From Fedora Project Wiki

< FWN‎ | Beats

(FWN #162 pass1, user: check, spell check, references check)
Line 2: Line 2:
== Developments ==
== Developments ==


In this section the people, personalities and debates on the @fedora-devel
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
mailing list are summarized.


Contributing Writer: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[OisinFeeley|Oisin Feeley]]


=== Fedora 11 Will Support i586 Instruction Set ===


=== Fedora 11 Alpha May Be Delayed ===
Last week (FWN#161<ref>http://fedoraproject.org/wiki/FWN/LatestIssue#Dropping_Support_for_i586_Architecture_.3F</ref>) we reported on a proposal to cease building Fedora 11 for the i586 CPU instruction set. FESCo had delayed its decision in order to discuss the matter further. The issue was addressed<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-02-05.html</ref> on 2009-02-05 with the outcome that a proposal by [[User:Ausil|Dennis Gilmore]] to continue supporting i586 for the duration of Fedora 11 but to transition to i686 for Fedora 12 was supported.   


[[User:jkeating|Jesse Keating]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02394.html</ref> that the <code>Fedora 11 Alpha</code> release date might slip due to some <code>anaconda</code> bugs which manifested themselves late in his testing on some architectures. A later post suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02395.html</ref> that installation using <code>NFS</code> was broken and that "[t]his likely means a slip, perhaps only a two day slip, of Alpha." More info to come either later this weekend or early next week. A bugzilla comment<ref>https://bugzilla.redhat.com/show.bug.cgi?id=483375#c2</ref> from [[WarrenTogami|Warren Togami]] on a side-effect of trying to fix this problem by reverting to an earlier <code>nfs-utils</code> version warned "People should be aware that NFS as a server in F11 Alpha is broken. That is all." As of going to press on 2009-02-01 there was no further information available.
Prior to the meeting[[WarrenTogami|Warren Togami]] summed up<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00200.html</ref> the advice of [[JakubJelinek|Jakub Jelínek]] as: "Jakub recommends i586.rpm for Fedora 11, because it doesn't gain us much of anything to go with i686 minimum. The benefits of i586 to i686 are simply not important because cmov is usually not a worthwhile optimization on ia32."


<references/>
An interesting suggestion by [[AdamJackson|Adam Jackson]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00282.html</ref><ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00407.html</ref> that if there is a committed user-base of i586 users they could probably support it in the Secondary Architecture (see FWN#92<ref>http://fedoraproject.org/wiki/FWN/Issue92#Secondary_Arch_Proposal_Cont.</ref>) infrastructure.


=== GCC: Default ISA Flags and Glibc===
[[UlrichDrepper|Ulrich Drepper]] and [[User:Rathann|Dominik Mierzejewski]] debated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00240.html</ref> whether the use of cmov can in some circumstances cause performance degradation.


[[JakubJelinek|Jakub Jelinek]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01661.html</ref> whether the minimum CPU which would run code compiled by Fedora 11's <code>GCC</code> should be re-evaluated. A follow-on question was whether the minimum supported kernel version in <code>glibc</code> could be bumped to <code>2.6.29</code>. Jakub held out the promise of potentially increased speed and decreased shared library sizes.
It is unclear exactly what performance benefits could be obtained by passing various architecture-specific flag combinations to GCC but it does seem that the burden of building and maintenance will be eased significantly by these changes. As a related change<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-02-05.html</ref> x86_64 kernels will be installed with a 32-bit userspace.  


A problem raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01668.html</ref> by [[KevinKofler|Kevin Kofler]] was that <code>mock</code> builds would no longer be able to run on older <code>Fedora</code> releases and that some VPSs would not be able to upgrade at all. [[GerdHoffman|Gerd Hoffman]] agreed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01813.html</ref>: "We just can't make the huge jump from .9 to .29. We have to do it smaller steps, considering kernel versions at least in supported Fedora versions, maybe also latest RHEL."
<references/>


[[JoshBoyer|Josh Boyer]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01680.html</ref> to believe that the required mass rebuild with GCC-4.4 would be difficult but possible. [[MikeMcGrath|Mike McGrath]] outlined<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01696.html</ref> the amount of work which would be needed.
=== RFC: Power Management ===
[[PhilKnirsch|Phil Knirsch]] initiated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00365.html</ref> a discussion of attempts to decrease power consumption especially in userland. A wiki page<ref>http://fedoraproject.org/wiki/Features/PowerManagement</ref> reflects some of the research Phil has pulled together.  


See this same FWN#161 "Dropping Support for i586 Architecture" for a related discussion.
[[RichardHughes|Richard Hughes]] pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00376.html</ref> out some interesting work on <code>DeviceKit-power</code> where he built on <code>powertop</code>. [[Olivier Galibert|Olivier Galibert]] raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00430.html</ref> a possible problem with Richard's use of D-Bus itself causing wakeups, but according to [[ColinWalters|Colin Walters]] a patch existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00642.html</ref> to fix this problem.


<references/>
Many of the items suggested in Phil's page for documentation were suggested by [[User:Notting|Bill Nottingham]] as desiderata for defaults. While Phil agreed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00406.html</ref> in general he itemized some of the problems. These include problems with network interfaces and hard-disk spindowns which may be approachable as a result of a <code>tuned</code> daemon on which Phil is working.


=== RPM Packagers: Too Many Unowned Directories ===
An addendum of audio hardware power-saving was made by [[EricSandeen|Eric Sandeen]] along with a list of bugs which led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00413.html</ref> Phil to wonder if a tracker bug to collate all the information would be useful.


[[MichaelSchwendt|Michael Schwendt]] raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02326.html</ref> the problem of unowned directories installed as a result of packagers unfamiliar with "how to include files vs. directories in RPM package %files lists."
[[MatthewGarrett|Matthew Garrett]] expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00415.html</ref> some worries that hard-disk power-saving would cause physical wear and the <code>relatime</code> patches to work around over-aggressive deletion of content in /tmp would continue to be stalled.


[[ColinWalters|Colin Walters]] remembered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02335.html</ref> discussions which had suggested that if <code>RPM</code> were able to reference count directories there could be a technological fix. Separately [[RichardJones|Richard W.M. Jones]] made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02400.html</ref> a similar argument. [[PanuMatilainen|Panu Matilainen]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02350.html</ref> willing to move this task to the top of his queue if it were sufficiently important.
The importance of separating out KDE and GNOME dependent features was noted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00403.html</ref> by [[User:Kkofler|Kevin Kofler]].


<references/>
<references/>


=== Lack of Update Information ===
=== Rawhide Report 2009-02-07 ===


A can of worms was opened<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01643.html</ref> by [[RahulSundaram|Rahul Sundaram]] when he noticed that the update information provided by package maintainers was often unhelpful. He cited generic messages of the form "Update foo to upstream x.y.z" as a common problem and wondered if guidelines could improve the situation.
The last report<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00661.html</ref> lists 14 new packages added, 57 modified and some broken dependencies. New packages include <code>dissy</code>, a graphical front-end to <code>objdump</code> and <code>python-pygooglechart</code> a Python wrapper for the Google Chart API.


Following some questions Rahul expanded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01648.html</ref> on the problem pointing out that package maintainers had the knowledge to tersely explain what upstream changes implied for ordinary users. He emphasized that he was concerned with the "description that is part of bodhi update and not the changelog which can be very brief."
[[RichardHughes|Richard Hughes]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00669.html</ref> that the update to PolicyKit-gnome-0.9.2-1.fc11 might be useful: "If you're having problems with PackageKit and buttons "not working" you need this update."


[[ChrisWeyl|Chris Weyl]] put<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01742.html</ref> forward the counter-argument that package maintainers had a difficult enough life already.
Some of the x86_64 broken dependencies were due to to <code>mono-2.4</code> being pushed to rawhide which led [[User:DavidNielsen|David Nielsen]] to suggest<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00674.html</ref> that a heads up would have been useful. [[User:Alexlan|Alex Lancaster]] requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00746.html</ref> that API/ABI breakage would be announced on @fedora-devel-announce instead of on the high-traffic @fedora-devel.


[[RichardJones|Richard W.M. Jones]] wondered<ref>htts://www.redhat.com/archives/fedora-devel-list/2009-January/msg01687.html</ref> if <code>rpm</code> could be altered to allow it to reference upstream changelogs which could be pulled out by other tools. [[PanuMatilainen|Panu Matilainen]] averred<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01703.html</ref> that while rpm was alterable Richard's proposed change would just dump the information into the rpm payload and it would thus not be available to users until after they had installed it. Further brainstorming seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01737.html</ref> to run into various practical dead ends.
<references/>


Subsequently Rahul published<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01842.html</ref> a draft guideline which fanned the flames back to life. ThorstenLeemhuis asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01845.html</ref> "Don't we have way [too] many guidelines and policies already? [...] Note that I don't disagree with the text that was proposed. My 2 cent: Put it as text into the wiki somewhere, write "best practices" on top of it (avoid the words "rules" and "guidelines") and add a link to the bodhi UI ("best practices for filling this box with information")." Rahul appeared to agree that this was the best course for the present and deferred to FESCo for the ultimate decision.
=== New module-init-tools Uses Binary modules.dep|alias|symbols ===
 
An update to <code>module-init-tools-3.6</code> was pushed to <code>rawhide</code> by [[JonMasters|Jon Masters]] in order to speed up<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00477.html</ref> boot time significantly. The files <code>modules.dep</code>, <code>modules.alias</code> and <code>modules.symbols</code> will have binary versions which are used in preference to their old text versions. Jon asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00353.html</ref> if the need to run <code>depmod -a</code> after upgrades to <code>module-init-tools</code> would upset anyone. There seemed to be general approbation of his changes and they should land soon for Fedora 9 also.  


<references/>
<references/>


=== Electronic Design Automation Content Without Tools ? ===
==== New Georgian Fonts Packaged Rapidly ===


[[ChitleshGoorah|Chitlesh Goorah]] redirected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02364.html</ref> a debate on Electronic Design Automation (EDA)<ref>http://en.wikipedia.org/wiki/Electronic_design_automation</ref> tools from FESCo to @fedora-devel. Chitlesh is the prime mover behind the <code>Fedora Electronic Lab Spin</code><ref>http://chitlesh.fedorapeople.org/FEL/</ref>. He was concerned that FESCo had decided that packages in the OVM<ref>http://www.ovmworld.org/overview.php</ref> format were barred from Fedora on the grounds that there was no FLOSS tool which could use them although they were licensed acceptably.
A call was put out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00281.html</ref> by [[User:Nim|Nicolas Mailhot]] for someone to package a completely new Georgian font pack created by Besarion Paata Gugushvili.  


[[JeffSpaleta|Jef Spaleta]] explained<ref>htts://www.redhat.com/archives/fedora-devel-list/2009-January/msg02369.html</ref> that there were subtle problems in the discussion as "[OVM] is code of some sort. The problem is we don't have a compiler or interpreter that can process the instructions. In the context of Fedora its code that can't be used." [[KevinKofler|Kevin Kofler]] supplied<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02377.html</ref> the appropriate guideline.
Nicolas was especially keen to get this done quickly as he had contacted Besarion and been rewarded with completely new fonts not shipped by any other distro, licensed with the FSF font exception to the GPL all within nine hours!


[[KevinFenzi|Kevin Fenzi]] expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02470.html</ref> appreciation for Chitlesh's work on the Fedora Electronics Lab and asked if there was any use for OVM besides hooking it up with a non-Free simulator? [[ManuelWolfshant|Manuel Wolfshant]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02480.html</ref> that OVM was i[...] interesting for a subset of the people interested in EDA" and that it should be provided for them. [[HorstvonBrand|Horst von Brand]] disliked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02489.html</ref> the idea of mirrors carrying such a little-used package around and suggested that Manuel could just set up his own repository.
[[User:Spot|Tom Callaway]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00308.html</ref> within mere hours.


<references/>
<references/>


=== Dropping Support for i586 Architecture ? ===
=== Distro-agnostic /boot Metadata Standard ? ===


Following FESCo discussions<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02328.html</ref>[[BillNottingham|Bill Nottingham]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02345.html</ref> that the supported architecture list was going to change. Important changes include building binaries only for i686 and above. There are concerns that older thin clients based on i586 hardware and the AMD Geode-based XO laptops may then be unsupported or unstable. Bill characterized the discussions as a follow-up to the compiler flag discussions (see this same FWN#161"GCC: Default ISA Flags and Glibc") and summarized the main points as:
A negative review in German IT magazine "c't" led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00273.html</ref> [[ChristophHoger|Christoph Höger]] to ask if it was possible to preserve the ability to boot other GNU/Linux distros after installing Fedora. The most annoying point seemed to be that Windows installations are preserved.


<pre>
A moderately long thread resulted and covered several ideas to allow the <code>GRUB</code> bootloader to identify other distributions. One such was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00345.html</ref> .that there should be an agreement among distributions to use a shared metadata standard on boot partitions.
- install x86.64 kernel on 32-bit OS where appropriate
- install PAE kernel on other 32-bit OS installs where appropriate
- build only i686 and above for Fedora
</pre>


[[JeremyKatz|Jeremy Katz]] added<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02382.html</ref> anecdotal reassurance that the XO should probably be fine with the i686 kernel and glibc.
<references/>
 
=== GCC-4.4 Mass Rebuild Successful ===
 
[[JakubJelinek|Jakub Jelínek]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00180.html</ref> that a mass rebuild of rawhide (snapshotted on 2009-01-26) of 6228 packages had produced only a few hundred failures. He listed these by type of failure.  


[[RobertScheck|Robert Scheck]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02355.html</ref> what the definition of "where appropriate" was and what mechanism would be used to make this determination.
Several of the packages listed failed to build for reasons other than GCC, for instance Java packages failed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00220.html</ref> due to <code>maven</code> being broken.


[[DominikMierzejewski|Dominik 'Rathann' Mierzejewski]] predicted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02378.html</ref> "[t]here's going to be some screaming from VIA C3 and AMD K6 users about this." His suggestion was true during an older similar discussion (see FWN#93<ref>http://fedoraproject.org/wiki/FWN/Issue93#No_More_586_Kernels</ref>) in 2007 which concerned plans to drop shipping an i586 kernel. Suggested attempts to compensate by making the i686 kernel bootable on i586 architectures were thwarted as rpm balked at installing a kernel which violated its architecture check. [[AlanCox|Alan Cox]] was one of the strongest objectors to the possibility of thus losing support for i586 as he had many thin clients using that architecture. Doubt was cast during that thread as to whether the smolt statistics were believable. However, Alan has recently become an Intel employee (following other ex-Red Hat luminaries [[DavidWoodhouse|David Woodhouse]] and [[ArjanvandeVen)|Arjan van de Ven]]) and did not contribute to the thread. The <code>smolt</code> statistics listed<ref>http://fedoraproject.org/wiki/Features/ArchitectureSupport#What_about_the_i586_users_3F</ref> on the feature page suggest that there are only 130 i586 users.
[[User:knurd|Thorsten Leemhuis]] provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00229.html</ref> a list of packages and owners sorted by owner which was generally appreciated. He pointed out: "Finding all your packages in such a long list gets really hard as soon as you maintain 10 or 15 packages."


[[JoshBoyer|Josh Boyer]] clarified<ref>htts://www.redhat.com/archives/fedora-devel-list/2009-January/msg02383.html</ref> that no decision had yet been made by FESCo and that a vote would take place next week.
Problems reported due to a mismatch between the <code>libstdc++</code> headers requirement of <code>-march=i486</code> and <code>Koji</code>'s default use of <code>-march=i386</code> led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00257.html</ref> Jakub to whip up some fixes. He requested that <code>CFLAGS</code> were not altered in <code>SPEC</code> files.


<references/>
<references/>


=== Blinking Cursor Wastes Power ===
=== Help Rel-eng Accelerate Updates Processing ===
 
[[MatthewGarret|Matthew Garrett]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02265.html</ref> for comments on the idea that the cursor should default to not blinking. The rationale was that several less Watts of power would be consumed. 


The suggestion seemed generally popular but [[DominikMierzejewski|Dominik `Rathann' Mierzejewski]] wished to retain the blinking cursor and expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02309.html</ref> a desire for more information on the methodology which Matthew had used. [[BillNottingham|Bill Nottingham]] reminded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02320.html</ref> that it would still be possible to turn the cursor back on from this new default. Matthew provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02387.html</ref> some of the requested details.
One bottleneck in the processing of updates to packages is that they need to be signed. Work is ongoing to automate this (see FWN#147<ref>http://fedoraproject.org/wiki/FWN/Issue147#Unsigned_Rawhide_Packages_an_Attack_Vector_.3F</ref>) with a signing-server codenamed "sigul".  


[[MatthiasClasen|Matthias Clasen]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02268.html</ref> changing a <code>GTK</code> setting which disables cursor blinking after a timeout. [[JoshBoyer|Josh Boyer]] worried<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02287.html</ref> about other desktop environments and vttys.
[[User:Cwickert|Christoph Wickert]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00508.html</ref> why it had taken over five days for an update to one of his packages to get to <code>testing</code>. When [[User:Jwboyer|Josh Boyer]] responded that it was because one human ([[User:Jkeating|Jesse Keating]]) had to sign the packages and he had been also busy getting <code>Fedora 11 Alpha</code> released, [[DanielBerrange|Daniel P. Berrange]] suggested<code>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00515.html</code> adding more humans to help. [[JesseKeating|Jesse Keating]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00576.html</ref> that anyone who wished to help could take some of the load off the release-engineering team so that they had more time for package signing.


<references/>
<references/>

Revision as of 02:40, 9 February 2009

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Fedora 11 Will Support i586 Instruction Set

Last week (FWN#161[1]) we reported on a proposal to cease building Fedora 11 for the i586 CPU instruction set. FESCo had delayed its decision in order to discuss the matter further. The issue was addressed[2] on 2009-02-05 with the outcome that a proposal by Dennis Gilmore to continue supporting i586 for the duration of Fedora 11 but to transition to i686 for Fedora 12 was supported.

Prior to the meetingWarren Togami summed up[3] the advice of Jakub Jelínek as: "Jakub recommends i586.rpm for Fedora 11, because it doesn't gain us much of anything to go with i686 minimum. The benefits of i586 to i686 are simply not important because cmov is usually not a worthwhile optimization on ia32."

An interesting suggestion by Adam Jackson was[4][5] that if there is a committed user-base of i586 users they could probably support it in the Secondary Architecture (see FWN#92[6]) infrastructure.

Ulrich Drepper and Dominik Mierzejewski debated[7] whether the use of cmov can in some circumstances cause performance degradation.

It is unclear exactly what performance benefits could be obtained by passing various architecture-specific flag combinations to GCC but it does seem that the burden of building and maintenance will be eased significantly by these changes. As a related change[8] x86_64 kernels will be installed with a 32-bit userspace.

RFC: Power Management

Phil Knirsch initiated[1] a discussion of attempts to decrease power consumption especially in userland. A wiki page[2] reflects some of the research Phil has pulled together.

Richard Hughes pointed[3] out some interesting work on DeviceKit-power where he built on powertop. Olivier Galibert raised[4] a possible problem with Richard's use of D-Bus itself causing wakeups, but according to Colin Walters a patch existed[5] to fix this problem.

Many of the items suggested in Phil's page for documentation were suggested by Bill Nottingham as desiderata for defaults. While Phil agreed[6] in general he itemized some of the problems. These include problems with network interfaces and hard-disk spindowns which may be approachable as a result of a tuned daemon on which Phil is working.

An addendum of audio hardware power-saving was made by Eric Sandeen along with a list of bugs which led[7] Phil to wonder if a tracker bug to collate all the information would be useful.

Matthew Garrett expressed[8] some worries that hard-disk power-saving would cause physical wear and the relatime patches to work around over-aggressive deletion of content in /tmp would continue to be stalled.

The importance of separating out KDE and GNOME dependent features was noted[9] by Kevin Kofler.

Rawhide Report 2009-02-07

The last report[1] lists 14 new packages added, 57 modified and some broken dependencies. New packages include dissy, a graphical front-end to objdump and python-pygooglechart a Python wrapper for the Google Chart API.

Richard Hughes suggested[2] that the update to PolicyKit-gnome-0.9.2-1.fc11 might be useful: "If you're having problems with PackageKit and buttons "not working" you need this update."

Some of the x86_64 broken dependencies were due to to mono-2.4 being pushed to rawhide which led David Nielsen to suggest[3] that a heads up would have been useful. Alex Lancaster requested[4] that API/ABI breakage would be announced on @fedora-devel-announce instead of on the high-traffic @fedora-devel.

New module-init-tools Uses Binary modules.dep|alias|symbols

An update to module-init-tools-3.6 was pushed to rawhide by Jon Masters in order to speed up[1] boot time significantly. The files modules.dep, modules.alias and modules.symbols will have binary versions which are used in preference to their old text versions. Jon asked[2] if the need to run depmod -a after upgrades to module-init-tools would upset anyone. There seemed to be general approbation of his changes and they should land soon for Fedora 9 also.

= New Georgian Fonts Packaged Rapidly

A call was put out[1] by Nicolas Mailhot for someone to package a completely new Georgian font pack created by Besarion Paata Gugushvili.

Nicolas was especially keen to get this done quickly as he had contacted Besarion and been rewarded with completely new fonts not shipped by any other distro, licensed with the FSF font exception to the GPL all within nine hours!

Tom Callaway responded[2] within mere hours.

Distro-agnostic /boot Metadata Standard ?

A negative review in German IT magazine "c't" led[1] Christoph Höger to ask if it was possible to preserve the ability to boot other GNU/Linux distros after installing Fedora. The most annoying point seemed to be that Windows installations are preserved.

A moderately long thread resulted and covered several ideas to allow the GRUB bootloader to identify other distributions. One such was[2] .that there should be an agreement among distributions to use a shared metadata standard on boot partitions.

GCC-4.4 Mass Rebuild Successful

Jakub Jelínek reported[1] that a mass rebuild of rawhide (snapshotted on 2009-01-26) of 6228 packages had produced only a few hundred failures. He listed these by type of failure.

Several of the packages listed failed to build for reasons other than GCC, for instance Java packages failed[2] due to maven being broken.

Thorsten Leemhuis provided[3] a list of packages and owners sorted by owner which was generally appreciated. He pointed out: "Finding all your packages in such a long list gets really hard as soon as you maintain 10 or 15 packages."

Problems reported due to a mismatch between the libstdc++ headers requirement of -march=i486 and Koji's default use of -march=i386 led[4] Jakub to whip up some fixes. He requested that CFLAGS were not altered in SPEC files.

Help Rel-eng Accelerate Updates Processing

One bottleneck in the processing of updates to packages is that they need to be signed. Work is ongoing to automate this (see FWN#147[1]) with a signing-server codenamed "sigul".

Christoph Wickert wondered[2] why it had taken over five days for an update to one of his packages to get to testing. When Josh Boyer responded that it was because one human (Jesse Keating) had to sign the packages and he had been also busy getting Fedora 11 Alpha released, Daniel P. Berrange suggestedhttp://www.redhat.com/archives/fedora-devel-list/2009-February/msg00515.html adding more humans to help. Jesse Keating suggested[3] that anyone who wished to help could take some of the load off the release-engineering team so that they had more time for package signing.