From Fedora Project Wiki

< FWN‎ | Beats
(175 pass1)
Line 7: Line 7:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Fedora 11 Preview Xorg "Lock-up" ===
=== Presto A-Go-Go ! ===


[[AndyLawrence|DrDiesel]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02425.html</ref> an Xorg lockup with a fully updated <code>Fedora 11 Preview</code> on 2009-04-28 whenever he visited a particular webpage. Subsequent confirmation from other testers led<ref>http://bugzilla.redhat.com/show_bug.cgi?id=498131</ref> to a bugzilla report. It intially appeared to be a soft lock according to some comments on the bug which reported the ability to move the mouse cursor and play music.  
Thanks to some hard work by Fedora Infrastructure folk [[User:Lmacken|Luke Macken]], [[User:Skvidal|Seth Vidal]], [[User:Notting|Bill Nottingham]] and [[User:Jwboyer|Josh Boyer]] <code>Fedora 11</code> will<ref>http://jwboyer.livejournal.com/31831.html</ref> come Presto-enabled contrary to last week's gloomy forecast<ref>http://fedoraproject.org/wiki/FWN/LatestIssue#Presto_No_Go</ref>.  


Some very helpful contributions from [[AdamJackson|Adam Jackson]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02452.html</ref> that the problem was due to a ridiculously large blit<ref>http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork#head-e39a838dc80e85fcd06dda71ffef534a5526444d-2</ref> exposing mis-handling of video memory mapping by the kernel. Adam laid<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02487.html</ref> the blame squarely on the mis-coding of the web-page. He added that this was not actually a lock-up, just agonizingly slow rendering. RichardKörber requested further help in debugging this and similar problems and that request led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02468.html</ref> to a nice, succinct recipe for generating <code>gdb</code> backtraces.
[[User:Pfrields|Paul W. Frields]] described the potential saved download bandwidth as "[t]ypically [...] in double digits, but I’ve heard of cases already (using our development branch Rawhide) where people were saving 90% or more of their download time."


<references/>
<references/>


=== Presto No Go ===
=== PPC as a Secondary Architecture ===


Unfortunately it appears that <code>Presto</code>, the near miraculous bandwidth saving <code>YUM</code> plugin<ref>http://fedoraproject.org/wiki/Releases/FeaturePresto</ref>, will not be an official part of <code>Fedora 11</code> due to infrastructure issues cited<ref>http://paul.frields.org/?p=1611</ref> by [[User:Pfrields|Paul W. Frields]]. This is contrary to what we reported<ref>http://fedoraproject.org/wiki/FWN/Issue172#Presto_and_DeltaRPM_Status</ref> in FWN#172.
The 2009-05-07 FESCo summary reported<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00581.html</ref> that there is interest in moving PowerPC to secondary architecture status. [[DavidWoodhouse|David Woodhouse]] suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00614.html</ref> that it would be interesting to hear from existing secondary architecture teams on the problems they had experienced. To date there are no secondary architectures ready to ship in Fedora.


<references/>
<references/>


=== Fedora 12 Changes to GConf and intltool ===
=== Retiring Packages ===


[[User:Mclasen|Matthias Clasen]] requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02386.html</ref> feedback on changes in the way sechma translations were handled in <code>GConf</code> and <code>intltool</code>: ly, translations were merged by intltool from .po files into schemas files and then copied by gconftool from the schemas file into the database.  Now, translations are kept in .po files, and intltool only copies the gettext domain into the schemas, and further into the GConf database.  The only tool that ever uses these translations, gconf-editor, knows how to get them from the message catalogs.  The big advantage of this change is that schemas shrink radically, which should help a lot with the 'slow updates due to GConf' problem. It also reduces the redundancy of storing the schema translations in three places, which should help with live cd size."
The decision of the 2009-05-07 FESCo meeting to orphan packages from de-activated maintainers led<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00596.html</ref> [[User:Toshio|Toshio Kuratomi]] to advertise that <code>PackageDB</code> will soon be able to retire packages.
 
It seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02396.html</ref> that all GConf-using applications will be rebuilt before <code>Fedora 12</code> ships but that there is no immediate rush to do so.


<references/>
<references/>


=== Ext4 fallocate() Happiness ===
=== RawERhide ? ===
 
[[EricSandeen|Eric Sandeen] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02259.html</ref> that it would be useful to speed the adoption of the preallocation features of the <code>ext4</code> filesystem. (See FWN#170<ref>http://fedoraproject.org/wiki/FWN/Issue170#fallocate.282.29_Preferred_Glibc_Interface_for_Preallocation_.3F</ref> for previous coverage.) Eric provided a concise, informative description of what preallocation is and how it can be used: "One big feature that has already been brought up on the list[1] is file preallocation, which allows an application to pre-allocate blocks it knows that it will eventually write into, thereby making sure it won't run out of space, and also generally getting a more efficient/contiguous file layout.  Only a few applications are taking advantage of this so far, in part because it's new.[2]  The transmission bittorrent client is using it, but only if you tweak a configfile in (IMHO) non-obvious ways."
 
A list of possible starting points to get more applications using preallocation was also provided.
 
In response to some skepticism from [[TomLane|Tom Lane]] further explanation of which sorts of applications might benefit from preallocation was shared<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02281.html</ref> by Eric: "You wouldn't want to use it for every little file you write, either.  But for some cases it can be a big win.  Torrent downloading?  This is sort of the quintessential case where it can help.  Databases?  yes.  Rsyncing large files?  yep.  Creating virtual images? yep.  Helping samba cope with weird windows client behavior?  yep Basically anything that is filled in over time, or filled in sparsely, could potentially benefit." Further questioning by [[MichaelCronenworth|Michael Cronenworth]] on the value of using <code>ext4</code> as opposed to <code>xfs</code> yielded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02309.html</ref> further interesting details.
 
It seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02285.html</ref> that the <code>libvirt</code> developers had already jumped at the opportunity thanks to a patch provided<ref>http://www.amitshah.net/2009/03/comparison-of-file-systems-and-speeding.html</ref> by Amit Shah.


<references/>
[[User:Jkeating|Jesse Keating]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00359.html</ref>: "How is it we have 182 stable updates pending for F11 already?  How have these seen any testing by a wider audience?  Are we really just not bothering with updates-testing anymore?  Do we not care about distro stability?" An interesting thread discussed the ways in which developer workflow and the availability of updates for testing can be re-aligned to each other. Among the complications discussed were the need to provide a way to upgrade for a previous release and the coupling of DVD image preparation with a release.


=== NetworkManager in Fedora 11 Preview ===
[[User:Till|Till Maas]] replied that updates-testing requests for <code>Fedora 11</code> had apparently not been processed and [[User:Kkofler|Kevin Kofler]] argued<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00573.html</ref> that the chances were high that packages which built succesfully on an earlier release would build on a later one. This was disputed by [[User:Jkeating|Jesse Keating]]. [[User:Dcantrel|David Cantrell]] and [[User:Skvidal|Seth Vidal]] shared<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00382.html</ref> their experience of users not responding to requests to test and comment on updates provided in <code>Bodhi</code>.


MarkBidewell wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02457.html</ref> why his sole network interface was inactivated automatically following a fresh install of <code>Fedora 11 Preview</code>.
A debate over the problems caused between the mismatch between the rolling, continuous nature of development and the need to freeze packages in a known state to produce a release received substantial contributions from [[RalfCorsepius|Ralf Corsepius]], who argued<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00435.html</ref> that Release-Engineering should change the workflow considerably. [[User:Jkeating|Jesse Keating]] responded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00469.html</ref> with a defense of the current system which emphasized the need of maintainers to adhere to the current workflow and "good development practices."


DanWilliams explained<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02461.html</ref> that this was a logical result of <code>anaconda</code> writing either <pre>"ONBOOT=no"</pre> if the install was not over a network or else <pre>"ONBOOT=yes"</pre> if the install was over a network. Dan explained that this was in part a security policy decision.  
[[RichardJones|Richard W.M. Jones]] was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00398.html</ref> in favor of rolling releases.


Later Dan suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02484.html</ref> using <code>nm-connection-editor</code> to correctly <pre>/etc/sysconfig/network-scripts/ifcfg-*</pre> for both wired and wireless connections.
[[User:Mschwendt|Michael Schwendt]] explained<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00554.html</ref> the problems arising when the <code>updates-testing</code> repository was not used as intended.


<references/>
[[MichalHlavinka|Michal Hlavinka]] proposed<ref></ref> breaking the freeze solely for the updates-testing repository shortly before the GA release.


=== Moblin2 Mostly Fedora-derived ? ===
There's a lot more in this thread beyond the ability of your correspondent to summarize adequately. It's worth a read for anyone trying to understand how and why Fedora is produced.
 
[[MatthewGarrett|Matthew Garrett]] picked up<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00157.html</ref> on an older discussion about the extent to which <code>Moblin2</code> could be considered a derivative of Fedora. Matthew's conclusion was that most of the packages were "[...] identical to the Fedora package or is a simple mechanical transformation of a Fedora package[.]" A significant number of the patches were mostly derived from Fedora or SuSE also.


<references/>
<references/>
=== Crypto Consolidation ===


=== Fedora 12: How to use DBUS for Terminal Sessions ? ===
[[AdamGoode|Adam Goode]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00349.html</ref> whether <code>NSS</code> was ready to provide <code>TLS</code> support. Adam referenced the Crypto Consolidation project<ref>http://fedoraproject.org/wiki/FedoraCryptoConsolidation</ref> (see also FWN#107<ref>http://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation</ref>).


[[DanWalsh|Dan Walsh]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00030.html</ref> for help in running a dbus session upon login to terminals so that he could run <code>restorecond</code> as a system service rather than a user service: "I want to run it under the Users UID and under with the users context.  Then I can have it watch for creation of files in the users home directory and be the equivalent of running restorecon ~/ by the user."
[[Dwinship|Dan Winship]] confirmed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00370.html</ref> that for the present <code>NSS</code> was best used directly with applications rather than by other libraries. [[RobertRelyea|Robert Relyea]] provided<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00493.html</ref> a detailed response to Adam including the hopeful sounding news that some of the issues around <code>NSS_Init</code> may be fixed in a few months.
 
[[SteveGrubb|Steve Grubb]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00066.html</ref> worried that this would disrupt the audit trail and suggested a <code>PAM</code> session module instead. [[User:Bwolf|Bruno Wolff III]] also was disturbed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00068.html</ref> by the idea: "This seems to increase the risk of hostile apps being able to get executables relabelled to something they couldn't do directly."


<references/>
<references/>


=== PulseAudio Flamewar Continues ===
=== Intel Moblin Pushing Proprietary Poulsbo ? ===
 
The fallout from last week's thermonuclear flamewar continued<ref>http://fedoraproject.org/wiki/FWN/Issue173#PulseAudio:_A_Hearty_and_Robust_Exchange_of_Ideas</ref> to splatter downwards. Among the hotspots were: a thread in which [[User:Jgudmundsson|Johan B. Gudmundsson]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02198.html</ref> some way in which there would be no privileged default desktop spin;


[[User:Notting|Bill Nottingham]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00035.html</ref> that slamming the PulseAudio team for closing bugs WONTFIX was inaccurate.
Last week's thread<ref>http://fedoraproject.org/wiki/FWN/LatestIssue#Moblin2_Mostly_Fedora-derived_.3F</ref> about the significant amount of Fedora-originating code being rolled into Intel's <code>Moblin2</code> platform without much kudos or thanks continued. Questions were asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00212.html</ref> about why Intel was not providing code for the <code>Poulsbo</code> graphics chipset (common in many netbooks) except via obscure repositories.  The appearance of ex-Red Hatter [[ArjanvandeVen|Arjan van de Ven]], who argued in defense of binary blobs in these drivers, occasioned<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00248.html</ref> some wry commentary.


It seems that perhaps <code>pavucontrol</code> may be one way to change the relative volume of individual applications (as per a question posed my [[MatthewWoehlke|Matthew Woehlke]] and echoed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00094.html</ref> by [[User:Pfrields|Paul W. Frields]]. [[LennartPoettering|Lennart Poettering]] stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg00099.html</ref>, however, that <code>pavucontrol</code> should be removed.
When [[User:Adamwill|Adam Williamson]] pointed to a "huge new pile of crack [...] in the Ubuntu Mobile special-sauce repositories [...]" [[DanWiliams|Dan Williams]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00326.html</ref>: "What makes the Poulsbo team so special that they are exempt from the upstreaming policy that every other part of Intel seems to follow so well these days?" Later discussion suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00491.html</ref> that it ought to at least be possible to produce a "[...] basic native accelerated 2D driver which doesn't depend on all the horrible proprietary crack [.]"


<references/>
<references/>

Revision as of 15:46, 11 May 2009

Developments

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

Contributing Writer: Oisin Feeley

Presto A-Go-Go !

Thanks to some hard work by Fedora Infrastructure folk Luke Macken, Seth Vidal, Bill Nottingham and Josh Boyer Fedora 11 will[1] come Presto-enabled contrary to last week's gloomy forecast[2].

Paul W. Frields described the potential saved download bandwidth as "[t]ypically [...] in double digits, but I’ve heard of cases already (using our development branch Rawhide) where people were saving 90% or more of their download time."

  1. ↑ http://jwboyer.livejournal.com/31831.html
  2. ↑ http://fedoraproject.org/wiki/FWN/LatestIssue#Presto_No_Go

PPC as a Secondary Architecture

The 2009-05-07 FESCo summary reported[1] that there is interest in moving PowerPC to secondary architecture status. David Woodhouse suggested[2] that it would be interesting to hear from existing secondary architecture teams on the problems they had experienced. To date there are no secondary architectures ready to ship in Fedora.

  1. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00581.html
  2. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00614.html

Retiring Packages

The decision of the 2009-05-07 FESCo meeting to orphan packages from de-activated maintainers led[1] Toshio Kuratomi to advertise that PackageDB will soon be able to retire packages.

  1. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00596.html

RawERhide ?

Jesse Keating asked[1]: "How is it we have 182 stable updates pending for F11 already? How have these seen any testing by a wider audience? Are we really just not bothering with updates-testing anymore? Do we not care about distro stability?" An interesting thread discussed the ways in which developer workflow and the availability of updates for testing can be re-aligned to each other. Among the complications discussed were the need to provide a way to upgrade for a previous release and the coupling of DVD image preparation with a release.

Till Maas replied that updates-testing requests for Fedora 11 had apparently not been processed and Kevin Kofler argued[2] that the chances were high that packages which built succesfully on an earlier release would build on a later one. This was disputed by Jesse Keating. David Cantrell and Seth Vidal shared[3] their experience of users not responding to requests to test and comment on updates provided in Bodhi.

A debate over the problems caused between the mismatch between the rolling, continuous nature of development and the need to freeze packages in a known state to produce a release received substantial contributions from Ralf Corsepius, who argued[4] that Release-Engineering should change the workflow considerably. Jesse Keating responded[5] with a defense of the current system which emphasized the need of maintainers to adhere to the current workflow and "good development practices."

Richard W.M. Jones was[6] in favor of rolling releases.

Michael Schwendt explained[7] the problems arising when the updates-testing repository was not used as intended.

Michal Hlavinka proposedCite error: Invalid <ref> tag; refs with no name must have content breaking the freeze solely for the updates-testing repository shortly before the GA release.

There's a lot more in this thread beyond the ability of your correspondent to summarize adequately. It's worth a read for anyone trying to understand how and why Fedora is produced.

  1. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00359.html
  2. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00573.html
  3. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00382.html
  4. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00435.html
  5. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00469.html
  6. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00398.html
  7. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00554.html

Crypto Consolidation

Adam Goode asked[1] whether NSS was ready to provide TLS support. Adam referenced the Crypto Consolidation project[2] (see also FWN#107[3]).

Dan Winship confirmed[4] that for the present NSS was best used directly with applications rather than by other libraries. Robert Relyea provided[5] a detailed response to Adam including the hopeful sounding news that some of the issues around NSS_Init may be fixed in a few months.

  1. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00349.html
  2. ↑ http://fedoraproject.org/wiki/FedoraCryptoConsolidation
  3. ↑ http://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation
  4. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00370.html
  5. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00493.html

Intel Moblin Pushing Proprietary Poulsbo ?

Last week's thread[1] about the significant amount of Fedora-originating code being rolled into Intel's Moblin2 platform without much kudos or thanks continued. Questions were asked[2] about why Intel was not providing code for the Poulsbo graphics chipset (common in many netbooks) except via obscure repositories. The appearance of ex-Red Hatter Arjan van de Ven, who argued in defense of binary blobs in these drivers, occasioned[3] some wry commentary.

When Adam Williamson pointed to a "huge new pile of crack [...] in the Ubuntu Mobile special-sauce repositories [...]" Dan Williams asked[4]: "What makes the Poulsbo team so special that they are exempt from the upstreaming policy that every other part of Intel seems to follow so well these days?" Later discussion suggested[5] that it ought to at least be possible to produce a "[...] basic native accelerated 2D driver which doesn't depend on all the horrible proprietary crack [.]"

  1. ↑ http://fedoraproject.org/wiki/FWN/LatestIssue#Moblin2_Mostly_Fedora-derived_.3F
  2. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00212.html
  3. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00248.html
  4. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00326.html
  5. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg00491.html
Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=100995"