From Fedora Project Wiki

< FWN‎ | Beats

No edit summary
(fwn139 first pass)
Line 7: Line 7:
Contributing Writer: [[:User:OisinFeeley|Oisin Feeley]]
Contributing Writer: [[:User:OisinFeeley|Oisin Feeley]]


=== Solving the Unsynchronized Release of Package Dependencies ===
=== FlashPlayer 10 Symlink Provokes Proprietary Support Argument ===


A problem often experienced by users of "add-on" packages[1] is that dependency resolution will fail during a simple <code>yum update</code> when the official Fedora repositories release an update to the base packages on which these add-ons depend. ThorstenLeemhuis explained[2] that as add-on packages have a strict dependency on the base packages for which they were built and updates are not available at exactly the same time on all mirrors there is no ideal point in time for the add-on to be released. Thorsten's RFC was careful to point out that the problem did not only affect ''kmods'', but also plugins for ''audacious'', ''xine'' and ''k3b'' and that the resulting dependency resolution failures occurred both when the add-on was visible to ''yum'' before the base package and vice versa. The two possible solutions envisioned by Thorsten included either ''yum'' being modified "to be taught to do a second look at the right place to find what's needed" or the third-party repositories to include the updated base packages along with the updated add-on. Thorsten feared that this latter option of "shipping non-free kernel modules and the GPLed kernels in one repo might [make] some people yell license violation."
A formal request to remove the "miniature libcurl.so.3 library" was made[1] by [[JoshBoyer|Josh Boyer]]. This had been created in order to support the latest version[2] of Adobe's proprietary Flash Player which had a hard dependency on <code>libcurl.so.3</code> while Fedora 8, Fedora 9 and Fedora 10(alpha) provided only <code>libcurl.so.4</code>. Josh argued that the change, mentioned on [[WarrenTogami|Warren Togami's]] blog[3] had been made solely to accommodate a proprietary application.


[1] Such packages are hosted by "third-party" repositories, which are run independently of the Fedora Project. The packages, while highly useful for many Fedora users, are deemed to be legally non-distributable due to the laws of the U.S.A.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00476.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
[2] http://labs.adobe.com/technologies/Flashplayer10/


A report of daily failures of this type occurring for Rawhide without any complicating third-party repository was posted[3] by [[JohnEllson|John Ellson]]. He gave two examples from his current machine. The first was a missing dependency error:
[3] http://wtogami.livejournal.com/27778.html


<pre>$ yum update phonon*
After [[NikolayVladimirov|NikolayVladimirov]] argued[4] that it was a minimal, non-invasive change which might be useful for some "dead opensource projects that use the old version" Josh replied[5] this support goal would be better met by providing a "compat-curl" package instead of "just a hack with the sole intention of making Flash work again". In an aside he mentioned that he would have no objection to removing libflashsupport and a bunch of other stuff. [[MatthewGarrett|Matthew Garrett]] followed[6] the train of thought to one possible final destination: "If the ABI is consistent across the SONAME bump, then it's a hack that supports any pre-existing binaries that users have. The best way we could serve those users with a compat package would be to ship another copy of the latest version of curl (so they get the bugfixes) but with a changed SONAME - at which point we'd be shipping two identical source packages that produce binary packages that differ only in library name. In doing so, we'd be increasing the cost of security updates. What does that actually win us?"
Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by package phonon-backend-gstreamer-4.2.0-1.fc10.x86.64 (installed)
</pre>


and the second was a file conflict error:
[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00484.html


<pre>$ yum update digikam*
[5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00484.html
Transaction Check Error: file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of digikam-0.10.0-0.1.beta2.fc10.x86.64 conflicts with file from package oxygen-icon-theme-4.1.0-1.fc10.noarch
</pre>


[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00044.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00498.html


John wished that ''yum'' would skip updating all rpms which produce conflicts with currently installed rpms whether or not they are third-party or otherwise, especially as neither of these issues had been flagged in the appropriately dated "Rawhide report". A good deal of the remainder of thread was devoted to replying to this post instead of to Thorsten's RFC. The first response came[4] from MichaelSchwendt and made the point that the first error was probably due to an incorrect "Obsoletes" tag in the !code?phonon-backend-gst!/code? that is supposed to replace <code>phonon-backend-gstreamer</code>. The script which checks for broken dependencies in Rawhide cannot detect this as the <code>phonon-backend-gstreamer</code> is not visible to it. Michael addressed the second error with the point that conflicts are entirely different from dependency issues and are not checked. RexDieter, as package maintainer, quickly fixed both of the problems and in doing so demonstrated that users filing bug reports can be an effective part of the current process. Thorsten also emphasized[5] that the two errors posted by JohnEllson were entirely different from each other and that the conflict was a bug best dealt with by user reports. He further argued that it was impossible for the Rawhide dependency checker script to examine the contents of users' hard disks. All that the script can do is examine the current contents of Rawhide and as the <code>phonon-backend-gstreamer</code> was long gone it could not test a theoretical update from it. [[MichaelSchwendt|Michael Schwendt]] later added[6] that although his own "repoclosure" script developed for the old "Extras" repository had been able to take account of "obsolete binary [packages] from the previous compose [...] because in Extras we've had up to two pkg releases in the repo[sitory ...] the Rawhide report is like a fresh install of only the latest [package] releases, and one can only hope that there are enough testers who find and report the additional update/upgrade problems." Michael claimed[7] that as the FedoraProject policy on file conflicts was "half-hearted" he was uninterested in shouldering the burden of running the script himself. He also noted that [[FlorianLaRoche|Florian La Roche]] had a script for determining conflicts between files and symlinks.
[[BastienNocera|Bastien Nocera]] thought[7] that such a "compat-curl" package would duplicate unmaintained code and was pointless "since libcurl didn't break ABI, and only changed soname". Josh stood firm[8] and retorted that if the ABI was static then the applications could simply rebuild against the newer libcurl. [[WarrenTogami|Warren Togami]] characterized[9] Josh's viewpoint as "extremist" as it proposed "removing a zero maintenance 2496 byte file that would permanently break Flash 10 forever in Fedora" and that furthermore "[Adobe] are not violating any licenses like NVidia[.]" Following similar sentiments from "drago01" Josh deferred the discussion to a FESCo meeting held on Wed 13th August and this duly decided[10] to leave things as they were with two soname files in the curl package despite some strenuous objections which emphasized both the desirability of sub-packaging and also of not catering to the needs of proprietary applications.


[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00045.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00486.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00046.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00488.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00097.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00496.html


[7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00048.html
[10] http://bpepple.fedorapeople.org/fesco/FESCo-2008-08-13.html


During this discussion JohnEllson was unimpressed[8] with the theoretical reasons as to why he was seeing these problems and requested that even if it were not possible to do such checks on the server "[j]ust have yum on the client recover gracefully from these and skip over them."
=== Parallel Install of syslog-ng, rsyslog and sysklogd ===


[8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00047.html
[[DouglasWarner|Douglas Warner]] sought help[1] in packaging ''syslog-ng'' so that it could be installed with either of the other current system loggers: ''rsyslog'' and ''sysklogd''. He explained that all three installed their own "logrotate" files which targeted the exact same log files for rotation and thus doubly rotated the logs. So far Douglas' attempt to change his own ''syslog-ng'' package to fix this was stymied on RHEL boxes because updates of ''sysklogd'' (RHEL's preferred system logger) silently remove ''syslog-ng''. Later in the thread [[BennyAmorsen|Benny Amorsen]] provided[2] the insight that running ''syslog-ng'' for handling remote logs and ''rsyslog'' for its simple configuration simultaneously was useful.


Similarly [[DavidTimms|David Timms]] wondered[9] if the original problem stated in the RFC could be solved by using the yum option <code>--skip-broken</code> if it were made to select only those packages which were: available, non-conflicting, non-dependency-breaking and actually downloadable.Thorsten restated[10] his belief that this was effectively hiding the problem instead of fixing it and would result in users being unaware that important updates were blocked solely due to a manually installed problem RPM. Instead he suggested setting a window of time during which updates with broken dependencies would be ignored and then finally reported as errors. [[SethVidal|Seth Vidal]] corrected[11] the impression that "skip broken" was a plugin to ''yum'' (it is now a core option) and while agreeing that "a tool to detect all these issues is worth discussing, not sure how we catch all possible conflicts, though" seemed to confuse Thorsten's window of time with checking the actual package creation filestamp. JesseKeating also appeared[12] to fall prey to this confusion and like Seth pointed out the problem of queued packages sitting in repositories before being released. To clear this confusion up Thorsten posted[13] a more detailed explanation which emphasized that the times being examined were relative to the client-side's first encountering of the problem and made no reference to the build-date or publication date of the package itself. The advantage of Thorsten's seventy-two hour window scheme is that it gives packagers a grace period in which to correct the problem and at the end of that the same situation prevails as now, namely that the update will fail and users will notice and report the errors.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00531.html


[9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00049.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00632.html


[10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00099.html
The question of how to ship precisely the same logrotate script, from the viewpoint of RPM, was mentioned[3] by Douglas as one possible solution. If this could be done then RPM would be agnostic about where the file came from as long as it were possible to figure out whether the identity was based on "file size, md5, timestamp, ?". [[VilleSkyttä|Ville Skyttä]] suggested[4] using the <code>%verify</code> directive as detailed in a link to the "Maximum RPM" book.


[11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00150.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00558.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00153.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00577.html


[13] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00154.html
A restructuring of the problem by [[JasonTibbits|Jason Tibbits]] led him to recommend[5] that a separate logrotation-script package be split out of the current packages and that each of the current packages be made to depend on the new package. When Douglas nixed the suggestion due to his lack of control over the ''sysklogd'' script Jason seemed[6] to react a little testily and asked "Could we discuss technical solutions and ignore Red Hat politics? What I proposed is a standard method of dealing with these things." After [[JarodDiamond]] agreed with this [[DmitryButskoy|Dmitry Butskoy]] pointed[7] out that a different PID filename is used in each script and wondered was it possible to to create such a common logrotate package for all the syslog-like packages. A likely solution was proposed[8] by [[ChrisAdams|Chris Adams]] which used the expedient of symlinking each of the unique PID files from within the init script.


=== Firefox Mouse Woes ===
[5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00561.html


MarkG reported[1] that ''Firefox'' did not respond to the scroll wheel on GNU/Linux in the same way in which it did on Microsoft Windows. He had intended to file a bugzilla report, but due to the outage (see this same FWN#138 "Bugzilla Overhauled") was merely posting to @fedora-devel. The basic point made in what MarkG chose to frame as an RFC was that he expected the middle mouse button when clicked to allow him to scroll the page but that "[w]hen you press it on linux in firefox you get ... nothing[.]" He suggested that a simple change of the<code>firefox-fedora-default-prefs.js</code> to <code>pref("general.autoScroll", true);</code> by the Fedora maintainer would achieve this goal and noted that currently it is possible for a user to achieve the same end by navigating to the URI <code>about: config</code> and filtering <code>general.autoScroll</code> and changing its boolean to "true". MarkG also noted in support of his argument that "Ubuntu" had made such a change.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00563.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00053.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00584.html


A correction was made[2] by [[IgnacioVazquezAbrams--Ignacio Vazquez-Abrams]] to the effect that clicking the middle mouse button brought one to the "URL stored in the clipboard." He also pointed out that the environment in which the middle-click was made was important and that Firefox was doing the correct thing by following the Windows' environment preference of autoscrolling and the *nix environment preference of pasting from the clipboard. At this point the thread should probably have stopped but instead descended into a morass of personal preferences and insults. Nevertheless there were a couple of points worth noting.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00604.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00054.html
=== General Outage of Fedora Infrastructure ===


[[NaheemZaffar--Naheem Zaffar]] thought[3] that while pasting was well and good it was not so nice to have the pasted URL automatically replacing the current page. [[RuiMiguelSilvaSeabra|Rui Miguel Silva Seabra]] provided[4] a fix for this with
Many were caught by surprise when there was a widespread outage of Fedora Project infrastructure during the week. The earliest symptoms noticed included an inability to access Koji (see e.g. this FWN#139 "Koji from Behind a Firewall") or obtain updates with ''yum''. A general announcement by [[PaulFrields|Paul Frields]] followed[1] quickly on Thursday 14th and stated that an "issue in the infrastructure systems [was being investigated and might] result in service outages[.]" Somewhat ominously it concluded "[..] as a precaution, we recommend you not download or update any additional packages on your Fedora systems." This led some to speculate[2] that there might be a security problem.


<code>about:config -> browser.tabs.opentabfor.middleClick</code>.
Further announcements or explanations were not forthcoming for days, except for a post to @fedora-infrastructure which suggested[3] that the problem was causing a lot of hard work. [[PaulFrields|Paul Frields]] posted another update[4] on Sat 16th. This succinctly stated that the wiki and FAS should be back soon but that the application servers would take a bit longer.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00108.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00109.html
[1] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.html


A type of closure to the thread was obtained when [[ToddZullinger|Todd Zullinger]] posted[5] that a likely result of making such changes would merely be to "get the opposite RFC from anyone who is used to the *nix behavior and wonders why Firefox is scrolling instead of pasting the clipboard contents as we'd expect. :)" and he speculated that "Ubuntu" had diverged from upstream.
[2] http://lwn.net/Articles/294188/


[5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00058.html
[3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00109.html


=== Bugzilla Overhauled ===
[4] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00009.html


As commented in several threads this week (e.g. this FWN#138 "Firefox Mouse Woes") Bugzilla was down for maintenance. This was due to upgrades of the OS on the servers and a move from the venerable ''bugzilla-2.18'' to ''bugzilla-3.2''. The original announcement[1] was posted on several lists and detailed the planned outage and the changes to ''bugzilla'' which included user-interface enhancements, AJAX optimizations for searching and displaying bugs and an XMLRPC API.
=== Koji from Behind a Firewall ===


[1] http://www.mail-archive.com/fedora-announce-list@redhat.com/msg01372.html
A query was made[1] by [[VictorLazzarini|Victor Lazzarini]] about how to connect to ''Koji'' using the CLI from behind a firewall. He wondered specifically how to set up a proxy connection. He added that he was seeing an error when using a web browser but was[2] unable to provide it due to the general outage in Fedora infrastructure.


The announcement and the reminder[2] that this would all happen on 2nd August requested that those using the API pointed their scripts to the test server https://partner-bugzilla.redhat.com to ensure that the new system was indeed backwards compatible.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00660.html


[2] http://www.mail-archive.com/fedora-devel-announce@redhat.com/msg00194.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00664.html


A brief thread on @fedora-devel was started[3] when [[GilboaDavara|Gilboa Davara]] noticed that attempting to file a bug resulted in the JavaScript hanging and Firefox offering to retry or stop the script. This experience was confirmed by several other posters who noted that hitting "Continue" and waiting seemed to work. [[PaulFrields--Paul Frields]] speculated[4] that it was the population of the component list which was slow.
[[MikeBonnet|Mike Bonnet]] answered[3] that ''Koji'' did not have direct proxy support but that it used only ports 80 (http) and 443(https) as these are generally open. He explained that it would be "a significant amount of effort" to support proxies directly. Unfortunately Vincent had to report[4] that his institution forced everything through a proxy due to being "paranoid about security) and he was stuck with either setting up an open access machine or working from home.


[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00175.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00665.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00178.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00667.html


=== Feature Proposal: Provers ===
A possibility for the web browser error was supplied[5] by [[AndrewPrice|Andrew Price]] as an <code>ssl_error_handshake_failure_alert</code> which he had seen prior to the general outage. 


An interesting proposal to include a bunch of tools for automated theorem proving was mooted[1] by [[User:dwheeler|David A. Wheeler]]. The bundle of tools, listed in David's post, would ease the task of increasing the reliability of software in some specific cases and are often used (see paper by David[2]) to perform assurance for safety and security on other programs. David argued that these tools, which are variously Formal Methods Tools, Key Provers and Solvers should be considered as a "Feature" for Fedora 10 as they needed some integration and had not previously been packaged for Fedora. Some of the methods enabled by these tools are being used by the OpenSuSE distribution to speed up dependency solving of RPM packages.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00675.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00263.html
=== Small Machine SIG ===


[2] http://www.dwheeler.com/essays/high-assurance-Floss.html
An effort to gauge interest in starting a small form-factor machine SIG was made[1] by [[JeremyKatz|Jeremy Katz]]. He asked that anyone interested in running Fedora on the Asus Eeepc, netbooks, UMPCs, MIDs and perhaps the XO would contribute to a wiki page[2]. The specific goals were both to "just get the hardware working well with [current] Fedora" and also "possibly a spin that is explicitly targeted at some of the constraints of the hardware down the line." Several people responded and added themselves to the wiki.


[[User:JarodWilson|Jarod Wilson]] was uncertain[3] that the case for calling "just a collection of new packages" a Feature had been made. After further support from [[PatriceDumas|Patrice Dumas]], [[CaseyDahlin|Casey Dahlin]] and [[PaulFrields|Paul Frields]] an explanation was posted[4] by [[ToshioKuratomi|Toshio Kuratomi]] that the determination is made in part by the presentation of why and how some packages are useful to a hypothetical end user: "just saying Fedora has a collection of provers isn't a Feature. But saying, in Fedora 10 we've made an effort to include foo, bar, baz important provers for Target Audience so they can find all the tools they need to do X Type of Work. Similarly, `We've done work so that foo and bar can import and export the same file format', or other work to show how we're making the user experience better would make a stronger case for a feature." Similarly Jarod provided[5] links to the Fedora Project wiki to support his case that not enough had been done to explain why the programs were a cohesive collection dedicated to a particular end use case although he admitted "I suppose perhaps this falls under "noteworthy enough to call out in the release notes", depending on who you ask. I'm still not sold yet."
[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00497.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00265.html
[2] http://fedoraproject.org/wiki/JeremyKatz/Netbooks


[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00298.html
[[PeterRobinson|Peter Robinson]] defined the goal as "a small, low power image with packages without massive dependencies" while [[JaroslavReznik|Jaroslav Reznik]] called[3] for an emphasis on the UI instead of merely on drivers for hardware support. [[KevinVerma|Kevin Verma]] agreed[4] that "more usable UIs for small devices, also apps that are more adaptive to small screens" were important, and cited Maemo[5] and Moblin[6] as inspirations. Kevin had already[7] done some packaging work in this area.


[5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00301.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00576.html


RahulSundaram wanted[6] a classification of packaging difficulty added as he had examined several on the package wishlist and found them "a large amount of pain to package." [[VasileGaburici|Vasile Gaburici]] suggested calling the packages "Theorem Proving Tools" in order to broaden the category a bit. He also suggested[7] including ''gap'' and ''twelf''. Suggestions to include other packages were forthcoming from [[MilesSavin|Miles Savin]] for ''Agda2'' and [[RichardJones|Richard Jones]] for ''CIL'', a C-parser and static-analysis tool. Richard included a link[8] to a nice analysis of ''libvirt'' performed with CIL. [[AndrewOverholt|Andrew Overholt]] noted[9] that ''sat4j'' was already packaged in Fedora.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00589.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00264.html
[5] Maemo is Nokia's software platform for internet tablets. It is based on GTK+. See http://maemo.org/ for more information.


[7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00267.html
[6] http://fedoraproject.org/wiki/FWN/Issue136#RPM_Inspires_Intel_Moblin2_Shift_From_Ubuntu


[8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00288.html
[7] http://kevinverma.fedorapeople.org/packages/


[9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00293.html
[[JeremyKatz|Jeremy Katz]] responded[8] that given the imminent release of Fedora 10 it was most likely that better hardware support would be the immediately achievable goal. While agreeing that Maemo was interesting he preferred to get Sugar[9] running within the Fedora 11 timeframe. In answer to JeffSpaleta he clarified[10] that recent work done by [[GregDeKoenigsberg|Greg DeKoenigsberg]] to run "stock" Fedora on the XO was relevant but a different goal from producing a spin of Fedora, for all small machines, using the Sugar interface.


=== rpmgrok Announced ===
[8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00594.html


Red Hat's [[DavidMalcolm|David Malcolm]] announced[1] ''rpmgrok'', a web-based tool to allow users to track program information across an entire distribution, yet without having a complete install tree. The tracked information includes all symbols in binaries, RPM manifests, shared objects, meta-information about rpms and more. He pointed interested parties to his test prototype[2].
[9] The unique interface developed for the resource-constrained XO produced by the OLPC project


[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00221.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00609.html


[2] http://publictest7.fedoraproject.org/rpmgrok
The main developer of BLAG[11], [[JeffMoe|Jeff Moe]], posted[12] links to images that supported "all hardware on the EeePC 701/900 using *only* free software. This includes wifi with the ath5k driver. It is based on -libre and -rt plus various other patches." [[JeremyKatz|Jeremy Katz]] re-phrased[13] his goal as "[to] be able to run on the systems with stock Fedora" in order to avoid the distribution problem of special spins. Jeff encouraged[14] this possibility with the information that apart from wireless the stock Fedora 9 kernel supported everything on the EeePC 701/900 and that although there was support for the Atheros ar2425 wireless chip support in the 2.6.27 kernel there were still specific patches lacking for EeePCs. He added that the EeePC 901/1000 used a different wireless chip (from Ralink who have been active in releasing information necessary for Free drivers in the past) and included a link to Ralink's code for an apparently complete RT2860 ABGN driver. [[WarrenTogami|Warren Togami]] confirmed[15] that there were vague rumors that the chipset would be supported upstream.


All this information is obtained by analyzing the actually built rpms and storing the results in a database. David requested that anyone interested in coding, sysadmin and UI design get involved and provided a link to the ''git'' repository and the information that it was built upon ''TurboGears'' and ''SQLAlchemy''.


Enthusiasm for the "Errors and warnings from rpmlint" was expressed[3] by [[AxelThimm|Axel Thimm]] because he could imagine that someone that's say an expert on "invalid-desktopfile" issues could now dig into this much easier. Very nice!", but upon further feedback[4] from [[MamoruTasaka|Mamoru Tasaka]] and [[VilleSkyttä|Ville Skyttä]] it appeared that some work needed to be done to ensure that ''rpmlint'' was being used correctly. In any case this looks like a very promising and useful tool.
[11] A single-CD derivative of Fedora 9 which is strictly Free Software. See https://wiki.blagblagblag.org/FAQ


[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00228.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00511.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00242.html
[13] www.redhat.com/archives/fedora-devel-list/2008-August/msg00533.html
 
[14] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00537.html
 
[15] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00550.html
 
After [[RexDieter|Rex Dieter]] asked why the BLAG folks were not upstreaming their changes to Fedora it was explained[16] by Jeff that he filed bug reports and mailed .spec files upstream but that they were perhaps in conflict with the packaging guidelines. He also alluded to the fact that much of his work centered around the "kernel-libre" which had caused flamewars in the recent past. In conclusion he noted that he had been able to perform many simultaneous tasks "while playing a song with *zero* stutters or dropouts on a teeny little computer. That rules." but that it required the use of the low-latency audio server JACK[17], that is non-standard on Fedora.
 
[16] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00554.html
 
[17] http://jackaudio.org/

Revision as of 00:02, 17 August 2008

Developments

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

Contributing Writer: Oisin Feeley

FlashPlayer 10 Symlink Provokes Proprietary Support Argument

A formal request to remove the "miniature libcurl.so.3 library" was made[1] by Josh Boyer. This had been created in order to support the latest version[2] of Adobe's proprietary Flash Player which had a hard dependency on libcurl.so.3 while Fedora 8, Fedora 9 and Fedora 10(alpha) provided only libcurl.so.4. Josh argued that the change, mentioned on Warren Togami's blog[3] had been made solely to accommodate a proprietary application.

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

[2] http://labs.adobe.com/technologies/Flashplayer10/

[3] http://wtogami.livejournal.com/27778.html

After NikolayVladimirov argued[4] that it was a minimal, non-invasive change which might be useful for some "dead opensource projects that use the old version" Josh replied[5] this support goal would be better met by providing a "compat-curl" package instead of "just a hack with the sole intention of making Flash work again". In an aside he mentioned that he would have no objection to removing libflashsupport and a bunch of other stuff. Matthew Garrett followed[6] the train of thought to one possible final destination: "If the ABI is consistent across the SONAME bump, then it's a hack that supports any pre-existing binaries that users have. The best way we could serve those users with a compat package would be to ship another copy of the latest version of curl (so they get the bugfixes) but with a changed SONAME - at which point we'd be shipping two identical source packages that produce binary packages that differ only in library name. In doing so, we'd be increasing the cost of security updates. What does that actually win us?"

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

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

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

Bastien Nocera thought[7] that such a "compat-curl" package would duplicate unmaintained code and was pointless "since libcurl didn't break ABI, and only changed soname". Josh stood firm[8] and retorted that if the ABI was static then the applications could simply rebuild against the newer libcurl. Warren Togami characterized[9] Josh's viewpoint as "extremist" as it proposed "removing a zero maintenance 2496 byte file that would permanently break Flash 10 forever in Fedora" and that furthermore "[Adobe] are not violating any licenses like NVidia[.]" Following similar sentiments from "drago01" Josh deferred the discussion to a FESCo meeting held on Wed 13th August and this duly decided[10] to leave things as they were with two soname files in the curl package despite some strenuous objections which emphasized both the desirability of sub-packaging and also of not catering to the needs of proprietary applications.

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

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

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

[10] http://bpepple.fedorapeople.org/fesco/FESCo-2008-08-13.html

Parallel Install of syslog-ng, rsyslog and sysklogd

Douglas Warner sought help[1] in packaging syslog-ng so that it could be installed with either of the other current system loggers: rsyslog and sysklogd. He explained that all three installed their own "logrotate" files which targeted the exact same log files for rotation and thus doubly rotated the logs. So far Douglas' attempt to change his own syslog-ng package to fix this was stymied on RHEL boxes because updates of sysklogd (RHEL's preferred system logger) silently remove syslog-ng. Later in the thread Benny Amorsen provided[2] the insight that running syslog-ng for handling remote logs and rsyslog for its simple configuration simultaneously was useful.

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

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

The question of how to ship precisely the same logrotate script, from the viewpoint of RPM, was mentioned[3] by Douglas as one possible solution. If this could be done then RPM would be agnostic about where the file came from as long as it were possible to figure out whether the identity was based on "file size, md5, timestamp, ?". Ville Skyttä suggested[4] using the %verify directive as detailed in a link to the "Maximum RPM" book.

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

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

A restructuring of the problem by Jason Tibbits led him to recommend[5] that a separate logrotation-script package be split out of the current packages and that each of the current packages be made to depend on the new package. When Douglas nixed the suggestion due to his lack of control over the sysklogd script Jason seemed[6] to react a little testily and asked "Could we discuss technical solutions and ignore Red Hat politics? What I proposed is a standard method of dealing with these things." After JarodDiamond agreed with this Dmitry Butskoy pointed[7] out that a different PID filename is used in each script and wondered was it possible to to create such a common logrotate package for all the syslog-like packages. A likely solution was proposed[8] by Chris Adams which used the expedient of symlinking each of the unique PID files from within the init script.

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

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

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

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

General Outage of Fedora Infrastructure

Many were caught by surprise when there was a widespread outage of Fedora Project infrastructure during the week. The earliest symptoms noticed included an inability to access Koji (see e.g. this FWN#139 "Koji from Behind a Firewall") or obtain updates with yum. A general announcement by Paul Frields followed[1] quickly on Thursday 14th and stated that an "issue in the infrastructure systems [was being investigated and might] result in service outages[.]" Somewhat ominously it concluded "[..] as a precaution, we recommend you not download or update any additional packages on your Fedora systems." This led some to speculate[2] that there might be a security problem.

Further announcements or explanations were not forthcoming for days, except for a post to @fedora-infrastructure which suggested[3] that the problem was causing a lot of hard work. Paul Frields posted another update[4] on Sat 16th. This succinctly stated that the wiki and FAS should be back soon but that the application servers would take a bit longer.

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

[2] http://lwn.net/Articles/294188/

[3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00109.html

[4] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00009.html

Koji from Behind a Firewall

A query was made[1] by Victor Lazzarini about how to connect to Koji using the CLI from behind a firewall. He wondered specifically how to set up a proxy connection. He added that he was seeing an error when using a web browser but was[2] unable to provide it due to the general outage in Fedora infrastructure.

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

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

Mike Bonnet answered[3] that Koji did not have direct proxy support but that it used only ports 80 (http) and 443(https) as these are generally open. He explained that it would be "a significant amount of effort" to support proxies directly. Unfortunately Vincent had to report[4] that his institution forced everything through a proxy due to being "paranoid about security) and he was stuck with either setting up an open access machine or working from home.

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

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

A possibility for the web browser error was supplied[5] by Andrew Price as an ssl_error_handshake_failure_alert which he had seen prior to the general outage.

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

Small Machine SIG

An effort to gauge interest in starting a small form-factor machine SIG was made[1] by Jeremy Katz. He asked that anyone interested in running Fedora on the Asus Eeepc, netbooks, UMPCs, MIDs and perhaps the XO would contribute to a wiki page[2]. The specific goals were both to "just get the hardware working well with [current] Fedora" and also "possibly a spin that is explicitly targeted at some of the constraints of the hardware down the line." Several people responded and added themselves to the wiki.

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

[2] http://fedoraproject.org/wiki/JeremyKatz/Netbooks

Peter Robinson defined the goal as "a small, low power image with packages without massive dependencies" while Jaroslav Reznik called[3] for an emphasis on the UI instead of merely on drivers for hardware support. Kevin Verma agreed[4] that "more usable UIs for small devices, also apps that are more adaptive to small screens" were important, and cited Maemo[5] and Moblin[6] as inspirations. Kevin had already[7] done some packaging work in this area.

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

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

[5] Maemo is Nokia's software platform for internet tablets. It is based on GTK+. See http://maemo.org/ for more information.

[6] http://fedoraproject.org/wiki/FWN/Issue136#RPM_Inspires_Intel_Moblin2_Shift_From_Ubuntu

[7] http://kevinverma.fedorapeople.org/packages/

Jeremy Katz responded[8] that given the imminent release of Fedora 10 it was most likely that better hardware support would be the immediately achievable goal. While agreeing that Maemo was interesting he preferred to get Sugar[9] running within the Fedora 11 timeframe. In answer to JeffSpaleta he clarified[10] that recent work done by Greg DeKoenigsberg to run "stock" Fedora on the XO was relevant but a different goal from producing a spin of Fedora, for all small machines, using the Sugar interface.

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

[9] The unique interface developed for the resource-constrained XO produced by the OLPC project

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

The main developer of BLAG[11], Jeff Moe, posted[12] links to images that supported "all hardware on the EeePC 701/900 using *only* free software. This includes wifi with the ath5k driver. It is based on -libre and -rt plus various other patches." Jeremy Katz re-phrased[13] his goal as "[to] be able to run on the systems with stock Fedora" in order to avoid the distribution problem of special spins. Jeff encouraged[14] this possibility with the information that apart from wireless the stock Fedora 9 kernel supported everything on the EeePC 701/900 and that although there was support for the Atheros ar2425 wireless chip support in the 2.6.27 kernel there were still specific patches lacking for EeePCs. He added that the EeePC 901/1000 used a different wireless chip (from Ralink who have been active in releasing information necessary for Free drivers in the past) and included a link to Ralink's code for an apparently complete RT2860 ABGN driver. Warren Togami confirmed[15] that there were vague rumors that the chipset would be supported upstream.


[11] A single-CD derivative of Fedora 9 which is strictly Free Software. See https://wiki.blagblagblag.org/FAQ

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

[13] www.redhat.com/archives/fedora-devel-list/2008-August/msg00533.html

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

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

After Rex Dieter asked why the BLAG folks were not upstreaming their changes to Fedora it was explained[16] by Jeff that he filed bug reports and mailed .spec files upstream but that they were perhaps in conflict with the packaging guidelines. He also alluded to the fact that much of his work centered around the "kernel-libre" which had caused flamewars in the recent past. In conclusion he noted that he had been able to perform many simultaneous tasks "while playing a song with *zero* stutters or dropouts on a teeny little computer. That rules." but that it required the use of the low-latency audio server JACK[17], that is non-standard on Fedora.

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

[17] http://jackaudio.org/

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