FWN/Beats/Developments

Developments

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

Contributing Writer: Oisin Feeley

Orphans Purged

It sounded 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.

A follow-up posted 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 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 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 by PeterÅstrand on @tigervnc-users provides some more details.

One specific outcome anticipated 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 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 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 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 by Tom Lane. Upon a challenge from Seth Vidal some problems with the process of upgrading rpm to handle stronger hashes were listed by Bill Nottingham. These included including "No solution for handling packages natively on F9" and Tom Lane expanded 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 following some thoughts from Adam Williamson.

RahulSundaram asked for more information on the use of LZMA compression as this is one of the new features of rpm-4.7. Panu replied 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 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 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 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 to an earlier thread on the latter question.

Anaconda Default of Separate / and /home Partitions

A long-standing bugzilla entry was referenced 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 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 to be surprisingly large due to multiple languages installed. Michel Salim and Callum Lerwick both brought up the necessity to have a large / partition in order to be able to run preupgrade.

Lex elaborated on possible space requirements for such a scheme.

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

Dennis Gilmore posted 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 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 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 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 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 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.