|
|
| (77 intermediate revisions by the same user not shown) |
| Line 5: |
Line 5: |
| mailing list are summarized. | | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === More and Wider Testing === | | === Would You Like to Write This Beat ? === |
|
| |
|
| In a thoughtful post [[CallumLerwick|Callum Lerwick]] suggested[1] that <code>Fedora</code> testing coverage could be improved in several inter-related areas. These included making <code>Bugzilla</code> easier to use; adding per-package rollbacks to enable reversion to known good states; blocking <code>yum</code> updates on specific reported bugs; providing a rescue image in <code>/boot</code> with the aforementioned functionality; and lastly, enabling simple installation of specific updates which might fix said reported bugs. Callum asked for respondents to eschew what he called the "Hard problem fallacy" which consisted of minor technical objections and asked them to provide answers modeled on the pattern of "You are an idiot and your ideas are stupid. We're not doing this."
| | 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. |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01370.html
| | <references/> |
|
| |
|
| On the subject of rollbacks [[JefSpaleta|Jef Spaleta]] objected[2] that it was complicated by the triggered scripts in packages. Currently there are no tests for rollback and Jef wondered "...how do you set up a test which attempts to measure whether rollback across a trigger boundary put you back to where you were? How much of a different in state counts as 'break rollback' ?" He then added the problem of <code>Obsoletes:</code> "When an obsolete is introduced in an update... can we rollback and get what we had?" He finished off with the suggestion that ''Carrier Grade Linux'' might have some experience to offer as they had attempted rollbacks. [[SethVidal|Seth Vidal]] remembered[3] that "[...] the rollback functionality the CGL wanted was removed from rpm recently." [[GilboaDavra|Gilboa Davra]] asked[4] how it would be possible to pin-point what exactly had broken when there was a "150 package update push. Will you rollback all the updates? Only the updates that had _something_ to do with the breakage?" RalfCorsepius also nixed[5] the idea as "[...] package rollbacks will never work in general, because updates may contain non-reversable statefull operations (e.g. reformatting databases)."
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01394.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. |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01396.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?" |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01409.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. |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01442.html
| | <references/> |
|
| |
|
| A comprehensive reply was made[6] by [[GilboaDavra|Gilboa Davra]]. In it he argued that automating bug reports lowered the signal-to-noise ratio considerable and objected to modification of yum to refuse updates until reported bugs are fixed: "Say-what?!? Are we building a second Vista here?" Although he liked the idea of a rescue image in <code>/boot</code> he cautioned that space considerations impinged upon the need to keep "[...] a different rescue image for each installed kernel unless you plan to keep the original kernel[.]" As regards selective updates he stated: "You can always enable updates-testing and selectively install what you need."
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01409.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?" |
|
| |
|
| A preliminary step was added[7] by [[ChrisLumens|Chris Lumens]] to those listed by Callum: "I'd like to add a step (0) before we make bugs easier to file and really crank up the number of reports we're getting: (0) More people FIXING the bug, not just reporting them. You can have a giant user base of people filing tons of bugs, and you can have a motivated and effective QA/Triaging team whittling them down to the really important and reproducable bugs. But without more people fixing them, the backlog is just going to continue to build."
| | [[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. |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01421.html
| | <references/> |
|
| |
|
| When [[PeterLemenkov|Peter Lemenkov]] wondered[8] why users were forced to register on <code>Bugzilla</code> [[BillNottingham|Bill Nottingham]] underscored[9] the need for tools which do not swamp developers with large numbers of bugs. [[AlanCox|Alan Cox]] added[10] that the key was "[...] one clear and accurate bug report that happens to contain the right information and the user willing to help." [[DanielBerrange|Daniel P. Berrange]] further explained[11] that "[...] 90% [of bugs] are essentially useless when first reported. It requires several back/forth interactions between myself & the bug reporter to get enough information to diagnose & resolve the problem. If we create a system where we bombard maintainers with bugreports & no scope for user interaction they'll end up directly in /dev/null, and further discourage maintainers from addressing even bugs with enough info."
| | === Who Wants a Pony? === |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01408.html | | [[User:Kushal|Kushal Das]] promised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html</ref> a pony to anyone that would take the trouble to review<ref>http://bugzilla.redhat.com/show_bug.cgi?id=503021</ref> one of his packages. |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01399.html
| | <references/> |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01415.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01422.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>. |
|
| |
|
| The ''Ubuntu'' tool <code>apport</code> was discussed[12] as a possible solution several times as was[13] the ''Debian'' tool <code>reportbug</code>.
| | 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." |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01428.html
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01456.html
| |
| | |
| An emphasis was placed[14] on providing Bugzilla tools for developers and packagers by [[JamesAntill|James Antill]]: "I won't mind getting 666 dups, or dealing with 10x as many bugs in general, as long as I have a decent local tool that can manage that number of bugs. Atm lots of TABs of open bugs, and giant folders of BZ email are the best tools I've seen."
| |
| | |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01492.html
| |
| | |
| [[KarelZak|KarelZak]] jumped[15] straight to the original question and answered that testing participation was low "[...] because this work is not attractive. It's boring work without proper credit in open source community. It's very simple to found list of top-ten kernel developers, but who knows the most active bug reporters or QA around kernel? Nobody. People who are testing a software are real contributors. Our THANKS to them should be more visible!"
| |
| | |
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01696.html
| |
| | |
| === Source File Audit Catches RPM Problems Early ===
| |
| | |
| [[KevinFenzi|Kevin Fenzi]] posted[1] the results from the latest run of his sources/patches URL checker script. There were 912 possible problems reported, which Kevin noted was "Up from 662 last run. This is a pretty sad increase."
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01433.html
| |
| | |
| Happily many of the reported problems appeared[2] to be due to either temporary problems with ''GoogleCode'' and ''SourceForge'' project hosting or to some minor oddities in the script. Many of the other highlighted problems were confirmed as genuine and fixed by the package owners.
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01450.html
| |
| | |
| [[IanWeller|Ian Weller]] contrasted[3] a successful run of <code>spectool -g</code>[4], which uses <code>wget</code> internally, with the failure of Kevin's script. Later Kevin also found[5] a similar result when examining another failure. He speculated "[...] it's working fine with a wget... perhaps they are blocking the agent that spectool -g uses? (which I am not sure what it reports)." [[VilleSkyttä|Ville Skyttä]] offered[6] that "spectool -g uses plain wget, with configuration file /etc/fedora/wgetrc if it exists, otherwise usual system wget configs" and [[ThomasMoschny|Thomas Moschny]] discovered[7] that "spectool uses -N, which seems to cause 404 errors with googlecode[.]" [[JaroslavReznik|Jaroslav Reznik]] confirmed[8] this: "Same for me - it's not working for googlecode downloads. Wget with -N param sends HEAD instead GET - these two are same, but HEADs response are only headers - it's used for links validation etc... But looks is it misconfiguration on server side?" and thanked Kevin for the usefulness of his script which had caught a serious problem.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01434.html
| |
| | |
| [4] The spectool utility is part of <code>rpmdevtools</code>. It downloads and extracts sources and patches to build RPMs
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01451.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01454.html | |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01459.html | |
| | |
| [[EricSandeen|Eric Sandeen]] asked[9] if it would be a good idea to extend <code>rpmlint</code> to perform these checks: "I'm most likely to fix this stuff if I'm in the middle of making some other change, and an automatic check while I'm working on a package that says `hey your source URL is no longer valid' would probably provoke me to fix it quickly. :)"
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01466.html | |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01641.html | |
| | |
| === One Issue Tracker to Rule Them All ===
| |
| | |
| [[ArthurPemberton|Arthur Pemberton]] examined[1] the challenge issued by [[CallumLerwick|Callum Lerwick]] to improve <code>Bugzilla</code> (see this same FWN#153 "More and Wider Testing".) He asked for a list features which distinguished <code>Bugzilla</code> from competitors.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01430.html
| |
| | |
| The ability of <code>Bugzilla</code> to deal with a massive number of "products, components, users, hits per second [with] clustering databases and similar magic" was advanced[2] by [[MatejCepl|Matej Cepl]] as the most compelling reason. [[NicolasMailhot|Nicholas Mailhot]] added[3] "feature completeness, familiar UI, integrating with upstream issue trackers (which are often bugzilla too)" and [[EmmanuelSeyman|Emmanuel Seyman]] suggested[4]: "And as an encore : it has to contain 109900+ bugs of existing data so that we don't lose any history."
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01470.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01477.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01483.html
| |
| | |
| A certain amount of impatience with the general idea was expressed[5] by [[MatejCepl|Matej Cepl]] when he agreed with [[AndrewCagney|Andrew Cagney]] that one essential feature would be a "push upstream" button: "AMEN!!! And I think we should concentrate on this rather than doing stupid bugzilla rewrites. Sorry, for being harsh, but it is so IMNSHO." [[EmmanuelSeyman|Emmanuel Seyman]] warned[6] that it would be necessary to map users, bugs and components across any separate upstream/downstream instances of bugzilla. He later expanded[7] upon this: "Bugzilla has gained the abilty to customize statuses and resolutions, making it even harder to push bugs from one bugzilla to another with prompting for user interaction." <code>LaunchPad</code>[8] was discussed[9] as possibly providing this feature. [[CaseyDahlin|Casey Dahlin]] noted[10] that cross-site integration was still not implemented "[...] because there should never ever ever be two independent sets of launchpad data ever, according to their philosophy [.]"
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01611.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01615.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01622.html
| |
| | |
| [8] Canonical's collaborative hosting service https://launchpad.net/
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01616.html
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01539.html
| |
| | |
| [[TillMaas|Till Maas]] suggested[11] several interesting improvements including "[...] the possibility of having several people beeing responsible for a Component, which is currently only partly possible. There is the initial CC list, but when a bug is reassigned to a different component, the members of the initial CC list of the old component are not removed from the list." Other desiderata included storing the <code>NEVR</code> of a package in a dedicated field and support for the same bug across several different releases.
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01612.html
| |
| | |
| The issue of how bugs can actually be fixed cropped up again in the discussion. [[BrennanAshton|Brennan Ashton]] suggested[12] that triaging bugs was an area in need of volunteers and provided a link[13] to the [[BugZappers]] wiki page.
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01704.html
| |
| | |
| [13] https://fedoraproject.org/wiki/BugZappers
| |
| | |
| === RFC: Fix Summary Text for Lots of Packages ===
| |
| | |
| [[RichardHughes|Richard Hughes]] wished[1] that the Packaging Guidelines on summaries and descriptions would be followed a little more closely as "[q]uite a lot of packages have summary text that is overly verbose, and this makes the GUI and output from pkcon look rubbish."
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01484.html
| |
| | |
| [[JoshBoyer|Josh Boyer]] warned[2] against making reviewers' jobs harder by codifying too much in the package guidelines and suggested: "Just file bugs for packages you think are overly verbose. Offer alternate summaries in the bug, and a URL to your email for rationale." [[BillNottingham|Bill Nottingham]] was[3] dubious that "[...] this scales across 5000 packages. So it would be good to have at least *something* in the guidelines." When Richard compromised on a "soft guideline such as: Summary should aim to be less than 8 words" [[DavidWoodhouse|David Woodhouse]] gently poked[4] fun at this summary as being too wordy.
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01487.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01489.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01493.html
| |
| | |
| [[ToshioKuratomi|Toshio Kuratomi]] expressed[5] disapproval of soft guidelines due to their potential for sparking many individual disagreements instead of one single point of contention being handled by the Packaging Committee. Richard seemed happy enough with Toshio's suggestion[6] that the packaging guidelines contain a "best practice" description with examples.
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01495.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01499.html
| |
| | |
| When [[BillNottingham|Bill Nottingham]] raised[7] the possibility of "summary collisions" [[JefSpaleta|Jef Spaleta]] threw out[8] an analogy based on searching for medicine in a grocery store in a foreign country. This was intended to stimulate clarification of the function of summaries. [[ToshioKuratomi|Toshio Kuratomi]] loved[9] it and suggested that summaries were like the "[...] little advertising gimicks seen on and alongside the other things on the bottle. Things like: "New!", "Larger size", [Picture of grapes and smiling child], etc. They're differentiators that "help" you choose one product over another." He provided some concrete examples which seemed to prove his case.
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01520.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01536.html
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01569.html
| |
| | |
| [[MichalHlavinka|Michal Hlavinka]] worried[10] that <code>yum search <keyword></code> would be disrupted but [[MichaelSchwendt|Michael Schwendt]] re-assured[11] him that "'yum search' also searches the package %description. And the description is the place where to be much more verbose than in the summary. The %summary is not made for searching, but for enabling the installer and packaging tools to to display a brief and concise package description or a list thereof. That means, put a few relevant keywords in the summary (newspaper headline-style at most), but avoid long/complete sentences as often as possible. That also makes it easier to fit into one line."
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01500.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01510.html
| |
| | |
| Later Richard asked[12] for opinions on a sample email which he intended to send out to some maintainers to alert them to their long package summaries.
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01640.html
| |
| | |
| | |
| [[AndreaMusuruane|Andrea Musuruane]], as an ''RPM Fusion'' packager, felt[13] that packagers' time would be wasted in following the proposal and that a "Summary is something that the packager should choose on his own. It must be less than 80 characters and _maybe_ it should not contain the package name. Everything else is just marketing. If someone thinks that adding the fact that the application is based on Gnome, it is fine for me. If someone else thinks that mentioning that other application uses DBUS it is fine for me too." Richard clarified[14]: "I'm _not_ saying "change your summary or we'll drop your package" I'm asking them to come into line with 90% of the other packages in the distro. I'm even offering to do the cvs commit myself, if they give me the new summary line."
| |
| | | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01654.html
| | A further suggestion from "Cry" prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html</ref> Adam to start filing RFEs against <code>system-config-firewall</code> for any features present in <code>Firestarter</code> but missing in <code>system-config-firewall</code>. |
| | | <references/> |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01656.html
| |
| | |
| The issue of these changes being made solely to accommodate <code>PackageKit</code> was addressed[15] by [[JamesAntill|James Antill]]: "The fact that a single tool decided that summaries should be used instead of names, and so summaries should be roughly the same size of names shouldn't make Fedora packages break their summaries for other tools ... all IMO." When [[EmmanuelSeyman|Emmanuel Seyman]] asked[16] exactly how GUI packaging tools made the summary more prominent than the package name [[RichardHughes|Richard Hughes]] responded[17] that it was actually one, but one that was exposed in many places. Emmanuel's response was blunt: "FWIW, I don't appreciate our maintainers being lied to. The vast majority of them work hard to make their packages and I believe that a minimum of respect should be shown [...] it is a case of changing one application versus changing 500." [[VilleSkyttä|Ville Skyttä]] took[18] an overview which left the current user-interface of <code>gnome-PackageKit</code> aside and concentrated on whether there was agreement that <code>rpmlint</code> should be taught to check that the package name should not be repeated in the summary.
| |
| | |
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01683.html
| |
| | |
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01672.html
| |
| | |
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01713.html
| |
| | |
| [18] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01673.html
| |
| | |
| Further criticism was made[19] by [[ChristopherWickert|Christopher Wickert]] of sorting packages by description instead of name in PackageKit and [[TomLane|Tom Lane]] raised[20] the problem of sub-packages needing to reference the name of their parent package. At this stage it seemed that some consensus had been reached on the idea that summaries which repeated the program name were frowned upon and that "verb phrases" should be also be deprecated as suggested[21] by [[IgnacioVazquezAbrams|Ignacio Vazquez-Abrams]].
| |
| | |
| [19] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01721.html
| |
| | |
| [20] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01733.html
| |
| | |
| [21] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01532.html
| |
| | |
| A brief dispute between [[AndreaMusuruane|Andreas Musuruane]] and [[MichaelSchwendt|Michael Schwendt]] yielded a closing statement which seemed[22] to make the case of those that favor the changes in a strong manner. Michael accepted that: "[i]t isn't trivial to come up with good one-line summaries that do more than repeating the program name. It's nothing packagers like to spend time on. Reducing a packager's freedom even further won't be a good thing [...] I think with some people one could argue endlessly about pkg summaries. And during pkg reviews that's wasted time. Still, with very old repositories it has been noticed [and agreed on, mostly] that some types of summaries simply look poor in Anaconda and package management tools. That was the rationale for some of the recommendations." RichardHughes noted[23] that over the last forty-eight hours many maintainers had changed their package summaries as requested.
| |
| | |
| [22] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01753.html
| |
| | |
| [23] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01764.html
| |
| | |
| === Smock: Simpler Smock for Chain Building ===
| |
|
| |
|
| A couple of announcements were made by [[RichardJones|Richard Jones]]. The first was of a new version of <code>OCaml</code>. The second was[1] of a wrapper script that "[...] runs on top of mock, allowing you to chain-build a series of RPMs from a single command." An example which would "[...] arrange the SRPMs into the correct order according to their BuildRequires, then build each in the four separate mock environments Fedora {9,10} {i386,x86_64}" was provided:
| | === Russian Fedora ? === |
|
| |
|
| <pre>smock.pl --arch=i386 --arch=x86_64 \ | | 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. |
| --distro=fedora-9 --distro=fedora-10 \
| |
| *.src.rpm
| |
| </pre> | |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01229.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]]. |
|
| |
|
| [[TillMaas|Till Maas]] suggested[2] that local file access URIs[3], such as <code>file:///</code>, could be used to avoid the need for a webserver and [[PaulHowarth|Paul Howarth]] confirmed[4] that he had been using mock "[...] like this for *years* with loopback-mounted ISO images for a low-cost source for the base repo. It definitely works."
| | <references/> |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01232.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [3] See RFC1738 section 3.10 http://tools.ietf.org/html/rfc1738 | | A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]]. |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01264.html | | [[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>. |
|
| |
|
| [[SethVidal|Seth Vidal]] asked[5] why the wrapper approach had been taken instead of integrating the functionality into <code>mock</code> and Richard agreed[6] that this should happen. An initial problem with build requires of the form "%{name}-devel" failing was quickly fixed[7].
| | <references/> |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01238.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01239.html | | Following a report from [[UweKiewel|Uwe Kiewel]] that a <pre>yum upgrade</pre> had spewed all sorts of errors the supported methods for upgrades were re-stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html</ref> by [[User:Adamwill|Adam Williamson]]: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline." |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01354.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."
