From dkl at redhat.com Sun Aug 3 01:08:33 2008 From: dkl at redhat.com (Dave Lawrence) Date: Sat, 02 Aug 2008 21:08:33 -0400 Subject: bugzilla.redhat.com Web UI, Database, XMLRPC Planned Outage | August 2nd, 2008 - 9:00 AM EST - 11:00 PM EST Message-ID: <1217725713.15447.8.camel@localhost.localdomain> Update: The bugzilla.redhat.com upgrade is now complete. Note: A database dump is currently running to allow us to update the slave database for replication. So the system may seem sluggish for a few more hours. Please send any feedback/comments to bugzilla-owner at redhat.com. Please file any bugs you find in Bugzilla against the Bugzilla product, version 3.2. Thanks Engineering Operations. ===================================== O U T A G E R E Q U E S T F O R M ===================================== Severity: Severity Two (High) Scheduled Date: August 2nd, 2008 Scheduled Time: 9:00 AM EST - 11:00 PM EST Estimated Time Required: 10 hours Performed By: Red Hat Engineering Operations People/Groups Impacted: Users of bugzilla.redhat.com and any services that rely on bugzilla.redhat.com Site/Services Affected: bugzilla.redhat.com Web UI, Database, XMLRPC Impact: bugzilla.redhat.com will be unavailable during the posted time on August 2nd, 2008. Description: On August 2nd, bugzilla.redhat.com will go down for an update to the latest upstream code base. During this time the web servers will be reinstalled with the latest OS updates as well as the latest Bugzilla code. Also the database servers will undergo a data migration to be made compatible with the latest Bugzilla code. The web UI, database, and all XMLRPC services will be unavailable during the migration. Services that rely on bugzilla.redhat.com may not function properly during this time so please let your users know about the outage as well. Also please take time to point your services/scripts at our test server https://partner-bugzilla.redhat.com to make sure that they will still work with the new system once it goes live. Care has been taken to make the new system backwards compatible as much as possible with the old XMLRPC API but still confirm that they work properly. If you encounter any problems, please contact bugzilla-owner redhat com or file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=3.2 Signoff: kbaker redhat com -- David Lawrence, RHCE dkl at redhat.com ------------------------------------ Red Hat, Inc. Web: www.redhat.com 1801 Varsity Drive Raleigh, NC 27606 From huzaifas at redhat.com Mon Aug 4 11:16:04 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Mon, 04 Aug 2008 16:46:04 +0530 Subject: Fedora Weekly News Issue 137 Message-ID: <4896E4F4.5080302@redhat.com> Fedora Weekly News Issue 137 ============================= Welcome to Fedora Weekly News Issue 137 for the week ending August 2, 2008. http://fedoraproject.org/wiki/FWN/Issue137 Fedora Weekly News keeps you updated with the latest issues, events and activities in the Fedora community. We are pleased to present a new beat on Virtualization issues and developments brought to you by beat writer Dale Bewley. In Developments we report on "How Maintainers Can Help Reduce XULRunner Breakage". In Announcements we reveal the Fedora 10 codename. In Artwork we examine "The Blue Color of Fedora". In Security Advisories, another new beat authored by David Nalley we run through the week's important updates. We are also saddened to announce the departure of Thomas Chung from the editorial chair, but heartened to be working as a new editorial team consisting of Pascal Calarco, Oisin Feeley and Huzaifa Sidhpurwala. 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 == 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 10 (Cambridge) = Josh Boyer informed us[0] that "Cambridge" was the winning name in the Fedora 10 naming election. Jeremy Katz wrote[1] on his blog that "Cambridge" was the original Red Hat Linux 10 codename, which was the release that eventually became Fedora Core 1. [0] https://www.redhat.com/archives/fedora-announce-list/2008-July/msg00014.html [1] http://katzj.livejournal.com/434986.html == Ambassadors == In this section, we cover Fedora Ambassadors Project. http://fedoraproject.org/wiki/Ambassadors Contributing Writer: JeffreyTadlock = Help Wanted: LinuxWorld San Francisco = Karsten Wade put out a help wanted call [1] for the Fedora booth at LinuxWorld San Francisco. If you are in the area and wnat to help out, please check the mailing list post [1] for details or the wiki page [2]. [1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00412.html [2] https://fedoraproject.org/wiki/Events/LinuxWorld_SF_2008 = Event Report: Lindependence 2008 = Karsten Wade reported [1] on Lindependence 2008 on the ambassador mailing list. THis event was in Felton, California and was an attempt to get an entire town to switch to FOSS alternatives. [1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00381.html = Event Report: Palmetto Open Source Software Conference = David Nalley posted [1] his event report covering the Palmetto Open Source Software Conference. This was a first year event and included a talk by Greg DeKoenigsberg and included an imprompt Fedora booth. [1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00375.html == Developments == In this section the people, personalities and debates on the @fedora-devel mailing list are summarized. Contributing Writer: Oisin Feeley = How Maintainers Can Help Reduce XULRunner Breakage = The recent breakage of many packages which depend on xulrunner (see FWN#136 "XULRunner Security Update Breakage Stimulates Bodhi Discussion"[1]) was addressed[2] in a post by Will Woods. Will reported that a QA meeting involving Christopher Aillon (caillon), as Firefox/XULRunner maintainer, had investigated the problem and produced an explanation and some recommendations for other package maintainers. As Christopher was unavailable for a week Will was relaying the information in the hope that some fixes could be made in his absence. [1] http://fedoraproject.org/wiki/FWN/LatestIssue#XULRunner.Security.Update.Breakage.Stimulates.Bodhi.Discussion [2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01682.html The reason that some xulrunner-dependent packages were affected and others not was that xulrunner provides both a stable API gecko-devel and an unstable API gecko-devel-unstable. Will noted that BuildRequires of xulrunner-devel or xulrunner-devel-unstable should no longer be used and instead that gecko equivalents should replace them. Packages using the stable API were unaffected by the update of xulrunner. Will stated that "[t]he unstable API could change at any time, so if your app is using the unstable API it must be rebuilt *every time* xulrunner is updated." It was recommended that packages that used the stable API should use the following in their specfiles: Requires: gecko-libs >= 1.9 BuildRequires: gecko-devel >= 1.9 and that those using the unstable API should use: %define gecko_ver 1.9.0.1 Requires: gecko-libs = %{gecko_ver} BuildRequires: gecko-devel-unstable = %{gecko_ver} Lastly an important request was made of package maintainers: "if your package uses the -unstable API, please send caillon redhat com a note, and *please* consider adding him to the ACL (or opening it entirely). He keeps tabs on all packages requiring the unstable API so they can all be rebuilt for each security update." Braden McDaniel wondered[3] why the same headers, but with different pathnames, were provided by xulrunner-devel-unstable and xulrunner-devel and Ville-PekkaVainio had[4] the same question. [3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01684.html In response to the suggested BuildRequires Douglas Warner requested[5] that a Provides: gecko-libs-api = 1.9 be added to xulrunner so that dependent packages would break if xulrunner were bumped to a new version which was not compatible: "For example, I can't do: Requires: gecko-libs < 2.0 Because I'm not guaranteed that the next version will *be* 2.0 (it might be 1.10, for example)." Rex Dieter independently came[6] to the same conclusion. Denis Leroy begged[7] that xulrunner would use "libtool-style soname versions like all other libraries in Fedora? So we don't need to add the version numbers in the spec file in the first place." Denis thought that xulrunner would fail a standard Fedora package review. [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01686.html [edit] NEVR Again Another report detailing broken upgrade paths was posted[1] by Jesse Keating's script (see FWN#136 "Broken Upgrade Paths Due to NEVR"[2]). This time it reported those packages which failed the path "f8-final -> dist-f8-updates -> dist-f8-updates-testing -> dist-f9-updates -> dist-f9-updates-testing -> dist-f10" and seventy-eight packages were listed. Also included as per last week's discussion was an ordering of the list per-builder as opposed to per-owner. Jesse requested[3] feedback from recipients of the automated email warnings if problems are encountered. [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01525.html [2] http://fedoraproject.org/wiki/FWN/LatestIssue#Broken.Upgrade.Paths.Due.to.NEVR [3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01526.html Stephen Warren was concerned[4] that the upgrade path did not include the GA release of dist-f9: "Shouldn't dist-f9-final (or whatever the correct name is) be inserted in this path list between dist-f8-updates-testing and dist-f9- updates?" This led to an interesting exchange with Kevin Kofler who argued[5] that the converse should be expected and it was desirable that updates to Fedora 8 would have higher EVRs than the packages which were released for "dist-f9". Stephen argued[6] that it would make it easier to backport fixes if bumping of the release number rather than the version number were preferred and suggested changing what he understood to be Fedora's policies. KevinKofler disagreed[7] both with Stephen's description of current Fedora practices and also with his desire to reduce version bumps. He listed several situations in which these bumps would be useful and suggested that it was such version upgrades which uniquely distinguished Fedora from Debian "stable" or Red Hat EL. [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01527.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01529.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01539.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01553.html The possibility that simultaneous updates would be released to all branches was discussed[8] by Kevin Kofler and Jesse Keating. Although Jesse thought this was a corner case and that it was best to let the maintainer decide Kevin was motivated[9] to write a patch as it was in his experience a common problem. Kevin thought that if Jesse wanted to avoid spamming maintainers with bogus reports then his patch would remove about thirty-nine percent of the volume. Jesse was grateful and excused[10] himself from looking at the patch for a week due to the pressure of releasing the alpha of Fedora 10. [8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01572.html [9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01574.html [10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01595.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01685.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01728.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01708.html = Slimming Down Java by Sub-Packaging AOT = A request to separate out the AOT[1] parts of Java packages into sub-packages was made[2] by Caolan McNamara. He estimated that it would be possible to remove circa 45 Mb (in /usr/lib/gcj) as OpenJDK tended to be installed anyway due to the web plugin. [1] AOT stands for Ahead-Of-Time. This refers to the static compilation of the program to produce native code which runs without the potential run-time performance hit imposed by JIT. JIT stands for Just-In-Time and refers to dynamic compilation of each method of a Java program immediately before execution. Although there are techniques to speed up JIT, by identifying "hot" frequently called methods and caching them[2a], in general it is believed to be sub-optimal for GUI-based programs. [2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01763.html [2a] http://en.wikipedia.org/wiki/HotSpot Andrew Haley and Andrew Overholt expressed[3] skepticism that users would realize that they needed the gcj AOT-compiled code in order to get good performance. Andrew Overholt stated "one of the reasons we didn't do this to begin with was because RPM has no notion of Suggests or Recommends like dpkg does. Debian went this route, but I've seen reports of people not realizing they needed to install the associated -gcj package." [3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01769.html The advantages of maintaining both AOT and JIT compilation were argued[4] by Colin Walters. Among the reasons listed by Colin for keeping a JIT were: "many apps will continue to load code at runtime from sources that are not Fedora. Think unpackaged Eclipse plugins for just a start" and that "[a] JIT also has a lot more interesting information than a normal AOT model. Hotspot does a lot of cool things there." Colin suggested that "profile driven optimizations",based on work done in 2001 by JanHubicka (SuSE), Richard Henderson (Red Hat) and AndreasJaeger (SuSE), might be a way to improve the performance of JITted programs. On the other hand he recognized that AOT compilation was useful "because having Hotspot re-profile and recompile the Eclipse core on everyone's computer is a bit of a waste." Colin followed up[5] with a putative infrastructure plan involving modifying Koji to create a new repository of optimized versions of select applications and a YUM plugin which feeds HotSpot profile data from individuals back to a central server which in turn is used to further optimize the compilations. Jeff Spaleta wanted[6] to know if this new repository would be disabled by default. Toshio Kuratomi was concerned[7] that Koji should maintain its ability to create a precisely audited build. [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01774.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01775.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01792.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01795.html = Rawhide Network Breakage Due to Wireless Drivers = A puzzled Richard Jones asked[1] if anyone else had experienced bizarre networking failures apparently due to DNS lookup failures for web browsers but not for command line tools. Several confirmations were posted and Dan Williams warned[2] that "all mac80211-based drivers (b43, b43-legacy, iwl3945, iwl4965, ath5k, rt2x00)" were broken due to upstream patching of multiqueue functionality. [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01788.html [2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01801.html Ralf Etzinger asked[3] if failure to associate with an Access Point was one of those expected pieces of "random weirdness." In response to a follow-up question from Michael Solberg about a failure to associate using kernel-2.6.25.10-47.fc8 Dan added[4] that only Rawhide kernels should be affected. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00000.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00008.html [edit] Possible Slippage of Fedora 10 Alpha? A brief note from Jesse Keating on Friday requested[1] an IRC meeting with spin owners, QA, Kernel and other concerned parties to discuss the problem that "split media"[2] was not working currently. As the Alpha release is scheduled[3] for August 5th it seems as though there is little time to solve this problem. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00005.html [2] The ability to break a set of RPM packages into media images to be used by anaconda during installation is a difficult one. Currently it is handled by the pungi module https://hosted.fedoraproject.org/pungi/wiki/PungiDocs/PungiDocs [3] http://fedoraproject.org/wiki/Releases/10/Schedule In an aside Jesse referred to the problem that the "Alphas" are currently hidden away from the general community and that he would like to address this at a subsequent ReleaseEngineering meeting. == Infrastructure == This section contains the discussion happening on the fedora-infrastructure-list http://fedoraproject.org/wiki/Infrastructure Contributing Writer: HuzaifaSidhpurwala = Email aliases and new cvs requests = Toshio Kuratomi writes for fedora-infrastructure-list [1] Last week Seth implemented email aliases for the people who should be notified of changes to packages. Toshio used this new functionality to have getnotifylist, which looks up who to notify on cvs commits, stop querying the pkgdb directly (a slow operation with multiple points where it could fail) and instead just construct the alias from the packagename. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00104.html = YUM security issues...= Toshio Kuratomi writes for fedora-infrastructure-list [2] This is a re-post from Josh Bressers. Justin asked if the ability for mirror admins to select a subnet where they'll serve all of the traffic has been removed? There is a particular concern about this issue in the short term. There is a paper about this also [3] [2] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00082.html [3] http://www.cs.arizona.edu/people/justin/packagemanagersecurity/ = cvsextras renamed to packager = Toshio Kuratomi writes for fedora-infrastructure-list [4] cvsextras has been renamed to packager. Any scripts that depends on querying the "cvsextras" group will now need to query "packager". [4] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00128.html = Server Monitoring - A replacement for Nagios? = Nigel Jones writes for fedora-infrastructure-list [5] While this was intended to be a primary discussion point for the Infrastructure meeting there was a little bit of discussion first in #fedora-admin, and then in #fedora-meeting regarding Zabbix, a tool like Nagios that Nigel begun to setup for testing this week. [5] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00143.html == Artwork == In this section, we cover the Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: Nicu Buculei = New Posters Needed for Fedora = Paul Frields asked[1] on @fedora-art-list about a new series of posters: "'Infinity / Freedom / Voice' has been a powerful message and an excellent way to characterize the themes that went into the Fedora logo. The logo has become a completely identifiable brand for us, and the original 'triptych' posters for these themes have allowed our brand to grow throughout the community. Now, it's time for us to build a revitalized message around the more concrete themes that characterize the entire Fedora Project as a whole." [1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00235.html Mair?n Duffy came up[2] with a concept fitting one of the Fedora 10 theme proposals: "I'm wondering if this could be tied into the F10 artwork theme.... I've been sketching up some steampunky doodles lately. Maybe I'll do some along these lines. Here are some steampunk-inspired ideas" (following with a list of ideas[2]) and after receiving positive feedback even with a graphic sketch [3]. [2] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00291.html [3] https://www.redhat.com/archives/fedora-art-list/2008-August/msg00002.html = A T-shirt Design for the Upcoming FUDCon in Brno = Max Spevack asked[1] on @fedora-art-list for a T-shirt design for the Brno FUDCon: "Since you guys did such an awesome job on the FUDCon Boston shirts, I was wondering if you'd be willing to make a few mock-ups of what a FUDCon Brno shirt would look like. I like the idea of trying to have a bit of design consistency for each year's FUDCon shirts... so maybe we could keep the front the same (switching the name of course) and doing something 'similar' on the back?" [1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00259.html The request was quickly followed[2] by a design by Nicu Buculei using, as requested, the same template as the recent FUDCon in Boston, a design which is generally liked. The discuss touched[3] on a hunt for usable Brno photos and a number of pieces of technical advice[4] from Mair?n Duffy about vectorizing photos. [2] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00270.html [3] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00271.html [4] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00305.html = The Blue Color of Fedora = Paul Frields started an interesting debate[1] about the dominant color used in Fedora graphics: "Does the Artwork team think, overall, that using a blue palette for our desktop theme (background) helps Fedora with its identity and branding? Do you want to continue that for Fedora 10?" [1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00326.html A large chorus of contributors to the Art Team expressed their support for using blue, one of the most convincing arguments came from Max Spevack[2]:"Blue = Fedora. Mix in some other stuff as appropriate, but I believe that Blue is now 'our' color. We shouldn't give that up. Ubuntu has brown, OpenSuse has green. Red Hat has red. We have blue. Personally, I like that we maintain that general blue-ish feel. Play with the shades if you like, mix in some spice and variety if you like, but I think Fedora should always be identifiable with the color blue." [2] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00338.html Of course there are different opinions, like the one voiced[3] by David Nielsen: "As a user I would love to see us break free of the blue prison, it looks dated and should be put down with all manners of mercy possible. I think it hurts us to stick with the blue theme and unlike other competing distros not work towards a unified look over several cycles." [3] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00333.html == Security Week == In this section, we highlight the security stories from the week in Fedora. Contributing Writer: JoshBressers Last week wasn't very exciting as far as security issues go. I have nothing of interest to note. Next week should be quite busy though. Black Hat[1] and DEFCON[2] are going on in Las Vegas. Things are expected to be very busy[3]. [1] http://www.blackhat.com/ [2] https://www.defcon.org/ [3] http://www.networkworld.com/news/2008/073108-black-hat.html?hpg1 = 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 = * filezilla-3.1.0.1-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00039.html * pdns-recursor-3.1.7-2.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01353.html * phpMyAdmin-2.11.8.1-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01316.html * asterisk-1.6.0-0.19.beta9.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01298.html * trac-0.10.5-1.fc9 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01270.html = Fedora 8 Security Advisories = * filezilla-3.1.0.1-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00013.html * drupal-5.9-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-August/msg00016.html * phpMyAdmin-2.11.8.1-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01239.html * trac-0.10.5-1.fc8 - https://www.redhat.com/archives/fedora-package-announce/2008-July/msg01261.html == Virtualization == In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies. Contributing Writer: Dale Bewley = Enterprise Management Tools List = This section contains the discussion happening on the et-mgmt-tools list = Virt-install Remote Guest Creation = Cole Robinson took[1] a stab at implementing remote guest creation in virt-install. The main unresolved issue was storage. How to detect it and how to allow the user to specify it. Michael DeHaan was interested[2] in teaching koan to install on remote hosts and also focused on the question of storage specification. [1] https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00277.html [2] https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00278.html The discussion of storage specification dovetails with the concurrent discussion of Storage Pool Discovery on @libvir-list (covered below) and a previous thread[3] on libvirt storage xml. [3] https://www.redhat.com/archives/et-mgmt-tools/2008-July/msg00235.html [edit] Fedora Xen List This section contains the discussion happening on the fedora-xen list. = kernel-xen is Dead = Mark McLoughlin wrote[1] to say the kernel-xen package is dead. That is to say the kernel package can now support x86 and x86_64 domU guests and kernel-xen will be dropped from Rawhide. Hiding between those lines is the fact that there is currently no Dom0 kernel in Fedora 9 or Rawhide. Without such a Dom0 kernel a domU must be booted via a paravirt_ops kernel or with the KVM-based xenner. [1] https://www.redhat.com/archives/fedora-xen/2008-July/msg00044.html The conversation then turned to the matter of migrating away from Xen and support for systems without hardware virtualization. Paul Wouters asked[2] if there was a howto for migration to KVM. It seemed there is not, but all are encouraged to provide one. [2] https://www.redhat.com/archives/fedora-xen/2008-July/msg00046.html Alain Williams realized that Fedora 9 has no Dom0 support after installing it. When he asked why Mark McLoughlin pointed[3] out the problems with kernel-xen being based on a much older kernel than kernel creating a time sink, so the decision was made to re-base to the upstream kernel which supports paravirt_ops. This decision was first announced[4] back in Nov 2007 by Daniel Berrange. Mark McLoughlin also stated[3] that Dom0 support at Fedora 10 launch looks unlikely. Fortunately we have more positive news on that front below. [3] https://www.redhat.com/archives/fedora-xen/2008-July/msg00048.html [4] https://www.redhat.com/archives/fedora-xen/2007-November/msg00106.html Dale Bewley bemoaned[5] the fact that he has no budget to upgrade to HVM capable hardware and will have to stick on Fedora 8 until Fedora 10 has Dom0 support. Stephen Smoogen pointed[6] out that RHEL5 and CentOS5 are options for Dom0 on non-HVM hardware. Daniel Berrange expressed[7] some empathy and the desire for such support, but reiterated it isn't viable until Dom0 is ported to pv_ops. [5] https://www.redhat.com/archives/fedora-xen/2008-July/msg00049.html [6] https://www.redhat.com/archives/fedora-xen/2008-July/msg00052.html [7] https://www.redhat.com/archives/fedora-xen/2008-July/msg00053.html = State of Xen in Upstream Linux = Pasi K?rkk?inen thoughtfully forwarded[1] a long detailed xen kernel status message which was sent to the @xen-devel-list by Jeremy Fitzhardinge. Jeremy pointed out that mainline kernel is at 2.6.27-rc1 and his current patch stack is pretty much empty after being merged into linux-2.6.git. [1] https://www.redhat.com/archives/fedora-xen/2008-July/msg00058.html Jeremy stated that Fedora 9's kernel-xen package was based on the mainline kernel even though it's been a separate package. Now that kernel-xen has been dropped from rawhide there will be only one kernel package in Fedora 10. Jeremy said his focus in the next kernel development window will be obvious missing dom0 support with the hope it will be merged into 2.6.28. That work will likely take place in a xen.git on Xen.org. Jeremy then provided his long TODO list with a request for help fullfilling it. In addition he asked what's missing. Paul Wouters followed up[2] on Jeremy's question of "What's missing?" with the answer of a lack of entropy in the guests. Daniel Berrange mentioned Rusty Russell's VirtIO-RNG patch from this thread. Thorsten Leemhuis provided a link to this LWN article on the subject of entropy sources and showed that this patch is in 2.6.26. [2] https://www.redhat.com/archives/fedora-xen/2008-July/msg00059.html [3] https://www.redhat.com/archives/fedora-xen/2008-August/msg00000.html = Creating Multiple Xen Bridges = Andy Burns asked[1] for a clean way to utilize the two NICs in a Dom0 server as multiple bridges. Kanwar Sandhu recommended[2] editing xend-config.sxp to utilize a very small custom network-bridge-wrapper script also provided in the post. Another option pointed[3] out on the list was to short-circuit xend-config.sxp and configure all networking by hand in /etc/sysconfig/network-scripts. [1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00004.html [2] https://www.redhat.com/archives/fedora-xen/2008-August/msg00005.html [3] https://www.redhat.com/archives/fedora-xen/2008-August/msg00008.html = Libvirt List = This section contains the discussion happening on the libvir-list. = PATCH: Storage Pool Discovery = David Lively refered[1] to a post[2] on "Storage Management APIs" by Daniel Berrange when he posted a patch to implement virConnectDiscoverStoragePools. As the API continues to be solidified, this patch implements discovery for only logical and netfs storage pools. Daniel Berrange pointed[3] to the Storage Management page on libvirt.org as an appropriate place to document the XML used for srcSpec. [1] https://www.redhat.com/archives/libvir-list/2008-July/msg00502.html [2] http://www.redhat.com/archives/libvir-list/2008-February/msg00107.html [3] https://www.redhat.com/archives/libvir-list/2008-August/msg00013.html = PATCH: Fix Setting of Bridge Forward-delay = Christoph H?ger described[1] a problem which caused a bridge to not pass traffic for a number of seconds after activation. Just a few minutes later Daniel Berrange posted[2] a fix for a bug which caused libvirt to ignore the forwarding delay when it was set to 0. The workaround in the meantime is to set fd=1. [1] https://www.redhat.com/archives/libvir-list/2008-August/msg00017.html [2] https://www.redhat.com/archives/libvir-list/2008-August/msg00020.html Daniel Veillard plus-oned[3] that patch and expressed that with the last release having been on June 25th, it may be time for a new release. Daniel Berrange mentioned[4] that the Xen & QEMU refactoring needs more testing, and the LXC and OpenVZ drivers need porting to the new XML routines. Richard W.M. Jones wanted[5] to get virsh edit in. The last word[6] was to delay another week. [3] https://www.redhat.com/archives/libvir-list/2008-August/msg00025.html [4] https://www.redhat.com/archives/libvir-list/2008-August/msg00030.html [5] https://www.redhat.com/archives/libvir-list/2008-August/msg00034.html [6] https://www.redhat.com/archives/libvir-list/2008-August/msg00036.html = oVirt Devel List = This section contains the discussion happening on the ovirt-devel list. From jkeating at redhat.com Tue Aug 5 14:38:49 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 05 Aug 2008 10:38:49 -0400 Subject: Announcing Fedora 10 Alpha! Message-ID: <1217947129.19808.47.camel@localhost.localdomain> In an ongoing effort to prevent premature kitten death, the Fedora Project is ecstatic to present the availability of Fedora 10 (Cambridge) Alpha. Test now, make it better now, keep Cambridge on schedule, and protect the kittens in the future. The Alpha release provides the first opportunity for the wider community to become involved with the testing of rawhide: * Alpha represents a sanitized snapshot of rawhide, Fedora's development branch, which undergoes rapid changes before becoming the next major release. * The Alpha should boot on the majority of systems, and provides: * A look at what new features are to be included in the next release * A way to provide feedback and bug reports to help ensure that the next release is as good as possible Fedora 10 features Some highlights of Fedora 10 Alpha: * Many improvements, bugfixes, and enhancements from upstream * New graphical boot environment * Wireless connection sharing * Audio improvements to remove glitches * Security audit tool * Improved webcam support * Better IR remote control support * RPM 4.6 * OCaml * Haskell For more information: http://fedoraproject.org/wiki/Releases/10/Alpha/ReleaseNotes What to test Test status is being tracked here: https://fedoraproject.org/wiki/QA/TestResults/Fedora10Install/Alpha Check out this page before reporting problems, including looking through the bug trackers as linked on that page. For a more detailed list of installation tests: http://fedoraproject.org/wiki/QA/TestPlans/Fedora10Install Get the Alpha The Alpha release is available both through the mirroring system and via bittorrent. For direct http access to a local mirror: http://download.fedoraproject.org/pub/fedora/linux/releases/test/10-Alpha/ For a list of mirrors carrying the content and the various protocols they support: http://mirrors.fedoraproject.org/publiclist/Fedora/10-Alpha/ For bittorrent: http://torrent.fedoraproject.org/ Join Fedora To find ways you can help and participate, visit: http://join.fedoraproject.org/ -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Tue Aug 5 19:15:47 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 05 Aug 2008 15:15:47 -0400 Subject: Updated Fedora Privacy Policy Message-ID: <1217963747.3415.165.camel@localhost.localdomain> 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 From stickster at gmail.com Wed Aug 6 11:17:59 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 06 Aug 2008 07:17:59 -0400 Subject: Fedora Board IRC meeting 1800 UTC 2008-08-12 Message-ID: <1218021479.3749.18.camel@victoria> ?The Board is holding its monthly public meeting on Tuesday, 12 August 2008, at 1800 UTC on IRC Freenode. The public is invited to do the following: * Join #fedora-board-meeting to see the Board's conversation. This channel is read-only for non-Board members. * Join #fedora-board-public to discuss topics and post questions. This channel is read/write for everyone. The moderator will direct questions from the #fedora-board-public channel to the Board members at #fedora-board-meeting. This shouldlimit confusion and make sure our logs are useful to everyone. ?The Board has set aside one meeting of each month as a public "town hall" style meeting. We are *still* hoping to hold an audio-based meeting at some point in the near future using some of the new resources being developed by the Infrastructure team. More news on this will be forthcoming. We look forward to seeing you at the meeting. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From huzaifas at redhat.com Mon Aug 11 10:07:02 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Mon, 11 Aug 2008 15:37:02 +0530 Subject: Fedora Weekly News #138 Message-ID: <48A00F46.3000702@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fedora Weekly News Issue 138 ============================ Welcome to Fedora Weekly News Issue 138 for the week ending August 11, 2008. http://fedoraproject.org/wiki/FWN/Issue138 Fedora Weekly News keeps you updated with the latest issues, events and activities in the Fedora community. If you are interested in contributing to Fedora Weekly News, please see our 'join' page. Being a Fedora Weekly News beat writer gives you a chance to work on one of our community's most important sources of news. Ideas for new beats are always welcome -- let us know how you'd like to contribute. We are still looking for a beat writer to summarize the Fedora Events and Meetings that happened during each week. http://fedoraproject.org/wiki/NewsProject/Join == Developments == In this section the people, personalities and debates on the @fedora-devel mailing list are summarized. Contributing Writer: Oisin Feeley =Solving the Unsynchronized Release of Package Dependencies= A problem often experienced by users of "add-on" packages[1] is that dependency resolution will fail during a simple yum update when the official Fedora repositories release an update to the base packages on which these add-ons depend. ThorstenLeemhuis explained[2] that as add-on packages have a strict dependency on the base packages for which they were built and updates are not available at exactly the same time on all mirrors there is no ideal point in time for the add-on to be released. Thorsten's RFC was careful to point out that the problem did not only affect kmods, but also plugins for audacious, xine and k3b and that the resulting dependency resolution failures occurred both when the add-on was visible to yum before the base package and vice versa. The two possible solutions envisioned by Thorsten included either yum being modified "to be taught to do a second look at the right place to find what's needed" or the third-party repositories to include the updated base packages along with the updated add-on. Thorsten feared that this latter option of "shipping non-free kernel modules and the GPLed kernels in one repo might [make] some people yell license violation." [1] Such packages are hosted by "third-party" repositories, which are run independently of the Fedora Project. The packages, while highly useful for many Fedora users, are deemed to be legally non-distributable due to the laws of the U.S.A. [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html A report of daily failures of this type occurring for Rawhide without any complicating third-party repository was posted[3] by John Ellson. He gave two examples from his current machine. The first was a missing dependency error: $ yum update phonon* Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by package phonon-backend-gstreamer-4.2.0-1.fc10.x86.64 (installed) and the second was a file conflict error: $ yum update digikam* Transaction Check Error: file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of digikam-0.10.0-0.1.beta2.fc10.x86.64 conflicts with file from package oxygen-icon-theme-4.1.0-1.fc10.noarch [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00044.html John wished that yum would skip updating all rpms which produce conflicts with currently installed rpms whether or not they are third-party or otherwise, especially as neither of these issues had been flagged in the appropriately dated "Rawhide report". A good deal of the remainder of thread was devoted to replying to this post instead of to Thorsten's RFC. The first response came[4] from MichaelSchwendt and made the point that the first error was probably due to an incorrect "Obsoletes" tag in the !code?phonon-backend-gst!/code? that is supposed to replace phonon-backend-gstreamer. The script which checks for broken dependencies in Rawhide cannot detect this as the phonon-backend-gstreamer is not visible to it. Michael addressed the second error with the point that conflicts are entirely different from dependency issues and are not checked. RexDieter, as package maintainer, quickly fixed both of the problems and in doing so demonstrated that users filing bug reports can be an effective part of the current process. Thorsten also emphasized[5] that the two errors posted by JohnEllson were entirely different from each other and that the conflict was a bug best dealt with by user reports. He further argued that it was impossible for the Rawhide dependency checker script to examine the contents of users' hard disks. All that the script can do is examine the current contents of Rawhide and as the phonon-backend-gstreamer was long gone it could not test a theoretical update from it. Michael Schwendt later added[6] that although his own "repoclosure" script developed for the old "Extras" repository had been able to take account of "obsolete binary [packages] from the previous compose [...] because in Extras we've had up to two pkg releases in the repo[sitory ...] the Rawhide report is like a fresh install of only the latest [package] releases, and one can only hope that there are enough testers who find and report the additional update/upgrade problems." Michael claimed[7] that as the FedoraProject policy on file conflicts was "half-hearted" he was uninterested in shouldering the burden of running the script himself. He also noted that Florian La Roche had a script for determining conflicts between files and symlinks. [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00045.html [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00046.html [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00097.html [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00048.html During this discussion JohnEllson was unimpressed[8] with the theoretical reasons as to why he was seeing these problems and requested that even if it were not possible to do such checks on the server "[j]ust have yum on the client recover gracefully from these and skip over them." [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00047.html Similarly David Timms wondered[9] if the original problem stated in the RFC could be solved by using the yum option --skip-broken if it were made to select only those packages which were: available, non-conflicting, non-dependency-breaking and actually downloadable.Thorsten restated[10] his belief that this was effectively hiding the problem instead of fixing it and would result in users being unaware that important updates were blocked solely due to a manually installed problem RPM. Instead he suggested setting a window of time during which updates with broken dependencies would be ignored and then finally reported as errors. Seth Vidal corrected[11] the impression that "skip broken" was a plugin to yum (it is now a core option) and while agreeing that "a tool to detect all these issues is worth discussing, not sure how we catch all possible conflicts, though" seemed to confuse Thorsten's window of time with checking the actual package creation filestamp. JesseKeating also appeared[12] to fall prey to this confusion and like Seth pointed out the problem of queued packages sitting in repositories before being released. To clear this confusion up Thorsten posted[13] a more detailed explanation which emphasized that the times being examined were relative to the client-side's first encountering of the problem and made no reference to the build-date or publication date of the package itself. The advantage of Thorsten's seventy-two hour window scheme is that it gives packagers a grace period in which to correct the problem and at the end of that the same situation prevails as now, namely that the update will fail and users will notice and report the errors. [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00049.html [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00099.html [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00150.html [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00153.html [13] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00154.html =Firefox Mouse Woes= MarkG reported[1] that Firefox did not respond to the scroll wheel on GNU/Linux in the same way in which it did on Microsoft Windows. He had intended to file a bugzilla report, but due to the outage (see this same FWN#138 "Bugzilla Overhauled") was merely posting to @fedora-devel. The basic point made in what MarkG chose to frame as an RFC was that he expected the middle mouse button when clicked to allow him to scroll the page but that "[w]hen you press it on linux in firefox you get ... nothing[.]" He suggested that a simple change of thefirefox-fedora-default-prefs.js to pref("general.autoScroll", true); by the Fedora maintainer would achieve this goal and noted that currently it is possible for a user to achieve the same end by navigating to the URI about: config and filtering general.autoScroll and changing its boolean to "true". MarkG also noted in support of his argument that "Ubuntu" had made such a change. [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00053.html A correction was made[2] by IgnacioVazquezAbrams--Ignacio Vazquez-Abrams to the effect that clicking the middle mouse button brought one to the "URL stored in the clipboard." He also pointed out that the environment in which the middle-click was made was important and that Firefox was doing the correct thing by following the Windows' environment preference of autoscrolling and the *nix environment preference of pasting from the clipboard. At this point the thread should probably have stopped but instead descended into a morass of personal preferences and insults. Nevertheless there were a couple of points worth noting. [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00054.html NaheemZaffar--Naheem Zaffar thought[3] that while pasting was well and good it was not so nice to have the pasted URL automatically replacing the current page. Rui Miguel Silva Seabra provided[4] a fix for this with about:config -> browser.tabs.opentabfor.middleClick. [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00108.html [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00109.html A type of closure to the thread was obtained when Todd Zullinger posted[5] that a likely result of making such changes would merely be to "get the opposite RFC from anyone who is used to the *nix behavior and wonders why Firefox is scrolling instead of pasting the clipboard contents as we'd expect. :)" and he speculated that "Ubuntu" had diverged from upstream. [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00058.html =Bugzilla Overhauled= As commented in several threads this week (e.g. this FWN#138 "Firefox Mouse Woes") Bugzilla was down for maintenance. This was due to upgrades of the OS on the servers and a move from the venerable bugzilla-2.18 to bugzilla-3.2. The original announcement[1] was posted on several lists and detailed the planned outage and the changes to bugzilla which included user-interface enhancements, AJAX optimizations for searching and displaying bugs and an XMLRPC API. [1] http://www.mail-archive.com/fedora-announce-list 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 @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 @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies. Contributing Writer: Dale Bewley =Enterprise Management Tools List= This section contains the discussion happening on the et-mgmt-tools list Virt-manager Support for Storage Pool API Cole Robinson posted[1] three patches (not to mention screen shots) which add support for the storage pool API to the virt-manager GUI. [1] https://www.redhat.com/archives/et-mgmt-tools/2008-August/msg00066.html =Virt-mem Tools 0.2.8 Released= Richard W.M. Jones announced[1] the release of virt-mem 0.2.8. Virt-mem provides a set of dom0 or host tools which leverage libvirt to facilitate the inspection of domU or guest kernel information. Commands include 'virt-uname', 'virt-ps', and 'virt-dmesg' for example. This latest version has been reworked to have direct access to basically any kernel structure. This will allow a more rapid fullfillment of outstanding feature requests such as memory usage information, network interface listings, etc. [1] https://www.redhat.com/archives/et-mgmt-tools/2008-August/msg00033.html Fedora Xen List This section contains the discussion happening on the fedora-xen list. =Installing Fedora 9 Guest on Centos 5 Fails= Kenneth Tanzer had trouble[1] installing a Fedora 9 paravirtualized guest on a CentOs 5 host. Eventually the install hung on installing openoffice.org-writer2latex. David Hl??ik reported[2] a kernel panic during the same scenario. He stated it was due to the Fedora 9 kernel-xen having newer features which the CentOs dom0 did not support. However, Mark McLoughlin said[3] RHEL5/CentOS Xen is expected to be able to run pv_ops kernels, and a bug should be filed if this isn't the case. [1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00011.html [2] https://www.redhat.com/archives/fedora-xen/2008-August/msg00013.html [3] https://www.redhat.com/archives/fedora-xen/2008-August/msg00018.html =Libvirt List= This section contains the discussion happening on the libvir-list. sVirt project to Integrate SELinux and Linux-based Virtualization James Morris announced[1] the formation of the sVirt project with the goal to be able to apply distinct security labels to individual VM instances and their resources, so that they can be isolated from each other via MAC policy. [1] https://www.redhat.com/archives/libvir-list/2008-August/msg00255.html Libvirt and Persistent Iptables Rules Daniel Berrange responded[1] to a networking problem by pointing out that libvirt will automatically setup the correct iptables rules to allow outbound NAT based connectivity for guest VMs and that restarting the iptables service will erase these rules. [1] https://www.redhat.com/archives/libvir-list/2008-July/msg00508.html David Lutterkort hoped[2] this was a temporary situation due to the confusion it can cause. Mark McLoughlin confirmed[3] there is a RFE (bug 227011) to enable libvirt to persistently register iptables rules, but was depressed that a resulting fix would be Fedora specific. [2] https://www.redhat.com/archives/libvir-list/2008-August/msg00098.html [3] https://www.redhat.com/archives/libvir-list/2008-August/msg00193.html =Network XML Configuration Options= To support a complex virtual network with 3 DMZs, Didier Ayllon asked[1] if it is possible to specify options such as default gateway, static routes, DNS options in the network config. Daniel Berrange pointed[2] out libvirt networking "is designed specifically to only provide 3 types of networking, an isolated network, a NAT based network, and a routed network" and the format is documented on libvirt.org. [1] https://www.redhat.com/archives/libvir-list/2008-August/msg00062.html [2] https://www.redhat.com/archives/libvir-list/2008-August/msg00078.html oVirt Devel List This section contains the discussion happening on the ovirt-devel list. =Lighter-weight "Developer" Setup= Chris Lalancette proposed[1] some steps toward lowering the barrier to entry for oVirt users with limited hardware resources and growing the community. The proposal would remove the "fake managed nodes" concept and allow oVirt to manage the hardware on the host machine and enable installation of guests along side the oVirt appliance, and eventually remove the appliance completely and facilitate installing from a set of RPMs. [1] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00080.html =Beginnings of an oVirt API= David Lutterkort posted[1] an RFC for implementing an oVirt API and 5 patches to begin the discussion. The patches covered handling hosts, storage pools, and hardware pools. The fifth patch provided sample[2] code for using the API. The exercise revealed some changes that could be made to the server code to to accomodate such an API. [1] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00045.html [2] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00050.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIoA9FzHDc8tpb2uURAn7LAJ9zJK8ARnWYLasyeaxJlO+L2T0EpACdHzJS X91bgm0rNNWSCZJeDqP32bE= =mNa6 -----END PGP SIGNATURE----- From stickster at gmail.com Tue Aug 12 15:01:37 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 12 Aug 2008 15:01:37 +0000 Subject: Board public IRC meeting Message-ID: <1218553297.4986.20.camel@victoria> Reminder: a Board public IRC meeting will be held today at 1800 UTC. Details are on the wiki at: https://fedoraproject.org/wiki/Board/IRC -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cdahlin at redhat.com Wed Aug 13 21:16:48 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Wed, 13 Aug 2008 17:16:48 -0400 Subject: ACL Changes and new package group policy Message-ID: <48A34F40.50508@redhat.com> 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 From stickster at gmail.com Thu Aug 14 23:15:13 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 14 Aug 2008 19:15:13 -0400 Subject: Important infrastructure announcement Message-ID: <1218755713.15419.9.camel@victoria> The Fedora Infrastructure team is currently investigating an issue in the infrastructure systems. That process may result in service outages, for which we apologize in advance. We're still assessing the end-user impact of the situation, but as a precaution, we recommend you not download or update any additional packages on your Fedora systems. We'll share updates as we develop more information. Those updates will be published here on the public fedora-announce-list: https://redhat.com/mailman/listinfo/fedora-announce-list Thanks for your patience as we continue working on this. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Sat Aug 16 15:30:03 2008 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 16 Aug 2008 11:30:03 -0400 Subject: Infrastructure status, 2008-08-16 UTC 1530 Message-ID: <1218900603.5845.23.camel@victoria> The Fedora Infrastructure team continues to work on the issues we discovered earlier this week. Right now, we're getting the account system restored to service, along with some of the application servers. We're also taking advantage of the outages to upgrade a few systems at the same time. Some services such as the Account System and the wiki should return to normal over the weekend, but we expect outages to continue for some other systems. Please be patient as we continue to work the problem. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pcalarco at nd.edu Mon Aug 18 13:08:58 2008 From: pcalarco at nd.edu (Pascal Calarco) Date: Mon, 18 Aug 2008 09:08:58 -0400 Subject: Fedora Weekly News, Issue 139 Message-ID: <48A9746A.7040301@nd.edu> * 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 @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 @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 From stickster at gmail.com Tue Aug 19 02:07:45 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 19 Aug 2008 02:07:45 +0000 Subject: Infrastructure status, 2008-08-19 UTC 0200 Message-ID: <1219111665.25510.175.camel@victoria> Our team has been hard at work for several days now, restoring services in the Fedora infrastructure. We started with what we identified as Fedora's "critical path," those systems required to restore minimum daily operation. That work to be completely finished by the end of the day. We then move on to our other value services to complete them as soon as possible. Please give the infrastructure team the time they need to do this demanding work. They have been doing a spectacular job and deserve the absolute highest credit. The systems that are now back online and usable include the following: * Puppet, Xen and FAS hosts * app1, app3, and app4 * database and proxy servers * the majority of the Xen guest machines * serverbeach5, serverbeach4 * Fedora Hosted** The systems that should be available very soon: * asterisk1 and collab1 * cvs1 * builders, x86 and ppc * Fedora People We know the community is awaiting more detail on the past week's activities and their causes. We're preparing a timeline and details and will make them available in the near future. We appreciate the community's patience, and will continue to post updates to the fedora-announce-list as soon as possible. = = = ** New SSH fingerprint for Fedora Hosted: e6:b3:68:51:98:2d:4c:dc:63:27:46:65:51:d5:f0:7a -- Paul W. Frields, Fedora Project Leader gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Fri Aug 22 12:00:02 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 22 Aug 2008 08:00:02 -0400 Subject: Infrastructure report, 2008-08-22 UTC 1200 Message-ID: <1219406402.21605.24.camel@victoria> Last week we discovered that some Fedora servers were illegally accessed. The intrusion into the servers was quickly discovered, and the servers were taken offline. Security specialists and administrators have been working since then to analyze the intrusion and the extent of the compromise as well as reinstall Fedora systems. We are using the requisite outages as an opportunity to do other upgrades for the sake of functionality as well as security. Work is ongoing, so please be patient. Anyone with pertinent information relating to this event is asked to contact fedora-legal at redhat.com. One of the compromised Fedora servers was a system used for signing Fedora packages. However, based on our efforts, we have high confidence that the intruder was not able to capture the passphrase used to secure the Fedora package signing key. Based on our review to date, the passphrase was not used during the time of the intrusion on the system and the passphrase is not stored on any of the Fedora servers. While there is no definitive evidence that the Fedora key has been compromised, because Fedora packages are distributed via multiple third-party mirrors and repositories, we have decided to convert to new Fedora signing keys. This may require affirmative steps from every Fedora system owner or administrator. We will widely and clearly communicate any such steps to help users when available. Among our other analyses, we have also done numerous checks of the Fedora package collection, and a significant amount of source verification as well, and have found no discrepancies that would indicate any loss of package integrity. These efforts have also not resulted in the discovery of additional security vulnerabilities in packages provided by Fedora. Our previous warnings against further package updates were based on an abundance of caution, out of respect for our users. This is also why we are proceeding with plans to change the Fedora package signing key. We have already started planning and implementing other additional safeguards for the future. At this time we are confident there is little risk to Fedora users who wish to install or upgrade signed Fedora packages. In connection with these events, Red Hat, Inc. detected an intrusion of certain of its computer systems and has issued a communication to Red Hat Enterprise Linux users which can be found at http://rhn.redhat.com/errata/RHSA-2008-0855.html. This communication states in part, "Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers." It is important to note that the effects of the intrusion on Fedora and Red Hat are *not* the same. Accordingly, the Fedora package signing key is not connected to, and is different from, the one used to sign Red Hat Enterprise Linux packages. Furthermore, the Fedora package signing key is also not connected to, and is different from, the one used to sign community Extra Packages for Enterprise Linux (EPEL) packages. We will continue to keep the Fedora community notified of any updates. Thank you again for your patience. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From huzaifas at redhat.com Mon Aug 25 10:38:06 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Mon, 25 Aug 2008 16:08:06 +0530 Subject: Fedora Weekly News, Issue 140 Message-ID: <48B28B8E.806@redhat.com> -----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 @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 @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 @fedora-devel as to whether it was possible to trust the new key fingerprint on the website. Jim Meyering added[11] a useful post which explained how to change from using a DSA ssh key to an RSA ssh key. Overall there was a surprisingly low level of public discussion of the problem and it was not until 18-08-2008 that some complaints about the lack of information were expressed[12] on @fedora-list. On 22-08-2008 another bulletin was released[13] by Paul Frields that explained that the Fedora key had not been obviously compromised but that it was still being changed on the precautionary principle. [6] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00011.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 @fedora-list. Jef Spaleta wondered[17] if there might be a better way of getting information out than relying on everyone to subscribe to @fedora-announce. Alan Cox suggested[18] that an RSS feed for critical announcements could be picked up by a system's default package updater and that repositories could communicate errors to yum. Alan was also unhappy with the absence of important notices on the very front of the website and as a separate matter criticized the content of the information issued: "[...] leaving people in the dark assuming the worst [is] a very bad way to create long term trust." Bruno Wolf III also suggested[19] that information should have been conveyed by a more central announcement on fedoraproject.org and co-ordination with media such as LWN.net. [14] https://www.redhat.com/archives/fedora-list/2008-August/msg01955.html [15] https://www.redhat.com/archives/fedora-list/2008-August/msg02034.html [16] https://www.redhat.com/archives/fedora-list/2008-August/msg02426.html [17] https://www.redhat.com/archives/fedora-list/2008-August/msg02010.html [18] https://www.redhat.com/archives/fedora-list/2008-August/msg02012.html [19] https://www.redhat.com/archives/fedora-list/2008-August/msg02013.html Most comments on @fedora-devel made a point of thanking the Fedora Infrastructure admins, even to the extent of providing internet beers[20] and Hans de Goede commented[21] that "Even before the unfortunate events of the last few weeks the infrastructure team has been doing an amazing job[.]" [20] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01037.html [21] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01028.html Epiphany, Konqueror and Plague Hamper Updating SSL Client-side Certificates As part of the general overhaul of Fedora Project infrastructure security occasioned by the recent intrusion[1] Dennis Gilmore advised[2] that the certificate authority governing access to cvs.fedoraproject.org and koji.fedoraproject.org had been changed. As a result it was necessary for those who wished to build packages or upload to the lookaside cache to manually import a new client-side certificate and to remove their old certificate. [1] http://fedoraproject.org/wiki/FWN/Issue139#General_Outage_of_Fedora_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----- From jbwillia at math.vt.edu Mon Aug 25 01:02:20 2008 From: jbwillia at math.vt.edu (ben) Date: Sun, 24 Aug 2008 21:02:20 -0400 Subject: Fedora Unity releases Fedora 8 Re-Spin Message-ID: <48B2049C.3030907@math.vt.edu> 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/