LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsFedora 19 and Apple hardwareThe Fedora 19 release brings a lot of goodies for Fedora users, but there is one class of users that may be a bit less happy: those who want to run Fedora on an Apple Mac system in a dual-boot configuration with OS X. A late bug in the Anaconda installer makes the creation of such systems nearly impossible. One might wonder why Fedora 19 shipped with this kind of problem; a look at the reasons gives a few insights into how the Fedora release process works.The decision to proceed with the Fedora 19 release was announced on June 27. Unfortunately, bug #979205 had been filed shortly before. The installer fails to create the needed partitions for a dual-boot system on an OS X machine, causing the installation to fail. As Matthew Garrett put it when calling attention to the problem: "This is rather frustrating, since Fedora's the only distribution with any significant support for running on Apple hardware." A glance at any Linux-related conference will show that Apple systems are popular among developers; it seems a bit strange that a distribution that has put significant effort into working on that hardware would ship with a known problem of this nature. The explanation for what happened involves a number of separate issues. The first is that the bug was introduced very late in the development cycle; according to Adam Williamson, it went into Anaconda 19.30.10, which first saw wide testing in the RC1 release on June 25. Naturally, the patch that caused the problem was a response to another bug; even so, the patch was the subject of some discussion before being merged into the otherwise-frozen Anaconda source. In the end, the patch was deemed to be sufficiently low-risk to be accepted — a judgment which, like many, is easy to criticize after the fact. At the time, though, it looked like a way to fix a known problem in the release. The new code took several days to find its way into a build that would see wider testing; it was committed on a Thursday, and the build did not happen until after the following weekend. That left a period of about two days between the bug's general availability and the Fedora 19 go/no-go decision — not very long for an installation-time issue to surface. Some participants have suggested that, in the future, the time between an RC release and the go/no-go decision should be lengthened to increase the chances of catching a last-minute problem. But that probably would not have helped in this case. The fact that the Fedora quality-assurance team only appears to have a single Mac system, and that they don't test it for dual-boot installations, also did not help. There was a clear hole in the QA net that this problem slipped through. One might argue that this does not necessarily indicate a problem: as Chris Murphy pointed out, Macs are not officially supported by the distribution. So it is not surprising that the testing resources available are unable to catch every problem. It also means that, even if the problem had been found before the go/no-go decision, it would not have been entitled to "blocker" status and, thus, might not have affected that decision. While not saying that the release should have been delayed to fix this problem, Matthew did question one interesting bit of Fedora policy: once the go/no-go decision has been made in the "go" direction, the process becomes unstoppable. That means that, even if this bug were deemed to have a "blocker" level of severity, it still would not have blocked the release. Kevin Fenzi defended this policy, describing the long series of events that starts to unfold once the decision to make the release has been made. The explanation was not satisfying to everybody, but the policy exists and doesn't appear to be subject to change. So Fedora 19 simply will not install properly in a dual-boot OS X configuration without a lot of extra work. And things are likely to stay that way; an installer problem cannot be fixed through the normal Fedora update process. There was some talk of a 19.1 release, but, as Kevin put it, "We are currently pretty unsetup for any kind of point releases." So this problem is likely to remain in the official Fedora distribution until Fedora 20. Not an ideal outcome by any means, but one that may have been hard to avoid.
Brief items Distribution quote of the week
Maintainers shouldn't have to do the work to support any configuration
they're not comfortable testing/etc, but if somebody else comes along
to do it for them, the solution is cooperation, not revert wars.
-- Rich Freeman
DoudouLinux 2.0 "Hyperborea" releasedVersion 2.0 of the DoudouLinux educational distribution is out. "But DoudouLinux is not just a CD/DVD of educative stuffs for children. DoudouLinux is now a vast project on its own. We have published with version 2.0 a manifesto that defines the philosophy and the ethics of our project: we want our children be able to fully master the digital world they are going to live in, instead of undergoing it. As a result we now feel very concerned about user privacy, especially when it comes to children." LWN looked at DoudouLinux in 2011.
Fedora 19 releasedThe Fedora 19 release is now available. As usual, this release offers a lot of new features; see the announcement or the release notes for details.Update: the Fedora 19 for ARM release is also available. The Fedora ARM team is clearly getting up to speed and is now able to offer releases on the same day as the primary architectures.
Announcing the release of Fedora 19 for PowerThe Fedora Secondary Arch Team for Power has announced the release of Fedora 19 for Power architecture.
GNU Linux-libre 3.10-gnuGNU Linux-libre 3.10-gnu is out. "No big deblobbing news for this one: a handful of new drivers that requested blobs had to be deblobbed, a few others had to be updated because of new blob requests."
13.10 (Saucy Salamander) Alpha 1 available for some flavorsKubuntu, Lubuntu, Ubuntu GNOME, and UbuntuKylin have released a first alpha version of 13.10 "Saucy Salamander".
Distribution News Fedora Cooperative Bug Isolation for Fedora 19 x86_64 and i386The Cooperative Bug Isolation Project (CBI) is now available for Fedora 19. CBI is a research effort designed to find out what went wrong when software crashes. Download CBI packages and help squash bugs.
Reminder: Fedora 17 end of lifeFedora 17 will reach its end-of-life on July 30, 2013. No further updates will be available after that time.
Newsletters and articles of interest Distribution newsletters
Kuhn: Berkeley DB 6.0 license change and DebianOracle recently changed the Berkeley DB license to AGPLv3 prompting a discussion on the Debian lists about possible conflicts between GPLv2 licensed software in Debian and the new AGPLv3 BDB. Bradley Kuhn sent an email to the Debian-legal mailing list with his point of view. "I know that some have complained that compliance with AGPLv3 may require more work by Debian redistributors. That is a reasonable concern, but I think the issue can be mitigated. The argument is roughly analogous to this one: complying with GPLv2 is more difficult than complying with the Apache license. But, unless Debian wants to take a wholesale position opposed to copyleft, I don't think this issue is or should be considered insurmountable."
Riddell: Kubuntu Won't be Switching to Mir or XMirJonathan Riddell has announced that the Kubuntu distribution will not be following Ubuntu in its switch to the Mir display server. "Here at Kubuntu we still want to work as part of the community development, taking the fine software from KDE and other upstreams and putting it on computers worldwide. So when Ubuntu Desktop gets switched to Mir we won't be following. We'll be staying with X on the images for our 13.10 release now in development and the 14.04LTS release next year. After that we hope to switch to Wayland which is what KDE and every other Linux distro hopes to do."
Zacchiroli: all Debian source are belong to usStefano Zacchiroli has announced the sources.debian.net (sources.d.n) web site, which hosts the source code for Debian packages. "Via sources.d.n you can therefore browse the content of Debian source packages with usual code viewing features like syntax highlighting. More interestingly, you can search through the source code (of unstable only, though) via integration with http://codesearch.debian.net. You can also use sources.d.n programmatically to query available versions or link to specific lines, with the possibility of adding contextual pop-up messages (example)."
Page editor: Rebecca Sobol |
|||||||||||||