August 2008 - announce - Fedora Mailing-Lists

by Huzaifa Sidhpurwala

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fedora Weekly News Issue 140 ================================= Welcome to Fedora Weekly News Issue 140 for the week ending August 24, 2008. http://fedoraproject.org/wiki/FWN/Issue140 Fedora Weekly News keeps you updated with the latest issues, events and activities in the Fedora community. If you are interested in contributing to Fedora Weekly News, please see our 'join' page. Being a Fedora Weekly News beat writer gives you a chance to work on one of our community's most important sources of news. Ideas for new beats are always welcome -- let us know how you'd like to contribute. http://fedoraproject.org/wiki/NewsProject/Join =Announcements= In this section, we cover announcements from the Fedora Project. http://www.redhat.com/archives/fedora-announce-list/ http://www.redhat.com/archives/fedora-devel-announce/ Contributing Writer: Max Spevack Fedora Infrastructure's ongoing issues Paul Frields continued to post[0] periodic updates about Fedora Infrastructure. "Our team has been hard at work for several days now, restoring services in the Fedora infrastructure. We started with what we identified as Fedora's "critical path," those systems required to restore minimum daily operation. That work to be completely finished by the end of the day. We then move on to our other value services to complete them as soon as possible." [0] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00011.... On August 22nd, a more complete report[1] was published. Rather than excerpt it here, Fedora Weekly News encourages readers to review the entire announcement. [1] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.... Finally, Dennis Gilmore announced[2] that "effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages." [2] http://www.redhat.com/archives/fedora-devel-announce/2008-August/msg00008... Email bounces Seth Vidal explained[3] that "a number of addresses @fedoraproject.org there were windows when those email addresses would have bounced reporting that the address did not exist." He goes on to say that the problem has been corrected, but anyone who wants the details should read the full message. [3] http://www.redhat.com/archives/fedora-devel-announce/2008-August/msg00007... =Planet Fedora= In this section, we cover the highlights of Planet Fedora - an aggregation of blogs from Fedora contributors worldwide. http://planet.fedoraproject.org Contributing Writer: Max Spevack This week on Planet Fedora... * Mairin Duffy posted[0] another draft of the Gears/Steampunk proposed wallpaper, and also [1] reminded everyone that the "deadline for round 2 of the Fedora 10 artwork process is 1 September 2008."[1] [0] http://mihmo.livejournal.com/60668.html [1] http://mihmo.livejournal.com/60797.html * Rex Dieter wrote several posts[2] about his trip to Akademy, the KDE uber-conference which was held this year in Brussels. [2] http://rdieter.livejournal.com/tag/akademy * Paul Frields announced[3] the Fedora Scholarship[4] program. "Now it?s finally official: a Fedora Scholarship. A while back, we started talking about ways to identify and cultivate young contributors to Fedora. We are starting to see more and more young people taking the opportunity to be full participants in the open source world. As part of our mission to develop a culture of contribution in FOSS and not just consumption, we want to identify and reward those individuals. One way we can do this is through the incentive of scholarship funds. This year we started the Fedora Scholarship to lead that effort. The inaugural winner, Ricky Zhou, is someone that many people may know from his exceptional work on our websites and infrastructure." [3] http://marilyn.frields.org:8080/~paul/wordpress/?p=1136 [4] https://fedoraproject.org/wiki/Scholarship * Karsten Wade has written a two[5] excellent posts[6] about the need for a Fedora CMS. His posts cover the differences between a CMS and a wiki, general requirements for any CMS that we choose, as well as a discussion of the scope of the project. Suggested reading for any members of the websites or documentation projects. [5] http://iquaid.org/2008/08/13/why-and-where-fedora-needs-a-cms-solution/ [6] http://iquaid.org/2008/08/19/fedora-cms-focus-and-scope/ =Ambassadors= In this section, we cover Fedora Ambassadors Project. http://fedoraproject.org/wiki/Ambassadors Contributing Writer: JeffreyTadlock Updated Q3 Budget Draft Max Spevack posted [1] an updated draft for the upcoming Q3 budget. The draft attempts to give more discretionary funds to North America, address concerns for FAD EMEA and leave a small amount in reserve for additional Q3 expenses that arise. Review the mailing list post for the detailed view. [1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-August/msg00... North America Polo Shirt Order - Round Two Pascal Calarco is ready to start a second round of ordering for Ambassador Polos as announced on the Fedora Ambassador mailing list [1]. There is also additional information in the wiki [2]. [1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-August/msg00... [2] https://fedoraproject.org/wiki/Ambassadors/NA#Fedora_Ambassador_Polo_Shir... Help Wanted: Austria LinuxDay 2008 Fabian Affolter posted [1] a request for help to organize a Fedora booth at the Austria LinuxDay 2008. The event is November 29, 2008 and expected attendance is 1000 visitors. If you are in the area and can attend, contact Fabian Affolter. [1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-August/msg00... =Developments= In this section the people, personalities and debates on the @fedora-devel mailing list are summarized. Contributing Writer: Oisin Feeley Mysterious Fedora Compromise The mysterious unavailability of much of the FedoraProject infrastructure (see FWN#139 "General Outage of Fedora Infrastructure"[1]) continued to provoke speculation during the week. Some light was shed[2] on 22-08-2008 when Paul Frields announced that there had been an intrusion onto several FedoraProject servers. The announcement emphasized that although one of the servers was used for signing rpm packages it was believed, based upon an absence of positive evidence, that the key and packages had not been tampered with. Nevertheless prudence and caution were being exercised and the opportunity was being seized to completely re-install and upgrade all systems. As a result it was necessary for most contributors to reset authentication tokens of various types (see this same issue[3].) It also appeared[4] that a concurrent event had led to the signing of some Red Hat OpenSSH packages, but that these had been quickly detected and had not led to the distribution of compromised packages. [1] http://fedoraproject.org/wiki/FWN/Issue139#General_Outage_of_Fedora_Infra... [2] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012... [3] "Epiphany, Konqueror and Plague Hamper Updating SSL Client-side Certificates" [4] http://www.redhat.com/security/data/openssh-blacklist.html Prior to that announcement all that was known was that there were problems on the build servers which became obvious to a wide audience on 13-08-2008 and that users were advised[5] on 14-08-2008 not to install updates. The wiki and email lists continued to function during this period thanks to the efforts of their administrators. [5] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008... An update[6] was posted on 18-08-2008 by Paul Frields that listed the services which had returned to normal and those which were expected to return to normal soon. Public speculation latched on[7][8] to the changing of "fedorahosted" SSH keys. Most guesses used this as evidence that something similar to the recent 2008 Debian OpenSSL vulnerabilities[9] had occurred. Some confusion prevailed[10] on @fedora-devel as to whether it was possible to trust the new key fingerprint on the website. Jim Meyering added[11] a useful post which explained how to change from using a DSA ssh key to an RSA ssh key. Overall there was a surprisingly low level of public discussion of the problem and it was not until 18-08-2008 that some complaints about the lack of information were expressed[12] on @fedora-list. On 22-08-2008 another bulletin was released[13] by Paul Frields that explained that the Fedora key had not been obviously compromised but that it was still being changed on the precautionary principle. [6] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00011... [7] http://lwn.net/Articles/294547/ [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00790.html [9] Metasploit has an excellent writeup on the topic here: http://www.metasploit.com/users/hdm/tools/debian-openssl/ [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00841.html [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00845.html [12] https://www.redhat.com/archives/fedora-list/2008-August/msg01953.html [13] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012... Although many responses to complaints about the limited information suggested[14] that the Fedora developers could be trusted to "do the right thing" in terms of alerting users to immediate threats of compromise there was still strong disquiet expressed[15] over the lack of information. This also occurred[16] on @fedora-list. Jef Spaleta wondered[17] if there might be a better way of getting information out than relying on everyone to subscribe to @fedora-announce. Alan Cox suggested[18] that an RSS feed for critical announcements could be picked up by a system's default package updater and that repositories could communicate errors to yum. Alan was also unhappy with the absence of important notices on the very front of the website and as a separate matter criticized the content of the information issued: "[...] leaving people in the dark assuming the worst [is] a very bad way to create long term trust." Bruno Wolf III also suggested[19] that information should have been conveyed by a more central announcement on fedoraproject.org and co-ordination with media such as LWN.net. [14] https://www.redhat.com/archives/fedora-list/2008-August/msg01955.html [15] https://www.redhat.com/archives/fedora-list/2008-August/msg02034.html [16] https://www.redhat.com/archives/fedora-list/2008-August/msg02426.html [17] https://www.redhat.com/archives/fedora-list/2008-August/msg02010.html [18] https://www.redhat.com/archives/fedora-list/2008-August/msg02012.html [19] https://www.redhat.com/archives/fedora-list/2008-August/msg02013.html Most comments on @fedora-devel made a point of thanking the Fedora Infrastructure admins, even to the extent of providing internet beers[20] and Hans de Goede commented[21] that "Even before the unfortunate events of the last few weeks the infrastructure team has been doing an amazing job[.]" [20] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01037.html [21] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01028.html Epiphany, Konqueror and Plague Hamper Updating SSL Client-side Certificates As part of the general overhaul of Fedora Project infrastructure security occasioned by the recent intrusion[1] Dennis Gilmore advised[2] that the certificate authority governing access to cvs.fedoraproject.org and koji.fedoraproject.org had been changed. As a result it was necessary for those who wished to build packages or upload to the lookaside cache to manually import a new client-side certificate and to remove their old certificate. [1] http://fedoraproject.org/wiki/FWN/Issue139#General_Outage_of_Fedora_Infra... [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00962.html Martin Sourada reported[3] that after following the procedure he still received a (Error code: ssl_error_unknown_ca_alert). Kai Engert suggested[4] that Martin might need to import the Fedora Project root CA certificate after verifying its fingerprint. As Martin had allowed exceptions for the Fedora websites this was not the problem and it turned out[5] to be due to a problem with the epiphany web browser failing to offer an option to remove old certificates. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00978.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00982.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00989.html Problems were also experienced[6] by Jose Matos, but this time with the konqueror web browser (version 4.1.0). Kevin Koffler replied[7] that in KDE 4 there was no support for SSL certificate authentication with konqueror and pasted a link[8] to an upstream bug report filed with the KDE project on this issue. [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00983.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00999.html [8] https://bugs.kde.org/show.bug.cgi?id=167668 Tim Jackson reported[9] that plague-client[10] was acting up and Michael Schwendt quickly provided[11] a patch which removed an assumption about how many bytes would be in the certificate. Dennis Gilmore commented "it's probably due to the new ca cert being 8096 bit and user certs are now all 2048 bit" and Chris Weyl filed[12] a bugzilla. [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00993.html [10] plague is the distributed package build system used by the EPEL repository [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00996.html [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01019.html Later Paul Howarth encountered[13] what seemed to be a problem with his key or koji but which turned out, as suggested[14] by Jason Tibbitts to be due to denyhosts blocking him. [13] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00970.html [14] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00971.html System Autodeath Seth Vidal raised[1] the possibility of including a non-default option to include an "autodie" feature in future Fedora releases. The idea, originally expressed[2] in Glen Turner's blog is that each OS release should ship with an expected expiry date and a means to automatically remove the default route from that machine once the expiry date arrives. This would prevent old, unmaintained machines from being quietly exploited. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00853.html [2] http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px Agreement was expressed[3] by Jon Masters that it would be useful if "a sysadmin consciously wants to remember to remove a system from production/upgrade it after a certain time but then loses track of it[.]" Rahul Sundaram also thought[4] that something should be done but preferred the idea of modifying PackageKit to notify users when an upgrade was due and fixing up PreUpgrade to allow users to easily update without burning media. Jon Ciesla and Colin Walters wrangled over whether LiveUpgrade or PreUpgrade was the appropriate place to present such notifications with Colin disliking the LiveUpgrade due to support logistics. Richard Hughes was pleased to relate[5] that most of Rahul's desired feature had been implemented only a couple of days previously. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00855.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00856.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00932.html Although Dave Jones was not worried[6] about desktop machines being abandoned this was contested. Dominik Mierzejewski related[7] anecdotes of people still running Fedora Core 2 while Stephen Smoogen regaled[8] the list with tales of hundreds of ancient Windows 3.11 clients on his network. Seth Vidal shared[9] Dave's insouciance and was more concerned about servers and "appliance-like machines" but promised to "look at putting a simple cron job together in a package to do this" while inviting anyone more motivated to go ahead and implement it. [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00861.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00862.html [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00865.html [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00863.html A slight misunderstanding of Seth's intentions led[10] Horst H. von Brand to put the case "[...] against forcing people forward, even for their own good[.]" Horst argued that some systems could not be updated due to reliance on unmaintained legacy software. After Seth explained that he was not recommending that the "autodeath" feature be made a default Horst still expressed[11] a worry that casual installation followed by forgetfulness could result in the unexpected deactivation of systems later on. He suggested that instead of removing the default route "to a nag screen when EOL nears, offer to set up for upgrade, show (current) pointers to scripts helping check if 3rd party stuff will still work, ... install /that/ by default, allow to disable/uninstall it (even while it is nagging)." Seth objected[12] forcefully to describing the removal of the default route as "kills itself" and this resulted in a spate of alternate name suggestions. [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00903.html [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00929.html [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00930.html James Hubbard saw[13] similarities to "Windows Genuine Advantage where you can't use your machine anymore if you can't validate your installation" and suggested instead that users be notified of the EOL and in a separate part of the thread Jef Spaleta suggested that "autoannoy", via motd or the login banner, instead of "autodeath" might educate and help users more than cutting off connectivity. [13] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00866.html Commenting on responses from Matt Miller[14][15] and Jason Tibbitts[16], among others, Seth Vidalcommented[17] that it appeared that "all the .edu people seem to get this". But Horst was skeptical[18] that it was necessary to force sysadmins to make such changes. [14] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00911.html [15] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00935.html [16] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00868.html [17] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00869.html [18] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00931.html James Hubbard also made[19] a strong argument that lack of updates was as much of a security problem as being EOL'ed and thus any such measures should also be applied to systems lagging in their updates. [19] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00959.html GNUstep Filesystem Layout Discussion A very clearly presented[1] explanation by Michel Salim kick started a discussion about how the GNUstep application development framework could finally be included in Fedora. Michel explained that GNUstep's idiosyncratic filesystem layout had previously made it impossible to install on an FHS[2] compliant system but that it was now possible. A choice had to be made for the layout of what GNUstep terms "application bundles" bearing in mind that "flattened" layouts are platform specific while "unflattened" can support multilib with little pain. Michel saw three main choices including a non-FHS-compliant one and noted that there were potential conflicts between utill-linux-ng and the default installation of GNUstep tools in /usr/bin/<arch>. He also noted that Debian had chosen to use an unflattened layout. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01007.html [2] http://www.pathname.com/fhs/pub/fhs-2.3.html#INTRODUCTION - From this point onwards the discussion became a little difficult to follow due to the use of GNUstep specific terminology. The simplest information your correspondent could find was the online version[3] of the library-combo manpage and is probably essential reading before even attempting to grasp the outlines of the following. [3] http://linux.die.net/man/7/library-combo A suggestion[4] from Axel Thimm was "[...] to place [the GNUstep tools] directly under %{_bindir} and let rpm deal with the different archs as it does for all other %{_bindir} mixing of subarchs with colors etc" and to put the libraries under %{_libdir}. He argued that multilib or multiarch binaries were not generally supported in Fedora. Axel was also encouraging about the idea of starting a wiki page to attract as wide a possible contribution from GNUstep developers including non-Fedora contributors. Even more importantly Axel contrasted the ability of an unflattened layout to support different compilers and libraries to that of a flattened layout which could make OpenGroupware[5] conflict with other applications due to its use of libFoundation[6.] Kevin Koffler was unimpressed[7] with "packages which think they are a distro" and posited the solution that "[...] they need to be fixed to work with the system libraries instead (or the system libraries fixed to work with the packages[.]" While Axel agreed he explained[8] that what was being chosen was an "Objective-C runtime/ foundation library/graphical interface tuple (flattened)" and that it was necessary to allow a choice at runtime of the middle component in order to support applications depending on either libFoundation or gnustep-base[9]. Axel concluded "[...] IMHO we need to start with gnustep-make's FHS and non-flattened layout and fix it where it still needs fixing (gnustep-make FHS layout is very young and one could say that we are shaking out the bugs and when we are finished hopefully upstream will be glad to accept any patch we will have made to the FHS mode layout of gnustep-make)." [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01009.html [5] A groupware server integrating office suites through XML-based interfaces: http://www.opengroupware.org/en/about/mission.html [6] Cocoa, libFoundation and gnustep-base all provide implementations of, and non-standard extensions to, the OpenStep API. Apart from licensing differences gnustep-base also has better platform coverage (Windows is not supported by the others) and full unicode support. [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01021.html [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01029.html [9] http://www.gnustep.org/developers/suite.html Discussion with Dominik 'Rathann' Mierzejewski and Kevin led Michel to post[10] that "[...] the consensus so far seems to be for using a flattened layout. Removing --disable-flattened from gnustep-make actually causes a much tighter adherence to the FHS, with %{_bindir} and %{_libdir} not containing any subdirectories." Michel was worried that this would result in duplicating data files and that "[...] keeping the unflattened layout might be too much trouble; if we are already flattening /usr/bin and /usr/lib*, might as well stick with a flattened layout after all." [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01024.html Apparently different conclusions were being reached at this stage and Axel attempted[11] to expand upon what he had said, explaining that this would result in having to choose between the Foundation libraries at buildtime. He presented unflattened layouts as allowing a choice of "libcombo" at runtime as opposed to flattened which forced a choice at buildtime. Dominik was[12] apparently comfortable with the idea of choosing between the two Foundation libraries and cited the precedent of not mixing lesstif and openmotif. To solve the problem he suggested "[put binaries in unflattened %{_libdir}/GNUstep/* and symlink to /usr/bin ." After Axel replied that the problem was the incompatible API/ABI of the Foundation libraries Michel posted[13] another summary of the current apparent state of knowledge. [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01039.html [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01040.html [13] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01054.html Varnish 2.0 Test Suite Fails in Rpmbuild An interesting post from Ingvar Hagelund, the maintainer of the varnish http accelerator package, asked[1] why a test suite in the package would behave differently within the rpmbuild created environment than when run from an interactive shell. Ingvar had eliminated selinux as a possibility and speculated "[...] the problem seems to be related to some missing communication between the test scripts and the test server process." [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00944.html A response from Mogens Kjaer contained[2] a report that it was to do with a missing libvarnish.so.0 and wondered "[...] is the build system using an already installed libvarnish.so.0 if one is available and not the newly built libvarnish.so.0?" Jason Tibbitts suggested[3] that it was usual to reference such newly built libraries by manipulating LD_LIBRARY_PATH in the specfile. After Mogens added LD_LIBRARY_PATH and rebuilt from scratch he found[4] that all the tests were passed but that no varnish-libs had been installed and this led him to conclude that there was indeed a difference to the rpmbuild environment. [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00945.html [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00946.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00948.html Ingvar ended up[5] filing a bug report upstream with the conclusion that the soname version should be bumped as the old libraries were incompatible with varnish-2.0. [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00951.html =Infrastructure= This section contains the discussion happening on the fedora-infrastructure-list http://fedoraproject.org/wiki/Infrastructure Contributing Writer: HuzaifaSidhpurwala So everyone is aware Mike McGrath writes for fedora-infrastructure-list [1] This is the first notice when came out to the community that there will be outages and a lot of the servers are being rebuild. Mike pointed to the mail on fedora-announce-list [2] [1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms... [2] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.... securing FAS certs Toshio Kuratomi writes for fedora-infrastructure-list [3] The Fedora Certificates issued by FAS are currently set to be autogenerated if you have an account in FAS. This has one drawback. We have to keep the password for the CA keys that sign the FAS certificates in a file on the filesystem so that the automatic signing can use them. Toshio suggested that we use a system which utilizes human interaction to sign the certs. [3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms... =Artwork= In this section, we cover the Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: Nicu Buculei One Canvas Workflow MartinSourada talked[1] on the Fedora Art list about the One Canvas Workflow: "I think we need to be up to date with technology, so I started downloading the One Canvas Workflow screencast by jimmac. I haven't tried it yet (but going to do so very soon), but from the people who already tried it and shared their thoughts about it, it seems like it would be improvement for the Echo Icon Theme creation workflow". And quickly after this he presented[2] the first icons created using this process, an opportunity to introduce icons at a very large size (256x256px) and with an increased amount of details[3]. Editor's note: One Canvas Workflow is an improved way to create multiple icon size in one single sheet, advocated by the famous designer and GNOME hacker Jackub Steiner "jimmac"[4]. [1] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00290.html [2] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00292.html [3] https://www.redhat.com/archives/fedora-art-list/2008-August/pngNdtP7y3qw7... [4] http://jimmac.musichall.cz/log/?p=436 Fedora Art Team Monthly Picks MairinDuffy proposed an initiative: "maybe the Fedora Art Team could do a monthly art pack (kind of along the likes of the iCE and ACiD art groups' monthly art packs) that would be a selection of say the top 10 best art works producing using Fedora (inkscape, gimp, etc., it just has to be software that's available in Fedora used to produce it.)", with the intention to promote the works created by the member of the team: "I think this might be a good way of getting more recognition to our artists as well as to what Fedora can do". The talk is open for details about the technical implementation. [1] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00298.html Round 2 theming developments With the deadline for the second round for theming the upcoming Fedora 10, a number of theme proposals received updates: Gears[1], Solar[2] and InvinXible[3] and each of them is under evolution in the remaining week. [1] http://mihmo.livejournal.com/60668.html [2] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00293.html [3] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00300.html =Security Advisories= In this section, we cover Security Advisories from fedora-package-announce. https://www.redhat.com/mailman/listinfo/fedora-package-announce Contributing Writer: David Nalley Fedora 9 Security Advisories None Fedora 8 Security Advisories None -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIsouNzHDc8tpb2uURAha9AJ4zU09+HRTb5qWzjNkB/12rF+z3SACgjOLa d6o4kC3gaPbsa0Ud8wlS3nM= =FRVA -----END PGP SIGNATURE-----

15 years, 3 months

1
0
0 / 0

Fedora Unity releases Fedora 8 Re-Spin

by Ben Williams

The Fedora Unity Project is proud to announce the release of new ISO Re-Spins (DVD Sets) of Fedora 8. These Re-Spin ISOs are based on the officially released Fedora 8 installation media and include all updates released as of August 14th, 2008. The ISO images are available for i386, x86_64 and PPC architectures via Jigdo and Torrent starting Sun August 24th, 2008. Go to http://spins.fedoraunity.org/spins to get the bits! DVD Media Only Due to packaging problems, this is a DVD Only Re-spin Bugs solved in this Re-Spin With this particular Re-Spin, fixes for the following bugs are included, like on our last Fedora 8 Re-Spin releases[1 <https://www.redhat.com/archives/fedora-announce-list/2007-December/msg000...>,2 <https://www.redhat.com/archives/fedora-advisory-board/2008-April/msg00001...>]: * #372011, "depsolve hang in F7 to F8 upgrade" We have incorporated the updates image made by Jeremy Katz (comment #11 in the bug), and we have verified that a full Fedora 7 installation upgrades to Fedora 8 without issues. * #367731, "anaconda fails on Via VPSD motherboard" On i586 hardware, the installation media wouldn't boot and thus renders itself unusable. We have backported the fix for this issue from anaconda development to the Fedora 8 stock anaconda, as anaconda is not updated during a release. * #369611, "yum upgrade with selinux-policy-strict installed fails" A dependency problem in selinux-policy-strict during upgrades is resolved in an updated selinux-policy-strict package, which is included in the Re-Spin * #404601, "anaconda crashes on 'cdrom' line in kickstart" Updates to pykickstart incorporated in the rebuilt installer resolve this issue. * #420281, Cannot find kickstart file during unattended installation The kickstart file name searched for after booting from CD or DVD with option "linux ks" and using a dhcp and nfs server is wrong. Attention: Changes in this Re-Spin Also, we would like to let you know that NetworkManager is now installed by default, and for people doing minimal installations; this service will need to be disabled before the network starts to work. Thanks to We would like to give a special thanks to the following for testing this Re-Spin: - zcat Jason Farrell - vwbusguy- Scott Williams - Southern_Gentleman Ben Williams - kanarip Jeroen van Meeuwen Testing Results A full test matrix can be found at our Test Matrix <http://spins.fedoraunity.org/Members/Southern_Gentleman/fedora-8-re-spin-...> A full list of bugs, packages and changelogs that have been updated in this Re-Spin can be reviewed on http://spins.fedoraunity.org/changelogs/20080814/ Previous Re-Spin (20080501) will expire Due to limited resources, this spin will immediately obsolete 20080501, which will be deleted from our mirrors in the next few days. Fedora Unity has taken up the Re-Spin task to provide the community with the chance to install Fedora with recent updates already included. These updates might otherwise comprise more than 2.05GiB of downloads for a full install. This is a community project, for and by the community. You can contribute to the community by joining our test process. Go to http://spins.fedoraunity.org/spins to get the bits! Assistance Needed If you are interested in helping with the testing or mirroring efforts, please contact the Fedora Unity team. Contact information is available at http://fedoraunity.org/ or the #fedora-unity channel on the Freenode IRC Network (irc.freenode.net). To report bugs in the Re-Spins please use http://bugs.fedoraunity.org/

15 years, 3 months

1
0
0 / 0

Infrastructure report, 2008-08-22 UTC 1200

by Paul W. Frields

Last week we discovered that some Fedora servers were illegally accessed. The intrusion into the servers was quickly discovered, and the servers were taken offline. Security specialists and administrators have been working since then to analyze the intrusion and the extent of the compromise as well as reinstall Fedora systems. We are using the requisite outages as an opportunity to do other upgrades for the sake of functionality as well as security. Work is ongoing, so please be patient. Anyone with pertinent information relating to this event is asked to contact fedora-legal(a)redhat.com. One of the compromised Fedora servers was a system used for signing Fedora packages. However, based on our efforts, we have high confidence that the intruder was not able to capture the passphrase used to secure the Fedora package signing key. Based on our review to date, the passphrase was not used during the time of the intrusion on the system and the passphrase is not stored on any of the Fedora servers. While there is no definitive evidence that the Fedora key has been compromised, because Fedora packages are distributed via multiple third-party mirrors and repositories, we have decided to convert to new Fedora signing keys. This may require affirmative steps from every Fedora system owner or administrator. We will widely and clearly communicate any such steps to help users when available. Among our other analyses, we have also done numerous checks of the Fedora package collection, and a significant amount of source verification as well, and have found no discrepancies that would indicate any loss of package integrity. These efforts have also not resulted in the discovery of additional security vulnerabilities in packages provided by Fedora. Our previous warnings against further package updates were based on an abundance of caution, out of respect for our users. This is also why we are proceeding with plans to change the Fedora package signing key. We have already started planning and implementing other additional safeguards for the future. At this time we are confident there is little risk to Fedora users who wish to install or upgrade signed Fedora packages. In connection with these events, Red Hat, Inc. detected an intrusion of certain of its computer systems and has issued a communication to Red Hat Enterprise Linux users which can be found at http://rhn.redhat.com/errata/RHSA-2008-0855.html. This communication states in part, "Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers." It is important to note that the effects of the intrusion on Fedora and Red Hat are *not* the same. Accordingly, the Fedora package signing key is not connected to, and is different from, the one used to sign Red Hat Enterprise Linux packages. Furthermore, the Fedora package signing key is also not connected to, and is different from, the one used to sign community Extra Packages for Enterprise Linux (EPEL) packages. We will continue to keep the Fedora community notified of any updates. Thank you again for your patience. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

15 years, 3 months

1
0
0 / 0

Infrastructure status, 2008-08-19 UTC 0200

by Paul W. Frields

Our team has been hard at work for several days now, restoring services in the Fedora infrastructure. We started with what we identified as Fedora's "critical path," those systems required to restore minimum daily operation. That work to be completely finished by the end of the day. We then move on to our other value services to complete them as soon as possible. Please give the infrastructure team the time they need to do this demanding work. They have been doing a spectacular job and deserve the absolute highest credit. The systems that are now back online and usable include the following: * Puppet, Xen and FAS hosts * app1, app3, and app4 * database and proxy servers * the majority of the Xen guest machines * serverbeach5, serverbeach4 * Fedora Hosted** The systems that should be available very soon: * asterisk1 and collab1 * cvs1 * builders, x86 and ppc * Fedora People We know the community is awaiting more detail on the past week's activities and their causes. We're preparing a timeline and details and will make them available in the near future. We appreciate the community's patience, and will continue to post updates to the fedora-announce-list as soon as possible. = = = ** New SSH fingerprint for Fedora Hosted: e6:b3:68:51:98:2d:4c:dc:63:27:46:65:51:d5:f0:7a -- Paul W. Frields, Fedora Project Leader gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

15 years, 3 months

1
0
0 / 0

Fedora Weekly News, Issue 139

by Pascal Calarco

* 1 Fedora Weekly News Issue 139 o 1.1 Announcements + 1.1.1 Board IRC Public Meeting + 1.1.2 Fedora Test Day: Encrypted Installs & Plymouth + 1.1.3 ACL Changes and New Package Group Policy + 1.1.4 Important Infrastructure Announcement o 1.2 Planet Fedora + 1.2.1 Tech Tidbits + 1.2.2 Artwork + 1.2.3 Features o 1.3 Developments + 1.3.1 FlashPlayer 10 Symlink Provokes Proprietary Support Argument + 1.3.2 Parallel Install of syslog-ng, rsyslog and sysklogd + 1.3.3 General Outage of Fedora Infrastructure + 1.3.4 Koji from Behind a Firewall + 1.3.5 Small Machine SIG o 1.4 Artwork + 1.4.1 Fedora 10 Themes: development and deadlines o 1.5 Security Advisories + 1.5.1 Fedora 9 Security Advisories + 1.5.2 Fedora 8 Security Advisories = Fedora Weekly News Issue 139 = Welcome to Fedora Weekly News Issue 139 for the week ending August 17, 2008. http://fedoraproject.org/wiki/FWN/Issue139 Fedora Weekly News keeps you updated with the latest issues, events and activities in the Fedora community. If you are interested in contributing to Fedora Weekly News, please see our 'join' page. Being a Fedora Weekly News beat writer gives you a chance to work on one of our community's most important sources of news. Ideas for new beats are always welcome -- let us know how you'd like to contribute. http://fedoraproject.org/wiki/NewsProject/Join = Announcements = In this section, we cover announcements from the Fedora Project. http://www.redhat.com/archives/fedora-announce-list/ http://www.redhat.com/archives/fedora-devel-announce/ Contributing Writer: Max Spevack == Board IRC Public Meeting == Paul Frields reminded us[1] that the Fedora Board's monthly IRC meeting was scheduled for August 12. [1] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00006.... == Fedora Test Day: Encrypted Installs & Plymouth James Laska informed us[1] that the Fedora QA team is organizing a test day specifically for working on encrypted installs and plymouth (the replacement for rhgb). "There will be a cast of testers and developers on hand between 8am - 5pm EDT (12:00 - 21:00 UTC) to help guide testing, answer questions, triage and troubleshoot issues." [1] http://www.redhat.com/archives/fedora-devel-announce/2008-August/msg00005... == ACL Changes and New Package Group Policy Casey Dahlin wrote[1] about the new Fedora Account System group policy, implemented "to encourage greater openness in the community while containing newer members until they have earned the trust of the community". The full text includes a discussion of the changes that have been made. [1] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00007.... == Important Infrastructure Announcement == Paul Frields announced[1]: "The Fedora Infrastructure team is currently investigating an issue in the infrastructure systems. That process may result in service outages, for which we apologize in advance. We're still assessing the end-user impact of the situation, but as a precaution, we recommend you not download or update any additional packages on your Fedora systems." [1] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.... = Planet Fedora = In this section, we cover the highlights of Planet Fedora - an aggregation of blogs from Fedora contributors worldwide. http://planet.fedoraproject.org Contributing Writer: Max Spevack == Tech Tidbits Kushal Das announced[1] a new version of the liveusb-creator GUI application. Separate from the livecd-tools and livecd-iso-to-disk application, liveusb-creator is packaged in its own RPM. Kushal writes, "liveusb-creator version 2.7 for Linux is released... Now feel free to create liveusb images for your friends and for the special one." Nigel Jones discussed[2] a variety of wiki improvements that have been deployed. This is a three-round improvement process. Nigel said of the first two rounds "At the request of the documentation team we enabled searching by default on various namespaces, of course, you most likely won't notice it at all. Round 2 of wiki improvements start tomorrow, this is the exciting one. We are trashing the current authentication method IN THE BIN! No more htaccess prompts... What's going in its place? The standard Mediawiki login prompt, it'll still be connected to FAS, it'll just look different." [1] http://kushaldas.in/?p=284 [2] http://nigelj.livejournal.com/8525.html == Artwork == Mairin Duffy gave us a look[1] at some of the proposed Fedora 10 artwork in the "gears" theme, which is a collaboration between her and Nicu Buculei. [1] http://mihmo.livejournal.com/60026.html == Features == Two interesting posts about the Fedora feature process this week. First, John Poelstra discussed the Fedora 10 feature status[1], saying: "Feature freeze for Fedora 10 is this coming Tuesday, August 19, 2008. The current list for Fedora 10 is growing with more waiting to go through the acceptance process here. At feature freeze all features must be significantly completed and testable or they will have to wait for Fedora 11. During this release cycle I collaborated with Paul Frields who greatly improved the documentation explaining the process. We also got help from the Fedora art folks to make the process diagram better. We also changed the categories used to classify feature pages in an attempt to bring greater clarity there." In a separate post[2], Paul Frields mused on the benefits of changing the way new Fedora spins are handled from a feature point of view. [1] http://poelcat.wordpress.com/2008/08/14/fedora-10-feature-process-and-bey... [2] http://marilyn.frields.org:8080/~paul/wordpress/?p=1129 = Developments = In this section the people, personalities and debates on the @fedora-devel mailing list are summarized. Contributing Writer: Oisin Feeley == FlashPlayer 10 Symlink Provokes Proprietary Support Argument == A formal request to remove the "miniature libcurl.so.3 library" was made[1] by Josh Boyer. This had been created in order to support the latest version[2] of Adobe's proprietary Flash Player which had a hard dependency on libcurl.so.3 while Fedora 8, Fedora 9 and Fedora 10(alpha) provided only libcurl.so.4. Josh argued that the change, mentioned on Warren Togami's blog[3] had been made solely to accommodate a proprietary application. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00476.html [2] http://labs.adobe.com/technologies/Flashplayer10/ [3] http://wtogami.livejournal.com/27778.html After NikolayVladimirov argued[4] that it was a minimal, non-invasive change which might be useful for some "dead opensource projects that use the old version" Josh replied[5] this support goal would be better met by providing a "compat-curl" package instead of "just a hack with the sole intention of making Flash work again". In an aside he mentioned that he would have no objection to removing libflashsupport and a bunch of other stuff. Matthew Garrett followed[6] the train of thought to one possible final destination: "If the ABI is consistent across the SONAME bump, then it's a hack that supports any pre-existing binaries that users have. The best way we could serve those users with a compat package would be to ship another copy of the latest version of curl (so they get the bugfixes) but with a changed SONAME - at which point we'd be shipping two identical source packages that produce binary packages that differ only in library name. In doing so, we'd be increasing the cost of security updates. What does that actually win us?" [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00484.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00484.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00498.html Bastien Nocera thought[7] that such a "compat-curl" package would duplicate unmaintained code and was pointless "since libcurl didn't break ABI, and only changed soname". Josh stood firm[8] and retorted that if the ABI was static then the applications could simply rebuild against the newer libcurl. Warren Togami characterized[9] Josh's viewpoint as "extremist" as it proposed "removing a zero maintenance 2496 byte file that would permanently break Flash 10 forever in Fedora" and that furthermore "[Adobe] are not violating any licenses like NVidia[.]" Following similar sentiments from "drago01" Josh deferred the discussion to a FESCo meeting held on Wed 13th August and this duly decided[10] to leave things as they were with two soname files in the curl package despite some strenuous objections which emphasized both the desirability of sub-packaging and also of not catering to the needs of proprietary applications. [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00486.html [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00488.html [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00496.html [10] http://bpepple.fedorapeople.org/fesco/FESCo-2008-08-13.html == Parallel Install of syslog-ng, rsyslog and sysklogd == Douglas Warner sought help[1] in packaging syslog-ng so that it could be installed with either of the other current system loggers: rsyslog and sysklogd. He explained that all three installed their own "logrotate" files which targeted the exact same log files for rotation and thus doubly rotated the logs. So far Douglas' attempt to change his own syslog-ng package to fix this was stymied on RHEL boxes because updates of sysklogd (RHEL's preferred system logger) silently remove syslog-ng. Later in the thread Benny Amorsen provided[2] the insight that running syslog-ng for handling remote logs and rsyslog for its simple configuration simultaneously was useful. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00531.html [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00632.html The question of how to ship precisely the same logrotate script, from the viewpoint of RPM, was mentioned[3] by Douglas as one possible solution. If this could be done then RPM would be agnostic about where the file came from as long as it were possible to figure out whether the identity was based on "file size, md5, timestamp, ?". Ville Skyttä suggested[4] using the %verify directive as detailed in a link to the "Maximum RPM" book. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00558.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00577.html A restructuring of the problem by Jason Tibbits led him to recommend[5] that a separate logrotation-script package be split out of the current packages and that each of the current packages be made to depend on the new package. When Douglas nixed the suggestion due to his lack of control over the sysklogd script Jason seemed[6] to react a little testily and asked "Could we discuss technical solutions and ignore Red Hat politics? What I proposed is a standard method of dealing with these things." After JarodDiamond agreed with this Dmitry Butskoy pointed[7] out that a different PID filename is used in each script and wondered was it possible to to create such a common logrotate package for all the syslog-like packages. A likely solution was proposed[8] by Chris Adams which used the expedient of symlinking each of the unique PID files from within the init script. [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00561.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00563.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00584.html [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00604.html == General Outage of Fedora Infrastructure == Many were caught by surprise when there was a widespread outage of Fedora Project infrastructure during the week. The earliest symptoms noticed included an inability to access Koji (see e.g. this FWN#139 "Koji from Behind a Firewall") or obtain updates with yum. A general announcement by Paul Frields followed[1] quickly on Thursday 14th and stated that an "issue in the infrastructure systems [was being investigated and might] result in service outages[.]" Somewhat ominously it concluded "[..] as a precaution, we recommend you not download or update any additional packages on your Fedora systems." This led some to speculate[2] that there might be a security problem. [1] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008... [2] http://lwn.net/Articles/294188/ Further announcements or explanations were not forthcoming for days, except for a post to @fedora-infrastructure which suggested[3] that the problem was causing a lot of hard work. Paul Frields posted another update[4] on Sat 16th. This succinctly stated that the wiki and FAS should be back soon but that the application servers would take a bit longer. [3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms... [4] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00009.... As of Sunday evening it became obvious that a very major amount of work was being undertaken to recover from the problem. It is worth noting that the email lists and the wiki were functional most of the time thanks to the commitment of their administrators. == Koji from Behind a Firewall == A query was made[1] by Victor Lazzarini about how to connect to Koji using the CLI from behind a firewall. He wondered specifically how to set up a proxy connection. He added that he was seeing an error when using a web browser but was[2] unable to provide it due to the general outage in Fedora infrastructure. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00660.html [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00664.html Mike Bonnet answered[3] that Koji did not have direct proxy support but that it used only ports 80 (http) and 443(https) as these are generally open. He explained that it would be "a significant amount of effort" to support proxies directly. Unfortunately Vincent had to report[4] that his institution forced everything through a proxy due to being "paranoid about security) and he was stuck with either setting up an open access machine or working from home. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00665.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00667.html A possibility for the web browser error was supplied[5] by Andrew Price as an ssl_error_handshake_failure_alert which he had seen prior to the general outage. [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00675.html == Small Machine SIG == An effort to gauge interest in starting a small form-factor machine SIG was made[1] by Jeremy Katz. He asked that anyone interested in running Fedora on the Asus Eeepc, netbooks, UMPCs, MIDs and perhaps the XO would contribute to a wiki page[2]. The specific goals were both to "just get the hardware working well with [current] Fedora" and also "possibly a spin that is explicitly targeted at some of the constraints of the hardware down the line." Several people responded and added themselves to the wiki. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00497.html [2] http://fedoraproject.org/wiki/JeremyKatz/Netbooks Peter Robinson defined the goal as "a small, low power image with packages without massive dependencies" while Jaroslav Reznik called[3] for an emphasis on the UI instead of merely on drivers for hardware support. Kevin Verma agreed[4] that "more usable UIs for small devices, also apps that are more adaptive to small screens" were important, and cited Maemo[5] and Moblin[6] as inspirations. Kevin had already[7] done some packaging work in this area. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00576.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00589.html [5] Maemo is Nokia's software platform for internet tablets. It is based on GTK+. See http://maemo.org/ for more information. [6] http://fedoraproject.org/wiki/FWN/Issue136#RPM_Inspires_Intel_Moblin2_Shi... [7] http://kevinverma.fedorapeople.org/packages/ Jeremy Katz responded[8] that given the imminent release of Fedora 10 it was most likely that better hardware support would be the immediately achievable goal. While agreeing that Maemo was interesting he preferred to get Sugar[9] running within the Fedora 11 timeframe. In answer to JeffSpaleta he clarified[10] that recent work done by Greg DeKoenigsberg to run "stock" Fedora on the XO was relevant but a different goal from producing a spin of Fedora, for all small machines, using the Sugar interface. [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00594.html [9] The unique interface developed for the resource-constrained XO produced by the OLPC project [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00609.html The main developer of BLAG[11], Jeff Moe, posted[12] links to images that supported "all hardware on the EeePC 701/900 using *only* free software. This includes wifi with the ath5k driver. It is based on -libre and -rt plus various other patches." Jeremy Katz re-phrased[13] his goal as "[to] be able to run on the systems with stock Fedora" in order to avoid the distribution problem of special spins. Jeff encouraged[14] this possibility with the information that apart from wireless the stock Fedora 9 kernel supported everything on the EeePC 701/900 and that although there was support for the Atheros ar2425 wireless chip support in the 2.6.27 kernel there were still specific patches lacking for EeePCs. He added that the EeePC 901/1000 used a different wireless chip (from Ralink who have been active in releasing information necessary for Free drivers in the past) and included a link to Ralink's code for an apparently complete RT2860 ABGN driver. Warren Togami confirmed[15] that there were vague rumors that the chipset would be supported upstream. [11] A single-CD derivative of Fedora 9 which is strictly Free Software. See https://wiki.blagblagblag.org/FAQ [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00511.html [13] www.redhat.com/archives/fedora-devel-list/2008-August/msg00533.html [14] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00537.html [15] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00550.html After Rex Dieter asked why the BLAG folks were not upstreaming their changes to Fedora it was explained[16] by Jeff that he filed bug reports and mailed .spec files upstream but that they were perhaps in conflict with the packaging guidelines. He also alluded to the fact that much of his work centered around the "kernel-libre" which had caused flamewars in the recent past. In conclusion he noted that he had been able to perform many simultaneous tasks "while playing a song with *zero* stutters or dropouts on a teeny little computer. That rules." but that it required the use of the low-latency audio server JACK[17], that is non-standard on Fedora. [16] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00554.html [17] http://jackaudio.org/ Surprisingly no mention was made during the discussion of the "Eeedora" distribution which had been written about[18] in Red Hat Magazine towards the start of this year. [18] http://www.redhatmagazine.com/2008/02/14/fedora-eee-pc-eeedora/ = Artwork = In this section, we cover the Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: Nicu Buculei == Fedora 10 Themes: development and deadlines == On the Fedora Art list NicuBuculei started[1] the work on the second round for creating the Fedora 10 desktop theme: "since the first round ended, we had very little theme activity, so maybe is time to heat the things a bit" and he posted an "work in progress" graphic[2]. [1] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00206.html [2] https://fedoraproject.org/wiki/Image:Gears-r2.png This was quickly followed by MairinDuffy, who, liking the concept, developed it further[3] with various designs, which were enthusiastically received by the rest of the team. She also wrote on her blog[4], showing the progress to the larger community. [3] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00208.html [4] http://mihmo.livejournal.com/60026.html In related theming news, MairinDuffy as the leader of the Art Team announced[5] a deadline for the Round 2, as an incentive for the rest of the team and also to fit the release schedule "Let's set the deadline for round 2 to 1 September 2008. Sound like a good idea? Consider this an official kick in the pants to get more artwork flowing". [5] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00229.html = Security Advisories = In this section, we cover Security Advisories from fedora-package-announce. https://www.redhat.com/mailman/listinfo/fedora-package-announce Contributing Writer: David Nalley == Fedora 9 Security Advisories == * condor-7.0.4-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00... == Fedora 8 Security Advisories == none

15 years, 3 months

1
0
0 / 0

Infrastructure status, 2008-08-16 UTC 1530

by Paul W. Frields

The Fedora Infrastructure team continues to work on the issues we discovered earlier this week. Right now, we're getting the account system restored to service, along with some of the application servers. We're also taking advantage of the outages to upgrade a few systems at the same time. Some services such as the Account System and the wiki should return to normal over the weekend, but we expect outages to continue for some other systems. Please be patient as we continue to work the problem. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

15 years, 3 months

1
0
0 / 0

Important infrastructure announcement

by Paul W. Frields

The Fedora Infrastructure team is currently investigating an issue in the infrastructure systems. That process may result in service outages, for which we apologize in advance. We're still assessing the end-user impact of the situation, but as a precaution, we recommend you not download or update any additional packages on your Fedora systems. We'll share updates as we develop more information. Those updates will be published here on the public fedora-announce-list: https://redhat.com/mailman/listinfo/fedora-announce-list Thanks for your patience as we continue working on this. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

15 years, 3 months

1
0
0 / 0

ACL Changes and new package group policy

by Casey Dahlin

The infrastructure team has been working on a new group policy to encourage greater openness in the community while containing newer members until they have earned the trust of the community. As such, the following changes are being implemented: 1) Effective already: The "cvsextras" group is now known as "packager." A bit more descriptive to start. 2) Effective in the next few days, members of "packager" formerly "cvsextras" will only have access to packages they own or comaintain directly. 3) Users who need to modify packages distro-wide can be added to the "uberpackager" group. Anyone who maintains 8 or more packages or is a sponsor in the "packager" group is in this group already. IF YOU NEED THIS ACCESS, IT SHOULD COST NO EFFORT TO GET. All members of the group are sponsors for the group as well, and sponsoring another individual is intended to be a low-to-no effort process. If they haven't broken the entire distro recently, and you haven't seen them talking about "porting Fedora to internet" on devel-list, you should sponsor them as soon as they ask. 4) After the above changes have taken effect, all packages which currently have locked down Acls will be opened to the entire "uberpackager" group. If you are a maintainer and object to this, please reconsider. If upon reconsideration you still strongly object, there is a checkbox labeled "Open package during mass ACL open?" on your package's pkgdb page which will allow you to opt out of this change. Let me know if you have any questions. --CJD

15 years, 3 months

1
0
0 / 0

Board public IRC meeting

by Paul W. Frields

Reminder: a Board public IRC meeting will be held today at 1800 UTC. Details are on the wiki at: https://fedoraproject.org/wiki/Board/IRC -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

15 years, 3 months

1
0
0 / 0

Fedora Weekly News #138

by Huzaifa Sidhpurwala

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fedora Weekly News Issue 138 ============================ Welcome to Fedora Weekly News Issue 138 for the week ending August 11, 2008. http://fedoraproject.org/wiki/FWN/Issue138 Fedora Weekly News keeps you updated with the latest issues, events and activities in the Fedora community. If you are interested in contributing to Fedora Weekly News, please see our 'join' page. Being a Fedora Weekly News beat writer gives you a chance to work on one of our community's most important sources of news. Ideas for new beats are always welcome -- let us know how you'd like to contribute. We are still looking for a beat writer to summarize the Fedora Events and Meetings that happened during each week. http://fedoraproject.org/wiki/NewsProject/Join == Developments == In this section the people, personalities and debates on the @fedora-devel mailing list are summarized. Contributing Writer: Oisin Feeley =Solving the Unsynchronized Release of Package Dependencies= A problem often experienced by users of "add-on" packages[1] is that dependency resolution will fail during a simple yum update when the official Fedora repositories release an update to the base packages on which these add-ons depend. ThorstenLeemhuis explained[2] that as add-on packages have a strict dependency on the base packages for which they were built and updates are not available at exactly the same time on all mirrors there is no ideal point in time for the add-on to be released. Thorsten's RFC was careful to point out that the problem did not only affect kmods, but also plugins for audacious, xine and k3b and that the resulting dependency resolution failures occurred both when the add-on was visible to yum before the base package and vice versa. The two possible solutions envisioned by Thorsten included either yum being modified "to be taught to do a second look at the right place to find what's needed" or the third-party repositories to include the updated base packages along with the updated add-on. Thorsten feared that this latter option of "shipping non-free kernel modules and the GPLed kernels in one repo might [make] some people yell license violation." [1] Such packages are hosted by "third-party" repositories, which are run independently of the Fedora Project. The packages, while highly useful for many Fedora users, are deemed to be legally non-distributable due to the laws of the U.S.A. [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html A report of daily failures of this type occurring for Rawhide without any complicating third-party repository was posted[3] by John Ellson. He gave two examples from his current machine. The first was a missing dependency error: $ yum update phonon* Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by package phonon-backend-gstreamer-4.2.0-1.fc10.x86.64 (installed) and the second was a file conflict error: $ yum update digikam* Transaction Check Error: file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of digikam-0.10.0-0.1.beta2.fc10.x86.64 conflicts with file from package oxygen-icon-theme-4.1.0-1.fc10.noarch [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00044.html John wished that yum would skip updating all rpms which produce conflicts with currently installed rpms whether or not they are third-party or otherwise, especially as neither of these issues had been flagged in the appropriately dated "Rawhide report". A good deal of the remainder of thread was devoted to replying to this post instead of to Thorsten's RFC. The first response came[4] from MichaelSchwendt and made the point that the first error was probably due to an incorrect "Obsoletes" tag in the !code?phonon-backend-gst!/code? that is supposed to replace phonon-backend-gstreamer. The script which checks for broken dependencies in Rawhide cannot detect this as the phonon-backend-gstreamer is not visible to it. Michael addressed the second error with the point that conflicts are entirely different from dependency issues and are not checked. RexDieter, as package maintainer, quickly fixed both of the problems and in doing so demonstrated that users filing bug reports can be an effective part of the current process. Thorsten also emphasized[5] that the two errors posted by JohnEllson were entirely different from each other and that the conflict was a bug best dealt with by user reports. He further argued that it was impossible for the Rawhide dependency checker script to examine the contents of users' hard disks. All that the script can do is examine the current contents of Rawhide and as the phonon-backend-gstreamer was long gone it could not test a theoretical update from it. Michael Schwendt later added[6] that although his own "repoclosure" script developed for the old "Extras" repository had been able to take account of "obsolete binary [packages] from the previous compose [...] because in Extras we've had up to two pkg releases in the repo[sitory ...] the Rawhide report is like a fresh install of only the latest [package] releases, and one can only hope that there are enough testers who find and report the additional update/upgrade problems." Michael claimed[7] that as the FedoraProject policy on file conflicts was "half-hearted" he was uninterested in shouldering the burden of running the script himself. He also noted that Florian La Roche had a script for determining conflicts between files and symlinks. [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00045.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00046.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00097.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00048.html During this discussion JohnEllson was unimpressed[8] with the theoretical reasons as to why he was seeing these problems and requested that even if it were not possible to do such checks on the server "[j]ust have yum on the client recover gracefully from these and skip over them." [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00047.html Similarly David Timms wondered[9] if the original problem stated in the RFC could be solved by using the yum option --skip-broken if it were made to select only those packages which were: available, non-conflicting, non-dependency-breaking and actually downloadable.Thorsten restated[10] his belief that this was effectively hiding the problem instead of fixing it and would result in users being unaware that important updates were blocked solely due to a manually installed problem RPM. Instead he suggested setting a window of time during which updates with broken dependencies would be ignored and then finally reported as errors. Seth Vidal corrected[11] the impression that "skip broken" was a plugin to yum (it is now a core option) and while agreeing that "a tool to detect all these issues is worth discussing, not sure how we catch all possible conflicts, though" seemed to confuse Thorsten's window of time with checking the actual package creation filestamp. JesseKeating also appeared[12] to fall prey to this confusion and like Seth pointed out the problem of queued packages sitting in repositories before being released. To clear this confusion up Thorsten posted[13] a more detailed explanation which emphasized that the times being examined were relative to the client-side's first encountering of the problem and made no reference to the build-date or publication date of the package itself. The advantage of Thorsten's seventy-two hour window scheme is that it gives packagers a grace period in which to correct the problem and at the end of that the same situation prevails as now, namely that the update will fail and users will notice and report the errors. [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00049.html [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00099.html [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00150.html [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00153.html [13] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00154.html =Firefox Mouse Woes= MarkG reported[1] that Firefox did not respond to the scroll wheel on GNU/Linux in the same way in which it did on Microsoft Windows. He had intended to file a bugzilla report, but due to the outage (see this same FWN#138 "Bugzilla Overhauled") was merely posting to @fedora-devel. The basic point made in what MarkG chose to frame as an RFC was that he expected the middle mouse button when clicked to allow him to scroll the page but that "[w]hen you press it on linux in firefox you get ... nothing[.]" He suggested that a simple change of thefirefox-fedora-default-prefs.js to pref("general.autoScroll", true); by the Fedora maintainer would achieve this goal and noted that currently it is possible for a user to achieve the same end by navigating to the URI about: config and filtering general.autoScroll and changing its boolean to "true". MarkG also noted in support of his argument that "Ubuntu" had made such a change. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00053.html A correction was made[2] by IgnacioVazquezAbrams--Ignacio Vazquez-Abrams to the effect that clicking the middle mouse button brought one to the "URL stored in the clipboard." He also pointed out that the environment in which the middle-click was made was important and that Firefox was doing the correct thing by following the Windows' environment preference of autoscrolling and the *nix environment preference of pasting from the clipboard. At this point the thread should probably have stopped but instead descended into a morass of personal preferences and insults. Nevertheless there were a couple of points worth noting. [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00054.html NaheemZaffar--Naheem Zaffar thought[3] that while pasting was well and good it was not so nice to have the pasted URL automatically replacing the current page. Rui Miguel Silva Seabra provided[4] a fix for this with about:config -> browser.tabs.opentabfor.middleClick. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00108.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00109.html A type of closure to the thread was obtained when Todd Zullinger posted[5] that a likely result of making such changes would merely be to "get the opposite RFC from anyone who is used to the *nix behavior and wonders why Firefox is scrolling instead of pasting the clipboard contents as we'd expect. :)" and he speculated that "Ubuntu" had diverged from upstream. [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00058.html =Bugzilla Overhauled= As commented in several threads this week (e.g. this FWN#138 "Firefox Mouse Woes") Bugzilla was down for maintenance. This was due to upgrades of the OS on the servers and a move from the venerable bugzilla-2.18 to bugzilla-3.2. The original announcement[1] was posted on several lists and detailed the planned outage and the changes to bugzilla which included user-interface enhancements, AJAX optimizations for searching and displaying bugs and an XMLRPC API. [1] http://www.mail-archive.com/fedora-announce-list@redhat.com/msg01372.html The announcement and the reminder[2] that this would all happen on 2nd August requested that those using the API pointed their scripts to the test server https://partner-bugzilla.redhat.com to ensure that the new system was indeed backwards compatible. [2] http://www.mail-archive.com/fedora-devel-announce@redhat.com/msg00194.html A brief thread on @fedora-devel was started[3] when Gilboa Davara noticed that attempting to file a bug resulted in the JavaScript hanging and Firefox offering to retry or stop the script. This experience was confirmed by several other posters who noted that hitting "Continue" and waiting seemed to work. PaulFrields--Paul Frields speculated[4] that it was the population of the component list which was slow. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00175.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00178.html =Feature Proposal: Provers= An interesting proposal to include a bunch of tools for automated theorem proving was mooted[1] by David A. Wheeler. The bundle of tools, listed in David's post, would ease the task of increasing the reliability of software in some specific cases and are often used (see paper by David[2]) to perform assurance for safety and security on other programs. David argued that these tools, which are variously Formal Methods Tools, Key Provers and Solvers should be considered as a "Feature" for Fedora 10 as they needed some integration and had not previously been packaged for Fedora. Some of the methods enabled by these tools are being used by the OpenSuSE distribution to speed up dependency solving of RPM packages. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00263.html [2] http://www.dwheeler.com/essays/high-assurance-Floss.html Jarod Wilson was uncertain[3] that the case for calling "just a collection of new packages" a Feature had been made. After further support from Patrice Dumas, Casey Dahlin and Paul Frields an explanation was posted[4] by Toshio Kuratomi that the determination is made in part by the presentation of why and how some packages are useful to a hypothetical end user: "just saying Fedora has a collection of provers isn't a Feature. But saying, in Fedora 10 we've made an effort to include foo, bar, baz important provers for Target Audience so they can find all the tools they need to do X Type of Work. Similarly, `We've done work so that foo and bar can import and export the same file format', or other work to show how we're making the user experience better would make a stronger case for a feature." Similarly Jarod provided[5] links to the Fedora Project wiki to support his case that not enough had been done to explain why the programs were a cohesive collection dedicated to a particular end use case although he admitted "I suppose perhaps this falls under "noteworthy enough to call out in the release notes", depending on who you ask. I'm still not sold yet." [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00265.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00298.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00301.html RahulSundaram wanted[6] a classification of packaging difficulty added as he had examined several on the package wishlist and found them "a large amount of pain to package." Vasile Gaburici suggested calling the packages "Theorem Proving Tools" in order to broaden the category a bit. He also suggested[7] including gap and twelf. Suggestions to include other packages were forthcoming from Miles Savin for Agda2 and Richard Jones for CIL, a C-parser and static-analysis tool. Richard included a link[8] to a nice analysis of libvirt performed with CIL. Andrew Overholt noted[9] that sat4j was already packaged in Fedora. [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00264.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00267.html [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00288.html [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00293.html =rpmgrok Announced= Red Hat's David Malcolm announced[1] rpmgrok, a web-based tool to allow users to track program information across an entire distribution, yet without having a complete install tree. The tracked information includes all symbols in binaries, RPM manifests, shared objects, meta-information about rpms and more. He pointed interested parties to his test prototype[2]. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00221.html [2] http://publictest7.fedoraproject.org/rpmgrok All this information is obtained by analyzing the actually built rpms and storing the results in a database. David requested that anyone interested in coding, sysadmin and UI design get involved and provided a link to the git repository and the information that it was built upon TurboGears and SQLAlchemy. Enthusiasm for the "Errors and warnings from rpmlint" was expressed[3] by Axel Thimm because he could imagine that someone that's say an expert on "invalid-desktopfile" issues could now dig into this much easier. Very nice!", but upon further feedback[4] from Mamoru Tasaka and Ville Skyttä it appeared that some work needed to be done to ensure that rpmlint was being used correctly. In any case this looks like a very promising and useful tool. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00228.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00242.html ==Infrastructure== This section contains the discussion happening on the fedora-infrastructure-list http://fedoraproject.org/wiki/Infrastructure Contributing Writer: HuzaifaSidhpurwala =static F10 Alpha relnotes page= Karsten Wade writes for fedora-infrastructure-list [1] Karsten proposed that we turn [2] static. People should also be able to edit that page. Perhaps as part of making it static we can tell people to post changes to the talk page, then we'll do irregular updates of the static content? [1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms... [2] https://fedoraproject.org/wiki/Releases/10/Alpha/ReleaseNotes =Photo gallery= Nicu Buculei writes for fedora-infrastructure-list [3] The Art team decided to start collecting photos which can be used as desktop wallpapers, make a best-of-breed selection and create one or more packages. The easiest way is to add all of them to the wiki. However Nicu proposed that we use a better solution, either a gallery plug-in for trac or a stand alone gallery or something like that. [3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms... =FAS authentication for Red Hat bugzilla= Rahul Sundaram writes for fedora-infrastructure-list [4] Rahul asked if configuring FAS Auth for Red Hat bugzilla was possible. At which Mike replies saying that it was not our call, and Red Hat will need to decide that. [4] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms... =RFC: script to run sqlalchemy migrations on the db= Toshio Kuratomi writes for fedora-infrastructure-list [5] FAS started using the python-migrate package to update its db. This is a good thing for third-parties that want to install their own FAS server as it lets us ship the database changes in a way that is easy for those users to apply to their own production databases. However, it doesn't work very well in our particular environment because we're a bit more strict about our permissions than the migrate authors envision. In order to perform migrations, you need to have a user that can modify the schema for the db. This is either the owner of the db or the superuser. In our setup, we create the db with the superuser and then run our web apps with another user. This prevents the normal web app from modifying the db schema. Toshio proposed a couple of solutions to this. [5] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms... ==Artwork== In this section, we cover the Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: Nicu Buculei =Web banner for FUDCon Brno= [PaulFrields] asked[1] on the Fedora Art list for a web banner "Red Hat Europe has agreed to put up a banner for Fedora, advertising the upcoming FUDCon Brno", request which is followed by two proposals, one [2] by NicuBuculei and another [3] from VaraPrasadPepakayala. One design is choosen and its quicly featured on the Red Hat Europe website[4]. [1] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00084.html [2] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00114.html [3] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00151.html [4] http://www.europe.redhat.com/ =Photographic wallpapers= An interesting question and offer[1] from BobPeterson about using photos as background images: "I like the 'blue' themes that Fedora has traditionally chosen, but I was wondering if Fedora could have a photo for its main background screen. As an amateur photographer, I have several 'scenery' photos I've taken that may be suitable, and I'm willing to donate". [1] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00103.html As the general opinion converged over the idea that probably abstract images work better as a default but a collection of additional photographic wallpapers is useful, MartinSourada stepped-up[2] and created a preliminary gallery inside the wiki[3], which was quickly populated with a few images[4] by [[NicuBuculei] "to break the ice, start the ball rolling, provide an incentive and show how to use the gallery tag". [2] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00118.html [3] https://fedoraproject.org/wiki/Artwork/Wallpaper_Extras [4] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00138.html The discussion covered licensing aspects[5], good practices about preparing wallpaper images[6] and also spawned a follow-up on the infrastructure list[7] about the best way of implementing the gallery, with a Gallery2 instance, proposed by JeffreyOllie looking as the most promising option. [5] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00159.html [6] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00165.html [7] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms... [8] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms... =First Nodoka 0.8 screenshots= MartinSourada posted[1] a status update of the development for the Nodoka theme, including a number of screenshots illustrating its current state. [1] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00144.html [2] https://fedorahosted.org/nodoka/wiki/Screenshots#a0.7.80.0git9a0f383 Security Advisories In this section, we cover Security Advisories from fedora-package-announce. https://www.redhat.com/mailman/listinfo/fedora-package-announce Contributing Writer: David Nalley ==Fedora 9 Security Advisories== * thunderbird-2.0.0.16-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00... * libxslt-1.1.24-2.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00... * pdns-2.9.21.1-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00... * httpd-2.2.9-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00... Fedora 8 Security Advisories * poppler-0.6.2-2.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00... * httpd-2.2.9-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00... * libxslt-1.1.24-2.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00... * pdns-2.9.21.1-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00... * thunderbird-2.0.0.16-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00... ==Virtualization== In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies. Contributing Writer: Dale Bewley =Enterprise Management Tools List= This section contains the discussion happening on the et-mgmt-tools list Virt-manager Support for Storage Pool API Cole Robinson posted[1] three patches (not to mention screen shots) which add support for the storage pool API to the virt-manager GUI. [1] https://www.redhat.com/archives/et-mgmt-tools/2008-August/msg00066.html =Virt-mem Tools 0.2.8 Released= Richard W.M. Jones announced[1] the release of virt-mem 0.2.8. Virt-mem provides a set of dom0 or host tools which leverage libvirt to facilitate the inspection of domU or guest kernel information. Commands include 'virt-uname', 'virt-ps', and 'virt-dmesg' for example. This latest version has been reworked to have direct access to basically any kernel structure. This will allow a more rapid fullfillment of outstanding feature requests such as memory usage information, network interface listings, etc. [1] https://www.redhat.com/archives/et-mgmt-tools/2008-August/msg00033.html Fedora Xen List This section contains the discussion happening on the fedora-xen list. =Installing Fedora 9 Guest on Centos 5 Fails= Kenneth Tanzer had trouble[1] installing a Fedora 9 paravirtualized guest on a CentOs 5 host. Eventually the install hung on installing openoffice.org-writer2latex. David Hláčik reported[2] a kernel panic during the same scenario. He stated it was due to the Fedora 9 kernel-xen having newer features which the CentOs dom0 did not support. However, Mark McLoughlin said[3] RHEL5/CentOS Xen is expected to be able to run pv_ops kernels, and a bug should be filed if this isn't the case. [1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00011.html [2] https://www.redhat.com/archives/fedora-xen/2008-August/msg00013.html [3] https://www.redhat.com/archives/fedora-xen/2008-August/msg00018.html =Libvirt List= This section contains the discussion happening on the libvir-list. sVirt project to Integrate SELinux and Linux-based Virtualization James Morris announced[1] the formation of the sVirt project with the goal to be able to apply distinct security labels to individual VM instances and their resources, so that they can be isolated from each other via MAC policy. [1] https://www.redhat.com/archives/libvir-list/2008-August/msg00255.html Libvirt and Persistent Iptables Rules Daniel Berrange responded[1] to a networking problem by pointing out that libvirt will automatically setup the correct iptables rules to allow outbound NAT based connectivity for guest VMs and that restarting the iptables service will erase these rules. [1] https://www.redhat.com/archives/libvir-list/2008-July/msg00508.html David Lutterkort hoped[2] this was a temporary situation due to the confusion it can cause. Mark McLoughlin confirmed[3] there is a RFE (bug 227011) to enable libvirt to persistently register iptables rules, but was depressed that a resulting fix would be Fedora specific. [2] https://www.redhat.com/archives/libvir-list/2008-August/msg00098.html [3] https://www.redhat.com/archives/libvir-list/2008-August/msg00193.html =Network XML Configuration Options= To support a complex virtual network with 3 DMZs, Didier Ayllon asked[1] if it is possible to specify options such as default gateway, static routes, DNS options in the network config. Daniel Berrange pointed[2] out libvirt networking "is designed specifically to only provide 3 types of networking, an isolated network, a NAT based network, and a routed network" and the format is documented on libvirt.org. [1] https://www.redhat.com/archives/libvir-list/2008-August/msg00062.html [2] https://www.redhat.com/archives/libvir-list/2008-August/msg00078.html oVirt Devel List This section contains the discussion happening on the ovirt-devel list. =Lighter-weight "Developer" Setup= Chris Lalancette proposed[1] some steps toward lowering the barrier to entry for oVirt users with limited hardware resources and growing the community. The proposal would remove the "fake managed nodes" concept and allow oVirt to manage the hardware on the host machine and enable installation of guests along side the oVirt appliance, and eventually remove the appliance completely and facilitate installing from a set of RPMs. [1] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00080.html =Beginnings of an oVirt API= David Lutterkort posted[1] an RFC for implementing an oVirt API and 5 patches to begin the discussion. The patches covered handling hosts, storage pools, and hardware pools. The fifth patch provided sample[2] code for using the API. The exercise revealed some changes that could be made to the server code to to accomodate such an API. [1] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00045.html [2] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00050.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIoA9FzHDc8tpb2uURAn7LAJ9zJK8ARnWYLasyeaxJlO+L2T0EpACdHzJS X91bgm0rNNWSCZJeDqP32bE= =mNa6 -----END PGP SIGNATURE-----

15 years, 3 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

announce August 2008