From Fedora Project Wiki

< FWN‎ | Beats

(second pass, make sure contrib names are marked up properly. Read over again.)
(fwn136 first pass)
Line 6: Line 6:
Contributing Writer: [[:User:OisinFeeley|Oisin Feeley]]
Contributing Writer: [[:User:OisinFeeley|Oisin Feeley]]


=== Kerneloops for SELinux ===
=== New libraw1394 Rebuild Exposes Closed ACLs ===


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].
A simple warning made[1] by [[JarodWilson]] of a soname bump of libraw1394 (which among other things allows easy switching between juju and the older drivers) revealed that Fedora's KDE maintainers are not using open ACLs for their packages.


[1] http://fedoraproject.org/wiki/FWN/Issue133#SELinux.Eats.Babies.2C.Confines.Wives.2C.Gives.Birth
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01159.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01081.html
Jarod provided a short list of affected packages including ''kdebase'' and ''kdebase3'' and wondered whether he should "do a fancy chainbuild[2], or just let rawhide be busted for a day?" Following advice received[3] offlist he decided that the procedure would be to first bump and tag each of the packages, and then from within the devel-branch of a dependent package issue a: <pre>[jwilson foo fedora-cvs/pkg11/devel]$ make chain-build CHAIN="libraw1394 pkg1 ... pkg10"</pre>


[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01085.html
[2] http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Chained.builds


[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.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01161.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01087.html
This eventually worked[4], but first Jarod had to contact maintainers that disallowed commit access using open ACLs and get them to do the bump and tag in order to use the above method.


[6] A web framework written in Python which is widely used in Fedora Project infrastructure.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01316.html


[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01093.html
Early on in the chain of events [[KevinKoffler]] noted[5] the necessity to do this for the KDE packages. "Drago01" wondered why there were closed ACLs to which [[RexDieter]] replied[6] that it was not necessary for non-core development platform bits and he would try to change the ACLs for them. [[KonradMeyer]] defended[7] the choice on the basis that "KDE is a major system component and the KDE team (which is something like 6-8 people) does a very good job of fixing things as soon as they need fixing." Further probing for an actual reason by [[RahulSundaram]] resulted in Konrad stating[8] that it was necessary to prevent people from making mistakes and that the <code>kernel</code> package was handled similarly. Rahul was unconvinced by this and [[JonStanley]] agreed[9] it should be possible, as with GNOME, to use open ACLs to allow anyone to help.


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.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01164.html


[8] http://fedoraproject.org/wiki/FWN/Issue133#SELinux.Eats.Babies.2C.Confines.Wives.2C.Gives.Birth
[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01192.html


[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01089.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01181.html


[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01092.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01223.html


[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01101.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01225.html


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."
=== XULRunner Security Update Breakage Stimulates Bodhi Discussion ===


[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01091.html
After [[MichaelSchwendt]] published[1] a summary of broken dependencies for Fedora 9 it was noticed[2] by [[MartinSourada]] that most of the problems were due to a recent update of <code>xulrunner</code> which now provides <code>geckolibs</code> (see FWN#110[3].) Martin discovered that <code>gxine</code>, which was his particular responsibility, did not depend on a specific version of <code>gecko-libs</code> and thus removed the versioned dependencies. He suggested that a review by carried out of the other affected packages to determine whether this was also the case for them.


[13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01170.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01175.html


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


[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01132.html
[3] http://fedoraproject.org/wiki/FWN/Issue110#Gecko-libs.Now.Provided.By.Xulrunnerdevel


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.
Martin was further concerned that the policies for pushing security updates for a stable release be examined in the light of this particular case because it would fail to install due to all the broken dependencies. He suggested that it ought to be possible to use chain builds (the Koji buildsystem allows packages to be grouped into sets during the build process and to only report success if all the packages complete perfectly) to ensure that such breakage does not occur. He also wondered why the security update was not mentioned on the "-devel(-announce) list?"


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".
[[NicolasMailhot]] agreed[4] strongly wondering: "why the hell is this stuff not tested in -devel first? [...] When the update process is not streamlined in -devel, it's no surprise it bombs in -stable when security updates are due." The answers to these questions came from [[AdelGadllah]] (drago01) who replied[5] that as it was a security fix it had to go to updates-stable immediately instead of following the normal procedure[6]. [[DavidNielsen]] interjected[7] that this method did not deliver a quick security fix because those using, for example, ''epiphany'' failed to get the update because the dependencies had not been properly handled. [[MichaelSchwendt]] also made[8] the same point: "Doesn't matter. It doesn't install at all if it breaks dependencies of *installed* packages. Not even *skip-broken helps in that case." Adel clarified[9] that he was explaining "why it was done, not that it was the right thing to do. As I already said, bodhi should block updates that break deps."


[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01193.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01182.html


[16] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01138.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01183.html


[17] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01151.html
[6] Generally bleeding-edge changes for the next version of Fedora are published in the "fedora-rawhide" repository, which is derived from a CVS branch named "-devel". The "fedora-updatestesting" repository contains bleeding edge changes for the current maintained release, the idea being that volunteers will test them and provide feedback before they are pushed to the "fedora-updates" repository for general consumption.


=== Process Wakeups and Energy Efficiency ===
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01184.html


[[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.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01185.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00921.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01188.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00931.html
=== Broken Upgrade Paths Due to NEVR ===


[[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.
A report listing packages which failed to upgrade smoothly was emailed[1] to the list on Mon 21st. This would appear[2] to be the output of [[JesseKeating]]'s revamped version of the old Extras script ''upgradecheck'' script (previously discussed in FWN#108 "Package EVR Problems"[3]) which examines Koji tags[[4]] to determine whether upgrades from one package version to another will work.


[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00938.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01253.html


[4] http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#g-timeoutadd-seconds
[2] http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgradepaths.py;hb=HEAD


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00962.html
[3] http://fedoraproject.org/wiki/FWN/Issue108#Package.EVR.Problems


[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00968.html
[4] http://fedoraproject.org/wiki/Koji


[[NilsPhilippsen]] added[7] that it should be possible to use IMAP IDLE to fix mail clients and servers that polled too frequently.
[[MichaelSchwendt]] noticed[5] that at least one reported failure, of ''audacity'' to upgrade from "dist-f8-updates-testing" to "dist-f9-updates" was a false positive because it omitted to take the possible intermediate tag "dist-f9-updates-testing" into account. [[JesseKeating]] pondered[6] the idea and while admitting the possibility that someone might "at one time [have] installed F8 testing updates, and then upgraded to F9 + updates, but without F9 updates-testing. However, it's more plausible that if they were using updates-testing on F8 that they would upgrade to F9 + updates + updates-testing." He suggested that he would break the testing down into two separate paths: "F8, F8-updates, f9-updates" and "F8-updates-testing, F9-updates-testing" and also list the person that built the broken instance instead of listing the owners of the broken packages.


[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01032.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01296.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.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01317.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00948.html
As the owner can change per branch [[MichaelSchwendt]] suggested that the ''pkgdb'' could be queried for branch-specific ownership data, but Jesse thought that it was more interesting to know who built the package rather than who owned it. He hoped that "the <pkg>-contact fedoraproject org or some such gets created soon so that the script can just email that + the person whom built the problematic package" and SethVidal quickly implemented[7] this after ToshioKuratomi made some changes to ''pkgdb''.


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


[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00973.html
=== Application Installer "Amber" ===


[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00976.html
A description was posted[1] by [[OwenTaylor]] of a visual means to rate, browse and install packaged applications in a repository. The discussion around this revealed some differences over the advisability of providing separate ways for ordinary end-users on the one hand and package maintainers on the other to discover and discuss the software available from the FedoraProject. Owen's post was to announce that he had hacked up a web-browser plugin (a detailed README is available[2] which includes discussion of security and cross-browser support) which used PackageKit to allow the installation of packages selected from this website. He had hopes that this would be "robust against inter-distro differences in package names" and wondered "[w]hat do people think... does this make sense as part of the PackageKit project?"
 
[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00978.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01433.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 ===
[2] http://git.o/shsoup.net/cgit/packagekit-plugin/tree/README


[[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].
Following a suggestion from [[TomCallaway]] that it be integrated with PackageDB (this is the central repository of meta-information on packages and is currently targeted to the needs of package maintainers and release-engineering[3] to track ownership and ACLs[4]) there were questions from JeffSpaleta about what that meant. Owen replied[5] with more detail, and explained that the web application would take information from PackageDB but that the plugin would use PackageKit (and YUM and hence ''comps.xml'') to display actual installable packages. He listed other possible operations beyond simple installation of packages. It would be possible to offer installation to any anonymous user, but after authentication rating and commenting on packages could be authorized for users in the FAS[6] class. Similarly, the ability to edit package information could be authorized for package owners.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00842.html
[3] https://admin.fedoraproject.org/pkgdb


[2] http://freedesktop.org/wiki/Specifications/systemtray-spec
[4] https://fedorahosted.org/packagedb/


[3] http://developer.gnome.org/doc/guides/platform-overview/platformoverview.html#notification-area
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01440.html


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.
[6] https://admin.fedoraproject.org/accounts/


[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00901.html
Jeff emphasized[7] that he would prefer to see Owen's interface replace, or augment, the existing PackageDB one[8] in order to increase user-maintainer communication by simplifying and reducing the number of interfaces. [[BillNottingham]] wondered[9] "Does anyone actually use packagedb to browse for available software?" and although there were a couple of affirmative replies there was no aggregate data presented to answer this question. [[NicolasMailhot]] replied[10] with some possible uses for expanded meta-information based upon the experience of the Fonts SIG.


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00908.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01442.html


[[WillWoods]] wrote[6] a concise and informative overview of what was expected from Test Plans.
[8] https://admin.fedoraproject.org/pkgdb


[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00912.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01445.html


=== Mono Beta ===
[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01474.html


[[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.
[[RobinNorwood]] explained[11] to Jeff that the PackageDB was for one audience "(mostly) targeted at people interested in the plumbing of Fedora" while the new interface was "targeted at people who are looking for applications to install and 'do stuff' with." He posted[12] a link to the Feature page for this ApplicationInstaller. Work seems to have progressed quite far with both the web-application side, which is tentatively named "Amber" and is available for proof-of-concept testing[13] and also with Owen's plugin.
 
[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.


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


[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01195.html
[12] http://fedoraproject.org/wiki/Features/ApplicationInstaller


=== Policy On Non-Responsive Maintainers ===
[13] http://publictest10.fedoraproject.org/amber


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.
Jeff re-iterated[14] his point that "driving users to a different site than the package maintainers... and allowing them to comment [is] going to cause a communication gap" and characterized this as "driveby commenting and rating." [MatthiasClasen] did not accept that the use cases and requirements were the same as those for PackageDB and argued that "[t]his is not an effort to improve package quality or gain new contributors. This is an effort to make life of users better. It is not about packages, but about applications." Robin was[15] against Jeff's idea of a "monolithic app" and emphasized that he was using existing infrastructure to provide a new interface and also planning easy export of the data. He envisioned this data as providing, for example, a feed of comments about each package to PackageDB: "More of a semantic web type idea than an isolated database or a 'one-stop shop'."


[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/thread.html#00796
[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01472.html


[[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."
[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01481.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00745.html
=== RPM Inspires Intel Moblin2 Shift From Ubuntu ===


[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00845.html
An excited [[PeterRobinson]] copied[1] a link to "The Register" to the list. The article claimed that Intel's next version of "Moblin"[2] (cunningly codenamed Moblin2) would be replacing the "Ubuntu-based kernel" with the Fedora kernel and cited Dirk Hohndel. Specifically it attributed a desire to "move to Fedora [as] a technical decision based on the desire to adopt RPM for package management [and also that] having a vibrant community push is the winning factor." The article has since been rebuffed[3] by Hohndel in a comment on one of his blogs as "not only low on detail, it's also high in content that's made up or blown out of proportion" but he does confirm that "we decided to move to an rpm based distribution as that gave us better build tools and most importantly a better way to manage the licenses under which the individual packages are released."


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


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.
[2] Moblin is a GNU/Linux-based software stack for Mobile Internet Devices which includes Xorg,GStreamer,ALSA,the MatchboxWM, GTK, Cairo, Pango, D-Bus, Avahi, Evolution Data Server and more. In order to make life easy for developers a Moblin Image Creator makes it easy to create a small 350-600MB binary image for a particular architecture. Moblin explicitly aims to provide an alternative to GNOME and KDE. http://www.moblin.org/resource.center.php


[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00894.html
[3] http://www.hohndel.org/communitymatters/moblin/moblin-at-oscon/


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00937.html
Commentary on @fedora-devel tended to cautious optimism mixed with a desire for a lot more information. [[JeffSpaleta]] asked[4] whether the idea was to have Moblin2 be a "part of the larger Fedora project or is it going to be a downstream derived distribution that will include components such that it can not carry the Fedora name?" and broached the idea that Moblin2 might be a candidate for a Secondary Architecture (see FWN#90[5] and FWN#92[6].) [[DavidWoodhouse]] (posting with an Intel.com sig) also liked[7] the idea of a Moblin2 SIG producing a Fedora spin for MIDs (Mobile Internet Devices.)


[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00856.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01386.html


[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00939.html
[5] http://fedoraproject.org/wiki/FWN/Issue90#Fedora.Secondary.Architectures.Proposal


[[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.
[6] http://fedoraproject.org/wiki/FWN/Issue92#Secondary.Arch.Proposal.Cont


[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00757.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01417.html


[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00764.html
While "yersinia" thought that the emphasis on RPM was interesting [[HansdeGoede]] was intrigued[8] by the emphasis on community activity. Hans suggested that [[JeffSpaleta]] contact DirkHohndel to emphasize the dynamic nature of the FOSS community behind Fedora. Jeff suggested that [[KarstenWade]] could meet with Dirk at this week's OSCON[9]. Ex-Red Hat star employee ArjanvandeVen volunteered[10] to do what he could to help make contact with Dirk, describing himself as "on the other side of a cube wall" from him. In response to [[RahulSundaram]]'s request for concrete information from Intel Arjan responded[11] that he would do his best to get the right people to make contact, but that much of the speculation on @fedora-devel concerned topics which have an "eh we don't know yet" answer. He also repeated cautions against believing anything which journalists write.


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[.]"
[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01397.html


[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01004.html
[9] http://en.oreilly.com/oscon2008/public/content/home


[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01008.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01447.html


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


[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00918.html
[[PaulFrields]] followed up[12] with details of a meeting at OSCON with senior Fedora hackers. It seemed that the ability to use OpenSuSE's Open Build System (which is based on RPM) was one of the main motivations behind Intel's move. Apparently ''Koji'' (the Fedora Project's buildsystem) lacks some specific functionality. Discussion between [[PaulFrields]] and [JeffSpaleta] centered[13] around whether the apparent Moblin2 plan of acting as a downstream derivative of the Fedora kernel would allow them to garner community contributions and whether this mattered anyway given Intel's vast resources.


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.
[12] http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00198.html


[13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00946.html
[13] http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00214.html


[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00982.html
[[ArthurPemberton]] thought that this was a good opportunity to take on some of the anti-RPM and anti-YUM misinformation which had been spread about. [[DavidNielsen]] thought it was best to merely demand proof from those spreading FUD. [[SethVidal]] conceded[14] that perhaps not enough had been done to publicize the improvements in YUM and RPM over the last few years and cited[15] a particular case-study of a ''smartpm'' user comparing it with ''YUM'' to the advantage of the latter.


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."
[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01503.html


[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01005.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01507.html

Revision as of 14:56, 27 July 2008

Planet Fedora

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

Contributing Writer: Oisin Feeley

New libraw1394 Rebuild Exposes Closed ACLs

A simple warning made[1] by JarodWilson of a soname bump of libraw1394 (which among other things allows easy switching between juju and the older drivers) revealed that Fedora's KDE maintainers are not using open ACLs for their packages.

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

Jarod provided a short list of affected packages including kdebase and kdebase3 and wondered whether he should "do a fancy chainbuild[2], or just let rawhide be busted for a day?" Following advice received[3] offlist he decided that the procedure would be to first bump and tag each of the packages, and then from within the devel-branch of a dependent package issue a: 

[jwilson foo fedora-cvs/pkg11/devel]$ make chain-build CHAIN="libraw1394 pkg1 ... pkg10"

[2] http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Chained.builds

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

This eventually worked[4], but first Jarod had to contact maintainers that disallowed commit access using open ACLs and get them to do the bump and tag in order to use the above method.

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

Early on in the chain of events KevinKoffler noted[5] the necessity to do this for the KDE packages. "Drago01" wondered why there were closed ACLs to which RexDieter replied[6] that it was not necessary for non-core development platform bits and he would try to change the ACLs for them. KonradMeyer defended[7] the choice on the basis that "KDE is a major system component and the KDE team (which is something like 6-8 people) does a very good job of fixing things as soon as they need fixing." Further probing for an actual reason by RahulSundaram resulted in Konrad stating[8] that it was necessary to prevent people from making mistakes and that the kernel package was handled similarly. Rahul was unconvinced by this and JonStanley agreed[9] it should be possible, as with GNOME, to use open ACLs to allow anyone to help.

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

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

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

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

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

XULRunner Security Update Breakage Stimulates Bodhi Discussion

After MichaelSchwendt published[1] a summary of broken dependencies for Fedora 9 it was noticed[2] by MartinSourada that most of the problems were due to a recent update of xulrunner which now provides geckolibs (see FWN#110[3].) Martin discovered that gxine, which was his particular responsibility, did not depend on a specific version of gecko-libs and thus removed the versioned dependencies. He suggested that a review by carried out of the other affected packages to determine whether this was also the case for them.

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

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

[3] http://fedoraproject.org/wiki/FWN/Issue110#Gecko-libs.Now.Provided.By.Xulrunnerdevel

Martin was further concerned that the policies for pushing security updates for a stable release be examined in the light of this particular case because it would fail to install due to all the broken dependencies. He suggested that it ought to be possible to use chain builds (the Koji buildsystem allows packages to be grouped into sets during the build process and to only report success if all the packages complete perfectly) to ensure that such breakage does not occur. He also wondered why the security update was not mentioned on the "-devel(-announce) list?"

NicolasMailhot agreed[4] strongly wondering: "why the hell is this stuff not tested in -devel first? [...] When the update process is not streamlined in -devel, it's no surprise it bombs in -stable when security updates are due." The answers to these questions came from AdelGadllah (drago01) who replied[5] that as it was a security fix it had to go to updates-stable immediately instead of following the normal procedure[6]. DavidNielsen interjected[7] that this method did not deliver a quick security fix because those using, for example, epiphany failed to get the update because the dependencies had not been properly handled. MichaelSchwendt also made[8] the same point: "Doesn't matter. It doesn't install at all if it breaks dependencies of *installed* packages. Not even *skip-broken helps in that case." Adel clarified[9] that he was explaining "why it was done, not that it was the right thing to do. As I already said, bodhi should block updates that break deps."

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

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

[6] Generally bleeding-edge changes for the next version of Fedora are published in the "fedora-rawhide" repository, which is derived from a CVS branch named "-devel". The "fedora-updatestesting" repository contains bleeding edge changes for the current maintained release, the idea being that volunteers will test them and provide feedback before they are pushed to the "fedora-updates" repository for general consumption.

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

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

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

Broken Upgrade Paths Due to NEVR

A report listing packages which failed to upgrade smoothly was emailed[1] to the list on Mon 21st. This would appear[2] to be the output of JesseKeating's revamped version of the old Extras script upgradecheck script (previously discussed in FWN#108 "Package EVR Problems"[3]) which examines Koji tags4 to determine whether upgrades from one package version to another will work.

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

[2] http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/check-upgradepaths.py;hb=HEAD

[3] http://fedoraproject.org/wiki/FWN/Issue108#Package.EVR.Problems

[4] http://fedoraproject.org/wiki/Koji

MichaelSchwendt noticed[5] that at least one reported failure, of audacity to upgrade from "dist-f8-updates-testing" to "dist-f9-updates" was a false positive because it omitted to take the possible intermediate tag "dist-f9-updates-testing" into account. JesseKeating pondered[6] the idea and while admitting the possibility that someone might "at one time [have] installed F8 testing updates, and then upgraded to F9 + updates, but without F9 updates-testing. However, it's more plausible that if they were using updates-testing on F8 that they would upgrade to F9 + updates + updates-testing." He suggested that he would break the testing down into two separate paths: "F8, F8-updates, f9-updates" and "F8-updates-testing, F9-updates-testing" and also list the person that built the broken instance instead of listing the owners of the broken packages.

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

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

As the owner can change per branch MichaelSchwendt suggested that the pkgdb could be queried for branch-specific ownership data, but Jesse thought that it was more interesting to know who built the package rather than who owned it. He hoped that "the <pkg>-contact fedoraproject org or some such gets created soon so that the script can just email that + the person whom built the problematic package" and SethVidal quickly implemented[7] this after ToshioKuratomi made some changes to pkgdb.

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

Application Installer "Amber"

A description was posted[1] by OwenTaylor of a visual means to rate, browse and install packaged applications in a repository. The discussion around this revealed some differences over the advisability of providing separate ways for ordinary end-users on the one hand and package maintainers on the other to discover and discuss the software available from the FedoraProject. Owen's post was to announce that he had hacked up a web-browser plugin (a detailed README is available[2] which includes discussion of security and cross-browser support) which used PackageKit to allow the installation of packages selected from this website. He had hopes that this would be "robust against inter-distro differences in package names" and wondered "[w]hat do people think... does this make sense as part of the PackageKit project?"

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

[2] http://git.o/shsoup.net/cgit/packagekit-plugin/tree/README

Following a suggestion from TomCallaway that it be integrated with PackageDB (this is the central repository of meta-information on packages and is currently targeted to the needs of package maintainers and release-engineering[3] to track ownership and ACLs[4]) there were questions from JeffSpaleta about what that meant. Owen replied[5] with more detail, and explained that the web application would take information from PackageDB but that the plugin would use PackageKit (and YUM and hence comps.xml) to display actual installable packages. He listed other possible operations beyond simple installation of packages. It would be possible to offer installation to any anonymous user, but after authentication rating and commenting on packages could be authorized for users in the FAS[6] class. Similarly, the ability to edit package information could be authorized for package owners.

[3] https://admin.fedoraproject.org/pkgdb

[4] https://fedorahosted.org/packagedb/

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

[6] https://admin.fedoraproject.org/accounts/

Jeff emphasized[7] that he would prefer to see Owen's interface replace, or augment, the existing PackageDB one[8] in order to increase user-maintainer communication by simplifying and reducing the number of interfaces. BillNottingham wondered[9] "Does anyone actually use packagedb to browse for available software?" and although there were a couple of affirmative replies there was no aggregate data presented to answer this question. NicolasMailhot replied[10] with some possible uses for expanded meta-information based upon the experience of the Fonts SIG.

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

[8] https://admin.fedoraproject.org/pkgdb

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

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

RobinNorwood explained[11] to Jeff that the PackageDB was for one audience "(mostly) targeted at people interested in the plumbing of Fedora" while the new interface was "targeted at people who are looking for applications to install and 'do stuff' with." He posted[12] a link to the Feature page for this ApplicationInstaller. Work seems to have progressed quite far with both the web-application side, which is tentatively named "Amber" and is available for proof-of-concept testing[13] and also with Owen's plugin.

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

[12] http://fedoraproject.org/wiki/Features/ApplicationInstaller

[13] http://publictest10.fedoraproject.org/amber

Jeff re-iterated[14] his point that "driving users to a different site than the package maintainers... and allowing them to comment [is] going to cause a communication gap" and characterized this as "driveby commenting and rating." [MatthiasClasen] did not accept that the use cases and requirements were the same as those for PackageDB and argued that "[t]his is not an effort to improve package quality or gain new contributors. This is an effort to make life of users better. It is not about packages, but about applications." Robin was[15] against Jeff's idea of a "monolithic app" and emphasized that he was using existing infrastructure to provide a new interface and also planning easy export of the data. He envisioned this data as providing, for example, a feed of comments about each package to PackageDB: "More of a semantic web type idea than an isolated database or a 'one-stop shop'."

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

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

RPM Inspires Intel Moblin2 Shift From Ubuntu

An excited PeterRobinson copied[1] a link to "The Register" to the list. The article claimed that Intel's next version of "Moblin"[2] (cunningly codenamed Moblin2) would be replacing the "Ubuntu-based kernel" with the Fedora kernel and cited Dirk Hohndel. Specifically it attributed a desire to "move to Fedora [as] a technical decision based on the desire to adopt RPM for package management [and also that] having a vibrant community push is the winning factor." The article has since been rebuffed[3] by Hohndel in a comment on one of his blogs as "not only low on detail, it's also high in content that's made up or blown out of proportion" but he does confirm that "we decided to move to an rpm based distribution as that gave us better build tools and most importantly a better way to manage the licenses under which the individual packages are released."

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

[2] Moblin is a GNU/Linux-based software stack for Mobile Internet Devices which includes Xorg,GStreamer,ALSA,the MatchboxWM, GTK, Cairo, Pango, D-Bus, Avahi, Evolution Data Server and more. In order to make life easy for developers a Moblin Image Creator makes it easy to create a small 350-600MB binary image for a particular architecture. Moblin explicitly aims to provide an alternative to GNOME and KDE. http://www.moblin.org/resource.center.php

[3] http://www.hohndel.org/communitymatters/moblin/moblin-at-oscon/

Commentary on @fedora-devel tended to cautious optimism mixed with a desire for a lot more information. JeffSpaleta asked[4] whether the idea was to have Moblin2 be a "part of the larger Fedora project or is it going to be a downstream derived distribution that will include components such that it can not carry the Fedora name?" and broached the idea that Moblin2 might be a candidate for a Secondary Architecture (see FWN#90[5] and FWN#92[6].) DavidWoodhouse (posting with an Intel.com sig) also liked[7] the idea of a Moblin2 SIG producing a Fedora spin for MIDs (Mobile Internet Devices.)

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

[5] http://fedoraproject.org/wiki/FWN/Issue90#Fedora.Secondary.Architectures.Proposal

[6] http://fedoraproject.org/wiki/FWN/Issue92#Secondary.Arch.Proposal.Cont

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

While "yersinia" thought that the emphasis on RPM was interesting HansdeGoede was intrigued[8] by the emphasis on community activity. Hans suggested that JeffSpaleta contact DirkHohndel to emphasize the dynamic nature of the FOSS community behind Fedora. Jeff suggested that KarstenWade could meet with Dirk at this week's OSCON[9]. Ex-Red Hat star employee ArjanvandeVen volunteered[10] to do what he could to help make contact with Dirk, describing himself as "on the other side of a cube wall" from him. In response to RahulSundaram's request for concrete information from Intel Arjan responded[11] that he would do his best to get the right people to make contact, but that much of the speculation on @fedora-devel concerned topics which have an "eh we don't know yet" answer. He also repeated cautions against believing anything which journalists write.

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

[9] http://en.oreilly.com/oscon2008/public/content/home

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

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

PaulFrields followed up[12] with details of a meeting at OSCON with senior Fedora hackers. It seemed that the ability to use OpenSuSE's Open Build System (which is based on RPM) was one of the main motivations behind Intel's move. Apparently Koji (the Fedora Project's buildsystem) lacks some specific functionality. Discussion between PaulFrields and [JeffSpaleta] centered[13] around whether the apparent Moblin2 plan of acting as a downstream derivative of the Fedora kernel would allow them to garner community contributions and whether this mattered anyway given Intel's vast resources.

[12] http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00198.html

[13] http://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00214.html

ArthurPemberton thought that this was a good opportunity to take on some of the anti-RPM and anti-YUM misinformation which had been spread about. DavidNielsen thought it was best to merely demand proof from those spreading FUD. SethVidal conceded[14] that perhaps not enough had been done to publicize the improvements in YUM and RPM over the last few years and cited[15] a particular case-study of a smartpm user comparing it with YUM to the advantage of the latter.

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

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

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