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 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.
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00093.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00103.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00474.html
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
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
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.
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00213.html
- ↑ http://fedoraproject.org/wiki/FWN/Issue119#Baracuda_To_Replace_VNC_.3F
- ↑ http://sourceforge.net/mailarchive/forum.php?thread_name=alpine.LFD.2.00.0902271116020.25749%40maggie.lkpg.cendio.se&forum_name=tigervnc-users
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00217.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00221.html
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
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
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
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
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02117.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02161.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02134.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02142.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02146.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02213.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02156.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02173.html
- ↑ http://bpepple.fedorapeople.org/fesco/FESCo-2009-03-06.html
Windows Cross-compiler Added to comps.xml
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
/ 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
/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
Lex elaborated on possible space requirements for such a scheme.
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00365.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00384.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00397.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01903.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01960.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01976.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02167.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02021.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg02356.html
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 [.]”
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00430.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00425.html
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
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
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.