|
|
| (102 intermediate revisions by 2 users not shown) |
| Line 5: |
Line 5: |
| mailing list are summarized. | | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === Mysterious Fedora Compromise === | | === Would You Like to Write This Beat ? === |
|
| |
|
| The mysterious unavailability of much of the FedoraProject infrastructure (see FWN#139 "General Outage of Fedora Infrastructure"[1]) continued to provoke speculation during the week. Some light was shed[2] on 22-08-2008 when [[PaulFrields|Paul Frields]] announced that there had been an intrusion onto several FedoraProject servers. The announcement emphasized that although one of the servers was used for signing rpm packages it was believed, based upon an absence of positive evidence, that the key and packages had not been tampered with. Nevertheless prudence and caution were being exercised and the opportunity was being seized to completely re-install and upgrade all systems. As a result it was necessary for most contributors to reset authentication tokens of various types (see this same issue[3].) It also appeared[4] that a concurrent event had led to the signing of some Red Hat OpenSSH packages, but that these had been quickly detected and had not led to the distribution of compromised packages.
| | Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or [[User:Pcalarco|Pascal Calarco]]. A short overview of what you may need to do can be obtained by reading the workflow<ref>http://fedoraproject.org/wiki/FWN/WorkFlow</ref> section of the wiki. The @fedora-news list is also extremely open and helpful. Joining<ref>http://fedoraproject.org/wiki/FWN/NewsProject/Join</ref> the News Project is quite straightforward. |
|
| |
|
| [1] http://fedoraproject.org/wiki/FWN/Issue139#General_Outage_of_Fedora_Infrastructure
| | <references/> |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [3] "Epiphany, Konqueror and Plague Hamper Updating SSL Client-side Certificates" | | [[User:Sundaram|Rahul Sundaram]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html</ref> the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using. |
| [4] http://www.redhat.com/security/data/openssh-blacklist.html
| |
|
| |
|
| Prior to that announcement all that was known was that there were problems on the build servers which became obvious to a wide audience on 13-08-2008 and that users were advised[5] on 14-08-2008 not to install updates. The wiki and email lists continued to function during this period thanks to the efforts of their administrators.
| | One interesting point is that CMUCL<ref>One of the Common Lisp implementations: http://www.cons.org/cmucl/</ref> was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html</ref> to be only available for 32-bit systems. However what got people really excited was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html</ref> Rahul's question about what to do concerning the <code>gNaughty</code> package. Its sole purpose seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html</ref> to be downloading pornography. Rahul referenced the <code>hot-babe</code> CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?" |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.html | | Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html</ref> by [[User:Alsadi|Muayyad AlSadi]] who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. [[User:Notting|Bill Nottingham]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html</ref> skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html</ref> the reaction typified by [[User:Skvidal|Seth Vidal]] which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. [[User:bochcecha|Mathieu Bridon]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html</ref> that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy. |
|
| |
|
| An update[6] was posted on 18-08-2008 by [[PaulFrields|Paul Frields]] that listed the services which had returned to normal and those which were expected to return to normal soon. Public speculation latched on[7][8] to the changing of "fedorahosted" SSH keys. Most guesses used this as evidence that something similar to the recent 2008 Debian OpenSSL vulnerabilities[9] had occurred. Some confusion prevailed[10] on @fedora-devel as to whether it was possible to trust the new key fingerprint on the website. [[JimMeyering|Jim Meyering]] added[11] a useful post which explained how to change from using a DSA ssh key to an RSA ssh key. Overall there was a surprisingly low level of public discussion of the problem and it was not until 18-08-2008 that some complaints about the lack of information were expressed[12] on @fedora-list. On 22-08-2008 another bulletin was released[13] by [[PaulFrields|Paul Frields]] that explained that the Fedora key had not been obviously compromised but that it was still being changed on the precautionary principle.
| | <references/> |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00011.html
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [7] http://lwn.net/Articles/294547/ | | [[KristapsViesalgs|Kristaps Viesalgs]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html</ref> for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?" |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00790.html | | [[User:Ajax|Adam Jackson]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html</ref> for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by [[User:Adamwill|Adam Williamson]] and [[User:|Xavier Bachelot]]. The latter asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html</ref> any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides. |
|
| |
|
| [9] Metasploit has an excellent writeup on the topic here: http://www.metasploit.com/users/hdm/tools/debian-openssl/
| | <references/> |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00841.html
| | === Who Wants a Pony? === |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00845.html | | [[User:Kushal|Kushal Das]] promised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html</ref> a pony to anyone that would take the trouble to review<ref>http://bugzilla.redhat.com/show_bug.cgi?id=503021</ref> one of his packages. |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-list/2008-August/msg01953.html
| | <references/> |
|
| |
|
| [13] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| Although many responses to complaints about the limited information suggested[14] that the Fedora developers could be trusted to "do the right thing" in terms of alerting users to immediate threats of compromise there was still strong disquiet expressed[15] over the lack of information. This also occurred[16] on @fedora-list. [[JeffSpaleta|Jef Spaleta]] wondered[17] if there might be a better way of getting information out than relying on everyone to subscribe to @fedora-announce. [[AlanCox|Alan Cox]] suggested[18] that an RSS feed for critical announcements could be picked up by a system's default package updater and that repositories could communicate errors to ''yum''. Alan was also unhappy with the absence of important notices on the very front of the website and as a separate matter criticized the content of the information issued: "[...] leaving people in the dark assuming the worst [is] a very bad way to create long term trust." [[BrunoWolff|Bruno Wolff III]] also suggested[19] that information should have been conveyed by a more central announcement on fedoraproject.org and co-ordination with media such as LWN.net.
| | [[User:Maxamillion|Adam Miller]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html</ref> whether he should just retire the <code>Firestarter</code><ref>Firestarter is a firewall configuration GUI</ref> package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate <code>Firestarter</code> with <code>PolicyKit</code>. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok <code>PolicyKit</code>. |
|
| |
|
| [14] https://www.redhat.com/archives/fedora-list/2008-August/msg01955.html | | Following confirmation from [[User:Sundaram|Rahul Sundaram]] and [[User:Skvidal|Seth Vidal]] a decision was made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html</ref> by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future." |
| | |
| | A further suggestion from "Cry" prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html</ref> Adam to start filing RFEs against <code>system-config-firewall</code> for any features present in <code>Firestarter</code> but missing in <code>system-config-firewall</code>. |
| | <references/> |
|
| |
|
| [15] https://www.redhat.com/archives/fedora-list/2008-August/msg02034.html
| | === Russian Fedora ? === |
|
| |
|
| [16] https://www.redhat.com/archives/fedora-list/2008-August/msg02426.html | | When [[User:Peter|Peter Lemenkov]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html</ref> about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. [[User:Kkofler|Kevin Kofler]] gave<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html</ref> an able summary why this would still present Red Hat with a problem. |
|
| |
|
| [17] https://www.redhat.com/archives/fedora-list/2008-August/msg02010.html | | An assertion by [[User:|Alexey Torkhov]] that there existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html</ref> a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from [[User:Sundaram|Rahul Sundaram]]. |
|
| |
|
| [18] https://www.redhat.com/archives/fedora-list/2008-August/msg02012.html
| | <references/> |
|
| |
|
| [19] https://www.redhat.com/archives/fedora-list/2008-August/msg02013.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| Most comments on @fedora-devel made a point of thanking the Fedora Infrastructure admins, even to the extent of providing internet beers[20] and [[HansdeGoede|Hans de Goede]] commented[21] that "Even before the unfortunate events of the last few weeks the infrastructure team has been doing an amazing job[.]"
| | A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]]. |
|
| |
|
| [20] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01037.html | | [[User:Adamwill|Adam Williamson]] and [[User:Mdomsch|Matt Domsch]] (Dell's DKMS mastermind) kicked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html</ref> some ideas back and forth over the advantages of <code>akmods</code> versus <code>kmods</code>. |
|
| |
|
| [21] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01028.html
| | <references/> |
|
| |
|
| === Epiphany, Konqueror and Plague Hamper Updating SSL Client-side Certificates === | | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| As part of the general overhaul of Fedora Project infrastructure security occasioned by the recent intrusion[1] [[DennisGilmore|Dennis Gilmore]] advised[2] that the certificate authority governing access to cvs.fedoraproject.org and koji.fedoraproject.org had been changed. As a result it was necessary for those who wished to build packages or upload to the lookaside cache to manually import a new client-side certificate and to remove their old certificate.
| | Following a report from [[UweKiewel|Uwe Kiewel]] that a <pre>yum upgrade</pre> had spewed all sorts of errors the supported methods for upgrades were re-stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html</ref> by [[User:Adamwill|Adam Williamson]]: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline." |
|
| |
|
| [1] http://fedoraproject.org/wiki/FWN/Issue139#General_Outage_of_Fedora_Infrastructure
| | <references/> |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00962.html
| |
| | |
| [[MartinSourada|Martin Sourada]] reported[3] that after following the procedure he still received a <code>(Error code: ssl_error_unknown_ca_alert)</code>. [[KaiEngert|Kai Engert]] suggested[4] that Martin might need to import the Fedora Project root CA certificate after verifying its fingerprint. As Martin had allowed exceptions for the Fedora websites this was not the problem and it turned out[5] to be due to a problem with the ''epiphany'' web browser failing to offer an option to remove old certificates.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00978.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00982.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00989.html
| |
| | |
| Problems were also experienced[6] by [[JoseMatos|Jose Matos]], but this time with the ''konqueror'' web browser (version 4.1.0). [[KevinKoffler|Kevin Koffler]] replied[7] that in ''KDE 4'' there was no support for SSL certificate authentication with ''konqueror'' and pasted a link[8] to an upstream bug report filed with the KDE project on this issue.
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00983.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00999.html
| |
| | |
| [8] https://bugs.kde.org/show.bug.cgi?id=167668
| |
| | |
| [[TimJackson|Tim Jackson]] reported[9] that ''plague-client''[10] was acting up and [[MichaelSchwendt|Michael Schwendt]] quickly provided[11] a patch which removed an assumption about how many bytes would be in the certificate. [[DennisGilmore|Dennis Gilmore]] commented "it's probably due to the new ca cert being 8096 bit and user certs are now all 2048 bit" and [[ChrisWeyl|Chris Weyl]] filed[12] a bugzilla.
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00993.html
| |
| | |
| [10] ''plague'' is the distributed package build system used by the EPEL repository
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00996.html
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01019.html
| |
| | |
| Later [[PaulHowarth|Paul Howarth]] encountered[13] what seemed to be a problem with his key or ''koji'' but which turned out, as suggested[14] by [[JasonTibbitts|Jason Tibbitts]] to be due to ''denyhosts'' blocking him.
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00970.html
| |
| | |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00971.html
| |
| | |
| === System Autodeath ===
| |
| | |
| [[SethVidal|Seth Vidal]] raised[1] the possibility of including a non-default option to include an "autodie" feature in future Fedora releases. The idea, originally expressed[2] in [[GlenTurner|Glen Turner's]] blog is that each OS release should ship with an expected expiry date and a means to automatically remove the default route from that machine once the expiry date arrives. This would prevent old, unmaintained machines from being quietly exploited.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00853.html
| |
| | |
| [2] http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
| |
| | |
| Agreement was expressed[3] by [[JonMasters|Jon Masters]] that it would be useful if "a sysadmin consciously wants to remember to remove a system from production/upgrade it after a certain time but then loses track of it[.]" [[RahulSundaram|Rahul Sundaram]] also thought[4] that something should be done but preferred the idea of modifying PackageKit to notify users when an upgrade was due and fixing up [[PreUpgrade]] to allow users to easily update without burning media. [[JonCiesla|Jon Ciesla]] and [[ColinWalters|Colin Walters]] wrangled over whether [[SIGs/LiveUpgrade|LiveUpgrade]] or [[Anaconda/Features/PreUpgrade|PreUpgrade]] was the appropriate place to present such notifications with Colin disliking the LiveUpgrade due to support logistics. [[RichardHughes|Richard Hughes]] was pleased to relate[5] that most of Rahul's desired feature had been implemented only a couple of days previously.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00855.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00856.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00932.html
| |
| | |
| Although [[DaveJones|Dave Jones]] was not worried[6] about desktop machines being abandoned this was contested. [[DominikMierzejewski|Dominik Mierzejewski]] related[7] anecdotes of people still running Fedora Core 2 while [[StephenSmoogen|Stephen Smoogen]] regaled[8] the list with tales of hundreds of ancient Windows 3.11 clients on his network. [[SethVidal|Seth Vidal]] shared[9] Dave's insouciance and was more concerned about servers and "appliance-like machines" but promised to "look at putting a simple cron job together in a package to do this" while inviting anyone more motivated to go ahead and implement it.
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00861.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00862.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00865.html
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00863.html
| |
| | |
| A slight misunderstanding of Seth's intentions led[10] [[HorstvonBrand|Horst H. von Brand]] to put the case "[...] against forcing people forward, even for their own good[.]" Horst argued that some systems could not be updated due to reliance on unmaintained legacy software. After Seth explained that he was not recommending that the "autodeath" feature be made a default Horst still expressed[11] a worry that casual installation followed by forgetfulness could result in the unexpected deactivation of systems later on. He suggested that instead of removing the default route "to a nag screen when EOL nears, offer to set up for upgrade, show (current) pointers to scripts helping check if 3rd party stuff will still work, ... install /that/ by default, allow to disable/uninstall it (even while it is nagging)." Seth objected[12] forcefully to describing the removal of the default route as "kills itself" and this resulted in a spate of alternate name suggestions.
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00903.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00929.html
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00930.html
| |
| | |
| [[JamesHubbard|James Hubbard]] saw[13] similarities to "Windows Genuine Advantage where you can't use your machine anymore if you can't validate your installation" and suggested instead that users be notified of the EOL and in a separate part of the thread [[JefSpaleta|Jef Spaleta]] suggested that "autoannoy", via ''motd'' or the login banner, instead of "autodeath" might educate and help users more than cutting off connectivity.
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00866.html
| |
| | |
| Commenting on responses from [[MattMiller|Matt Miller]][14][15] and [[JasonTibbitts|Jason Tibbitts]][16], among others, [[SethVidal|Seth Vidal]]commented[17] that it appeared that "all the .edu people seem to get this". But Horst was skeptical[18] that it was necessary to force sysadmins to make such changes.
| |
| | |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00911.html
| |
| | |
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00935.html
| |
| | |
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00868.html
| |
| | |
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00869.html
| |
| | |
| [18] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00931.html
| |
| | |
| [[JamesHubbard|James Hubbard]] also made[19] a strong argument that lack of
| |
| updates was as much of a security problem as being EOL'ed and thus any such
| |
| measures should also be applied to systems lagging in their updates.
| |
| | |
| [19] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00959.html
| |
| | |
| === GNUstep Filesystem Layout Discussion ===
| |
| | |
| A very clearly presented[1] explanation by [[MichelSalim|Michel Salim]] kick started a discussion about how the GNUstep application development framework could finally be included in Fedora. Michel explained that GNUstep's idiosyncratic filesystem layout had previously made it impossible to install on an FHS[2] compliant system but that it was now possible. A choice had to be made for the layout of what GNUstep terms "application bundles" bearing in mind that "flattened" layouts are platform specific while "unflattened" can support multilib with little pain. Michel saw three main choices including a non-FHS-compliant one and noted that there were potential conflicts between <code>utill-linux-ng</code> and the default installation of GNUstep tools in /usr/bin/<arch>. He also noted that Debian had chosen to use an unflattened layout.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01007.html
| |
| | |
| [2] http://www.pathname.com/fhs/pub/fhs-2.3.html#INTRODUCTION
| |
| | |
| From this point onwards the discussion became a little difficult to follow due to the use of GNUstep specific terminology. The simplest information your correspondent could find was the online version[3] of the <code>library-combo</code> manpage and is probably essential reading before even attempting to grasp the outlines of the following.
| |
| | |
| [3] http://linux.die.net/man/7/library-combo
| |
| | |
| A suggestion[4] from [[AxelThimm|Axel Thimm]] was "[...] to place [the GNUstep tools] directly under %{_bindir} and let rpm deal with the different archs as it does for all other %{_bindir} mixing of subarchs with colors etc" and to put the libraries under <code>%{_libdir}</code>. He argued that multilib or multiarch binaries were not generally supported in Fedora. Axel was also encouraging about the idea of starting a wiki page to attract as wide a possible contribution from GNUstep developers including non-Fedora contributors. Even more importantly Axel contrasted the ability of an unflattened layout to support different compilers and libraries to that of a flattened layout which could make OpenGroupware[5] conflict with other applications due to its use of <code>libFoundation</code>[6.] [[KevinKoffler|Kevin Koffler]] was unimpressed[7] with "packages which think they are a distro" and posited the solution that "[...] they need to be fixed to work with the system libraries instead (or the system libraries fixed to work with the packages[.]" While Axel agreed he explained[8] that what was being chosen was an "Objective-C runtime/ foundation library/graphical interface tuple (flattened)" and that it was necessary to allow a choice at runtime of the middle component in order to support applications depending on either libFoundation or gnustep-base[9]. Axel concluded "[...] IMHO we need to start with gnustep-make's FHS and non-flattened layout and fix it where it still needs fixing (gnustep-make FHS layout is very young and one could say that we are shaking out the bugs and when we are finished hopefully upstream will be glad to accept any patch we will have made to the FHS mode layout of gnustep-make)."
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01009.html
| |
| | |
| [5] A groupware server integrating office suites through XML-based interfaces: http://www.opengroupware.org/en/about/mission.html
| |
| | |
| [6] Cocoa, libFoundation and gnustep-base all provide implementations of, and non-standard extensions to, the OpenStep API. Apart from licensing differences gnustep-base also has better platform coverage (Windows is not supported by the others) and full unicode support.
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01021.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01029.html
| |
| | |
| [9] http://www.gnustep.org/developers/suite.html
| |
| | |
| Discussion with [[DominikMierzejewski|Dominik 'Rathann' Mierzejewski]] and Kevin led Michel to post[10] that "[...] the consensus so far seems to be for using a flattened layout. Removing --disable-flattened from gnustep-make actually causes a much tighter adherence to the FHS, with %{_bindir} and %{_libdir} not containing any subdirectories." Michel was worried that this would result in duplicating data files and that "[...] keeping the unflattened layout might be too much trouble; if we are already flattening /usr/bin and /usr/lib*, might as well stick with a flattened layout after all."
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01024.html
| |
| | |
| Apparently different conclusions were being reached at this stage and Axel attempted[11] to expand upon what he had said, explaining that this would result in having to choose between the Foundation libraries at buildtime. He presented unflattened layouts as allowing a choice of "libcombo" at runtime as opposed to flattened which forced a choice at buildtime. Dominik was[12] apparently comfortable with the idea of choosing between the two Foundation libraries and cited the precedent of not mixing ''lesstif'' and ''openmotif''. To solve the problem he suggested "[put binaries in unflattened %{_libdir}/GNUstep/* and symlink to /usr/bin ." After Axel replied that the problem was the incompatible API/ABI of the Foundation libraries Michel posted[13] another summary of the current apparent state of knowledge.
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01039.html
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01040.html
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01054.html
| |
| | |
| === Varnish 2.0 Test Suite Fails in Rpmbuild ===
| |
| | |
| An interesting post from [[IngvarHagelund|Ingvar Hagelund]], the maintainer of the ''varnish'' http accelerator package, asked[1] why a test suite in the package would behave differently within the ''rpmbuild'' created environment than when run from an interactive shell. Ingvar had eliminated ''selinux'' as a possibility and speculated "[...] the problem seems to be related to some missing communication between the test scripts and the test server process."
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00944.html
| |
| | |
| A response from [[MogensKjaer|Mogens Kjaer]] contained[2] a report that it was to do with a missing <code>libvarnish.so.0</code> and wondered "[...] is the build system using an already installed libvarnish.so.0 if one is available and not the newly built libvarnish.so.0?" [[JasonTibbitts|Jason Tibbitts]] suggested[3] that it was usual to reference such newly built libraries by manipulating <code>LD_LIBRARY_PATH</code> in the specfile. After Mogens added LD_LIBRARY_PATH and rebuilt from scratch he found[4] that all the tests were passed but that no varnish-libs had been installed and this led him to conclude that there was indeed a difference to the rpmbuild environment.
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00945.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00946.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00948.html
| |
| | |
| Ingvar ended up[5] filing a bug report upstream with the conclusion that the soname version should be bumped as the old libraries were incompatible with varnish-2.0.
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00951.html
| |
Developments
In this section the people, personalities and debates on the @fedora-devel
mailing list are summarized.
Contributing Writer: Oisin Feeley
Would You Like to Write This Beat ?
Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or Pascal Calarco. A short overview of what you may need to do can be obtained by reading the workflow[1] section of the wiki. The @fedora-news list is also extremely open and helpful. Joining[2] the News Project is quite straightforward.
Is gNaughty a Hot Babe ?
Rahul Sundaram posted[1] the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.
One interesting point is that CMUCL[2] was revealed[3] to be only available for 32-bit systems. However what got people really excited was[4] Rahul's question about what to do concerning the gNaughty package. Its sole purpose seemed[5] to be downloading pornography. Rahul referenced the hot-babe CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?"
Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised[6] by Muayyad AlSadi who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. Bill Nottingham was[7] skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was[8] the reaction typified by Seth Vidal which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. Mathieu Bridon thought[9] that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy.
Chrome9 Vx800 Graphics Support on LiveUSB
Kristaps Viesalgs asked[1] for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"
Adam Jackson asked[2] for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by Adam Williamson and [[User:|Xavier Bachelot]]. The latter asked[3] any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.
Who Wants a Pony?
Kushal Das promised[1] a pony to anyone that would take the trouble to review[2] one of his packages.
Firestarter Retired as Unportable to PolicyKit
Adam Miller asked[1] whether he should just retire the Firestarter[2] package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate Firestarter with PolicyKit. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok PolicyKit.
Following confirmation from Rahul Sundaram and Seth Vidal a decision was made[3] by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."
A further suggestion from "Cry" prompted[4] Adam to start filing RFEs against system-config-firewall for any features present in Firestarter but missing in system-config-firewall.
Russian Fedora ?
When Peter Lemenkov asked[1] about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. Kevin Kofler gave[2] an able summary why this would still present Red Hat with a problem.
An assertion by [[User:|Alexey Torkhov]] that there existed[3] a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from Rahul Sundaram.
Will FESCo Revisit Kmods ?
A discussion of why VirtualBox will not be a feature due to its code not yet heading upstream and consequently remaining as kmods drew a statement of support from Kevin Kofler for reverting the current banning of kmods should he become a FESCo member. Upon request from Richard W.M. Jones for a dispassionate summary of the reasons to avoid kmods drew[1] a concise response from Seth Vidal.
Adam Williamson and Matt Domsch (Dell's DKMS mastermind) kicked[2] some ideas back and forth over the advantages of akmods versus kmods.
Upgrade from Fedora 10 to Rawhide (Fedora 11)
Following a report from Uwe Kiewel that a
yum upgrade
had spewed all sorts of errors the supported methods for upgrades were re-stated[1] by Adam Williamson: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."
