|
|
| (85 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| {{Anchor|Developments}} | | {{Anchor|Developments}} |
|
| |
| == Developments == | | == Developments == |
|
| |
|
| Line 6: |
Line 5: |
| mailing list are summarized. | | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
| | |
| === Splitting Up R ===
| |
| | |
| [[TomCallaway|Tom Callaway]] alerted[1] the list that he intended to merge the <code>R-devel</code> package with the base <code>R</code>[2] package. Tom's motivation was that many complaints had been received from users who attempted to install extensions from the external CRAN[3] repository using R's built-in package system. "This doesn't work unless you have R-devel installed. The average R user is a professor or a student, and neither of them are going to necessarily possess the necessary Linux/Fedora knowledge to be able to understand why this doesn't work like the R documentation says it should." Tom recognized that this was a violation of the Fedora Packaging Guidelines[4] and that he was "[...] not entirely sure if I need FESCo or FPC approval to take this action, if so, this is my notice of requesting it. ;)"
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02240.html
| |
| | |
| [2] R is an interpreted language based upon S and Scheme intended to be used for statistical computation: http://www.r-project.org/
| |
| | |
| [3] http://cran.r-project.org/
| |
| | |
| [4] http://fedoraproject.org/wiki/Packaging/Guidelines
| |
| | |
| [[EnricoScholz|Enrico Scholz]] suggested[5] instead: "[...] add it to comps.xml [or] move 'R' to Rcore, and add 'R' which depends on 'R-core' + 'R-devel"' which have the major advantage of not missing all of R-devel's dependencies. Tom accepted[6] these points because "[...] the suggested R/R-core/R-devel split instead [would allow users] to get everything with yum install R, it would meet the guidelines, and minimal installs with R can simply have R-core."
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02249.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02251.html
| |
| | |
| [[JamesAntill|James Antill]] agreed that the general model of "foo-core + additions" was maintained by such a split but asked[7] "[...] why don't we just package more of the <code>R</code> modules so <code>CRAN</code> usage isn't a requirement?" [[JoséMatos|José Matos]] answered[8] that there were far too many R modules "[...] more than 1500 modules (the have been growing at an exponential rate in the last years). So while we would like to see more R packages in Fedora in are not even near to have a reasonable subset of R packaged." James worried[9] that "[...] you could use that argument a lot (there are probably still more unpackaged libc using things than packaged)." James showed that there were many more unpackaged users of libc than packaged using:
| |
| <pre>repoquery -whatrequires '*-devel' | \
| |
| fgrep -v - '-devel-' | \
| |
| fgrep -v - '-static-'
| |
| </pre>
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02267.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02272.html
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02274.html
| |
| | |
| The availability of a tool named <code>R2spec</code> to convert <code>R</code> package formats to rpm packages was mentioned[10] by [[MatthewSalzman|Matthew Salzman]]. Later threads which appeared in part only on @fedora-r-devel investigated the problem of languages implementing their own packaging systems. [[JoséMatos|José Matos]] played[11] Devil's Advocate with the remark that "[...] each language is building its own repository and packaging system in a sense we have lots of equivalents of (yum+rpm) for each language (perl, php, python, R, tex, ...) [but] for the system to be really useful it must use the least possible denominator (read the dumbest wins- pun intended ;-) )." José suggested that R2spec could also be tweaked to discover dependencies and include them in its generated spec files. It appeared[12] that Pierre-Yves had a "[...] small script to update the spec file when there is a new release of an already package R-library. This might be something that I should develop maybe a bit more now (especially since Bioconductor[12a] 2.3 has been released with R 2.8.0)"
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02288.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02301.html
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02306.html
| |
| | |
| [12a] Modules primarily for bioinformatics and genomics.
| |
| | |
| === Flinging Poo at libtool-2.2 ===
| |
| | |
| A discussion on the future of <code>libtool</code> in Fedora is worth reporting although it is slightly older. [[OrionPoplawski|Orion Poplawski]] wondered[1] whether it was the correct time to integrate <code>libtool-2.2.X</code> into Fedora 11. [[BenjaminKosnik|Benjamin Kosnik]] wanted[2] it available in Fedora before <code>GCC</code> was bumped to <code>gcc-4.4.x</code> as that will depend on <code>libtool-2.2.6</code>.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00467.html
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00516.html
| |
| | |
| A possible need for FESCo approval was expressed[3] by [[KarstenHopp|Karsten Hopp]] as he was worried that "[...] it breaks up to 300 packages according to my mass rebuilds. I'm going to prepare a Wiki page with details about that." That prompted the first of several queries about the purpose and suitability of <code>libtool</code>. [[DavidWoodhouse|David Woodhouse]] asked[4] "[i]sn't the whole point of libtool that it should make things _easier_, not break huge swathes of packages whenever we change it? How about we fix those 300 packages by making them _not_ use libtool, rather than making them use the latest version?" [[ToshioKuratomi|Toshio Kuratomi]] thought[5] that "If the state of the art has advanced and there's a tool that can replace libtool so a developer can say `I want a shared library' and the tool builds it on all platforms then we could look into getting upstreams to switch but simply getting rid of libtool in favour of handcoding Makefiles to build shared libraries is a step in the wrong direction."
| |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00479.html
| | === Would You Like to Write This Beat ? === |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00730.html | | 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. |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00737.html
| | <references/> |
|
| |
|
| AdamJackson offered[6] that gcc was available on <code>Solaris</code>, <code>Windows</code>, <code>*BSD</code> and <code>OSX</code> with the conclusion "[m]st of the complexity in libtool (and autotools in general) is to support systems that simply are not worth supporting and that practically speaking don't exist anymore. I'm being slightly flip in saying 'gcc -shared' but really not by much. Honestly for any fringe platform the correct thing to do is port gcc/binutils/gmake first." There were many disagreements on this point and [[SamVarshavchik|Sam Varshavchik]] posted[7] a convincing potted summary of them: "There's much more to libtool then just building shared libraries. If you remove everything from libtool that supports ancient platforms, you'll still have quite a bit left. For example, libtool builds both shared and static libraries in parallel. That, alone, saves you from dealing with a massive hairball in your makefiles. Ask anyone who works on a large, complicated app, that links with its own shared libraries. The option to easily build a statically-linked version is quite invaluable, for debugging purposes."
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00744.html | | [[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. |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00791.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?" |
|
| |
|
| The practical experience of the MinGW project related[8] by DanielBerrange was also that gcc -shared was insuOEcient i[...] if you're trying to build for windows. The mingw32 work has only been made viable because libtool has basically taken care of the horrible shared library build process required by Windows.j Further details were supplied[9] at Adam's request and KevinKoAEer confirmed[10] that producing a DLL involved several complications.
| | 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. |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00743.html
| | <references/> |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00755.html
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00780.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?" |
|
| |
|
| Discussion of alternatives veered[11] towards <code>CMake</code>. [[BradenMcDaniel|Braden McDaniel]] was unconvinced[12] that this was a realistic suggestion for replacing libtool in approximately three hundred upstream projects. [[KevinKofler|Kevin Kofler]] took[13] a detailed look at the problem and argued that attempting to "[...] convince the automake developers to use something other than libtool is pointless, because automake should also go away, it's at least as obsolete, buggy, unable to maintain backwards compatibility, annoying, a massive time waster at build time and a major PITA for developers to code with as libtool is. The whole autotools stack sucks. It always did, we just didn't have anything better. We now do, so why are people still using autotools?" His critique seemed convincing and he later added[14] that "CMake is used by all of KDE 4 [...]" and in an exchange with [[RichardJones|Richard W. M. Jones]] explained[15] that Gnulib was also not a good replacement for autotools: "[...] a "library" which works by copying itself into the source code of the project is a horribly broken concept."
| | [[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. |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00780.html
| | <references/> |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00775.html
| | === Who Wants a Pony? === |
|
| |
|
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00799.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. |
|
| |
|
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01017.html
| | <references/> |
|
| |
|
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01142.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| LennartPoettering and RalfCorsepius were[16] suspicious of the attempt to replace autotools with CMake. Ralf argued that "Cmake is imake in new clothes and suffers from the same design flaws as imake did. It's only the limited set of requirements being used by the limited set of use cases it's proponents apply which lets them think 'cmake is better'." StephenSmoogen saw[17] a need to halt the conversation when he examined it from a human neuropsychology viewpoint: "So basically this conversation is a 'dead' conversation. People have their hairs on their necks up, [enough] testosterone pumping to put [out] 3 or 4 beards in a day, and are [on] to the flinging poo part. At this point, there is no way either side is going to say that Cmake is better at this, or Autotools is better than that. Wait a week, and see if one can bridge the gap with some diplomatic discourse[.]"
| | [[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>. |
|
| |
|
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00954.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." |
| | | |
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01023.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/> |
| Later a new thread was started[18] by [[BradenMcDaniel|Braden McDaniel]] to recommend that <code>autoreconf</code> should be explicitly forbidden to be run by rpm packages. He explained that he saw the problems caused by running <code>autoreconf</code> or <code>libtoolize</code> as "[b]y running autoreconf, the RPM build becomes exposed to different versions of autoconf, automake, and libtool than were used by the upstream developer to create the upstream source package. Newer versions of these tools have the potential to introduce incompatibilities, breaking the RPM build. Rather than patching configure.[ac,in] and Makefile.am, a more resilient approach is to patch the configure script and Makefile.in files."[[ TillMaas|TillMaas]] added[19] a link to a wiki draft on the subject and suggested that "[...] one should run autoreconf locally and create a patch from this, that is then used within the spec." The conversation veered[20] into sharp disagreement as to whether autotool generated files should be treated similarly to "binary JARs (for which the packaging guidelines mandate that they have to be removed and rebuilt from source)" or this should be avoided in order to avoid "potential breakage". This issue seems destined to generate further disagreement.
| |
| | |
| [18] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00866.html
| |
| | |
| [19] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00869.html
| |
| | |
| [20] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00970.html
| |
| | |
| === Livna Migration to RPM Fusion ===
| |
| | |
| Several of the third-party repositories external to the Fedora Project agreed some time ago to merge into a single new entity named "RPM Fusion"[1]. The current partners include Dribble, Freshrpms and Livna. [[ThorstenLeemhuis|Thorsten Leemhuis]] reported[2] that "[...] nearly all of livna's packages have been imported and build for RPM Fusion, but a few are still missing. So you should leave livna repos enabled for now if you want everything [.]" Thorsten explained the migration process in this post with the important details that "[...] all users that installed livna properly (e.g. by installing the livna-release package) and enabled the testing repos will now get RPM Fusion enabled automatically."
| |
| | |
| [1] http://rpmfusion.org
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02367.html
| |
| | |
| A suggestion was made[3] by [[NicolasMailhot|Nicolas Mailhot]] to either use the "modern proxyfriendly createrepo" or else "define http.caching=packages" in the yum repo files.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02368.html
| |
| | |
| Users who currently have the Livna repository enabled can transition to the new RPM Fusion repository by:
| |
| | |
| <code>yum install rpmfusion-free-release rpmfusion-nonfree-release</code> | |
| | |
| === Sbin Sanity Stays ===
| |
| | |
| The latest FESCo meeting[1] logs record that the decision to add <code>/sbin</code> to each users <code>PATH</code> variable (see FWN#146[2]) will be kept until a working alternative for both non-root and root users is available. The brief deliberations indicate that FESCo members tended to manually add <code>/sbin</code> to their own paths and distilled the objections to the sole point of "".
| |
| | |
| [[ThorstenLeemhuis|Thorsten Leemhuis]] was dismayed[3] and agreed with [[VilleSkyttä|Ville Skyttä]] that the change would[[4]] result in many confused users. Thorsten wished to "[...] help Ville and Matthew making a real solution, where sbin stays "root commands" only, and where package that are right now get into he search path for ordinary users (either with symlinks or by moving the binaries). But it's IMHO best for everyone if we do that for F11. Come on, we had /sbin not in the path for more then how many years, so what is one half year more (especially as everyone that dislikes it is used to enable it already)?"
| |
| | |
| [[JonMasters|Jon Masters]] disagreed[5] on the basis that any script should be using an explicit and absolute binary location anyway: "If you're writing scripts and not explicitly calling out the binary location, then it's not surprising if your scripts break later. I know it's nice to always assume a particular PATH, but it's not good practice any more than including or not including sbin in the PATH to begin with." He also cautioned that most other distributions had made this change a long time ago and that "[...] everyone else is already laughing that Fedora didn't do this, so really it doesn't need to wait for yet another 1.5 years to get done :)"
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02273.html
| |
| | |
| [2] http://fedoraproject.org/wiki/FWN/Issue146#PATH:.2Fsbin.Tab.Confusion
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02294.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02180.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02296.html
| |
| | |
| === Packaging Webmin: Should it go in /opt ? ===
| |
|
| |
|
| [[AndyTheuninck|Andy Theuninck]] asked[1] for some help in "[...] trying to put a package together for webmin. It wants to install to libexec, but if I do that rpmlint (rightly) complains that there are non-executable text files. Perl files & HTML files are intermixed and separating them out would be a patching nightmare [...] as I read FHS /opt would be the most appropriate place [but] if I try to use /opt/webmin [then] rpmlint pitches a fit about using /opt."
| | === Russian Fedora ? === |
|
| |
|
| [[ToshioKuratomi|Toshio Kuratomi]] quoted[2] the FHS[3:] "The FHS says: /opt is reserved for the installation of add-on application software packages. Anything packaged by Fedora is part of the system packaging rather than an addon so we stay out of /opt." He also suggested that separating the different files types and getting webmin's upstream[4] to accept patches to do this was a preferred path in the Fedora Project. Failing this it was possible to separate the files and symlink them to the upstream-enforced layout. Another useful link[5] to the Fedora Project's web application packaging guidelines in Toshio's post indicated that non-executable files might best be put into /usr/share. Andy seemed[6] to like the idea of "[m]oving as much as possible over to /usr/share and symlinking against the files that are actually needed[...]" as this would allow upstream to continue to support many OSes by the simple expedient of "sticking everything into a single directory." | | 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. |
|
| |
|
| [[NicolasMailhot|Nicolas Mailhot]] disparaged[7] the use of /opt as "[...] he right place to dump messes and is good enough for ISVs with no ambitions but Fedora does not package messes [.]" [[CaseyDahlin|Casey Dahlin]] cautioned[8] Nicolas "Easy, he's here because he wants to do the right thing, and he's not upstream, so there's no reason to clueby4 him just yet" and went on to suggest a similar path to that above: "You might do what apache does and simply place the files where they go, then symlink them to a conf directory in /etc . You'd be doing it on a much larger scale than apache, but until you get upstream to suck less, you at least have a precedent for it (though doing it for apache hasn't particularly encouraged them to change their goofy-as-hell recommended file layout)." | | 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]]. |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02289.html
| | <references/> |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02291.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [3] Filesystem Hierarchy Standard: http://www.pathname.com/fhs/ | | 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]]. |
|
| |
|
| [4] http://www.webmin.com/ | | [[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>. |
|
| |
|
| [5] http://fedoraproject.org/wiki/Packaging/Guidelines#Web.Applications
| | <references/> |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02327.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02297.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." |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02300.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."
