FWN/Issue103

Fedora Weekly News Issue 103

Welcome to Fedora Weekly News Issue 103 for the week of September 24th. http://fedoraproject.org/wiki/FWN/Issue103

In Announcements, "Cast your vote for the Fedora 8 Codename", "Fedora Unity releases updated Fedora 7 Re-Spins".

After a month-long break, Fedora Weekly News is now back to our regular schedule. Thank you for your patience and support.

To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join.

Announcements

In this section, we cover announcements from various projects.

Contributing Writer: ThomasChung

Cast your vote for the Fedora 8 Codename!

JesseKeating announces in fedora-announce-list[1] ,

"We have two options for the Fedora 8 codename, and you get to help decide which we use! Log in with your Fedora Account name and password. As long as you belong to at least one group in the Fedora Account System, you can cast your vote[2] . Voting will end and be tallied at Oct, 5, 23:59:59 UTC."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-September/msg00003.html

[2] https://admin.fedoraproject.org/voting/vote.cgi

Fedora Unity releases updated Fedora 7 Re-Spins

BobJensen announces in fedora-announce-list[1] ,

"The Fedora Unity Project is proud to announce the release of new ISO Re-Spins (DVD and CD Sets) of Fedora 7. These Re-Spin[2] ISOs are based on Fedora 7 and all updates released as of September 12th, 2007. The ISO images are available for i386 and x86_64 architectures via jigdo starting Friday, September 28th, 2007. We have included CD Image sets for those in the Fedora community that do not have DVD drives or burners available."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-September/msg00004.html

[2] http://spins.fedoraunity.org/

Ask Fedora

In this section, we answer general questions from Fedora community. Send your questions to askfedora@fedoraproject.org and Fedora News Team will bring you answers from the Fedora Developers and Contributors to selected number of questions every week as part of our weekly news report. Please indicate if you do not wish your name and/or email address to be published.

http://fedoraproject.org/wiki/AskFedora

Contributing Writer: RahulSundaram

Compiz-Fusion in Fedora 8

Gideon Mayhak asks,

"I'm writing a brief e-mail regarding the state of Compiz-Fusion in Fedora 8. The current offering is not what I would consider acceptable. Without the libcompizconfig and ccsm packages, Compiz-Fusion is not worth mentioning. The current configuration offering is a joke at best. Can we expect a proper Compiz-Fusion offering soon, or will Fedora 8 end up touting its pseudo-Compiz-Fusion when it's released? It's obviously not a deal breaker, but I don't see why it would be so hard for official package maintainers to build a couple more packages. I know there are people on the Fedora Forums who are packaging these things as they learn how to package, so maybe you could recruit them. I just hope you can ease my mind with news that they're working on it and we'll see the real deal soon."

Fedora 8 is currently under active development and the release notes in the last test release did mention that what was being offered is a preview. They use glib and gconf instead of the other configuration mechanisms you have mentioned although both the GNOME and KDE front ends have been separated to integrate better with the respective desktop environments. compiz-bcop has been introduced into the repository recently and libcompizfusion is waiting on review at https://bugzilla.redhat.com/show_bug.cgi?id=247406.

If you find bugs or want to request enhancements, you can report or request them in http://bugzilla.redhat.com against the relevant packages as usual. If there are interested people willing to participating in maintaining or co-maintaining software in Fedora, you are most welcome to do so. More information at http://fedoraproject.org/wiki/PackageMaintainers. We also need people doing package reviews to ensure the high quality of new packages being introduced in Fedora. Review guidelines are available http://fedoraproject.org/wiki/Packaging/ReviewGuidelines. Reviews can be done by virtually anyone.

Nodoka

Robert Myers asks,

"Is the new Nodoka theme going to be ported to KDE? If not, why isn't it?"

It can be ported as soon as someone with the interest, time and skills show up to do it. Martin Sourada answered more questions on Nodoka including this one in a recent interview available at http://fedoraproject.org/wiki/Interviews/MartinSourada.

Planet Fedora

In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors.

http://fedoraproject.org/wiki/Planet

Contributing Writers: ThomasChung

Ohio Linux Fest

MaxSpevack reports in his blog[1] ,

"We had a great day at Ohio Linux Fest. Jeff did a superb job as the point person for the booth, and it was great to see a bunch of Fedora folks in attendance. Karlie gave a really interesting talk about how FOSS developers pay their bills, and apparently her kids had a good time playing with Seth's OLPC."

[1] http://spevack.livejournal.com/29104.html

[2] http://www.ohiolinux.org/

The Linux Hardware Database

HaraldHoyer reports in his blog[1] ,

"Have you ever tried to find out, if a specific computer device (e.g. laptop, sound card, wireless card) you want to buy, works with Linux? If yes, you know how distributed all the information is over the net. Here is the chance to build a solid, updated database[2] . Over the wekend, I put together a Turbogears web frontend and glued it together with a MoinMoin Wiki. Curious? Try it out!"

[1] http://www.harald-hoyer.de/fedora/the-linux-hardware-database

[2] http://hwdb.surfsite.org/

Fedora 8 + Online Desktop

JonathanRoberts reports in his blog[1] ,

"The third interview in the series of feature previews for F8 has just gone up on the wiki[2] . This time it’s with Colin Walters and he talks about the work that’s gone on to integrate a lot of the Gnome Online Desktop work, particularly Bigboard. This includes the new GDM session that is created after installing the online-desktop package - Online Desktop - where a browser is launched immediately and the top panel is replaced by Bigboard. As always there is also a cool screencast showing some of the coolest features."

[1] http://blog.questionsplease.org/2007/09/30/fedora-8-online-desktop/

[2] http://fedoraproject.org/wiki/Interviews/ColinWalters

Daily Package

In this section, we recap the packages that have been highlighted as a Fedora Daily Package [1] .

[1] http://dailypackage.fedorabook.com/

Contributing Writer: ChrisTyler

Editor's Note: Sorry, no Daily Package has been posted for this week since our editor for this beat is busy with teaching the good kids this semester.

Marketing

In this section, we cover Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: ThomasChung

Customized spins of Fedora

RahulSundaram reports in fedora-marketing-list[1] ,

"When Fedora 7 was released, one of the big features that we talked about was the idea of customized spins of the distribution. Now that Fedora 8 is on the way, it’s useful to look and see how we have done, and what sort of custom spins have been created.[2] "

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-September/msg00192.html

[2] http://www.redhatmagazine.com/2007/09/28/customized-spins-of-fedora/

The 7 Most Influential GNU/Linux Distributions

RahulSundaram reports in fedora-marketing-list[1] ,

"Fedora's main reputation is for being the first distro to include new innovations. For instance, Fedora was the first distribution to include tools that allowed average users to work with SELinux's detailed security options. In the same way, Fedora 7 was the first to include Smolt, a program for collecting hardware information about users; Revisor, a program for creating custom install disks, and the Liberation typefaces that provide the metrical equivalents of Arial, Helvetica, and Times Roman in free fonts. Although some users on Fedora mailing lists suggest that this innovation makes Fedora unsuitable for servers and mission-critical operations, an increased attention to testing is starting to make that generality obsolete. After a slow couple of years, Fedora is also well on the way to realizing its goal of creating a thriving community in which Red Hat is important, but no longer completely dominates decision-making.[2] "

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-September/msg00180.html

[2] http://itmanagement.earthweb.com/entdev/article.php/11070_3701421_1

Visual: Mirrors vs Users

MikeMcGrath reports in fedora-marketing-list[1] ,

"I wrote a little call[2] to help post today as well as a comparison of where our users are vs mirrors. This is using a small sampling of people that have connected to our mirrors site. Not an exact science but interesting none the less, thought I'd share."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-September/msg00173.html

[2] http://mmcgrath.livejournal.com/8797.html

Developments

In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on Fedora Developments.

http://www.redhat.com/mailman/listinfo/fedora-devel-list

Contributing Writer: OisinFeeley

Now that we're back from a break @fedora-devel beat has two sections. This top one is the most recent and covers events from September 23rd to September 29th. The material below it covers a selection of events from earlier activity on the list while we were re-charging our batteries.

RFC: /var or /srv?

CaseyDahlin touched off[1] a wide-ranging discussion about backup and reinstall policies when he suggested that the /srv directory should be populated with data currently in /var/www and /var/ftp/pub as apparently recommended by the FHS[2] .

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01790.html

[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM

The status quo was summed up[3] by JesseKeating, who noted that the FedoraPackagingCommittee had decided that the FHS was contradictory about the uses of /srv and it had thus been decided to leave /srv blank although some packaged applications were writing there.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01791.html

AlanCox argued[4] that Casey's proposal was a bad one for a distribution because updates could result in the removal/modification of files placed there by administrators, which was explicitly prohibited by the FHS. Alan also was very straightforward in stating that /srv was a mistake in the FHS specification, that the FHS in the waning years of its life had created /srv on the basis of a vote conducted by those "who had no clue about distribution building"[5] . Alan recommended that /srv should be obsoleted and the removal of "the silly statements about /var (which mostly exist to try and force the /srv stupidity into being)."

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01806.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01809.html

A response[6] from SethVidal suggested that while Alan had perfectly good points about not using /srv in the distro it was nevertheless widely used (either with that name or another) as a top-level directory to simplify backups. There was substantial agreement on this point from JesseKeating, and DavidCantrell added[7] that although he favored leaving the directory and deciding that packages should not install to it, it was worth considering a limit to the number of top-level directories.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01821.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01833.html

RobCrittenden wondered[8] what Seth meant by saying that /var only contained transient data which did not need backup. Further discussion between NicolasMailhot and RalfCorsepius about the treatment of spools in /var led ArthurPemberton to wonder[9] whether they were describing current practice or what should be done. Scattered throughout the long (over one hundred messages) thread were numerous examples of data contained in /var which it wouldn't be nice to lose. These included mail spools, databases and web server data.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01834.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01853.html

Attempting to draw some sense out of the mass of examples of current practice and competing intents, RichiPlana enumerated[10] four concerns which had emerged as considerations in determining a policy governing the placement of data files.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01870.html

The need to backup efficiently without wasting space and time was raised[11] by MattMiller after IanBurrell pointed out that /var contained a mixture of data that absolutely should be backed-up and other non-important local writable data. LamontPetersen observed[12] that it seemed to be common practice in medium to large-scale enterprises to use the '/srv' directory to separate out the important material. This theme was later re-visited in a slightly acrimonious exchange between NicolasMailhot,LamontPetersen and KrzysztofHalasa. Nicolas made the point[13] , based on his experience, that for enterprise purposes the current use of /var for a mixture of "long-term and transient data, generic and implementation-specific stuff, local and global data" was a problem. Lamont also provided some good ballpark figures[14] to expand the point when Krzyzstof would not accept this portrait of typical enterprise needs. Nicolas explained[15] the typical strategy employed by large enterprises in a further excellent post.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01876.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01882.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02290.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02391.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02423.html

JohannGudmundsson's strong opinion in favor of removing /srv entirely, with the expectation that sysadmins who want it would find their way to the mkdir command prompted[16] a satirical reaction from NicolasMailhot, portraying the possible Fedora config files which could be supplied were this option chosen.

[16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01850.html

A post from RichiPlana in which he volunteered[17] to modify the spec files of either MySQL or Mailman to use /srv instead of /var raised another pair of issues. JohnDennis pointed out[18] that SELinux policies would have to be changed in tandem with the moving around of any files contained in packages. John also noted that there are many applications depending on the current locations and that advanced notice of such changes were necessary.

[17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02191.html

[18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02192.html

A potential way out of this latter difficulty was suggested[19] by KellyMiller(lightsolphoenix) in the form of "compat" packages which create symlinks to the old location. AlexanderBostrom was skeptical that this would be transparent and listed[20] some potential ways in which it could fail, concluding that the release notes would need to explain it, whatever was decided. CaseyDahlin agreed[21] with Alexander that it might be necessary to create a "structure" within /srv/lib, which to some extent mirrored the structuring within /var. He sketched an interesting perspective of /var, which was that it contained information which should be in RAM except for the reasons of size or the need to persist across reboots.

[19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02274.html

[20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02278.html

[21] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02284.html

The former difficulty was addressed[22] by SteveGrubb who confirmed the need for SELinux to be made aware of a mapping between /srv and /var. This led JesseKeating to tie[23] the two problems, pointing out that as /srv was by definition a free-for-all there was no way to prepopulate it without the danger of treading on the toes of the local sysadmin. MattMiller then wondered whether the SELinux tools could be modified to allow the local sysadmin to choose a particular policy for /srv and DanielWalsh responded[24] that it could be done, but would require changing the hardcoded default locations searched by regexes in semanage commands.

[22] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02197.html

[23] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02198.html

[24] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02221.html

LamontPetersen was sanguine about the potential change and rebutted[25] Jesse's worries on all points, essentially pointing out that sticking with the current /var setup had all the problems except the SELinux one, which he asserted was trivial. SteveGrubb countered[26] that although it might be possible to assign the correct SELinux types to directories there would still be per-file problems. RichiPlana asked why it was that the SELinux policies were not set by the installation package and this led to an interesting post[27] from KarlMacMillan, who explained that allowing a package to install a new type and also to install files that should have that new type was a chicken-and-egg problem. The post and responses from Jesse[28] and PanuMatilainen[29] (on whether RPM should/could record file contexts in rpm headers) are probably worth reading.

[25] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02202.html

[26] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02217.html

[27] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02255.html

[28] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02266.html

[29] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02281.html

Finally, there were several[30] [31] scattered suggestions throughout the thread that recognized that the FHS should perhaps be changed and the best policy was to submit patches upstream with regard to the specific issue of /srv.

[30] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02234.html

[31] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02237.html

YUM To Get Configurable Multilib Behavior In Fedora 9 ?

A slightly disturbed SteveGrubb reported[1] that an x86_64 machine with no i386 packages was unwantedly installing i386 packages for NetworkManager during a yum update, but that if yum update NetworkManager.x86_64 or yum update NetworkManager was used then only the desired x86_64 packages were installed. Steve wanted to know if this was a known problem, or if he should file a bugzilla report. SethVidal asked for more detailed information and Steve supplied it, noting that the problem seemed to be that if dhcdbd were deleted by hand then there was no problem, but that if YUM made the deletion then the problem was manifested. JesseKeating quickly surmized that dhcdbd was being obsoleted by both the i386 and x86_64 packages in the repository and Seth confirmed this and suggested[2] that to avoid this problem /etc/yum.conf should have exclude=*.?86 added to it.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01927.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01954.html

Steve still wondered why his exactarch=1 had been ignored and why yum update <packagename> was behaving differently to yum update. Seth replied[3] that obsoletes were allowed to cross architecture boundaries, which provoked further questions[4] from MattMiller concerning the handling of obsoletes when there are potential competitors on either the installed or obsoleting ends.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01961.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01973.html

A suggestion from MichaelWiktowy that anaconda might add Seth's fix to /etc/yum.conf by default along with a concern not to paper over bugs led Seth to respond[5] that there was no bug as YUM was doing exactly what it had been written to do. This provoked DavidWoodhouse to state[6] his concerns with YUM's behavior and to label it as "buggy". David, MattMiller[7] and VilleSkyttä[8] also cautioned that Seth's fix did not work for the situation where the desired state was a 64-bit only system with some small number of specific exceptions.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01956.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01965.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01957.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01967.html

JesseKeating defended[9] YUM's behavior from David's accusation of "bugginess", pointing out that it was implementing exactly the mulitlib strategy which it had been asked to do. VilleSkyttä wanted to know where the strategy was documented and Jesse did his best to describe[10] it. David wasn't buying one of the important conditions of the strategy, namely that "we want both runtime library and development package availability of the secondary arch installed by default" and suggested[11] that exactly the opposite was wanted by users.

[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01970.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02003.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02009.html

A large part of the problem seemed to hinge around RPM's (as opposed to YUM's) inability to use architecture specific dependencies (see also earlier threads[12] ). David was keen to disentangle[13] the problem of the default installation of secondary architecture packages (which he saw as undesirable) from whether multilib[14] should be provided.

[12] http://www.redhat.com/archives/rpm-list/2006-August/msg00011.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02029.html

[14] http://www.redhat.com/magazine/009jul05/features/multilib/

JosVos argued[15] that a plurality of strategies should be enabled through plugins to YUM and Jesse responded[16] that this was exactly the plan for Fedora 9. A plan for a face-to-face meeting with some of the principle architects (SethVidal, BillNottingham, Jesse and David) looked like it was underway[17] for "some time in the future".

[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01987.html

[16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02014.html

[17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02018.html

Rapid NetworkManager Development

MatthewSalzmann provided[1] a nice, compact report of a NetworkManager problem manifested since version 0.7. He had eliminated possible SELinux problems by testing with it set to permissive and reported that several kernels had shown the problem. The wireless chipset was an iwl13945 (see FWN#89 "Status Of Support for IWP3945abg Wireless In Fedora 7"[2] ).

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02151.html

[2] http://fedoraproject.org/wiki/FWN/Issue89#head-3e38c7216e9a44e59750ac3ed823234b9d7178df

Matthew's worry that the problem might be due to user-error was quickly dispelled[3] [4] [5] by a series of similar, confirmatory reports. MattMiller posted a bugzilla entry[5] which seemed to indicate that updating to the latest versions of NM and wpa_supplicant would fix some issues for some people. Unfortunately although Matthew was able to report some progress in terms of the menu appearing the wireless options were grayed out.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02153.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02166.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02168.html

A raft of related, but individual problems were reported in the thread once Jessekeating suggested updating to the latest versions of NetworkManager and wpa_supplicant.

TomLondon reported that although scanning was working properly only hex-keys were being accepted and ZackCerza added[6] that this would be a problem with his AP which only allowed a passphrase to be set. A workaround was suggested by DanWilliams (/usr/sbin/wpa_passphrase <ssid> <passphrase>) which did not impress RalfErtzinger, but produced results[7] for Tom.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02277.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02327.html

A later kernel seemed to work nearly perfectly for Tom[8] and DarrellPfeifer (who was using an iwl3945 but not wpa_supplicant). Matthew reported no success with the latest versions of affected software (NetworkManager*-0.7.0-0.3.svn2907.fc8, wpa_supplicant-0.5.7-9.fc8, kernel-2.6.23-0.213.rc8.git2.fc8) and agreed[10] with Tom that the issue was that if the AP did not broadcast its SSID then the greyed-out menu items rendered the network unusable.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02348.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02347.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02358.html

Matthew then listed[11] his current problems, including an inability to choose the format for entering the passphrase, a tiny non-resizable icon for the passphrase box, and finally greyed-out/inactive menu items for "connect to" and "create new". Matthew concluded by asking for step-by-step instructions to use wpa_supplicant. JesseKeating addressed[12] Matthew's problems, including the information that the UI hadn't been written yet for the greyed-out items and while it might not make Test3 it was hoped to be done by Fedora8 Final.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02375.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02377.html

TomLondon wrote up a nice wpa_supplicant HOWTO which got Matthew finally connected[13] and JeremyKatz noted that VPNC support[14] and the tiny password box dialogue[15] would be fixed in the next build.

[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02393.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02402.html

The overall impression was that NetworkManager and associated tools are going through a lot of needed changes and that flakiness abounded as did the rapid fixing of bugs. KevinKofler queried[15] the strategy behind this.

[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02194.html

System Entries In /etc/hosts

HarryHoffman asked[1] when the hostname had stopped being added by default to /etc/hosts. His concern was that mail sent by applications via a mail host should have an address from "root@myhost.com" instead of "root@localhost.com".

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02222.html

DavidCantrell took the bullet[2] , suspecting that he had made the change by mistake while rewriting the guts of anaconda, he noted that he had fixed this rawhide in and provided a bugzilla link. Almost immediately SimoSorce begged him to reconsider as Kerberos would break if the hostname did not reflect the public-facing IP address. David then suggested[3] that the best course of action was to defer the change until after Fedora 8 had been released. Harry took David's recommendation and mused out loud[4] that his particular problem was best solved by configuring his local MTA to use the FQDN.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02225.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02228.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02229.html

Meanwhile AdamJackson(ajax) reacted[5] to Simo's suggestion that GNOME needed to be smarter about changing the hostname mapping when the main network interface got an IP by suggesting that if it were true that Kerberos/winbindd broke this way then they were buggy. AlexanderBostrom admitted that he wasn't sure what happened in these situations (which he had observed) but believed[6] that if a hostname were mapped to 127.0.0.1 in /etc/hosts then DNS would be over-ridden and Kerberos duly upset.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02247.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02317.html

A spate of testimonies followed from those who had no Kerberos problems while the hostname was mapped to 127.0.0.1 in /etc/hosts. JesseKeating thought[7] that expecting DNS-resolvable hostnames was dated thinking. LamontPeterson argued[8] that the /etc/hosts file was merely to enable the box to resolve itself without respect to the network so that daemons depending on the hostname in their configurations would not be confused.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02319.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02344.html

SimoSorce responded[9] that this would cause problems for a KDC and that he agreed with Lamont's interpretation of /etc/hosts as long as dhclient or the network-config tools could enter the correct hostname to IP mapping. Lamont thought[10] that the KDC point was obvious, but that what was being discussed was laptop clients.

[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02350.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02372.html

RPMFusion Spin

The need for an RPMFusion spin was expressed[1] by JóhannGuðmundsson. It was phrased in a confrontational style, wondering whether "MaxSpevack [would] put his money where [h] is mouth is" and allow the spin to be hosted on fedoraprojects.org. Simultaneously the post implicitly admitted knowledge the presence of legal problems and the need to host any such project outside of the USA. Jóhann expressed an interest in seeing whether there were more downloads of the spin than of "Fedora".

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02294.html

HansdeGoede made it clear[2] that this was not a post made on behalf of the RPMFusion project.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02297.html

The initial response from JesseKeating answered[3] negatively the suggestion that the spin could include Fedora artwork or the name. Jesse also addressed the quote from MaxSpevack, pointing out that remixing Fedora implied a lot more than the uninteresting project of adding a few patent-encumbered packages and producing a work which was not free for /everybody/.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02300.html

JoshBoyer answered some later questions, and confirmed[4] that the hypothetical spin would be allowed to pull from the Fedora Project's repositories, explained that it would not be possible to host even a GPL licensed package which implemented a patented technique and reminded that the "media problem" is not one solvable by the Fedora Project.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02306.html

Further discussion unearthed[5] the information (from MattDomsch and NicuBuculei) that the replacement of the artwork would not be necessary apart from the trademarked logos due to recent work, and that work has been done to provide non-logoed graphics to facilitate this sort of derivative.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02310.html

RahulSundaram[6] and BillNottingham[7] also pointed Johann towards the generic-logos package in rawhide which is intended precisely to allow easier rebranding by derivative distributions.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02311.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02320.html

Based on the answers received, Johann asked whether the FedoraUnity respins could be hosted on fedoraproject.org and MikeMcGrath supplied[8] a link to the current process-in-progress. Johann felt that these should be given pride of place as they would save users a lot of downloading of updates. JesseKeating expressed[9] admiration for the respins but also cautioned that they should not replace the gold images because they hadn't gone through the same QA. Jesse further suggested that with a six-month release schedule it was hard to see where the resources would come from to do such QA. JeroenvanMeeuwen(kanarip) was skeptical[10] that the spins would be blessed because of their respin tool being unapproved by ReleaseEngineering.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02330.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02334.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02337.html

Johann then posted[11] a critique of how it seemed that the hosting of spins would be handled, advocating a completely unreviewed, hands-off provision of space for anyone that wanted to do anything. Reaction was unfavorable and ranged from SethVidal's threat to create a FedoraPr0n respin[12] to MikeMcGrath's observation[13] that the most interesting spins would come from countries with different laws and that they would not be called Fedora.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02351.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02359.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02363.html

Much later in the thread DouglasMcClendon posed[14] a hypothetical way of evading the intent of the Trademark guidelines (by creating an initrd) which elicited a long subthread of legal supposition. Rahul also explained contributory infringement and other problems in response to a demand[15] for a definitive settling of accounts from Johann.

[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02394.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02383.html

Mock Builds Of Rawhide

MattDomsch posted[1] the results of the Fedora Rawhide-in-Mock x86_64 build with a list of 431 packages failing to build without a bug filed.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02100.html

TomLane thought[2] that Matt was using a broken compiler based on the reported failure of the MySQL builds.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02108.html

The results[3] for the Fedora Rawhide-in-Mock i386 builds were similar with 433 out of 4740 packages failing to build with no bug filed. BojanSmojver noted[4] the mock problem in resolving the localhost.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02101.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02107.html

A discrepancy between the lists provided and the individual logs for mod_perl was observed by JoeOrton and Matt explained[5] that since providing the lists he had re-run the failures overnight, some of which were now resolved.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02140.html

JesseKeating was curious as to whether Matt's build set included the latest glibc which should include warnings about potential buffer overflows in C++ applications due to D_FORTIFY_SOURCE{,=2} being enabled. The good news[7] was that there were no additional warnings/failed-builds due to this.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02141.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02216.html

Updates Busted. Bodhi Fixed.

On Tuesday 25th September ThomasBaker asked[1] whether the Fedora 7 updates had gone down again. LukeMacken explained[2] that memory issues were being manifested during the composition of the repository and that he intended to write some sanity checks into Bodhi's masher.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02095.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02109.html

BojanSmojver saw[3] an opportunity (to grab the latest kernel) instead of a problem.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02117.html

A problem still appeared[4] to exist on Wednesday 26th according to BrunoWolff as he reported that updates were still missing although files were present.

OpenGL Wrapper Preparation for Games Live DVD

HansdeGoede continued his pleasant practice of announcing exciting new respins by asking[1] maintainers of OpenGL-using games to start using a wrapper he had created. The wrapper is a bash script which checks for DRI availability and upon failure pops up an error dialogue with which it is simple to interact.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02055.html

The point of including OpenGL games, but not propietary drivers on the DVD was questioned[2] by GérardMilmeister and DebarshiRay(rishi) happily answered that it would provide a nice means of testing new computers for available, quality FL/OSS drivers. RichiPlana quipped[3] that maybe it should be renamed "3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors" and JefSpaleta embraced[4] that idea: "that is the WHOLE point. This is what Fedora IS, as a project it is focused completely and utterly on the open source software stack. We aren't sugar coating it or hiding the fact that video driver coverage is a problem, by slipping users proprietary pills. Video driver coverage IS a problem, its a problem that needs to be stressed and not covered over in a very shallow and vain attempt to boost our distribution numbers by sneaking in addon drivers we don't support as a project."

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02058.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02082.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02084.html

Although it was hoped that the pre-5xx series ATI Radeon cards would all work perfectly NilsPhillipsen was able to highlight[5] one non-working example, leaving Intel as the current sole contender although the situation is expected to change in the near future.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02339.html

JochenSchmitt reported[6] that although he could run stellarium with the rpm.livna.org supplied nvidia driver the wrapper erroneously reported that DRI was disabled. Hans requested some moe data to fix the problem.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02081.html

Kmod (Kernel Module) Packages No Longer Permitted

A long-expected and debated announcement of the removal of kmods from Fedora was posted[1] by TomCallaway.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01949.html

DennisLeroy pointed[2] out that it was ironic that VMware were opening up their tools just now and that Fedora might be left without them while Ubuntu and Gentoo worked out of the box. His post included a link[3] to a bugzilla where Open-VM-tools was discussed extensively.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01968.html

[3] https://bugzilla.redhat.com/show_bug.cgi?id=294341

It seemed clear from the comments on the bugzilla review that the kernel hackers were convinced that significant parts of the code were never going to be accepted upstream and so would not be carried by Fedora. Denis wanted to know how open-vm-tools could be incorporated into Fedora and Jesse suggested[4] that he post to the fedora-kernel list. DaveJones thought this was pointless and Denis responded[5] that he knew this.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01971.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02041.html

DavidWoodhouse speculated[6] that due to the massive changes indicated in the review it was far from likely that FESCo would have voted for open-vm-tools as a package regardless of the new rules on kmods.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01982.html

Tickless x86_64 Kernels

After installing PowerTOP[1] AhmedKamal wanted[2] to install a tickless kernel so that he follow the most promising path to reducing power usage on his laptop. Ahmed wondered if he needed a patched version of the kernel to enable hpet timers for his ICH6 chipset.

[1] http://www.linuxpowertop.org/

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01924.html

A response[3] from JoshBoyer wondered where Ahmed had obtained his kernel (2.6.22.4-45_1.cubbi_suspend2.fc6) and suggested that if he were running x86_64 then his best bet for a tickless kernel was to upgrade to Fedora 8. ChristopherBrown confirmed[4] that this was the case.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01926.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01937.html

All was not well, however, because Ahmed reported[5] that the hpet force-enable patch was still needed because the BIOS on his laptop was disabling hpet. He asked whether Fedora 8 would contain that patch.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01942.html

The following @fedora-development summaries cover a period stretching from Aug 21st to September 22nd with an emphasis on more recent material.

Graphical Shutdown?

JonathanRoberts wondered[1] if it would be possible to have a less ugly means of shutting down Fedora 8.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01302.html

The idea was warmly received[2] by AdamJackson(ajax), although he admitted to not having looked into it yet and thought it might be too late for Fedora 8. Adam advanced a rough model in which the X session would be able to stay up until the computer halted. DavidWoodhouse agreed that X didn't need to save state and pointed out[3] that probably nothing else needed to either. He described what seemed like a fairly brutal method of shutdown sync; reboot -f or SysRq-S-U-B as his preferred speedy method of shutting down.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01367.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01369.html

There was a good deal of agreement that David was right, with the exception[4] that unmounting filesystems could be a problem.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01406.html

ColinWalters provided[5] a link to the thinking of Ubuntu developers about the same problem and reminded the list that most of the services needing special handling on shutdown were server services usually unused in the desktop scenario.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01401.html

A request for clarification was made by RichiPlana and JesseKeating answered with a succinct explanation[6] of the problem/opportunity as being that a system shutdown would kill the PID of running services without going through the usual service script rigmarole of displaying information to the console and then killing the PID.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01408.html

A possible problem with Samba, and with recovering databases was identified[7] by SimoSorce and echoed[8] by ChrisAdams.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01463.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01476.html

util-linux Missing From Build Root

GérardMilmeister pointed out[1] that in addition to "awk" being absent from the buildroot, "util-linux" was not there either, and JindrichNovy found[2] that this meant that /bin/kill was unavailable.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02019.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02021.html

JesseKeating[3] and RichardJones[4] explained that "util-linux" had become "util-linux-ng" and needed to be explicitly BuildRequire'd.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02025.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02023.html

This prompted MichaelSchwendt to lament the death of the minimal build environment and JesseKeating to dispute[5] this with the assertion that the buildroot packages were the same and anything depsolved from there should never have been relied upon. Michael explained[6] that he felt that having to BuildRequire packages which should be included in the buildroot was not a good thing and Jesse pointed[7] out his previous invitation to discuss the growth of the base packages. He noted that dependency chains change and that the list of installed packages was provided. Michael responded[8] that the bureaucratic burden was too high and wondered why the list had changed.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02036.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02041.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02042.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02049.html

MikeMcGrath corrected[9] this by noting the difference between the explicit list (which had not been changed and would require FESCo approval) and the implicit list (of dependencies dragged in in the past). This angered[10] RichardJones who felt it was rude, hence offputting to outside developers essential to Fedora's growth. PatriceDumas smoothed the situation over[11] , explaining that following the guidelines wasn't just arbitrary and unimportant, but provided a means of making sure the buildroot installation was faster.

[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02051.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02103.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02110.html

After Jesse accused[12] Michael of "whining" about the situation instead of coming up with a solution, Michael was moved[13] to suggest merging the old minimal(explicit) list and the expanded(implicit) list.

[12] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02053.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02054.html

Michael wondered[14] how, without a full list, it was possible to check whether a BuildRequires would be installed implicitly. Ralf responded[15] that the problem was due to using a list of packages instead of a list of applications and libraries.

[14] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02061.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02084.html

NicolasMailhot and MichaelSchwendt debated this point for some time with Nicholas advocating[16] Requires and BuildRequires which explicitly named the absolute pathnames of required tools instead of packages which contain them. Michael concluded[17] that many single files would have to be be BuildRequired and that a well-defined base environment would be easier.

[16] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02125.html

[17] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02161.html

SethVidal wondered[18] whether it would be possible to use yum to resolve a list of required libraries and applications, but had to admit that it couldn't be expressed as a comps group.

[18] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02157.html

Michael argued[19] that it would be necessary to use mock, or else many scratch builds in Koji, to figure out the list of new BuildRequires.

[19] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02162.html

Proposed Buildsys-build Group Changes

Following on from the discussion of the minimal buildroot (see this same FWN#103 "util-linux Missing From BuildRoot"), JesseKeating requested[1] feedback on a proposal to add some packages to the Explicit list of packages guaranteed to be in the buildroot. Jesse noted that he'd also asked SethVidal to provide a yum-based utility which would show what packages would be installed implicitly by the minimal build root.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02226.html

Seth wanted to know what the desired output from the tool would be and Jesse opened[2] the question up for input.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02232.html

PatriceDumas spotted some glaring omissions and Jesse responded[3] that they were pulled in via rpm-build, but that it was a good idea to list them. TomasMraz found it a little weird that binutils, glibc-devel, glibc-headers and kernel-headers would now need an explicit BuildRequire. PatriceDumas replied[4] that kernel-headers should never be needed explicitly and that glibc-headers would be brought in with glibc-devel.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02333.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02262.html

TillMaas thought[5] that the full exception list needed to be revived as otherwise it would not be possible to make sure BuildRequires were fully provided for in the spec by rebuilding in mock.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02260.html

RPM Fusion

HansdeGoede announced[1] that three previously separate RPM repositories: Dribble, FreshRPMS and Livna had agreed to join their efforts into one common project. This would provide two repositories: Free; and non-Free with the latter containing Open Source Software non-distributable in the USA due to possible patent problems. No replacements of packages in RHEL/CentOS, EPEL or Fedora will be carried, only add-ons including kmods.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00750.html

Congratulations, good-wishes and thanks rolled in, with a dominant theme of sadness that ATrpms was not going to be part of the effort. JarodWilson expressed[2] the opinion that most conflicts occurred between ATrpms and Livna. ChristopherBrown reminded[3] him that it was still an incremental improvement and that one major source of conflict (nVidia drivers) may soon disappear.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00850.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00852.html

An interesting perspective was provided[4] by CaseyDahlin when he described the ATrpms repository as more of a "service pack" than a collection of applications. Casey was at pains to point out that he wasn't diminishing the service which ATrpms provides. WarrenTogami agreed and wondered[5] if it might even be described as a fork of the Fedora distribution. RichiPlana was in agreement on the positive value provided by ATrpms (availability of packages for MythTV and Asterisk and the ability to install library versions in parallel easily), but wondered about the conflict in package namespace with original Fedora packages.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00833.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00834.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00848.html

ChristopherStone posted a link to an announcement[7] from Thorsten which seemed likely to squash this hope though.

[7] http://lists.fedoraunity.org/pipermail/repo-merge-discussion/2007-May/000137.html

Attention was drawn to the split between Free/non-Free when RahulSundaram thanked RPMFusion for it and hoped that Fedora would thus be able to link to the Free part. KevinKofler was dubious[8] about this because of the patent-encumbrance issue and JesseKeating also doubted it, as the ability to reference (link) to such a repository seemed to imply that just packaging the material in the Fedora Project repositories would also be legal (which no one argues). A longish thread developed in which Rahul stated[9] that referencing, linking or pointing-to such packages is legally different from including them. This had been discussed at length at the Fedora Advisory Board (see FWN#99 "FESCo Approves CodecBuddy"[10] ).

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00835.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00840.html

[10] http://fedoraproject.org/wiki/FWN/Issue99#head-8f0c339b91cb83b8c9626974b6ec53d3b19f64b9

The legal situation was frustrating to many participants who sought creative technical ways to solve the problem. JeroenvanMeeuwen went back and forth with Rahul over including yum repo configuration files which he believed must have the same legal status as linking to the information contained in them. Rahul asserted[11] the difference between these two actions and suggested again that anyone interested read the FAB discussions. RichiPlana thought that he finally understood the legal distinction to be that documents could point to places to get such packages, but that a configuration file to allow downloading them was illegal. But Rahul replied[12] that the legal situation used to be that even pointing in documents to a website which hosted a repository of contentious material was not allowed, but that the situation had changed (due to the Microsoft vs. AT&T case). This had been discussed[13] on the FAB list.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00936.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01006.html

[13] https://www.redhat.com/archives/fedora-advisory-board/2007-July/msg00032.html

TomCallaway (spot) put it plainly[14] when he explained "contributory infringement", which doesn't seem to leave much wiggle room. Tom also passed[15] on to Red Hat lawyers the question raised by Rahul of exactly what sort of information could be included on a linked page.

[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00959.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01041.html

LesMikesell suggested moving the repository out of the USA, but Tom (as the new Fedora Legal contact) quashed that notion by pointing out that the problem was where Red Hat was based, not the repository[16] . CaseyDahlin mooted[17] a solution similar to a bit-torrent tracker, but Tom had to regretfully respond that it would almost certainly be contributory infringement. KingInuYasha was led to rant[18] about the awfulness of software patents and to wonder how on earth the problem could be fixed.

[16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00913.html

[17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00991.html

[18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00997.html

An inquiry about how packagers can join RPMFusion was made[19] by KellyMiller (lightsolphoenix) and HansdeGoede responded[20] with the subscription address and the information that the review procedure would only differ from Fedora's in using blocker bugs instead of flags (subject to discussion).

[19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01056.html

[20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01113.html

Other suggestions in the thread included registering both fedora.us and fedora.eu and hoping that users would find their way by word-of-mouth/Google to the .eu site which would contain contested software, or to providing a repository which contained packages which would configure yum to look at a repository containing the contested software. Neither gained much traction.

Root Login And Display Managers In Rawhide

A mammoth thread was initiated[1] by RahulSundaram when he requested that all display managers follow the pattern set by GDM, which disallows root logins.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01483.html

PatriceDumas thought that PAM might provide a way to do this and TomasMraz agreed[2] that auth required pam_succeed_if.so user!=root quiet would work. This suggestion worried BernardoInnocenti as it seemed as though it would also prevent ssh and console root logins on a server which ordinarily would not have any non-root accounts. SimoSorce replied[3] that the directive could be put into the specific /etc/pam.d/ configuration file instead of the univeral /etc/pam.conf.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01485.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01492.html

The issue of the normality and sanity of such set-ups was raised fairly forcibly at several points. The first strong objection was by AlanCox who pointed out[4] that if one were using networked authentication schemes, e.g. LDAP or NIS, and these fail then there would be no chance of recovery if root logins were disallowed. MattMiller drew[5] on his experience at Boston University to suggest that root logins could be allowed to a restricted custom rescue desktop workspace providing, for example, a terminal and system-config-users and nothing else. This idea struck Alan and others favorably, with RichiPlana highlighting[6] the problem of ordinary GNOME/KDE sessions granting root privileges to myriad daemons of uncertain[7] code quality.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01514.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01532.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01646.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01664.html

SimoSorce added[8] , in response to Alan, that the proposal was merely to disable root login via GDM, not via console or SSH and RahulSundaram confirmed[9] this separately in answer to RexDieter's direct question. Rahul also noted that users wishing to ignore the proposed safeguard could always override this default. DenisLeroy took issue[10] with the idea that root login via a display manager was abnormal. He also wondered whether there would be a simple anaconda option to enable root login via DM as it would seem to be impossible to run gdmsetup without root access. Rahul didn't accept this argument and explained[11] how gdmsetup could be run even when root-login via DM was disallowed.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01576.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01516.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01519.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01528.html

A certain amount of confusion ensued when Denis replied that non-root user creation was not mandatory in anaconda, and explained[12] that he was trying to avoid a scenario where after a successful X installation it would become impossible to log onto the system. Denis suggested that anaconda should allow root logins if no other users were created during installation. The confusion arose when AlanCox understood[13] Denis to be saying that anaconda should make non-root user creation mandatory. Alan explained again that single-sign-on, LDAP, NIS, YP made the creation of non-root users meaningless. A second source of confusion was generated when he added that the security argument was flawed because all one had to do was Ctrl-Alt-F1 and login as root at the console. RuiMiguelSilvaSeabra replied[14] that this was not the security concern, which was rather that GUIs tended to have large amounts of buggy code and running them as root was a risk.

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

[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01537.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01719.html

After Rahul suggested that Denis file an RFE requesting that anaconda enforce the mandatory creation of a non-root user Alan responded[15] with a request to be kept advised of this so that he could file a "violent disagreement". JesseKeating made a proposal[16] which seemed to work around the problem.

[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01538.html

[16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01550.html

ColinWaters argued[17] that this was a change only to the Desktop Live image in order to improve the experience for creative users who would be installing only on a laptop or home PC. Colin reminded Alan that the traditional "choose your own adventure" DVD would be untouched.

[17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01548.html

An attempt[18] by Alan to pinpoint his heartfelt disagreement emphasized that he thought that "If [the user has] not ticked any of ldap, nis [during installation] .. then its a very good idea to be extremely clear to the user that they want a non root account." Colin responded[19] that remote authentication shouldn't even be a consideration as this spin was targetted at home users' laptops and that anyone wanting to set up a lab could use the DVD and kickstart. Things heated up when Alan then attempted to "insert clue"[20] with the information that he didn't want to download multiple media in order to cover both his laptop and desktops. Colin stuck to his guns and offered[21] sympathy to Alan for running an enterpise network, the information that only the boot.iso would be needed (instead of the whole DVD), and a link to the Fedora 7 install guide.

[18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01553.html

[19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01557.html

[20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01565.html

[21] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01569.html

JohannGudmundsson agreed with Alan that too many options and too many variants of install media would be a problem[22] and this was amplified[23] by RudolfKastl who noted the support burden which might be incurred.

[22] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01597.html

[23] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01861.html

After DenisLeroy suggested[24] the Desktop SIG driving the changes must have little experience with real-world GNU/Linux deployments and should consult with RHEL customers MatthiasClasen tried[25] to stop the thread hitting rock-bottom. This didn't entirely succeed as when Rahul reminded the list that the discussion was solely for the Desktop spin MattMiller floated the idea that this was the deliberate introduction of a feature which would be unacceptable to RHEL customers, thus forcing them towards purchasing RHEL. Matt later recanted[26] slightly and made a different point, namely that "features" deprecated by RHEL customers might also be ones which Fedora users would not like.

[24] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01542.html

[25] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01545.html

[26] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01573.html

Rahul's request to discuss the (de)merits of the proposal for the Desktop spin without reference to RHEL led RalfCorsepius to argue[27] that the Desktop spin itself was the bad idea. Ralf further disputed that Fedora and RHEL had different audiences citing the existence of EPEL as evidence. A thread then developed where Rahul contrasted Fedora/RHEL roles, while Ralf compared their installation similarities. Ralf argued that the only significant differences were non-technical and included support contracts, longevity, and the "non-free"[28] nature of RHEL. This latter point was disputed by, among others, Rahul and in turn Ralf accused[29] him of "spreading vile propaganda". The general reaction was that this was incivil and inaccurate. JesseKeating noted[30] that although there was some non-free software available to RHEL customers it was not part of the distribution.

[27] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01606.html

[28] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01706.html

[29] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01711.html

[30] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01727.html

PatriceDumas thought[31] that Rahul was over-stating the differences between Fedora rawhide and CentOS, leaving aside update policy and lifecycle, and also wondered if Ralf were talking about the use of OpenMotif (whose licensing is not OSI approved). Further discussion with Patrice and Ralf led Rahul to expand[32] on the point that there were both technical differences and different audiences for the distributions.

[31] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01716.html

[32] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01745.html

Xulrunner

A note[1] from JesseKeating cautioned that the appearance of a build of xulrunner in the Fedora 8 buildroot was premature do to outstanding issues including lack of ppc64 support and not matching the Firefox build. The build was the first appearance and could therefore be made unavailable by untagging it.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01588.html

DavidWoodhouse was startled[2] by the ppc(64) mention as it should all JustWork and asked what, if anything, he needed to do. JeremyKatz helpfully remembered[3] ChrisopherAillon mentioning missing Firefox ppc pieces in the upstream Xulrunner trunk. David was sagnuine that an existing patch for ppc64 should work and asked to be poked[4] if it didn't. Further investigation allowed him to declare[5] that the problem was in "xptc" (part of XPCOM[6] ) and that although the build still failed it could be seen to be non ppc64 specific.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01589.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01591.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01594.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01627.html

[6] http://developer.mozilla.org/en/docs/XPCOM

TomCallaway pointed out[7] that the error also occurred with x86_64 and appeared to be a GCC bug for C++ and JakubJelinek confirmed[8] this and assigned a GCC bug[9] to himself.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01666.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01668.html

[9] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33506

JesseKeating posted[10] that ChristopherAillon had used an ExcludeArch with no comments or changelog entry, but the cvslog entry from him noted that xptcall might be missing on ppc64. DavidWoodhouse wondered[11] when the "ExcludeArch must have bug filed rule (see FWN#90 "Fedora Secondary Architectures Proposal"[12] ) was going to be enforced and also clarified that contrary to the cvslog supposition the xptcall stubs had been implemented for a while on ppc64. David declined Jesse's invitation to code up a means of "enforcing" the rule.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01593.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01596.html

[12] http://fedoraproject.org/wiki/FWN/Issue90#head-271f52b8e5603cd40d00d7c44ec8632cae42b1aa

PlanetCCRMA Packages For Audio Creation To Be Integrated

Some good news[1] was announced by HansdeGoede. He had been planning with PlanetCCRMA's[2] FernandoLopez-Lezcano to improve the audio creation experience in Fedora by taking the existing PlanetCCRMA packages and modifying them to meet the FedoraPackagingGuidelines.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01421.html

[2] http://ccrma.stanford.edu/planetccrma/software/

The method by which this will happen is outlined at the wiki page for the Audio Creation SIG[3] , and boils down to Fedora contributors identifying interesting SRPMS at PlanetCCRMA, whipping the spec files into shape and then submitting them for review while CCing Fernando.

[3] http://fedoraproject.org/wiki/SIGs/AudioCreation

There were several early takers including NicolasChauvet (kwizart) who had already[4] submitted "jack-rack" for review and also volunteered to act as a reviewer. RichiPlana was interested[5] in whether the SIG was solely going to integrate PlanetCCRMA packages (and hence should change its title) or was going to address other audio-creation issues in the future. Hans replied that for the immediate present work would focus on using the pre-existing CCRMA packages, but that the future was open to other activities.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01426.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01429.html

Richi wanted some further guidance as to which packages needed attention and where interested contributors might find the SRPMS. Fernando replied[6] with that information and also some great background on the history of CCRMA. Following up on that Richi had some more questions[7] about the potential of accumulating differences between Fedora curated packages and PlanetCCRMA's packages, and also about the need for a low latency kernel.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01635.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01640.html

According to Fernando[8] a low-latency kernel is not essential to run any of the packages, although it is desirable for live performance situations. Fernando noted that IngoMolnar's work on realtime pre-emption won't be in the mainline kernel anytime soon and wondered what Richi meant about "kmods" (see FWN#99 "Kmods Clarified"[9] ).

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01679.html

[9] http://fedoraproject.org/wiki/FWN/Issue99#head-98170522fb95c1c25efc05a5f2f6367656a7f174

Possibly Orphaned Lftp Spawns Bug Squad!

An angry plea[1] from AlainPortal requested that the lftp package should be orphaned because the maintainer MarosBarabas was not tracking upstream releases and had left the package at an early version (3.5.10) despite despite a request from Alain to update to a new release and three subsequent upstream changes. The bugzilla entry contained[2] a mix of frustrated speculation as to why this had not happened.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01192.html

[2] https://bugzilla.redhat.com/show_bug.cgi?id=242112

When RichiPlana asked how packages get orphaned and how he might pick one up for maintenance he was supplied with the necessary links by RahulSundaram[3] and JefSpaleta[4] .

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01202.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01272.html

Rahul recommended that Alain follow the AWOL policy and after thanking him for the information Alain wondered[5] whether he could skip some steps due to the age of his bugzilla request which was some months old and awaiting response from the maintainer. Alain expressed willingness to attempt to maintain the package, but also doubt as to his ability. HansdeGoede responded with a generous and open invitation to help with any C programming problems and encouraged[6] Alain or anyone else to contact him with such C problems.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01199.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01210.html

JeffSpaleta floated[7] the idea of a larger "broken code response group" where those skilled in programming areas could help out the less skilled. This idea seemed very popular and several people volunteered (possibly stimulated by the idea of tshirts!). Hans then wondered[8] whether creating a specific mailing list for the purpose of stimulating packagers to send out help requests would be useful. There seemed to be general agreement that it would be better than overwhelming @fedora-devel and Jef also suggested[9] enhancing bugzilla to allow the bug owner to set a flag requesting help from the code squad (whose members had swelled by this time to include JonCisela, RichiPlana, PaulFrields, HansdeGoede, DenisLeroy and JesseKeating).

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01213.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01221.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01231.html

The positive, productive note of the thread was continued when Alain committed to maintaining the package if no response was heard in 72 hours and JeremyKatz noted[10] that this was a very short timeframe over a weekend and did a "side channel ping" to alert the maintainer. MattMiller agreed[11] that this timeframe was a bit hasty and also pointed out that although the release version numbers had increased it did not look as though anything very important was changing between releases. ChristopherBrown disagreed[12] that this was a reasonable maintenance strategy as "bugs are bugs".

[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01240.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01252.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01260.html

Subsequently the bugzilla entry showed that the maintainer was dealing with the issue and wasn't using age of a bug as the criterion of importance.

Disable IPv6 By Default

A surprisingly good thread resulted from JohannGudmundsson suggestion[1] that as IPv6 uptake had been slow it would be better to disable it in Fedora by default.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01024.html

One group of posters wondered what exactly was the point of disabling IPv6. ChuckAnderson asked[2] what specific problem was being solved and thought that the chicken-and-egg nature of deploying IPv6 meant that Fedora was to be applauded for being proactive and DennisGilmore was a satisfied IPv6 user who wondered[3] why he should have to jump through extra hoops when no harm was caused by having both IPv4 and IPv6 enabled. Johann responded[4] that it was a "waste of time and resources" and JohnReiser commented[5] that recommended security policy was to turn off all unused services. He added that several dozen pages of RAM were wasted if it was not used and suggested adding alias net-pf-10 off to /etc/modprobe.conf.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01025.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01028.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01030.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01037.html

DennisGilmore pressed Johann for further proof of the exact resource burden and security threat and also informed[6] him that the contractors to the government of the USA were mandated to use IPv6 by 2008. Johann was unimpressed with the needs of the USA and provided no exact figures on the resources used, this was followed by PeterRobinson providing[6] a crude estimate of a mere 312KB RAM and also the information that MacOSX, Vista, Server2008 and others all supported IPv6 out of the box and that the EU and Asia were using IPv6 (separately DennisGilmore noted that Asia was one of the largest IPv6 users).

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01048.html

Earlier in the conversation RichiPlana suggested that disabling IPv6 should be made a simple one-step process and asked[7] how he could do this. Interestingly, throughout the thread there were a variety of solutions offered: JohnReiser's solution above; ThomasSteenholdt's[8] install ipv6 /bin/true in /etc/modprobe.conf followed by chkconfig ip6tables off followed by a reboot; TillMaas's[9] IPV6INIT=no in /etc/sysconfig/network (which Till reported as failing in FC6). The variety of these responses indicated that Richi was onto something. DavidWoodhouse made an amusing suggestion[10] of echo blacklist ipv6 > /etc/modprobe.d/luddite. Further discussion led to Richi posting[10] a link which explained things clearly.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01043.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01298.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01122.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01080.html

In another part of the discussion DavidWoodhouse explained[11] how to get IPv6 connectivity using tunnel brokers even if one only has an IPv4 public address.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01301.html

ColinWalters overview[12] of the thread was that the wrong question (should IPv6 be disabled) was being asked and instead it should be what specific bugs need to be fixed if it is to be enabled. This resonated[13] with DavidCantrell who had said[14] earlier that it was a pain working with IPv6 due to so many Fedora users being afraid of it. He commented that the module could be blacklisted by those that wanted to disable it but that users shouldn't be bothered with something which should just work.

[12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01074.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01079.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01031.html

After RichiPlana outlined[15] a plan to modify system-config-network to disable IPv6 but leave it on by default, Johann reminded[16] the list that the discussion topic was whether and how to disable IPv6 during installation and asked "IPv6fanboys" how well their pure IPv6 WAN/LAN could communicate[16a] with the rest fo the world. JesseKeating thought[17] that users should be allowed to disable IPv6 post installation using either s-c-n or NetworkManager but that bugs appearing due to it being enabled but not actively used needed fixing. OlaThoresen provided[18] personal testimony about how perfectly IPv6 worked for him. In a separate part of the thread ChuckAnderson provided[19] a list of network operators using IPv6.

[15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01193.html

[16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01206.html

[16a] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01224.html

[17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01207.html

[18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01245.html [19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01315.html

RubenKerkhof's interest was so piqued[20] by the discussion that he registered for an account with sixss.net and MattDomsch provided[21] more details for anyone interested in experimenting with tunnelled IPv6.

[20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01317.html

[21] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01142.html

JohnReiser provided a list of arguments[22] including anonymity and expense as reasons why one would not wish to transition to IPv6.

[22] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01128.html

Udev Performance

A response to concerns about udev performance was posted[1] by HaraldHoyer. Harald had profiled udev activity and determined that it spent the majority of its time with /sbin/modprobe due to parsing its configuration/dependency files on each call[2] .

[1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00771.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00773.html

RalfErtzinger asked what udev could do except process the files each time and HansdeGoede suggested[3] several alternatives including: a daemon mode; a cached dump of the dependency tree; or splitting out the modprobe code into a library which could be called by udev. According[4] to Harald the daemon mode had also been suggested by GregKroah-Hartman and KaySievers.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00777.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00778.html

Some very interesting systemtap results were supplied by WilliamCohen, who noted that the current process of searching linearly through 250K of modules.dep was inefficient. Harald responded[5] that the problem was that most modprobes with a modalias were non-existent and so each line was parsed.

JakubJelinek suggested[6] a hash table or other compact format might solve this problem if the time taken really was significant.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00790.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00793.html

DavidHollis liked[7] Hans' last option of creating a libmodprobe.so as it would avoid maintaining duplicate code and the security problems of a pipe or socket.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00788.html

The daemon idea was also deprecated[8] by Ralf due to security issues, while Jakubs suggestion was judged favorably. EricSandeen remained to be convinced[9] however that the parsing of the modules.dep was what was taking the time and provided an strace during boot to reinforce this point.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00790.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00793.html

DavidHollis liked[7] Hans' last option of creating a libmodprobe.so as it would avoid maintaining duplicate code and the security problems of a pipe or socket.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00788.html

The daemon idea was also deprecated[8] by Ralf due to security issues, while Jakubs suggestion was judged favorably. EricSandeen remained to be convinced[9] however that the parsing of the modules.dep was what was taking the time and provided an strace during boot to reinforce this point.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00808.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00818.html

Maintainers

In this section, we cover Fedora Maintainers, the group of people who maintain the software packages in Fedora.

https://www.redhat.com/mailman/listinfo/fedora-maintainers

Contributing Writer: ThomasChung

End of fedora-maintainers-list

Editor's Note: FWN will not be covering fedora-maintainers in the future issue.

BrianPepple announces in fedora-maintainers[1] ,

"The plan is to close the fedora-maintainers-list on 2007-09-10. The fedora-devel-list[2] will be the mailing that acts as the direct successor for the fedora-maintainers-list."

[1] https://www.redhat.com/archives/fedora-maintainers/2007-September/msg00090.html

[2] https://www.redhat.com/mailman/listinfo/fedora-devel-list

Translation

This section, we cover the news surrounding the Fedora Translation (L10n) Project.

L10N

Contributing Writer: JasonMatthewTaylor

FAQ

DimitrisGlezos posted[1] about his additions of a FAQ to help address some translation questions. Comments/suggestions are always welcome.

[1] https://www.redhat.com/archives/fedora-trans-list/2007-September/msg00147.html

Transifex Update

DimitrisGlezos had some updates for transifex this week, one of which added support for system-config-printer.[1]

[1] https://www.redhat.com/archives/fedora-trans-list/2007-September/msg00156.html

Online Translation

DimitrisGlezos wanted to start discussion about whether or not an online translation tool would be useful and what features would be good to have.[1]

[1] https://www.redhat.com/archives/fedora-trans-list/2007-September/msg00171.html

Infrastructure

In this section, we cover the Fedora Infrastructure Project.

Infrastructure

Contributing Writer: JasonMatthewTaylor

DB2 Outage/Upgrade

MikeMcGrath posted[1-2] that DB2 would be taken down to address disk space issues. No problems with the upgrade were reported.

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/msg00066.html

[2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/msg00071.html

Spins Directory

MattDomsch posted[1] a suggestion to modify the mirror directory structure to better facilitate respins. The idea being that respins can be done and content can be moved back and forth between servers without causing mirror breakage. After some discussion it was agreed to be a good idea and will likely see some implementation in the future.

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/msg00083.html

Security Week

In this section, we highlight the security stories from the week in Fedora.

Contributing Writer: JoshBressers

Is a chroot secure?

Kerneltrap has a nice summary of why a chroot is not a security feature. This is an issue that comes up every couple of years. It is likely this will continue to happen since there is quite a lot of information available on the Internet that claims a chroot is a fine way to keep something secure. The best advice if you wish to keep a process in a cage would be to use SELinux.

http://kerneltrap.org/Linux/Abusing_chroot

Is SELinux really too complex?

Speaking of SELinux, this article takes a rather insightful look at the technology.

http://enterpriselinuxlog.blogs.techtarget.com/2007/09/26/selinux-is-it-really-too-complex/

The article does point out that the OpenBSD mailing list is obviously a rather biased place to find SELinux commentary, but many of the points made about SELinux are good for someone who hasn't been keeping an eye on the discussions.

Advisories and Updates

In this section, we cover Security Advisories and Package Updates from fedora-package-announce.

FSA

Contributing Writer: ThomasChung

Fedora 7 Security Advisories

• elinks-0.11.3-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00335.html
• libsndfile-1.0.17-2.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00344.html
• fuse-2.7.0-5.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00367.html
• ntfs-3g-1.913-2.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00368.html
• kernel-2.6.22.7-85.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00375.html
• bugzilla-3.0.2-0.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00387.html
• php-5.2.4-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00397.html
• t1lib-5.1.1-3.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00431.html
• kernel-2.6.22.9-91.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00436.html

Fedora Core 6 Security Advisories

• httpd-2.2.6-1.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00353.html
• php-5.1.6-3.7.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00354.html
• kernel-2.6.22.7-57.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg00355.html

Events and Meetings

In this section, we cover event reports and meeting summaries from various projects.

Contributing Writer: ThomasChung

Fedora Board Meeting Minutes 2007-MM-DD

• No Report

Fedora Ambassadors Meeting 2007-MM-DD

• No Report

Fedora Documentation Steering Committee 2007-MM-DD

• No Report

Fedora Engineering Steering Committee Meeting 2007-MM-DD

• No Report

Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-09-26

• https://www.redhat.com/archives/epel-devel-list/2007-September/msg00110.html

Fedora Infrastructure Meeting (Log) 2007-09-27

• https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/msg00078.html

Fedora Localization Project Meeting 2007-MM-DD

• No Report

Fedora Packaging Committee Meeting 2007-09-25

• https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02152.html

Fedora Release Engineering Meeting 2007-MM-DD

• No Report