|
|
| (96 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]] |
|
| |
|
| === Getting Back on our Feet === | | === Would You Like to Write This Beat ? === |
|
| |
|
| On 05-09-2008 [[JesseKeating|Jesse Keating]] posted[1] the good news that "[...] we have done a successful compose of all the existing[,] and as of yesterday[,] pending updates for Fedora 8 and Fedora 9, all signed with our new keys." He cautioned that the size of this backlog of updates meant that it would take some time to get them out to mirrors. The updates will be in new directory locations and there will be an "[...] updated fedora-release package in the old updates location that will get you the new keys and the new repo locations."
| | 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-September/msg00329.html
| | <references/> |
|
| |
|
| Jesse was keen to point out that there would be a FAQ to which we can all contribute and that its location will be announced shortly.
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [[SeanDarcy|Sean Darcy]], after thanking Jesse for all the work he had put in, asked[2] how he could get the new key for updates right now without having to wait for the fedora-release package to be placed in the old repository location. A variety of answers followed and the canonical one appeared[3] to be that given by [[ToddZullinger|Todd Zullinger]] in which he suggested obtaining ''fedora-release'' from CVS and then checking that the fingerprints matched those published[4] on the FedoraProject website. Some minor confusion followed[5] as the example presented on the web page uses the old key signed by "fedora@redhat.com" but the new key is signed by "fedora@fedoraproject.org". Similarly the use of "PUBKEY" as a placeholder variable on the web page caused some difficulties which Todd cleared[6] up again. | | [[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. |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00392.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?" |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00396.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. |
|
| |
|
| [4] https://fedoraproject.org/keys
| | <references/> |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00406.html
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00417.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?" |
|
| |
|
| [[JeffreyOllie|Jeffrey Ollie]] made[7] the good point that using a GPG WoT would make it easier for Fedorans to have confidence that they had obtained the correct key and hoped that those at the Brno FUDCon could "arrange an impromptu keysigning[.]" | | [[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-September/msg00411.html
| | <references/> |
|
| |
|
| Early in the week on 02-09-2008 [[StefanGrosse|Stefan Grosse]] asked[8] politely when the resigned Fedora 9 updates would be available. [[BrunoWolff|Bruno Wolff III]] suggested[9] "If you are worried about something in particular, you can look at bodhi to see pending updates and updates-testing and get rpms from koji if there is something you want right now." A brief discussion between [[TillMaas|Till Maas]], [[JesseKeating|Jesse Keating]] and [[BrunoWolff|Bruno Wolff]] explored whether it was possible to download from Koji using SSL if one did not have a FAS account. Bruno testified[10] "I needed certs (two from fedora and mine) to get the bodhi client to work. I used this to grab a list of stable updates last week [...] I didn't bother with ssl when grabbing them from koji." Till was[11] using ''wget'' to grab the packages from Koji and found it necessary to use certificates. Jesse showed[12] that it was possible to do a <code>koji download-build</code> to get packages anonymously.
| | === Who Wants a Pony? === |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00083.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. |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00086.html
| | <references/> |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00089.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00092.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>. |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00096.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." |
| | |
| | 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/> |
|
| |
|
| In a separate thread [[JesseKeating|Jesse Keating]] announced[13] that the revised Fedora 10 freeze date would be 09-09-2008 and as part of a friendly reminder that it was coming up quickly observed "I realize that rawhide has been less than great lately, and we're working quite hard to fix the issues. The installer images from the 30th may be of use in getting rawhide installed and then updating to what is in the public repos. See http://kojipkgs.fedoraproject.org/mash/rawhide20080830/development/ (please only grab the installer images from there, not the entire tree)." [[MattMiller|Matt Miller]] reported[14] a successful net install from the Fedora 10 alpha images using the rawhide repository.
| | === Russian Fedora ? === |
|
| |
|
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00091.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. |
|
| |
|
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00107.html | | 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]]. |
|
| |
|
| === Removing Packages with Long-standing FTBFS Failures ===
| | <references/> |
|
| |
|
| [[User:Mdomsch|Matt Domsch]] posted[1] a list of ninety packages which "Fail To Build From Source" (FTBFS)[2]. Matt noted that some of these packages have failed since 02-2008 and that "[...] packages with unresolved FTBFS bugs immediately following the Alpha release will be removed from the distribution" in line with a proposal passed by FESCo. He asked that concerned parties help to resolve the problems and noted that several of them had easy fixes.
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00319.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]]. |
|
| |
|
| [2] http://fedoraproject.org/wiki/FTBFS | | [[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>. |
|
| |
|
| Response was fairly quick and positive from both those listed as maintainers and concerned parties that needed the packages in Fedora 10.
| | <references/> |
|
| |
|
| One interesting ramification of the removal of such packages was mentioned[3] by [[DanielBerrange|Daniel Berrange]] who asserted "[t]his list is far from complete - if you want to remove these 90, the dependency chain ripple, will entail the removal of tonnes of other packages which depend on these." He asked Matt to generate a report which "[...] shows the ripple effect for each proposed package. If something is just a leaf-node, it isn't very important to worry about, but if something triggers removal of 50 dependant packages that's pretty damn important to fix. This info would be useful in prioritizing which builds need fixing most urgently." [[SethVidal]] modified[4] a script written by [[JamesAntill|James Antill]] so that it did exactly that and Matt posted[5] a link to the script and an example run. [[TillMaas|Till Maas]] suggested[6] that it would be useful make sure that a src.rpm responsible for several dependent packages is only counted once.
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00320.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." |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00363.html
| | <references/> |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00361.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00371.html
| |
| | |
| The practical consequence of neglecting such dependencies was highlighted[7] by [[MatthiasClasen|Matthias Clasen]] when he commented that "djvulibre-devel is a BuildRequires for evince. If you remove djvulibre, evince will become unbuildable." [[JesseKeating|Jesse Keating]] responded that Daniel, or his team should fix the package as "[i]f we have to do a chained rebuild for various reasons, evince would fail due to this package not building first."
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00323.html
| |
| | |
| The inclusion of ''monodevelop'' in the list had the side effect of spurring the ''Mono'' maintainers including [[MichelSalim|Michel Salim]], [[DavidNielsen|David Nielsen]] and [[PaulJohnson|Paul Johnson]] to decide[8] to attempt a co-ordinated push of "Mono-2.0".
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00385.html
| |
| | |
| === MinGW on Fedora ===
| |
| | |
| The availability of a ''MinGW'' development repository was announced[1] by [[RichardJones|Richard Jones]]. "MinGW" provides a GNU toolchain on Windows allowing the development of Free native Windows binaries. Richard credited [[DanielBerrange|Daniel Berrange]] with a good deal of the work.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00296.html
| |
| | |
| In response to [[FarkasLevente|Farkas Levente's]] question, as to when it would be available in Fedora, Daniel replied[2] that due to the need for "infrastructure" to create a separate repository and dedicated build root it was impossible to predict. [[User:Jspaleta|Jef Spaleta]] seemed[3] to be trying to move the process forward and published a draft which explained that "[t]he initial impetus for this effort has been ovirt developers who desire to more easily use Fedora installations as development environments for the work they are doing to build open source cross-platform virtualization tools." The possible impact on FedoraProject resources appears to have led to the compromise of creating a separate repository which could be strictly confined in size.
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00298.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00364.html
| |
| | |
| [[RichardJones|Richard Jones]] encouraged[4] Farkas to try out MinGW without waiting for official inclusion in Fedora "[...] if you want to download and play with it, and send patches :-) It's currently buildable on Rawhide, and possibly on earlier versions of Fedora too." Farkas then revealed that he currently used an older MinGW on RHEL5 and Richard responded[5] that although there were no srpms at this moment it should be possible to use the specfiles and patches (both in the mercurial repository[6]) to rebuild everything.
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00300.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00330.html
| |
| | |
| [6] http://hg.et.redhat.com/misc/fedora-mingw--devel/
| |
| | |
| === Dependency Loops Considered Harmful? ===
| |
| | |
| [[MiroslavLichvar|Miroslav Lichvar] raised[1] the issue of a considerable number of packages (354 by his count) which are components of dependency loops in the rawhide repository. Miroslav provided[2] a list. In such loops two or more RPM packages require each other as dependencies in their spec files with the result that it can become confusing for users trying to remove selected packages manually with ''yum'' or ''rpm''. Miroslav wondered whether such loops were acceptable and specifically "why games data depend on binaries?"
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00149.html
| |
| | |
| [2] http://fedorapeople.org/~mlichvar/tmp/rawhide.i386.loops
| |
| | |
| A substantial conversation resulted which exposed the different needs of packagers and users, some possible limitations due to the design of ''rpm'' and varied philosophies concerning the correct way to specify dependencies. One of the central examples chosen were the game packages which tend to be split into a "binary" or "engine" package and a companion "data" package for graphics, sound and levels. The central concerns expressed were that occasionally an install followed by a remove will leave "orphaned" packages behind. Also in contention was the specific case of developers experiencing the problem of maintaining a stable environment when there is no easy way of tracking changes to system libraries. The package manager ''aptitude'' was mentioned favorably due to its ability to distinguish between packages installed automatically to satisfy dependencies and those which are installed manually.
| |
| | |
| On the one hand [[ChrisSnook|Chris Snook]] and [[MichaelSchwendt|Michael Schwendt]] advocated[3] that instead of using <code>Requires: foo >= X</code> in their spec files packagers should choose <code>Conflicts: foo < X </code>. The possible downside to this would be installing game data yet having no game engine/binary installed. This was seen as a non-serious problem.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00211.html
| |
| | |
| On the other hand [[JonCiesla|Jon Ciesla]] argued[4] that the advantage of having games data depend on their binaries from a packagers perspective is that it ensures that attempting to upgrade the binary <code>Version</code> without also upgrading the data will fail. The case of allowing minor fixes without forcing users to download a big bundle of data can be handled by bumping the <code>Release</code> of the package. More concisely he answered[5] that the reason for the dependencies was that "[...] so when you remove the game, you remove the data." Michael responded[6] that Jon's example could be handled by using a <code>Requires: foo-data = X</code> without exposing the increased risk of needing to "bump'n'rebuld" the data package each time the engine package incremented its <code>Version</code> while still working with the same data. He characterized such dependencies as "superfluous [...] try[ing] to enhance 'yum remove'."
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00150.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00151.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00161.html
| |
| | |
| This was not accepted as accurate by Jon and he described the current situation as "require on name and version" for game data which allows <code>Release</code> to be changed without affecting the match on <code>Name</code> and <code>Version</code> "If new data is required, it will change the version. If not, we only increment the binary rpm's release, so the data rpm matches on version and needs no rebuild." Michael responded[7] by laying out two cases, the first of which illustrated the problem of having to update the data package solely to keep in step with updates to the version so that <code>yum remove</code> would function properly. His alternate case used non-versioned dependencies in the data package and strict dependencies in the engine package. [[HansdeGoede|Hans de Goede]] seemed a bit irritated and asked Michael to "Please take an actual look at game spec files before making up all kinds of BS, it's really easy" and argued that for games there was a one-to-one mapping between the engine and the data. He added that just because other cases resulted in dependencies being sucked in by an install and left behind on a remove there was no reason to change the way things were done for games.
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00167.html
| |
| | |
| [[StephenGallagher|Stephen Gallagher]] suggested that the "groups" exposed through ''yum'' should be used to bundle together the multiple packages for an application instead of using looped dependencies to which [[CallumLerwick|Callum Lerwick]] replied[8] that it was actually time to "implement the per-package 'explicitly installed/pulled in as a dep' flag that has been discussed several times in the past, and is already implemented (thus proven) in the 'aptitude' apt front end." He followed this with an amusing piece of hyperbole about "the looming dark future of closed DRM-laden content delivery services[.]"
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00193.html
| |
| | |
| [[ToshioKuratomi|Toshio Kuratomi]] raised[9] the problem faced by developers using system libraries that could come and go due to packages being updated or removed. Callum's suggestion was[10] that developers should be "RPM packag[ing] your app. Apps on your system that are not tracked by RPM are a ticking time bomb of dependency breakage whether or not the 'leaf culling' is performed manually or is assisted by a 'pulled in as dep' flag. A package or distribution update could very well break your app too." Needless to say Toshio had[11] several objections to this including the impact on developer workflow imposed by packaging up everything and the inadvisability of forcing developers to become expert administrators. He suggested that "If we implement this, it needs to be at a low enough level that anyone installing packages on the system will be storing the information. That could mean rpm (since rpm is responsible for taking the package and turning it into files on the filesystem) or that could mean yum since yum is the one that actually knows whether a package is being installed due to depsolving or user request. Doing this at a higher level means that information gets lost (for instance, if you do this in PackageKit, there won't be any information about what anaconda chose to install due to checkboxes being clicked and which things were installed due to dependencies). With that said, there needs to be a way for a developer to tell yum not to prune away leaf packages if they want." A very detailed and amusing discussion with (among others) [[MatthewWoehlke|Matthew Woehlke]] followed in which Matthew argued[12] for a script which essentially produced a parallel iuserj rpm database so that quick and dirty rpms could be produced locally for developers.
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00195.html
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00209.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00214.html
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00278.html
| |
| | |
| [[User:jspaleta|Jef Spaleta]] wondered[13] what actual examples revealed about the amount of harddrive space being consumed by dependencies and remarked "I hope the packagekit people are watching this discussion. The game data subpackaging issue should be right up their ally in terms of end-user ease of use issues." He discounted the polluting of the packagelist but [[MichaelSchwendt]] pointed out[14] that as the packagelist increases then "[because of] the frequent updates common in Fedora land, you need to download and update more[.]"
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00162.html
| |
| | |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00170.html
| |
| | |
| The idea of keeping game data outside of any package management was mentioned[15] by [[JamesAntill|James Antill]] as an "obvious fix" and he discounted the probability of PackageKit being able to do anything about the issue if ''yum'' or ''rpm'' could not. Jef responded[16] that "[a]t some point someone is going to have to wade into rpm itself for ease of use of removals to get better" and pointed out that he was "[...] making sure that the people with the right motivation and the right skills find the right way to handle it. That's not going to happen just by telling the current maintainers who are abusing the available requires syntax that they are abusing the syntax and slapping their wrists." [[RichardHughes|Richard Hughes]] showed[17] that the PackageKit developers were indeed listening to the conversation and mentioned that he had considered "[...] running through a large "get-depends" output into the basename filter, so that the user only sees the 'applications' by default, rather than a huge list[.]"
| |
| | |
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00184.html
| |
| | |
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00185.html
| |
| | |
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00212.html
| |
| | |
| There is a lot more to this conversation than reported here, but the main thrust is that the limitations of ''rpm'' have resulted in package maintainers wrangling spec files to do what they want which in some cases has undesirable effects.
| |
| | |
| === Fedora Security Tools Spin ===
| |
| | |
| A suggestion was made[1] by [[HuzaifaSidhpurwala|Huzaifa Sidhpurwala]] to produce a Security Tools spin similar to the "Knoppix Security Tools Distribution"[2] .
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00108.html
| |
| | |
| [2] http://knoppix-std.org/index.html
| |
| | |
| [[ToddZullinger|Todd Zullinger]] responded[3] that there was already a spin similar to this being curated by [[LukeMacken|Luke Macken]]. The SecuritySpin[4] mentioned by Luke seemed to be roughly what Huzaifa was searching for, except that he thought it should have "more tools and [be] more bare bones".
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00110.html
| |
| | |
| [4] https://fedoraproject.org/wiki/SecuritySpin
| |
| | |
| [[AdrianPilchowiec|Adrian Pilchowiec]] mentioned[5] a free fork of ''nessus'' named ''OpenVAS''[6] as a desirable part of the spin. Luke drew[7] attention to the need for more people to help out with packaging missing tools. Subsequently the wishlist of the project recorded that Huzaifa was packaging up ''OpenVAS'' and ''labrea''.
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00275.html
| |
| | |
| [6] http://www.openvas.org/
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00183.html
| |
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."
