From Fedora Project Wiki

< FWN‎ | Beats

m (give proper name of tool instead of showing way to access it)
(devel beat 172 pass 1, spellchecked, fasnames, wikinames)
Line 7: Line 7:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Emacs, Glibc, Malloc and i586 ===
=== Frozen for Fedora 11. Some Packages Still Not Built dist-f11 ===


As the pressure to stick to the <code>Fedora 11</code> release schedule built up some glitches arising in part from the decision to support i586 instead of i686 (see FWN#162<ref>http://fedoraproject.org/wiki/FWN/Issue162#Fedora_11_Will_Support_i586_Instruction_Set</ref>) led to tense words.
[[User:Jkeating|Jesse Keating]] announced<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00892.html</ref> that henceforth all F-11/ builds would go to dist-f11-updates-candidate and builds from devel/ would go to dist-f12. He asked for concerned parties to check that builds were being properly tagged.


Reports trickled in of problems with <code>emacs</code> in rawhide. [[PerBothner|Per Bothner]] reported<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg00221.html</ref> both that <code>emacs-23.0.91</code> threw an "Invalid regex: Unmatched ( or \\(" and that <code>emacs-23-0.92</code> was responding excruciatingly slowly. [[UlrichDrepper|Ulrich Drepper]] speculated<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg00225.html</ref> to that the regexp problem was due to some changes to <code>malloc</code> in <code>glibc</code>.  A bugzilla report by [[AndyWingo|Andy Wingo]] expanded<ref>http://bugzilla.redhat.com/show_bug.cgi?id=494631</ref> on the problem and drew comments suggesting that <code>rpm</code> and <code>mysql</code> were also failing to due <code>glibc</code> changes. [[JakubJelinek|Jakub Jelinek]] thought they were different problems with the <code>emacs</code> errors being due to <code>malloc_{get|set}_state</code>.
In response to [[User:Miketc302|Mike Chambers]]' question Jesse confirmed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00954.html</ref> that the nightly rawhide composes would consist of <code>Fedora 11</code> content until the GOLD packages were on their way out to the mirrors at which point the nightly rawhide composes would contain <code>Fedora 12</code> content.


[[TomLane|TomLane]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00572.html</ref> what was going on with <code>glibc</code> reverting to an earlier version in rawhide. [[User:Jkeating|Jesse Keating]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00573.html</ref> that <code>glibc</code> for the <code>i586</code> architecture was broken for all versions after beta. After [[PanuMatilainen|Panu Matilainen]] commented that <code>glibc.i586</code> was so broken that <code>rpm</code> could not even read its own configurations [[UlrichDrepper|Ulrich Drepper]] said<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00600.html</ref>: "If you want to complain then to the idiots who made the decision to go with .i586 instead of .i686 for x86 binaries.  This is exactly the kind of problem I've been warning about all along.  Using the i586 target stresses code paths (in this case in gcc) which are hardly ever used since nobody cares for this target in general." Panu disavowed any intent to complain.
On a related note [[User:Notting|Bill Nottingham]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01160.html</ref> maintainers of a list of packages not yet rebuilt in dist-f11 (with the attendant compiler and strong RPM hashes) to fix them if possible. [[User:Jkeating|Jesse Keating]] provided<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01189.html</ref> a slightly more aggressive list as an addendum.  
=== Xorg Hacking Solves DontZap ===


=== Wireless Regulatory Domain Automatically Determined ===
[[PeterHutterer|Peter Hutterer]] made some valuable contributions to resolving the furore over the disabling of the zapping of the Xorg server via the Ctrl-Alt-Backspace key combination<ref>http://fedoraproject.org/wiki/FWN/Issue171#Zap_DontZap</ref>.


[[User:Linville|John W. Linville]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00566.html</ref> an update to an old(ish) thread. He reported that <code>Fedora 11</code> now has <code>udev</code> rules in place to set wireless regulatory domains based on the configured timezone.
[[User:Spot|Tom Callaway]] drew attention<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00700.html</ref> to a blog entry of Peter's which mentioned upstream patches by Julien Cristau (of Debian) to <code>xkeyboard-config</code> and Peter's own patch<ref>http://lists.freedesktop.org/archives/xorg-devel/2009-April/000626.html</ref> to <code>Xserver</code> which together make it possible to disallow zapping by default and also to turn zapping on with a <pre>'setxkbmap -option terminate:ctrl_alt_bksp'</pre>. The net result is that it is possible to get zapping to work but the <code>XKB</code><ref>http://www.charvolant.org/~doug/xkb/html/index.html</ref> configuration needs to be set up properly and the DontZap option left disabled (as per the new default).  


=== Moonlight Still Banned in Fedora ===
In discussion with [[User:Kkofler|Kevin Kofler]] Peter clarified<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00861.html</ref> the situation in which the new settings would take effect. Kevin responded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00863.html</ref> that it appeared that for <code>KDE</code> users zapping with Ctrl-Alt-BkSp would remain as before.


The 2009-04-08 "Rawhide Report"<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00426.html</ref> caused some excitement when it seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00427.html</ref> that <code>moonlight</code><ref>Moonlight is an implementation<ref>http://mono-project.com/Moonlight</ref> of Microsoft's "Silverlight" which is a virtual machine and framework for creating Rich Internet Applications, roughly competing in the same space as Adobe's Flex<ref>http://www.adobe.com/products/flex/</ref> and Mozilla's Prism<ref>http://labs.mozilla.com/projects/prism/</ref>. It is considered<ref>http://fedoraproject.org/wiki/ForbiddenItems#Moonlight</ref> to risky to include in Fedora due to legal worries raised by the Microsoft-Novell covenant.  </ref> might have been enabled. It turned out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00500.html</ref> that this was simply due to a confusion between a <code>mono</code> API named "moonlight" and the actual <code>moonlight</code> itself.
Later Peter answered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00838.html</ref> some questions from [[User:Surenkarapetyan|Suren Karapetyan]] about the ability to kill broken X grabs with details about how zapping works.


All that had actually happened<ref>http://bugzilla.redhat.com/show_bug.cgi?id=492048</ref> was that Fedora Legal okayed the use of the mono compiler switch "moonlight" in order to facilitate RPMFusion's request.
The above summary of an elegant technical solution ignores the long, and at times vitriolic, complaints about this change. A common trope occurring in some recent threads seems to be that changes are made by Red Hat employees who are implementing changes without community consultation and all work to a common game plan. [[User:Skvidal|Seth Vidal]] challenged<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01059.html</ref> the latter assumption:"In a survey of 10 RH employees you will find between 10 and 40 different opinions. sometimes more if you don't ask some of them to confine their comments to a limited amount of time."  In any event it's worth noting that the resolution (which filters the "Terminate_Server" action in a manner consistent<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01173.html</ref> with the handling of other actions in xkb rulesets) was contributed upstream by a Red Hat employee. As a point of information [[User:Kevin |Kevin Fenzi]] also made it clear that the change had not been instigated by FESCo.


=== Mono Breakage on PPC May Cause Reversion ===
=== Minesweeper Certified Solitaire Professionals Satisfied with DVD ===


Another <code>mono</code> issue discussed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00457.html</ref> with reference to the 2009-04-08 Rawhide Report suggests that due to breakage on the <code>ppc</code> architecture it may be necessary to untag the latest mono package.  
[[User:Jkeating|Jesse Keating]] requested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00943.html</ref> help in selecting which packages should be dropped from the DVD image. He suggested some java development packages and games.  


Objections that the disabling of PPC architecture support on the <code>mono</code> package was happening too close to the <code>Fedora 11</code> final freeze prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00471.html</ref> [[User:Dnielsen|David Nielsen]] to make the rejoinder that no help had been given to the Mono SIG despite their reporting a problem. [[User:Jkeating|Jesse Keating]] announced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00483.html</ref> that in the absence of a fix before the final freeze <code>mono</code> would simply be downgraded: "[t]his kind of version change shouldn't really be made after beta anyway."
Feedback suggested that retaining the games was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00947.html</ref> preferred and dropping the development libraries made sense as the latest versions would be needed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00981.html</ref> and could be obtained from the repositories anyway. Jesse later posted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01037.html</ref> this was sufficient to achieve the desired image size.


[[User:Dnielsen|David Nielsen]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00501.html</ref> that the changes had been made well before the beta. [[User:Notting|Bill Nottingham]] thrust<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00515.html</ref> the responsibility back on him. [[User:Alexlan|Alex Lancaster]] made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00524.html</ref> a similar point more diplomatically.  
A side-issue discussed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01019.html</ref> was the unwieldiness of <code>jigdo</code> as a download method. [[CallumLerwick|Callum Lerwick]] suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01246.html</ref> that <code>jigdo</code> would benefit from a userspace ISO implementation.


[[User:Mef|Mary Ellen Foster]] requested, as a mono-dependent maintainer, that concrete actions be recommended. [[User:Jkeating|Jesse Keating]] and [[User:Toshio|Toshio Kuratomi]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00568.html</ref> that all such did _not_ set "ExcludeArch: ppc" and rebuild as this would cause massive churn on a large number of packages. Instead a process to track down the failures and fix them with a fallback plan to revert to a mono release-candidate was proposed by Toshio. 
=== Presto and DeltaRPM Status ===


The ability to download binary diffs of RPM packages has been offered<ref>http://fedoraproject.org/wiki/FWN/Issue97#Presto-digitation</ref> for some time now on Fedora through the <code>Presto</code><ref>https://fedorahosted.org/presto/</ref> project and presto-enabled repositories. Interest is high enough in Presto's bandwidth-saving abilities that no fewer than three separate threads were started to ensure that it would function properly for <code>Fedora 11</code>.


=== YUM Downgrade Feature Now in Rawhide ===
[[WarrenTogami|Warren Togami]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00701.html</ref> if <code>Presto</code> would be enabled by default for <code>Fedora 11</code>. Last month (2009-03-21) [[User:Jdieter|Jonathan Dieter]] reported<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg01910.html</ref> that the use of <code>SHA-256</code> in <code>rpm</code> had broken <code>deltarpm</code> but that a patched version was available in rawhide. See FWN#166<ref>http://fedoraproject.org/wiki/FWN/Issue166</ref> for earlier coverage of the challenges and changes resulting from the introduction of stronger hashes<ref>http://fedoraproject.org/wiki/Features/StrongerHashes</ref>. 
Jonathan also reported that the changes necessary in infrastructure to build deltarpms had been done. These changes were made fairly rapidly thanks to work done<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00528.html</ref> Michael Schroeder, the upstream <code>deltarpm</code> developer. One issue that concerned<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01236.html</ref> [[User:Athimm|Axel Thimm]] was the security with which checksums of deltarpms were being made. [[User:Till|Till Maas]] and [[User:Jdieter|Jonathan Dieter]] provided<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01240.html</ref> reassurance that all deltarpms are generated from original rpms which needed to pass all verifications which <code>yum</code> and <code>rpm</code> enforce.   


[[User:James|James Antill]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00469.html</ref> that it is now possible to downgrade a package using
[[User:Mso|Martin Sourada]] was excited<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01262.html</ref> not just about <code>Presto</code> but also about the slick new <code>PackageKit</code> in <code>Fedora 11</code>. Martin was concerned about the issue of <code>PackageKit</code> and <code>Presto</code> apparently not working well together. A bugzilla entry revealed<ref>https://bugzilla.redhat.com/show_bug.cgi?id=496445</ref> that <code>PackageKit</code> developer [[User:|Richard Hughes]] quickly created a patch which Martin reported as working.
<pre>yum downgrade <packagename></pre>


He suggested: "[...]this will be most useful for rawhide users when installing test packages from koji static repos. etc. ... because then an older version will still be available in rawhide. Whereas if you upgrade to what is in rawhide there is nothing older available to downgrade to."  
On 2009-04-16 [[User:Notting|Bill Nottingham]] added to the "Rawhide Report" that "[...] rawhide is composed with deltarpms against the prior rawhide. Due to a bug, this is only currently working on i386; it should be fixed for other arches tomorrow. Please test and report any issues."  


=== Multiple Package Ownership of Directories ===
A Fedora Test Day centering around Presto was also announced<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00939.html</ref> by [[User:|James Laska]]. The usual excellent wikipage<ref>https://fedoraproject.org/wiki/Test_Day:Presto_2009-04-16</ref> suggests that <code>Presto</code> can deliver significant bandwidth savings. 


A query posed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00425.html</ref> by [[User:Sundaram|Rahul Sundaram]] concerned whether it was appropriate for multiple packages to claim ownership of a directory.
=== Browser Plugins May Strip SELinux Protections ===


[[User:Mschwendt|Michael Schwendt]] and [[User:Cwickert|Christoph Wickert]] were<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00544.html</ref> clear that the packages Rahul mentioned should not own the directory because they were part of a dependency chain which led up to their ancestor package <code>hicolor-icon-theme</code>. Contrary advice led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00546.html</ref> to some sarcasm from [[User:Cwickert|Christoph Wickert]] about Red Hat employees not being familiar with Fedora packaging guidelines and it worried<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00591.html</ref> [[User:Peter|Peter Lemenkov]], who believed that Red Hat employees all had "provenpackager" status (see FWN#170<ref>http://fedoraproject.org/wiki/FWN/Issue170#Provenpackager_Policies</ref>). [[User:Tibbs|Jason L. Tibbitts III]] corrected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00595.html</ref> this latter assertion.
[[DanielWalsh|Daniel Walsh]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01107.html</ref> why <code>mozplugger</code><ref>Mozplugger describes itself as "[a] general purpose Mozilla plugin module that allows the user to embed and launch their favorite application to handle the various different types of media found on the Internet." http://mozplugger.mozdev.org/</ref> was being installed by default. He cautioned that <code>mozplugger</code> broke <code>nsplugin</code> and thus <code>SELinux</code> functionality.


=== Zap DontZap ===
An answer posted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01111.html</ref> by [[User:Notting|Bill Nottingham]] pointed out the java plugin as the dependent.


[[PaulWouters|Paul Wouters]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00363.html</ref> that he had needed to <code>ssh</code> into his machine to fix an X session problem and would like to revert "[...] to the old behavior of having ctrl-alt-backspace kill the current X session." See FWN#169<ref>http://fedoraproject.org/wiki/FWN/Issue169#Emacs_Cabal_Disables_Xorg_Ctrl-Alt-Backspace</ref> for earlier discussion.
Dan worried that while "[a] confined nsplugin is a nice feature for confining plugins downloaded from the network. But if you run openoffice and evince from within nsplugin they get confined, causing the apps to not work properly." In response to [[User:Simo|Simo Sorce]] Dan explained that any attempt to write transition rules to enable said applications to work properly would create an easy avenue of attack. Simo wondered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01115.html</ref> if it would be possible to either write a security wrapper to restrict the command line, or to get application developers to honor SELinux labels in some way.


[[AndersRayner-Karlsson|Anders Rayner-Karlsson]] explained that dual-head setup in <code>Fedora 10</code> was as simple as:
[[WarrenTogami|Warren Togami]] shared<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01117.html</ref> that removing <code>mozplugger</code> was "[...] something I always do. It seems to cause more problems than it solves [...]" and [[JamesMorris|James Morris]] expanded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01226.html</ref> upon this with instructions "[...] on both removing mozplugger and restoring the security protections of SELinux.  Simply removing the package isn't enough[.]" James questioned "[...] how a package which breaks a security feature not only made it into the repo, but how it became enabled by default[?]"


<pre>xrandr --output LVDS --auto --output VGA --auto --above LVDS</pre>
A similar issue was raised<ref>https://bugzilla.redhat.com/show_bug.cgi?id=491543</ref> by [[User:Bruno|Bruno Wolff III]] about the re-enabling of disabled ''Firefox'' plugins. Comments by [[MartinStransky|Martin Stransky]] suggest this is a feature of <code>mozilla-plugin-config</code>.


to which [[User:Mooninite|Michael Cronenworth]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00371.html</ref> that this would need to be done in a start-up script as there was also now no <code>xorg.conf</code> by default. [[User:Jkeating|Jesse Keating]] suggested using the <code>system-config-display</code> tool instead as this would obviate the need for an <code>xorg.conf</code>. [[AdamJackson|Adam Jackson]] cautioned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00377.html</ref> that nVidia's proprietary drivers might not export RANDR-1.2 yet and thus the latter might not work. Further discussions about whether <code>xorg.conf</code> was needed for side-by-side wide virtual desktops suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00430.html</ref> that Intel chipsets while currently enforcing a 2048 pixel limit may be<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00450.html</ref> capable of supporting up to 4096 pixels on <code>Intel 915</code> or <code>Intel 945</code> in the near future.
=== Getting Rid of /usr for Fedora 12 ===


Dissent and discussion about Fedora's decision to follow the upstream rumbled on. [[User:Kkofler|Kevin Kofler]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00617.html</ref> that "mailing list consensus" was not a good process by which to make such decisions as that taken by Xorg. [[DaveAirlie|Dave Airlie]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00635.html</ref> as though he had had enough of personal attacks on him, but was also able to joke about it.
[[LennartPoettering|Lennart Poettering]] cheerfully invited<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01063.html</ref> any inclined parties to a flamefest over the elimination of the /usr directory. Lennart suggested that recent history indicated that more files were being moved from /usr to / and that confusion between the two was a source of error from some packages.
 
Enthusiasm for both the flamewar and the proposal was low.
 
A forceful and well-argued objection was made<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01064.html</ref><ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01076.html</ref> by [[KonstantinRyabitsev|Konstantin Ryabitsev]] on the basis that he liked to keep /boot and /usr on their own partitions and use a LUKS-encrypted LVM for everything else. Konstantin emphasized this was especially well-suited to portable machines which need to conserve power and are more likely to need encryption.
 
[[RalfCorsepius|Ralf Corsepius]] invoked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01077.html</ref> the FHS<ref>http://www.pathname.com/fhs/</ref> on /usr and the need to contain<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01105.html</ref> non-essential packages unavailable at certain boot stages therein. [[ChrisAdams|Chris Adams]] added<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01101.html</ref> that symlinking /usr to / had been shown to break <code>rpm</code>.
 
Lennart explained<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01198.html</ref> how /etc could be made read-only and adduced<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01208.html</ref> OpenSUSE, Debian and Gentoo as further evidence that a read-only root could be attained. [[CallumLerwick|Callum Lerwick]] pined<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01300.html</ref> for the days of floppy disks.
 
[[User:Toshio|Toshio Kuratomi]] completely declined to play and asked: "I'm hereby giving notice that I don't have time to read obvious flamefests anymore.  Once this thread concludes, please summarize whatever the pros and cons are and send it to the packaging committee to discuss and vote on."

Revision as of 01:53, 20 April 2009

Developments

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

Contributing Writer: Oisin Feeley

Frozen for Fedora 11. Some Packages Still Not Built dist-f11

Jesse Keating announced[1] that henceforth all F-11/ builds would go to dist-f11-updates-candidate and builds from devel/ would go to dist-f12. He asked for concerned parties to check that builds were being properly tagged.

In response to Mike Chambers' question Jesse confirmed[2] that the nightly rawhide composes would consist of Fedora 11 content until the GOLD packages were on their way out to the mirrors at which point the nightly rawhide composes would contain Fedora 12 content.

On a related note Bill Nottingham asked[3] maintainers of a list of packages not yet rebuilt in dist-f11 (with the attendant compiler and strong RPM hashes) to fix them if possible. Jesse Keating provided[4] a slightly more aggressive list as an addendum.

Xorg Hacking Solves DontZap

Peter Hutterer made some valuable contributions to resolving the furore over the disabling of the zapping of the Xorg server via the Ctrl-Alt-Backspace key combination[5].

Tom Callaway drew attention[6] to a blog entry of Peter's which mentioned upstream patches by Julien Cristau (of Debian) to xkeyboard-config and Peter's own patch[7] to Xserver which together make it possible to disallow zapping by default and also to turn zapping on with a

'setxkbmap -option terminate:ctrl_alt_bksp'

. The net result is that it is possible to get zapping to work but the XKB[8] configuration needs to be set up properly and the DontZap option left disabled (as per the new default).

In discussion with Kevin Kofler Peter clarified[9] the situation in which the new settings would take effect. Kevin responded[10] that it appeared that for KDE users zapping with Ctrl-Alt-BkSp would remain as before.

Later Peter answered[11] some questions from Suren Karapetyan about the ability to kill broken X grabs with details about how zapping works.

The above summary of an elegant technical solution ignores the long, and at times vitriolic, complaints about this change. A common trope occurring in some recent threads seems to be that changes are made by Red Hat employees who are implementing changes without community consultation and all work to a common game plan. Seth Vidal challenged[12] the latter assumption:"In a survey of 10 RH employees you will find between 10 and 40 different opinions. sometimes more if you don't ask some of them to confine their comments to a limited amount of time." In any event it's worth noting that the resolution (which filters the "Terminate_Server" action in a manner consistent[13] with the handling of other actions in xkb rulesets) was contributed upstream by a Red Hat employee. As a point of information Kevin Fenzi also made it clear that the change had not been instigated by FESCo.

Minesweeper Certified Solitaire Professionals Satisfied with DVD

Jesse Keating requested[14] help in selecting which packages should be dropped from the DVD image. He suggested some java development packages and games.

Feedback suggested that retaining the games was[15] preferred and dropping the development libraries made sense as the latest versions would be needed[16] and could be obtained from the repositories anyway. Jesse later posted[17] this was sufficient to achieve the desired image size.

A side-issue discussed[18] was the unwieldiness of jigdo as a download method. Callum Lerwick suggested[19] that jigdo would benefit from a userspace ISO implementation.

Presto and DeltaRPM Status

The ability to download binary diffs of RPM packages has been offered[20] for some time now on Fedora through the Presto[21] project and presto-enabled repositories. Interest is high enough in Presto's bandwidth-saving abilities that no fewer than three separate threads were started to ensure that it would function properly for Fedora 11.

Warren Togami asked[22] if Presto would be enabled by default for Fedora 11. Last month (2009-03-21) Jonathan Dieter reported[23] that the use of SHA-256 in rpm had broken deltarpm but that a patched version was available in rawhide. See FWN#166[24] for earlier coverage of the challenges and changes resulting from the introduction of stronger hashes[25]. Jonathan also reported that the changes necessary in infrastructure to build deltarpms had been done. These changes were made fairly rapidly thanks to work done[26] Michael Schroeder, the upstream deltarpm developer. One issue that concerned[27] Axel Thimm was the security with which checksums of deltarpms were being made. Till Maas and Jonathan Dieter provided[28] reassurance that all deltarpms are generated from original rpms which needed to pass all verifications which yum and rpm enforce.

Martin Sourada was excited[29] not just about Presto but also about the slick new PackageKit in Fedora 11. Martin was concerned about the issue of PackageKit and Presto apparently not working well together. A bugzilla entry revealed[30] that PackageKit developer [[User:|Richard Hughes]] quickly created a patch which Martin reported as working.

On 2009-04-16 Bill Nottingham added to the "Rawhide Report" that "[...] rawhide is composed with deltarpms against the prior rawhide. Due to a bug, this is only currently working on i386; it should be fixed for other arches tomorrow. Please test and report any issues."

A Fedora Test Day centering around Presto was also announced[31] by [[User:|James Laska]]. The usual excellent wikipage[32] suggests that Presto can deliver significant bandwidth savings.

Browser Plugins May Strip SELinux Protections

Daniel Walsh asked[33] why mozplugger[34] was being installed by default. He cautioned that mozplugger broke nsplugin and thus SELinux functionality.

An answer posted[35] by Bill Nottingham pointed out the java plugin as the dependent.

Dan worried that while "[a] confined nsplugin is a nice feature for confining plugins downloaded from the network. But if you run openoffice and evince from within nsplugin they get confined, causing the apps to not work properly." In response to Simo Sorce Dan explained that any attempt to write transition rules to enable said applications to work properly would create an easy avenue of attack. Simo wondered[36] if it would be possible to either write a security wrapper to restrict the command line, or to get application developers to honor SELinux labels in some way.

Warren Togami shared[37] that removing mozplugger was "[...] something I always do. It seems to cause more problems than it solves [...]" and James Morris expanded[38] upon this with instructions "[...] on both removing mozplugger and restoring the security protections of SELinux. Simply removing the package isn't enough[.]" James questioned "[...] how a package which breaks a security feature not only made it into the repo, but how it became enabled by default[?]"

A similar issue was raised[39] by Bruno Wolff III about the re-enabling of disabled Firefox plugins. Comments by Martin Stransky suggest this is a feature of mozilla-plugin-config.

Getting Rid of /usr for Fedora 12

Lennart Poettering cheerfully invited[40] any inclined parties to a flamefest over the elimination of the /usr directory. Lennart suggested that recent history indicated that more files were being moved from /usr to / and that confusion between the two was a source of error from some packages.

Enthusiasm for both the flamewar and the proposal was low.

A forceful and well-argued objection was made[41][42] by Konstantin Ryabitsev on the basis that he liked to keep /boot and /usr on their own partitions and use a LUKS-encrypted LVM for everything else. Konstantin emphasized this was especially well-suited to portable machines which need to conserve power and are more likely to need encryption.

Ralf Corsepius invoked[43] the FHS[44] on /usr and the need to contain[45] non-essential packages unavailable at certain boot stages therein. Chris Adams added[46] that symlinking /usr to / had been shown to break rpm.

Lennart explained[47] how /etc could be made read-only and adduced[48] OpenSUSE, Debian and Gentoo as further evidence that a read-only root could be attained. Callum Lerwick pined[49] for the days of floppy disks.

Toshio Kuratomi completely declined to play and asked: "I'm hereby giving notice that I don't have time to read obvious flamefests anymore. Once this thread concludes, please summarize whatever the pros and cons are and send it to the packaging committee to discuss and vote on."

  1. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00892.html
  2. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00954.html
  3. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01160.html
  4. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01189.html
  5. http://fedoraproject.org/wiki/FWN/Issue171#Zap_DontZap
  6. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00700.html
  7. http://lists.freedesktop.org/archives/xorg-devel/2009-April/000626.html
  8. http://www.charvolant.org/~doug/xkb/html/index.html
  9. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00861.html
  10. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00863.html
  11. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00838.html
  12. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01059.html
  13. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01173.html
  14. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00943.html
  15. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00947.html
  16. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00981.html
  17. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01037.html
  18. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01019.html
  19. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01246.html
  20. http://fedoraproject.org/wiki/FWN/Issue97#Presto-digitation
  21. https://fedorahosted.org/presto/
  22. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00701.html
  23. https://www.redhat.com/archives/fedora-devel-list/2009-March/msg01910.html
  24. http://fedoraproject.org/wiki/FWN/Issue166
  25. http://fedoraproject.org/wiki/Features/StrongerHashes
  26. https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00528.html
  27. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01236.html
  28. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01240.html
  29. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01262.html
  30. https://bugzilla.redhat.com/show_bug.cgi?id=496445
  31. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00939.html
  32. https://fedoraproject.org/wiki/Test_Day:Presto_2009-04-16
  33. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01107.html
  34. Mozplugger describes itself as "[a] general purpose Mozilla plugin module that allows the user to embed and launch their favorite application to handle the various different types of media found on the Internet." http://mozplugger.mozdev.org/
  35. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01111.html
  36. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01115.html
  37. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01117.html
  38. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01226.html
  39. https://bugzilla.redhat.com/show_bug.cgi?id=491543
  40. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01063.html
  41. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01064.html
  42. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01076.html
  43. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01077.html
  44. http://www.pathname.com/fhs/
  45. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01105.html
  46. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01101.html
  47. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01198.html
  48. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01208.html
  49. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01300.html