FWN/Beats/Developments: Difference between revisions

Revision as of 19:04, 5 April 2009

Developments

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

Contributing Writer: Oisin Feeley

Noarch with pkconfig Files

PeterRobinson asked^[1] for help building his <package>gupnp-vala</package> package as noarch. The complication was that it contained a pkgconfig file.

Several helpful responses, such as MichaelSchwendt's^[2] suggested installing pkgconfig files into /usr/share/pkgconfig instead of one of the /usr/lib directories. ToshioKuratomi thoughtCite error: Invalid <ref> tag; refs with no name must have content

VilleSkyttä ran^[3] the rpmlint check and confirmed that it warned exactly of this misuse of a libdir macro.

In response to a subsidiary question JesseKeating explained^[4] that the noarch packages merely appeared to be present in each of the different architecture trees because they were hardlinked.

Fedora and OpenSolaris Dualboot Issue Solved

After AhmedKamal reported^[5] that a ZFS formatted partition seemed to be causing a Fedora 11 Beta installation failure there was a quick response. EricSandeen noted^[6] that a patch had already been produced^[7] by DaveLehman to merely log the problem instead of raising an error. The bugzilla entry suggested^[8] that the root problem was due to udev failing to recognize ZFS properly.

fallocate(2) Preferred Glibc Interface for Preallocation ?

JamesRalson noted^[9] the adoption of the ext4 filesystem in Fedora 11 and suggested that in order to use its preallocation features more efficiently it would be useful to patch applications. This could help avoid the current "double write" penalty currently incurred^[10] by preallocation in which the reserved space is first filled with nulls. James wondered whether there was a better interface to do this than glibc's posix_fallocate() which first attempts the allocation and then falls "[...] back to writing nulls to fill up the requested range if fallocate() fails."

EricSandeen suggested^[11] using fallocate(2) which is present in the glibc version in rawhide and provided a test program to investigate how well this would work.

Rawhide Report Glitches Resolved

After a few "Rawhide Reports" were missed AlexLancaster askedCite error: Invalid <ref> tag; refs with no name must have content what was going on. JoshBoyer answered^[12] that pungi for i386 was failing.

Rawhide Reports resumed^[13] on 2009-04-04.

XULRunner Committable by non-Provenpackagers

The summary of the 2009-04-03 FESCo meeting indicated^[14] that "Firefox/Thunderbird/XULRunner" are open for commits by those who do not have "provenpackager" status. Also discussed and declined for such changes were: popt; initscripts; ethtool; lvm-related packages; and hwdata.

JonStanley also noted^[15] that he was going to shoulder the burden of providing his excellent summaries of FESCo meetings.

Provenpackager Policies

Also discussed in the 2009-04-04 FESCo meeting were several requests for "provenpackager" and "sponsor" status. This followed^[16] on the heels of work done by PatriceDumas to codify some meanings and processes around "provenpackagers".

A general concern was expressedCite error: Invalid <ref> tag; refs with no name must have content in the IRC meeting that the ability of a provenpackager to modify others' packages should not be used lightly. DavidWoodhouse warned that "provenpackagers who commit to other packages without even _trying_ to coordinate with the owner should expect censure" and JonStanley posted a helpful link^[17] to a wiki entry on "Who is allowed to modify which packages".

Python3K Planning

ToshioKuratomi reported^[18] on a PyCon^[19] talk on Python 3 incompatibility which he had attended. LennartRegebro's "Python 3 Compatibility"^[20] talk stimulated Toshio to consider how to port older python code to python-2.6's py3 compatiblity layer.

When JochenSchmitt suggested a compatibility package TomCallaway replied^[21] that this would just be a crutch that perpetuated upstream projects unwillingness to move to Python 3. Tom preferred that Fedora developers would "[...] help port such applications to Python 3, and do so in a way that they detect the version of python at runtime and set defines appropriately. That way, we can have applications ready for Python3 before we actually make the switch."

There seemed^[22] to be rough agreement between ToshioKuratomi and JamesAntill that some way of allowing python3 modules and an interpreter in parallel to python-2 would be necessary.

IgnacioVazquezAbrams linked^[23] to video of all the PyCon 2009 sessions.

[1] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00162.html

[2] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00163.html

[3] ttps://www.redhat.com/archives/fedora-devel-list/2010-April/msg00194.html

[4] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00164.html

[5] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00177.html

[6] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00195.html

[7] ttps://www.redhat.com/archives/anaconda-devel-list/2009-April/msg00131.html

[8] ttps://bugzilla.redhat.com/show_bug.cgi?id=494070

[9] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html

[10] ttp://kernelnewbies.org/Ext4#head-3a678beda18002402ba62cf0292fae849d105271

[11] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00117.html

[12] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00139.html

[13] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00192.html

[14] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00199.html

[15] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00109.html

[16] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00067.html

[17] ttps://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages

[18] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00085.html

[19] ttp://us.pycon.org/

[20] ttp://us.pycon.org/media/2009/talkdata/PyCon2009/074/Python_3_Compatibility.pdf

[21] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00089.html

[22] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00104.html

[23] ttps://www.redhat.com/archives/fedora-devel-list/2009-April/msg00140.html

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

@@ Line 7: / Line 7: @@
 Contributing Writer: [[User:Ush|Oisin Feeley]]
-=== What Happened Last Summer ===
+=== Noarch with pkconfig Files ===
-[[User:Pfrields|Paul W. Frields]] broke radio silence to provide<ref>http://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html</ref> a detailed explanation of last August's (2008-08-12) security problem. Briefly, a <code>Fedora Project</code> systems administrator used a pass-phraseless SSH key. This was copied from the administrator's machine and used to gain access to Fedora infrastructure. Subsequently trojaned versions of <code>OpenSSH</code> and <code>rpm</code> were built and deployed on Fedora infrastructure. The investigation concludes that these packages were detected and removed before any <code>rpms</code> were built with them or distributed to Fedora users.  The full, detailed communication includes a time-line.
+PeterRobinson asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00162.html</ref> for help building his <package>gupnp-vala</package> package as noarch. The complication was that it contained a <code>pkgconfig</code> file.
-=== Emacs Cabal Disables Xorg Ctrl-Alt-Backspace ===
+Several helpful responses, such as MichaelSchwendt's<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00163.html</ref> suggested installing <code>pkgconfig</code> files into <code>/usr/share/pkgconfig</code> instead of one of the <code>/usr/lib</code> directories. ToshioKuratomi thought<ref></ref>
-Much work has been done on the <code>Fedora 11</code> release notes<ref>http://fedoraproject.org/wiki/Fedora_11_Beta_release_notes</ref> to advise users of significant changes. A thread started<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01682.html</ref> by [[GerryReno|Gerry Reno]] to question the disabling of Ctrl-Alt-Backspace as a key combination to kill the X server shows that these beta release notes are an important means to notify prospective users of new features of the operating system. Gerry was among many contributors to the thread that preferred to keep the traditional functionality enabled. This change was an upstream Xorg decision apparently taken to prevent users from accidentally killing their X servers. Although there had previously been extensive discussion (reported in FWN#162<ref>http://fedoraproject.org/wiki/FWN/Issue162#Fedora_11_Alpha_Released</ref>) and a nice, hot flamewar on the upstream lists<ref>http://lists.freedesktop.org/archives/xorg/2008-September/038786.html</ref> the change seemed to take many by surprise. This prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01705.html</ref> accusations that "[...] big changes like this need to be advertised extensively instead of just quietly slipped in."
+VilleSkyttä ran<ref>https://www.redhat.com/archives/fedora-devel-list/2010-April/msg00194.html</ref> the <code>rpmlint</code> check and confirmed that it warned exactly of this misuse of a <code>libdir</code> macro.
-[[RolandMcGrath|Roland McGrath]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01691.html</ref> ways in which <code>xorg.conf</code> could be changed using a <code>kickstart</code> post-scriptlet but preferred that such choices would be pushed into the users' "keyboard shortcut" preferences. Gerry raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01697.html</ref> the issue of the use of the Ctrl-Alt-Backspace combination being essential to virtual machine management.
+In response to a subsidiary question JesseKeating explained<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00164.html</ref> that the <code>noarch</code> packages merely appeared to be present in each of the different architecture trees because they were hardlinked.
-Another dissatisfied user was [[ArthurPemberton|Arthur Pemberton]]. He requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01770.html</ref> discussion of why such large changes as disabling Ctrl-Alt-Backspace, removing <code>Xorg.conf</code> in favor of auto-detection, and others had been made without what he considered to be enough discussion. Response to this line of questioning suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01791.html</ref> variously that the change had been made "secretly" upstream in order to appease an emacs-using cabal, and that Fedora had adopted the changes solely because Ubuntu had done so. This latter accusation was disputed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01888.html</ref> by [[MatthewGarrett|Matthew Garrett]].  The <code>emacs</code> angle seems to come from the fact that the <code>emacs</code> key-combinations "Ctrl-Alt-End" and "Ctrl-Alt-\" are, with certain keyboard layouts, a danger to fumble-fingered users. Arthur pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01732.html</ref> to an added complication in a use case in which booting with the monitor powered off requires restarting the X server.
+=== Fedora and OpenSolaris Dualboot Issue Solved ===
-[[FelixMiata|Felix Miata]] mentioned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01820.html</ref> that OpenSuSE's solution was to require that the Ctrl-Alt-Backspace sequence be struck twice before it took effect. This was also suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01804.html</ref> by Gerry during a thread in which [[MatthewGarrett|Matthew Garrett]] and [[MatthiasClasen|Matthias Clasen]] explained that the <code>Terminate_Server</code> symbol could be bound to any desired key-binding through <code>XKB</code> maps.
+After AhmedKamal reported<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00177.html</ref> that a <code>ZFS</code> formatted partition seemed to be causing a <code>Fedora 11 Beta</code> installation failure there was a quick response. EricSandeen noted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00195.html</ref> that a patch had already been produced<ref>https://www.redhat.com/archives/anaconda-devel-list/2009-April/msg00131.html</ref> by DaveLehman to merely log the problem instead of raising an error.  The bugzilla entry suggested<ref>https://bugzilla.redhat.com/show_bug.cgi?id=494070</ref> that the root problem was due to <code>udev</code> failing to recognize <code>ZFS</code> properly.
-[[AhmedKamal|Ahmed Kamal]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01708.html</ref>: "To anyone wanting to kill X when it hangs, why not login through a VC and `pkill X' .. Just like any process, why do we have to have magic keys!" Similarly [[AdamJackson|Adam Jackson]] challenged<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01989.html</ref> the assertion that it would be possible to use the key combination to deal with faulty drivers.
+=== fallocate(2) Preferred Glibc Interface for Preallocation ? ===
-=== ZFS-based Upgrades ===
+JamesRalson noted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html</ref> the adoption of the <code>ext4</code> filesystem in <code>Fedora 11</code> and suggested that in order to use its preallocation features more efficiently it would be useful to patch applications. This could help avoid the current "double write" penalty currently incurred<ref>http://kernelnewbies.org/Ext4#head-3a678beda18002402ba62cf0292fae849d105271</ref> by preallocation in which the reserved space is first filled with nulls. James wondered whether there was a better interface to do this than <code>glibc</code>'s <code>posix_fallocate()</code> which first attempts the allocation and then falls "[...] back to writing nulls to fill up the requested range if fallocate() fails."
-[[NealBecker|Neal Becker]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01597.html</ref> a link to an interesting way to use the capabilities of the <code>ZFS</code> filesystem to take snapshots of the system and provide a safe, stable way to upgrade. [[User:Skvidal|Seth Vidal]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01599.html</ref> sanguine that this would be relatively easy with a <code>YUM</code>-based system.
+EricSandeen suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00117.html</ref> using <code>fallocate(2)</code> which is present in the <code>glibc</code> version in rawhide and provided a test program to investigate how well this would work.
-=== Repoview Temporarily Bust in Fedora 10 ===
+=== Rawhide Report Glitches Resolved ===
-After a report from [[UweKiewel|Uwe Kiewel]] that he could not create a repoview for <code>Fedora 10</code> Everything [[User:Skvidal|Seth Vidal]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01585.html</ref> that there was a fix available in rawhide but it had not got into <code>Fedora 10</code> yet. [[KonstantinRyabitsev|Konstantin Ryabitsev (Icon)]] built the updated packages and [[User:Jwboyer|Josh Boyer]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01648.html</ref> that they would be available very shortly.
+After a few "Rawhide Reports" were missed AlexLancaster asked<ref></ref> what was going on. JoshBoyer answered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00139.html</ref> that <code>pungi</code> for <code>i386</code> was failing.
-=== LGPL Qt-4.5 in Fedora 10 and Fedora 9 ===
+Rawhide Reports resumed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00192.html</ref> on 2009-04-04.
-[[User:Kkofler|KevinKofler]] announced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01696.html</ref> updates of <code>Qt-4.5</code> for <code>Fedora 10</code> and <code>Fedora 9</code>. He detailed the advantages of this backwards-compatible update and suggested that maintainers of <code>Qt-4</code>-based packages do some quick checks to ensure that there would be no snags.
+=== XULRunner Committable by non-Provenpackagers ===
+The summary of the 2009-04-03 FESCo meeting indicated<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00199.html</ref> that "Firefox/Thunderbird/XULRunner" are open for commits by those who do not have "provenpackager" status. Also discussed and declined for such changes were: <code>popt</code>; <code>initscripts</code>; <code>ethtool</code>; lvm-related packages; and <code>hwdata</code>.
+JonStanley also noted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00109.html</ref> that he was going to shoulder the burden of providing his excellent summaries of FESCo meetings.
+=== Provenpackager Policies ===
+Also discussed in the 2009-04-04 FESCo meeting were several requests for "provenpackager" and "sponsor" status. This followed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00067.html</ref> on the heels of work done by PatriceDumas to codify some meanings and processes around "provenpackagers".
+A general concern was expressed<ref></ref> in the IRC meeting that the ability of a provenpackager to modify others' packages should not be used lightly. DavidWoodhouse warned that "provenpackagers who commit to other packages without even _trying_ to coordinate with the owner should expect censure" and JonStanley posted a helpful link<ref>https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages</ref> to a wiki entry on "Who is allowed to modify which packages".
+=== Python3K Planning ===
+ToshioKuratomi reported<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00085.html</ref> on a PyCon<ref>http://us.pycon.org/</ref> talk on Python 3 incompatibility which he had attended. LennartRegebro's "Python 3 Compatibility"<ref>http://us.pycon.org/media/2009/talkdata/PyCon2009/074/Python_3_Compatibility.pdf</ref> talk stimulated Toshio to consider how to port older python code to python-2.6's py3 compatiblity layer.
+When JochenSchmitt suggested a compatibility package TomCallaway replied<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00089.html</ref> that this would just be a crutch that perpetuated upstream projects unwillingness to move to Python 3. Tom preferred that Fedora developers would "[...] help port such applications to Python 3, and do so in a way that they detect the version of python at runtime and set defines appropriately. That way, we can have applications ready for Python3 before we actually make the switch."
+There seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00104.html</ref> to be rough agreement between ToshioKuratomi and JamesAntill that some way of allowing python3 modules and an interpreter in parallel to python-2 would be necessary.
+IgnacioVazquezAbrams linked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00140.html</ref> to video of all the PyCon 2009 sessions.

Search