Fedora Weekly News #119 — Development Beat
== Developments ==
In this section, we cover the problems/solutions, people/personalities, and
ups/downs of the endless discussions on Fedora Developments.
http://www.redhat.com/mailman/listinfo/fedora-devel-list
Contributing Writer: Oisin Feeley
=== Baracuda To Replace VNC ? ===
A query as to the status of the replacement of ”vnc” by ”baracuda” (note the single “r”) in Fedora 9 was posted[1] by MikeC. Mike was concerned that there was no mention of either in the feature list and especially wanted to preserve the ability to load a vnc module in Xorg.conf so that the screen could be viewed remotely even without a user logging in via the display manager.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00254.html
Several replies focused on the client end of the equation and ignored the server part. DanielBerrange pointed out[2] that for GNOME the ”vinagre” package is superior to the old RealVNC ”vncviewer” as it can handle ”gnome-keyring”, ”avahi” discovery and bookmarking of connections. KevinKofler and BenjaminKreuter responded[3] that on the KDE desktop the same functionality is provided by ”Krfb”. Benjamin hoped that ”vncviewer” was going to be maintained in the repositories as there were scripts which depended on it. AdamTkac responded to DanielBerrange that the focus of ”baracuda” was to produce a standalone Xvnc server with a libvnc.so module built against Xorg 1.5 and that the client was subsidiary.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00259.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00266.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00337.html
Mike pointed out[5] that a user needed to be logged in before ”krfb” could be run and that his use case involved remote logins.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00274.html
AdamTkac, responding[6] directly to the original mail, gave an update on ”baracuda”, explaining that it was a fork forced by the need to have an Xorg-1.5 based vncserver and that the original upstream (RealVNC) were not maintaining the source. This is probably because they also sell an “enterprise” edition. The current Xvnc has thus accumulated a significant number of patches which Adam ,as Fedora maintainer, judged unacceptable. Seemingly other projects had made the same determination and once Adam announced[7] the Fedora fork the TightVNC project expressed[8] interest in merging his work and it seems this is going ahead. Mike greeted this good news with thanks to Adam for his work.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00334.html
[7] http://www.realvnc.com/pipermail/vnc-list/2008-February/058598.html
[8] http://www.realvnc.com/pipermail/vnc-list/2008-February/058619.html
=== Sins Of Commission: Google Earth ===
A plea for the packaging of Google Earth[1] was made by DouglasMcClendon. He explained that he was short of time but thought it ought to be easy for someone to whip up a ”kickstart” ”%post” scriptlet to install Google Earth. A quick response from ChristopherBrown declined to attempt to package non-Free software: “When [G]oogle actually release something open source other than obscure OCR software that sucks anyway I’ll be more than happy to work a bit harder on stuff like that.” Christopher’s comment became the focal point of the thread which echoed long-standing unease with Google Earth’s non-Free binaries, its reliance upon further non-Free video-card drivers and its restrictive licensing terms on its data[2]. Douglas clarified[3] that what he was interested in was copying Debian’s approach which is to use a properly licensed script which grabs the non-Free code, turns it into an rpm and then installs it.
[1] http://earth.google.com/
[2] http://lwn.net/Articles/211153/
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00367.html
Christopher made it clear[4] that he was aware that what Douglas was requesting might not be so different from the ”autodownload” scriptlets on the Fedora Games DVD which pull non-Free game data and asked how far down the slippery slope it was proposed to travel. He described[5] the method as a circumvention of Fedora policy. AndrewFarris agreed[6] that the package should not be in the Fedora repositories but did wish that someone would package it in some other repository. He also disagreed that Google Earth and the ”autodownload” scripts were the same as in the former case the actual program code is unavailable whereas in the latter the code is available and all that is missing is some data. Douglas largely agreed, suggested[7] the Livna repository as a good place and wished that someone would port NASA’s ”worldwind”[8].
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00368.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00371.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00374.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00378.html
[8] http://worldwind.arc.nasa.gov/java/index.html
ToshioKuratomi summed up[9] the situation concisely and noted that HansdeGoede ‘s script was “controversial”. TomCallaway’s opinion was[10] that the distinction between data and code was a fine, but important one and OlivierGalibert thinned it even further when he asked[11] “How much of this data is code for a virtual machine?”. Further exploration led ChristopherAillon to state that the games supplied are supposed to have enough data to be somewhat useful without the restricted data and KevinKofler to state[12] that in practice this was not the case. Kevin listed several possible problems in this regard and suggested that anyone objecting should take it up with FESCo.
[9] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00373.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00393.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00394.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00423.html
The situation, as described, was thought by JesseKeating to be unacceptable and Toshio responded[13] that if FESCo were going to revisit the issue then it would be wise and fair to ensure that Hans were available during the discussion as he was shouldering the burden of any work and needed to understand the requirements. Responding to a request from TomCallaway for specifics, KevinKofler ran a quick {{{repoquery —whatrequires autodownloader}}} and listed[14] five games which have licenses which restrict the distribution of their data and are useless without it. AlanCox did not think the situation was so clear cut and posited[15] that a better test was to ask “whether it is possible to produce new free data sets for [such tools].” He later expanded[16] upon this with examples and with the correction that the important condition was “practicality” rather than “possibility.”
[13] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00471.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00481.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00519.html
[16] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00623.html
=== Autodownloader vs. CodecBuddy ===
A thread to specifically discuss the ethical and practical problems posed by the use of ”autodownloader” (see this FWN#119 “Sins Of Commission: Google Earth”) was opened[1] by HansdeGoede. Hans explained that his own guideline for the use of autodownloader was that it was “only for content […] for Free engines.” He thought that while CodecBuddy (also known as Codeina[2]) was included in the distribution it was hypocritical to worry about autodownloader. He emphasized that Codeina downloads closed-source code and also offers the user the option to purchase said code, effectively advertising closed-source.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00476.html
[2] http://fedoraproject.org/wiki/Multimedia/Codeina
A longish sub-thread started[3] by JakubRusinek worked over the exhausted topic of whether or not Codeina/CodecBuddy can do anything further to facilitate the installation of possibly patent-encumbered codecs. There was nothing particularly new to see here, with the situation remaining as it has since the last opinion from Red Hat “legal” which implies that the current web page can obliquely explain the problem but needs to beware of contributory infringement. RahulSundaram supplied[4] a link to the relevant post. Unless the interpretation of software as both machine and copyrightable work (see AlanCox’s post[5]) in the U.S.A. were to be miraculously overthrown then such discussion appears moot, as do comparisons to the non-US based Canonical.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00480.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00540.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00523.html
A bizarrely formatted post made by TrondDanielsen suggested[6] that the pursuit of the Online Desktop[7] was another example of the hypocrisy and grey areas to which Hans had alluded. MatejCepl reacted[8] harshly, rebutting Trond’s assertion that there was a partnership with Google, or that the purpose was to integrate Flickr and Google with the rest of the desktop. Trond’s civil, self-deprecating response explained[9] that “The purpose of the argument was that Fedora already depend on proprietary services and software which makes the argument against the autodownloader invalid” but HorstvonBrand undermined[10] the validity of the argument and explained that while a daily beating with the cluestick may be beneficial to recipients it is tiring for the administrator.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00492.html
[7] http://fedoraproject.org/wiki/Releases/FeatureOnlineDesktop
[8] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00545.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00558.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00570.html
There were several voices raised in favor of removing Codeina/CodecBuddy. Among them were Dexter[11] and KevinKofler[12]. Kevin added that web browsers should be prevented from offering to install the proprietary flash plugins as there was a Yum repository facilitating cleaner installs. JefSpaleta grew tired[13] of the strained comparisons between different pieces of software. ChrisAdams thought that picking on Adobe’s Flash (especially when they provide such a repository) would prevent him from being able to use Fedora in his job. He pointed out that ”swfdec” and other free software Flash players cannot support MP3 audio until possibly 2017. BrianPepple pointed[14] out that the gstreamer plugin was available, just not included in Fedora due to legal reasons and so the thread came full circle to the issue of licensing. Rahul provided links and wondered[15] if this conversation had to occur every few weeks.
[11] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00479.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00544.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00588.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00648.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00673.html
=== The Point Of Mock ===
An interesting short thread was started[1] by KellyMiller (lightsolphoenix). Kelly sought advice on how to write the spec file for a KDE3 package destined for both Fedora 8 and rawhide now that the package names have changed. IgnacioVazquezAbrams suggested[2] using a ”%{dist}” tag and JarodWilson added[3] that BuildRequires did not need to be versioned to catch devel packages less than version 3.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00286.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00287.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00290.html
As a subsidiary issue Kelly mentioned[4] that there seemed to be problems with the ability of ”mock” to build x86_64 packages. Jarod and Jesse both wondered whether he was on an x86 machine and it seemed that he was. Kelly mused[5] “I was under the impression that the whole point of using Mock was to handle that situation”. Jesse responded[6] “No, the whole point of mock is to create clean chroots each time you want to build. The x86_64 platforms ability to run i386 code is a side effect.” KevinKofler observed[7] that running ”qemu” allowed (at the expense of a massive speed penalty) the building of x86_64 code on an i386 platform.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00297.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00329.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00331.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00347.html
=== Glade 2 And Glade 3 Co-existence ===
DebarshiRay (rishi) drew attention[1] to the dependency of the latest ”anjuta” on ”glade3”[2] and requested that the replacement of ”glade2” by ”glade3” be considered. Debarshi thought this would affect the Developer Live spin and the regular GNOME DVD spin.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00308.html
[2] Glade is a RAD tool to develop GTK GUIs: http://glade.gnome.org/
MatthiasClasen asked[3] whether ”glade3” could handle all the files produced by ”glade2”. TimWaugh confirmed[4] that although this seemed to work he had seen problems with the converse, where files touched or produced by ”glade3” were not rendered correctly by ”glade2”.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00309.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00326.html
The suggestion by Debarshi that it might be prudent to split Anjuta up or drop it entirely was thought[5] by Matthias not to be necessary as the two glade versions might be able to co-exist. JeremyKatz was happy that there was plenty of space on the DVD for both versions[6].
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00311.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00320.html
=== Dropping FUSE Group? Security Concerns ===
As the upcoming GNOME VFS will use FUSE as a backend PeterLemenkov proposed[1] to drop the Fuse group as otherwise all users would need to be added to this group. He asked for objections to be made known.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00237.html
Initial concern was expressed by WarrenTogami on the foot of the affect this might have on KDE users. He also wondered how upgrades would be affected. ThorstenLeemhuis asked[3] whether a security audit had been conducted as he had suggested some time ago. KarelZak reported[4] that MiklosSzeredi’s work on a non-root-privileged mount (which could be used by FUSE) was making its way into the —mm kernel tree. He also made some interesting observations on the Fedora Project package process. MattDomsch suggested[5] a Koji equivalent of ”rpmlint” to search for suid problems.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00239.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00240.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00278.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00442.html
AlexanderLarsson argued[6] that Thorsten’s security worries were only tangentially related to FUSE itself and had more to do with inappropriate use of setuid. He added that SELinux policy for ”fusermount” would be a possibly useful enhancement. Alex also provided[7] the information that it was actually ”GVFS”, a replacement to ”GNOME VFS” which was under discussion and explained its workings.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00306.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00296.html
KevinKofler called[8] the FUSE group “plugdev reloaded” and outlined the problem of having to add users manually.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00382.html
Further questioning by Warren as to the implications of the change for users of non-GNOME desktops drew[9] a reply from Alexander to the effect that it was an orthogonal issue and Kevin provided some backing on this point with the comparison of KIO functionality.
[9] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00387.html
An excellent summary was made[10] by Alexander in which he pointed out that FUSE provides desired features that GNOME and other software are currently using and that Fedora’s security fears will lead to either “punching users in the face” by shipping a setup which they need to correct manually or else just not shipping the software. SteveGrubb replied[11] that the Common Criteria[12] evaluations were for specific mounting mechanisms and that this new, parallel method might necessitate Steve doing a lot of extra, unplanned work. A meaty, information-filled series of posts followed. Alexander described[13], in another excellent post, the benefits of FUSE, Steve pointed[14] to a potential problem with SELinux auditing and wondered whether FUSE was duplicating some pre-existing functionality in sharing files over SSH, but without the benefit of auditing mechanisms. Alexander’s last mail[15] (as of publication date) was a detailed apparent rebuttal of Steve’s concerns which emphasized the role of FUSE in exposing non-root users to filesystems which were otherwise awkward to access.
[10] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00386.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00402.html
[12] http://en.wikipedia.org/wiki/Common_Criteria
[13] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00447.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00452.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00457.html
