From Fedora Project Wiki

< FWN‎ | Beats

(#163 developments draft 1)
(#163 developments draft 2. Removed duplicated sections, correct fasname, references block below each section)
Line 1: Line 1:
{{Anchor|Developments}}
== Developments ==
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: [[OisinFeeley|Oisin Feeley]]
=== Fedora 11 Alpha Released ===
[[User:Jkeating|Jesse Keating]] announced<ref>http://www.redhat.com/archives/fedora-announce-list/2009-February/msg00004.html</ref> the availability of <code>Fedora 11 Alpha</code> on 2009-02-05. His beautiful poetry was accompanied by a suggestion to read the Release Notes<ref>http://fedoraproject.org/wiki/Fedora_11_Alpha_release_notes</ref>.
One change which drew<ref>http://www.redhat.com/archives/fedora-test-list/2009-February/msg00118.html</ref> extensive commentary on @fedora-test was the default disabling of the <code>Ctrl-Alt-Backspace</code> key combination. This traditionally kills the X server and to regain the usual behavior it is necessary to create an <code>Xorg.conf</code> file (these no longer exist by default either) and add the line <code>Option "DontZap" "false"</code> to it.
<references/>
=== Fedora 11 Will Support i586 Instruction Set ===
{{Anchor|Developments}}
{{Anchor|Developments}}
== Developments ==
== Developments ==
Line 74: Line 57:


After some issue with platform dependency were reported by [[MichaelCronenworth|Michael Cronenworth]] were sorted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01074.html</ref> out it seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01076.html</ref> the tool is ready for use.
After some issue with platform dependency were reported by [[MichaelCronenworth|Michael Cronenworth]] were sorted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01074.html</ref> out it seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01076.html</ref> the tool is ready for use.
Last week (FWN#161<ref>http://fedoraproject.org/wiki/FWN/LatestIssue#Dropping_Support_for_i586_Architecture_.3F</ref>) we reported on a proposal to cease building Fedora 11 for the i586 CPU instruction set. FESCo had delayed its decision in order to discuss the matter further. The issue was addressed<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-02-05.html</ref> on 2009-02-05 with the outcome that a proposal by [[User:Ausil|Dennis Gilmore]] to continue supporting i586 for the duration of Fedora 11 but to transition to i686 for Fedora 12 was supported.   
Prior to the meeting [[WarrenTogami|Warren Togami]] summed up<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00200.html</ref> the advice of [[JakubJelinek|Jakub Jelínek]] as: "Jakub recommends i586.rpm for Fedora 11, because it doesn't gain us much of anything to go with i686 minimum.  The benefits of i586 to i686 are simply not important because cmov is usually not a worthwhile optimization on ia32."
An interesting suggestion by [[AdamJackson|Adam Jackson]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00282.html</ref><ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00407.html</ref> that if there is a committed user-base of i586 users they could probably support it in the Secondary Architecture (see FWN#92<ref>http://fedoraproject.org/wiki/FWN/Issue92#Secondary_Arch_Proposal_Cont.</ref>) infrastructure.
[[UlrichDrepper|Ulrich Drepper]] and [[User:Rathann|Dominik Mierzejewski]] debated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00240.html</ref> whether the use of cmov can in some circumstances cause performance degradation.
It is unclear exactly what performance benefits could be obtained by passing various architecture-specific flag combinations to GCC but it does seem that the burden of building and maintenance will be eased significantly by these changes. As a related change<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-02-05.html</ref> x86_64 kernels will be installed with a 32-bit userspace.
<references/>
=== RFC: Power Management ===
[[PhilKnirsch|Phil Knirsch]] initiated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00365.html</ref> a discussion of attempts to decrease power consumption especially in userland. A wiki page<ref>http://fedoraproject.org/wiki/Features/PowerManagement</ref> reflects some of the research Phil has pulled together.
[[RichardHughes|Richard Hughes]] pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00376.html</ref> out some interesting work on <code>DeviceKit-power</code> where he built on <code>powertop</code>. [[Olivier Galibert|Olivier Galibert]] raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00430.html</ref> a possible problem with Richard's use of D-Bus itself causing wakeups, but according to [[ColinWalters|Colin Walters]] a patch existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00642.html</ref> to fix this problem.
Many of the items suggested in Phil's page for documentation were suggested by [[User:Notting|Bill Nottingham]] as desiderata for defaults. While Phil agreed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00406.html</ref> in general he itemized some of the problems. These include problems with network interfaces and hard-disk spindowns which may be approachable as a result of a <code>tuned</code> daemon on which Phil is working.
An addendum of audio hardware power-saving was made by [[EricSandeen|Eric Sandeen]] along with a list of bugs which led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00413.html</ref> Phil to wonder if a tracker bug to collate all the information would be useful.
[[MatthewGarrett|Matthew Garrett]] expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00415.html</ref> some worries that hard-disk power-saving would cause physical wear and the <code>relatime</code> patches to work around over-aggressive deletion of content in /tmp would continue to be stalled.
The importance of separating out KDE and GNOME dependent features was noted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00403.html</ref> by [[User:Kkofler|Kevin Kofler]].
<references/>
=== Rawhide Report 2009-02-07 ===
The last report<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00661.html</ref> lists 14 new packages added, 57 modified and some broken dependencies. New packages include <code>dissy</code>, a graphical front-end to <code>objdump</code> and <code>python-pygooglechart</code> a Python wrapper for the Google Chart API.
[[RichardHughes|Richard Hughes]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00669.html</ref> that the update to PolicyKit-gnome-0.9.2-1.fc11 might be useful: "If you're having problems with PackageKit and buttons "not working" you need this update."
Some of the x86_64 broken dependencies were due to to <code>mono-2.4</code> being pushed to rawhide which led [[User:DavidNielsen|David Nielsen]] to suggest<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00674.html</ref> that a heads up would have been useful. [[User:Alexlan|Alex Lancaster]] requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00746.html</ref> that API/ABI breakage would be announced on @fedora-devel-announce instead of on the high-traffic @fedora-devel.
<references/>
=== New module-init-tools Uses Binary modules.dep|alias|symbols ===
An update to <code>module-init-tools-3.6</code> was pushed to <code>rawhide</code> by [[JonMasters|Jon Masters]] in order to speed up<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00477.html</ref> boot time significantly. The files <code>modules.dep</code>, <code>modules.alias</code> and <code>modules.symbols</code> will have binary versions which are used in preference to their old text versions. Jon asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00353.html</ref> if the need to run <code>depmod -a</code> after upgrades to <code>module-init-tools</code> would upset anyone. There seemed to be general approbation of his changes and they should land soon for Fedora 9 also.
<references/>
=== New Georgian Fonts Packaged Rapidly ===
A call was put out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00281.html</ref> by [[User:Nim|Nicolas Mailhot]] for someone to package a completely new Georgian font pack created by Besarion Paata Gugushvili.
Nicolas was especially keen to get this done quickly as he had contacted Besarion and been rewarded with completely new fonts not shipped by any other distro, licensed with the FSF font exception to the GPL all within nine hours!
[[User:Spot|Tom Callaway]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00308.html</ref> within mere hours.
<references/>
=== Distro-agnostic /boot Metadata Standard ? ===
A negative review in German IT magazine "c't" led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00273.html</ref> [[ChristophHoger|Christoph Höger]] to ask if it was possible to preserve the ability to boot other GNU/Linux distros after installing Fedora. The most annoying point seemed to be that Windows installations are preserved.
A moderately long thread resulted and covered several ideas to allow the <code>GRUB</code> bootloader to identify other distributions. One such was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00345.html</ref> .that there should be an agreement among distributions to use a shared metadata standard on boot partitions.
<references/>
=== GCC-4.4 Mass Rebuild Successful ===
[[JakubJelinek|Jakub Jelínek]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00180.html</ref> that a mass rebuild of rawhide (snapshotted on 2009-01-26) of 6228 packages had produced only a few hundred failures. He listed these by type of failure.
Several of the packages listed failed to build for reasons other than GCC, for instance Java packages failed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00220.html</ref> due to <code>maven</code> being broken.
[[User:knurd|Thorsten Leemhuis]] provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00229.html</ref> a list of packages and owners sorted by owner which was generally appreciated. He pointed out: "Finding all your packages in such a long list gets really hard as soon as you maintain 10 or 15 packages."
Problems reported due to a mismatch between the <code>libstdc++</code> headers requirement of <code>-march=i486</code> and <code>Koji</code>'s default use of <code>-march=i386</code> led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00257.html</ref> Jakub to whip up some fixes. He requested that <code>CFLAGS</code> were not altered in <code>SPEC</code> files.
<references/>
=== Help Rel-eng Accelerate Updates Processing ===
One bottleneck in the processing of updates to packages is that they need to be signed. Work is ongoing to automate this (see FWN#147<ref>http://fedoraproject.org/wiki/FWN/Issue147#Unsigned_Rawhide_Packages_an_Attack_Vector_.3F</ref>) with a signing-server codenamed "sigul".
[[User:Cwickert|Christoph Wickert]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00508.html</ref> why it had taken over five days for an update to one of his packages to get to <code>testing</code>. When [[User:Jwboyer|Josh Boyer]] responded that it was because one human ([[User:Jkeating|Jesse Keating]]) had to sign the packages and he had been also busy getting <code>Fedora 11 Alpha</code> released, [[DanielBerrange|Daniel P. Berrange]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00515.html</ref> adding more humans to help. [[JesseKeating|Jesse Keating]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00576.html</ref> that anyone who wished to help could take some of the load off the release-engineering team so that they had more time for package signing. 
<references/>

Revision as of 17:47, 15 February 2009

Developments

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

Contributing Writer: Oisin Feeley

FLOSS Multimedia Codec Support

Inspired by previous discussions on whether Fedora should distribute FLOSS content[1] Martin Sourada tried[2] to start a discussion about the poor support of FLOSS multimedia. Martin noted: "Out of the combinations of two FLOSS containers (matroska and ogg) and two FLOSS video codecs (dirac and theora) I know only one (ogg + theora) actually works in xine-lib (used by KDE4) which is pathetic." He asked for help in documenting the situation on a wiki page[3].

When Bastien Nocera suggested that the most important thing was to file bugs Martin responded[4] that this was what he was doing after first performing tests.

An information packed sub-thread started[5] by Gregory Maxwell expanded the scope of the tests and started a discussion with Dominik Mierzejewski about the problem of ffmpeg providing sub-optimal implementations of unencumbered codecs. It seems that for reasons of efficiency ffmpeg re-invents the wheel from scratch instead of using and improving upstream implementations. Kevin Kofler also rose[6] to the implied challenge that GStreamer was preferable to xine-lib.

Multiple Packages from One Source ?

A question about how to handle the situation where a single source could be compiled with alternate databases was posted[7] by Steven Moix. The motion video motion detector software can be compiled to use either MySQL or Postgres. Steven explained that the problem was that "[...]you can't divide it into sub-packages, at the end it generates one big binary file [...]" and wondered should he just choose the database he preferred or propose two packages.

Manuel Wolfshant expressed[8] what appeared to be the common wisdome: "personally I would compile twice, once enabling mysql and another time pgsql, and create 2 packages. each package would install a "motion-dbname" binary, and a symlink would allow access via the well known name "motion". Using alternatives would allow a switch between the two."

Although it was admitted that David Woodhouse's suggestion[9] to make the program use loadable plugins was the ideal Tom Lane thought[10] that was "[...] a bit above and beyond what a packager should do. If he's also an upstream developer, then he should undertake that addition with his developer hat on; but it's *well* beyond the size of patch that a Fedora package should be carrying."

The ability to specify alternate requires (similar to those used in the .deb package format[11]) was discussed[12] by Richard W.M. Jones and Tom Lane and dismissed as impractical in this case anyway due to variations in SQL.

Take a Peek at the Fedora 11 Release Notes

Fresh from his work on the RHEL-5.3 Release Notes Ryan Lerch apprised[13] the list of the latest changes to the Fedora 11 Release Notes. Ryan sought early feedback and changes to documentation beats in order to give the community an early preview of the release notes.

Initial feedback from Thorsten Leemhuis and Kevin Kofler and others indicated that the use of fixed-width instead of liquid layout was disliked by some people and loved[14] by others.

Ryan also provided[15] an rpm of this Release Notes mockup.

Heads Up: Noarch Subpackages Landing Soon

Florian Festi warned[16] that the ability to produce noarch subpackages will soon be available in Fedora. This brings the benefit of being able to share these packages among different architectures thus reducing disk space and mirror bandwidth.

Although rpm-4.6</rpm> supports noarch fully there are still some fixes to make to koji before the Fedora buildsystem can cope with noarch subpackages. Florian suggested that those who wanted to could experiment in mock with rpmdiff to compare the results across different architectures. He assured readers that there were no plans to force packagers to use this feature and invited anyone interested in developing the use of noarch in future release to a discussion.

Florian later warned[17] that one potential negative outcome of using such sub-packages would be a proliferation of packages and consequent bloating of metadata which might affect yum.

VilleSkyttä suggested[18] that it would be wise to make sure that use of BuildRequire: rpm-build >= 4.6.0 was enforced in order to ensure that earlier versions of rpmbuild did not produce noarch versions of the main package and other potential subpackages. Florian's response recognized[19] the problem but deprecated the use of BuildRequires to such an extent. One possible alternative which he proposed was to "[have [[User:|Panu Matilainen]] backport a check that will make noarch packages (both regular and noarch) fail to build if they contain binaries [and ensure that this] additional check will be in place before koji will be updated[.]" This latter proposal stimulated a good deal of interest from Ralf Corsepius and Richard W.M. Jones as they were both concerned with cross-architecture issue. The definition of a "binary" seemed to be one unclear point.

In a later thread Florian updated[20] a list of packages which could be easily turned into noarch subpackages.

Mass Rebuild Coming Soon

Jesse Keating drew attention to "[...] a perfect storm brewing for Fedora 11" due to the need to rebuild with GCC-4.4 (see FWN#161[21], the use of i586 as the default supported architecture (see FWN#162[22] and the support of stronger hashes (last paragraph of FWN#107[23]).

Apparently the time-constraints led to a desire to start the rebuild as soon as possible without giving maintainers an explicit window in which to do their own builds. Jesse preferred to give maintainers an ability to opt-out and sought suggestions on how this could be achieved.

Jesse suggested that interested parties should either reply to the thread and/or participate in the 2009-02-16 IRC meeting in #fedora-meeting at 1800UTC.

New Tool Measures Ease of Cross-compiling to Windows

Richard W.M. Jones announced[24] the availability of CrossReport, a tool to evaluate the ease with which applications can be ported to Windows using the MinGW libraries.

After some issue with platform dependency were reported by Michael Cronenworth were sorted[25] out it seemed[26] the tool is ready for use.

  1. ↑ http://fedoraproject.org/wiki/FWN/Issue161#Electronic_Design_Automation_Content_Without_Tools_.3F
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00794.html
  3. ↑ http://fedoraproject.org/wiki/User:Mso/Open_Multimedia
  4. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00826.html
  5. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00800.html
  6. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00806.html
  7. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00918.html
  8. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00920.html
  9. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00923.html
  10. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01091.html
  11. ↑ http://www.debian.org/doc/debian-policy/ch-relationships.html
  12. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01097.html
  13. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00910.html
  14. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00942.html
  15. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00911.html
  16. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01012.html
  17. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01020.html
  18. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01023.html
  19. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01046.html
  20. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01105.html
  21. ↑ http://fedoraproject.org/wiki/FWN/Issue161#GCC:_Default_ISA_Flags_and_Glibc
  22. ↑ http://fedoraproject.org/wiki/FWN/LatestIssue#Fedora_11_Will_Support_i586_Instruction_Set
  23. ↑ http://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation
  24. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01055.html
  25. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01074.html
  26. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01076.html
Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=78460"