|
|
| (87 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]] |
| | |
| === Unsigned Rawhide Packages an Attack Vector ? ===
| |
| | |
| [[RahulSundaram|Rahul Sundaram]] noticed[1] that when using <code>PackageKit</code> to obtain updates from the rawhide repository a warning for each package was displayed as they are all unsigned. He asked "[it] is just plain annoying. Can't we do something nice about that?"
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00959.html
| |
| | |
| The planets may have wobbled in their orbits when [[RalfCorsepius|Ralf Corsepius]] responded[2] "IMO the 'only correct approach' would be to only have signed packages in rawhide" and Rahul agreed[3] completely "[m]any of us including me run rawhide for a large time of the Fedora development cycle, a security exploit in one of our machines via a bad rawhide mirror can result in malicious packages being pushed to stable repositories or other even worse issues. We should take this attack vector seriously." He asked if the reason was due to the time delay.
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00960.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00964.html
| |
| | |
| [[JoshBoyer|Josh Boyer]] confirmed[4] that time delay was the central problem and added "[...] the fact that we have a very limited number of people that know the signing key." [[TillMaas|Till Maas]] pointed[5] to the need for more developers to help [[JesseKeating|Jesse Keating]] implement the Sigul[6] signing server that "[...] stores the signing keys within smartcards or something similar."
| |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00980.html
| | === Would You Like to Write This Beat ? === |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00976.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. |
|
| |
|
| [6] https://fedorahosted.org/sigul
| | <references/> |
|
| |
|
| [[RichardHughes|Richard Hughes]] suggested[7] that although PackageKit should simply abort any transaction involving an unsigned package it might be possible to add a configuration setting <code>UnsignedPackages=abort|warn|allow</code> to <code>PackageKit.conf</code> and asked for opinions on whether it was possible for "[u]pstream [to] set this to abort, and patch the package in rawhide to "allow" -- having F10 set to warn or abort[?]" In response to [[DenisLeroy|Denis Leroy's]] suggestion that such properties belonged to the repository rather than the package manager Richard agreed[8] that the policy would be implemented only if the repository declared itself as unsigned.
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01004.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. |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01010.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?" |
|
| |
|
| === Procedure for Re-naming a Package ===
| | 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. |
|
| |
|
| Two issues were raised[1] by [[PatriceDumas|Patrice Dumas]] in a post which initially asked for information on the formal procedure to rename a package and later explored the apparent lack of an active <code>LaTeX</code> and <code>TeX</code> community within the Fedora Project.
| | <references/> |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00210.html
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| Patrice listed all the possible places on the wiki which should contain the information but failed to do so. [[DebarshiRay|Debarshi Ray]] remembered[2] a similar request on @fedora-packaging to which [[TomCallaway|Tom Callaway]] had suggested: "[...] just open a ticket with Fedora Release Engineering (http://fedorahosted.org/rel-eng) and request the renaming of the package." A slightly different procedure was advanced[3] by [[JesseKeating|Jesse Keating]]: "Renaming a package is just bringing in the new package, getting it reviewed, particularly for correct Provides/Obsoletes, and then requesting that the old named package be removed." [[ThorstenLeemhuis|Thorsten Leemhuis]] concurred[4] with this but pointed out that decisions made by FESCo had not been documented properly on the wiki.
| | [[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?" |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-packaging/2008-October/msg00004.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. |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00220.html
| | <references/> |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00224.html
| | === Who Wants a Pony? === |
|
| |
| The procedure appeared cumbersome to Patrice although Jesse argued[5] that a new review was useful in order to help diminish "[...] the vast number of improper Provides/Obsoletes I've ran across [.]" Patrice stuck to the idea that time spent "re-reviewing" the package would be better spent elsewhere. Specifically he worried[6] that not enough reviewers knowledgeable about <code>TeX</code> and <code>LaTeX</code> were active and able to keep pace with the "[...] rapid pace of changes linked with switching to texlive 2007 and now 2008 [.]" In response to interest from [[MatejCepl|Matej Cepl]] he posted[7] a list of pending reviews.
| |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00234.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. |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00278.html
| | <references/> |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00450.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| === Review of trash-cli Raises Generic Naming Issues ===
| | [[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>. |
|
| |
|
| The maintainer of the putative <code>trash-cli</code> package, [[User:lokthare|Jean-François Martin (lokthare)]], asked[1] whether any package reviewers were interested in examining trash-cli . The package implements the FreeDesktop.org trash specification via the command line. The package had been partially reviewed previously by [[PatriceDumas|Patrice Dumas]] who seemed generally supportive and interested but had expressed[2] unhappiness with the generic nature of one of the command names, <code>trash</code>, provided by the package . The other command names are: <code>list-trash</code>; <code>empty-trash</code>;<code>restore-trash</code>. Patrice had suggested to Jean-Francois that other reviewers might react more favorably but that it would be better to persuade upstream to change the names of the commands.
| | 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." |
| | | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00216.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] https://bugzilla.redhat.com/show.bug.cgi?id=448122
| |
| | |
| This objection was re-iterated[3] by [[MichaelSchwendt|Michael Schwendt]] with the addition of the explanation that such names increased the chances of a namespace collision between current and future packages. Reference was made to existing generic naming of <code>samba</code> commands by [[JuhaTuomala|Juha Tuomala]] and <code>player</code>[4] by [[YankoKaneti|Yanko Kaneti]]. [[TimNiemuller|Tim Niemuller]] argued that for the latter case the review had covered the naming problem and decided that adhering to upstream convention in the absence of present conflicts was the best policy as it allowed users to easily reproduce commands found elsewhere on the internet. A longish exchange followed in which Patrice argued[5] that upstreams should consider such issues more carefully and suggested[6] that individual distributions could follow Debian's example and override upstream naming choices when necessary. Tim put[7] the case for respecting upstream choices as long as there were no obvious current conflicts. His suggestion to use <code>/etc/alternatives</code> to resolve the problem was challenged[8] by [[ToshioKuratomi|Toshio Kuratomi]] as an inappropriate use.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00223.html
| |
| | |
| [4] Player is part of a robot and sensor research system: http://playerstage.sourceforge.net/
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00287.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00324.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00359.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00320.html
| |
| | |
| Re-naming was considered[9] by Jean-Francois early on in the discussion and [[RahulSundaram|Rahul Sundaram]] recommended[10] alerting one of the FreeDesktop.org email lists to the change. [[BehdadEsfahbod|Behdad Esfahbod]] suggested renaming all the commands to follow the pattern <code>trash-*</code> and was engaged[11] by the primary developer [[AndreaFrancia|Andrea Francia]] in a discussion about why this might be preferable. [[MattMiller|Matt Miller]] wondered if it was a real problem and Andrea provided[12] a list of all the possible "trash" programs to show that none of them conflicted. [[JesseKeating|Jesse Keating]] commented[13] that this was because "[...] all of them were smart enough to avoid falling into the generic trap." The bugzilla entry indicated[14] that upstream was going to rename the commands and the trash-cli commands will be available with the next release.
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00218.html
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00219.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00251.html
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00327.html
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00330.html
| |
| | |
| [14] https://bugzilla.redhat.com/show.bug.cgi?id=448122
| |
| | |
| === PackageKit-gstreamer-plugins Obsoletes Codeina ===
| |
| | |
| [[RichardHughes|Richard Hughes]] wondered[1] what he was doing wrong with the specfile for the <code>PackageKit-gstreamer-plugins</code> package. This package allows individual applications to call <code>PackageKit</code> to install[2] missing codecs.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00281.html
| |
| | |
| [2] http://blogs.gnome.org/hughsie/2008/10/02/codec-install-in-fedora-10/
| |
| | |
| The bugzilla error filed[3] against the package reported that it conflicted with the codeina package[4], which was the previous method to install plugins for GStreamer aware applications. Richard wondered if a simple <pre>Obsoletes: codeina
| |
| Provides: codeina
| |
| </pre>
| |
| would do the trick, but [[PaulHowarth|Paul Howarth]] cautioned[5] "[u]nversioned obsoletes are bad and should be avoided like the plague." [[MatejCepl|Matej Cepl]] suggested[6] using the RPM name and version macros:
| |
| <pre>Obsoletes: codeina < 0.10.1-10
| |
| Provides: codeina = %{version}-%{release}</pre>
| |
| | |
| [3] https://bugzilla.redhat.com/show.bug.cgi?id=465723
| |
| | |
| [4] http://fedoraproject.org/wiki/Multimedia/Codeina
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00284.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00443.html
| |
| | |
| [[VilleSkyttä|Ville Skyttä]] wondered "[i]s the Provides: above appropriate in the first place, or should only the Obsoletes: be there? The only thing PackageKit-gstreamerplugin and codeina appear to have in common is /usr/libexec/gst-install-pluginshelper." [[JesseKeating|Jesse Keating]] disputed[7] this but Villä explained[8] that "Dropping the Provides would mean that if something had a depdendency on codeina, that dep would be broken, and that pk-gstreamer-plugin couldn't be installed with "yum install codeina". I don't think it'd have any effect on whether pk-gstreamerplugin would/wouldn't be applied as an upgrade over installed codeina e.g. by yum (assuming the Obsoletes is left there)." He proved[9] his point with a practical example and this combined with [[JamesAntill|James Antill's]] observation[10] seemed[11] convincing.
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00468.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00471.html
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00480.html
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00481.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00483.html
| |
| | |
| === LXDE Feature Removal Disappointment - How to Avoid ===
| |
| | |
| Some possible problems with the package review process were raised when [[ChristophWickert|Christoph Wickert]] expressed[1] disappointment over the removal of his Lightweight X11 Desktop Environment (LXDE)[2] Feature from Fedora 10 without any apparent notification coming his way. The discussion was positive and restrained although Christoph was obviously upset. Christoph admitted that his feature was late but pleaded that he had followed the Feature Wrangler's advice and argued that the FESCo deliberations incorrectly assumed that most of his packages were unready. He requested an explanation of the concerns about breaking the string freeze as this was the other main reason for omitting LXDE from Fedora 10. [[BillNottingham|Bill Nottingham]] explained that "Groups in comps (and their descriptions) are translatable strings; adding or changing them breaks the string freeze [...]" and added that "[t]he feature is supposed to be testable by the feature freeze, which is the same time as the string freeze." Christoph argued[3] that in that case he should have been informed earlier.
| |
|
| |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00408.html
| |
| | |
| [2] https://fedoraproject.org/w/index.php?title=Features/LXDE#LXDE
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00422.html
| |
| | |
| Suggestions made[4][5] by [[KevinKofler|Kevin Kofler]] to hack around the translation problem were rebutted[6] by [[BillNottingham|Bill Nottingham]] as not following the string freeze policy and he also listed the uncompleted parts of the feature and wondered "[...] exactly what else is there to do when even the basic scope and test plan of the feature isn't ready?" Christoph responded[7] fully and explained that his outrage was because of a lack of communication from anyone and incorrect assumptions made during the FESCo deliberations. He thanked Bill for his feedback. Christoph contended that the necessary packages had in fact passed review contrary to an assumption that none of them had done so. The existence of this assumption was disputed[8] by [[BrianPepple|Brian Pepple]]. Christoph explained that in addition he had waited fruitlessly for FESCo to give him permission to make changes to <code>comps</code>.
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00446.html
| |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00457
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00461.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00484.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00521.html
| |
| | |
| [[ToshioKuratomi|Toshio Kuratomi]] tried[9] to calm the discussion by avoiding assigning fault to any party. He suggested trading reviews with other people, explained that any maintainer can make changes to <code>comps</code> without waiting for FESCo and suggested some improvements to the communication process. Apparently <code>MediaWiki</code> handles watches differently to <code>MoinMoin</code> and this might explain some missed information. But Toshio disavowed some of the stronger assertions made by Christoph as "unfair" and reminded him "[t]he Feature Page shows that the feature is not done. Checking bugzilla shows that the page is up-to-date in regards to the package review status. Beta is a deadline for features and that has come and gone. So the Feature is plainly not completed whether you were contacted or not; whether the people who commented knew all the particulars or only some." Finally Toshio interpreted the lack of FESCo commentary to "[...] a bunch of polite people not jumping in to say 'Me too' [.]" This part of the discussion did not seem to go much further, but [[NicolasMailhot|Nicolas Mailhot]] added[10] the interesting observation that "Comps is both central and under-regulated. You'll have a hard time finding who is supposed to approve comps policy, and the files themselves are wide open. However out of respect both for the people working on comps translations, and for the people working of comps consumers, I personally wouldn't make any deep restructuring such as new group creation after test1 (to give people time to react)."
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00493.html
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00514.html
| |
| | |
| [[RichardJones|Richard W. M. Jones]] supported[11] the idea that FESCo members were making decisions without reading the documentation or being interested in the topics and cited MinGW as another example. He suggested that FESCo members should volunteer to produces packages for MinGW. [[JoshBoyer|Josh Boyer]] dismissed[12] the accusations firmly and stated his own interest in MinGW and participation in the debate. The particular example of MinGW seemed ancillary to the central question and ended[13] in irascible disagreement when Richard re-iterated his request and accused FESCo members of lacking sufficient knowledge. The history of MinGW development has included[14] substantial disagreements due to the desire to[15] create a separate repository for it in opposition to Richard's wishes.
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00494.html
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00508.html
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00511.html
| |
| | |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00519.html
| |
| | |
| [15] https://fedoraproject.org/wiki/FWN/Issue142#MinGW.on.Fedora
| |
| | |
| Josh pointed to the finite amount of time FESCo board members have at their disposal: "If FESCo has to go and be an intimate part of a Feature in order for it to get approved or discussed, then that is what I would consider to be a very large failure. Reality dictates that the 9 people in FESCo do not have infinite time to do explicit things with every single Feature that gets presented. FESCo is a steering committee. We rely on you, the developers, to do your part for Features." Josh noted that other Fedora 10-approved Features had been dropped simply because of their owners failing to follow the process: "They were dropped later for nothing more than lack of following the Feature process. Not out of spite, or lack of interest, or some evil desire to promote only things that some Cabal cares about." Separately Josh explained[16] that although the advertising advantage of declaring LXDE a Fedora 10 Feature had been missed it did not mean Christoph's work was wasted.
| |
| | |
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00510.html
| |
| | |
| While sympathetic to Christoph and extremely interested in <code>LXDE</code> [[KevinFenzi|Kevin Fenzi]] was[17] largely in agreement with [[BillNottingham|Bill Nottingham]] and [[JoshBoyer|Josh Boyer]] that "[LXDE] was not testable by Beta, so it shouldn't be advertised as a feature this time. I'm sorry that that is due to communication problems. ;( I find it very unfortunate." He suggested that although there had been a string freeze it would be possible to make LXDE a Feature for Fedora 11. Christoph appeared[18] unhappy still but keen to move forward with these suggestions.
| |
| | |
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00495.html
| |
|
| |
|
| [18] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00513.html
| | === Russian Fedora ? === |
|
| |
|
| [[DavidWoodhouse|David Woodhouse]] expressed[19] regret at the lack of communication, sought further details to avoid such failures in the future and suggested "[o]ne thing we can do in future to make that situation better is Cc the feature owners when the meeting agenda is sent to fedora-devel-list." As a related matter he urged "[l]et's get the final two packages reviewed -- and that's another area where we could do with some improvement, because failing to approve packages really _is_ verging on the 'deletionism' you spoke of. But that's a separate discussion." He later proposed[20] "[...] that each FESCo member should try to work on at least one package review per week. Each week at the FESCo meeting, we'll ask members which reviews they've worked on in the past week [...] ad anyone else who considers themselves an active member of the Fedora development community should also try to do the same." The size of the review queue was cited by [[JohnPoelstra|John Poelstra]] as 1,212 which surprised[21] [[HansdeGoede|Hans de Goede]] into suggesting review swapping as a solution: "[...] what we should be promoting much more is exchange reviews. Just post a mail to fedora-devel-list, saying I've got these and these packages which need review, and I'll gladly review any other package in return." [[PatriceDumas|Patrice Dumas]] analyzed[22] the situation slightly differently and noted that many of the review requests were blocked upon waiting for upstream changes. He thought that "[...] the ratio of review requests that nobody had a look at over the number of fedora contributors" would be a statistic which might indicate if there were a problem with a lack of reviewers. | | 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. |
| [19] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00553.html
| |
|
| |
|
| [20] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00673.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]]. |
|
| |
|
| [21] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00829.html
| | <references/> |
|
| |
|
| [22] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00836.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| | 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]]. |
|
| |
|
| Matters seemed to end amicably enough when [[BrianPepple|Brian Pepple]] corrected[23] Christoph's assumption that FESCo meeting summaries were not being posted to @fedora-devel and this was accepted[24] with apologies by Christoph.
| | [[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>. |
|
| |
|
| [23] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00529.html
| | <references/> |
|
| |
|
| [24] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00649.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
| The positive note continued to be sounded when [[ChuckAnderson|Chuck Anderson]] asked[25] for some practical advice on how he could help out with reviews and Christoph sought[26] information on how to find suitable outstanding reviews.
| |
|
| |
|
| [25] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00854.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." |
|
| |
|
| [26] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00850.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."
