|
|
| (139 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| {{Anchor|Developments}} | | {{Anchor|Developments}} |
| == Planet Fedora == | | == Developments == |
|
| |
|
| In this section the people, personalities and debates on the @fedora-devel mailing list are summarized. | | In this section the people, personalities and debates on the @fedora-devel |
| | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[:User:OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === Kerneloops for SELinux === | | === Would You Like to Write This Beat ? === |
|
| |
|
| The last furore[1] over SELinux contained a positive contribution from StewartAdam, who proposed[2] to improve the interaction between users and SELinux by means of a "kerneloops-like plugin [which] would allow for statistics on where denials occur most and that way the policy could be modified accordingly." DanWalsh commented[[3]] that JohnDennis had written the ''setroubleshoot'' tool[4] to include the ability to send messages to an upstream collector. Dan was worried that he would be chosen as "the upstream infrastructure to handle all the messages" but optimistic that "the XML data [could be] run through some tools to see if the AVC was fixed by a newer version of policy". RobinNorwood thought[5] this would be easily solved using TurboGears[6] and Stewart concurred[7].
| | 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] http://fedoraproject.org/wiki/FWN/Issue133#SELinux.Eats.Babies.2C.Confines.Wives.2C.Gives.Birth
| | <references/> |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01081.html
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01085.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. |
|
| |
|
| [4] The ''setroubleshootd'' daemon listens for AVC denials and passes them through a series of plugins to analyze the audits and report what has been prevented. Suggestions are made on how to fix denials. On the client side ''sealert'' provides either a GUI or plain CLI interface which can connect to either the local machine or to a remote ''setroubleshootd''. The daemon can be configured to send email alerts. Making changes to system policy can be done in a variety of ways. The aforementioned sealert often suggests a simple CLI sequence to run. The older CLI ''audit2allow'' and ''audit2why'' tools respectively generate fixes based on the audit logs and explain them. ''semanage'' allows changes to be made on the fly to SELinux policies and ''system-config-selinux'' also allows boolean selection among pre-written policy options and the easy changes of ports or filecontexts.
| | 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?" |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01087.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. |
|
| |
|
| [6] A web framework written in Python which is widely used in Fedora Project infrastructure.
| | <references/> |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01093.html
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| A substantial chunk of the rest of the discussion hovered around the topic of whether some button(s) should be added to make it easier for the user to ignore the problem. Similar ideas had been floated (see AlanCox's and JamesMorris's comments in FWN#133, ref 7&8 [8]) earlier and AhmedKamal made[9] a good summary of them. He suggested that an AVC denial would present two buttons: "AutoFix" would try to enact the recommended fix stored in the database; and an "Exempt" button which would allow the offending application to run unrestricted. The latter especially was intended to prevent users from just switching off SELinux entirely. ArthurPemberton and StewartAdam thought[10] that this was exactly the wrong approach, with Arthur being reminded of MS Vista users automatically clicking "allow" and Stewart commenting "The idea of this is to get users to report what's going wrong and get it fixed in the policy instead of exempt/disable which defeats the purpose and trains the user to hit "Exempt" without reading anything." Ahmed took the point and made the modification that the "Exempt" button would only work once-per-launch. He argued this would allow the user to get work done but still preserve the incentive to get the problem fixed. DaveAirlie appeared[11] somewhat upset at the idea, arguing that this was "NO NO NO ... DOING IT WRONG."! Taking a cue from the implicit messages of the iMac vs. Windows television advertisements and the successful model of kerneloops he insisted that users should "[never be involved] in the mess other than asking for opt-in [...] The user is not going to have a freaking clue wtf exempting means." Instead he suggested that pinging a remote server to ask for an updated policy would be superior.
| | [[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?" |
|
| |
|
| [8] http://fedoraproject.org/wiki/FWN/Issue133#SELinux.Eats.Babies.2C.Confines.Wives.2C.Gives.Birth | | [[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. |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01089.html
| | <references/> |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01092.html
| | === Who Wants a Pony? === |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01101.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. |
|
| |
|
| Replying specifically to the idea of an "Exempt" DanWalsh noted[12] that there were such policies (called "permissive domains") now available in Rawhide. He went on to restate the problem that "Teaching people to press a button to tell SELinux to disable protection [because of AVCs that don't really block anything will get them to disable it when a real attack comes along." Instead the SELinux developers are concentrating on eliminating many of the false AVCs and one of the recent changes towards this end is the addition of a new access permission "open". JamesMorris added[13] that he had written about this work, as implemented by EricParis, in his livejournal: "Until now, opening a file under SELinux invoked the same permission checks as the intended operation on the file, such as read, write, execute and append. There was no separate "open" check: opening a file for write, for example, was considered by SELinux policy as equivalent to actually writing to the file. Experience has shown that this approach is not ideal for handling cases such as IO redirection via the shell, because policy writers cannot usefully guess where users will send redirected output."
| | <references/> |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01091.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01170.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>. |
|
| |
|
| DanWalsh, in response to questions from ArthurPemberton,listed[14] the private information contained in an AVC denial as "Hostname, filename, potentially username, rpm information. What apps they are running."
| | 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." |
| | |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01132.html | |
| | |
| Dan was also concerned that any new upstream reporting only occurred when ''setroubleshoot'' had been unable to find a suggested fix in its database. He reported that many bugzilla entries filed against him appeared to indicate that users did not even attempt the actions indicated as potential fixes by ''setroubleshoot''. ArjanvandeVen suggested[15] that ''setroubleshoot'' should just make those changes. DavidTimms wondered whether suggesting such "let this happen anyway" actions to users should be considered risky and not dissimilar to Ahmed's "Exempt" and "FixMe" buttons. He also listed several means by which he considered SELinux could be improved. DanWalsh replied[16] that many of these desired capabilities were already present in SELinux but appeared to ignore the behavioral similarities argued by David.
| |
| | |
| In response to further questions from ArthurPemberton it seemed[17] that the preferred mode for such a tool would be to suggest installation of any available updated policies either via PackageKit offering to install them or a "yum update".
| |
| | |
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01193.html
| |
| | |
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01138.html
| |
| | |
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01151.html
| |
| | |
| === Process Wakeups and Energy Efficiency ===
| |
| | |
| UlrichDrepper posted[1] a systemtap script which revealed a list of applications which cause wakeups due to timeouts. He noted that "Programs should be woken based on events. They shouldn't poll data (which is what usually happens after a timeout)" and requested that package maintainers for the programs in the list try to help solve the issue. The Flash ''npviewer'' was clearly the worst offender. The creator of the ''PowerTOP'' program, ArjanvandeVen wondered[2] why this work could not have been done using PowerTOP.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00921.html | |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00931.html
| |
| | |
| MatthewGarrett thought[3] that polling was inevitable for many applications but that the Glib timer function ''g_timeout_add_seconds''[4], which allows a function to be called at repeated intervals until it is automatically destroyed, could be used to do this at low frequency. It turned out[5] that this was exactly the approach which ArjanvandeVen had taken. HaraldHoyer thought that this was non-ideal as it did not sync globally and while Matthew agreed that kernel support would be needed DavidWoodhouse speculated[6] that tackling the problem per-thread instead of per-event might be possible.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00938.html
| |
| | |
| [4] http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#g-timeoutadd-seconds
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00962.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00968.html
| |
| | |
| NilsPhilippsen added[7] that it should be possible to use IMAP IDLE to fix mail clients and servers that polled too frequently.
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01032.html
| |
| | |
| RichardHughes quickly jumped[8] in to report a fix for his PackageKit problem but was less sanguine that GNOME Power Manager could be fixed quite so easily, although there was an expectation that Xorg would fix things by sending out a notification of changed DPMS state.
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00948.html
| |
| | |
| DanielBerrange provided[9] some evidence that the apparent problem with ''libvirtd'' was actually due to DBus sending unrequested signals every six seconds. When DanWilliams took a look[10] at NetworkManager's contributions and explained some problems were due to the ''ipw2200'' drivers waking up all WEXT listeners every four seconds and others were due to the presence of bogus rfkill switch events in HAL Daniel connected[11] the dots and said "Ahhh, so that's probably what's causing /usr/libexec/hal-ipw-killswitch-linux to be run every 6 seconds, which in turns causes any app connected to DBus system bus to be send a signal every 6 seconds and thus causes all the hits against libvirtd - and a fair number of other apps in that list too." DanWilliams responded that it was possible, but that it might be worth checking to see if D-Bus signal filtering was being done properly. The forthcoming 2.6.27 kernel was also said to contain the appropriate patches for rfkill which would help solve the problem.
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00973.html
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00976.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00978.html
| |
| | |
| Problems with ''PulseAudio'' were guessed by LennartPoettering to be due to the aforementioned Flash player ''npviewer'' opening audio streams and never closing them which in turn caused PulseAudio to keep the device open. Again there was a promise of future improvement as Lennart mentioned that the version of PulseAudio in rawhide should not generate any wakeups when completely idle.
| |
| | |
| It would seem that Ulrich's initiative may yield some useful improvements.
| |
| | |
| === Nodoka Notification Theme a Fedora 10 Feature ===
| |
| | |
| MartinSourada asked[1] for help determining whether his plan to provide a beautiful new notification theme for Fedora 10 counted as a "Feature" (see FWN#135 "New RPM Sparks Exploded Source Debate refs 10-20 for recent discussion of the Feature process.) The notification daemons are responsible for popping up small, dismissable windows informing the user that certain events have occurred[2][3].
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00842.html
| |
| | |
| [2] http://freedesktop.org/wiki/Specifications/systemtray-spec
| |
| | |
| [3] http://developer.gnome.org/doc/guides/platform-overview/platformoverview.html#notification-area
| |
| | |
| Martin stated that the public test release had been available for three months and no issues had been reported. He explained how to obtain the new theme from Koji and how to make it available to the system. After encouragement from RahulSundaram that such a visible change should be considered a feature Martin created a feature[4] page in the wiki. Further feedback from Rahul resulted[5] in the addition of screenshots and a Test Plan section.
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00901.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00908.html
| |
| | |
| WillWoods wrote[6] a concise and informative overview of what was expected from Test Plans.
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00912.html
| |
| | |
| === Mono Beta ===
| |
| | |
| PaulJohnson announced[1] that a new beta of ''mono'' was about to hit the servers and would probably break a number of things. Also of note was the change of license to MIT for Mono-2.0.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01123.html
| |
| | |
| DavidNielsen was excited and wondered if this would be pushed into Fedora 8 and Fedora 9 once any obvious breakage had been fixed. BillNottingham did not think 2 that "breaking the entire ABI and licensing of mono in released distros is a *good* thing. Especially Fedora 8." David expressed the advantages of pushing out one big update with a completely revamped stack to which WillWoods replied[3] that it made more sense to wait for Fedora 10's release in three months' time. David returned[4] to the idea that "having the same Mono throughout our releases is easier to maintain [and] pushing newer versions of the stack will enable us to support applications more widely across the stack." He suggested shipping a Fedora 9 preview release and drew a parallel to the situation with KDE-4.1 and their QT libraries. KevinKoffler disputed[5] the parallel as "Qt-4.4 and KDE-4.1 aren't breaking binary compatibility[.]"
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01156.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01158.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01160.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01163.html
| |
| | | |
| PaulJohnson explained[6] that until all the breakage had subsided only Rawhide would see the new beta "To me, rawhide is there for exactly this purpose - a testing ground to see how much is broken before pushing to stable." JeffSpaleta wondered[7] what the purpose of "updates-testing" was in that case.
| | 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/> |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01189.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01195.html
| |
| | |
| === Policy On Non-Responsive Maintainers ===
| |
| | |
| The issue of non-responsive maintainers was aired[1] when PatriceDumas suggested a new policy designed to force maintainers to answer "easy fix" bugs or orphan packages. While Patrice worried that it might look rude he emphasized that the intent was to spread co-maintainership and obtain quicker bugfixes. While most contributors acknowledged the intent behind this they saw myriad problems.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-July/thread.html#00796
| |
| | |
| EricSandeen quickly raised[2] the problem of defining an "easy bug". AndrewBartlett thought[3] that this was potentially just "a stick to hit a stressed developer with - and surely developers under external stresses, who do not maintain Fedora packages as their day, job will be the ones most likely to have this stick waved at them. Their re-action may not be the one they or you want in the short and long term."
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00745.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00845.html
| |
| | |
| The issue of whether or not a fix had to, or could be, determined as correct was also seen[4] as a problem by BillNottingham and JesseKeating.
| |
| | |
| A very detailed and thoughtful response from MichaelSchwendt to MatejCepl outlined[5] the problem of increasing the volume of bureaucracy and email dealt with by maintainers. It's worth reading to understand the stresses mentioned by other posters including AdamJackson and NigelJones who described[6] typical volumes of email which they faced. Adam added that anyone was welcome to help him fix bugs. Michael suggested instead that there be "a policy for package maintainers to respond to specially marked tickets from fellow fedora contributors in a timely manner. And if that results in tickets which are still not answered, timeout periods can be applied and give contributors the opportunity to prepare a test update (and only a test update!)." JesseKeating liked[7] the idea and added that SIG meetings could help to triage bugs.
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00894.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00937.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00856.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00939.html
| |
| | |
| HansdeGoede thought[8] that it would be better to address the problem of how to allow others to help make easy fixes. He argued that it ought to be possible to use ACLs to allow "easy fixes" to be committed by anyone with CVS extras permissions if a developer has allowed it. Patrice replied[9] that the cases which he was concerned about were not owned by maintainers who would allow such changes.
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00757.html
| |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00764.html
| | === Russian Fedora ? === |
|
| |
|
| Another voice against too much bureaucracy was that of RichardHughes who queried[10] "Surely the maintainer in question knows the package well enough to decide whether to merge patches? For instance, I might push a patch upstream and hold off applying it to fedora as it's trivial and will get updated at the next version bump of my package in a few weeks" to which KevinPage replied that there were examples where the timeframe was closer to numerous months. JeffSpaleta pushed[11] the idea of putting "packages under the purview of maintainer teams who are comfortable working with each other and care about the packages in question regardless of who the primary owner of a package is. SIGs are the obvious construct here[.]"
| | 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-July/msg01004.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]]. |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01008.html
| | <references/> |
|
| |
|
| Refinement of the policy was carried out between RahulSundaram and ToshioKuratomi. Toshio wanted[12] to make it possible for a co-maintainer to be added in egregious cases to help ease the burden on the original maintainer.
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00918.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]]. |
|
| |
|
| The emphasis on orphaning packages aggressively over a short time-period was questioned[13] by DanielBerrange. He suggested that adding co-maintainers would be a better strategy. RichardJones added[14] the disturbing spectre of "Wikipedia-style deletionism" occurring.
| | [[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-July/msg00946.html
| | <references/> |
|
| |
|
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00982.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| Some balance was added by a post made[15] by KevinPage which conveyed the perspective of frustrated bugzilla posters who find their easy fixes ignored. Kevin explained his experience with trying to get his patches applied and wondered whether it was a consequence of the new emphasis on pushing bugfixes upstream. He finished with "One conclusion from this thread is that it's accepted that some maintainers don't follow bugzilla. Not condoned, but accepted as a reality. That's clearly incompatible with asking users to report their problems in bugzilla."
| | 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-July/msg01005.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."
