From Fedora Project Wiki

< FWN‎ | Beats

(get JvM wikipage right)
(#160 pass 1, spell checking, some name checking)
Line 7: Line 7:
Contributing Writer: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[OisinFeeley|Oisin Feeley]]


=== The Possible Future of Comps ? ===
=== Fedora 11 Alpha Release Activities ===


[[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.
There was a flurry of activity related to the <code>Fedora 11 Alpha</code> release (scheduled[1] for 2009-02-03). [[DenisLeroy|Denis Leroy]] inquired[2] on 2009-01-21 what had happened to the freeze, originally scheduled for the previous day, and whether all builds in rawhide were queued until after the freeze. [[MamoruTasaka|Mamoru Tasaka]] responded[3] with a link to [[JesseKeating|Jesse Keating's]] explanation[4] that the freeze is a non-blocking freeze which allows targeted fixes to be made.  [[TomLane|Tom Lane]] wanted[5] an "all-clear signal that the alpha tag has been made and we can go back to breaking rawhide ;-)" Jesse created [6] the <code>alpha tag</code> and apologized for slacking on it. He suggested that if many dependencies were going to be broken by Tom's <code>mysql-5.1</code> push that Tom should ask for a <code>koji</code> tag specifically to land it and build all the deps for it before moving it into <code>rawhide</code> itself.[[JoshBoyer|Josh Boyer]] demonstrated[7] how the <code>Koji</code> command-line can be used to answer queries about what tags are present:


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.
<pre>
$koji list-tags -- grep f11-alpha
$koji list-tag-inheritance f11-alpha
</pre>


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.
[[RahulSundaram|Rahul Sundaram]] requested[8] that knowledgeable folks would help build the Release Notes[9] for <code>Fedora 11</code> by adding relevant information to the wiki.  After Rahul got the ball rolling, with some information on the use of <code>ext4</code> as the default filesystem, the experimental provision of the <code>btrfs</code> filesystem and more, [[RichardJones|Richard W.M. Jones]] added information on the <code>MinGW</code> windows cross-compiler and [[Uer:Tmz|Todd Zullinger]] added information about <code>git-1.6</code>.


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]].
The 2009-01-23 Rawhide Report[10] contained some large lists of broken dependencies which were pounced on by the respective developers. As the majority were due to the new <code>MySQL</code> mentioned above [[JesseKeating|Jesse Keating]] asked[11] why his advice to use a special tag had been ignored. [[TomLane|Tom Lane]] replied that there had been no objections when he mooted the idea a week ago and that a non-standard tag would cause more work for affected developers than the current rebuilds. Jesse re-iterated[12] his request to "[p]lease consider using it in the future if you're going to break such a wide array of packages."


[[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."
[[RichardJones|Richard W.M. Jones]] reported[13] problems using <code>yum</code> on <code>Rawhide</code>. [[TomLondon|Tom London]] suggested and [[RichardJones|Richard W.M. Jones]] confirmed[14] that reverting to <code>sqlite-3.6.7-1.fc11.x86.64</code> fixed the problems. It transpired[15] that there was indeed an <code>SQLite</code> bug which was quickly fixed by [[PanuMatilainen|Panu Matilainen]].


[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00733.html
[1] https://fedoraproject.org/wiki/Releases/11/Schedule


[2] http://fedoraproject.org/wiki/FUDCon
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01275.html


[3] http://fedoraproject.org/wiki/PackageMaintainers/CompsXml#How_comps_is_used
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01276.html


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


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


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


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


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


=== New GPG Signing Keys for Each Release ===
[9] https://fedoraproject.org/wiki/Fedora_11_Alpha_release_notes


[[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."
[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01510.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.
[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01510.html


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
[12] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01533.html


[[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."
[13] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01464.html


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


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


[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01020.html
=== Minimalist Root Login to X ? ===


[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01003.html
[[WarrenTogami|Warren Togami]] suggested[1] "mak[ing] root logins from GDM a stripped down desktop with only a terminal and a menu with only configuration tools [and making the desktop] ugly and with a very obvious note explaining why [users] shouldn't be logged in as root."


[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01036.html
"Nodata" was among those who wondered[2] if Warren's use cases "[...] where /home filesystem is full and logins fail, or /home is remote and inaccessible[...]" were anything other than odd edge cases. [[JefSpaleta|Jeff Spaleta]] and [[ChrisAdams|Chris Adams]] expanded[3] upon this line of thought: "[...] if /home is full, can users really not log in? If that is the case, that's broke and should be fixed. The user should be able to log in and remove files."


[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01050.html
The impetus for this discussion may have been another thread which asserted that the denial of root login via <code>GDM</code> on <code>Fedora 10</code> systems made it too difficult to maintain said systems. The thread yielded[4] good examples by [[JudCraft|Jud Craft]] and [[DaveAirlie|Dave Airlie]][5] of arguments that such modifications merely penalized experienced users and failed to enhance security as the users could just login as root on the console anyway. As an aside [[BenjaminLaHaise|Benjamin LaHaise]] brought up the issue that <code>Ctrl+Alt+F2</code> no longer worked. DanHorák explained[6] that "F2-6 are blocked when you have getty running on vt1 (/etc/event.d/tty1 is the same tty[2-6]) and Xorg server runs on vt1 too (gdm runs with --force-active-vt) Then there are messages like `unable to switch vt' in /var/log/Xorg.log. [Such behavior] requires manual editing of at least /etc/event.d/tty1, it should not happen in default setups." [[NicholasMailhot|Nicolas Mailhot]] suggested[7] an imperfect upgrade as another possible cause. A further nugget of information revealed in the thread was as <code>Fedora 10</code> had implemented <code>hiddenmenu</code> as a default in grub it was best to hold down any key once the <code>BIOS</code> had finished the <code>POST</code> routine. [[JesseKeating|Jesse Keating]] suggested[8] the <code>shift</code> key as it typically had no bindings either in <code>BIOS</code> or <code>grub</code>. [[AndrewHaley|Andrew Haley]] pointed out[9] that many of the recent changes were breaking established use patterns. [[KevinKofler|Kevin Kofler]] and [[ChristopherWickert|Christopher Wickert]] suggested[10][11] that anyone who wished to revert to the previous status should just edit <code>/etc/pam.d/gdm</code> to comment out
<pre>
auth required pam_succeed_if.so user != root quiet
</pre>


=== libssl.so.7 Going Through a Bumpy Patch ===
Back in the later thread which sought to deal with some of the difficulties raised above [[TomCallaway|Tom `spot' Callaway]] suggested: "A `Rescue Mode' in GDM which goes to a root session with minimal apps, marked as "Rescue Mode", rather than a root X login (even though it does need root credentials)." [[LyosGeminiNorezel|Lyos Gemini Norezel]] preferred[12] that "[...] the root login should use the user selected interface (gnome, kde, xfce, etc)" but [[MatthewWoehlke|Matthew Woehlke]] emphasized[13] the maintenance benefits of choosing a single Desktop Environment and forcing that as the safe root login.


[[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.
Variations on this topic have been covered previously in FWN#133[14] and FWN#103[15]


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]).
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01387.html


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."
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01542.html


[[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.
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01547.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].
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01300.html


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


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


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


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


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


[6] https://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation
[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01278.html


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


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


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


[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00946.html
[14] http://fedoraproject.org/wiki/FWN/Issue133#Running_As_Root


[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01051.html
[15] http://fedoraproject.org/wiki/FWN/Issue103#Root_Login_And_Display_Managers_In_Rawhide


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


[13] https://fedoraproject.org/wiki/Releases/11/Schedule
[[YaakovNemoy|Yaakov Nemoy]] announced[1] a "[...] respin of Fedora with packages for doing OSM and cartography installed out of the box, or included on a LiveCD and/or LiveUSB. For OSM people, the primary advantage is a live usb stick that can be used at mapping parties to save time cono/guring user computers to do mapping. The USB stick can then be brought home, and the user can continue doing mapping there."


=== MinGW Package Reviews Requested===
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01155.html


[[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.
=== Draft Guidelines for Approving provenpackagers ===


There is apparently no question that the feature, which will allow generation of Windows targets on Fedora, will slip from Fedora 11.
[[JesseKeating|Jesse Keating]] drafted[1] a definition of `provenpackager' (see FWN#151[2)]. [[AlexLancaster|Alex Lancaster]] was worried[3] that too many hoops would mean that maintainers such as himself would lose motivation to continue their work.


[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00793.html
As a subsidiary concern Alex was worried that there were still some packages not being opened up. KevinKofler assured Alex that he would become a `provenpackager' based up his sterling work and Jesse confirmed[4][5] that this redefinition and re-seeding of the `provenpackager' group was in part to address such concerns.


[2] https://fedoraproject.org/wiki/Releases/11/Schedule
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html


[3] https://fedoraproject.org/wiki/Features/Windows_cross_compiler
[2] http://fedoraproject.org/wiki/FWN/Issue151#Security_Exceptions_to_the_Mass_ACL_Opening


=== MySQL 5.1 Coming to Rawhide After Alpha-Freeze ===
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01620.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/msg01629.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/msg01628.html


=== Spins SIG Controversy ===
=== Cloning of Bug Reports ? ===


A vigorous disagreement erupted when [[User:kanarip|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.
[[User:Johannbg|Jóhann B. Guðmundsson]] asked[1] for input, in the form of suggestions and votes, as to whether Bug Hunters (which later seemed to mean testers, but not triagers) should file a separate bug entry for each of: past supported release, current release and rawhide or just annotate a bug for one of the former with a note that it was present in the others.


[[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.
There was general agreement that mailing list votes were ineffective and
unwanted.


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
[[KevinKofler|Kevin Kofler]] objected[2] to the tack taken by Jóhann which seemed to assume an authority over a decision which would affect not just QA, testing and triage teams but also packagers and maintainers. It appeared[3] that the matter would be elevated to FESCo for a decision but as of going to press this had not happened.
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.
[[MarkMcLoughlin|Mark McLoughlin]] suggested[4] a more flexible policy and warned that "[...] you can be sure you'll have maintainers who haven't read or replied to this thread waking up and getting annoyed that they've 3x bug reports to deal with :-)"


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.
[[JesseKeating|Jesse Keating]] argued[5] that the multiple bug-entry option was preferable on four heads: 1) that bugs may have different causes in their releases; 2) users of past releases will not be helped by closing bugs on rawhide; 3) bodhi updates are not pushed at the same time; 4) maintainers are the only people with the knowledge to make such a call.


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


[2] http://fedoraproject.org/wiki/SIGs/Spins
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01423.html


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


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


[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00811.html
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01342.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

Revision as of 02:16, 26 January 2009

Developments

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

Contributing Writer: Oisin Feeley

Fedora 11 Alpha Release Activities

There was a flurry of activity related to the Fedora 11 Alpha release (scheduled[1] for 2009-02-03). Denis Leroy inquired[2] on 2009-01-21 what had happened to the freeze, originally scheduled for the previous day, and whether all builds in rawhide were queued until after the freeze. Mamoru Tasaka responded[3] with a link to Jesse Keating's explanation[4] that the freeze is a non-blocking freeze which allows targeted fixes to be made. Tom Lane wanted[5] an "all-clear signal that the alpha tag has been made and we can go back to breaking rawhide ;-)" Jesse created [6] the alpha tag and apologized for slacking on it. He suggested that if many dependencies were going to be broken by Tom's mysql-5.1 push that Tom should ask for a koji tag specifically to land it and build all the deps for it before moving it into rawhide itself.Josh Boyer demonstrated[7] how the Koji command-line can be used to answer queries about what tags are present:

$koji list-tags -- grep f11-alpha
$koji list-tag-inheritance f11-alpha

Rahul Sundaram requested[8] that knowledgeable folks would help build the Release Notes[9] for Fedora 11 by adding relevant information to the wiki. After Rahul got the ball rolling, with some information on the use of ext4 as the default filesystem, the experimental provision of the btrfs filesystem and more, Richard W.M. Jones added information on the MinGW windows cross-compiler and Todd Zullinger added information about git-1.6.

The 2009-01-23 Rawhide Report[10] contained some large lists of broken dependencies which were pounced on by the respective developers. As the majority were due to the new MySQL mentioned above Jesse Keating asked[11] why his advice to use a special tag had been ignored. Tom Lane replied that there had been no objections when he mooted the idea a week ago and that a non-standard tag would cause more work for affected developers than the current rebuilds. Jesse re-iterated[12] his request to "[p]lease consider using it in the future if you're going to break such a wide array of packages."

Richard W.M. Jones reported[13] problems using yum on Rawhide. Tom London suggested and Richard W.M. Jones confirmed[14] that reverting to sqlite-3.6.7-1.fc11.x86.64 fixed the problems. It transpired[15] that there was indeed an SQLite bug which was quickly fixed by Panu Matilainen.

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

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

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

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

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

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

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

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

[9] https://fedoraproject.org/wiki/Fedora_11_Alpha_release_notes

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

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

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

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

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

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

Minimalist Root Login to X ?

Warren Togami suggested[1] "mak[ing] root logins from GDM a stripped down desktop with only a terminal and a menu with only configuration tools [and making the desktop] ugly and with a very obvious note explaining why [users] shouldn't be logged in as root."

"Nodata" was among those who wondered[2] if Warren's use cases "[...] where /home filesystem is full and logins fail, or /home is remote and inaccessible[...]" were anything other than odd edge cases. Jeff Spaleta and Chris Adams expanded[3] upon this line of thought: "[...] if /home is full, can users really not log in? If that is the case, that's broke and should be fixed. The user should be able to log in and remove files."

The impetus for this discussion may have been another thread which asserted that the denial of root login via GDM on Fedora 10 systems made it too difficult to maintain said systems. The thread yielded[4] good examples by Jud Craft and Dave Airlie[5] of arguments that such modifications merely penalized experienced users and failed to enhance security as the users could just login as root on the console anyway. As an aside Benjamin LaHaise brought up the issue that Ctrl+Alt+F2 no longer worked. DanHorák explained[6] that "F2-6 are blocked when you have getty running on vt1 (/etc/event.d/tty1 is the same tty[2-6]) and Xorg server runs on vt1 too (gdm runs with --force-active-vt) Then there are messages like `unable to switch vt' in /var/log/Xorg.log. [Such behavior] requires manual editing of at least /etc/event.d/tty1, it should not happen in default setups." Nicolas Mailhot suggested[7] an imperfect upgrade as another possible cause. A further nugget of information revealed in the thread was as Fedora 10 had implemented hiddenmenu as a default in grub it was best to hold down any key once the BIOS had finished the POST routine. Jesse Keating suggested[8] the shift key as it typically had no bindings either in BIOS or grub. Andrew Haley pointed out[9] that many of the recent changes were breaking established use patterns. Kevin Kofler and Christopher Wickert suggested[10][11] that anyone who wished to revert to the previous status should just edit /etc/pam.d/gdm to comment out

auth required pam_succeed_if.so user != root quiet

Back in the later thread which sought to deal with some of the difficulties raised above Tom spot' Callaway suggested: "A Rescue Mode' in GDM which goes to a root session with minimal apps, marked as "Rescue Mode", rather than a root X login (even though it does need root credentials)." Lyos Gemini Norezel preferred[12] that "[...] the root login should use the user selected interface (gnome, kde, xfce, etc)" but Matthew Woehlke emphasized[13] the maintenance benefits of choosing a single Desktop Environment and forcing that as the safe root login.

Variations on this topic have been covered previously in FWN#133[14] and FWN#103[15]

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

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

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

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

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

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

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

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

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

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

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

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

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

[14] http://fedoraproject.org/wiki/FWN/Issue133#Running_As_Root

[15] http://fedoraproject.org/wiki/FWN/Issue103#Root_Login_And_Display_Managers_In_Rawhide

Fedora Geo Spin

Yaakov Nemoy announced[1] a "[...] respin of Fedora with packages for doing OSM and cartography installed out of the box, or included on a LiveCD and/or LiveUSB. For OSM people, the primary advantage is a live usb stick that can be used at mapping parties to save time cono/guring user computers to do mapping. The USB stick can then be brought home, and the user can continue doing mapping there."

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

Draft Guidelines for Approving provenpackagers

Jesse Keating drafted[1] a definition of provenpackager' (see FWN#151[2)]. Alex Lancaster was worried[3] that too many hoops would mean that maintainers such as himself would lose motivation to continue their work.

As a subsidiary concern Alex was worried that there were still some packages not being opened up. KevinKofler assured Alex that he would become a provenpackager' based up his sterling work and Jesse confirmed[4][5] that this redefinition and re-seeding of the `provenpackager' group was in part to address such concerns.

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

[2] http://fedoraproject.org/wiki/FWN/Issue151#Security_Exceptions_to_the_Mass_ACL_Opening

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

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

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

Cloning of Bug Reports ?

Jóhann B. Guðmundsson asked[1] for input, in the form of suggestions and votes, as to whether Bug Hunters (which later seemed to mean testers, but not triagers) should file a separate bug entry for each of: past supported release, current release and rawhide or just annotate a bug for one of the former with a note that it was present in the others.

There was general agreement that mailing list votes were ineffective and unwanted.

Kevin Kofler objected[2] to the tack taken by Jóhann which seemed to assume an authority over a decision which would affect not just QA, testing and triage teams but also packagers and maintainers. It appeared[3] that the matter would be elevated to FESCo for a decision but as of going to press this had not happened.

Mark McLoughlin suggested[4] a more flexible policy and warned that "[...] you can be sure you'll have maintainers who haven't read or replied to this thread waking up and getting annoyed that they've 3x bug reports to deal with :-)"

Jesse Keating argued[5] that the multiple bug-entry option was preferable on four heads: 1) that bugs may have different causes in their releases; 2) users of past releases will not be helped by closing bugs on rawhide; 3) bodhi updates are not pushed at the same time; 4) maintainers are the only people with the knowledge to make such a call.

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

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

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

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

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