FWN/Beats/Developments: Difference between revisions

Revision as of 04:30, 19 January 2009

Developments

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

Contributing Writer: Oisin Feeley

The Possible Future of Comps ?

Seth Vidal reported[1] that one outcome of the recent FUDCon[2] had been an initiative to overhaul the comps.xml file. This file is part of the metadata used to define group membership of related packages in order to allow[3] yum or anaconda to aid in installation.

Seth described the intent to replace the fixed group definitions with metapackages created on-the-fly, based on examining and dependency-solving repository metadata, as "a fairly radical departure". Related changes will be the ability to define groups within groups and the addition of new metadata to allow tag cloud classification. Some of the anticipated benefits are the ability to find desired software more easily, the creation of more fine-grained groups and a more intuitive persistence of groups.

One apparent sticking point raised by Bill Nottingham was that the flattening of the package levels included the removal of "conditional" packages and "[...] a large portion of the language support is built around conditional packages." Seth argued[4] that removing conditional packages was something which was desirable whether or not this particular initiative took hold. This seemed like a problem especially for KDE but Bill prototyped[5] a yum plugin to solve the problem.

Some examples in which removing a metapackage would not remove dependencies installed to satisfy the metapackage were teased out[6][7] in conversations between Josh Boyer and Seth and Jesse Keating.

Florian Festi thought[8] that the list of problems to be solved should be expanded to include how multilib is handled, the proliferation of noarch subpackages and poor implementations of parts of the tool-chain. He also emphasized that with the "increasing number of languages supported and packages being properly translated we ship more and more language dependent content the users are not interested in. We are currently missing both a way to package these contents properly and a mechanism the control which should be actually installed."

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00733.html

[2] http://fedoraproject.org/wiki/FUDCon

[3] http://fedoraproject.org/wiki/PackageMaintainers/CompsXml#How_comps_is_used

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00748.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00882.html

[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00751.html

[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00777.html

[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00841.html

New GPG Signing Keys for Each Release

Jesse Keating asked[1] what value Fedora users perceived in the presence of the "[...] two gpg keys per release, one for rawhide/updates-testing and one for the final release and stable updates."

Todd Zullinger suggested[2] that eschewing the importation of the "updates-testing" key would ensure that "[...] no packages from updates-testing are installed on a box [.]" Casey Dahlin disliked[3] such a use of keys to categorize things.

Todd asked if each new release would come with a new key, similar to the way this was handled after the infrastructure intrusion. He balanced the sense of confidence given by keeping a key around for a "reasonably long time" versus the mitigation of "the lack of any way to revoke a key in the rpm db [.]" Jesse confirmed[4] "[...] yes, we plan to use new keys each release. We can use gpg web-"-trust thing and sign the new keys with the old keys and whatnot, does that actually help people?j

Douglas E. Warner and Steve Grubb worried[5] that the inability to revoke keys exposed machines to repository metadata attacks and Steve revealed[6] that the import of keys is "[...] one of the few security sensitive actions that is not put into the audit system."

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00999.html

[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01001.html

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01020.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01003.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01036.html

[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01050.html

libssl.so.7 Going Through a Bumpy Patch

Tomas Mraz advised[1] that he was going to build a new OpenSSL in rawhide which would require a soname bump due to minor breakage of the ABI. As a transitional measure he intended to temporarily provide symlinks to the old soname so that most of the 288 affected packages should continue working until they were rebuilt. Jesse Keating expressed[2] disquiet with the timing as the large number of rebuilds would be "[...] likely to break buildroots, break anaconda composes, break installs, break users. This isn't the kind of crap we want to land in rawhide just before a freeze, and just before an effort to turn that freeze into something usable. PLEASE wait until after Alpha has been cut to do this." He seemed slightly mollified[3] by Tomas' use of compatibility symlinks and rpm provides.

When Benny Amorsen wondered why such breakage was occurring again with openssl Tomas explained[4] that the design "declar[ed] some important structures which have to be changed/extended with new functionality in the public headers. Unless they move these structures to private headers this situation is going to happen again." Christopher Aillon joked[5] that it was happening again because Benny had not ported his applications to use NSS(see FWN#107[6]).

Later Horst von Brand reported[7] widespread problems with many packages which seemed to fail. RalfErtzinger explained[8] that "[t]he problem is that the openssl package was supposed to contain symlinks for libssl.so.7 and libcrypto.so.7, and rpm -ql says that the package does contain them, but they are, in fact, missing from the filesystem."

Tomas Mraz scrambled[9][10] to sort out the problem by trying to run ldconfig in the %post of the openssl package. Kevin Kofler suggested[11] a possible cause.

Jesse Keating fretted[12] that all of this was exactly what he did not want just before next week's alpha freeze[13].

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00758.html

[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00761.html

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00764.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00880.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00977.html

[6] https://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation

[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00941.html

[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00942.html

[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00943.html

[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00946.html

[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01051.html

[12] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01000.html

[13] https://fedoraproject.org/wiki/Releases/11/Schedule

MinGW Package Reviews Requested

Richard W.M. Jones noted[1] that the rapid development cycle[2] meant that Fedora 11 was already approaching (2009-01-20) alpha-freeze and asked for package reviews of the outstanding parts of the MinGW Windows cross-compiler feature[3]. He offered to trade reviews with interested parties and provided links to outstanding reviews.

There is apparently no question that the feature, which will allow generation of Windows targets on Fedora, will slip from Fedora 11.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00793.html

[2] https://fedoraproject.org/wiki/Releases/11/Schedule

[3] https://fedoraproject.org/wiki/Features/Windows_cross_compiler

MySQL 5.1 Coming to Rawhide After Alpha-Freeze

A heads-up was posted[1] by Tom Lane to advise that mysql-5.1.30 would be pushed into rawhide immediately after the alpha freeze. He warned: "This involves an ABI break: libmysqlclient.so has increased its major version number from 15 to 16 [...]" and provided a list of affected packages along with the offer to launch rebuilds for anyone who wished.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00721.html

Spins SIG Controversy

A vigorous disagreement erupted when Jeroen van Meeuwen announced[1] that the Spins SIG[2] would henceforth be having meetings every two weeks (Jeroen later rescheduled[3] the meeting to Mondays at 17:00 UTC) and that the first meeting would be to finalize a new process arrived at during the last FUDCon.

Rahul Sundaram contended[4] that "[s]uch decisions shouldn't be taken at FUDCon because it automatically excludes people who cannot be present at the event. You should use the events only to discuss the issues and make the decisions over mailing lists or irc where others can participate as well." A long thread mostly involving just Rahul, Jeroen and Josh Boyer resulted.

In response to Rahul's point that the new process was onerous as it mandated a weekly compose and report JoshBoyer seemed[5] to be of the opinion that this was a good thing. BillNottingham added[6]: "It's not really adding anything to the amount of work that needs to be done, in total. It's just shifting around who it gets done by and when."

Some weight was given to Rahul's argument that the method of arriving at the new process was a problem when Jeroen posted[7] that no minutes had been kept of the meeting and pointed to a "5-minute after best-recollection of what happened" summary on the wiki[8] as a source of information.

JesseKeating argued[9] that FUDCon was a useful, "high-bandwidth" means of having discussions and that public email was too slow to make decisions compared to IRC, IM, phone and face-to-face meetings. Subsequently he added that the result of the FUDCon discussions was a proposal and not a decision and suggested that unless the skeleton process was approved quickly then there might be no spins for Fedora 11. Rahul responded[10] that the original post had been a simple declaration which did not suggest it was merely a proposal. Rahul added[11] that there was a need to clarify the process in order to avoid the confusion of the past.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00695.html

[2] http://fedoraproject.org/wiki/SIGs/Spins

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00782.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00789.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00811.html

[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00826.html

[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00838.html

[8] http://fedoraproject.org/wiki/SIGs/Spins_NewProcess

[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00864.html

[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00872.html

[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00874.html

@@ Line 7: / Line 7: @@
 Contributing Writer: [[OisinFeeley|Oisin Feeley]]
-=== Default ssh-agent Dialog Pop-up ===
+=== The Possible Future of Comps ? ===
-Confusion abounded when user "nodata" reported[1] that running <code>ssh-add</code> from the command-line popped up a gnome dialog requesting his private SSH key. "nodata" disliked handing out his private key in such a manner. The confusion resulted from the availability of at least two possible <code>ssh-agents</code>[2] and also a change in configuration between <code>Fedora 9</code> and <code>Fedora 10</code> which presents the authentication dialog by default.
+[[SethVidal|Seth Vidal]] reported[1] that one outcome of the recent FUDCon[2] had been an initiative to overhaul the <code>comps.xml</code> file. This file is part of the metadata used to define group membership of related packages in order to allow[3] <code>yum</code> or <code>anaconda</code> to aid in installation.
-[[RickyZhou|Ricky Zhou]] was among those who suggested (with a manpage quote) that the <code>SSH_ASKPASS</code> environment variable determined whether the passphrase was read from a terminal or by an X11 dialog. Separately [[JesseKeating|Jesse Keating]][3] and [[NalinDahyabhai|Nalin Dahyabhi]] explained[4] that the dialog was presented by <code>gnome-keyring</code> and not <code>gnome-ssh-askpass</code>.
+Seth described the intent to replace the fixed group definitions with metapackages created on-the-fly, based on examining and dependency-solving repository metadata, as "a fairly radical departure". Related changes will be the ability to define groups within groups and the addition of new metadata to allow tag cloud classification. Some of the anticipated benefits are the ability to find desired software more easily, the creation of more fine-grained groups and a more intuitive persistence of groups.
-"nodata" questioned[5] whether the behavior had changed between <code>Fedora 9</code> and <code>Fedora 10</code> and expressed irritation that a "[...] GUI is popping up when I am using a command line app." [[JesseKeating|Jesse Keating]] responded[6]: "You're using a command line app from a graphical terminal. Also, cli apps aren't the only use for ssh and ssh keys." This did not appeal to many respondents including [[JohnLinville|John Linville]] who questioned[7] the benefit of changing focus to a new window to type a passphrase. [[CallumLerwick|Callum Lerwick]] rather tartly outlined[8] some benefits including preventing key logging attacks.
+One apparent sticking point raised by [[BillNottingham|Bill Nottingham]] was that the flattening of the package levels included the removal of "conditional" packages and "[...] a large portion of the language support is built around conditional packages." Seth argued[4] that removing conditional packages was something which was desirable whether or not this particular initiative took hold. This seemed like a problem especially for <code>KDE</code> but Bill prototyped[5] a <code>yum</code> plugin to solve the problem.
-[[MatthiasClasen|Matthias Clasen]] suggested[9] using
+Some examples in which removing a metapackage would not remove dependencies installed to satisfy the metapackage were teased out[6][7] in conversations between [[JoshBoyer|Josh Boyer]] and Seth and [[JesseKeating|Jesse Keating]].
-<pre>
-gconftool-2 -s -t bool /apps/gnome-keyring/daemon-components/ssh false
-</pre>
-to turn off the behavior for those who dislike it and this led to several requests to make this the default. [[AndrewHaley|Andrew Haley]] put[10] the case that "[t]he key argument against a pop-up dialog box that asks for the passphrase is that we're training people to type secrets into pop-up dialog boxes. Bad psychology, bad security."
-][MatthiasClasen|Matthias Clasen]] and [[TomasMraz|Tomas Mraz]] with [[JerryAmundson|Jerry Amundson]] explored[11] the use of <code>SSH_ASKPASS</code> as an alternate method to disable the GUI dialog.
+[[FlorianFesti|Florian Festi]] thought[8] that the list of problems to be solved should be expanded to include how <code>multilib</code> is handled, the proliferation of <code>noarch</code> subpackages and poor implementations of parts of the tool-chain. He also emphasized that with the "increasing number of languages supported and packages being properly translated we ship more and more language dependent content the users are not interested in. We are currently missing both a way to package these contents properly and a mechanism the control which should be actually installed."
-[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00486.html
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00733.html
-[2] Private keys are stored by ssh agents so that they may handle all key related operations requested by clients. The passphrase to decrypt the key thus need only be typed into the agent once instead of per-operation.
+[2] http://fedoraproject.org/wiki/FUDCon
-[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00487.html
+[3] http://fedoraproject.org/wiki/PackageMaintainers/CompsXml#How_comps_is_used
-[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00536.html
+[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00748.html
-[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00492.html
+[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00882.html
-[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00495.html
+[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00751.html
-[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00523.html
+[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00777.html
-[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00533.html
+[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00841.html
-[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00498.html
+=== New GPG Signing Keys for Each Release ===
-[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00517.html
+[[JesseKeating|Jesse Keating]] asked[1] what value <code>Fedora</code> users perceived in the presence of the "[...] two gpg keys per release, one for rawhide/updates-testing and one for the final release and stable updates."
-[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00540.html
+[[ToddZullinger|Todd Zullinger]] suggested[2] that eschewing the importation of the "updates-testing" key would ensure that "[...] no packages from updates-testing are installed on a box [.]" [[CaseyDahlin|Casey Dahlin]] disliked[3] such a use of keys to categorize things.
-=== Intel Graphics Installation Woes ===
+Todd asked if each new release would come with a new key, similar to the way this was handled after the infrastructure intrusion. He balanced the sense of confidence given by keeping a key around for a "reasonably long time" versus the mitigation of "the lack of any way to revoke a key in the rpm db [.]" Jesse confirmed[4] "[...] yes, we plan to use new keys each release. We can use gpg web-"-trust thing and sign the new keys with the old keys and whatnot, does that actually help people?j
-"Mike" requested[1] information on when a working <code>xorg-x11-drv-i810</code> driver for Intel graphics chipsets had a chance of appearing. He was disappointed that it was non-trivial to get two machines with <code>82945G</code> and <code>82845G</code> chipsets installed and had needed to fall back to using the <code>vesa</code> driver instead of the intel one.
+[[DouglasWarner|Douglas E. Warner]] and [[SteveGrubb|Steve Grubb]] worried[5] that the inability to revoke keys exposed machines to repository metadata attacks and Steve revealed[6] that the import of keys is "[...] one of the few security sensitive actions that is not put into the audit system."
-Others listed outstanding bugzilla entries for a wide range of Intel chipsets. [[DanWilliams|Dan Williams]] asked[2] if using Option "EXANoComposite" "true" as a workaround for problems with the <code>i830</code> chipsets was succesfull and received mixed reports. It seemed that he was making some progress with resolving some of the issues.
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00999.html
-MAYoung suggested[3] that setting "NoAccel true" in <code>xorg.conf</code> might work for some people but that "[...] intel graphics are highly flaky on Fedora 10."
+[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01001.html
-[[RobertArendt|Robert Arendt]] laid[4] the blame at the door of upstream merges of <code>GEM/DRM</code> into the kernel and noted that other distributions were suffering identical problems. "Mike" later confirmed[5] this with a list of bugzilla entries from upstream GNOME: "It would be nice if Intel would help to get this fixed, and there are indeed problems with Suse, Ubuntu and Mandriva also with newer drivers and Intel graphics chipsets of various flavors - this is really bad!"
+[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01020.html
-[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00435.html
+[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01003.html
-[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00475.html
+[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01036.html
-[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00443.html
+[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01050.html
-[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00445.html
+=== libssl.so.7 Going Through a Bumpy Patch ===
-[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00467.html
+[[TomasMraz|Tomas Mraz]] advised[1] that he was going to build a new <code>OpenSSL</code> in <code>rawhide</code> which would require a soname bump due to minor breakage of the ABI. As a transitional measure he intended to temporarily provide symlinks to the old soname so that most of the 288 affected packages should continue working until they were rebuilt. [[JesseKeating|Jesse Keating]] expressed[2] disquiet with the timing as the large number of rebuilds would be "[...] likely to break buildroots, break anaconda composes, break installs, break users. This isn't the kind of crap we want to land in rawhide just before a freeze, and just before an effort to turn that freeze into something usable. PLEASE wait until after Alpha has been cut to do this." He seemed slightly mollified[3] by Tomas' use of compatibility symlinks and rpm provides.
-=== KPackageKit Auto-update Bug ===
+When [[BennyAmorsen|Benny Amorsen]] wondered why such breakage was occurring again with <code>openssl</code> Tomas explained[4] that the design "declar[ed] some important structures which have to be changed/extended with new functionality in the public headers. Unless they move these structures to private headers this situation is going to happen again." [[ChristopherAillon|Christopher Aillon]] joked[5] that it was happening again because Benny had not ported his applications to use NSS(see FWN#107[6]).
-[[MichaelAllen|Michael B Allen]] reported[1] that his system had performed an update without his permission and asked how to completely disable such behavior.
+Later [[HorstvonBrand|Horst von Brand]] reported[7] widespread problems with many packages which seemed to fail. RalfErtzinger explained[8] that "[t]he problem is that the openssl package was supposed to contain symlinks for libssl.so.7 and libcrypto.so.7, and rpm -ql says that the package does contain them, but they are, in fact, missing from the filesystem."
-It appeared[2] that this was due to a bug in <code>KPackageKit</code> which has been unfixable[3] for over a month due in part to the complexity of the code.
+[[TomasMraz|Tomas Mraz]] scrambled[9][10] to sort out the problem by trying to run <code>ldconfig</code> in the <code>%post</code> of the <code>openssl</code> package. [[KevinKofler|Kevin Kofler]] suggested[11] a possible cause.
-[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00461.html
+[[JesseKeating|Jesse Keating]] fretted[12] that all of this was exactly what he did not want just before next week's alpha freeze[13].
-[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00504.html
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00758.html
-[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00510.html
+[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00761.html
-=== Disabling Staging Drivers ? ===
+[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00764.html
-[[RahulSundaram|Rahul Sundaram]] asked[1] if enabling the many new drivers in the staging tree[2] would make sense in <code>rawhide</code> in order to support a wider range of hardware such as the <code>EeePC</code>'s <code>ralink</code> wireless chipset.
+[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00880.html
-Opinion was roughly split between those who were completely against the idea and those who suggested avoiding codifying a rigid policy. [[MatthewGarrett|Matthew Garrett]] believed[3] that it would be "somewhat user-hostile" to, for example enable the <code>ralink</code> drivers in <code>rawhide</code> but possibly remove them for a general release. He argued that the <code>ralink</code> drivers were a dead-end[4] which would never merge upstream. On the other hand [[DaveJones|Dave Jones]] preferred[5] to take a case-by-case approach as long as "[...] we have someone responsible for working on it, with the goal of getting it out of staging, and dealing with bugs etc. Not unlike the same reasoning for us adding various not-yet-upstream drivers to the Fedora kernel really."
+[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00977.html
-While preferring to completely disable the staging drivers [[ThorstenLeemhuis|Thorsten Leemhuis]] expressed[6] the intention to provide <code>RPM Fusion</code> <code>kmods</code> in that case. [[DanWilliams|Dan Williams]] made[7] a strong argument that "-staging" itself was a bad idea as it gave "legitimacy to drivers of questionable quality" and [[JohnLinville|John Linville]] limned[8] the tortured history of the <code>at76</code> driver.
+[6] https://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation
-[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00459.html
+[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00941.html
-[2] "linux-staging" is a kernel tree whose purpose is to test drivers and filesystems for later inclusion in mainline http://lkml.org/lkml/2008/6/10/329
+[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00942.html
-[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00462.html
+[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00943.html
-[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00474.html
+[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00946.html
-[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00472.html
+[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01051.html
-[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00465.html
+[12] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01000.html
-[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00473.html
+[13] https://fedoraproject.org/wiki/Releases/11/Schedule
-[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00476.html
+=== MinGW Package Reviews Requested===
-=== git-* Commands Moved to /usr/libexec/git-core/ ===
+[[RichardJones|Richard W.M. Jones]] noted[1] that the rapid development cycle[2] meant that <code>Fedora 11</code> was already approaching (2009-01-20) alpha-freeze and asked for package reviews of the outstanding parts of the <code>MinGW</code> Windows cross-compiler feature[3]. He offered to trade reviews with interested parties and provided links to outstanding reviews.
-[[AdamTkac|Adam Tkac]] worried[1] that scripts would break due to the latest git branch in rawhide which had moved all the <code>git-*</code> binaries to <code>/usr/libexec/git-core</code> in order to comply with upstream practice. The issue was previously discussed (see FWN#141[2)] with the resolution that updating to <code>git-1.6.0</code> would be a flag day for this change. Adam suggested that the new location could be added to the <code>PATH</code> environment variable but this received no support.
+There is apparently no question that the feature, which will allow generation of Windows targets on Fedora, will slip from Fedora 11.
-[[KarelZak|Karel Zak]] advocated[3] that such scripts should be fixed as the change had been coming since 2006.
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00793.html
-[[BrynReeves|Bryn Reeves]] wondered[4] if compatibility symlinks and a release note would ease the transition over a couple of releases. Although the symlinks were generally felt to be a non-effective strategy [[ToddZulinger|Todd Zulinger]] was encouraged[5] by [[PaulFrields|Paul W. Frields]] to open a bugzilla entry against the Release Notes to ensure that the documentation team take care of highlighting the issue for <code>Fedora 11</code>.
+[2] https://fedoraproject.org/wiki/Releases/11/Schedule
-[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00404.html
+[3] https://fedoraproject.org/wiki/Features/Windows_cross_compiler
-[2] http://fedoraproject.org/wiki/FWN/Issue141#Git-1.6.0_Commands_to_be_Moved_Out_of_PATH
+=== MySQL 5.1 Coming to Rawhide After Alpha-Freeze ===
-[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00408.html
+A heads-up was posted[1] by [[TomLane|Tom Lane]] to advise that <code>mysql-5.1.30</code> would be pushed into <code>rawhide</code> immediately after the alpha freeze. He warned: "This involves an ABI break: libmysqlclient.so has increased its major version number from 15 to 16 [...]" and provided a list of affected packages along with the offer to launch rebuilds for anyone who wished.
-[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00410.html
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00721.html
-[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00460.html
+=== Spins SIG Controversy ===
-=== Mandatory FHS Adherence ===
+A vigorous disagreement erupted when [[JeroenvanMeeuwen|Jeroen van Meeuwen]] announced[1] that the Spins SIG[2] would henceforth be having meetings every two weeks (Jeroen later rescheduled[3] the meeting to Mondays at 17:00 UTC) and that the first meeting would be to finalize a new process arrived at during the last FUDCon.
-[[JasonLTibbittsIII|JasonTibbitts]] posted[1] a summary and links to the 2009-01-06 FPC meeting deliberations. Interest on @fedora-devel was mostly sparked by the item which declared that the FPC would "Make adherence to the FHS a MUST [.]" Jason encouraged reading of the full minutes in order to understand this item.
+[[RahulSundaram|Rahul Sundaram]] contended[4] that "[s]uch decisions shouldn't be taken at FUDCon because it automatically excludes people who cannot be present at the event. You should use the events only to discuss the issues and make the decisions over mailing lists or irc where others can participate as well." A long thread mostly involving just Rahul, Jeroen and [[JoshBoyer|Josh Boyer]] resulted.
-[[DougLedford|Doug Ledford]] discussed[2] the problem his MPI[3] implementations experienced with the FHS and [[RichardJones|Richard W. M. Jones]] expressed [4] concern that the FHS was a moribund standard and adhering to it would block projects such as MinGW without any method to evolve the standard. [[ToshioKuratomi|Toshio Kuratomi]] responded in detail in both threads and pointed out[5] that the MinGW case had been addressed in the meeting and also that there were problems with changing the FHS.
+In response to Rahul's point that the new process was onerous as it mandated a weekly compose and report JoshBoyer seemed[5] to be of the opinion that this was a good thing. BillNottingham added[6]: "It's not really adding anything to the
+amount of work that needs to be done, in total. It's just shifting around who it gets done by and when."
-[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00362.html
+Some weight was given to Rahul's argument that the method of arriving at the new process was a problem when Jeroen posted[7] that no minutes had been kept of the meeting and pointed to a "5-minute after best-recollection of what happened" summary on the wiki[8] as a source of information.
-[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00424.html
+JesseKeating argued[9] that FUDCon was a useful, "high-bandwidth" means of having discussions and that public email was too slow to make decisions compared to IRC, IM, phone and face-to-face meetings. Subsequently he added that the result of the FUDCon discussions was a proposal and not a decision and suggested that unless the skeleton process was approved quickly then there might be no spins for Fedora 11. Rahul responded[10] that the original post had been a simple declaration which did not suggest it was merely a proposal. Rahul added[11] that there was a need to clarify the process in order to avoid the confusion of the past.
-[3] http://www.open-mpi.org/papers/ipdps-2006/
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00695.html
-[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00469.html
+[2] http://fedoraproject.org/wiki/SIGs/Spins
-[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00483.html
+[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00782.html
+[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00789.html
+[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00811.html
+[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00826.html
+[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00838.html
+[8] http://fedoraproject.org/wiki/SIGs/Spins_NewProcess
+[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00864.html
+[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00872.html
+[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00874.html

Search