From Fedora Project Wiki

< FWN‎ | Beats

(FWN #156 Development beat pass 1)
(FWN #157 spellchecked pass1)
Line 7: Line 7:
Contributing Writer: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[OisinFeeley|Oisin Feeley]]


=== Fedora 11: OSS and PulseAudio Conflict Resolved by CUSE ? ===
=== Nautilus Spatial-mode Flamewar ===


A thread[1] from November led [[WarrenTogami|Warren Togami]] to suggest[2] a plan to use CUSE[3] as part of a strategy to deprecate the near obsolete Open Sound System (OSS) which wreaks havoc with <code>PulseAudio</code> enabled boxes. The plan included a fallback to <code>OSS</code> for users who really wanted it.
The tired, old topic of whether <code>nautilus</code> should use "spatial-mode" as a default was re-opened[1] by MarkG85 in the form of a request for list subscribers to "vote" on the mailing list for a reversion to "browser-mode". In spatial-mode <code>nautilus</code> opens a new window for each directory unless one middle-clicks or holds the shift key down.
 
[[BastienNocera|Bastien Nocera]] was[4] skeptical that <code>CUSE</code> would be ready in time for <code>Fedora 11</code> and suggested instead that a list of applications using OSS be created so that they could be fixed.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01005.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02195.html
It was pointed out by several contributors that voting "+/- 1" was not a recognized way to achieve change within the Fedora Project. [[ChrisAdams|Chris Adams]] asked[2] if he and his friends "[...] should [...] all spam fedora-devel with `+1' and `metoo' to change the default background color? What if it is 20 friends, or 100, or 500?" A similar point was made[3] by [[JeffSpaleta|Jef Spaleta]].


[3] Character Devices in User space: http://lwn.net/Articles/308445/
[[DimiPaun|Dimi Paun]] expressed[4] frustration with what he charcaterized as "lame community involvenment" and several personal attacks were made on both the maintainer and other contributors who had deprecated the attempt to take a mailing list vote. After tempers had flared Jeff commented[5]: "Noone has figured out how to write a markup language for human intention...and as a result any passionate discussion degrades severely as we are wired to read intention but without body language and vocal ques...we absolutely do it wrong when relying solely on written language. Even more so with English! If we mandated everyone encode thought into Lisp we'd be having more constructive discussions (and less of them). The productivity of the list would be through the roof."


[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00872.html
In response to a challenge to detail some advantages of spatial-mode [[TomasTorcz|Tomas Torcz]] was among those who offered[6] that the persistent screen placement of directory windows was a major advantage. He also suggested a way to avoid leaving multiple windows open: "When I open new window and don't want parent directory open, I just open with middle button. Some people prefer Shift+click in this situation. I never has to use `Close all parent folder' (ctrlshift-w), but I aware it exist." [[JoonasSarajärvi|Joonas Sarajärvi]] confirmed[7] the persistence as an advantage: "[...] the state of each folder is persistent. Every window opens in the same view that it had when I reopen them. I can have appropriate zoom levels and views for every directory I commonly use."


=== Rawhide Report 2008-12-08 ===
Very much later in the thread, after he had been referred to several times, the package maintainer [[AlexanderLarsson|Alexander Larsson]] replied[8] that he was unconvinced both by the tone and content of the argument that there was a case to be made for changing the default.


When the latest ''Rawhide Report'' logged[1] one maintainers use of <code>cvs-import.sh</code> [[DominikMierzejewski|Dominik Mierzejewski]] criticised[2] the use of the script for updating. [[RichardJones|Richard Jones]] asked[3]: "[I]s this stuff really documented anywhere? I have tended to learn it by osmosis, deduction and reading the horribly complicated rules in Makefile.common."
It is possible to choose which behavior one wants by at least two methods. One can either use the <code>GUI</code>


[[JasonTibbitts|Jason Tibbitts]] argued[4] that using <code>cvs-import.sh</code> nullified the potential advantages of using an <code>SCM</code> as it sequestered the sources elsewhere. [[JesseKeating|Jesse Keating]] disagreed[5] due to ease of use issues.
<pre>Nautilus -> Preferences -> Behavior -> Always open in browser windows</pre>


A direct answer was provided[6] by [[PatriceDumas|Patrice Dumas]] with links to the relevant portions of the wiki.
or else change the <code>GConf</code> setting using


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00671.html
<code>gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true</code>


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00677.html
As part of the argument involved a desire to be able to replicate these settings automatically and possibly distribute them to others [[MatthiasClasen|Matthias Clasen]] suggested[9] that anyone wishing to make permanent change to the default settings could create a <code>sabayon</code> profile.


[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00691.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02089.html


[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00694.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02286.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00695.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02305.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00701.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02416.html


=== The D-Bus Problem ===
[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02392.html


[[IanAmess|Ian Amess]] asked[1] for the current status of a problem caused by a substantial update of the <code>D-Bus</code> package. The update had resulted in the incapacitation of many packages. The most important of these was <code>PackageKit</code>, the default graphical application for managing software.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02387.html


[[ColinWalters|Colin Walters]] decided[2] that reverting the update was necessary and that changes to <code>D-Bus</code> policy would be postponed. <code>PackageKit</code>, and its <code>GNOME</code> and <code>KDE</code> clients were updated[3] by [[RichardHughes|Richard Hughes]] in an attempt to accommodate the changes. Richard testified that "[o]ver the last two days we've all been working really hard on fixing up all the projects after the DBus update. I know personally I'm closing a duplicate bugzilla every 30 minutes." He noted that the delay between creating an update and pushing it to a mirror was a limiting factor in being able to implement these fixes.
[7] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02213.html


A post to @fedora-announce by [[PaulFrields|Paul Frields]] explained[4] the series of steps which allowed users to re-enable normal system updates using PackageKit. As of 2008-12-15 this notice also appears at the top of all the Fedora Project wiki pages.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02189.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01391.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02389.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01412.html
=== Font Package Naming Guidelines ===


[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00746.html
[[NicolasMailhot|Nicholas Mailhot]] ensured[1] that everyone was made aware of the new font package naming rules for <code>Fedora 11</code>. These will help break up large font packages in order to allow users to obtain fonts from desired families without imposing a large download burden.


[4] https://www.redhat.com/archives/fedora-announce-list/2008-December/msg00012.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02597.html


=== Fedora Com System ? ===
=== How to become a Co-Maintainer ===


An exploration of possible ways to alert users to critical information was initiated[1] by [[ArthurPemberton|Arthur Pemberton]]. Most ideas seemed to center around some sort of <code>RSS</code> feed enabled by default on the desktop.
[[RayVanDolson|Ray Van Dolson]] asked[1] for some information on identifying the current (co)maintainers of the <code>proftpd</code> package, the procedure to become a co-maintainer and the abilities to push bugfixes which this would confer upon him if the primary maintainer were absent.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01347.html
A full answer was provided[2] by [[PatriceDumas|Patrice Dumas]] with links to <code>PackageDB</code> and the policies on the wiki regarding non-responsive maintainers.


=== YUM: Enable --skip-broken by Default ? ===
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02253.html


Aliasing <code>yum update</code> to <code>yum --skip-broken update</code> was suggested[1] by [[StevenMoix|Steven Moix]] as a way to prevent a lot of recurring support problems by eliminating dependency problems.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02255.html


It was attempted[2] to strike a balance between reporting these broken dependencies so that they can be fixed and guarding the list of packages on a user's system as private information.
=== Proposed Package Re-Naming Guidelines ===


A divergent sub-thread delved[3] into the appropriate use of <code>Conflicts:</code> in <code>rpm</code> packages.
Feedback was requested[1] by [[KevinFenzi|Kevin Fenzi]] on a draft guideline concerning the re-naming of packages either as a result of upstream action or locally to adhere to the [[NamingGuidelines]].


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01161.html
[[PatriceDumas|Patrice Dumas]] and [[DennisGilmore|Dennis Gilmore]] remembered[2] that a re-review followed by EOL of the old package was the current practice.  


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01171.html
[[JasonTibbitts|Jason Tibbitts]][3] and [[JesseKeating|Jesse Keating]][4] referenced <code>IRC</code> discussions of the practice and its advantages in checking the <code>Obsoletes</code> and <code>Provides</code> in discussion with [[JochenSchmitt|Jochen Schmitt.]] Jochen was concerned[5] that the process be kept lightweight as opposed to a full review.


[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01349.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02052.html


=== Making `updates-testing' More Useful ===
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02054.html


The means to enable <code>PackageKit</code> to prompt willing users to install testing updates was explored in a thread opened[1] by [[MatthiasClasen|Matthias Clasen]]: "Basically, PackageKit should know that these are testing updates, and should ask me 'There are ... package updates available that need testing. Do you want to test these now ?' For extra points, we could even show a 'report back' link somewhere that allows to send comments to bodhi."
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02058.html


[[RichardHughes|Richard Hughes]] prototyped a solution but worried[2] that it would be necessary to make changes to the users' repository configurations without their explicit consent.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02056.html


A sub-thread discussed[3] the problem of out-of-sync mirrors and the use of the <code>--skip-broken</code> option with yum (see also this same FWN#156"YUM: Enable --skip-broken by Default?".)
[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02060.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00925.html
=== Exiv2 Bump in Rawhide ===


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01063.html
[[RexDieter|Rex Dieter]] announced[1] that a bump to <code>exiv2-0.18</code>[2] would occur soon including a soname bump. [[JonCiesla|Jon Ciesla]] offered to help and Rex produced[3] a quick list of dependent applications.


[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01314.html
When [[MatejCepl|Matej Cepl]] struggled with some odd results [[MichaelJChudobiak|Michael Chudobiak]] answered[4] that the API had changed a good deal.
 
 
=== Fedora Suckage ? ===
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02061.html
 
The tinder for this week's massive flamewar was laid[1] by [[RobertScheck|Robert Scheck]] in the form of a dryly ironic, multiple-topic rant. Robert attacked the use of "memory wasting" python daemons, lags in pushing updates compared to the <code>EPEL</code> repositories, lack of information on the recent intrusion, poor German translation, the minimal requirements for <code>LiveCD</code> usage, <code>RPM-4.6</code> bugs, Red Hat employees blocking Merge Reviews, <code>PackageKit</code> bugs, and the EU support organisation for Fedora[2]!
 
Although there were several worthy attempts to make use of the above material
for a true conflagration in general the opportunity was wasted and instead
several rational, civil discussions of possible underlying causes and explanations took place. There were some worthy attempts to respond to all parts of this portmanteau complaint, but for the most part the discussion fractured naturally into several threads.
 
One such thread was concerned with the pushing of a <code>D-Bus</code> update which broke many applications including <code>PackageKit</code>. [[KevinKofler|Kevin Kofler]] argued[3] that "[...] we need to be more careful with certain types of security updates, and better let them get some QA even if it means the fix gets delayed." [[MichaelSchwendt|Michael Schwendt]] asserted[4] the lack of active Quality Assurance as one of the contributing factors. KevinKofler explained[5] that the package had been rushed out "Because it was deemed a security update, complete with a CVE ID[.]" See this FWN#156 "The D-Bus Problem" for more details.
 
[[MaxSpevack|Max Spevack]] took up[6] the complaints about ''Fedora EMEA'' and more of that discussion continued[7] on the more appropriate @fedora-ambassadors list.
 
No further information on the security intrusion was forthcoming from [[PaulFrields|Paul Frields]] but he relayed[8] that the matter was not being forgotten or hushed up and that he planned to meet with others to discuss communication procedures for any possible future intrusions.
 
[[RichardHughes|Richard Hughes]] asked[9] for specific bugs to be filed instead of general rants: "[...] I think you need to write much shorter, to the point emails. Ranting doesn't have much affect on anything, whilst filing bugs and getting involved upstream does." He also corrected Robert that many of the daemons which he complained about were written in C, not in Python.
 
[[ColinWalters|Colin Walters]] issued[10] a mea culpa: "Just to be clear, the direct push into stable is my fault; not Red Hat's or other DBus developers or anyone else's. I had originally listed it for updates-testing, but then changed the update to security and in a moment of total stupidity also changed the listing for stable."
 
The idea of "repeatable updates" was raised[11] again by [[LesMikesell|Les Mikesell]] and critiqued for want of a practical implementation by [[JamesAntill|James Antill]]. [[JesseKeating|Jesse Keating]] made[12] a suggestion: "Treat rawhide as your 'new code' land, leave the release trees as your 'testing and working' code. That is don't be so goddamn eager to push new packages and new upstream releases to every freaking branch in existence."
 
[[BehdadEsfahbod|Behdad Esfahbod]] tackled[13] the issue of Red Hat employees allegedly stalling on merge reviews. Behdad criticized the jumbling together of so many issues and repudiated any suggestion that as the maintainer of un-reviewed packages he "[...] must incorporate the merge reviews and close them, no thank you, I don't mind not maintaining anything in Fedora, and I certainly didn't block anyone from making progress in the merge reviews. When you say `The Red Hat people have to follow the Fedora packaging guidelines and rules same as the Fedora folks', does it mean that Fedora should feel free to decide what *I* work on, when it doesn't decide what `other Fedora folks' work on? That doesn't feel right."
 
The criticism of <code>LiveCD</code> localization was handled[14] by [[JeroenvanMeeuwen|Jeroen van Meeuwen]] and he accepted that it would be useful if there were some manner in which the <code>Spin SIG</code> could create spins and torrent seeds outside of Fedora release engineering. It seemed that the need to make absolutely certain that such torrents and spins are kept available for support purposes may make this difficult.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00722.html
 
[2] EMEA is a non-profit organization with the mission to provide a focal-point and economic base for the European Fedora community. http://fedoraproject.org/wiki/Ambassadors/EMEA
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00733.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00753.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00855.html
 
[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00772.html
 
[7] https://www.redhat.com/archives/fedora-ambassadors-list/2008- December/msg00092.html
 
[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00773.html
 
[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00798.html


[10] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00812.html
[2] Exiv is a command-line utility for examining EXIF and IPTC metadata of images.


[11] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00832.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02068.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00913.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02244.html


[13] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00834.html
=== wxGTK2 to wxGTK Re-name ==


[14] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00899.html
[[MichaelSchwendt|Michael Schwendt]] discovered[1] that a rename had been performed[2] some time ago so that there was no <code>wxGTK2-devel</code> package available. [[DanHorák|Dan Horák]] explained[3] that only <code>audacity</code> was affected. There was[4] some discussion about whether versioned <code>Provides</code> should be kept indefinitely.


=== Help Needed: Sift "rawhide" for .pc Files ===
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01897.html


[[JesseKeating|Jesse Keating]] requested[1] "[...] somebody to examine all the packages in rawhide that provide .pc [pkg-config] files and ensure proper placement of them based on the review guideline. This will likely require interaction with the packages maintainer(s) so the first step should probably be to produce a list of packages that ship .pc in a non -devel package and send the list (sorted by maintainer) to here so that we can discuss and pick off items."
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01972.html


[[MichaelSchwendt|Michael Schwendt]] helped[2] to start the process by providing some lists of non-devel packages which included .pc files or had requires which pulled in packages which provided .pc files.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01975.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00612.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02046.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00648.html
=== RFC: Description Text in Packages ===


=== Offtrac ===
Follow-up action (see FWN#153[1]) was requested[2] by [[RichardHughes|Richard Hughes]] for packagers to fix "isane descriptions" in their package summary text. <code>Enlightenment</code> was singled out as an example of an undesirable multi-page description. Richard also asked for comments on how bullet-points should be represented and the use of <code>UTF-8</code>.


An itch scratched[1] by [[JesseKeating|Jesse Keating]] was to be able to interact with <code>Trac</code> via the commandline to create milestones for the Fedora 11 release cycle. He implemented his own python library, named Offtrac, to interact with <code>trac</code> using <code>XML-RPC</code> and asked for help in firming up the API and extending his client. Later Jesse explained[2] that the purpose was to "[...] make some aspects of using trac easier for folks, not just project owners but people who file tickets in track, like say for package tagging requests, or blocks, or... "
A heated discussion followed[3] in which [[NicolasMailhot|Nicolas Mailhot]] deprecated the possible development of a "broken application-side transcoding system". He advocated the use of <code>UTF-8</code> over <code>ASCII</code> for several reasons including supporting the default Asian locales. Paragraph boundaries and lists were also mentioned[4] as a special area of concern.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00738.html
This is a long and painful thread to read which expresses a conflict between constraints imposed by PackageKit and how things are currently done. Packagers should probably skim it to determine what final decisions are going to be made. [[RichardHughes|Richard Hughes]] seemed[5] to decide to implement what seemed to him to be sane changes to gnome-packagekit in which "If you're [g]oing to use [UTF-8 representations of skull-and-crossbones and radiation-hazard symbols] in a spec file, then the text box is going to look rubbish and be all on one line. If you use a description longer than a few hundred words, gnome-packagekit will truncate it."


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00808.html


=== Updates QA and Karma ===
[1] http://fedoraproject.org/wiki/FWN/Issue153#RFC:_Fix_Summary_Text_for_Lots_of_Packages


The updates system came in for some more questioning (see this FWN#156 "Making `updates-testing' More Useful") when [[OrionPoplawski|Orion Poplawski]] showed[1] that an <code>rpcbind</code> update for <code>Fedora 9</code> may have been pushed to stable despite comments made by him indicating that it failed due to a dependency. Orion asked two questions: "[1] Should update submitters be allowed to give positive karma to their updates? Seems like that they are too biased. [2] Is there any requirement that an update have positive karma before being pushed to stable?"
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01550.html


It appeared that ultimately monitoring of such pushes are down to package maintainers and depend upon the good judgment of those doing the updates. [[MichaelSchwendt|Michael Schwendt]] provided[2] an overview of the situation.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01555.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01298.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01577.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01427.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01927.html

Revision as of 17:01, 22 December 2008

Developments

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

Contributing Writer: Oisin Feeley

Nautilus Spatial-mode Flamewar

The tired, old topic of whether nautilus should use "spatial-mode" as a default was re-opened[1] by MarkG85 in the form of a request for list subscribers to "vote" on the mailing list for a reversion to "browser-mode". In spatial-mode nautilus opens a new window for each directory unless one middle-clicks or holds the shift key down.

It was pointed out by several contributors that voting "+/- 1" was not a recognized way to achieve change within the Fedora Project. Chris Adams asked[2] if he and his friends "[...] should [...] all spam fedora-devel with +1' and metoo' to change the default background color? What if it is 20 friends, or 100, or 500?" A similar point was made[3] by Jef Spaleta.

Dimi Paun expressed[4] frustration with what he charcaterized as "lame community involvenment" and several personal attacks were made on both the maintainer and other contributors who had deprecated the attempt to take a mailing list vote. After tempers had flared Jeff commented[5]: "Noone has figured out how to write a markup language for human intention...and as a result any passionate discussion degrades severely as we are wired to read intention but without body language and vocal ques...we absolutely do it wrong when relying solely on written language. Even more so with English! If we mandated everyone encode thought into Lisp we'd be having more constructive discussions (and less of them). The productivity of the list would be through the roof."

In response to a challenge to detail some advantages of spatial-mode Tomas Torcz was among those who offered[6] that the persistent screen placement of directory windows was a major advantage. He also suggested a way to avoid leaving multiple windows open: "When I open new window and don't want parent directory open, I just open with middle button. Some people prefer Shift+click in this situation. I never has to use `Close all parent folder' (ctrlshift-w), but I aware it exist." Joonas Sarajärvi confirmed[7] the persistence as an advantage: "[...] the state of each folder is persistent. Every window opens in the same view that it had when I reopen them. I can have appropriate zoom levels and views for every directory I commonly use."

Very much later in the thread, after he had been referred to several times, the package maintainer Alexander Larsson replied[8] that he was unconvinced both by the tone and content of the argument that there was a case to be made for changing the default.

It is possible to choose which behavior one wants by at least two methods. One can either use the GUI 

Nautilus -> Preferences -> Behavior -> Always open in browser windows

or else change the GConf setting using

gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true

As part of the argument involved a desire to be able to replicate these settings automatically and possibly distribute them to others Matthias Clasen suggested[9] that anyone wishing to make permanent change to the default settings could create a sabayon profile.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02089.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02286.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02305.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02416.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02392.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02387.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02213.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02189.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02389.html

Font Package Naming Guidelines

Nicholas Mailhot ensured[1] that everyone was made aware of the new font package naming rules for Fedora 11. These will help break up large font packages in order to allow users to obtain fonts from desired families without imposing a large download burden.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02597.html

How to become a Co-Maintainer

Ray Van Dolson asked[1] for some information on identifying the current (co)maintainers of the proftpd package, the procedure to become a co-maintainer and the abilities to push bugfixes which this would confer upon him if the primary maintainer were absent.

A full answer was provided[2] by Patrice Dumas with links to PackageDB and the policies on the wiki regarding non-responsive maintainers.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02253.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02255.html

Proposed Package Re-Naming Guidelines

Feedback was requested[1] by Kevin Fenzi on a draft guideline concerning the re-naming of packages either as a result of upstream action or locally to adhere to the NamingGuidelines.

Patrice Dumas and Dennis Gilmore remembered[2] that a re-review followed by EOL of the old package was the current practice.

Jason Tibbitts[3] and Jesse Keating[4] referenced IRC discussions of the practice and its advantages in checking the Obsoletes and Provides in discussion with Jochen Schmitt. Jochen was concerned[5] that the process be kept lightweight as opposed to a full review.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02052.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02054.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02058.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02056.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02060.html

Exiv2 Bump in Rawhide

Rex Dieter announced[1] that a bump to exiv2-0.18[2] would occur soon including a soname bump. Jon Ciesla offered to help and Rex produced[3] a quick list of dependent applications.

When Matej Cepl struggled with some odd results Michael Chudobiak answered[4] that the API had changed a good deal.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02061.html

[2] Exiv is a command-line utility for examining EXIF and IPTC metadata of images.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02068.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02244.html

= wxGTK2 to wxGTK Re-name

Michael Schwendt discovered[1] that a rename had been performed[2] some time ago so that there was no wxGTK2-devel package available. Dan Horák explained[3] that only audacity was affected. There was[4] some discussion about whether versioned Provides should be kept indefinitely.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01897.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01972.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01975.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02046.html

RFC: Description Text in Packages

Follow-up action (see FWN#153[1]) was requested[2] by Richard Hughes for packagers to fix "isane descriptions" in their package summary text. Enlightenment was singled out as an example of an undesirable multi-page description. Richard also asked for comments on how bullet-points should be represented and the use of UTF-8.

A heated discussion followed[3] in which Nicolas Mailhot deprecated the possible development of a "broken application-side transcoding system". He advocated the use of UTF-8 over ASCII for several reasons including supporting the default Asian locales. Paragraph boundaries and lists were also mentioned[4] as a special area of concern.

This is a long and painful thread to read which expresses a conflict between constraints imposed by PackageKit and how things are currently done. Packagers should probably skim it to determine what final decisions are going to be made. Richard Hughes seemed[5] to decide to implement what seemed to him to be sane changes to gnome-packagekit in which "If you're [g]oing to use [UTF-8 representations of skull-and-crossbones and radiation-hazard symbols] in a spec file, then the text box is going to look rubbish and be all on one line. If you use a description longer than a few hundred words, gnome-packagekit will truncate it."


[1] http://fedoraproject.org/wiki/FWN/Issue153#RFC:_Fix_Summary_Text_for_Lots_of_Packages

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01550.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01555.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01577.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01927.html

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=67205"