Announcements

In this section, we cover announcements from various projects.

Contributing Writer: ThomasChung

Announcing Fedora 8 Test 3 (7.92)!

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

"Fedora 8 Test 3 is here! This is the last test release before the
development freeze and a great time to test all those packages that you
know and love. Test 3 is for beta users. This is the time when we must
have full community participation. Without this participation both
hardware and software functionality suffers."

Ask Fedora

In this section, we answer general questions from Fedora community. Send your questions to askfedora AT 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.

How can I be a part of Fedora?

Mark McLaughlin: How can I be a part of the Fedora project and be able to cast a vote for the codename for the next Fedora Releases? I want to contribute with ideas and distribute Live CDs in New England USA

You can be part of Fedora by joining one of the sub projects available at http://fedoraproject.org/join-fedora.html. Any Fedora contributor would be able to vote for a codename for the upcoming releases of Fedora. Ideas are worth it's weight in gold but the key factor in realizing those ideas in many instances is to step up and do the work involved. With Free software, you don't have to be contend with merely being a consumer and you have the nice opportunity to go beyond it and drive the changes you desire. Go for it.

If you are interested in distributing media freely to more end users, join the Free Media project at http://fedoraproject.org/wiki/Distribution/FreeMedia where hundreds of copies of Fedora is being distributed every month all over the world by volunteers in the Fedora community. Give everyone you can, the gift of Fedora!

Planet Fedora

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

Release Notes freeze

PaulFrields points out in his blog[1] ,

"Tomorrow night at 2359 UTC the wiki beats, where we collect the release notes for F8, will be “frozen” for the final release. From there, we produce DocBook XML sources which go to the L10N folks for translation for the F8 general release."

Summit Happenings

"Online Desktop - Owen, Bryan, Marina and I gave a talk on the Online Desktop effort that went pretty well, lots of stuff was demoed and there were some good questions."

"Summit[2] General - So far it's fun, a lot of people hacking on things here. Gave a short talk about the current state of Hotwire which went well. I think there's a lot of interest but probably most people are waiting for bugs to be fixed; if you've tried it and found some, please file them!

Marketing

Fedora 7: A Solid Core Distribution

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

"Overall, Fedora is a good distribution to consider both for an easy-to-use desktop and for a basic home or small-office server. The user interface and security features are first-class, and the rest of the environment is straightforward, particularly if you are used to Red Hat. When deciding between Linux distributions to try out, Fedora should certainly be on the list."

Interview with Fedora's Max Spevack

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

"Fedora is a distribution that we try to release twice a year, and we try to always focus on the things that are important to the larger Fedora community, while at the same time allowing Fedora to be a place where things that Red Hat engineering groups are working on can also make their way into the distribution."

Pungi Error Corrected

The continued activity of the Alphacore[1] project was revealed when OliverFalk asked[2] for some Python gurus to help him in creating non-DVD ISOs using Pungi. Oliver provided a patch to the ConfigParser.py module to allow it to accept either ints or strings. He wondered whether no one else was generating non-DVD ISOs.

Further discussion focused[5] on why ConfigParser only accepted strings. Jesse speculated that it was because it would be hard to mark an element of a plaintext file as an integer rather than a string.

A related, but distinct question asked[6] by Oliver was why Koji did not create an sqlite database with createrepo -d. Oliver noted that for slower architectures there would be a speeding up of the init phase of the build-root. It turned out that the reason was that Koji had been developed on machines which lacked the ability to run "createrepo -d" and Oliver kindly provided[7] a patch for when they became capable.

MikeBonnet added[8] the information that the createrepo in koji used the -update flag to parse pre-existing repodata resulting in a huge speed boost. Mike wondered whether --update would work with an sqlite database. Oliver responded[9] that it did not, but explained the speed trade offs faced in his situation and promised to post a request for the sqlite support with --update in the right place.

GPLv2 Obligations To Maintain Sources

An interesting question was raised[1] by MattDomsch about how the Fedora Project could help derivative spins to meet their obligation under the GPLv2 to make source-code available. There are several methods mentioned in GPLv2 by which this can be achieved depending upon the distribution method used for the object-code/binaries. Matt wanted to make sure that the producers of a spin would be able to rely upon the Fedora Project to maintain sources under provision 3(b) and suggested that JefSpaleta's method for generating specific versioned SRPMS from CVS on demand would be useful.

One of the obligations attendant upon using provision 3(b) is to make the source available for three years. NicolasMailhot thought that the easiest thing would be to never purge the SRPMS generated by Koji. While Jef agreed[2] that if this were possible it would make things simple he doubted that it was possible. MattDomsch agreed and estimated[3] that keeping four, or more, years of source-code in an SCCM[4] would take less space than the equivalent Koji archive for the same time period. JesseKeating shared[3] Matt's concerns and added that it was uncertain as to when the three year period started.

AlexanderBoström suggested[5] that ensuring that the Fedora Project's written promise which is passed on under 3(b) to re-spinners (who in turn distribute under 3(c)) had a specific time-limitation written in could solve the problem. Such a method ensures that the re-spinners are responsible for providing source if they continue distributing the software past the time at which the Fedora Project stops distributing it. SimoSorce[6] made largely similar points to Alexander, echoing the idea that it would be easier to provide binary and source CDs when distributing them at events, with a smaller number of source CDs being needed to be produced. JesseKeating responded[7] to MattMiller that this would not achieve the goal of helping the re-spinners.

Co-maintainers Without Sponsorship?

A request for comments from ToshioKuratomi(abadger) floated[1] a method for enabling upstream maintainers who to co-operate in a non-onerous way with the Fedora Project without getting a sponsor. Toshio outlined how pairing of a FedoraProject package owner with an outside upstream maintainer could proceed through three phases. The initial phases would require the sponsor to police the actions of the upstream co-maintainer. In later phases sponsors would not be required, but this requires changes to the PackageDB, Bodhi and Koji and the CVS repository.

Orinoco Driver And Scanning Problems With NetworkManager

A continuation of last week's[1] thread about all the changes in NetworkManager delved into some scanning problems experienced by MattMiller. Initial speculation[2] from DanWilliams that Matt's driver was based on mac80211 was followed up with some extensive debugging help. Dan concluded[3] that it looked as though there were some problems both with the orinoco driver and also with wpa_supplicant itself.

/etc/hosts Discussion Yields libICE Fix

Another thread from last week(FWN#103 "System Entries In /etc/hosts"[1] ) which yielded more fruit concerned the setting of hostnames by NetworkManager. BillCrawford had noticed that when running X from a console login the desktop could crash if the hostname was changed. AdamJackson(ajax) did not think[2] that the problem was a simple mismatch between the magic cookies stored in .Xauthority for the client and the server.

Bill reported[3] a specific error logged when he tried to switch VTs. This stimulated[4] Adam to patch libICE so that the path to the ICE[5] socket (which is bound at session start up) uses "unix" as the hostname part of the tuple instead of relying on gethostbyname(). The advantage of this is that although dhclient changes the system hostname, NetworkManager will not. Adam recommended that anyone experiencing delays, stalls or crashes of applications after or during changing network information should try to update libICE and reproduce the problem. He provided updated packages for Fedora 7[6] as well as rawhide.

Speeding Up Firefox?

ArthurPemberton was dissatisfied[1] with the speed of Firefox on Fedora 7 and noted that changing the default Firefox network.dns.disableIPv6 false to true and some other changes seemed to result in an improvement. JeroenVanMeeuwen(kanarip) said[2] that such changes to the defaults should only be made if upstream approved.

The reasons for why the defaults should stay as they are were detailed by the knowledgeable ChristopherAillon (who had blogged on this topic several years ago). Christopher specifically noted[3] that pipelining would break (in the sense of causing browser hangs and refusing to load) for websites served by unpatched Apache-1.3. In response to DennisJacobfeuerborn's request for some numbers, Ajax posted links to a blog entry[4] and a bugzilla[5] .

Some more anecdotal experience came[7] from DarrellPfeifer who thought that the problem was due to auto detect proxy settings instead of direct connection to internet. NicolasMailhot agreed[8] that there was a problem which needed to be reported upstream, and in response to a useful suggestion from MattMiller explained[9] that the whole UI could freeze while one tab blocked on content. BernardoInnocenti had some potential Javascript culprits in mind[10] .

Bodhi To Allow "cvsextras" To Push To Testing

An attempt by ToddZullinger to push an updated vorbis-tools package to testing to fix a bug failed[1] due to the restrictions on members of cvsextras. Todd laid out the case for easing the burden on primary maintainers by getting pkgdb to allow members of cvsextras to undertake such tasks.

LukeMacken responded[2] that bodhi currently authenticates only those with commit access in pkgdb, but thought that it should also check the group ACL. He noted that Toshio was trying to patch bodhi to do this right now (see also this same FWN#104 "Unsponsored Co-maintainers").

Toshio produced a patch and Luke applied[3] it, and a short delay[4] intervened until the production bodhi was patched after some minor[4a] adjustments. Unfortunately it seemed that Todd was still being denied[5] .

ExcludeArch Packaging Bug Resolved For 'gnome-python2-extras'

A query[1] from MichałBentkowski about the absence of a PPC64 build of gnome-python2-libegg causing sonata to fail to build revealed that gnome-python2-extras was using an ExcludeArch: ppc64. PaulFrields reported[2] a related error.

JeremyKatz responded[3] that the problem was in gnome-python2-extras, specifically that it should use ifarch for the gdl subpackage and not ExcludeArch (see last paragraph of FWN#103 "Xulrunner"[4] and links therein to earlier discussions on this topic).

Mono Packages Lagging, New Co-maintainer Added

An observation[1] that mono packages in rawhide were lagging behind the actual releases was posted by "Paul". Apparently this was affecting his work and he volunteered to co-maintain the packages if that would help.

HansdeGoede replied[2] that the RPM would certainly build, but that the Fedora Project guidelines would disallow this in favor of using either macros exclusively or native commands. MatthiasClasen disagreed, arguing[3] instead that the guidelines only distinguish between two types of macro styles, but are silent on the issue of native commands versus macros.

Initial response involved some dismay[2] at the replacement of pam_console for desktop access control with HAL, and concern that the KDE-LiveCD was only available by torrent. JesseKeating responded[3] to the latter issue, explaining that this was just for the test release and that the live images would be back to normal for the actual final release.

Separately WarrenTogami[4] noted apparently untested breakage of the iwl3945 wireless chipsets in kernels and asked for help testing kernels before they hit the nightly build. DaveJones added[5] that it was possible to install the latest builds directly from his repo using "sudo bash; cd /etc/yum.repos.d; wget http://people.redhat.com/davej/kernels/Fedora/f7.92/kernel.repo" within one hour of koji building them.

Translation

Online Translation

There was more discussion[1] this week about the possibility of setting up an online translation tool. The team has been hashing out some details about how commits would happen and how to scale access. We will definately be keeping tabs on this discussion as it would be a definate help to the team and project as a whole.

Infrastructure

MirrorManager Patch

WarrenTogami and LukeMacken worked on a validator patch[1] for mirror manager[2] so that it would work properly with the new turbogears. It was apparently a trivial patch so users should see no changes other than mirror manager now working flawlessly.

CVSExtras

There was some discussion[1] this week about renaming cvsextras to packager. The change will likely happen, though it has not been decided when. The idea behind the change is that it will be clearer what tree is for and when CVS is no longer the tracking mechanism the name is generic enough so no changes will likely need ot be made.

"you security people are insane."

Linus makes some interesting points about various security systems in the Linux kernel. While his colorful comments are humorous, this makes a rather powerful statement. Linus says:

Schedulers can be objectively tested. There's this thing called
"performance", that can generally be quantified on a load basis.
Yes, you can have crazy ideas in both schedulers and security. Yes, you
can simplify both for a particular load. Yes, you can make mistakes in
both. But the *discussion* on security seems to never get down to real
numbers.
So the difference between them is simple: one is "hard science". The other
one is "people wanking around with their opinions".

This is a big problem. Security is hard to understand, so you end up with two different types of people causing trouble. There are people who don't really understand what they're doing. These are the people that say incorrect things and just make up what they don't know. There are also the people who will blatantly lie to further their own agenda. The hope is that the right solution will eventually win out, but that's not always the case.

Advisories and Updates

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