|
|
| (134 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| {{Anchor|Developments}} | | {{Anchor|Developments}} |
| == Planet Fedora == | | == Developments == |
|
| |
|
| In this section the people, personalities and debates on the @fedora-devel mailing list are summarized. | | In this section the people, personalities and debates on the @fedora-devel |
| | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[:User:OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === New libraw1394 Rebuild Exposes Closed ACLs === | | === Would You Like to Write This Beat ? === |
|
| |
|
| A simple warning made[1] by [[JarodWilson]] of a soname bump of ''libraw1394'' (which among other things allows easy switching between juju and the older drivers) revealed that Fedora's KDE maintainers are not using open ACLs for their packages.
| | 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-July/msg01159.html
| | <references/> |
|
| |
|
| Jarod provided a short list of affected packages including ''kdebase'' and ''kdebase3'' and wondered whether he should "do a fancy chainbuild[2], or just let rawhide be busted for a day?" Following advice received[3] offlist he decided that the procedure would be to first bump and tag each of the packages, and then from within the devel-branch of a dependent package issue a: <pre>[jwilson foo fedora-cvs/pkg11/devel]$ make chain-build CHAIN="libraw1394 pkg1 ... pkg10"</pre>
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [2] http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Chained.builds | | [[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-July/msg01161.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?" |
|
| |
|
| This eventually worked[4], but first Jarod had to contact maintainers that disallowed commit access using open ACLs and get them to do the bump and tag in order to use the above method.
| | 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. |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01316.html
| | <references/> |
|
| |
|
| Early on in the chain of events [[KevinKoffler]] noted[5] the necessity to do this for the KDE packages. "Drago01" wondered why there were closed ACLs to which [[RexDieter]] replied[6] that it was not necessary for non-core development platform bits and he would try to change the ACLs for them. [[KonradMeyer]] defended[7] the choice on the basis that "KDE is a major system component and the KDE team (which is something like 6-8 people) does a very good job of fixing things as soon as they need fixing." Further probing for an actual reason by [[RahulSundaram]] resulted in Konrad stating[8] that it was necessary to prevent people from making mistakes and that the <code>kernel</code> package was handled similarly. Rahul was unconvinced by this and [[JonStanley]] agreed[9] it should be possible, as with GNOME, to use open ACLs to allow anyone to help.
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01164.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?" |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01192.html | | [[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. |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01181.html
| | <references/> |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01223.html
| | === Who Wants a Pony? === |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01225.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. |
|
| |
|
| === XULRunner Security Update Breakage Stimulates Bodhi Discussion ===
| | <references/> |
|
| |
|
| After [[MichaelSchwendt]] published[1] a summary of broken dependencies for Fedora 9 it was noticed[2] by [[MartinSourada]] that most of the problems were due to a recent update of ''xulrunner'' which now provides ''gecko-libs'' (see FWN#110[3].) Martin discovered that ''gxine'', which was his particular responsibility, did not depend on a specific version of ''gecko-libs'' and thus removed the versioned dependencies. He suggested that a review by carried out of the other affected packages to determine whether this was also the case for them.
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01175.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>. |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01177.html | | 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." |
| | |
| [3] http://fedoraproject.org/wiki/FWN/Issue110#Gecko-libs.Now.Provided.By.Xulrunnerdevel
| |
| | |
| Martin was further concerned that the policies for pushing security updates for a stable release be examined in the light of this particular case because it would fail to install due to all the broken dependencies. He suggested that it ought to be possible to use chain builds (the Koji buildsystem allows packages to be grouped into sets during the build process and to only report success if all the packages complete perfectly) to ensure that such breakage does not occur. He also wondered why the security update was not mentioned on the "-devel(-announce) list?"
| |
| | |
| [[NicolasMailhot]] agreed[4] strongly wondering: "why the hell is this stuff not tested in -devel first? [...] When the update process is not streamlined in -devel, it's no surprise it bombs in -stable when security updates are due." The answers to these questions came from [[AdelGadllah]] (drago01) who replied[5] that as it was a security fix it had to go to updates-stable immediately instead of following the normal procedure[6]. [[DavidNielsen]] interjected[7] that this method did not deliver a quick security fix because those using, for example, ''epiphany'' failed to get the update because the dependencies had not been properly handled. [[MichaelSchwendt]] also made[8] the same point: "Doesn't matter. It doesn't install at all if it breaks dependencies of *installed* packages. Not even *skip-broken helps in that case." Adel clarified[9] that he was explaining "why it was done, not that it was the right thing to do. As I already said, bodhi should block updates that break deps." | |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01182.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01183.html
| |
| | |
| [6] Generally bleeding-edge changes for the next version of Fedora are published in the "fedora-rawhide" repository, which is derived from a CVS branch named "-devel". The "fedora-updatestesting" repository contains bleeding edge changes for the current maintained release, the idea being that volunteers will test them and provide feedback before they are pushed to the "fedora-updates" repository for general consumption.
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01184.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01185.html
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01188.html
| |
| | |
| === Broken Upgrade Paths Due to NEVR ===
| |
| | |
| A report listing packages which failed to upgrade smoothly was emailed[1] to the list on Mon 21st. This would appear[2] to be the output of [[JesseKeating]]'s revamped version of the old Extras script ''upgradecheck'' script (previously discussed in FWN#108 "Package EVR Problems"[3]) which examines Koji tags[4] to determine whether upgrades from one package version to another will work.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01253.html
| |
| | |
| [2] http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgradepaths.py;hb=HEAD
| |
| | |
| [3] http://fedoraproject.org/wiki/FWN/Issue108#Package.EVR.Problems
| |
| | |
| [4] http://fedoraproject.org/wiki/Koji
| |
| | |
| [[MichaelSchwendt]] noticed[5] that at least one reported failure, of ''audacity'' to upgrade from "dist-f8-updates-testing" to "dist-f9-updates" was a false positive because it omitted to take the possible intermediate tag "dist-f9-updates-testing" into account. [[JesseKeating]] pondered[6] the idea and while admitting the possibility that someone might "at one time [have] installed F8 testing updates, and then upgraded to F9 + updates, but without F9 updates-testing. However, it's more plausible that if they were using updates-testing on F8 that they would upgrade to F9 + updates + updates-testing." He suggested that he would break the testing down into two separate paths: "F8, F8-updates, f9-updates" and "F8-updates-testing, F9-updates-testing" and also list the person that built the broken instance instead of listing the owners of the broken packages.
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01296.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01317.html
| |
| | |
| As the owner can change per branch [[MichaelSchwendt]] suggested that the ''pkgdb'' could be queried for branch-specific ownership data, but Jesse thought that it was more interesting to know who built the package rather than who owned it. He hoped that "the <pkg>-contact fedoraproject org or some such gets created soon so that the script can just email that + the person whom built the problematic package" and [[SethVidal]] quickly implemented[7] this after [[ToshioKuratomi]] made some changes to ''pkgdb''.
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01489.html
| |
| | |
| === Application Installer "Amber" ===
| |
| | |
| A description was posted[1] by [[OwenTaylor]] of a visual means to rate, browse and install packaged applications in a repository. The discussion around this revealed some differences over the advisability of providing separate ways for ordinary end-users on the one hand and package maintainers on the other to discover and discuss the software available from the FedoraProject. Owen's post was to announce that he had hacked up a web-browser plugin (a detailed README is available[2] which includes discussion of security and cross-browser support) which used PackageKit to allow the installation of packages selected from this website. He had hopes that this would be "robust against inter-distro differences in package names" and wondered "[w]hat do people think... does this make sense as part of the PackageKit project?"
| |
| | | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01433.html
| | 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/> |
| [2] http://git.o/shsoup.net/cgit/packagekit-plugin/tree/README
| |
| | |
| Following a suggestion from [[TomCallaway]] that it be integrated with PackageDB (this is the central repository of meta-information on packages and is currently targeted to the needs of package maintainers and release-engineering[3] to track ownership and ACLs[4]) there were questions from JeffSpaleta about what that meant. Owen replied[5] with more detail, and explained that the web application would take information from PackageDB but that the plugin would use PackageKit (and YUM and hence ''comps.xml'') to display actual installable packages. He listed other possible operations beyond simple installation of packages. It would be possible to offer installation to any anonymous user, but after authentication rating and commenting on packages could be authorized for users in the FAS[6] class. Similarly, the ability to edit package information could be authorized for package owners.
| |
| | |
| [3] https://admin.fedoraproject.org/pkgdb
| |
| | |
| [4] https://fedorahosted.org/packagedb/
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01440.html
| |
| | |
| [6] https://admin.fedoraproject.org/accounts/
| |
| | |
| Jeff emphasized[7] that he would prefer to see Owen's interface replace, or augment, the existing PackageDB one[8] in order to increase user-maintainer communication by simplifying and reducing the number of interfaces. [[BillNottingham]] wondered[9] "Does anyone actually use packagedb to browse for available software?" and although there were a couple of affirmative replies there was no aggregate data presented to answer this question. [[NicolasMailhot]] replied[10] with some possible uses for expanded meta-information based upon the experience of the Fonts SIG.
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01442.html
| |
| | |
| [8] https://admin.fedoraproject.org/pkgdb
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01445.html
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01474.html
| |
| | |
| [[RobinNorwood]] explained[11] to Jeff that the PackageDB was for one audience "(mostly) targeted at people interested in the plumbing of Fedora" while the new interface was "targeted at people who are looking for applications to install and 'do stuff' with." He posted[12] a link to the Feature page for this ApplicationInstaller. Work seems to have progressed quite far with both the web-application side, which is tentatively named "Amber" and is available for proof-of-concept testing[13] and also with Owen's plugin.
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01460.html
| |
| | |
| [12] http://fedoraproject.org/wiki/Features/ApplicationInstaller
| |
| | |
| [13] http://publictest10.fedoraproject.org/amber
| |
| | |
| Jeff re-iterated[14] his point that "driving users to a different site than the package maintainers... and allowing them to comment [is] going to cause a communication gap" and characterized this as "driveby commenting and rating." [MatthiasClasen] did not accept that the use cases and requirements were the same as those for PackageDB and argued that "[t]his is not an effort to improve package quality or gain new contributors. This is an effort to make life of users better. It is not about packages, but about applications." Robin was[15] against Jeff's idea of a "monolithic app" and emphasized that he was using existing infrastructure to provide a new interface and also planning easy export of the data. He envisioned this data as providing, for example, a feed of comments about each package to PackageDB: "More of a semantic web type idea than an isolated database or a 'one-stop shop'."
| |
| | |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01472.html
| |
| | |
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01481.html
| |
| | |
| === RPM Inspires Intel Moblin2 Shift From Ubuntu ===
| |
| | |
| An excited [[PeterRobinson]] copied[1] a link to "The Register" to the list. The article claimed that Intel's next version of "Moblin"[2] (cunningly codenamed Moblin2) would be replacing the "Ubuntu-based kernel" with the Fedora kernel and cited Dirk Hohndel. Specifically it attributed a desire to "move to Fedora [as] a technical decision based on the desire to adopt RPM for package management [and also that] having a vibrant community push is the winning factor." The article has since been rebuffed[3] by Hohndel in a comment on one of his blogs as "not only low on detail, it's also high in content that's made up or blown out of proportion" but he does confirm that "we decided to move to an rpm based distribution as that gave us better build tools and most importantly a better way to manage the licenses under which the individual packages are released."
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01381.html
| |
| | |
| [2] Moblin is a GNU/Linux-based software stack for Mobile Internet Devices which includes Xorg,GStreamer,ALSA,the MatchboxWM, GTK, Cairo, Pango, D-Bus, Avahi, Evolution Data Server and more. In order to make life easy for developers a Moblin Image Creator makes it easy to create a small 350-600MB binary image for a particular architecture. Moblin explicitly aims to provide an alternative to GNOME and KDE. http://www.moblin.org/resource.center.php
| |
| | |
| [3] http://www.hohndel.org/communitymatters/moblin/moblin-at-oscon/
| |
| | |
| Commentary on @fedora-devel tended to cautious optimism mixed with a desire for a lot more information. [[JeffSpaleta]] asked[4] whether the idea was to have Moblin2 be a "part of the larger Fedora project or is it going to be a downstream derived distribution that will include components such that it can not carry the Fedora name?" and broached the idea that Moblin2 might be a candidate for a Secondary Architecture (see FWN#90[5] and FWN#92[6].) [[DavidWoodhouse]] (posting with an Intel.com sig) also liked[7] the idea of a Moblin2 SIG producing a Fedora spin for MIDs (Mobile Internet Devices.)
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01386.html
| |
| | |
| [5] http://fedoraproject.org/wiki/FWN/Issue90#Fedora.Secondary.Architectures.Proposal
| |
| | |
| [6] http://fedoraproject.org/wiki/FWN/Issue92#Secondary.Arch.Proposal.Cont
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01417.html
| |
|
| |
|
| While "yersinia" thought that the emphasis on RPM was interesting [[HansdeGoede]] was intrigued[8] by the emphasis on community activity. Hans suggested that [[JeffSpaleta]] contact DirkHohndel to emphasize the dynamic nature of the FOSS community behind Fedora. Jeff suggested that [[KarstenWade]] could meet with Dirk at this week's OSCON[9]. Ex-Red Hat star employee ArjanvandeVen volunteered[10] to do what he could to help make contact with Dirk, describing himself as "on the other side of a cube wall" from him. In response to [[RahulSundaram]]'s request for concrete information from Intel Arjan responded[11] that he would do his best to get the right people to make contact, but that much of the speculation on @fedora-devel concerned topics which have an "eh we don't know yet" answer. He also repeated cautions against believing anything which journalists write.
| | === Russian Fedora ? === |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01397.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. |
|
| |
|
| [9] http://en.oreilly.com/oscon2008/public/content/home | | 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]]. |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01447.html
| | <references/> |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01523.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [[PaulFrields]] followed up[12] with details of a meeting at OSCON with senior Fedora hackers. It seemed that the ability to use OpenSuSE's Open Build System (which is based on RPM) was one of the main motivations behind Intel's move. Apparently ''Koji'' (the Fedora Project's buildsystem) lacks some specific functionality. Discussion between [[PaulFrields]] and [JeffSpaleta] centered[13] around whether the apparent Moblin2 plan of acting as a downstream derivative of the Fedora kernel would allow them to garner community contributions and whether this mattered anyway given Intel's vast resources. | | 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]]. |
|
| |
|
| [12] http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00198.html | | [[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>. |
|
| |
|
| [13] http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00214.html
| | <references/> |
|
| |
|
| [[ArthurPemberton]] thought that this was a good opportunity to take on some of the anti-RPM and anti-YUM misinformation which had been spread about. [[DavidNielsen]] thought it was best to merely demand proof from those spreading FUD. [[SethVidal]] conceded[14] that perhaps not enough had been done to publicize the improvements in YUM and RPM over the last few years and cited[15] a particular case-study of a ''smartpm'' user comparing it with ''YUM'' to the advantage of the latter.
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01503.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." |
|
| |
|
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01507.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."
