From Fedora Project Wiki

< FWN‎ | Beats

(fwn #147 spellchecked, first pass)
(fwn #148 spell-checked)
Line 8: Line 8:
Contributing Writer: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[OisinFeeley|Oisin Feeley]]


=== Unsigned Rawhide Packages an Attack Vector ? ===
=== OpenOffice and go-oo ===


[[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?"
The controversy swirling around the OpenOffice.org "fork" named "go-oo" popped up[1] along with a request for information about why "[...] Fedora ships a relatively stock (stock + 98 patches) OO.o rather than shipping [...] the extended feature set provided by go-oo such as the opengl slide transitions [?]" [[CaolanMcNamara|Caolán McNamara]], the maintainer, explained[2] that he attempted to stick close to upstream "[w]ith a fairly aggressive push of any fedora patches back upstream asap [...]" and based upon the low number of reported bugs he believed "[...] this route provides the stablest and best supported product for fedora users." Caolán added that the OpenGL slide transitions were "still in a bit of a confused state" but would probably appear in Fedora 11. While Caolán eschewed any animosity to the parent ooo-build[3], and emphasized that Fedora had contributed <code>fontconfig</code> glyph replacement functionality to ooo-build and extended their <code>GStreamer</code> patches, he suggested that using ooo-build as an upstream would result in a confusing morass of patches upon patches.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00959.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01134.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/msg01140.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00960.html
[3] A collection of patches presented through a subversion repository which was intended to work around organizational and practical bottlenecks in OpenOffice.org development. http://wiki.services.openoffice.org/wiki/Ooo-build


[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00964.html
[[MuayyadAlSadi|Muayyad AlSadi]] argued[4] that go-oo should be used because "[...] one can drop java and ship openoffice on a livecd [like Novell, Gentoo, Ubuntu.]" In the exchange that followed Muayyad revealed[5][6] that he had produced a Fedora-derived LiveCD with <code>Openoffice.org</code> on it by the expedients of moving some large Java <code>jar</code> and <code>.class</code> files out of the core rpm package and restricting the language choice to Arabic only. Muayyad suggested that adding the resulting missing pieces could be done by adding them to comps.xml . Caolán argued[7] that providing a non-working OpenOffice.org (the search functionality depends on Lucene[8] and the XSLT wizard depends on SAXON[9] both of which are written in Java) was an unacceptable user experience. It also appeared that the other distributions mentioned by Muayyad had restricted themselves to a small subset of languages which would result in a non-usable OpenOffice.org for many Fedora users.


[[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/msg01163.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00980.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01181.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00976.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01291.html


[6] https://fedorahosted.org/sigul
[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01287.html


[[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. 
[8] A text search-engine library: http://lucene.apache.org/java/docs/


[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01004.html
[9] An XML stylesheet processor: http://saxon.sourceforge.net/


[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01010.html
Caolán suggested[10] that using go-oo as a base would not solve the Java dependency and referred[11] to his own work to reduce Java dependencies as a way in which this goal might be achieved: "Taking `removing java from core dependencies' as the target, then the right approach is the boring slow-fix stuff to e.g. rewrite the help search to not require the java lucene stuff and to tweak the xsltfilter stuff to be a standalone expert-style feature that only appears in the menus when the xsltfilter package is installed and place the saxon requires on that subpackage, and so on for other java functionality." Caolán had previously split out the <code>beanshell</code> scripting engine to a separate package and he recommended that Muayyad: "[...] investigate further as to why exactly removing or replacing java dependencies is the target, when I last thought seriously about the area I felt the right thing to do was stop swimming against the tide and boil out some concrete standalone feature requires for gcj to be able to provide the functionality that was missing at that stage to implement the java-needs of OOo, and our fabulous java hackers simply implemented them. Your questions should be what exactly are the size figures are for requiring the java dependencies and where is that space getting used and why."


=== Procedure for Re-naming a Package ===
[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01362.html


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.
[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01460.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00210.html
=== PackageGurus, SpecMentats or UeberPackagers? ===


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.
On 2008-08-13 it was announced[1] on @fedora-announce that CVS access had been revamped to allow trusted users to modify packages "distro-wide", not merely packages which they own or co-maintain. In order to clarify the changes some new terminology was introduced. Ordinary maintainers (previously members of the "cvsextras" group) are now members of the "packagers" group and those who are trusted to assist with all packages are members of the group named "uberpackager". This change has been coming for some time (see FWN#136[2] for previous discussions) and seems as though it will help cut out some bureaucracy.


[2] https://www.redhat.com/archives/fedora-packaging/2008-October/msg00004.html
[1] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00007.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00220.html
[2] http://fedoraproject.org/wiki/FWN/Issue136#New.libraw1394.Rebuild.Exposes.Closed.ACLs


[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00224.html
[[LennartPoettering|Lennart Poettering]] objected[3] to the term "uberpackager" as too redolent of "Nazi terminology" and asked "[...] if we have "Überpackagers", maybe it's time to rename normal packagers to "Unterpackagers"? That would fit awfully well into our pursuit for world domination, wouldn't it?"
 
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
[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01657.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00278.html
[[CaseyDahlin|Casey Dahlin]] took the point but wondered[4] why Lennart had waited until now to object which led[5] Lennart to clarify that he did not follow all Fedora mailing-list discussions and "[...] noticed the adoption of this term for the first time a week or two ago when I had to log into FAS and noticed I had become an Überpackager. And, oh, god, with my blonde hair and blue eyes it felt so deserved... "


[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00450.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01658.html


=== Review of trash-cli Raises Generic Naming Issues ===
[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01661.html


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.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00216.html


[2] https://bugzilla.redhat.com/show.bug.cgi?id=448122
Many respondents were sympathetic to the objection. [[PaulFrields|Paul Frields]] explained[6] that "[u]se of "über-" has indeed made the jump to slang English. I think there's an increasing tendency in new media communities to attempt to subvert or undermine existing connotations of terms, for better or worse. In cases like this, I think we unconsciously or semi-consciously think we're deflating any unpleasantness by using them casually.I'm certain no offense was intended, but your comment is worth serious consideration." The problem of over-sensitivity was raised by several contributors including [[AndrewParker|Andrew Parker]] who asked[7] "Do we have to have all our words vetted against every language before we can use them?" and provided some examples of common failures to do this. [[AxelThimm|Axel Thimm]] added[8] further arguments against Lennart's interpretations.


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.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01659.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00223.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01785.html


[4] Player is part of a robot and sensor research system: http://playerstage.sourceforge.net/
[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01815.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00287.html
Some extensive bike-shedding[9] followed with suggestions for alternate terminology ranging from [[JonCiesla|Jon Ciesla's]] "spec-mentat"[10] to [[SethVidal|Seth Vidal's]][11] "WednesdayPackager". Seth exclaimed[12] "[...] our ability to make subtle references that even we eventually don't understand kicks ass. :)"


[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00324.html
[9] http://en.wikipedia.org/wiki/Color.of.the.bikeshed


[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00359.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01662.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00320.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01800.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.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01863.html


[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00218.html
At one stage it appeared[13] that [[ToshioKuratomi|Toshio Kuratomi]] would change the name to "ultrapackagers" and Lennart excused[14] himself from further discussion: "Toshio already agreed to changing this term and it is not too much work. So let's just do it and forget about it and not continue this discussion here. I am here for the code, not for discussing Nazism." [[AxelThimm|Axel Thimm]][15] and [[TillMaas|Till Maas]] disagreed[16] that the prefix "über-" necessarily carried the connotations associated with it by Lennart and several others on the thread. Toshio noted[17] that he would need to make any change either tomorrow or else put it off until after the freeze. In passing he expressed a preference for the term "masterpackager" leading [[JesseKeating|Jesse Keating]] to joke[18] that he preferred his bike sheds colored chartreuse.


[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00219.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01675.html


[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00251.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01826.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00327.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01836.html


[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00330.html
[16] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01897.html


[14] https://bugzilla.redhat.com/show.bug.cgi?id=448122
[17] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01902.html


=== PackageKit-gstreamer-plugins Obsoletes Codeina ===
[18] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01904.html


[[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.
=== A Single Torrent ? ===


[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00281.html
The ability of many torrent clients to offer the user a choice of specific files within a torrent prompted [[JesseKeating|JesseKeating]] to ask[1] "[...] does it make sense to collapse the DVD and CD torrents into a single torrent and allow people to use the client to pick which they want? Are there pros/cons to this?"


[2] http://blogs.gnome.org/hughsie/2008/10/02/codec-install-in-fedora-10/
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01735.html


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
[[JonCiesla|Jon Ciesla]] wondered if the perceived "lowest common denominator client" <code>bittorrent-curses</code> offered this ability. <code>bittorrent-curses</code> was dismissed[2] as being dead and closed by [[JesseKeating|Jesse Keating]] which led[3] to a slightly hyperbolic demand by [[BehdadEsfahbod|Behdad Esfahbod]] for an equivalent to facilitate "mindless" downloading. In a later exchange with [[JohnReiser|John Reiser]] it was clarified[4] that the "old dead" <code>bittorrent4.4.0-7</code> only downloaded all files in a torrent. [[DenisLeroy|Dennis Leroy]] and [[ConradMeyer|Conrad Meyer]] provided[5] reassurance that both <code>rtorrent</code> and <code>transmission</code> provided ncurses-based interfaces that offer marking specific files for download.
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
[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01745.html


[4] http://fedoraproject.org/wiki/Multimedia/Codeina
[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01753.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00284.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01752.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00443.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01808.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.
Jesse explained[6] that one advantage of what he was suggesting was "[w]e can reduce the number of links offered to users on download pages, simplify the instructions, and have a better end user experience." His workflow avoided resorting to the command line.


[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00468.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01760.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00471.html
[[RichiPlana|Richi Plana]] responded[7] that lumping all the isos into a single torrent was not a good idea as "[m]ost people really only download one iso [...]" and Jesse hastened[8] to clarify "I meant collapsing them per arch, so you'd have one torrent file for Fedora 10 x86.64, one for Fedora 10 i386, ppc, source etc.. and probably different torrent files for the i686 Live and x86.64 Live offerings. I wouldn't imagine one giant torrent file that has every iso of the release on it."


[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00480.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01751.html


[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00481.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01761.html


[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00483.html
Some definite preferences were expressed[9] by [[ChrisSnook|Chris Snook]] on how to Do The Right Thing By Default: "there needs to be a standalone torrent that has just the DVD ISO (and maybe the netinst ISO) for all those newcomers who don't know any better, so we don't scare them off with a 9 GB torrent." Chris raised the problems of prioritization and smaller sets of disjoint peers for more specific torrents, especially for the case[10] of one CD iso per torrent. The ability to prioritize specific files might allow work to be started sooner by, for instance, downloading a LiveCD first. [[CallumLerwick|Callum Lerwick]] suggested [11] using <code>Azureus</code> for this purpose.


=== LXDE Feature Removal Disappointment - How to Avoid ===
[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01764.html


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.
[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01772.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00408.html


[2] https://fedoraproject.org/w/index.php?title=Features/LXDE#LXDE
[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01806.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00422.html
A separate problem posed[12] by [[SethVidal|Seth Vidal]] was the absence of good trackers and seeders: "[I]n terms of clients - there are a lot of choices. In terms of trackers and good server-like-seeders there are NOT a lot of choices. [T]he original bittorrent client pre-proprietary is the best we have right now." [[CallumLerwick|Callum Lerwick]] again noted[13] <code>Azureus</code>' abilities: "I'd suggest just biting the bullet, fire up a vncserver instance, and run Azureus. It is incredibly flexible at managing many torrents at once, it can run a tracker as well, and the GUI allows you a level of insight into the status of a torrent that you just won't get from a text client."


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>.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01759.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00446.html  
[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01807.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
=== The Old Sendmail Argument ===


[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00484.html
An old discussion (see FWN#145[1]) was given new legs when instructor [[LutzLange|Lutz Lange]] asked[2] why <code>sendmail</code> "[...] is still the default MTA in Fedora [?]" [[PatriceDumas|Patrice Dumas]] answered[3] with an excellent summary of the discussions preceding Fedora 10: "To sum up some people considered that local delivery was a must for the default MTA, and that a send-only MTA wasn't good enough, e.g., for cronie. My personnal opinion is that there should not be any MTA in the @base or @code group, and that a MTA should be chosed if it is pulled in as a dependency, so it could be sendmail or anything else. Whether local delivery is a must for cronie or other packages that today require /usr/sbin/sendmail is another story that caould be discussed a bit more, though in the end it seems to me that this should be up to the maintainer."


[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00521.html
[1] http://fedoraproject.org/wiki/FWN/Issue145#Default.Deactivation.of.Services


[[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)."
[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01693.html


[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00493.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01694.html


[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00514.html
[[LesMikesell|Les Mikesell]] rose[4] to the defense of <code>sendmail</code> as a highly-audited and extensible standard with which most administrators are familiar. All these points were disputed by various and sundry and [[DominikMierzejewski|Dominik Mierzejewski]] added[5] the interesting information that <code>postfix</code> has partial <code>milter</code> support thus allowing it to be extended easily. [[DavidWoodhouse|David Woodhouse]] took issue[6] with the idea that <code>milter</code> support was important: "Some of the better alternatives don't even _try_ to run milters, because they are fully-featured enough in their own right, without needing to rely on external software" and appeared[7] to put to rest the idea that it was difficult for these alternatives to run tests on messages prior to accepting them in an SMTP conversation. Les finished[8] off with an argument invoking the inertia of a wide base of currently working sendmail systems: "[Postfix is] worse at backwards compatibility. Fedora seems to assume that their users don't already have something working, so maybe that's not a concern to anyone here. If it shipped with a decked-out, well tested setup already integrated with MimeDefang/clamd/spamassassin it might be enough of an improvement to switch."


[[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.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01697.html


[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00494.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01730.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00508.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01895.html


[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00511.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01917.html


[14] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00519.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01750.html


[15] https://fedoraproject.org/wiki/FWN/Issue142#MinGW.on.Fedora
Some abstruse jokes were cracked[9] when [[DenisLeroy|Denis Leroy]] observed[10] that "[t]he sendmail configuration file is arguably one of the most complex and obfuscated configuration format ever designed in the history of computer science. :-)" and [[AlanCox|Alan Cox]] suggested[11] comparing it to IBM's JCL or TECO. But [[LesMikesell|Les Mikesell]] believed[12] that "[...] these days all of the m4 templates anyone might ever need have already been written, so everyone just uncomments or tweaks a few lines in sendmail.mc for options and the default already does the right thing for most people. Or, for complex scenarios you can drop in MimeDefang as a milter and do most of the control steps with perl snippets."


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.
[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01708.html


[16] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00510.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01702.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.
[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01707.html


[17] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00495.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01710.html


[18] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00513.html
The decision to ship the Desktop spin[13] with no <code>MTA</code> was mentioned[14] by [[ColinWalters|Colin Walters]] with the observation that mail from <code>logwatch</code> would be sent to <code>/dev/null</code> as "[...] most logs from a desktop machine are just pure noise." In response to [[MatthewWoehlke|Matthew Woehlke's]] desire for a means to view some log information [[RahulSundaram|Rahul Sundaram]] suggested[[15]] working on <code>gnome-system-log</code>.


[[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. 
ArjanvandeVen threw[16] some cold water over the discussion with the observation that "[a]nybody trying to argue for the politics of Exim/Postfix/Sendmail as default choice is ignoring the reality..." as users simply requiring send-only MTAs can use sSMTP (or something similar) while those requiring a full-blown MTA have strong individual preferences. [[KarelZak|Karel Zak]] and [[ColinWalters|Colin Walters]] returned[17] to the vision of Fedora as a "desktop distribution" with Colin arguing "I understand there's the "workstation" use case where you're say doing web development and you want to install Apache or Tomcat or something locally and run logwatch on it. We obviously will support that. But it doesn't make sense for the default desktop OS to be sending you email about all the junk going on under the hood."
[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
[13] https://fedoraproject.org/wiki/SIGs/Desktop


[21] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00829.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01787.html


[22] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00836.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01791.html


[16] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01915.html


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.
[17] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01920.html


[23] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00529.html
=== Review-o-matic ===


[24] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00649.html
[[KushalDas|Kushal Das]] announced[1] that he was starting work on a project to help automate the repetitive parts of the review process, as originally suggested[2] by [[ChrisWeyl|Chris Weyl]] on @fedora-packaging. This seems timely in light of recent discussions which indicated (see FWN#111[3] and FWN#147[4)] that as the number of Fedora packages grows (PackageDB indicates[5] that Fedora has grown to offer approximately 6,842 packages) the review queue has on occasion become congested.
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
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01625.html


[26] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00850.html
[2] https://www.redhat.com/archives/fedora-packaging/2008-October/msg00023.html
 
[3] http://fedoraproject.org/wiki/FWN/Issue111#Review.Queue.Cont.
 
[4] http://fedoraproject.org/wiki/FWN/Issue147#LXDE.Feature.Removal.Disappointment.- .How.to.Avoid
 
[5] https://admin.fedoraproject.org/pkgdb/collections/
 
Kushal listed the basic tasks as: rpmlint; build in mock; md5sum matches between srpm and upstream. The tool would, upon submission of a new review request, download the SRPM and SPEC, run the aforementioned tasks and then post the results on bugzilla.
 
"Pierre-Yves" was among those that requested[6] the ability to make the build directly on <code>koji</code>. [[RichardJones|Richard W. M. Jones]] explained[7] that this would allow checking that the package also built on PPC/PPC64 architectures. [[PaulFrields|Paul Frields]] and [[BrianKearney|Brian Kearney]] liked[8] the idea of doing koji scratch-builds and Pierre-Yves and [[DebarshiRay|Debarshi Ray]] concurred[9] as long as it was possible to keep the builds from being removed until the review was completed. [[User:Ivazquez|Ignacio Vazquez-Abrams]] thought[10] that it ought to be easy enough to do some automatic annotations conditional on the success of the build.
 
[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01634.html
 
[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01649.html
 
[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01639.html
 
[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01641.html
 
[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01643.html
 
Approval of the general idea was expressed[11] by [[RichardJones|Richard W. M. Jones]] : "[...] every package guideline which (a) isn't already done by rpmlint, and (b) can feasibly be checked automatically, should be checked." He added that it would be useful to extend rpmbuild to be able to run test tools such as rpmlint or "review-o-matic" on its generated packages. [[VilleSkyttä|Ville Skyttä]] later confirmed[12] that Richard would need to get a patch in to rpm itself in order to get "[...] rpmbuild to run rpmlint automatically on the packages that rpmbuild makes [.]"
 
[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01649.html
 
[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01816.html
 
DebarshiRay linked[13] to a script named "fedora-qa" which seemed to overlap some of the functionality of rpmlint and added that [[RakeshPandit|Rakesh Pandit]] and [[DebarshiRay|Debarshi Ray]] were[14] working on using it to "[...] do spec file sanity checking [...]" He stated his own progress as "I have a very initial stage of code up and running which is taking bugzilla numbers manually (due to limited speed of network). Currently only doing koji builds and if successful then rpmlint on resultant rpms. It is also commenting back to the bugzilla entries."
 
[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01644.html
 
[14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01825.html
 
It turned[15] out that [[ChrisWeyl|Chris Weyl]] had also gone to work on a base implementation and he asked if there was room for collaboration.
 
[15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01718.html

Revision as of 00:36, 20 October 2008

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

OpenOffice and go-oo

The controversy swirling around the OpenOffice.org "fork" named "go-oo" popped up[1] along with a request for information about why "[...] Fedora ships a relatively stock (stock + 98 patches) OO.o rather than shipping [...] the extended feature set provided by go-oo such as the opengl slide transitions [?]" Caolán McNamara, the maintainer, explained[2] that he attempted to stick close to upstream "[w]ith a fairly aggressive push of any fedora patches back upstream asap [...]" and based upon the low number of reported bugs he believed "[...] this route provides the stablest and best supported product for fedora users." Caolán added that the OpenGL slide transitions were "still in a bit of a confused state" but would probably appear in Fedora 11. While Caolán eschewed any animosity to the parent ooo-build[3], and emphasized that Fedora had contributed fontconfig glyph replacement functionality to ooo-build and extended their GStreamer patches, he suggested that using ooo-build as an upstream would result in a confusing morass of patches upon patches.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01134.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01140.html

[3] A collection of patches presented through a subversion repository which was intended to work around organizational and practical bottlenecks in OpenOffice.org development. http://wiki.services.openoffice.org/wiki/Ooo-build

Muayyad AlSadi argued[4] that go-oo should be used because "[...] one can drop java and ship openoffice on a livecd [like Novell, Gentoo, Ubuntu.]" In the exchange that followed Muayyad revealed[5][6] that he had produced a Fedora-derived LiveCD with Openoffice.org on it by the expedients of moving some large Java jar and .class files out of the core rpm package and restricting the language choice to Arabic only. Muayyad suggested that adding the resulting missing pieces could be done by adding them to comps.xml . Caolán argued[7] that providing a non-working OpenOffice.org (the search functionality depends on Lucene[8] and the XSLT wizard depends on SAXON[9] both of which are written in Java) was an unacceptable user experience. It also appeared that the other distributions mentioned by Muayyad had restricted themselves to a small subset of languages which would result in a non-usable OpenOffice.org for many Fedora users.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01163.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01181.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01291.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01287.html

[8] A text search-engine library: http://lucene.apache.org/java/docs/

[9] An XML stylesheet processor: http://saxon.sourceforge.net/

Caolán suggested[10] that using go-oo as a base would not solve the Java dependency and referred[11] to his own work to reduce Java dependencies as a way in which this goal might be achieved: "Taking `removing java from core dependencies' as the target, then the right approach is the boring slow-fix stuff to e.g. rewrite the help search to not require the java lucene stuff and to tweak the xsltfilter stuff to be a standalone expert-style feature that only appears in the menus when the xsltfilter package is installed and place the saxon requires on that subpackage, and so on for other java functionality." Caolán had previously split out the beanshell scripting engine to a separate package and he recommended that Muayyad: "[...] investigate further as to why exactly removing or replacing java dependencies is the target, when I last thought seriously about the area I felt the right thing to do was stop swimming against the tide and boil out some concrete standalone feature requires for gcj to be able to provide the functionality that was missing at that stage to implement the java-needs of OOo, and our fabulous java hackers simply implemented them. Your questions should be what exactly are the size figures are for requiring the java dependencies and where is that space getting used and why."

[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01362.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01460.html

PackageGurus, SpecMentats or UeberPackagers?

On 2008-08-13 it was announced[1] on @fedora-announce that CVS access had been revamped to allow trusted users to modify packages "distro-wide", not merely packages which they own or co-maintain. In order to clarify the changes some new terminology was introduced. Ordinary maintainers (previously members of the "cvsextras" group) are now members of the "packagers" group and those who are trusted to assist with all packages are members of the group named "uberpackager". This change has been coming for some time (see FWN#136[2] for previous discussions) and seems as though it will help cut out some bureaucracy.

[1] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00007.html

[2] http://fedoraproject.org/wiki/FWN/Issue136#New.libraw1394.Rebuild.Exposes.Closed.ACLs

Lennart Poettering objected[3] to the term "uberpackager" as too redolent of "Nazi terminology" and asked "[...] if we have "Überpackagers", maybe it's time to rename normal packagers to "Unterpackagers"? That would fit awfully well into our pursuit for world domination, wouldn't it?"

[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01657.html

Casey Dahlin took the point but wondered[4] why Lennart had waited until now to object which led[5] Lennart to clarify that he did not follow all Fedora mailing-list discussions and "[...] noticed the adoption of this term for the first time a week or two ago when I had to log into FAS and noticed I had become an Überpackager. And, oh, god, with my blonde hair and blue eyes it felt so deserved... "

[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01658.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01661.html


Many respondents were sympathetic to the objection. Paul Frields explained[6] that "[u]se of "über-" has indeed made the jump to slang English. I think there's an increasing tendency in new media communities to attempt to subvert or undermine existing connotations of terms, for better or worse. In cases like this, I think we unconsciously or semi-consciously think we're deflating any unpleasantness by using them casually.I'm certain no offense was intended, but your comment is worth serious consideration." The problem of over-sensitivity was raised by several contributors including Andrew Parker who asked[7] "Do we have to have all our words vetted against every language before we can use them?" and provided some examples of common failures to do this. Axel Thimm added[8] further arguments against Lennart's interpretations.

[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01659.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01785.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01815.html

Some extensive bike-shedding[9] followed with suggestions for alternate terminology ranging from Jon Ciesla's "spec-mentat"[10] to Seth Vidal's[11] "WednesdayPackager". Seth exclaimed[12] "[...] our ability to make subtle references that even we eventually don't understand kicks ass. :)"

[9] http://en.wikipedia.org/wiki/Color.of.the.bikeshed

[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01662.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01800.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01863.html

At one stage it appeared[13] that Toshio Kuratomi would change the name to "ultrapackagers" and Lennart excused[14] himself from further discussion: "Toshio already agreed to changing this term and it is not too much work. So let's just do it and forget about it and not continue this discussion here. I am here for the code, not for discussing Nazism." Axel Thimm[15] and Till Maas disagreed[16] that the prefix "über-" necessarily carried the connotations associated with it by Lennart and several others on the thread. Toshio noted[17] that he would need to make any change either tomorrow or else put it off until after the freeze. In passing he expressed a preference for the term "masterpackager" leading Jesse Keating to joke[18] that he preferred his bike sheds colored chartreuse.

[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01675.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01826.html

[15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01836.html

[16] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01897.html

[17] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01902.html

[18] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01904.html

A Single Torrent ?

The ability of many torrent clients to offer the user a choice of specific files within a torrent prompted JesseKeating to ask[1] "[...] does it make sense to collapse the DVD and CD torrents into a single torrent and allow people to use the client to pick which they want? Are there pros/cons to this?"

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01735.html

Jon Ciesla wondered if the perceived "lowest common denominator client" bittorrent-curses offered this ability. bittorrent-curses was dismissed[2] as being dead and closed by Jesse Keating which led[3] to a slightly hyperbolic demand by Behdad Esfahbod for an equivalent to facilitate "mindless" downloading. In a later exchange with John Reiser it was clarified[4] that the "old dead" bittorrent4.4.0-7 only downloaded all files in a torrent. Dennis Leroy and Conrad Meyer provided[5] reassurance that both rtorrent and transmission provided ncurses-based interfaces that offer marking specific files for download.

[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01745.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01753.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01752.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01808.html

Jesse explained[6] that one advantage of what he was suggesting was "[w]e can reduce the number of links offered to users on download pages, simplify the instructions, and have a better end user experience." His workflow avoided resorting to the command line.

[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01760.html

Richi Plana responded[7] that lumping all the isos into a single torrent was not a good idea as "[m]ost people really only download one iso [...]" and Jesse hastened[8] to clarify "I meant collapsing them per arch, so you'd have one torrent file for Fedora 10 x86.64, one for Fedora 10 i386, ppc, source etc.. and probably different torrent files for the i686 Live and x86.64 Live offerings. I wouldn't imagine one giant torrent file that has every iso of the release on it."

[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01751.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01761.html

Some definite preferences were expressed[9] by Chris Snook on how to Do The Right Thing By Default: "there needs to be a standalone torrent that has just the DVD ISO (and maybe the netinst ISO) for all those newcomers who don't know any better, so we don't scare them off with a 9 GB torrent." Chris raised the problems of prioritization and smaller sets of disjoint peers for more specific torrents, especially for the case[10] of one CD iso per torrent. The ability to prioritize specific files might allow work to be started sooner by, for instance, downloading a LiveCD first. Callum Lerwick suggested [11] using Azureus for this purpose.

[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01764.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01772.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01806.html

A separate problem posed[12] by Seth Vidal was the absence of good trackers and seeders: "[I]n terms of clients - there are a lot of choices. In terms of trackers and good server-like-seeders there are NOT a lot of choices. [T]he original bittorrent client pre-proprietary is the best we have right now." Callum Lerwick again noted[13] Azureus' abilities: "I'd suggest just biting the bullet, fire up a vncserver instance, and run Azureus. It is incredibly flexible at managing many torrents at once, it can run a tracker as well, and the GUI allows you a level of insight into the status of a torrent that you just won't get from a text client."

[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01759.html

[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01807.html

The Old Sendmail Argument

An old discussion (see FWN#145[1]) was given new legs when instructor Lutz Lange asked[2] why sendmail "[...] is still the default MTA in Fedora [?]" Patrice Dumas answered[3] with an excellent summary of the discussions preceding Fedora 10: "To sum up some people considered that local delivery was a must for the default MTA, and that a send-only MTA wasn't good enough, e.g., for cronie. My personnal opinion is that there should not be any MTA in the @base or @code group, and that a MTA should be chosed if it is pulled in as a dependency, so it could be sendmail or anything else. Whether local delivery is a must for cronie or other packages that today require /usr/sbin/sendmail is another story that caould be discussed a bit more, though in the end it seems to me that this should be up to the maintainer."

[1] http://fedoraproject.org/wiki/FWN/Issue145#Default.Deactivation.of.Services

[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01693.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01694.html

Les Mikesell rose[4] to the defense of sendmail as a highly-audited and extensible standard with which most administrators are familiar. All these points were disputed by various and sundry and Dominik Mierzejewski added[5] the interesting information that postfix has partial milter support thus allowing it to be extended easily. David Woodhouse took issue[6] with the idea that milter support was important: "Some of the better alternatives don't even _try_ to run milters, because they are fully-featured enough in their own right, without needing to rely on external software" and appeared[7] to put to rest the idea that it was difficult for these alternatives to run tests on messages prior to accepting them in an SMTP conversation. Les finished[8] off with an argument invoking the inertia of a wide base of currently working sendmail systems: "[Postfix is] worse at backwards compatibility. Fedora seems to assume that their users don't already have something working, so maybe that's not a concern to anyone here. If it shipped with a decked-out, well tested setup already integrated with MimeDefang/clamd/spamassassin it might be enough of an improvement to switch."

[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01697.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01730.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01895.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01917.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01750.html

Some abstruse jokes were cracked[9] when Denis Leroy observed[10] that "[t]he sendmail configuration file is arguably one of the most complex and obfuscated configuration format ever designed in the history of computer science. :-)" and Alan Cox suggested[11] comparing it to IBM's JCL or TECO. But Les Mikesell believed[12] that "[...] these days all of the m4 templates anyone might ever need have already been written, so everyone just uncomments or tweaks a few lines in sendmail.mc for options and the default already does the right thing for most people. Or, for complex scenarios you can drop in MimeDefang as a milter and do most of the control steps with perl snippets."

[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01708.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01702.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01707.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01710.html

The decision to ship the Desktop spin[13] with no MTA was mentioned[14] by Colin Walters with the observation that mail from logwatch would be sent to /dev/null as "[...] most logs from a desktop machine are just pure noise." In response to Matthew Woehlke's desire for a means to view some log information Rahul Sundaram suggested15 working on gnome-system-log.

ArjanvandeVen threw[16] some cold water over the discussion with the observation that "[a]nybody trying to argue for the politics of Exim/Postfix/Sendmail as default choice is ignoring the reality..." as users simply requiring send-only MTAs can use sSMTP (or something similar) while those requiring a full-blown MTA have strong individual preferences. Karel Zak and Colin Walters returned[17] to the vision of Fedora as a "desktop distribution" with Colin arguing "I understand there's the "workstation" use case where you're say doing web development and you want to install Apache or Tomcat or something locally and run logwatch on it. We obviously will support that. But it doesn't make sense for the default desktop OS to be sending you email about all the junk going on under the hood."

[13] https://fedoraproject.org/wiki/SIGs/Desktop

[14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01787.html

[15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01791.html

[16] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01915.html

[17] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01920.html

Review-o-matic

Kushal Das announced[1] that he was starting work on a project to help automate the repetitive parts of the review process, as originally suggested[2] by Chris Weyl on @fedora-packaging. This seems timely in light of recent discussions which indicated (see FWN#111[3] and FWN#147[4)] that as the number of Fedora packages grows (PackageDB indicates[5] that Fedora has grown to offer approximately 6,842 packages) the review queue has on occasion become congested.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01625.html

[2] https://www.redhat.com/archives/fedora-packaging/2008-October/msg00023.html

[3] http://fedoraproject.org/wiki/FWN/Issue111#Review.Queue.Cont.

[4] http://fedoraproject.org/wiki/FWN/Issue147#LXDE.Feature.Removal.Disappointment.- .How.to.Avoid

[5] https://admin.fedoraproject.org/pkgdb/collections/

Kushal listed the basic tasks as: rpmlint; build in mock; md5sum matches between srpm and upstream. The tool would, upon submission of a new review request, download the SRPM and SPEC, run the aforementioned tasks and then post the results on bugzilla.

"Pierre-Yves" was among those that requested[6] the ability to make the build directly on koji. Richard W. M. Jones explained[7] that this would allow checking that the package also built on PPC/PPC64 architectures. Paul Frields and Brian Kearney liked[8] the idea of doing koji scratch-builds and Pierre-Yves and Debarshi Ray concurred[9] as long as it was possible to keep the builds from being removed until the review was completed. Ignacio Vazquez-Abrams thought[10] that it ought to be easy enough to do some automatic annotations conditional on the success of the build.

[6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01634.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01649.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01639.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01641.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01643.html

Approval of the general idea was expressed[11] by Richard W. M. Jones : "[...] every package guideline which (a) isn't already done by rpmlint, and (b) can feasibly be checked automatically, should be checked." He added that it would be useful to extend rpmbuild to be able to run test tools such as rpmlint or "review-o-matic" on its generated packages. Ville Skyttä later confirmed[12] that Richard would need to get a patch in to rpm itself in order to get "[...] rpmbuild to run rpmlint automatically on the packages that rpmbuild makes [.]"

[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01649.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01816.html

DebarshiRay linked[13] to a script named "fedora-qa" which seemed to overlap some of the functionality of rpmlint and added that Rakesh Pandit and Debarshi Ray were[14] working on using it to "[...] do spec file sanity checking [...]" He stated his own progress as "I have a very initial stage of code up and running which is taking bugzilla numbers manually (due to limited speed of network). Currently only doing koji builds and if successful then rpmlint on resultant rpms. It is also commenting back to the bugzilla entries."

[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01644.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01825.html

It turned[15] out that Chris Weyl had also gone to work on a base implementation and he asked if there was room for collaboration.

[15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01718.html

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=55641"