Developments
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Unsigned Rawhide Packages an Attack Vector ?
Rahul Sundaram noticed[1] that when using PackageKit 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 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
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." Till Maas pointed[5] to the need for more developers to help 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
[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00976.html
[6] https://fedorahosted.org/sigul
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 UnsignedPackages=abort|warn|allow to PackageKit.conf 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 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.
[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01004.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01010.html
Procedure for Re-naming a Package
Two issues were raised[1] by 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 LaTeX and TeX community within the Fedora Project.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00210.html
Patrice listed all the possible places on the wiki which should contain the information but failed to do so. Debarshi Ray remembered[2] a similar request on @fedora-packaging to which 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 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." Thorsten Leemhuis concurred[4] with this but pointed out that decisions made by FESCo had not been documented properly on the wiki.
[2] https://www.redhat.com/archives/fedora-packaging/2008-October/msg00004.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00220.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00224.html
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 TeX and LaTeX 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 Matej Cepl he posted[7] a list of pending reviews.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00234.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00278.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00450.html
Review of trash-cli Raises Generic Naming Issues
The maintainer of the putative trash-cli package, 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 Patrice Dumas who seemed generally supportive and interested but had expressed[2] unhappiness with the generic nature of one of the command names, trash, provided by the package . The other command names are: list-trash; empty-trash;restore-trash. 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.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00216.html
[2] https://bugzilla.redhat.com/show.bug.cgi?id=448122
This objection was re-iterated[3] by 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 samba commands by Juha Tuomala and player[4] by Yanko Kaneti. 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 /etc/alternatives to resolve the problem was challenged[8] by 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 Rahul Sundaram recommended[10] alerting one of the FreeDesktop.org email lists to the change. Behdad Esfahbod suggested renaming all the commands to follow the pattern trash-* and was engaged[11] by the primary developer Andrea Francia in a discussion about why this might be preferable. 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. 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
Richard Hughes wondered[1] what he was doing wrong with the specfile for the PackageKit-gstreamer-plugins package. This package allows individual applications to call PackageKit 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
Obsoletes: codeina Provides: codeina
would do the trick, but Paul Howarth cautioned[5] "[u]nversioned obsoletes are bad and should be avoided like the plague." Matej Cepl suggested[6] using the RPM name and version macros:
Obsoletes: codeina < 0.10.1-10
Provides: codeina = %{version}-%{release}
[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
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." 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 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 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. 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 Kevin Kofler to hack around the translation problem were rebutted[6] by 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 Brian Pepple. Christoph explained that in addition he had waited fruitlessly for FESCo to give him permission to make changes to comps.
[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
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 comps without waiting for FESCo and suggested some improvements to the communication process. Apparently MediaWiki handles watches differently to MoinMoin 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 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
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. 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 LXDE Kevin Fenzi was[17] largely in agreement with Bill Nottingham and 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
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 John Poelstra as 1,212 which surprised[21] 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." 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. [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
[21] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00829.html
[22] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00836.html
Matters seemed to end amicably enough when 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.
[23] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00529.html
[24] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00649.html The positive note continued to be sounded when 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
[26] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00850.html