|
|
| (98 intermediate revisions by 2 users not shown) |
| Line 5: |
Line 5: |
| mailing list are summarized. | | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === Approaches to a Minimal Fedora === | | === Would You Like to Write This Beat ? === |
|
| |
|
| [[LuyaTshimbalanga|Luya Tshimbalanga]] alerted[1] the list to a post on FedoraForum.org in which a user "stevea" had produced a 67MB "minimalFedora" system. [[JefSpaleta|Jeff Spaleta]] worried[2] that the bare-bones system was unable to receive updates and that this was something which "we as a project might not officially want to endorse." One way out of that suggested by Jef was that interested parties could produce a derived distribution which pushed out entire updated images. Recent changes in the trademark guidelines make such a move easier.
| | Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or [[User:Pcalarco|Pascal Calarco]]. A short overview of what you may need to do can be obtained by reading the workflow<ref>http://fedoraproject.org/wiki/FWN/WorkFlow</ref> section of the wiki. The @fedora-news list is also extremely open and helpful. Joining<ref>http://fedoraproject.org/wiki/FWN/NewsProject/Join</ref> the News Project is quite straightforward. |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01304.html
| | <references/> |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01305.html
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| A parallel to the minimal OS appliance image used in the ''oVirt'' project was discerned[3] by [[DanielBerrange|Daniel Berrange]]. Daniel reported their 'oVirt managed node' as being less than 64MB and built entirely from the Fedora 9 repositories. Later Daniel posted[4] that the similarities ended with the desire for a small image. The ''oVirt'' goal was to use only Fedora as upstream whereas stevea's approach had been to substitute ''coreutils'' with ''busybox''. Daniel acknowledged "[...] finding the bits which aren't needed is fun in itself & somewhat of a moving target. So wherever possible we've been filing BZ to get some RPMs split up into finer grained sub-RPMs" and included a link to his project's ''kickstart'' %post stanza. [[RichardJones|Richard Jones]] suggested[5] that KDE's ''filelight'' was useful for finding bloated files and [[VasileGaburici|Vasile Gaburici]] added[6] that there was a GNOME equivalent called ''baobab''. Vasile also included[7] a script which he uses to "keep track of bloatware".
| | [[User:Sundaram|Rahul Sundaram]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html</ref> the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using. |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01307.html
| | One interesting point is that CMUCL<ref>One of the Common Lisp implementations: http://www.cons.org/cmucl/</ref> was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html</ref> to be only available for 32-bit systems. However what got people really excited was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html</ref> Rahul's question about what to do concerning the <code>gNaughty</code> package. Its sole purpose seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html</ref> to be downloading pornography. Rahul referenced the <code>hot-babe</code> CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?" |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01319.html | | Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html</ref> by [[User:Alsadi|Muayyad AlSadi]] who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. [[User:Notting|Bill Nottingham]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html</ref> skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html</ref> the reaction typified by [[User:Skvidal|Seth Vidal]] which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. [[User:bochcecha|Mathieu Bridon]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html</ref> that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy. |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01373.html
| | <references/> |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01374.html
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01376.html | | [[KristapsViesalgs|Kristaps Viesalgs]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html</ref> for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?" |
|
| |
|
| A follow-up post from Daniel concluded[8] that the only bits of upstream Fedora actually used in stevea's approach were the kernel and ''busybox'' as even ''glibc'' and ''initscripts'' had been ditched. Daniel wondered "So not really much trace of Fedora left at all. Not sure why you'd go to the trouble of doing the initial anaconda install at that point - might as well just 'rpm *no-deps' install kernel + busybox RPMs into a chroot & add the custom init script."
| | [[User:Ajax|Adam Jackson]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html</ref> for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by [[User:Adamwill|Adam Williamson]] and [[User:|Xavier Bachelot]]. The latter asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html</ref> any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides. |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01320.html
| | <references/> |
|
| |
|
| Doubt on the advantages of stripping down Fedora to make it run on embedded targets was cast[9] by [[PatriceKadionik|Patrice Kadionik]] when he argued that using the Fedora kernel with all its patches and modules was too bloated. Instead he preferred to use the vanilla kernel with ''busybox'' with the result that "[...] you have a Linux kernel (about 1MB) with its root [filesystem] (about 1-2 MB) adapted completely to the target platform." [[AlanCox|Alan Cox]] replied[10] that the ability to receive updates and benefit from the maintained and tested code was desirable if there were enough extra space.
| | === Who Wants a Pony? === |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01353.html | | [[User:Kushal|Kushal Das]] promised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html</ref> a pony to anyone that would take the trouble to review<ref>http://bugzilla.redhat.com/show_bug.cgi?id=503021</ref> one of his packages. |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01357.html
| | <references/> |
|
| |
|
| [[MichaelPetullo|W. Michael Petullo]] added a link[11] to his "FedoraNano" project which has the goal of reducing redundancies, identifying probable cases for sub-packaging and documenting a method to install a small Fedora onto solid state drives.
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [11] http://www.flyn.org/fedoranano/fedoranano.html | | [[User:Maxamillion|Adam Miller]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html</ref> whether he should just retire the <code>Firestarter</code><ref>Firestarter is a firewall configuration GUI</ref> package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate <code>Firestarter</code> with <code>PolicyKit</code>. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok <code>PolicyKit</code>. |
|
| |
|
| | | Following confirmation from [[User:Sundaram|Rahul Sundaram]] and [[User:Skvidal|Seth Vidal]] a decision was made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html</ref> by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future." |
| === Using PackageKit Without NetworkManager-Controlled Interfaces ===
| |
| | |
| A question from [[MartinLanghoff|Martin Langhoff]] asked[1]: "[i]s there anything preventing PK from connecting to the network over non-[NetworkManager]-controlled network interfaces?" This question appeared to be predicated on the assumption that PackageKit had a dependency on NetworkManager.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01209.html
| |
| | |
| [[JeremyKatz|Jeremy Katz]] clarified[2] that PackageKit depended on NetworkManager-glib and not on NetworkManager. He added that this was because PackageKit attempted to determine the status of the network connection prior to checking for updates. [[DanWilliams|Dan Williams]] confirmed[3] that this was the case and expanded on the explanation: "If talking to NM fails, the app should either (a) assume a connection, or (b) could be more intelligent by asking SIOCGIFCONF/netlink for interfaces, and if at least one interface is IFF_UP | IFF_RUNNING and has an IP address, then try." Using NetworkManager in this way allows PackageKit to be restricted to sensible choices about the type of networks over which it is acceptable to receive updates.
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01210.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01213.html
| |
| | |
| A further point raised by Martin was that there were a surprising number of dependencies and Dan pointed[4] to bugzilla entry#351101[5] while noting that "[PackageKit] should only depend on NetworkManager-glib, which itself should not pull in NetworkManager in the future." That bug specifically affects multilib systems, that is x86-64 systems with i386 packages on them, and prevents the simple removal of the older version of NetworkManager-glib and replacement with a re-factored one. This will be fixed for Fedora 10 using the installer ''anaconda''.
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01214.html
| |
| | |
| [5] https://bugzilla.redhat.com/show.bug.cgi?id=351101
| |
| | |
| In a separate thread Martin asked[6] what debugging facilities were available for network scripts beyond using <code>bash -x</code>. He detailed his "hack du jour" by which <code>/etc/udev/rules.d/60-net.rules</code> invokes <code>net.hotplug.debugger</code> which in turn uses <code>bash -x net.hotplug</code> with STDIN and STDOUT redirected to a logfile. It appeared from the lack of further suggestions that this is a good strategy. He also provided[7] a note which explained that he was upgrading the "School Server" spin to Fedora 9 from Fedora 7.
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01263.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01207.html
| |
| | |
| === Git-1.6.0 Commands to be Moved Out of PATH ===
| |
| | |
| A response by [[ToddZullinger|Todd Zullinger]] to a "cvsextras" commit[1] of changes to ''git'' questioned[2] whether setting <code>gitexecdir=%{_bindir}</code> was a justified deviation from upstream intent. According to Todd "[..] we've effectively negated upstream's intent to present less binaries in the users path". Currently there are 137 git-commands in the <code>/usr/bin</code> directory. Todd suggested that it was better that individual users added the output of <code>$(git -exec-path)</code> to their <code>PATH</code> environment variable. As a precaution against breaking scripts upon update to ''git-1.6.0'' Todd suggested that this addition to PATH should be made by the package.
| |
| | |
| [1] http://www.redhat.com/archives/fedora-extras-commits/2008-August/msg05593.html
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01330.html
| |
| | |
| The package maintainer responsible for the change, [[JamesBowes|James Bowes]] replied[3] that he had recently attempted to do as Todd suggested and that had resulted in complaints. He was worried that although Todd's change made sense there had been no due diligence conducted to see what would break if the <code>git-*</code> commands were moved in such a way. [[JoshBoyer|Josh Boyer]] replied[4] that the original complaint had been about "yank[ing] out commands [...] from a stable release [Fedora 9]". [[ToddZullinger|Todd Zullinger]] discounted such complaints and dreamt[5] that "[...] a warning could be hand delivered by a beautiful naked person of whatever gender the user prefers and many would still scream when the change finally landed. :)" He suggested that in order to achieve predictability and consistency across distributions it was best to follow upstream and use the update to 1.6.0 as a flag day.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01361.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01363.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01389.html
| |
| | |
| In response to queries as to whether there was a need to update Fedora 9 also [[JoshBoyer|Josh Boyer]] replied[6] that a security bug was fixed by ''git-1.6.0'' but that he thought that this might have also been fixed by "a later release of 1.5.6.x."
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01390.html
| |
| | |
| === Resurrecting Multi-Key Signatures in RPM ===
| |
| | |
| Spurred on by the disquiet caused by the recent signing of Red Hat packages (but not as far as is known any Fedora packages)[1] it was suggested[2] by [[BojanSmojver|Bojan Smojver]] that multiple GPG signatures of RPM packages would be a good idea. Distributing the signing could include using alternate buildsystems "[...] with no public access [...] to verify package checks before signing[.]"
| |
|
| |
| [1] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01136.html
| |
| | |
| [[AndrewBartlett|Andrew Bartlett]] thought that the checksum part would be a problem because a build often includes hosts, build times and other specifics and [[ChrisAdams|Chris Adams]] added[3] that even individual files within a package had such information embedded. Bojan decided to find out how many packages were so constrained and [[SethVidal|Seth Vidal]] suggested[4] a useful ''rpm'' command <code>rpm -qp *dump pkg.rpm</code> to list all available information about each package.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01140.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01146.html
| |
|
| |
| Seth was dubious about the general idea and upon being pressed doubted the security gain and noted the cost incurred on users trying to verify that a package was signed correctly. Bojan expanded[5] upon the idea that for a "[...] multi-key, multi-build system, an attacker would need to get his hands on a lot of private key passwords, break multiple independent build systems [...] It is similar to what a reporter does to confirm a story. One source, not so reliable. Two sources, more reliable. Many sources, most likely reliable." [[StephenSmoogen|Stephen Smoogen]] described[6] this a logical fallacy and argued that due to the number of packages all signing would need to be automated and thus probably each of the multiple sources would "[...] get their information from the same top level source."
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01198.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01205.html
| |
| | | |
| A useful post by [[NilsPhilippsen|Nils Philippsen]] laid out[7] four practical objections. Prime among these was that there were additional pieces of data, besides those mentioned above, embedded in a specific build even though the source package may have the same tag. The possibility of making the build system vulnerable to a DoS attack was also mentioned. A sub-thread on German banking practices and the value of multiple credentials developed[8] as did one[9] on the problems of determinism in producing identical binaries. | | A further suggestion from "Cry" prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html</ref> Adam to start filing RFEs against <code>system-config-firewall</code> for any features present in <code>Firestarter</code> but missing in <code>system-config-firewall</code>. |
| | | <references/> |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01156.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01275.html
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01329.html
| |
| | |
| [[TomLane|Tom Lane]] was also among those that expressed[10] a general skepticism that the increased burden of such a scheme was realistic: "Most of us [packagers] are overworked already. We aren't going to jump through any hoops for third-party signatories." Bojan argued[11] that if the system were automated then it probably would be vulnerable but suggested that it would be better if a community effort to absorb the extra non-automatic work would be a solution in line with "open source" practices. Reluctantly he concluded "[n]ever mind, it was just an idea. Probably not even a good one. Back to the drawing board... ;-)"
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01141.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01215.html
| |
| | |
| === Intrusion Recovery Slow and Steady ===
| |
| | |
| A politely phrased request[1] was made on 25-08-2008 by [[MikeChambers|Mike Chambers]] for information about when normal service would resume in the Fedora Project after the disruptions[1a]. Enigmatically [[DominikMierzejewski|Dominik 'Rathann' Mierzejewski]] observed[2] that there had been "some speculation on fedora-advisory-board that might explain the information blackout, so please don't jump to conclusions until you really know what happened" This led [[ChrisAdams|Chris Adams]] to observe that the list archives appeared to be offline and to restate the request for information "[...] in the absence of information, rumors and speculation fill the gap (which is not good)."
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01102.html
| |
| | |
| [1a] https://fedoraproject.org/wiki/FWN/Issue140#Mysterious_Fedora_Compromise
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01122.html
| |
| | |
| Several days later (on 28-08-2008) a similar request was made[3] by [[AlanDunn|Alan Dunn]]. He wondered whether ''bodhi'' was pushing updates out again, and [[JoshBoyer|Josh Boyer]] responded[4] that planning and implementation of "how to revoke the current gpg key used to sign RPMs" were in progress. [[JesseKeating|Jesse Keating]] cautioned[5] that the migration to a new key would be slow "I'm currently re-signing all of the 8 and 9 content with these new keys so that we can make them available along with the new updates with the new key for these product lines. This is going to take some time due to the nature of how our signing works."
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01308.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01309.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01310.html
| |
|
| |
|
| A proposal mooted[6] on @rel-eng by [[WarrenTogami|Warren Togami]] and others provided some insight into at least the part of the plans that involve the problem of how to distribute a new package signing key.
| | === Russian Fedora ? === |
|
| |
|
| [6] http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html | | When [[User:Peter|Peter Lemenkov]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html</ref> about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. [[User:Kkofler|Kevin Kofler]] gave<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html</ref> an able summary why this would still present Red Hat with a problem. |
|
| |
|
| "nodata" asked[7] whether the new plans included a means to push out critical security updates even while there was a general outage. The thinking behind this seems to be that an attacker could decide to knock out Fedora infrastructure in order to gain some time to exploit a known vulnerability even if a simple fix existed. [[JesseKeating|Jesse Keating]] replied[8] confidently that in such a scenario the Fedora Project would do "whatever it takes [...] to get a critical update onto a public webserver should the need arise" and cautioned against wasting time trying to plan for every possible scenario. [[ToshioKuratomi|Toshio Kuratomi]] added[9] that although it might be possible to speed up recovery "[...] unfortunately if the infrastructure problem is bad enough, there's no way we can push package X out until the problem is at least partially resolved."
| | An assertion by [[User:|Alexey Torkhov]] that there existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html</ref> a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from [[User:Sundaram|Rahul Sundaram]]. |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01313.html
| | <references/> |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01314.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01316.html | | A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]]. |
|
| |
|
| On 27-08-2008 [[PaulJohnson|Paul Johnson]] noted that it was possible to "compose and build" and asked "when will updates via yum become available for rawhide?" [[JeremyKatz|Jeremy Katz]] responded[10] that "[a]t the moment, the compose is falling over for new reasons unrelated to the infrastructure changes. Hopefully we'll see a rawhide make its way out to the masses real soon now."
| | [[User:Adamwill|Adam Williamson]] and [[User:Mdomsch|Matt Domsch]] (Dell's DKMS mastermind) kicked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html</ref> some ideas back and forth over the advantages of <code>akmods</code> versus <code>kmods</code>. |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01249.html
| | <references/> |
|
| |
|
| Later [[MikeChambers|Mike Chambers]] and [[OlaThoresen|Ola Thoresen]] reported[11] that updating from Fedora 9 to Rawhide seemed to be working. Several Rawhide Reports also appeared[12].
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01350.html | | Following a report from [[UweKiewel|Uwe Kiewel]] that a <pre>yum upgrade</pre> had spewed all sorts of errors the supported methods for upgrades were re-stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html</ref> by [[User:Adamwill|Adam Williamson]]: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline." |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01339.html
| | <references/> |
Developments
In this section the people, personalities and debates on the @fedora-devel
mailing list are summarized.
Contributing Writer: Oisin Feeley
Would You Like to Write This Beat ?
Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or Pascal Calarco. A short overview of what you may need to do can be obtained by reading the workflow[1] section of the wiki. The @fedora-news list is also extremely open and helpful. Joining[2] the News Project is quite straightforward.
Is gNaughty a Hot Babe ?
Rahul Sundaram posted[1] the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.
One interesting point is that CMUCL[2] was revealed[3] to be only available for 32-bit systems. However what got people really excited was[4] Rahul's question about what to do concerning the gNaughty package. Its sole purpose seemed[5] to be downloading pornography. Rahul referenced the hot-babe CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?"
Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised[6] by Muayyad AlSadi who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. Bill Nottingham was[7] skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was[8] the reaction typified by Seth Vidal which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. Mathieu Bridon thought[9] that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy.
Chrome9 Vx800 Graphics Support on LiveUSB
Kristaps Viesalgs asked[1] for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"
Adam Jackson asked[2] for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by Adam Williamson and [[User:|Xavier Bachelot]]. The latter asked[3] any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.
Who Wants a Pony?
Kushal Das promised[1] a pony to anyone that would take the trouble to review[2] one of his packages.
Firestarter Retired as Unportable to PolicyKit
Adam Miller asked[1] whether he should just retire the Firestarter[2] package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate Firestarter with PolicyKit. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok PolicyKit.
Following confirmation from Rahul Sundaram and Seth Vidal a decision was made[3] by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."
A further suggestion from "Cry" prompted[4] Adam to start filing RFEs against system-config-firewall for any features present in Firestarter but missing in system-config-firewall.
Russian Fedora ?
When Peter Lemenkov asked[1] about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. Kevin Kofler gave[2] an able summary why this would still present Red Hat with a problem.
An assertion by [[User:|Alexey Torkhov]] that there existed[3] a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from Rahul Sundaram.
Will FESCo Revisit Kmods ?
A discussion of why VirtualBox will not be a feature due to its code not yet heading upstream and consequently remaining as kmods drew a statement of support from Kevin Kofler for reverting the current banning of kmods should he become a FESCo member. Upon request from Richard W.M. Jones for a dispassionate summary of the reasons to avoid kmods drew[1] a concise response from Seth Vidal.
Adam Williamson and Matt Domsch (Dell's DKMS mastermind) kicked[2] some ideas back and forth over the advantages of akmods versus kmods.
Upgrade from Fedora 10 to Rawhide (Fedora 11)
Following a report from Uwe Kiewel that a
yum upgrade
had spewed all sorts of errors the supported methods for upgrades were re-stated[1] by Adam Williamson: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."
