gmane.linux.redhat.fedora.core.announce

Fedora Board IRC meeting 1800 UTC 2008-09-09

Paul W. Frields — 2008-09-06T13:33:30

FESCo Issue tracking

Kevin Fenzi — 2008-09-05T21:11:59

Fedora 8 and 9 updates status

Jesse Keating — 2008-09-05T16:09:10

Echo Monthly News, Issue 1

Martin Sourada — 2008-09-01T12:17:22

Fedora Weekly News 141

Huzaifa Sidhpurwala — 2008-09-01T10:28:16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fedora Weekly News Issue 141 ============================== Welcome to Fedora Weekly News Issue 141 for the week ending August 30, 2008. http://fedoraproject.org/wiki/FWN/Issue141 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 Unity releases Fedora 8 Re-Spin Ben Williams announced[0] that the Fedora Unity team has released a new re-spin 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 Sunday August 24th, 2008. Go to http://spins.fedoraunity.org/spins to get the bits!" [0] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00014.html = 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 Education The Fedora Education Spin is progressing[0], having been "approved by all necessary bodies - Spin SIG, Board, Rel-Eng", reported Sebastian Dziallas. The spin has its own feature page. "Hopefully, we'll be able to have a preview of the spin ready in the next weeks", added Sebastian. [0] http://sdziallas.joyeurs.com/blog/2008/08/status-report-on-fedora-educat.html Greg DeKoenigsberg reminded potential OLPC contributors[1] to surf over to the contributors' program on the OLPC wiki in order to request their own XO for development. Soon, Greg "will be sitting in on the weekly call that decides how these laptops are disbursed". [1] http://gregdek.livejournal.com/34240.html Tech Tidbits Michael DeHaan, holder of the coveted "best blogger on Planet Fedora" title, as determined each week by your correspondent, has penned a treatise[8] concerning the future of systems management software. "Cobbler and Func are very fun, I think they are quite useful, but I'm wondering what are next on the horizon for server management tech, not in terms of a evolutionary improvement but how things can be legitimately improved by fundamental, indeed 'paradigm-shifty' means." Click the link below to read the entire post. [8] http://www.michaeldehaan.net/?p=702 James Antill has written[9] a tutorial on the Python yum API, which is incredibly useful if you have ever wanted to do stuff with yum, but don't know where to start and are afraid to ask Seth. [9] http://illiterat.livejournal.com/6254.html Events David Nalley shared some details about the upcoming Fedora Ambassadors Day for North America[2]. The event will coincide with Ohio Linux Fest in October. David said, "If you are a Fedora Ambassador, or want to be one, you should try and attend." [2] http://www.nalley.sc/david/?p=81 [[ChristophWickert|Christoph Wickert] attended FrOSCon 2008, along with several other other Ambassadors, and shared his event report[3]. "Just like on Linuxtag the Fedora booth was located close to the entrance, so we had quite a lot of visitors. Unfortunately the booth was a little small and we had lot of stuff to show: Two OLPCs, an eeepc, two ALIX Machines and a couple of Laptops. Everything was running Fedora, the Laptops were running Gnome and Xfce, mine also LXDE." Check out the link below for pictures, and the full report. [3] http://www.christoph-wickert.de/blog/2008/08/26/back-from-froscon/ Max Spevack reminded[4] everyone about the upcoming FUDCon Brno. "We currently have 110 people registered for the event," and the list of sessions and hackfests is on the Fedora wiki. Hans de Goede will be attending FUDCon Brno. He wrote an update[5] about webcam support in Fedora, which will be worked on at FUDCon, and also blogged[6] about the session he will give on how to become a Fedora package maintainer. [4] http://spevack.livejournal.com/62369.html [5] http://hansdegoede.livejournal.com/5576.html [6] http://hansdegoede.livejournal.com/5304.html Fedora List Fedora Board member Chris Tyler wrote[7] about the plans for changing the scope and ownership of fedora-list. Chris says, it is "one of the first lists that most Fedora users join, and therefore quite important to the community. However, it's a high-volume list (and is sometimes perceived to have a high noise level), so many veterans of the Fedora community aren't subscribed... Paul Frields and I have taken on the ownership of the list, and we'd welcome one or two experienced members of the community to join us." [7] http://blog.chris.tylers.info/index.php?/archives/134-The-Scope-and-Ownership-of-fedora-list.html = Developments = In this section the people, personalities and debates on the < at >fedora-devel mailing list are summarized. Contributing Writer: Oisin Feeley Approaches to a Minimal Fedora Luya Tshimbalanga alerted[1] the list to a post on FedoraForum.org in which a user "stevea" had produced a 67MB "minimalFedora" system. Jeff Spaleta worried[2] that the bare-bones system was unable to receive updates and that this was something which "we as a project might not officially want to endorse." One way out of that suggested by Jef was that interested parties could produce a derived distribution which pushed out entire updated images. Recent changes in the trademark guidelines make such a move easier. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01304.html [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01305.html A parallel to the minimal OS appliance image used in the oVirt project was discerned[3] by Daniel Berrange. Daniel reported their 'oVirt managed node' as being less than 64MB and built entirely from the Fedora 9 repositories. Later Daniel posted[4] that the similarities ended with the desire for a small image. The oVirt goal was to use only Fedora as upstream whereas stevea's approach had been to substitute coreutils with busybox. Daniel acknowledged "[...] finding the bits which aren't needed is fun in itself & somewhat of a moving target. So wherever possible we've been filing BZ to get some RPMs split up into finer grained sub-RPMs" and included a link to his project's kickstart %post stanza. Richard Jones suggested[5] that KDE's filelight was useful for finding bloated files and Vasile Gaburici added[6] that there was a GNOME equivalent called baobab. Vasile also included[7] a script which he uses to "keep track of bloatware". [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01307.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01319.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01373.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01374.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01376.html A follow-up post from Daniel concluded[8] that the only bits of upstream Fedora actually used in stevea's approach were the kernel and busybox as even glibc and initscripts had been ditched. Daniel wondered "So not really much trace of Fedora left at all. Not sure why you'd go to the trouble of doing the initial anaconda install at that point - might as well just 'rpm *no-deps' install kernel + busybox RPMs into a chroot & add the custom init script." [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01320.html Doubt on the advantages of stripping down Fedora to make it run on embedded targets was cast[9] by Patrice Kadionik when he argued that using the Fedora kernel with all its patches and modules was too bloated. Instead he preferred to use the vanilla kernel with busybox with the result that "[...] you have a Linux kernel (about 1MB) with its root [filesystem] (about 1-2 MB) adapted completely to the target platform." Alan Cox replied[10] that the ability to receive updates and benefit from the maintained and tested code was desirable if there were enough extra space. [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01353.html [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01357.html W. Michael Petullo added a link[11] to his "FedoraNano" project which has the goal of reducing redundancies, identifying probable cases for sub-packaging and documenting a method to install a small Fedora onto solid state drives. [11] http://www.flyn.org/fedoranano/fedoranano.html Using PackageKit Without NetworkManager-Controlled Interfaces A question from Martin Langhoff asked[1]: "[i]s there anything preventing PK from connecting to the network over non-[NetworkManager]-controlled network interfaces?" This question appeared to be predicated on the assumption that PackageKit had a dependency on NetworkManager. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01209.html Jeremy Katz clarified[2] that PackageKit depended on NetworkManager-glib and not on NetworkManager. He added that this was because PackageKit attempted to determine the status of the network connection prior to checking for updates. Dan Williams confirmed[3] that this was the case and expanded on the explanation: "If talking to NM fails, the app should either (a) assume a connection, or (b) could be more intelligent by asking SIOCGIFCONF/netlink for interfaces, and if at least one interface is IFF_UP | IFF_RUNNING and has an IP address, then try." Using NetworkManager in this way allows PackageKit to be restricted to sensible choices about the type of networks over which it is acceptable to receive updates. [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01210.html [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01213.html A further point raised by Martin was that there were a surprising number of dependencies and Dan pointed[4] to bugzilla entry#351101[5] while noting that "[PackageKit] should only depend on NetworkManager-glib, which itself should not pull in NetworkManager in the future." That bug specifically affects multilib systems, that is x86-64 systems with i386 packages on them, and prevents the simple removal of the older version of NetworkManager-glib and replacement with a re-factored one. This will be fixed for Fedora 10 using the installer anaconda. [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01214.html [5] https://bugzilla.redhat.com/show.bug.cgi?id=351101 In a separate thread Martin asked[6] what debugging facilities were available for network scripts beyond using bash -x. He detailed his "hack du jour" by which /etc/udev/rules.d/60-net.rules invokes net.hotplug.debugger which in turn uses bash -x net.hotplug with STDIN and STDOUT redirected to a logfile. It appeared from the lack of further suggestions that this is a good strategy. He also provided[7] a note which explained that he was upgrading the "School Server" spin to Fedora 9 from Fedora 7. [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01263.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01207.html Git-1.6.0 Commands to be Moved Out of PATH A response by Todd Zullinger to a "cvsextras" commit[1] of changes to git questioned[2] whether setting gitexecdir=%{_bindir} was a justified deviation from upstream intent. According to Todd "[..] we've effectively negated upstream's intent to present less binaries in the users path". Currently there are 137 git-commands in the /usr/bin directory. Todd suggested that it was better that individual users added the output of $(git *exec-path) to their PATH environment variable. As a precaution against breaking scripts upon update to git-1.6.0 Todd suggested that this addition to PATH should be made by the package. [1] http://www.redhat.com/archives/fedora-extras-commits/2008-August/msg05593.html [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01330.html The package maintainer responsible for the change, James Bowes replied[3] that he had recently attempted to do as Todd suggested and that had resulted in complaints. He was worried that although Todd's change made sense there had been no due diligence conducted to see what would break if the git-* commands were moved in such a way. Josh Boyer replied[4] that the original complaint had been about "yank[ing] out commands [...] from a stable release [Fedora 9]". Todd Zullinger discounted such complaints and dreamt[5] that "[...] a warning could be hand delivered by a beautiful naked person of whatever gender the user prefers and many would still scream when the change finally landed. :)" He suggested that in order to achieve predictability and consistency across distributions it was best to follow upstream and use the update to 1.6.0 as a flag day. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01361.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01363.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01389.html In response to queries as to whether there was a need to update Fedora 9 also Josh Boyer replied[6] that a security bug was fixed by git-1.6.0 but that he thought that this might have also been fixed by "a later release of 1.5.6.x." [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01390.html Resurrecting Multi-Key Signatures in RPM Spurred on by the disquiet caused by the recent signing of Red Hat packages (but not as far as is known any Fedora packages)[1] it was suggested[2] by Bojan Smojver that multiple GPG signatures of RPM packages would be a good idea. Distributing the signing could include using alternate buildsystems "[...] with no public access [...] to verify package checks before signing[.]" [1] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01136.html Andrew Bartlett thought that the checksum part would be a problem because a build often includes hosts, build times and other specifics and Chris Adams added[3] that even individual files within a package had such information embedded. Bojan decided to find out how many packages were so constrained and Seth Vidal suggested[4] a useful rpm command rpm - -qp *dump pkg.rpm to list all available information about each package. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01140.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01146.html Seth was dubious about the general idea and upon being pressed doubted the security gain and noted the cost incurred on users trying to verify that a package was signed correctly. Bojan expanded[5] upon the idea that for a "[...] multi-key, multi-build system, an attacker would need to get his hands on a lot of private key passwords, break multiple independent build systems [...] It is similar to what a reporter does to confirm a story. One source, not so reliable. Two sources, more reliable. Many sources, most likely reliable." Stephen Smoogen described[6] this a logical fallacy and argued that due to the number of packages all signing would need to be automated and thus probably each of the multiple sources would "[...] get their information from the same top level source." [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01198.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01205.html A useful post by Nils Philippsen laid out[7] four practical objections. Prime among these was that there were additional pieces of data, besides those mentioned above, embedded in a specific build even though the source package may have the same tag. The possibility of making the build system vulnerable to a DoS attack was also mentioned. A sub-thread on German banking practices and the value of multiple credentials developed[8] as did one[9] on the problems of determinism in producing identical binaries. [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01156.html [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01275.html [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01329.html Tom Lane was also among those that expressed[10] a general skepticism that the increased burden of such a scheme was realistic: "Most of us [packagers] are overworked already. We aren't going to jump through any hoops for third-party signatories." Bojan argued[11] that if the system were automated then it probably would be vulnerable but suggested that it would be better if a community effort to absorb the extra non-automatic work would be a solution in line with "open source" practices. Reluctantly he concluded "[n]ever mind, it was just an idea. Probably not even a good one. Back to the drawing board... ;-)" [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01141.html [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01215.html Intrusion Recovery Slow and Steady A politely phrased request[1] was made on 25-08-2008 by Mike Chambers for information about when normal service would resume in the Fedora Project after the disruptions[1a]. Enigmatically Dominik 'Rathann' Mierzejewski observed[2] that there had been "some speculation on fedora-advisory-board that might explain the information blackout, so please don't jump to conclusions until you really know what happened" This led Chris Adams to observe that the list archives appeared to be offline and to restate the request for information "[...] in the absence of information, rumors and speculation fill the gap (which is not good)." [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01102.html [1a] https://fedoraproject.org/wiki/FWN/Issue140#Mysterious_Fedora_Compromise [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01122.html Several days later (on 28-08-2008) a similar request was made[3] by Alan Dunn. He wondered whether bodhi was pushing updates out again, and Josh Boyer responded[4] that planning and implementation of "how to revoke the current gpg key used to sign RPMs" were in progress. Jesse Keating cautioned[5] that the migration to a new key would be slow "I'm currently re-signing all of the 8 and 9 content with these new keys so that we can make them available along with the new updates with the new key for these product lines. This is going to take some time due to the nature of how our signing works." [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01308.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01309.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01310.html A proposal mooted[6] on < at >rel-eng by Warren Togami and others provided some insight into at least the part of the plans that involve the problem of how to distribute a new package signing key. [6] http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html "nodata" asked[7] whether the new plans included a means to push out critical security updates even while there was a general outage. The thinking behind this seems to be that an attacker could decide to knock out Fedora infrastructure in order to gain some time to exploit a known vulnerability even if a simple fix existed. Jesse Keating replied[8] confidently that in such a scenario the Fedora Project would do "whatever it takes [...] to get a critical update onto a public webserver should the need arise" and cautioned against wasting time trying to plan for every possible scenario. Toshio Kuratomi added[9] that although it might be possible to speed up recovery "[...] unfortunately if the infrastructure problem is bad enough, there's no way we can push package X out until the problem is at least partially resolved." [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01313.html [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01314.html [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01316.html On 27-08-2008 Paul Johnson noted that it was possible to "compose and build" and asked "when will updates via yum become available for rawhide?" Jeremy Katz responded[10] that "[a]t the moment, the compose is falling over for new reasons unrelated to the infrastructure changes. Hopefully we'll see a rawhide make its way out to the masses real soon now." [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01249.html Later Mike Chambers and Ola Thoresen reported[11] that updating from Fedora 9 to Rawhide seemed to be working. Several Rawhide Reports also appeared[12]. [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01350.html [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01339.html = Infrastructure = This section contains the discussion happening on the fedora-infrastructure-list http://fedoraproject.org/wiki/Infrastructure Contributing Writer: HuzaifaSidhpurwala Some noteworty praise Paul W. Frields writes for fedora-infrastructure-list [1] Paul forwarded a mail [2] send by Tim Burke, who is the Director of Linux Development inside Red Hat, praising the efforts of fedorans who rose to the occasion to bring things back on track after the recent incidents in Fedora infrastructure. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00149.html [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01023.html Maintaining a partial cvs workarea Axel Thimm writes for fedora-infrastructure-list [3] Axel described how he was keeping a partial check-out of packages, ie the ones which he was maintaining. Now he would like to be able to cvs up and have all updates flow in, but if he does do so cvs will want to get all other thousand packages in. He is currently using a for loop with pushd/popd, but this process is extremely slow. Axel asked if there was a better way of doing this? [3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00156.html rawhide, /mnt/koji and /pub/fedora Jesse Keating writes for fedora-infrastructure-list [4] Jesse created a user "masher" to have the ability to write to /mnt/koji/mash/ but not any of the other koji space. This is useful to prevent too much damage from a horribly wrong rawhide compose. To make things easier in the rawhide compose configs, they decided to run the cron/scripts as the masher user. This is also good because it means things run unprivileged. However he ran into a snag. They have another user, 'ftpsync' that has write access to /pub/fedora/. Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls. The masher user does not possess the capability of doing this. [4] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00174.html New Key Repo Locations Warren Togami writes for fedora-infrastructure-list [5] Warren proposed the latest draft of New Key repo locations. Jesse Keating points out that the deep levels are necessary because mirrors exclude releases by directory name like "9/" [5] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00198.html = Artwork = In this section, we cover the Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: Nicu Buculei The Echo icon theme and Fedora 10 NicuBuculei asked[1] on < at >fedora-art about the plans to use the new Echo icon set as a default on Fedora 10: "considering the feature freeze, the Beta release and as Echo is not a feature proposed for F10, is correct the assumption that we won't have Echo as a default for F10, staying with Mist [at least] one more release cycle?" [1] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00328.html In reply LuyaTshimbalanga pointed[2] out that it is still possible, due to a slip in the release cycle: "Shall we try to make it as Fedora 10 feature. Thanks to, in some extend, the incident, feature freeze has been moved on September 9th." [2] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00329.html MartinSourada shared[3] his experience "It seems like artwork things are preferred to be decided by the Art Team rather than Fesco. I have a feeling it might be same for Echo." and proposed that this decision should be made together by the Art and Desktop teams "In this case I personally think Echo should be put on evaluation by Art Team and Desktop Team. If both agree it's ready for default we can roll it in ;-)" while NicuBuculei stressed[4] the importance of having Art features listed "from a marketing POV, if we list it as a "feature" it will be picked by more news source and help building the excitement around the new release." [3] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00337.html [4] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00343.html Automating the One Canvas workflow In the last FWN[1] issue we covered 'One Canvas workflow', an innovative way to create icons, this week it continued to be a topic on < at >fedora-art and MartinSourada introduced[2][3] a script that makes the work easier. "[It] greatly simplifies life for Echo artist, since all they need is to make the Source SVG, run the script on it, select which branches they'd like to push it to and write commit message(s) - i.e. it automates most of the process". He also wrote a blog post[4] about this and created a screencast[5] illustrating the process. [1] http://fedoraproject.org/wiki/FWN/Issue140 [2] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00327.html [3] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00368.html [4] http://mso-chronicles.blogspot.com/2008/08/echo-nodoka-one-canvas-ruby-and-new.html [5] http://mso.fedorapeople.org/screencasts/echo-add-icon-screencast.ogg = 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 As there have been disruptions to the infrastructure of the Fedora Project this week there are no Security Advisories to report. Please see the Announcements and Development sections for more information. Fedora 9 Security Advisories None Fedora 8 Security Advisories None = Virtualization = In this section, we cover discussion on the < at >et-mgmnt-tools-list, < at >fedora-xen-list, < at >libvirt-list and < at >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 Fedora Xen List This section contains the discussion happening on the fedora-xen list. virt-what Script Detects Running in a Virtual Machine Richard W.M. Jones announced[1] version 1.0 of | virt-what which is a simple shell script that detects if you are running inside a virtual machine, and prints some "facts" about that virtual machine. [1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00039.html Xen 3.3.0 Released Pasi Kärkkäinen forwarded[1] from xen-devel an announcement of Xen 3.3.0. Pasi also followed up[2] on a thread from July where Daniel P. Berrange said about Fedora 10, "Even though we don't have any Dom0 I'll update it to 3.3.0 for the xen RPM and hypervisor. This will at least let people build their own legacy Xen kernel from upstream's 2.6.18 xen kernel" [1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00038.html [2] https://www.redhat.com/archives/fedora-xen/2008-August/msg00029.html Testing LiveCD Distros as DomU Guests jean-Noël Chardron posted[1] a howto for testing live cd images by booting them in a DomU with virt-install. [1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00024.html Libvirt List This section contains the discussion happening on the libvir-list. Daniel P. Berrange posted[1] a todo list for libvirt which was the product of a brainstorming session at Red Hat. Daniel offered this list as a good starting point for those wishing to assist in the development of libvirt. [1] https://www.redhat.com/archives/libvir-list/2008-August/msg00718.html Live Migration Sanity Checks Chris Lalancette described[1] a feature that oVirt would like to see. The feature would be a set of sanity checks a caller could make to determine if live migration of a given virtual machine would be likely to succeed. [1] https://www.redhat.com/archives/libvir-list/2008-August/msg00757.html sVirt: XML Representation of Security Labels James Morris continued[1] work on the sVirt project by investigating how and when to label the resources accessed by domains and proposed an XML representation of these labels. [1] https://www.redhat.com/archives/libvir-list/2008-August/msg00740.html LXC: Making the Private Root Filesystem More Secure After committing the private root filesystem code for LXC Daniel P. Berrange noted[1] that cgroups supports device ACLs which could defend against 'mknod' escapes into the host OS devices. [1] https://www.redhat.com/archives/libvir-list/2008-August/msg00734.html Exposing Unique Hypervisor Features Nguyen Anh Quynh asked[1] how libvirt can expose the unique features of a given hypervisor such as the monitor interface of Qemu. Daniel P. Berrange responded[2] by stating the policy for adding new APIs to libvirt is that the conceptual representation has to be applicable to multiple hypervisors and unique concepts may be exposed if they can be represented in a way which would also make sense for other hypervisors in the future. This goal is also stated in the libvirt architecture document. [1] https://www.redhat.com/archives/libvir-list/2008-August/msg00693.html [2] https://www.redhat.com/archives/libvir-list/2008-August/msg00701.html oVirt Devel List This section contains the discussion happening on the ovirt-devel list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIu8O/zHDc8tpb2uURArkzAKCZJprWqqb9prB84eXpqiSqvbrDDACgh50M 3H2qF1AMyoMPdcf1comVOwU= =wk+7 -----END PGP SIGNATURE-----

Fedora Unity releases Fedora 8 Re-Spin

ben — 2008-08-25T01:02:20

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 ,2 ]: * #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 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/

Fedora Weekly News, Issue 140

Huzaifa Sidhpurwala — 2008-08-25T10:38:06

-----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.html 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.html 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.html Email bounces Seth Vidal explained[3] that "a number of addresses < at >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.html =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/msg00266.html 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/msg00271.html [2] https://fedoraproject.org/wiki/Ambassadors/NA#Fedora_Ambassador_Polo_Shirts_for_North_America 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/msg00289.html =Developments= In this section the people, personalities and debates on the < at >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_Infrastructure [2] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html [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.html 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 < at >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 < at >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.html [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.html 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 < at >fedora-list. Jef Spaleta wondered[17] if there might be a better way of getting information out than relying on everyone to subscribe to < at >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 < at >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_Infrastructure [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/. 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/msg00108.html [2] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.html 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/msg00122.html =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.png [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-----

Infrastructure report, 2008-08-22 UTC 1200

Paul W. Frields — 2008-08-22T12:00:02

Infrastructure status, 2008-08-19 UTC 0200

Paul W. Frields — 2008-08-19T02:07:45

Fedora Weekly News, Issue 139

Pascal Calarco — 2008-08-18T13:08:58

* 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.html == 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.html == 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.html == 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.html = 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-beyond/ [2] http://marilyn.frields.org:8080/~paul/wordpress/?p=1129 = Developments = In this section the people, personalities and debates on the < at >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.html [2] http://lwn.net/Articles/294188/ Further announcements or explanations were not forthcoming for days, except for a post to < at >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/msg00109.html [4] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00009.html 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_Shift_From_Ubuntu [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/msg00252.html == Fedora 8 Security Advisories == none

Infrastructure status, 2008-08-16 UTC 1530

Paul W. Frields — 2008-08-16T15:30:03

Important infrastructure announcement

Paul W. Frields — 2008-08-14T23:15:13

ACL Changes and new package group policy

Casey Dahlin — 2008-08-13T21:16:48

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

Board public IRC meeting

Paul W. Frields — 2008-08-12T15:01:37

Fedora Weekly News #138

Huzaifa Sidhpurwala — 2008-08-11T10:07:02

-----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 < at >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 < at >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< at >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< at >redhat.com/msg00194.html A brief thread on < at >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/msg00013.html [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/msg00028.html =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/msg00039.html =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/msg00059.html ==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/msg00028.html [8] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00029.html =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/msg00125.html * libxslt-1.1.24-2.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00118.html * pdns-2.9.21.1-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00109.html * httpd-2.2.9-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00055.html Fedora 8 Security Advisories * poppler-0.6.2-2.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00161.html * httpd-2.2.9-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00153.html * libxslt-1.1.24-2.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00092.html * pdns-2.9.21.1-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00140.html * thunderbird-2.0.0.16-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00144.html ==Virtualization== In this section, we cover discussion on the < at >et-mgmnt-tools-list, < at >fedora-xen-list, < at >libvirt-list and < at >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-----

Fedora Board IRC meeting 1800 UTC 2008-08-12

Paul W. Frields — 2008-08-06T11:17:59

Updated Fedora Privacy Policy

Tom "spot" Callaway — 2008-08-05T19:15:47

This is a notice that the official Fedora Privacy Policy has been updated. A brief notice can also be found on the main website (http://fedoraproject.org). Previously, Fedora was using the generic Red Hat Privacy Policy, which did not make sense for a number of reasons. Fedora now has its own Privacy Policy at: http://fedoraproject.org/wiki/Legal/PrivacyPolicy I would encourage everyone to read the new Privacy Policy. This policy went through a public review process on the fedora-advisory-board mailing list, and was approved by the Fedora Board on August 5th, 2008. This new policy defines that more of your "Personal Information" is public by default. This will make things much easier for the daily workings of Fedora, however, if you wish for this "Publicly Available Personal Information" to be kept private, it is possible to do so in the Fedora Account System. It also enables us to be able to generate useful statistics about Fedora's ongoing progress. Last, but not least, it got rid of a lot of useless wording and confusing text about transactions and Red Hat services which are not applicable to Fedora. If you have any questions about the updated Fedora Privacy Policy, feel free to email me. Thanks, Tom "spot" Callaway, Fedora Legal

Announcing Fedora 10 Alpha!

Jesse Keating — 2008-08-05T14:38:49