Wittering2.0

Fedora Weekly News #166

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.

2 years ago

There is no FWN#165

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

2 years ago

Fedora Weekly News #164

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.”

2 years ago

FedoraWeeklyNews#163

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.

2 years ago

FedoraWeeklyNews#162

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.

2 years ago

FedoraWeeklyNews#161

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.

2 years ago

FedoraWeeklyNews#160

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

2 years ago

Fedora Weekly News #159

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

2 years ago

Fedora Weekly News #158

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

2 years ago

Fedora Weekly News #157

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

2 years ago