|
|
| (86 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]] |
| | |
| === 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 [?]" [[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/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
| |
| | |
| [[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.
| |
| | |
| [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 <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."
| |
| | |
| [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
| |
| | |
| [[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?"
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01657.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... "
| |
| | |
| [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. [[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.
| |
| | |
| [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 [[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. :)"
| |
| | |
| [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 [[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.
| |
| | |
| [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|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
| |
| | |
| [[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.
| |
| | |
| [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
| |
| | |
| [[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."
| |
| | |
| [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 [[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.
| |
| | |
| [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 [[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."
| |
| | |
| [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 [[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."
| |
| | |
| [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
| |
| | |
| [[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."
| |
| | |
| [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 [[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."
| |
| | |
| [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 <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>.
| | === Would You Like to Write This Beat ? === |
|
| |
|
| 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."
| | 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. |
|
| |
|
| [13] https://fedoraproject.org/wiki/SIGs/Desktop
| | <references/> |
|
| |
|
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01787.html
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01791.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. |
|
| |
|
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01915.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?" |
|
| |
|
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01920.html | | Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html</ref> by [[User:Alsadi|Muayyad AlSadi]] who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. [[User:Notting|Bill Nottingham]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html</ref> skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html</ref> the reaction typified by [[User:Skvidal|Seth Vidal]] which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. [[User:bochcecha|Mathieu Bridon]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html</ref> that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy. |
|
| |
|
| === Review-o-matic ===
| | <references/> |
|
| |
|
| [[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.
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01625.html | | [[KristapsViesalgs|Kristaps Viesalgs]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html</ref> for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?" |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-packaging/2008-October/msg00023.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] http://fedoraproject.org/wiki/FWN/Issue111#Review.Queue.Cont.
| | <references/> |
|
| |
|
| [4] http://fedoraproject.org/wiki/FWN/Issue147#LXDE.Feature.Removal.Disappointment.- .How.to.Avoid
| | === Who Wants a Pony? === |
|
| |
|
| [5] https://admin.fedoraproject.org/pkgdb/collections/ | | [[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. |
|
| |
|
| 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.
| | <references/> |
|
| |
|
| "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.
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01634.html | | [[User:Maxamillion|Adam Miller]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html</ref> whether he should just retire the <code>Firestarter</code><ref>Firestarter is a firewall configuration GUI</ref> package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate <code>Firestarter</code> with <code>PolicyKit</code>. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok <code>PolicyKit</code>. |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01649.html | | Following confirmation from [[User:Sundaram|Rahul Sundaram]] and [[User:Skvidal|Seth Vidal]] a decision was made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html</ref> by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future." |
| | |
| | A further suggestion from "Cry" prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html</ref> Adam to start filing RFEs against <code>system-config-firewall</code> for any features present in <code>Firestarter</code> but missing in <code>system-config-firewall</code>. |
| | <references/> |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01639.html
| | === Russian Fedora ? === |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01641.html | | When [[User:Peter|Peter Lemenkov]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html</ref> about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. [[User:Kkofler|Kevin Kofler]] gave<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html</ref> an able summary why this would still present Red Hat with a problem. |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01643.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]]. |
|
| |
|
| 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 [.]"
| | <references/> |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01649.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01816.html | | A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]]. |
|
| |
|
| 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."
| | [[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>. |
|
| |
|
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01644.html
| | <references/> |
|
| |
|
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01825.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| 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.
| | 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." |
|
| |
|
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg01718.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."
