From Fedora Project Wiki

< FWN‎ | Beats

(170 devel pass1)
(170 devel pass2. spellcheck, fasnames, cites)
Line 9: Line 9:
=== Noarch with pkconfig Files ===
=== Noarch with pkconfig Files ===


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.
[[User:Pbrobinson|Peter Robinson]] 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.


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>
Several helpful responses, such as [[User:Mschwendt|Michael Schwendt'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. [[User:Toshio|Toshio Kuratomi]] thought<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00167.html</ref> that the problem was that the package did not use the new noarch-subpackage feature but instead tried to be a regular noarch package.


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.
[[User:Scop|Ville Skyttä]] 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.


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.  
In response to a subsidiary question [[User:Jkeating|Jesse Keating]] 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 hard-linked.  


=== Fedora and OpenSolaris Dualboot Issue Solved ===
=== Fedora and OpenSolaris Dualboot Issue Solved ===


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.
After [[hAhmedKamal|Ahmed Kamal]] 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. [[User:Sandeen|Eric Sandeen]] 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 [[User:Dlehman|Dave Lehman]] 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.


=== fallocate(2) Preferred Glibc Interface for Preallocation ? ===
=== fallocate(2) Preferred Glibc Interface for Preallocation ? ===


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."
[[JamesRalston|James Ralston]] 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."


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.  
[[User:Sandeen|Eric Sandeen]] 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.  


=== Rawhide Report Glitches Resolved ===
=== Rawhide Report Glitches Resolved ===


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.
After a few "Rawhide Reports" were missed [[User:Alexlan|Alex Lancaster]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00138.html</ref> what was going on. [[User:Jwboyer|Josh Boyer]] 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.


Rawhide Reports resumed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00192.html</ref> on 2009-04-04.  
Rawhide Reports resumed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00192.html</ref> on 2009-04-04.  
Line 37: Line 37:
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>.  
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.  
[[User:Jstanley|Jon Stanley]] 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 ===
=== 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".
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 [[User:Pertusus|Patrice Dumas]] 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".
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|David Woodhouse]] warned that "provenpackagers who commit to other packages without even _trying_ to coordinate with the owner should expect censure" and [[User:Jstanley|Jon Stanley]] 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 ===
=== 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.
[[User:Toshio|Toshio Kuratomi]] 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."  
When [[User:S4504kr|Jochen Schmitt]] suggested a compatibility package [[User:Spot|Tom Callaway]] 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.  
There seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00104.html</ref> to be rough agreement between [[User:Toshio|Toshio Kuratomi]] and [[User:James|James Antill]] 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.
[[User:Ivazquez|Ignacio Vazquez-Abrams]] linked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00140.html</ref> to video of all the PyCon 2009 sessions.

Revision as of 19:26, 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

Peter Robinson 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 Michael Schwendt's[2] suggested installing pkgconfig files into /usr/share/pkgconfig instead of one of the /usr/lib directories. Toshio Kuratomi thought[3] that the problem was that the package did not use the new noarch-subpackage feature but instead tried to be a regular noarch package.

Ville Skyttä ran[4] the rpmlint check and confirmed that it warned exactly of this misuse of a libdir macro.

In response to a subsidiary question Jesse Keating explained[5] that the noarch packages merely appeared to be present in each of the different architecture trees because they were hard-linked.

Fedora and OpenSolaris Dualboot Issue Solved

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

fallocate(2) Preferred Glibc Interface for Preallocation ?

James Ralston noted[10] 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[11] 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."

Eric Sandeen suggested[12] 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 Alex Lancaster asked[13] what was going on. Josh Boyer answered[14] that pungi for i386 was failing.

Rawhide Reports resumed[15] on 2009-04-04.

XULRunner Committable by non-Provenpackagers

The summary of the 2009-04-03 FESCo meeting indicated[16] 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.

Jon Stanley also noted[17] 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[18] on the heels of work done by Patrice Dumas 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. David Woodhouse warned that "provenpackagers who commit to other packages without even _trying_ to coordinate with the owner should expect censure" and Jon Stanley posted a helpful link[19] to a wiki entry on "Who is allowed to modify which packages".

Python3K Planning

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

When Jochen Schmitt suggested a compatibility package Tom Callaway replied[23] 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[24] to be rough agreement between Toshio Kuratomi and James Antill that some way of allowing python3 modules and an interpreter in parallel to python-2 would be necessary.

Ignacio Vazquez-Abrams linked[25] to video of all the PyCon 2009 sessions.

  1. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00162.html
  2. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00163.html
  3. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00167.html
  4. https://www.redhat.com/archives/fedora-devel-list/2010-April/msg00194.html
  5. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00164.html
  6. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00177.html
  7. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00195.html
  8. https://www.redhat.com/archives/anaconda-devel-list/2009-April/msg00131.html
  9. https://bugzilla.redhat.com/show_bug.cgi?id=494070
  10. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html
  11. http://kernelnewbies.org/Ext4#head-3a678beda18002402ba62cf0292fae849d105271
  12. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00117.html
  13. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00138.html
  14. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00139.html
  15. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00192.html
  16. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00199.html
  17. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00109.html
  18. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00067.html
  19. https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages
  20. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00085.html
  21. http://us.pycon.org/
  22. http://us.pycon.org/media/2009/talkdata/PyCon2009/074/Python_3_Compatibility.pdf
  23. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00089.html
  24. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00104.html
  25. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00140.html