Wittering2.0

Fedora Weekly News #166

Mon, 09 Mar 2009 11:40:26 -0400

Developments

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

Contributing Writer: Oisin Feeley

Orphans are Purged

It sounded^[1] like Dickensian cruelty when Jesse Keating announced that he would be purging the orphans. All that it meant however was that those packages which were not blocked and had no owners would be “[…] blocked, and will not be shipped with F11.” The initial list mistakenly listed EPEL packages and a shorter revised list was posted^[2].

A follow-up posted^[3] states that packages listed therein will be removed on 2009-03-09 unless volunteers are found to maintain them.

Fedora 11 to Ship Tiger VNC

Adam Tkac wrote^[1] to explain why he had decided “one minute before the beta freeze” to replace TightVNC with the TigerVNC fork. Adam has a history of very actively seeking to merge improvements upstream which in the past led^[2] to the replacement of RealVNC with TightVNC when it seemed that the latter was more willing to evolve. The glacial pace of RealVNC development seemed to be correlated with the presence of a non-Free enterprise edition. Adam reported that unfortunately a lack of co-ordination of the TightVNC project had led to the TurboVNC and TightVNC projects deciding that a fork was necessary. An initial mail posted^[3] by PeterÅstrand on @tigervnc-users provides some more details.

One specific outcome anticipated^[4] by KingInuYasha was a “[…] proper implementations of VNC 4 for UNIX like systems […] Having a VNC implementation that actually is kept up to date with the VNC protocol and is optimized with extensions is something I have been waiting for awhile now.”

Another hint of good things which may come from a more rapid pace of development was revealed^[5] when Daniel Berrange asked about Adam’s plans to include the VeNCrypt server-side SSL/TLS extension. This would result in a “[…] consistent TLS extension that’s inter operable across all the VNC clients & servers in Fedora.” Daniel also mentioned that he had “[…] recently defined & implemented another VNC auth extension based on SASL. This provides for a good extendable authentication capability, most importantly including GSSAPI Kerberos for single sign on. I’ve got it implemented for QEMU, KVM, GTK-VNC and VINO already, so again it’d be good to plan for adding it to TigerVNC too so we have a widely interoperable strong authentication system.”

All in all it looks as though contrary to their slogan “The VNC that bites” TigerVNC will be superb.

Ready for a New RPM Version ?

On 2009-02-26 Panu Matilainen asked^[1] if it would be possible to introduce RPM-4.7 at this late stage of the Fedora 11 release cycle. This new version decreases memory use and improves performance. Panu emphasized that it was not as large an upgrade as the “[…] 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year [.]”

Bill Nottingham was among those who expressed concern that rpm-4.7 would be completely ready for the final release of Fedora 11. He also wondered if there would be incompatibilities with previous rpm version. Panu answered^[2] that rpm-4.7 was expected to be ready for the final release and that incompatibilities would only result if packagers used the POSIX file capabilities. This latter is protected against with an rpmlib() dependency.

A certain amount of disquiet at the idea of “[g]oing with a beta version of critical infrastructure like RPM […]” based on the recent changes to RPM was voiced^[3] by Tom Lane. Upon a challenge from Seth Vidal some problems with the process of upgrading rpm to handle stronger hashes were listed^[4] by Bill Nottingham. These included including “No solution for handling packages natively on F9” and Tom Lane expanded^[5] on the point: “I’m personally still ticked off that I’m being forced to update my development workstation to F-10 immediately in order to continue doing useful work on rawhide packages. I don’t have time for that right now. Since F-9 is still supported, isn’t it a management failing to have allowed this to happen without a plan to make mock on F-9 work?” The general response seemed to be that developers need to use one of the virtual machine solutions in order to be able to build for rawhide.

A substantial sub-thread on the rate of change in rawhide and whether or not developers should use it or stick to the current stable release with a virtualized instance of rawhide developed^[6] following some thoughts from Adam Williamson.

RahulSundaram asked^[7] for more information on the use of LZMA compression as this is one of the new features of rpm-4.7. Panu replied^[8]LZMA will not be used by default as it would make even the current Fedora 10 rpm unable to read packages produced with such compression.

A FESCo decision made on 2009-03-06 confirmed^[9] that rpm-4.7 would be the version shipping in Fedora 11.

Windows Cross-compiler Added to comps.xml

Following from a FESCo 2009-03-06 decision Richard W.M. Jones asked^[1] to add a “Windows cross-compiler” group to comps.xml before the rapidly approaching 2009-03-10 string freeze.

Kevin Kofler asked why Richard did not call it “MinGW cross compiler” and Richard responded^[2] that he wanted to avoid trademarks and leave open the possibility to broaden support to other non-embedded platforms. He came up with either “Consumer cross-compilers (CCC) or Consumer cross-compiler collection (CCCC).” Kevin had some other interesting questions about the legality of possible OS X cross-compilers and the desirability of one group per OS. Richard pointed^[3] to an earlier thread on the latter question.

Anaconda Default of Separate / and /home Partitions

A long-standing bugzilla entry was referenced^[4] by Lex Hider as background for the idea that anaconda should support separate /home and / partitions in order to support clean installs during upgrades. Lex’s detailed post included links to relevant previous discussion.

Adam Williamson was very much in favor of the idea and in response to Jesse Keating suggested^[5] some heuristics which might allow anaconda to determine the relative sizes of the / and /home partitions. Bruno Wolff III’s / partition size (circa 40GB) proved^[6] to be surprisingly large due to multiple languages installed. Michel Salim^[7] and Callum Lerwick^[8] both brought up the necessity to have a large / partition in order to be able to run preupgrade.

Lex elaborated^[9] on possible space requirements for such a scheme.

Beta Freeze and String Freeze this Tuesday 2009-03-10

Dennis Gilmore posted^[1] a heads up on 2009-03-06 that “[…] anything that needs translations needs to be done by COB [Tuesday]. This is a blocking Freeze any packages you need included in the Beta release must be requested via release engineering [.]”

A brief amount of confusion occurred^[2] due to the misnaming of the day of the week. Till Maas also wondered exactly what Close Of Business meant exactly for an international project like Fedora.

Fedora 11 Default Mediaplayer Not Banshee. Mono to Blame ?

A summary of FESCo deliberations posted^[1] by BillNottingham stirred DavidNielsen to object that he had not been alerted (as maintainer) that discussion of the Banshee media player was to occur. David also objected^[2] that the onus had been placed on him to convince the maintainer of the competitor Rhythmbox package to allow the replacement. He also suggested that the use of the Mono language was a stumbling block due to RHEL eschewing Mono: “[…] RHEL does not ship Mono, if RHEL wants to ship Rhythmbox that is their decision but what Fedora ships should not be. What else are we going to be dictated from above.. who else should bother to make proposals for what they preceive to be improvements?”

Jesse Keating responded^[3] that his understanding was that the desire to avoid mono in Fedora is to avoid bloating the LiveCDs with dependencies. The IRC logs bore out^[4] this interpretation with FESCo members explicitly stating that “[…] what its written in should have no bearing on what goes in[.]” It was also clear however that RHEL, as the largest downstream distributor of an OS directly derived from Fedora, would not be ignored.

There is no FWN#165

Mon, 09 Mar 2009 11:39:39 -0400

Unfortunately I was sick for FWN#165 so no Developments column for that week.

Fedora Weekly News #164

Mon, 23 Feb 2009 20:01:00 -0500

Developments

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

Contributing Writer: Oisin Feeley

—- Fedora 11 Mass Rebuild —-

Some complications resulting from the inconsistent application of Fedora Packaging Guidelines were manifested when the mass rebuild discussed last week(FWN#163^[1]) gained^[2] a more concrete shape. Jesse Keating posted^[3] a request that all maintainers would read the wiki page describing what needs to be done, especially the Maintainer Actions section.

The rebuild should kick-off this Monday (2009-02-23). The wiki page describes the relatively narrow timeframe in which maintainers can attempt their own rebuilds and the way in which they can avoid the auto-rebuild.

Concern was expressed by Tom Lane that the rebuilds were non-ordered. Jesse responded^[4] that ordered builds were “[…] generally only are necessary when bumping sonames or otherwise bootstrapping items. Given that neither of those apply for this rebuild, effort spent trying to order and chain builds would be effort wasted.” Ralf Corsepius challenged^[5] this with the observation that pkgconfig BuildRequires are added automatically. Ralf suggested^[6] the problem could be solved by “[…] checking which packages in current rawhide contain *.pc’s but do not Provide nor Require pkgconfig(foo) and to rebuild them (in manually presorted order) in advance to the mass rebuild.”

Jon Masters appreciated^[7] Jesse’s work and worried that the rebuild might leave some statically built binaries using i386 instead of the promised i586 (see FWN#162^[8]). Subsequent rebuilds were suggested as a means to work around the problem but Jesse preferred to identify specific problems and stated^[9]: “I think the most I’d be willing to do would be a second build pass across the static packages. IMHO everything else should be left up to testing discovery and fixing the assumptions rather than hiding them.”

Another approach was suggested by Conrad Meyer based on using BuildRequires: *-static. When Ralf replied that this would not work because many packagers who had not used static subpackages Conrad pointed^[10] to the guidelines. Nicolas Mailhot ruefully responded^[11] that his experience with the fonts guidelines suggested that enforcement was necessary. Later discussion with Jakub Jelínek about the presence of libc.a in glibc-devel suggested^[12] that it will not be simple to apply this particular guideline to glibc without gcc -static ceasing to behave as expected.

—- Virtual Provides for Login Managers —-

Following problems reported^[1] with booting to runlevel 5 by default with the slim login-manager Chris Lumens suggested^[2] that “[…] all packages containing a login manager include a special Provides: that we can query on.” This would allow anaconda to determine whether a login-manager is installed without the difficulties of curating a list.

Patrice Dumas, and others, provided^[3] a good deal of feedback which seems to have led to a consensus that Provides: service(graphical-login) will be added to all packages which provide a login manager.

An interesting sub-thread developed in which Colin Walters argued^[4] that adding display managers (other than gdm and kdm should be strongly discouraged. This was met^[5] with a good deal of disagreement from Tom Callaway and Seth Vidal.

Colin explained^[6] that the ramifications of changing such an integral part of the OS were complex and that while anyone should be free to add such software it should also be “[…] within the rights of the people working on the desktop to close any bugs filed by people using something else WONTFIX.” Jesse Keating and Seth Vidal seemed^[7] to agree that it should be possible for the Fedora Project do define specs to which login managers should conform.

The thread blossomed into several discussions. One focused on the technical challenges occasioned^[8] by the interaction of GDM, PAM, gnome-keyring, NetworkManager and ConsoleKit. Another saw^[9]Toshio Kuratomi and Colin debating the strategic merits of making it more or less easy for interested parties to add their software to the Fedora Project ecosystem.

—- Reducing the Number of (Dis)Charge Cycles for Laptop Batteries —-

A certain amount of excitement resulted when Brad Longo asked^[1]: “[…] if Fedora’s power management tool has something built in so that when the battery reaches full charge, it will then discharge to lets say around 95% before beginning to charge again.” The excitement arose from Brad’s premise that “[…] leaving your laptop plugged in and charging with a full battery charge is harmful for the battery.”

Several responses rejected^[2] the premise and pointed out that smart chargers implement trickle-mode charging. Matthew Garrett replied^[3] with some specific information about how laptop battery charging happens at a firmware-controlled threshold level. Matthew speculated that Brad wanted “[…] presumably an interface to modify that threshold. This is device specific. The tp_smapi driver (which is not in the kernel for exceedingly dull reasons) allows this to be configured on Thinkpads. I don’t believe that we know how to on any other systems.” Hans Ulrich Niedermann had^[4] an out-of-kernel module for tm_smapi which was configurable via /etc/sysconfig.

Matthew Saltzman reported^[5] some experiences with Windows setting the charge-threshold to 85% which is supposed to lengthen the battery life. Callum Lerwick referenced^[6] a Wikipedia article which claimes that the “[…] optimal storage charge for a Li-Ion is %40. Also, heat causes Li-Ion batteries to degenerate much faster, so if you’re really worried about preserving your battery, don’t leave it in the laptop while it’s running. Yet another argument for less power usage. Less power, less heat, longer battery service life. Fewer toxic batteries going in to the land fill if you like that angle.”

—- config.guess Reporting Incorrect Configuration Name ? —-

Panu Matilainen asked^[1] if it was a problem that the config.guess script from autotools no longer reported “redhat” as the manufacturer part of the configuration triplet. Panu referenced the documentation which suggests that “[…] the manufacturer part of the configuration name is the manufacturer of the CPU, not `OS vendor’ so the former `redhat’ was always incorrect. I don’t know the history behind the decision to stomp `redhat’ in there to begin with nor why it was then dropped later on. But having gotten used to it, people occasionally think the `unknown’ (or `pc’ for that matter) is a bug.”

While Jakub Jelínek thought that providing the “redhat” string provided more information than “pc” or “unknown” Stepan Kaspal argued^[2] strongly that reverting to maintaining such a patch was wrong. He suggested that either upstream should be convinced to change the use of “manufacturer” or that the %configure macro in the specfile could be used to explicitly avoid calling config.guess. From here on the thread became too technically detailed to summarize although it is relatively brief as of going to press. Those learned in the lore of autotools and cross-compilation will find much to gladden their hearts.

—- Build-time Trapping of Python Syntax Errors —-

Tim Waugh initiated^[1] verification that Python code can be parsed correctly: “[…] since we are already byte-compiling Python code at build time, it is no extra effort to verify that it can be parsed and fail if not.”

Reaction was^[2] uniformly positive and when Panu Matilainen explained the simple errors which the byte compile would catch and suggested^[3] a simple method of determining affected packages Florian Festi took up the challenge.

—- YUM Plans for Transition to Fedora 12 i686 Architecture —-

When Paul Howarth asked^[1]: “Now that Fedora 11 x86_32 is going to be based on i586 packages rather than i386 packages, does it follow that yum’s $basearch will change from i386 to i586 and hence repository directory layouts changing too, or will it stay at i386?” a brief discussion between Seth Vidal and Josh Boyer started^[2] with a discussion over whether repositories should be named after specific architectures.

Seth Vidal differentiated between $arch and $basearch and explained^[3]: “The whole reason I liked used $arch was that it meant when fedora stopped producing a 586 compatible tree, we didn’t stop any one else from making a 586 compat tree and having it available like secondary arches are.” Jesse Keating explained^[4] that “i386” was a misnomer for the x86 offering. Josh Boyer was^[5] unsure whether i586 would actually “go away” for Fedora 12. Dennis Gilmore was sure that it would and offered^[6]: “Anyone who wants to continue i586 support post F11 i look forward to talking to about setting up i586 as a secondary arch.”

FedoraWeeklyNews#163

Mon, 23 Feb 2009 19:59:00 -0500

Developments

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

Contributing Writer: Oisin Feeley

—- FLOSS Multimedia Codec Support —-

Inspired by previous discussions on whether Fedora should distribute FLOSS content^[1]Martin Sourada tried^[2] to start a discussion about the poor support of FLOSS multimedia. Martin noted: “Out of the combinations of two FLOSS containers (matroska and ogg) and two FLOSS video codecs (dirac and theora) I know only one (ogg + theora) actually works in xine-lib (used by KDE4) which is pathetic.” He asked for help in documenting the situation on a wiki page^[3].

When Bastien Nocera suggested that the most important thing was to file bugs Martin responded^[4] that this was what he was doing after first performing tests.

An information packed sub-thread started^[5] by Gregory Maxwell expanded the scope of the tests and started a discussion with Dominik Mierzejewski about the problem of ffmpeg providing sub-optimal implementations of unencumbered codecs. It seems that for reasons of efficiency ffmpeg re-invents the wheel from scratch instead of using and improving upstream implementations. Kevin Kofler also rose^[6] to the implied challenge that GStreamer was preferable to xine-lib.

—- Multiple Packages from One Source ? —-

A question about how to handle the situation where a single source could be compiled with alternate databases was posted^[1] by Steven Moix. The motion video motion detector software can be compiled to use either MySQL or Postgres. Steven explained that the problem was that “[…]you can’t divide it into sub-packages, at the end it generates one big binary file […]” and wondered should he just choose the database he preferred or propose two packages.

Manuel Wolfshant expressed^[2] what appeared to be the common wisdome: “personally I would compile twice, once enabling mysql and another time pgsql, and create 2 packages. each package would install a “motion-dbname” binary, and a symlink would allow access via the well known name “motion”. Using alternatives would allow a switch between the two.”

Although it was admitted that David Woodhouse’s suggestion^[3] to make the program use loadable plugins was the ideal Tom Lane thought^[4] that was “[…] a bit above and beyond what a packager should do. If he’s also an upstream developer, then he should undertake that addition with his developer hat on; but it’s *well* beyond the size of patch that a Fedora package should be carrying.”

The ability to specify alternate requires (similar to those used in the .deb package format^[5]) was discussed^[6] by Richard W.M. Jones and Tom Lane and dismissed as impractical in this case anyway due to variations in SQL.

—- Take a Peek at the Fedora 11 Release Notes —-

Fresh from his work on the RHEL-5.3 Release Notes Ryan Lerch apprised^[1] the list of the latest changes to the Fedora 11 Release Notes. Ryan sought early feedback and changes to documentation beats in order to give the community an early preview of the release notes.

Initial feedback from Thorsten Leemhuis and Kevin Kofler and others indicated that the use of fixed-width instead of liquid layout was disliked by some people and loved^[2] by others.

Ryan also provided^[3] an rpm of this Release Notes mockup.

—- Heads Up: Noarch Subpackages Landing Soon —-

Florian Festi warned^[1] that the ability to produce noarch subpackages will soon be available in Fedora. This brings the benefit of being able to share these packages among different architectures thus reducing disk space and mirror bandwidth.

Although rpm-4.6 supports noarch fully there are still some fixes to make to koji before the Fedora buildsystem can cope with noarch subpackages. Florian suggested that those who wanted to could experiment in mock with rpmdiff to compare the results across different architectures. He assured readers that there were no plans to force packagers to use this feature and invited anyone interested in developing the use of noarch in future release to a discussion.

Florian later warned^[2] that one potential negative outcome of using such sub-packages would be a proliferation of packages and consequent bloating of metadata which might affect yum.

VilleSkyttä suggested^[3] that it would be wise to make sure that use of BuildRequire: rpm-build >= 4.6.0 was enforced in order to ensure that earlier versions of rpmbuild did not produce noarch versions of the main package and other potential subpackages. Florian’s response recognized^[4] the problem but deprecated the use of BuildRequires to such an extent. One possible alternative which he proposed was to “[have Panu Matilainen backport a check that will make noarch packages (both regular and noarch) fail to build if they contain binaries [and ensure that this] additional check will be in place before koji will be updated[.]” This latter proposal stimulated a good deal of interest from Ralf Corsepius and Richard W.M. Jones as they were both concerned with cross-architecture issue. The definition of a “binary” seemed to be one unclear point.

In a later thread Florian updated^[5] a list of packages which could be easily turned into noarch subpackages.

—- Mass Rebuild Coming Soon —-

Jesse Keating drew attention to “[…] a perfect storm brewing for Fedora 11” due to the need to rebuild with GCC-4.4 (see FWN#161^[1], the use of i586 as the default supported architecture (see FWN#162^[2] and the support of stronger hashes (last paragraph of FWN#107^[3]).

Apparently the time-constraints led to a desire to start the rebuild as soon as possible without giving maintainers an explicit window in which to do their own builds. Jesse preferred to give maintainers an ability to opt-out and sought suggestions on how this could be achieved.

Jesse suggested that interested parties should either reply to the thread and/or participate in the 2009-02-16 IRC meeting in #fedora-meeting at 1800UTC.

—- New Tool Measures Ease of Cross-compiling to Windows —-

Richard W.M. Jones announced^[1] the availability of CrossReport, a tool to evaluate the ease with which applications can be ported to Windows using the MinGW libraries.

After some issue with platform dependency were reported by Michael Cronenworth were sorted^[2] out it seemed^[3] the tool is ready for use.

FedoraWeeklyNews#162

Mon, 23 Feb 2009 19:57:00 -0500

Developments

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

Contributing Writer: Oisin Feeley

—- Fedora 11 Alpha Released —-

Jesse Keating announced^[1] the availability of Fedora 11 Alpha on 2009-02-05. His beautiful poetry was accompanied by a suggestion to read the Release Notes^[2].

One change which drew^[3] extensive commentary on @fedora-test was the default disabling of the Ctrl-Alt-Backspace key combination. This traditionally kills the X server and to regain the usual behavior it is necessary to create an Xorg.conf file (these no longer exist by default either) and add the line Option "DontZap" "false" to it.

—- Fedora 11 Will Support i586 Instruction Set —-

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

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

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

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

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

—- RFC: Power Management —-

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

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

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

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

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

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

—- Rawhide Report 2009-02-07 —-

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

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

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

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

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

—- New Georgian Fonts Packaged Rapidly —-

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

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

Tom Callaway responded^[2] within mere hours.

—- Distro-agnostic /boot Metadata Standard ? —-

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

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

—- GCC-4.4 Mass Rebuild Successful —-

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

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

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

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

—- Help Rel-eng Accelerate Updates Processing —-

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

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

FedoraWeeklyNews#161

Mon, 23 Feb 2009 19:56:00 -0500

Developments

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

Contributing Writer: Oisin Feeley

— Fedora 11 Alpha May Be Delayed —-

Jesse Keating reported^[1] that the Fedora 11 Alpha release date might slip due to some anaconda bugs which manifested themselves late in his testing on some architectures. A later post suggested^[2] that installation using NFS was broken and that “[t]his likely means a slip, perhaps only a two day slip, of Alpha.” More info to come either later this weekend or early next week. A bugzilla comment^[3] from Warren Togami on a side-effect of trying to fix this problem by reverting to an earlier nfs-utils version warned “People should be aware that NFS as a server in F11 Alpha is broken. That is all.” As of going to press on 2009-02-01 there was no further information available.

—- GCC: Default ISA Flags and Glibc —-

Jakub Jelinek asked^[1] whether the minimum CPU which would run code compiled by Fedora 11’s GCC should be re-evaluated. A follow-on question was whether the minimum supported kernel version in glibc could be bumped to 2.6.29. Jakub held out the promise of potentially increased speed and decreased shared library sizes.

A problem raised^[2] by Kevin Kofler was that mock builds would no longer be able to run on older Fedora releases and that some VPSs would not be able to upgrade at all. Gerd Hoffman agreed^[3]: “We just can’t make the huge jump from .9 to .29. We have to do it smaller steps, considering kernel versions at least in supported Fedora versions, maybe also latest RHEL.”

Josh Boyer seemed^[4] to believe that the required mass rebuild with GCC-4.4 would be difficult but possible. Mike McGrath outlined^[5] the amount of work which would be needed.

See this same FWN#161 “Dropping Support for i586 Architecture” for a related discussion.

—- RPM Packagers: Too Many Unowned Directories —-

Michael Schwendt raised^[1] the problem of unowned directories installed as a result of packagers unfamiliar with “how to include files vs. directories in RPM package %files lists.”

Colin Walters remembered^[2] discussions which had suggested that if RPM were able to reference count directories there could be a technological fix. Separately Richard W.M. Jones made^[3] a similar argument. Panu Matilainen seemed^[4] willing to move this task to the top of his queue if it were sufficiently important.

—- Lack of Update Information —-

A can of worms was opened^[1] by Rahul Sundaram when he noticed that the update information provided by package maintainers was often unhelpful. He cited generic messages of the form “Update foo to upstream x.y.z” as a common problem and wondered if guidelines could improve the situation.

Following some questions Rahul expanded^[2] on the problem pointing out that package maintainers had the knowledge to tersely explain what upstream changes implied for ordinary users. He emphasized that he was concerned with the “description that is part of bodhi update and not the changelog which can be very brief.”

Chris Weyl put^[3] forward the counter-argument that package maintainers had a difficult enough life already.

Richard W.M. Jones wondered^[4] if rpm could be altered to allow it to reference upstream changelogs which could be pulled out by other tools. Panu Matilainen averred^[5] that while rpm was alterable Richard’s proposed change would just dump the information into the rpm payload and it would thus not be available to users until after they had installed it. Further brainstorming seemed^[6] to run into various practical dead ends.

Subsequently Rahul published^[7] a draft guideline which fanned the flames back to life. Thorsten Leemhuis asked^[8] “Don’t we have way [too] many guidelines and policies already? […] Note that I don’t disagree with the text that was proposed. My 2 cent: Put it as text into the wiki somewhere, write “best practices” on top of it (avoid the words “rules” and “guidelines”) and add a link to the bodhi UI (“best practices for filling this box with information”).” Rahul appeared to agree that this was the best course for the present and deferred to FESCo for the ultimate decision.

—- Electronic Design Automation Content Without Tools ? —-

Chitlesh Goorah redirected^[1] a debate on Electronic Design Automation (EDA)^[2] tools from FESCo to @fedora-devel. Chitlesh is the prime mover behind the Fedora Electronic Lab Spin^[3]. He was concerned that FESCo had decided that packages in the OVM^[4] format were barred from Fedora on the grounds that there was no FLOSS tool which could use them although they were licensed acceptably.

Jef Spaleta explained^[5] that there were subtle problems in the discussion as “[OVM] is code of some sort. The problem is we don’t have a compiler or interpreter that can process the instructions. In the context of Fedora its code that can’t be used.” Kevin Kofler supplied^[6] the appropriate guideline.

Kevin Fenzi expressed^[7] appreciation for Chitlesh’s work on the Fedora Electronics Lab and asked if there was any use for OVM besides hooking it up with a non-Free simulator? Manuel Wolfshant argued^[8] that OVM “is interesting for a subset of the people interested in EDA” and that it should be provided for them. Horst von Brand disliked^[9] the idea of mirrors carrying such a little-used package around and suggested that Manuel could just set up his own repository.

—- Dropping Support for i586 Architecture ? —-

Following FESCo discussions^[1]Bill Nottingham reported^[2] that the supported architecture list was going to change. Important changes include building binaries only for i686 and above. There are concerns that older thin clients based on i586 hardware and the AMD Geode-based XO laptops may then be unsupported or unstable. Bill characterized the discussions as a follow-up to the compiler flag discussions (see this same FWN#161”GCC: Default ISA Flags and Glibc”) and summarized the main points as:

- install x86.64 kernel on 32-bit OS where appropriate
- install PAE kernel on other 32-bit OS installs where appropriate
- build only i686 and above for Fedora

Jeremy Katz added^[3] anecdotal reassurance that the XO should probably be fine with the i686 kernel and glibc.

Robert Scheck wondered^[4] what the definition of “where appropriate” was and what mechanism would be used to make this determination.

Dominik ‘Rathann’ Mierzejewski predicted^[5] “[t]here’s going to be some screaming from VIA C3 and AMD K6 users about this.” His suggestion was true during an older similar discussion (see FWN#93^[6]) in 2007 which concerned plans to drop shipping an i586 kernel. Suggested attempts to compensate by making the i686 kernel bootable on i586 architectures were thwarted as rpm balked at installing a kernel which violated its architecture check. Alan Cox was one of the strongest objectors to the possibility of thus losing support for i586 as he had many thin clients using that architecture. Doubt was cast during that thread as to whether the smolt statistics were believable. However, Alan has recently become an Intel employee (following other ex-Red Hat luminaries David Woodhouse and Arjan van de Ven) and did not contribute to the thread. The smolt statistics listed^[7] on the feature page suggest that there are only 130 i586 users.

Josh Boyer clarified^[8] that no decision had yet been made by FESCo and that a vote would take place next week.

—- Blinking Cursor Wastes Power —-

Matthew Garrett asked^[1] for comments on the idea that the cursor should default to not blinking. The rationale was that several less Watts of power would be consumed.

The suggestion seemed generally popular but Dominik `Rathann’ Mierzejewski wished to retain the blinking cursor and expressed^[2] a desire for more information on the methodology which Matthew had used. Bill Nottingham reminded^[3] that it would still be possible to turn the cursor back on from this new default. Matthew provided^[4] some of the requested details.

Matthias Clasen suggested^[5] changing a GTK setting which disables cursor blinking after a timeout. Josh Boyer worried^[6] about other desktop environments and vttys.

FedoraWeeklyNews#160

Mon, 23 Feb 2009 19:55:00 -0500

Developments

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

Contributing Writer: Oisin Feeley

—- NFS Mounts and Caching DNS Nameserver Problem —-

An update on problems with NFS mounts was posted[1] by Warren Togami. It was decided that nfs-utils will revert to its pre 2009-01-14 behavior.

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

—- Fedora 11 Alpha Release Activities —-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—- Minimalist Root Login to X ? —-

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

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

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

auth required pam_succeed_if.so user != root quiet

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—- Fedora Geo Spin for USB Key and LiveCD —-

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

[0] OpenStreetMap http://en.wikipedia.org/wiki/OpenStreetMap

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

—- Draft Guidelines for Approving provenpackagers —-

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

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

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

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

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

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

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

—- Cloning of Bug Reports ? —-

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

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

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

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

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

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

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

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

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

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

Fedora Weekly News #159

Mon, 23 Feb 2009 19:53:00 -0500

Developments

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

Contributing Writer: Oisin Feeley

—- The Possible Future of Comps ? —-

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

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

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

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

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

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

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

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

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

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

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

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

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

—- New GPG Signing Keys for Each Release —-

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

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

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

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

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

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

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

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

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

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

—- libssl.so.7 Going Through a Bumpy Patch —-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—- MinGW Package Reviews Requested —-

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

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

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

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

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

—- MySQL 5.1 Coming to Rawhide After Alpha-Freeze —-

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

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

—- Spins SIG Controversy —-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fedora Weekly News #158

Mon, 23 Feb 2009 19:51:00 -0500

Developments

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

Contributing Writer: Oisin Feeley

—- Default ssh-agent Dialog Pop-up —-

Confusion abounded when user “nodata” reported[1] that running ssh-add from the command-line popped up a gnome dialog requesting his private SSH key. “nodata” disliked handing out his private key in such a manner. The confusion resulted from the availability of at least two possible ssh-agents[2] and also a change in configuration between Fedora 9 and Fedora 10 which presents the authentication dialog by default.

Ricky Zhou was among those who suggested (with a manpage quote) that the SSH_ASKPASS environment variable determined whether the passphrase was read from a terminal or by an X11 dialog. Separately Jesse Keating[3] and Nalin Dahyabhai explained[4] that the dialog was presented by gnome-keyring and not gnome-ssh-askpass.

“nodata” questioned[5] whether the behavior had changed between Fedora 9 and Fedora 10 and expressed irritation that a “[…] GUI is popping up when I am using a command line app.” Jesse Keating responded[6]: “You’re using a command line app from a graphical terminal. Also, cli apps aren’t the only use for ssh and ssh keys.” This did not appeal to many respondents including John Linville who questioned[7] the benefit of changing focus to a new window to type a passphrase. Callum Lerwick rather tartly outlined[8] some benefits including preventing key logging attacks.

Matthias Clasen suggested[9] using

gconftool-2 -s -t bool /apps/gnome-keyring/daemon-components/ssh false

to turn off the behavior for those who dislike it and this led to several requests to make this the default. Andrew Haley put[10] the case that “[t]he key argument against a pop-up dialog box that asks for the passphrase is that we’re training people to type secrets into pop-up dialog boxes. Bad psychology, bad security.”

Matthias Clasen and Tomas Mraz with Jerry Amundson explored[11] the use of SSH_ASKPASS as an alternate method to disable the GUI dialog.

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

[2] Private keys are stored by ssh agents so that they may handle all key related operations requested by clients. The passphrase to decrypt the key thus need only be typed into the agent once instead of per-operation.

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

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

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

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

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

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

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

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

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

—- Intel Graphics Installation Woes —-

“Mike” requested[1] information on when a working xorg-x11-drv-i810 driver for Intel graphics chipsets had a chance of appearing. He was disappointed that it was non-trivial to get two machines with 82945G and 82845G chipsets installed and had needed to fall back to using the vesa driver instead of the intel one.

Others listed outstanding bugzilla entries for a wide range of Intel chipsets. Dan Williams asked[2] if using Option "EXANoComposite" "true" as a workaround for problems with the i830 chipsets was succesfull and received mixed reports. It seemed that he was making some progress with resolving some of the issues.

MAYoung suggested[3] that setting “NoAccel true” in xorg.conf might work for some people but that “[…] intel graphics are highly flaky on Fedora 10.”

Robert Arendt laid[4] the blame at the door of upstream merges of GEM/DRM into the kernel and noted that other distributions were suffering identical problems. “Mike” later confirmed[5] this with a list of bugzilla entries from upstream freedesktop.org: “It would be nice if Intel would help to get this fixed, and there are indeed problems with Suse, Ubuntu and Mandriva also with newer drivers and Intel graphics chipsets of various flavors - this is really bad!”

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

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

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

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

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

—- KPackageKit Auto-update Bug —-

Michael B Allen reported[1] that his system had performed an update without his permission and asked how to completely disable such behavior.

It appeared[2] that this was due to a bug in KPackageKit which has been unfixable[3] for over a month due in part to the complexity of the code.

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

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

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

—- Enabling Staging Drivers ? —-

Rahul Sundaram asked[1] if enabling the many new drivers in the staging tree[2] would make sense in rawhide in order to support a wider range of hardware such as the EeePC’s ralink wireless chipset.

Opinion was roughly split between those who were completely against the idea and those who suggested avoiding codifying a rigid policy. Matthew Garrett believed[3] that it would be “somewhat user-hostile” to, for example enable the ralink drivers in rawhide but possibly remove them for a general release. He argued that the ralink drivers were a dead-end[4] which would never merge upstream. On the other hand Dave Jones preferred[5] to take a case-by-case approach as long as “[…] we have someone responsible for working on it, with the goal of getting it out of staging, and dealing with bugs etc. Not unlike the same reasoning for us adding various not-yet-upstream drivers to the Fedora kernel really.”

While preferring to completely disable the staging drivers Thorsten Leemhuis expressed[6] the intention to provide RPM Fusion kmods in that case. Dan Williams made[7] a strong argument that “-staging” itself was a bad idea as it gave “legitimacy to drivers of questionable quality” and John Linville limned[8] the tortured history of the at76 driver.

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

[2] “linux-staging” is a kernel tree whose purpose is to test drivers and filesystems for later inclusion in mainline http://lkml.org/lkml/2008/6/10/329

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

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

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

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

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

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

—- git-* Commands Moved to /usr/libexec/git-core/ —-

Adam Tkac worried[1] that scripts would break due to the latest git branch in rawhide which had moved all the git-* binaries to /usr/libexec/git-core in order to comply with upstream practice. The issue was previously discussed (see FWN#141[2)] with the resolution that updating to git-1.6.0 would be a flag day for this change. Adam suggested that the new location could be added to the PATH environment variable but this received no support.

Karel Zak advocated[3] that such scripts should be fixed as the change had been coming since 2006.

Bryn Reeves wondered[4] if compatibility symlinks and a release note would ease the transition over a couple of releases. Although the symlinks were generally felt to be a non-effective strategy Todd Zulinger was encouraged[5] by Paul W. Frields to open a bugzilla entry against the Release Notes to ensure that the documentation team take care of highlighting the issue for Fedora 11.

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

[2] http://fedoraproject.org/wiki/FWN/Issue141#Git-1.6.0_Commands_to_be_Moved_Out_of_PATH

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

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

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

—- Mandatory FHS Adherence —-

Jason L. Tibbitts III posted[1] a summary and links to the 2009-01-06 FPC meeting deliberations. Interest on @fedora-devel was mostly sparked by the item which declared that the FPC would “Make adherence to the FHS a MUST [.]” Jason encouraged reading of the full minutes in order to understand this item.

Doug Ledford discussed[2] the problem his MPI[3] implementations experienced with the FHS and Richard W. M. Jones expressed [4] concern that the FHS was a moribund standard and adhering to it would block projects such as MinGW without any method to evolve the standard. Toshio Kuratomi responded in detail in both threads and pointed out[5] that the MinGW case had been addressed in the meeting and also that there were problems with changing the FHS.

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

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

[3] http://www.open-mpi.org/papers/ipdps-2006/

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

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

Fedora Weekly News #157

Mon, 23 Feb 2009 19:50:00 -0500

Developments

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

Contributing Writer: Oisin Feeley

—- Nautilus Spatial-mode Flamewar —-

The tired, old topic of whether nautilus should use “spatial-mode” as a default was re-opened[1] by MarkG85 in the form of a request for list subscribers to “vote” on the mailing list for a reversion to “browser-mode”. In spatial-mode nautilus opens a new window for each directory unless one middle-clicks or holds the shift key down.

It was pointed out by several contributors that voting “+/- 1” was not a recognized way to achieve change within the Fedora Project. Chris Adams asked[2] if he and his friends “[…] should […] all spam fedora-devel with `+1’ and `metoo’ to change the default background color? What if it is 20 friends, or 100, or 500?” A similar point was made[3] by Jef Spaleta.

Dimi Paun expressed[4] frustration with what he charcaterized as “lame community involvenment” and several personal attacks were made on both the maintainer and other contributors who had deprecated the attempt to take a mailing list vote. After tempers had flared Jeff commented[5]: “Noone has figured out how to write a markup language for human intention…and as a result any passionate discussion degrades severely as we are wired to read intention but without body language and vocal ques…we absolutely do it wrong when relying solely on written language. Even more so with English! If we mandated everyone encode thought into Lisp we’d be having more constructive discussions (and less of them). The productivity of the list would be through the roof.”

In response to a challenge to detail some advantages of spatial-mode Tomas Torcz was among those who offered[6] that the persistent screen placement of directory windows was a major advantage. He also suggested a way to avoid leaving multiple windows open: “When I open new window and don’t want parent directory open, I just open with middle button. Some people prefer Shift+click in this situation. I never has to use `Close all parent folder’ (ctrlshift-w), but I aware it exist.” Joonas Sarajärvi confirmed[7] the persistence as an advantage: “[…] the state of each folder is persistent. Every window opens in the same view that it had when I reopen them. I can have appropriate zoom levels and views for every directory I commonly use.”

Very much later in the thread, after he had been referred to several times, the package maintainer Alexander Larsson replied[8] that he was unconvinced both by the tone and content of the argument that there was a case to be made for changing the default.

It is possible to choose which behavior one wants by at least two methods. One can either use the GUI

Nautilus -> Preferences -> Behavior -> Always open in browser windows

or else change the GConf setting using

gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true

As part of the argument involved a desire to be able to replicate these settings automatically and possibly distribute them to others Matthias Clasen suggested[9] that anyone wishing to make permanent change to the default settings could create a sabayon profile.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02089.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02286.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02305.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02416.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02392.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02387.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02213.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02189.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02389.html

—- Font Package Naming Guidelines —-

Nicholas Mailhot ensured[1] that everyone was made aware of the new font package naming rules for Fedora 11. These will help break up large font packages in order to allow users to obtain fonts from desired families without imposing a large download burden.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02597.html

—- How to become a Co-Maintainer —-

Ray Van Dolson asked[1] for some information on identifying the current (co)maintainers of the proftpd package, the procedure to become a co-maintainer and the abilities to push bugfixes which this would confer upon him if the primary maintainer were absent.

A full answer was provided[2] by Patrice Dumas with links to PackageDB and the policies on the wiki regarding non-responsive maintainers.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02253.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02255.html

—- Proposed Package Re-Naming Guidelines —-

Feedback was requested[1] by Kevin Fenzi on a draft guideline concerning the re-naming of packages either as a result of upstream action or locally to adhere to the NamingGuidelines.

Patrice Dumas and Dennis Gilmore remembered[2] that a re-review followed by EOL of the old package was the current practice.

Jason Tibbitts[3] and Jesse Keating[4] referenced IRC discussions of the practice and its advantages in checking the Obsoletes and Provides in discussion with Jochen Schmitt. Jochen was concerned[5] that the process be kept lightweight as opposed to a full review.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02052.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02054.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02058.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02056.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02060.html

—- Exiv2 Bump in Rawhide —-

Rex Dieter announced[1] that a bump to exiv2-0.18[2] would occur soon including a soname bump. Jon Ciesla offered to help and Rex produced[3] a quick list of dependent applications.

When Matej Cepl struggled with some odd results Michael Chudobiak answered[4] that the API had changed a good deal.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02061.html

[2] Exiv is a command-line utility for examining EXIF and IPTC metadata of images.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02068.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02244.html

—- wxGTK2 to wxGTK Re-name —-

Michael Schwendt discovered[1] that a rename had been performed[2] some time ago so that there was no wxGTK2-devel package available. Dan Horák explained[3] that only audacity was affected. There was[4] some discussion about whether versioned Provides should be kept indefinitely.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01897.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01972.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01975.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02046.html

—- RFC: Description Text in Packages —-

Follow-up action (see FWN#153[1]) was requested[2] by Richard Hughes for packagers to fix “isane descriptions” in their package summary text. Enlightenment was singled out as an example of an undesirable multi-page description. Richard also asked for comments on how bullet-points should be represented and the use of UTF-8.

A heated discussion followed[3] in which Nicolas Mailhot deprecated the possible development of a “broken application-side transcoding system”. He advocated the use of UTF-8 over ASCII for several reasons including supporting the default Asian locales. Paragraph boundaries and lists were also mentioned[4] as a special area of concern.

This is a long and painful thread to read which expresses a conflict between constraints imposed by PackageKit and how things are currently done. Packagers should probably skim it to determine what final decisions are going to be made. Richard Hughes seemed[5] to decide to implement what seemed to him to be sane changes to gnome-packagekit in which “If you’re [g]oing to use [UTF-8 representations of skull-and-crossbones and radiation-hazard symbols] in a spec file, then the text box is going to look rubbish and be all on one line. If you use a description longer than a few hundred words, gnome-packagekit will truncate it.”

[1] http://fedoraproject.org/wiki/FWN/Issue153#RFC:_Fix_Summary_Text_for_Lots_of_Packages

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01550.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01555.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01577.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01927.html

Fedora Weekly News #156

Mon, 23 Feb 2009 19:49:00 -0500

Developments

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

Contributing Writer: Oisin Feeley

—- Fedora 11: OSS and PulseAudio Conflict Resolved by CUSE ? —-

A thread[1] from November led Warren Togami to suggest[2] a plan to use CUSE[3] as part of a strategy to deprecate the near obsolete Open Sound System (OSS) which wreaks havoc with PulseAudio enabled boxes. The plan included a fallback to OSS for users who really wanted it.

Bastien Nocera was[4] skeptical that CUSE would be ready in time for Fedora 11 and suggested instead that a list of applications using OSS be created so that they could be fixed.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01005.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02195.html

[3] Character Devices in User space: http://lwn.net/Articles/308445/

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00872.html

—- Rawhide Report 2008-12-08 —-

When the latest Rawhide Report logged[1] one maintainers use of cvs-import.sh Dominik Mierzejewski criticised[2] the use of the script for updating. Richard Jones asked[3]: “[I]s this stuff really documented anywhere? I have tended to learn it by osmosis, deduction and reading the horribly complicated rules in Makefile.common.”

Jason Tibbitts argued[4] that using cvs-import.sh nullified the potential advantages of using an SCM as it sequestered the sources elsewhere. Jesse Keating disagreed[5] due to ease of use issues.

A direct answer was provided[6] by Patrice Dumas with links to the relevant portions of the wiki.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00671.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00677.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00691.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00694.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00695.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00701.html

—- The D-Bus Problem —-

Ian Amess asked[1] for the current status of a problem caused by a substantial update of the D-Bus package. The update had resulted in the incapacitation of many packages. The most important of these was PackageKit, the default graphical application for managing software.

Colin Walters decided[2] that reverting the update was necessary and that changes to D-Bus policy would be postponed. PackageKit, and its GNOME and KDE clients were updated[3] by Richard Hughes in an attempt to accommodate the changes. Richard testified that “[o]ver the last two days we’ve all been working really hard on fixing up all the projects after the DBus update. I know personally I’m closing a duplicate bugzilla every 30 minutes.” He noted that the delay between creating an update and pushing it to a mirror was a limiting factor in being able to implement these fixes.

A post to @fedora-announce by Paul Frields explained[4] the series of steps which allowed users to re-enable normal system updates using PackageKit. As of 2008-12-15 this notice also appears at the top of all the Fedora Project wiki pages.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01391.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01412.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00746.html

[4] https://www.redhat.com/archives/fedora-announce-list/2008-December/msg00012.html

—- Fedora Com System ? —-

An exploration of possible ways to alert users to critical information was initiated[1] by Arthur Pemberton. Most ideas seemed to center around some sort of RSS feed enabled by default on the desktop.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01347.html

—- YUM: Enable —skip-broken by Default ? —-

Aliasing yum update to yum --skip-broken update was suggested[1] by Steven Moix as a way to prevent a lot of recurring support problems by eliminating dependency problems.

It was attempted[2] to strike a balance between reporting these broken dependencies so that they can be fixed and guarding the list of packages on a user’s system as private information.

A divergent sub-thread delved[3] into the appropriate use of Conflicts: in rpm packages.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01161.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01171.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01349.html

—- Making `updates-testing’ More Useful —-

The means to enable PackageKit to prompt willing users to install testing updates was explored in a thread opened[1] by Matthias Clasen: “Basically, PackageKit should know that these are testing updates, and should ask me ‘There are … package updates available that need testing. Do you want to test these now ?’ For extra points, we could even show a ‘report back’ link somewhere that allows to send comments to bodhi.”

Richard Hughes prototyped a solution but worried[2] that it would be necessary to make changes to the users’ repository configurations without their explicit consent.

A sub-thread discussed[3] the problem of out-of-sync mirrors and the use of the --skip-broken option with yum (see also this same FWN#156”YUM: Enable —skip-broken by Default?”.)

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00925.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01063.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01314.html

—- Fedora Suckage ? —-

The tinder for this week’s massive flamewar was laid[1] by Robert Scheck in the form of a dryly ironic, multiple-topic rant. Robert attacked the use of “memory wasting” python daemons, lags in pushing updates compared to the EPEL repositories, lack of information on the recent intrusion, poor German translation, the minimal requirements for LiveCD usage, RPM-4.6 bugs, Red Hat employees blocking Merge Reviews, PackageKit bugs, and the EU support organisation for Fedora[2]!

Although there were several worthy attempts to make use of the above material for a true conflagration in general the opportunity was wasted and instead several rational, civil discussions of possible underlying causes and explanations took place. There were some worthy attempts to respond to all parts of this portmanteau complaint, but for the most part the discussion fractured naturally into several threads.

One such thread was concerned with the pushing of a D-Bus update which broke many applications including PackageKit. Kevin Kofler argued[3] that “[…] we need to be more careful with certain types of security updates, and better let them get some QA even if it means the fix gets delayed.” Michael Schwendt asserted[4] the lack of active Quality Assurance as one of the contributing factors. KevinKofler explained[5] that the package had been rushed out “Because it was deemed a security update, complete with a CVE ID[.]” See this FWN#156 “The D-Bus Problem” for more details.

Max Spevack took up[6] the complaints about Fedora EMEA and more of that discussion continued[7] on the more appropriate @fedora-ambassadors list.

No further information on the security intrusion was forthcoming from Paul Frields but he relayed[8] that the matter was not being forgotten or hushed up and that he planned to meet with others to discuss communication procedures for any possible future intrusions.

Richard Hughes asked[9] for specific bugs to be filed instead of general rants: “[…] I think you need to write much shorter, to the point emails. Ranting doesn’t have much affect on anything, whilst filing bugs and getting involved upstream does.” He also corrected Robert that many of the daemons which he complained about were written in C, not in Python.

Colin Walters issued[10] a mea culpa: “Just to be clear, the direct push into stable is my fault; not Red Hat’s or other DBus developers or anyone else’s. I had originally listed it for updates-testing, but then changed the update to security and in a moment of total stupidity also changed the listing for stable.”

The idea of “repeatable updates” was raised[11] again by Les Mikesell and critiqued for want of a practical implementation by James Antill. Jesse Keating made[12] a suggestion: “Treat rawhide as your ‘new code’ land, leave the release trees as your ‘testing and working’ code. That is don’t be so goddamn eager to push new packages and new upstream releases to every freaking branch in existence.”

Behdad Esfahbod tackled[13] the issue of Red Hat employees allegedly stalling on merge reviews. Behdad criticized the jumbling together of so many issues and repudiated any suggestion that as the maintainer of un-reviewed packages he “[…] must incorporate the merge reviews and close them, no thank you, I don’t mind not maintaining anything in Fedora, and I certainly didn’t block anyone from making progress in the merge reviews. When you say `The Red Hat people have to follow the Fedora packaging guidelines and rules same as the Fedora folks’, does it mean that Fedora should feel free to decide what *I* work on, when it doesn’t decide what `other Fedora folks’ work on? That doesn’t feel right.”

The criticism of LiveCD localization was handled[14] by Jeroen van Meeuwen and he accepted that it would be useful if there were some manner in which the Spin SIG could create spins and torrent seeds outside of Fedora release engineering. It seemed that the need to make absolutely certain that such torrents and spins are kept available for support purposes may make this difficult.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00722.html

[2] EMEA is a non-profit organization with the mission to provide a focal-point and economic base for the European Fedora community. http://fedoraproject.org/wiki/Ambassadors/EMEA

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00733.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00753.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00855.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00772.html

[7] https://www.redhat.com/archives/fedora-ambassadors-list/2008- December/msg00092.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00773.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00798.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00812.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00832.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00913.html

[13] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00834.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00899.html

—- Help Needed: Sift “rawhide” for .pc Files —-

Jesse Keating requested[1] “[…] somebody to examine all the packages in rawhide that provide .pc [pkg-config] files and ensure proper placement of them based on the review guideline. This will likely require interaction with the packages maintainer(s) so the first step should probably be to produce a list of packages that ship .pc in a non -devel package and send the list (sorted by maintainer) to here so that we can discuss and pick off items.”

Michael Schwendt helped[2] to start the process by providing some lists of non-devel packages which included .pc files or had requires which pulled in packages which provided .pc files.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00612.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00648.html

—- Offtrac —-

An itch scratched[1] by Jesse Keating was to be able to interact with Trac via the commandline to create milestones for the Fedora 11 release cycle. He implemented his own python library, named Offtrac, to interact with trac using XML-RPC and asked for help in firming up the API and extending his client. Later Jesse explained[2] that the purpose was to “[…] make some aspects of using trac easier for folks, not just project owners but people who file tickets in track, like say for package tagging requests, or blocks, or… “

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00738.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00808.html

—- Updates QA and Karma —-

The updates system came in for some more questioning (see this FWN#156 “Making `updates-testing’ More Useful”) when Orion Poplawski showed[1] that an rpcbind update for Fedora 9 may have been pushed to stable despite comments made by him indicating that it failed due to a dependency. Orion asked two questions: “[1] Should update submitters be allowed to give positive karma to their updates? Seems like that they are too biased. [2] Is there any requirement that an update have positive karma before being pushed to stable?”

It appeared that ultimately monitoring of such pushes are down to package maintainers and depend upon the good judgment of those doing the updates. Michael Schwendt provided[2] an overview of the situation.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01298.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01427.html

Bespin - Cloud-based IDE

Mon, 16 Feb 2009 13:10:48 -0500

Hmmm…. very nice. However I still can’t view the Vimeo introduction because it’s in some god-awful Flash wrapper. I’d much rather Mozilla could do something about that:

http://vimeo.com/3195079

Fedora Weekly News#155 - Development

Wed, 10 Dec 2008 14:21:00 -0500

=== The PATH to CAPP Audits ===

Some tough questioning about the purpose and usefulness of the Common Criteria for Information Technology Security Evaluation (CC)[1] was dished out to the maintainers of shadow-utils (the family of secure utilities for manipulating user accounts and passwords) when it appeared that the need to audit specific behaviors was causing some awkward constraints in OS design. The CC certifications are an ISO standard originally developed by the USA’s National Security Agency to specify the expected behavior of systems under certain strictly defined criteria (so called Protection Profiles) to certain levels (Enterprise Assurance Levels). Red Hat Enterprise Linux (a downstream derivative of Fedora) is able to boast several of them, including CAPP,LSPP and RBACPP to EAL4+[2], enabling RHEL5 to be purchased for use in government programs which require “assured information sharing.” See[3][4] for further information. In order to provide the auditing capabilities mandatory to achieve such certifications Steve Grubb and others on his team have been steadily committing changes to Fedora. The specific protection profile under discussion in this case was the Controlled Access Protection Profile (CAPP) and there has been a good deal of unease about the usefulness of such certification in other forums[5].

[1] http://en.wikipedia.org/wiki/Common_Criteria

[2] http://www.redhat.com/solutions/government/commoncriteria/

[3] A good blog entry by Sun’s Jim Laurent: http://blogs.sun.com/jimlaurent/entry/faq_what_is_a_common

[4] https://www2.sans.org/reading_room/whitepapers/standards/1078.php

[5] http://www.schneier.com/blog/archives/2005/12/microsoft_windo.html

When Callum Lerwick noticed[6] that he could not run usermod as an unprivileged user in order to get its help page he suggested that “[…] it and all the other account tools have been changed to mode 750, inaccessible to normal users” and erroneously attributed this to recent changes made to accommodate changes to the PATH environment variable. Earlier discussion of the addition of the sbin directories to users’ PATHs can be found in FWN#146[7]. Jon Stanley replied[8] “These permissions have been in place for over 2 years, with valid reasoning. Just because it’s in your PATH doesn’t mean you should be able to execute it.” Jon appended the 2006 log message which attributed the change to “fix regression. Permissions on user* group* binaries should be 0750, because of CAPP/LSPP certification.” Callum posted a list of all the account tools which had such permissions including the shadow-utils account tools and the audit subsystem tools.

[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00489.html

[7] http://fedoraproject.org/wiki/FWN/Issue146#PATH:.2Fsbin_Tab_Confusion

[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00495.html

Although the change was actually several years old it appeared to cause surprise in many circles and prompted demands for information on what CAPP was and whether it was of any use to the Fedora Project. Steve Grubb responded[9] to the original query that “[…] you cannot do anything with [the user* commands] unless you are root. Allowing anyone to execute them would require lots of bad things for our LSPP/CAPP evaluations” and suggested that man pages should be used instead of running the tools with the --help argument.

[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00501.html

Jesse Keating probed what appeared to be a reliance on restricting execution permissions for security. When Steve corrected[10] this to be “[…] more to do with the fact that we have to audit all attempts to modify trusted databases - in this case, shadow […] if we open the permissions, we need to make these become setuid root so that we send audit events saying they failed” Jesse was even more perturbed[11] and asked “Why would the binary have to be suid? Why can’t the binary detect that [the] calling user is not root, and just print out the usage and a message saying that you have to be root? How would this action make it any less auditable?” Later Chris Adams extended[12] the apparent logic: “[…] cat will have to be setuid root so it can audit? What about echo, bash, perl, etc.? This is absurd.”

[10] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00513.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00523.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00575.html

From this point onwards the confusion and questioning gained in volume and intensity with several points being made to question the usefulness of this particular (CAPP) certification. These included the points that any user could obtain copies of the restricted binaries from outside of the system[13] for nefarious testing purposes; and that there were plenty of other tools[14] on the system which might allow violations of the policy.

[13] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00514.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00626.html

It would be fair to characterize most of the reactions as hostile. Some of this was due to an apparent impatience with “security certifications” which seemed to be of more interest to managers than achieving practical security. Callum Lerwick suggested[15] “[…] just because RHEL has to do stupid ignorant shit to appease certification authorities doesn’t mean Fedora has to do it too.” Another part was undoubtedly due to concern about who had made the decision to follow this path. Jesse Keating expressed[16] some frustration and asked “Who’s ‘we’? Perhaps ‘we’ shouldn’t piss on Fedora in order to meet some cert that I highly highly doubt any Fedora install will find useful.” When Seth Vidal and Dominik Mierzejewski also wondered when, and by whom, the decision was made Steve answered[17]: “By me after a group presented the options back in 2005. Back in those days shadow-utils was in ‘Core’ and that was maintained by Red Hat.”

[15] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00528.html

[16] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00534.html

[17] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00584.html

Another part of the hostility seemed to originate in the novelty of the certification requirements to many participants. Steve answered many queries as they came in and suggested that it was necessary to take an overview of how the whole process worked. He was pressed by Jeff Spaleta for further details. This led[18] to an interesting quote from the CAPP guidelines and the example of how they are applied to shadow-utils. The guidelines make some assumptions which many will find unrealistic, such as the “[t]he system administrative personnel are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the administrator documentation.” While this criticism obviously calls into question the practical usefulness of the CAPP certification it is just one layer designed to perform a specific function, other more apparently useful security can only be built on top of these layers after they are implemented. Steve’s post also contained some interesting practical examples of how administrators can use the audit tools to view information gained by instrumenting the shadow-utils code. To see who has modified accounts, and how, one can:

#ausearch --start this-month -m ADD_USER

#ausearch --start this-month -m ADD_GROUP

A view of attempts to change accounts both through the approved shadow-utils (restricted to root) or other non-approved tools can be obtained with a

#ausearch --start this-month -f /etc/shadow --raw | aureport -x -i

[18] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00585.html

Enrico Scholz pointed out[19] that this seemed like security through obscurity because there were other tools (vipw and ldapadd) which could modify the trusted database and Steve responded[20] that vipw was forbidden and that it would be possible to extend the auditing to ldap if someone had the time. In response to Andrew Bartlett Jesse Keating interpreted[21] this “forbidden” as “`forbidden by policy’ in which using anything /but/ the audit-able tools is `forbidden by policy’. If you’re expecting everybody to follow policy, why not just set policy that says `don’t hack this box’. That’ll work right?”

[19] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00587.html

[20] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00588.html

[21] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00623.html

Callum Lerwick jumped[22] to what was for him the central point: “So I guess this is what all this really comes down to: Do we care about certification?” and asked whether the shadow-utils maintainer(s) would care to put the permissions to a FESCo vote. Steve affirmed[23] that certification was worthwhile with a detailed list of the positive side-effects of the certification process which include: man pages for each syscall, bug fixing and reporting, test suites, crypto work, virtualization with strong guarantees of VM separation and more. It was an impressive list which seemed to counter the dominant assumption that certification was merely another item to be ticked off on a bureaucrat’s mindless list. Steve noted that “[a]s a result, Fedora is the ONLY community distribution that actually meets certification requirements. OpenSuse might be close for CAPP, but not LSPP/RSBAC, but that would be the only one I can think of that might be getting close.”

[22] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00560.html

[23] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00563.html

While this summary might make it seem as though certification is a slamdunk (and your correspondent has to admit a strong bias in favor of it) it has probably failed to convey the sense of unease expressed by Fedora Project contributors that decisions have been taken without discussion or consultation. Jesse Keating asked[24] Steve Grubb to explain who was providing impetus to the shadow-utils/certification team: “Where is this yelling going on? Where are the bug reports? Where is the public discussion about supposed problems in our install processes? Where is the discussion with domain knowledge experts debating whether or not the complaint has merit? Where is the open and frank discussion?”

[24] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00547.html

One possible route around what seems to be an impasse was suggested by Jeff Spaleta. Jeff observed[25] that CAPP certification for putative “appliance spins”, but not the current set of spins, might make sense and asked[26]: “could some of the restrictions like the permissions be handled in a more modular way? Could for example, things be changed so I could install a specialized fedora-CAPP package at install time which tightens up aspects of the system to bring it into CAPP compliance, instead of expressing those restrictions in the default settings of all installs?”

[25] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00556.html

[26] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00625.html

=== The Looming Py3K Monster ===

Last week we reported that Ignacio Vazquez-Abrams was busy shepherding Python-2.6 into Fedora. This week Michael DeHaan raised[1] the question of what the plan for incorporating Python 3K will be. Michael worried that Py3K’s incompatibilities with Python-2.6 “[are] pretty bad for someone who wants to keep a single codebase across EL 4 (Python 2.3) and up, which I think a lot of us do. That gets to be darn impossible and we have to double our involvement with code because we essentially have to maintain a differently-compatible fork for each project.” He asked: “Are we looking at also carrying on with packaging 2.N indefinitely when we do decide to carry 3, because as I know it, the code changes to make something Python 3 compatible will be severe and that’s a big item for any release, and will probably result in some undiscovered bugs even after the initial ports (if applied).”

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00379.html

Although there was some optimism that the “from future import” syntax would allow the use of python-3 features in python-2 Daniel P. Berrange quashed[2] the idea that this was a simple fix because it “[…] isn’t much help if python 2.3, 2.4 and 2.5 don’t support ‘from future import’ and you care about shipping stuff that works on the 99% of deployed Linux boxes today which don’t have 2.6 let alone 3.0.” Basil Mohamed Gohar suggested[3] running the 2to3 tool on the Core packages to gain a sense of what needs to be done.

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00394.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00438.html

Some strategies and their implications were detailed[4] by Toshio Kuratomi in a post which comprehensively explains the options. Toshio suggested avoiding maintaining separate python2 and python3 packages within a single version of Fedora due to the resulting double work and space. He suggested that “[…] this decision is only partially within the powers of the Fedora Project to decide. If 80% of our upstream libraries move to py3, we’ll need to move to py3 sooner. If 80% refuse to move off of py2, we can take our time working on migration code.” In later discussion with Arthur Pemberton he seemed[5] to favor the idea of using python-2.6 while ensuring that all code is as compatible as possible with python-3 and avoided estimating how hard this would be until actual experience is gained with “[…] porting code to 2.6 with 3.x features turned on at some point.”

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00420.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00437.html

James Antill was[6] skeptical that Py3K would be seen in Fedora any time soon due to the massive changes required and the past history (FWN#114[7])of votes on maintaining compatibility packages: “I’ll put money on python3k not being the default in Fedora 12. Hell, I’ll even put some money on it not being the default in Fedora 14, at this point. My personal opinion is that we stay with 2.6.* for as long as possible, giving everyone time to dual port and the problems to be found/fixed and then it “should be easy” to have it as a feature and move for one release. But I’ll point out that Ignacio Vazquez-Abrams did .all. the work for 2.6 in Fedora 11 … so feel free to take this as just my opinion.”

[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00391.html

[7] http://fedoraproject.org/wiki/FWN/Issue114#Policy_Proposal_For_New_Compatibility_Packages

=== PackageKit Stealth Installations ===

Robert Locke asked[1] how createrepo, anaconda-yum-plugins and preupgrade had been installed without his permission on a fresh Fedora 10 install.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00431.html

An answer was posted[2] by Jesse Keating to the effect that this had been done by PackageKit “[…] so that it could offer you the ability to upgrade. We’ve moved that information to a public webserver rather than being in the preupgrade package so that PK can get this information without stealth installing packages.” He added that while there were no “[…] current guidelines that would have caught this […] it does fall into the `don’t do that’ category.”

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00448.html

In further answers Jesse explained[3]: “It was installed so that PackageKit could have the appropriate information to check if there were distro level upgrades (say 9 to 10) available for you. The upstream has been asked to please not install any software in Fedora without a users consent, so hopefully this scenario won’t happen again, at least not with PackageKit.”

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00505.html

=== DNS Resolution Unreliable ===

Previously in FWN#154[1] we reported on some strange name resolution problems. Seth Vidal, as maintainer of the YUM package which looked as though it might be implicated, requested[2] follow-up information.

[1] http://fedoraproject.org/wiki/FWN/Issue154#Strange_Resolution_Problems

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00246.html

Tim Niemuller replied that the problems persisted for him and were probably not to do with YUM. He added failures with svn to the mix and suggested[3] that “[…] yum is [not] the problem but there is a more general problem related to DNS lookups. As a specialty I’m using nss-mdns. But on F-8/F-9 this has never been a problem, so I suspect this is not what is causing the problem, especially because others have the same problem and I don’t think nss-mdns is installed on many machines.”

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00305.html

Jonathan Underwood posted[4] a link to a heavily commented bugzilla entry opened by Tom Horsley on 2008-08-21. The gist of the comments appears to be that with certain DNS servers there is a problem with simultaneous IPv4 and IPv6 requests being sent. A reported[5] work-around involved using a non-glibc resolver such as dnsmasq and was added[6] to the Fedora Project wiki by Christopher Stone.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00308.html

[5] http://www.fedorafaq.org/f10/#dns-slow

[6] https://fedoraproject.org/wiki/Common_F10_bugs#DNS_resolver_not_reliable

Jakub Jelinek prepared[7] a glibc update which temporarily disables the simultaneous requests and Ben Williams promised that once the issue is cleanly resolved the Fedora Unity team[8] will issue a Fedora 10 re-spin.

[7] https://bugzilla.redhat.com/show_bug.cgi?id=459756#c91

[8] http://fedoraunity.org/

Comprehensive SELinux guide for Fedora 10

Tue, 02 Dec 2008 16:27:00 -0500

Murray McAllister has produced a very useful “Security-Enhanced Linux User Guide for Fedora 10”. This integrates a lot of information which was scattered around. Essential reading for anyone running a modern system.

1. http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/ .

Fedora Weekly News#154 - Development

Tue, 02 Dec 2008 11:01:08 -0500

== Developments ==

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

Contributing Writer: Oisin Feeley

=== Python Bump to 2.6 in Rawhide ===

The success of Fedora’s dogged persistence in pursuing an “upstream all
possible patches” methodology was anecdotally highlighted during a
thread in which Ignacio Vazquez-Abrams warned that all Python packages
in rawhide would soon be affected. An apology was made[1] by Ignacio for
a dramatic subject-line (“It’s all ASPLODY!), but he explained that
“[w]ithin the next few days Python 2.6 will be imported into Rawhide.
This means that EVERY single Python-based package in Rawhide will be
broken, and that we’ll need to slog our way through rebuilding it
package by package.” Ignacio suggested that the list of approximately
seven hundred packages could be examined with a:

repoquery —disablerepo=\* —enablerepo={development,rawhide} \
—whatrequires “python(abi)” | sort | less

Ignacio expressed[2] willingness to trigger the rebuilds for some of the
packages but “[…] there’s no way I can get [700] done in a timely
fashion.”

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01809.html

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01813.html

Ville Skyttä asked[3] “[i]f a package installs some *.py, *.pyc, *.pyo
somewhere else than in versioned python dirs, and the source *.py is
python 2.6 compatible, will the *.pyc and *.pyo compiled with 2.5 break
with 2.6?” Ignacio confirmed[4] that such packages should not need to be
recompiled as the API had not changed beween versions 2.5 and 2.6.

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01826.html

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01837.html

Tom ‘spot’ Callaway suggested[5] using a separate Koji tag so that
Ignacio could use a process similar to that which Tom had employed for
the transition from PERL-5.8 to PERL-5.10. Jeremy Katz remembered[6]
that such tagging had been used for past bumping of Python and suggested
“It’s good to at least get the stack up through yum and friends building
and working before thrusting the new python upon everyone as otherwise
it’s quite difficult for people to even try to fix things on their own.”
A list of the essential packages was made[7] by Seth Vidal and
Konstantin Ryabitsev.

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01823.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01815.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01820.html

On the foot of some skeptical questions from Les Mikesell Tom
reported[8] that the end result of following such a process for PERL was
that “[Fedora is] closer to perl upstream than we’ve ever been, and we
have most of the long-standing perl bugs resolved (and we fixed the
“RHEL slow perl” bug without even being aware of it as a byproduct of
the methodology). The fact that you just noticed it means that we must
have done some things properly, you’re welcome. :)”

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01839.html

On 28-11-2008 Ignacio reported[9] that “[…] we’re going to go ahead
and commit 2.6 to Rawhide and start the rebuild of all Python packages
in Rawhide. So please keep your hands off any packages that require
python(abi) until we’re done. Or if you like, you can help out by
bumping the release and building against the dist-f11-python tag.” He
later explained[10] that python-2.6 would appear in rawhide “[…]
within 10 days if all goes well. Then releng will need to fold the tag
back into f11-dist” and confirmed[11] that the version in Fedora 11 will
be Python-2.6.

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02126.html

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02130.html

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02136.html

On 30-11-2008 Ignacio posted[12] the results of the “first cycle of
rebuilds” and categorized the failures into several convenient classes.
On 01-12- 2008 Ignacio posted the results of round two which he
explained[13][14] were “a set of packages that a different net caught. I
used python(abi)=2.5 for the first set in order to get the low-level
packages, and this one uses libpython2.5.so.1.0.” The latest follow-up,
on 01-12-2008 consisted[15] of the list of packages which “[…] contain
compiled Python code but do not have a Requires of python(abi). Please
note that this is a packaging bug as the bytecode is specific to the
version of the Python it was compiled with. Whether this is a problem
with rpm’s macros or with the package itself must be dealt with on a
case-by-case basis.”

[12]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02201.html

[13]
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00014.html

[14]
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00028.html

[15]
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00041.html

=== Power Management and Filesystem Parameters ===

A series of three disk-power management proposals were published[1] as
an RFC by Matthew Garrett. They were generally well-received and
discussion was mostly focused on ways to instrument the kernel to
measure any resulting changes and to ensure that disk lifetimes are
monitored carefully.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02047.html

The first, least controversial, proposal is to get Ingo Molnar’s
relatime patch upstream. An extensive discussion in LWN[2] explains that
this allows applications to keep track of when files have been read
without having to constantly update the last file access time, thus
reducing the number of writes to the disk.

[2] http://www.lwn.net/Articles/244829/

Matthew’s second proposal was to “[…] increase the value of
dirty_writeback_centisecs. This will result in dirty data spending more
time in memory before being pushed out to disk. This is probably more
controversial. The effect of this is that a power interruption will
potentially result in more data being lost.” The third proposal was to
enable laptop-mode[3] by default in order to mitigate the second change.

[3] cat
/usr/share/doc/kernel-doc-2.6.27.5/Documentation/laptops/laptop-mode.txt

EricSandeen was interested[4] in how Matthew would measure the effects
on power and performance, whether it was possible to identify individual
applications causing disk accesses, and whether disk spin-down should be
considered. When Matthew replied[5] that it would be difficult to
monitor disk access without causing further disk access David Woodhouse
suggested using blktrace and this was eagerly recognized[6] by Matthew
as exactly what he needed.

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02048.html

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02052.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02093.html

Eric’s spin-down suggestion was confirmed: “Yes, the long-term plan
involves allowing drive spindown. I’m hoping to do this adaptively to
let us avoid the spinup/down tendancies a static timeout provides, but
you’re right that monitoring SMART information would be a pretty
important part of that. I lean towards offering it on desktops and
servers, but not enabled by default.”

Phil Knirsch posted[7] that he was working on similar ideas currently
including “the idea if a combination of a monitoring backend and a
tuning engine could provide an automatic adoption of the system to the
current use. E.g. during daytime when a user works with his machine we
would typically see quite a few reads and write all the time. Drive
spindowns or other power saving features could during that time be
reduced so that the user will have the best performance. During the
night (in case he didn’t turn of the machine) only very few read and
even fewer write operations should happen, at which time the disk could
then be powered down most of the time. And of course this can be
extended to not only disk drives but other tunable hardware components.”

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02089.html

Some of the pitfalls of choosing defaults for all users were exposed
when Ralf Ertzinger and Phil disagreed[8] on the ideal behavior of
logging mechanisms. Phil drew a distinction between system logging
mechanisms and user application logs and argued that losing data from
the latter was not as important. Dariusz Garbowski put[9] the point of
view of “Joe the User”: “He cares a lot that he lost last hour of his
xchat (or whatever he uses) logs. He quite likely doesn’t care about
last hour of syslog messages (he may not even be aware they exist in the
first place)…”

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02099.html

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02137.html

See FWN#88[10],FWN#100[11][12] for previous discussion of
power-management in Fedora.

[10]
https://fedoraproject.org/wiki/FWN/Issue88#PowerTOP_Release_Opens_Up_New_Directions_In_Power_Saving

[11] http://fedoraproject.org/wiki/FWN/Issue100#Disabling_Atime

[12]
http://fedoraproject.org/wiki/FWN/Issue100#Reducing_Power_Usage_Of_Fedora

=== Strange Resolution Problems ===

A report of a strange name resolution problem was made[1] by Mark
Bidewell. Yum failed to download the Adobe flash-plugin with an error:
[Errno 4] IOError: <urlopen error (-2, ‘Name or service not known’)>
Trying other mirror.” , yet it was possible to download it directly over
HTTP using the browser.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02002.html

Christian Iseli added[2] that he had a similar “[…] issue which seems
to be due to some sort of DNS lookup problem. In my case I’d get the
‘Name or service not known’ for download1.rpmfusion.org.” Christian’s
troubleshooting revealed that specific sites (linuxdownload.adobe.com
and download1.rpmfusion.org) were consistently resolved with ping or
firefox but failed with wget and ssh. Moreover: “Putting the IP
addresses in /etc/hosts “works around” the problem[.]”

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02071.html

Following some questions from Seth Vidal nothing seemed[3] obviously
wrong and the mystery remains.

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

=== Cron Confusion ===

Pavel Alexeev asked[1] for guidance on how to correctly rpm package a
cron job. The specific requirement was a cronjob that ran every twenty
minutes and might thus use the /etc/cron.d directory provided by cronie
,the SELinux and PAM aware derivative of vixie cron. Pavel wondered how
he could make a package which would work for both variants of cron.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02179.html

When Martin Langhoff confirmed that /etc/cron.d was necessary Pavel
replied[2]: “[…] /etc/cron.d [is] provided only by cronie [and] now we
have several other crons in the repositories[.]” He listed several other
implementations of cron found by a

# repoquery ‘*cron*’ | egrep -v ‘^(yum-cron|PackageKit-cron|cronolog)’

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02182.html

Ignacio Vazquez-Abrams corrected[3] him: “The only replacement for
cronie in that list is fcron. Feel free to log a bug against it.” Till
Maas and Pavel noted[4], however, that the /etc/cron.* directories were
also provided by the package named crontabs.

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02183.html

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02187.html

Patrice Dumas posted[5] the welcome news that he was “[…] currently
preparing a fcron sub-package that would be completly compatible with
cronie and would watch /etc/cron.d (using inotifywait). I’ll keep the
list informed.”

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02187.html

=== Man Pages to be Mandatory and Upstreamed ===

A vigorous thread flowered from the promising seed planted[1] by Michael
Cronenworth in which he advocated getting rid of all current
documentation: “Yes, what I’m about to describe should obsolete man,
info, and all the other dozen “help” documentation found in all the
Fedora packages.” Michael proposed that a new, lightweight standard of
some sort would solve the problem of missing documentation.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02015.html

During the course of the week there have been requests for
“NetworkManager cli docs”[2] and “PulseAudio info needed”[3] in which
the desired information has mostly been found on external web pages
instead of in documentation supplied with the OS.

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01757.html

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02041.html

Richard W. M. Jones suggested[4] instead that the Debian model should be
followed: “Debian forces all programs to come with a man page. If one is
missing, this is considered a bug and packagers have to write one.”
Patrice Dumas was[5] against compulsion and preferred leaving the choice
to the packager.

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

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02025.html

The idea of upstreaming the man pages was introduced[6] by Thorsten
Leemhuis: “One reason for that: If you add man pages from debian to a
fedora package then you have to recheck every now and then if the man
pages are still up2date. That afaics often tends to be forgotten (I’m
guilty myself here).” Richard agreed[7] and in the course of several
clarifications made the strong point that “[…] it’s a really useful
feature of Debian that _any_ command, any many configuration files and
other files, are documented using ‘man’. I find it a big negative
against Fedora that things aren’t so consistently documented.”

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02024.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02050.html

There seemed to be little disagreement on the desirability of providing
more information but Michael was not impressed[8] with Trond Danielsen’s
suggestion that yelp would fulfill his requirements: “[…] it lacks in
the lightweight department. It eats 40 megs of RAM upon startup and more
RAM once searching occurs or pages are opened. Sure, we’re all getting
gigabytes of RAM these days, but it’s a HELP tool with TEXT.” Basil
Mohamed Gohar was inspired[9] to “[write] or two man pages, because I’ve
run into the missing-man-page problem too often.” He suggested a very
reasonable sounding action plan for identifying missing man pages and
then filling them in with at least stubs in order to form a SIG which
would work on providing quality replacements. Gergely Buday also
seemed[10] interested.

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00004.html

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00023.html

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00060.html

Fedora Weekly News #153 Developments

Tue, 25 Nov 2008 15:45:00 -0500

== Developments ==

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

Contributing Writer: Oisin Feeley

=== More and Wider Testing ===

In a thoughtful post Callum Lerwick suggested[1] that Fedora testing
coverage could be improved in several inter-related areas. These
included making Bugzilla easier to use; adding per-package rollbacks to
enable reversion to known good states; blocking yum updates on specific
reported bugs; providing a rescue image in /boot with the aforementioned
functionality; and lastly, enabling simple installation of specific
updates which might fix said reported bugs. Callum asked for respondents
to eschew what he called the “Hard problem fallacy” which consisted of
minor technical objections and asked them to provide answers modeled on
the pattern of “You are an idiot and your ideas are stupid. We’re not
doing this.”

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01370.html

On the subject of rollbacks Jef Spaleta objected[2] that it was
complicated by the triggered scripts in packages. Currently there are no
tests for rollback and Jef wondered “…how do you set up a test which
attempts to measure whether rollback across a trigger boundary put you
back to where you were? How much of a different in state counts as
‘break rollback’ ?” He then added the problem of Obsoletes: “When an
obsolete is introduced in an update… can we rollback and get what we
had?” He finished off with the suggestion that Carrier Grade Linux might
have some experience to offer as they had attempted rollbacks. Seth
Vidal remembered[3] that “[…] the rollback functionality the CGL
wanted was removed from rpm recently.” Gilboa Davra asked[4] how it
would be possible to pin-point what exactly had broken when there was a
“150 package update push. Will you rollback all the updates? Only the
updates that had _something_ to do with the breakage?” RalfCorsepius
also nixed[5] the idea as “[…] package rollbacks will never work in
general, because updates may contain non-reversable statefull operations
(e.g. reformatting databases).”

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01394.html

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01396.html

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01409.html

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01442.html

A comprehensive reply was made[6] by Gilboa Davra. In it he argued that
automating bug reports lowered the signal-to-noise ratio considerable
and objected to modification of yum to refuse updates until reported
bugs are fixed: “Say-what?!? Are we building a second Vista here?”
Although he liked the idea of a rescue image in /boot he cautioned that
space considerations impinged upon the need to keep “[…] a different
rescue image for each installed kernel unless you plan to keep the
original kernel[.]” As regards selective updates he stated: “You can
always enable updates-testing and selectively install what you need.”

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01409.html

A preliminary step was added[7] by Chris Lumens to those listed by
Callum: “I’d like to add a step (0) before we make bugs easier to file
and really crank up the number of reports we’re getting: (0) More people
FIXING the bug, not just reporting them. You can have a giant user base
of people filing tons of bugs, and you can have a motivated and
effective QA/Triaging team whittling them down to the really important
and reproducable bugs. But without more people fixing them, the backlog
is just going to continue to build.”

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01421.html

When Peter Lemenkov wondered[8] why users were forced to register on
Bugzilla Bill Nottingham underscored[9] the need for tools which do not
swamp developers with large numbers of bugs. Alan Cox added[10] that the
key was “[…] one clear and accurate bug report that happens to contain
the right information and the user willing to help.” Daniel P. Berrange
further explained[11] that “[…] 90% [of bugs] are essentially useless
when first reported. It requires several back/forth interactions between
myself & the bug reporter to get enough information to diagnose &
resolve the problem. If we create a system where we bombard maintainers
with bugreports & no scope for user interaction they’ll end up directly
in /dev/null, and further discourage maintainers from addressing even
bugs with enough info.”

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01408.html

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01399.html

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01415.html

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01422.html

The Ubuntu tool apport was discussed[12] as a possible solution several
times as was[13] the Debian tool reportbug.

[12]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01428.html

[13]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01456.html

An emphasis was placed[14] on providing Bugzilla tools for developers
and packagers by James Antill: “I won’t mind getting 666 dups, or
dealing with 10x as many bugs in general, as long as I have a decent
local tool that can manage that number of bugs. Atm lots of TABs of open
bugs, and giant folders of BZ email are the best tools I’ve seen.”

[14]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01492.html

KarelZak jumped[15] straight to the original question and answered that
testing participation was low “[…] because this work is not
attractive. It’s boring work without proper credit in open source
community. It’s very simple to found list of top-ten kernel developers,
but who knows the most active bug reporters or QA around kernel? Nobody.
People who are testing a software are real contributors. Our THANKS to
them should be more visible!”

[15]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01696.html

=== Source File Audit Catches RPM Problems Early ===

Kevin Fenzi posted[1] the results from the latest run of his
sources/patches URL checker script. There were 912 possible problems
reported, which Kevin noted was “Up from 662 last run. This is a pretty
sad increase.”

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01433.html

Happily many of the reported problems appeared[2] to be due to either
temporary problems with GoogleCode and SourceForge project hosting or to
some minor oddities in the script. Many of the other highlighted
problems were confirmed as genuine and fixed by the package owners.

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01450.html

Ian Weller contrasted[3] a successful run of spectool -g[4], which uses
wget internally, with the failure of Kevin’s script. Later Kevin also
found[5] a similar result when examining another failure. He speculated
“[…] it’s working fine with a wget… perhaps they are blocking the
agent that spectool -g uses? (which I am not sure what it reports).”
Ville Skyttä offered[6] that “spectool -g uses plain wget, with
configuration file /etc/fedora/wgetrc if it exists, otherwise usual
system wget configs” and Thomas Moschny discovered[7] that “spectool
uses -N, which seems to cause 404 errors with googlecode[.]” Jaroslav
Reznik confirmed[8] this: “Same for me - it’s not working for googlecode
downloads. Wget with -N param sends HEAD instead GET - these two are
same, but HEADs response are only headers - it’s used for links
validation etc… But looks is it misconfiguration on server side?” and
thanked Kevin for the usefulness of his script which had caught a
serious problem.

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01434.html

[4] The spectool utility is part of rpmdevtools. It downloads and
extracts sources and patches to build RPMs

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01451.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01454.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01459.html

Eric Sandeen asked[9] if it would be a good idea to extend rpmlint to
perform these checks: “I’m most likely to fix this stuff if I’m in the
middle of making some other change, and an automatic check while I’m
working on a package that says `hey your source URL is no longer valid’
would probably provoke me to fix it quickly. :)”

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01466.html

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01641.html

=== One Issue Tracker to Rule Them All ===

Arthur Pemberton examined[1] the challenge issued by Callum Lerwick to
improve Bugzilla (see this same FWN#153 “More and Wider Testing”.) He
asked for a list features which distinguished Bugzilla from competitors.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01430.html

The ability of Bugzilla to deal with a massive number of “products,
components, users, hits per second [with] clustering databases and
similar magic” was advanced[2] by Matej Cepl as the most compelling
reason. Nicholas Mailhot added[3] “feature completeness, familiar UI,
integrating with upstream issue trackers (which are often bugzilla too)”
and Emmanuel Seyman suggested[4]: “And as an encore : it has to contain
109900+ bugs of existing data so that we don’t lose any history.”

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01470.html

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01477.html

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01483.html

A certain amount of impatience with the general idea was expressed[5] by
Matej Cepl when he agreed with Andrew Cagney that one essential feature
would be a “push upstream” button: “AMEN!!! And I think we should
concentrate on this rather than doing stupid bugzilla rewrites. Sorry,
for being harsh, but it is so IMNSHO.” Emmanuel Seyman warned[6] that it
would be necessary to map users, bugs and components across any separate
upstream/downstream instances of bugzilla. He later expanded[7] upon
this: “Bugzilla has gained the abilty to customize statuses and
resolutions, making it even harder to push bugs from one bugzilla to
another with prompting for user interaction.” LaunchPad[8] was
discussed[9] as possibly providing this feature. Casey Dahlin noted[10]
that cross-site integration was still not implemented “[…] because
there should never ever ever be two independent sets of launchpad data
ever, according to their philosophy [.]”

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01611.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01615.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01622.html

[8] Canonical’s collaborative hosting service https://launchpad.net/

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01616.html

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01539.html

Till Maas suggested[11] several interesting improvements including
“[…] the possibility of having several people beeing responsible for a
Component, which is currently only partly possible. There is the initial
CC list, but when a bug is reassigned to a different component, the
members of the initial CC list of the old component are not removed from
the list.” Other desiderata included storing the NEVR of a package in a
dedicated field and support for the same bug across several different
releases.

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01612.html

The issue of how bugs can actually be fixed cropped up again in the
discussion. Brennan Ashton suggested[12] that triaging bugs was an area
in need of volunteers and provided a link[13] to the BugZappers wiki
page.

[12]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01704.html

[13] https://fedoraproject.org/wiki/BugZappers

=== RFC: Fix Summary Text for Lots of Packages ===

Richard Hughes wished[1] that the Packaging Guidelines on summaries and
descriptions would be followed a little more closely as “[q]uite a lot
of packages have summary text that is overly verbose, and this makes the
GUI and output from pkcon look rubbish.”

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01484.html

Josh Boyer warned[2] against making reviewers’ jobs harder by codifying
too much in the package guidelines and suggested: “Just file bugs for
packages you think are overly verbose. Offer alternate summaries in the
bug, and a URL to your email for rationale.” Bill Nottingham was[3]
dubious that “[…] this scales across 5000 packages. So it would be
good to have at least *something* in the guidelines.” When Richard
compromised on a “soft guideline such as: Summary should aim to be less
than 8 words” David Woodhouse gently poked[4] fun at this summary as
being too wordy.

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01487.html

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01489.html

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01493.html

Toshio Kuratomi expressed[5] disapproval of soft guidelines due to their
potential for sparking many individual disagreements instead of one
single point of contention being handled by the Packaging Committee.
Richard seemed happy enough with Toshio’s suggestion[6] that the
packaging guidelines contain a “best practice” description with
examples.

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01495.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01499.html

When Bill Nottingham raised[7] the possibility of “summary collisions”
Jef Spaleta threw out[8] an analogy based on searching for medicine in a
grocery store in a foreign country. This was intended to stimulate
clarification of the function of summaries. Toshio Kuratomi loved[9] it
and suggested that summaries were like the “[…] little advertising
gimicks seen on and alongside the other things on the bottle. Things
like: “New!”, “Larger size”, [Picture of grapes and smiling child], etc.
They’re differentiators that “help” you choose one product over
another.” He provided some concrete examples which seemed to prove his
case.

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01520.html

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01536.html

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01569.html

Michal Hlavinka worried[10] that yum search <keyword> would be disrupted
but Michael Schwendt re-assured[11] him that “‘yum search’ also searches
the package %description. And the description is the place where to be
much more verbose than in the summary. The %summary is not made for
searching, but for enabling the installer and packaging tools to to
display a brief and concise package description or a list thereof. That
means, put a few relevant keywords in the summary (newspaper
headline-style at most), but avoid long/complete sentences as often as
possible. That also makes it easier to fit into one line.”

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01500.html

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

Later Richard asked[12] for opinions on a sample email which he intended
to send out to some maintainers to alert them to their long package
summaries.

[12]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01640.html

Andrea Musuruane, as an RPM Fusion packager, felt[13] that packagers’
time would be wasted in following the proposal and that a “Summary is
something that the packager should choose on his own. It must be less
than 80 characters and _maybe_ it should not contain the package name.
Everything else is just marketing. If someone thinks that adding the
fact that the application is based on Gnome, it is fine for me. If
someone else thinks that mentioning that other application uses DBUS it
is fine for me too.” Richard clarified[14]: “I’m _not_ saying “change
your summary or we’ll drop your package” I’m asking them to come into
line with 90% of the other packages in the distro. I’m even offering to
do the cvs commit myself, if they give me the new summary line.”

[13]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01654.html

[14]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01656.html

The issue of these changes being made solely to accommodate PackageKit
was addressed[15] by James Antill: “The fact that a single tool decided
that summaries should be used instead of names, and so summaries should
be roughly the same size of names shouldn’t make Fedora packages break
their summaries for other tools … all IMO.” When Emmanuel Seyman
asked[16] exactly how GUI packaging tools made the summary more
prominent than the package name Richard Hughes responded[17] that it was
actually one, but one that was exposed in many places. Emmanuel’s
response was blunt: “FWIW, I don’t appreciate our maintainers being lied
to. The vast majority of them work hard to make their packages and I
believe that a minimum of respect should be shown […] it is a case of
changing one application versus changing 500.” Ville Skyttä took[18] an
overview which left the current user-interface of gnome-PackageKit aside
and concentrated on whether there was agreement that rpmlint should be
taught to check that the package name should not be repeated in the
summary.

[15]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01683.html

[16]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01672.html

[17]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01713.html

[18]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01673.html

Further criticism was made[19] by Christopher Wickert of sorting
packages by description instead of name in PackageKit and Tom Lane
raised[20] the problem of sub-packages needing to reference the name of
their parent package. At this stage it seemed that some consensus had
been reached on the idea that summaries which repeated the program name
were frowned upon and that “verb phrases” should be also be deprecated
as suggested[21] by Ignacio Vazquez-Abrams.

[19]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01721.html

[20]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01733.html

[21]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01532.html

A brief dispute between Andreas Musuruane and Michael Schwendt yielded a
closing statement which seemed[22] to make the case of those that favor
the changes in a strong manner. Michael accepted that: “[i]t isn’t
trivial to come up with good one-line summaries that do more than
repeating the program name. It’s nothing packagers like to spend time
on. Reducing a packager’s freedom even further won’t be a good thing
[…] I think with some people one could argue endlessly about pkg
summaries. And during pkg reviews that’s wasted time. Still, with very
old repositories it has been noticed [and agreed on, mostly] that some
types of summaries simply look poor in Anaconda and package management
tools. That was the rationale for some of the recommendations.”
RichardHughes noted[23] that over the last forty-eight hours many
maintainers had changed their package summaries as requested.

[22]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01753.html

[23]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01764.html

=== Smock: Simpler Mock for Chain Building ===

A couple of announcements were made by Richard Jones. The first was of a
new version of OCaml. The second was[1] of a wrapper script that “[…]
runs on top of mock, allowing you to chain-build a series of RPMs from a
single command.” An example which would “[…] arrange the SRPMs into
the correct order according to their BuildRequires, then build each in
the four separate mock environments Fedora {9,10} {i386,x86_64}” was
provided:

smock.pl —arch=i386 —arch=x86_64 \
—distro=fedora-9 —distro=fedora-10 \
*.src.rpm

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01229.html

Till Maas suggested[2] that local file access URIs[3], such as file:///,
could be used to avoid the need for a webserver and Paul Howarth
confirmed[4] that he had been using mock “[…] like this for *years*
with loopback-mounted ISO images for a low-cost source for the base
repo. It definitely works.”

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01232.html

[3] See RFC1738 section 3.10 http://tools.ietf.org/html/rfc1738

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01264.html

Seth Vidal asked[5] why the wrapper approach had been taken instead of
integrating the functionality into mock and Richard agreed[6] that this
should happen. An initial problem with build requires of the form
“%{name}-devel” failing was quickly fixed[7].

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01238.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01239.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01354.html

Small Sample-size Cross Validation and Bootstrapping are Unreliable

Tue, 25 Nov 2008 15:38:00 -0500

25 years of conventional evaluation of data analysis proves worthless in practice

Nice paper from Isaksson & Gustafsson at Uppsala which appears to demonstrate the unreliability of bootstrapping and cross-validation when the ratio of sample size to natural variation is too low. The problem is that it’s difficult to know what the natural variation is when you’ve got a small sample size. Looks like Bayesian confidence intervals may provide a sobering reassesment of many medical trials. See also the Ioannidis PLoS paper and E.T. Jaynes.

Fedora Weekly News#152 - Developments

Mon, 17 Nov 2008 10:53:00 -0500

Developments

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

Contributing Writer: Oisin Feeley

Features Policy Modified

The latest FESCo discussions (2008-11-12) clarified[1] the Features[2] process. The changes make explicit the need for testing to be complete one week prior to the final freeze. Failure to meet that condition can result in FESCo deciding to drop the feature or implement a contingency plan or other suitable action.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00847.html

[2] Features are “a significant change or enhancement to the version of Fedora currently under development”: http://fedoraproject.org/wiki/Features/Policy/Definitions

The spur to these discussions was several last-minute changes for Fedora 10 which included dropping the instant-messaging client Empathy as the default, and the late addition of LiveConnect (see FWN#151[3]) and AMQP[4]. Earlier confusion about the Feature process and difficulties with communication had also been expressed (see FWN#147[5]) after the decision to drop the Lightweight X11 Desktop Environment as a feature.

[3] http://fedoraproject.org/wiki/FWN/Issue151#LiveConnect_Feature_Approved_for_Fedora_10

[4] The Advanced Messaging Queue Protocol is a vendor-neutral middleware transport for business processes: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol

[5] http://fedoraproject.org/wiki/FWN/Issue147#LXDE_Feature_Removal_Disappointment_-_How_to_Avoid

The other major changes to the process include the emailing of the Feature owner to inform them when their feature is being discussed by FESCo and any decisions made concerning said feature. The extra work involved in tracking down email addresses was anticipated to be an over-burdening of the committee chair, Brian Pepple. To ease this problem it was decided that Feature owners must include current email addresses on their Feature pages.

Server SIG

DanHorák announced[1] that a “[…] formal entity to coordinate […] the server fundamentals that later create a successful enterprise product […]” had been launched as a SIG. He invited constructive ideas and the wiki page[2] suggests that the SIG has many important initial goals including: a spin for headless servers, CLI equivalents of GUI tools, a lightweight installer and maintenance of the /etc/sysconfig/network-scripts.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00645.html

[2] https://fedoraproject.org/wiki/DanHorak/ServerSIG

The extensive discussion which followed mostly consisted of approval for the idea. Dennis Gilmore expressed[3] enthusiasm for the general idea and specifically requested kickstart files for different types of servers and “best practice” whitepapers. An example of one of the issues the SIG might deal with was[4] the observation by Chris Adams that an installation of ntop had resulted in seventy dependencies, including metacity, being pulled down. Peter Robinson attributed[5] this to graphviz and suggested that while such problems were declining in number it would be useful for the ServerSIG to co-ordinate bug filing for these issues. Chris provided[6] a script which allowed test installs into a subdirectory to determine “what gets pulled in.” Later James Antill mentioned two useful scripts written by himself and Seth Vidal which show package dependencies and provides as a tree structure. Dominik “rathan” Mierzejewski added[7] a mention of rpmreaper, a utility which eases the removal of unnecessary dependencies.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00652.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00730.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00736.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00778.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00932.html

After Chris observed that “[w]ith rawhide, it appears impossible to install a kernel without pulling in X libraries (because of plymouth), so I guess the base X libraries can be considered “core” now” the conversation took a more adversarial turn. The accuracy of this statement turned out[8] to depend on whether libpng and pango were considered to be “X libraries” and Chris demonstrated the dependency chain as originating with the plymouth-plugin-solar. Les Mikesell commented[9]: “This is all pretty strange from a server perspective. And plymouth is there to keep the screen from blinking while you boot?” When Jesse Keating replied that Plymouth “handl[ed] the passphrase prompting for encrypted volumes” Les argued[10] that it should be optional for remote, headless boxes. Dominik “rathann” Mierzejewski was shocked[11] when Jesse Keating pointed out that plymouth also provided working /var/log/boot.logs: ” Hm, you’re right, all my boot.log files are 0 bytes (F-9). So instead of fixing the bug, a new package was introduced? Amazing.” Dominik’s dissatisfaction continued[12] to be unabated when he was informed that the absence of the kernel commandline parameter “rhgb” would result in plymouthd running but without any graphical plugins.

[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00787.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00787.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00795.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00814.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00859.html

The automatic selection of plymouth-plugin-solar as opposed to the alternate “plymouth-text-and-details-only” resulted[13] in a discussion around whether it was possible to make yum behave differently in such ambiguous situations. Enrico Scholz wished to add a “fail, warn and/or prompt when multiple packages satisfy a (virtual) dependency[.]” Seth Vidal reminded[14] him that the constraint of non-interactive defaults meant that this might not work. James Antill posted[15] that he had a patch to yum which “[…] would allow Fedora (or any active repo.) to configure these choices manually. We could then also easily have different defaults for the desktop vs. the server spins.” James received some questions from Jesse Keating and Bill Nottingham who asked how per-spin defaults would be stored and how to deal with conflicting information from multiple repositories. His answer suggested[16] that introducing new repositories for the metadata or changing its syntax would be necessary.

[13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00858.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00907.html

[15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00995.html

[16] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01030.html

Dan Horák’s desire to remove plymouth entirely was dismissed[17] as non-optional by Bill Nottingham as it will take on an even more important role in storage handling in the future. Bill suggested that the default plugin was optional however. He reassured[18] Dan that as regards headless machines there had been “[…] some testing on PPC boxes via serial/hvc consoles. Please test that it works in your scenarios as well, of course.” When Enrico Scholz rejected disk encryption as important for servers Jesse Keating made[19] the case that “In a colo environment I /would/ want some encryption on the disk, and if I have to use a remote kvm to input the passphrase at reboot time, that’s OK. Reboots are either planned events, or emergencies, both of which are going to require the attention of the people who have the passphrase.” Alan Cox backed[20] this up: “If you are storing personal data on a system in a colo its practically mandatory to have encryption, and if you are storing anything sensitive its a big deal indeed - at least in those parts of the world with real data and privacy law ;)”

[17] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00784.html

[18] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00792.html

[19] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00798.html

[20] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00823.html

The thread continued in fits and starts. Adam Tkac raised[21] the problem of handling static IPs with NetworkManager (see this same FWN#152 “NetworkManager keyfiles for Pre-login Static Routes” for a discussion of as yet undocumented features). Chuck Anderson disputed[22] that the problem existed and provided commandline and GUI solutions: “[…] for system-wide connections which you would presumably want for a server, you edit /etc/sysconfig/networkscripts/ifcfg-* as usual and NM will bring the interface up at boot. From the desktop, you can Edit Connections and create a new static connection and select it instead of the System or Auto connection which is very handy when moving between networks that don’t support DHCP.”

An important addendum was provided[23] by Olivier Galibert “Try a “chkconfig -list network”. It should be on for levels 2-5. If it isn’t, you haven’t enabled the old-style networking [.]” The same point was made by Chuck[24] “Are you using NetworkManager or network service? chkconfig -list NetworkManager; chkconfig -list network If NetworkManager is enabled and network is not, then you need to change ifcfg-eth0: NM_CONTROLLED=yes” and by Bill Nottingham[25] “You need to either set NM_CONTROLLED to something other than ‘no’, or enable the ‘network’ service. In either case, NM’s static network support is not your problem.”

[21] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00863.html

[22] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00871.html

[23] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00892.html

[24] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00887.html

[25] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00938.html

The LSB[26] also came in for a bashing due to infrequently used, old tools (such as ypbind and the insecure r-commands) being installed to achieve compliance. Patrice Dumas clarified[27] that ypbind was necessary in @base to provide NIS functionality. Later discussion separated[28] out LSB-Core and LSB-Desktop which should simplify making a minimal install LSB compliant. Bill Nottingham and Chris Adams performed[29] a dissection of @core with the intent of separating out items such as hdparm , prelink , dhclient , ed and others into @base.

[26] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00718.html

[27] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00753.html

[28] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00759.html

[29] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00802.html

Jeremy Katz outlined[30][31] a perspective from the Quality Assurance point of view. The burden imposed by preserving the modularity that many of the participants advocated sounds quite high: “[…] trying to preserve that modularity combinatorially adds to the testing matrix and also makes it significantly more difficult to write code since you can no longer depend on functionality. It also makes things slower as you have to conditionally check for things constantly […] It’s more than just /etc/init.d/network that has to be maintained. There’s oodles of stuff in install-time configuration that will have to be maintained, tested, and have things fixed when people report them.” Seth Vidal acknowledged[32] this but cautioned against dismissing the objections to particular changes as merely “neoluddite”.

[30] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01023.html

[31] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01025.html

[32] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01027.html

The massive thread included much more discussion and resists easy summary. Those interested should probably plow through the messages. Among the issues raised were finding DBus documentation[33] and contention between class devices to set default routes[34].

A quote from DanHorak which seems to offer the perspective of the ServerSIG concisely is appropriate in closing: “It is really time to look back at the roots of Unix systems. It should be a combination of small pieces with well defined interfaces doing well their tasks. Only the time had changed those pieces from simple command line utilities to more complex ones.”

[33] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01071.html

[34] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00911.html

NetworkManager keyfiles for Pre-login Static Routes

In the course of the ServerSIG discussions (see this same FWN#152 “Server SIG”) an interesting question about NetworkManager was asked[1] by Les Mikesell: “If you bring up a mix of static and dynamically assigned interfaces, can you control which gets to assign the default route and DNS servers?”

[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00872.html

Dan Williams provided[2] a useful description of how NetworkManager currently decides the default route. In response to Olivier Galibert he added[3] that static routes could be set up using the “[…] connection editor see the “Routes…” button in the IPv4 tab. Routes from ifcfg files aren’t yet supported, but could be. Routes from keyfile-based system connections (ie, prelogin) are supported.” After this tidbit Chuck Anderson prodded[4] Dan into explaining that keyfiles were a way to support things like “VPN, 3G, WPA” which were difficult or impossible to support with the ifcfg files in /etc/sysconfig/network-scripts. “NM has a system settings ‘keyfile’ plugin that allows editing system connections from the connection editor, or your favorite text editor if you don’t use a GUI at all. Add `,keyfile’ to the —plugins argument in the /usr/share/dbus-1/systemservices/org.freedesktop.NetworkManagerSystemSettings.service file, and then ‘killall -TERM nm-system-settings’.”

[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00880.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00897.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00900.html

Jesse Keating wondered when and where the documentation for this was placed and Dan replied[5] “[w]hen I struggle up for air from the tarpit that is the concurrent release of NM 0.7 + F10 + RHEL 5.3? :) “

[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00912.html

Flash 10 in 64-bit Fedora 9

Jos Vos asked[1] for comparative data on using nspluginwrapper with Firefox to access Flash content in 64-bit Fedora 9. He was experiencing “[…] error messages about not finding ‘soundwrapper’ in my $PATH [.]”

[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00432.html

Although Chris Adams reported success Orcan Ogetbil described[2] a “gray rectangle bug” which seemed to be manifested mostly when multiple tabs were open. Brennan Ashton claimed[3] that it was due to a PulseAudio “bug”.

[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00439.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00443.html

Ignacio Vazquez-Abrams and others reported[4] no problems and Jos posted[5] that there appeared to be a dependency on libcurl.i386 in the Adobe supplied rpm. This was later stated[6] by Paul Howarth to be changed so that either libcurl.so.3 or libcurl.so.4 will be used via a dlopen() and there is no explicit requires:libcurl in the rpm. Gianluca Szforna supplied[7] a link[8] which suggests that libflashsupport should be completely removed as it may cause crashes.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00437.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00445.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00479.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00484.html

[8] http://macromedia.mplug.org/

Non-dictionary attack on WPA-TKIP

Sat, 15 Nov 2008 08:28:00 -0500

Martin Beck and Erik Tews present[1] an attack on WPA-TKIP. Seems to depend on 802.11e QoS features to implement a chopchop attack. A re-keying interval of < 120s is suggested as a counter-measure.

The way chopchop attacks work is to “chop” off the last byte of a packet and iterate adding each of the 256 possible values for the packet back on and attempting to get the AP to rebroadcast it. Once a packet with the correct dst-mac is seen being re-broadcast then the corresponding correct value is known. This approach was originally applied by KoreK to WEP.

A follow up article on NetworkWorld suggests this is a big problem because of customers assuming that WPA was safe enough.

1. http://dl.aircrack-ng.org/breakingwepandwpa.pdf

2. http://www.networkworld.com/news/2008/110608-once-thought-safe-wpa-wi-fi.html?ts0hb&story=ts_wpahack

Fedora Weekly News #151 - Developments

Mon, 10 Nov 2008 13:08:50 -0500

Developments
1.2.1 Security Exceptions to the Mass ACL Opening
1.2.2 Who Moved My Bug ?
1.2.3 HOWTO: Get an SELinux Policy Change
1.2.4 Comps Czar Appointed to Encourage Modifications
1.2.5 LiveConnect Feature Approved for Fedora 10

== Developments ==

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

Contributing Writer: Oisin Feeley

=== Security Exceptions to the Mass ACL Opening ===

MichaelDeHaan initiated[1] discussion on why he had chosen not to open access (previously covered in FWN#148[2], FWN#136[3]) on some of his systems management software packages. His main reasoning was that
obtaining provenpackager[4] status was too easy and could lead to at
least two undesirable security outcomes: “(A) provenpackager decides to correct what he thinks is an rpmlint error and thus unintentionally breaks the security of the packaged application, (B) credentials of provenpackager are compromised allowing $evil to replace the contents of a said package. In either case, the change could either be making a new release of an application (which contains an exploit and/or unwitting bug), or updating the specfile in a way that breaks file permissions in a way that may not be immediately obvious (whether intentional or not).” The packages omitted by Michael were koan, cobbler, func and certmaster all of which could, if compromised, “[…] allow reprogramming of an entire datacenter in very easy steps.”

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00382.html

[2] http://fedoraproject.org/wiki/FWN/Issue148#The_Big_ACL_Opening

[3]
http://fedoraproject.org/wiki/FWN/Issue136#New_libraw1394_Rebuild_Exposes_Closed_ACLs

[4] After a flamewar (see FWN#148 “PackageGurus, SpecMentats or
UeberPackagers?”) the group name for packagers with access to any
package in CVS is provenpackager:
https://fedorahosted.org/packagedb/browser/fedora-packagedb-stable/ChangeLog#L45

Toshio Kuratomi shared[5] Michael’s concerns but pointed out that it
would be possible to introduce compromised code into his packages’
dependencies: “I’d like to mention, though, that func depends on the
following packages with open acls: pyOpenSSL, python, python-simplejson So in terms of protecting against $EVIL, restricting provenpackager isn’t very effective.”

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00384.html

Daniel Berrange thought[6] it would be more effective to have more
co-maintainers: “The ideal should be for every package in the distro to
have at least 1 extra comaintainer, or preferrably 3 or 4. People with a
little domain knowledge for the package who can handle both the
low-hanging fruit the main maintainer misses, with less risk of making
mistakes due to lack of package specific knowledge.” Toshio countered[7]
with a detailed reply which investigated the problems of
non-responsiveness and trust which would be encountered by such a
change. Michael Schwendt added[8] his experiences of the practical
problems involving non-responsive maintainers and the difficulty of
informing people without overloading them.

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00387.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00392.html

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00405.html

Jesse Keating returned[9] to the main topic and remarked that he agreed
with Michael DeHaan’s logic with regard to these specific packages but
that membership of “provenpackagers” was now obtainable by requesting
membership via the account system and approval of said request by a
provenpackager. The requirement to have at least five packages was
merely for initial seeding.

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00385.html

Tim Lauridsen wondered[10] when co-maintainers would be enabled to
submit updates to packages through bodhi and subsequent discussion with
Michael Schwendt suggested that it should be possible. Kevin Kofler had
similar concerns and Michael shared[11] the last public information on
the topic which was that anyone with commit access to the devel branch
can submit updates.

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00407.html

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00411.html

=== Who Moved My Bug ? ===

Debarshi Ray’s question sounded[1] alluringly like a parody of a
self-help book but expressed genuine concern over why the status of bugs
assigned to him were being changed. Till Maas reassured[2] Debarshi that
the status ASSIGNED means “that the bug has been triaged, i.e. it is
assigned to the rigth component and all necessary information is
provided. A member of the Fedora Triage Team probably did the changes to
your bugs [,]” he included a useful link[3] to the BugZappers wikipage.
Bryn Reeves explained[4] how to see every change made to a bug. John
Poelstra also suggested[5] using the “history” link and explained that
the use of the “FutureFeature” keyword was to insure that bugs would
continue to be given the version “rawhide” even after the GA release of
Fedora 10.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00273.html

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00274.html

[3] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00279.html

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00290.html

It appeared[6] that this was a different process to that used to handle
package review submissions and this had difference had caused some
confusion. Confusion also reigned[7] about when this use of the ASSIGNED
keyword had become standard and Dominik Mierzejewski argued[8] that it
had not been approved by FESCo, but Brian Pepple posted the FESCo logs
and Jesse Keating suggested[9] following the discussions on
@fedora-devel. Dominik declined to rely on following such a high-volume
list and Steve Grubb agreed[10].

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00325.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00285.html

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00285.html

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00310.html

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00420.html

Kevin Kofler added[11] some useful information for those working in
teams: “[…] when you’re actively working on fixing something (so you
don’t duplicate work in the team), you can use the ON_DEV status for
that purpose.”

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00283.html

=== HOWTO: Get an SELinux Policy Change ===

Jerry James requested[1] information on how to get the correct security
context in place for the GCL binaries which he was packaging. He needed
to know both whether it was acceptable to use a chcon -t java_exec_t
within the Makefile and how to have this reflected explicitly in Fedora
policy.

[1]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00259.html

Hans de Goede suggested[2] filing a bug against selinux-policy as Dan
Walsh was “[…] usually very fast and correct in fixing issues like
this one.” Dan posted that Jerry could get the final destination of the
file with a chcon `matchpathcon -n /usr/bin/gcl` LOCALPATH/gcl.

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00261.html

Jochen Schmitt suggested[3] that Jerry create a SELinux module to fix
the issue and then actually did it himself and shared[4] it with the
list, which impressed Jerry.

[3]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00289.html

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00294.html

The problem evolved[5] to be a little deeper than modifying the Makefile
as Jerry explained[6]: “I need a non-default security context for
binaries that are both built and executed in the %build script, when the
policy module has not yet been installed. It appears to me that there
are only two ways to accomplish this: keep abusing java_exec_t like I
have been, or get a GCL policy incorporated into selinux-policy* prior
to building GCL. Am I wrong?” After Paul Howarth pointed out that
selinux-policy needed to provide a context type for /usr/bin/gcl Dan
modified[7] his previous matchpathcon suggestion and advised that this
would be provided in selinux-policy-3.5.13-19.fc10.

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00307.html

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00350.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00367.html

=== Comps Czar Appointed to Encourage Modifications ===

An important decision made[1] by FESCo in its 2008-10-29 deliberations
was to try and encourage further modification of comps.xml[2] by
defining some clearer procedures. These included the appointment of Bill
Nottingham as a “Grand Arbitrator of Comps” to decide which packages
should be included in comps. The main concern expressed during the
deliberation was that packagers tended not to modify comps and that
awareness of its purpose had not been clearly communicated. It was hoped
that extending the wiki page[3] and making one person formally
responsible would help. Currently there are filters in place and only
those with uberpackager status can commit changes. Jesse Keating (f13)
wanted to “[…] rather correct bad behavior than prevent good behavior
[.]”

[1] http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.html

[2] Comps is an XML file which is used by anaconda (the installer) to
present groups of available packages for selection by the administrator
during the installation of a new operating system. See:
https://fedoraproject.org/wiki/PackageMaintainers/CompsXml

[3] https://fedoraproject.org/wiki/PackageMaintainers/CompsXml

One worry was to ensure that not everything is added to comps as this
would produce an unreadable, large list. This latter problem was
foregrounded when Christopher Stone advocated[4] that “[a]ll packages
should go in comps. I don’t know why notting is against this?!!? Why
should my php-pear-* packages be excluded from comps for example? Just
because some newb might not want to install them does not mean a php web
developer would not use comps to install them.” Matt Miller explained[5]
that the current scheme was inflexible: “If comps ends up with a
thousand programs under Games and Entertainment, another thousand under
Graphical Internet, etc., it’s even more useless than having nothing in
comps at all. What would be the point? On the other hand, having a
thousand small comps groups is also no good.”

[4]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00098.html

[5]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00120.html

Seth Vidal and Toshio Kuratomi seemed[6] interested in the idea of
allowing Flickr-like tagging of package as a replacement for the problem
of assigning them to groups. Denis Leroy also suggested[7] such a
system: “Comps evolved over time into something that doesn’t make a
whole bunch of sense to me. Is the main use of comps still for
installation groups within yum and anaconda ? A lot of packages are not
installation “targets” but simply libraries that should only be
installed by being pulled in from dependency resolution. Now if we’re
trying to “categorize” all packages nonetheless, it’d be better to have
a tagbased system from packagedb, where packages can be “tagged”
a-la-gmail, and also belong into multiple tag groups as some things
really belong into multiple categories…”

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00134.html

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00107.html

Nicolas Mailhot listed[8][9] the advantages of the current format of
comps as: human-editable, version-controllable, diff-able, grep-able,
platform-agnostic and scalable. Toshio leaned[10] towards having tag
information stored in packagedb which could generate static “[…]
separate files for the installer and general use (so that the installer
isn’t sprinkled with thousands of libraries but one could still use yum
to search for “all packages that have a ‘python’ ‘library’ to do
‘ssl’”).”

[8]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00108.html

[9]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00158.html

[10]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00122.html

In another post Nicolas raised[11] another series of pertinent questions
which included thinking about other repositories and alternate views of
any data which might shoehorned into a particular model. Bill Nottingham
wondered[12] where Nicolas was going with all this and re-capped the
current purpose of comps as both an input to a graphical package
selector and an input to tree composition tools. The discussion with
Bill revealed that Nicolas advocated[13] “[…] just add everything in
comps and run basic scripts that check every package we ship appears
there (say in a dev-null group for libs or such stuff). You can easily
cull the dev-null group at comps.xml.in -> comps.xml stage if needed” in
order to ease the QA burden.

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00125.html

[12]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00165.html

[13]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00226.html

Jeremy Katz wondered[14] who was the audience and task for Seth Vidal’s
“tree hierarchy plus tags” interface and distinguished between users
looking for an application and administrators installing a system. Seth
suggested[15] that using kickstart to install a minimal base and then
the desired packages was the appropriate solution for the latter
problem. He later explained[16] that having a tag-based presentation of
the packages online would make it easier to determine which packages
were available. Les Mikesell wished to reproduce specific machine
configurations easily which led[17] Seth to suggest using
yum-groups-manager to create a comps.xml file and then createrepo -g
that_comps.xml somedir which produces “[…] a repository that ONLY has
comps.xml in it that is then instantly usable by any site which can get
to the baseurl where it lives.”

[14]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00147.html

[15]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00148.html

[16]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00150.html

[17]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00152.html

=== LiveConnect Feature Approved for Fedora 10 ===

FESCo’s 2008-10-29 discussions[1] contained a decision to include the
LiveConnect[2] feature in Fedora 10. LiveConnect is a way for web
browsers to allow JavaScript and Java classes to call each other’s
methods. The project to develop a completely FLOSS implementation was
initiated[3] by Tom Fitzsimmons and brought to completion by Deepak
Bhole. Tom’s work[4] on a rewrite of gcjwebplugin as an XPCOM plugin has
been named IcedTeaPlugin and is the default in IcedTea6.

[1] http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.html

[2] http://fedoraproject.org/wiki/Features/Liveconnect

[3]
http://people.redhat.com/fitzsim/fosdem-2008/fosdem-2008-liveconnect.pdf

[4] http://fitzsim.org/blog/?p=23

The practical implications for end users are that many popular
sites[5][6] are now usable without the problems associated with the
installation of Sun Microsystems’ non-FLOSS Java plugin.

[5] http://www.jigzone.com/

[6] http://games.yahoo.com/

There was[7] some agonizing over the problem that LiveConnect was being
approved as a Feature post freeze date while other exciting projects had
been dropped because they were not complete at that time. Brian Pepple
worried: “Those folks we booted since they weren’t complete would be
justified in being pissed about us.” Although this seemed to be a
non-controversial opinion Deepak’s work was also felt to be very
important and fully tested. In addition Deepak submitted that “[…] no
new packages introduced for this feature. Just an update to an existing
package, that now installs a different Java plugin.”

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00097.html