FWN/Beats/Developments: Difference between revisions

Revision as of 00:36, 11 January 2009

Developments

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

Contributing Writer: Oisin Feeley

Default ssh-agent Dialog Pop-up

Confusion abounded when user "nodata" reported[1] that running ssh-add from the command-line popped up a gnome dialog requesting his private SSH key. "nodata" disliked handing out his private key in such a manner. The confusion resulted from the availability of at least two possible ssh-agents[2] and also a change in configuration between Fedora 9 and Fedora 10 which presents the authentication dialog by default.

Ricky Zhou was among those who suggested (with a manpage quote) that the SSH_ASKPASS environment variable determined whether the passphrase was read from a terminal or by an X11 dialog. Separately Jesse Keating[3] and Nalin Dahyabhi explained[4] that the dialog was presented by gnome-keyring and not gnome-ssh-askpass.

"nodata" questioned[5] whether the behavior had changed between Fedora 9 and Fedora 10 and expressed irritation that a "[...] GUI is popping up when I am using a command line app." Jesse Keating responded[6]: "You're using a command line app from a graphical terminal. Also, cli apps aren't the only use for ssh and ssh keys." This did not appeal to many respondents including John Linville who questioned[7] the benefit of changing focus to a new window to type a passphrase. Callum Lerwick rather tartly outlined[8] some benefits including preventing key logging attacks.

Matthias Clasen suggested[9] using

gconftool-2 -s -t bool /apps/gnome-keyring/daemon-components/ssh false

to turn off the behavior for those who dislike it and this led to several requests to make this the default. Andrew Haley put[10] the case that "[t]he key argument against a pop-up dialog box that asks for the passphrase is that we're training people to type secrets into pop-up dialog boxes. Bad psychology, bad security."

][MatthiasClasen|Matthias Clasen]] and Tomas Mraz with Jerry Amundson explored[11] the use of SSH_ASKPASS as an alternate method to disable the GUI dialog.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00486.html

[2] Private keys are stored by ssh agents so that they may handle all key related operations requested by clients. The passphrase to decrypt the key thus need only be typed into the agent once instead of per-operation.

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00487.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00536.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00492.html

[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00495.html

[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00523.html

[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00533.html

[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00498.html

[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00517.html

[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00540.html

Intel Graphics Installation Woes

"Mike" requested[1] information on when a working xorg-x11-drv-i810 driver for Intel graphics chipsets had a chance of appearing. He was disappointed that it was non-trivial to get two machines with 82945G and 82845G chipsets installed and had needed to fall back to using the vesa driver instead of the intel one.

Others listed outstanding bugzilla entries for a wide range of Intel chipsets. Dan Williams asked[2] if using Option "EXANoComposite" "true" as a workaround for problems with the i830 chipsets was succesfull and received mixed reports. It seemed that he was making some progress with resolving some of the issues.

MAYoung suggested[3] that setting "NoAccel true" in xorg.conf might work for some people but that "[...] intel graphics are highly flaky on Fedora 10."

Robert Arendt laid[4] the blame at the door of upstream merges of GEM/DRM into the kernel and noted that other distributions were suffering identical problems. "Mike" later confirmed[5] this with a list of bugzilla entries from upstream GNOME: "It would be nice if Intel would help to get this fixed, and there are indeed problems with Suse, Ubuntu and Mandriva also with newer drivers and Intel graphics chipsets of various flavors - this is really bad!"

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00435.html

[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00475.html

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00443.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00445.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00467.html

KPackageKit Auto-update Bug

Michael B Allen reported[1] that his system had performed an update without his permission and asked how to completely disable such behavior.

It appeared[2] that this was due to a bug in KPackageKit which has been unfixable[3] for over a month due in part to the complexity of the code.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00461.html

[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00504.html

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00510.html

Disabling Staging Drivers ?

Rahul Sundaram asked[1] if enabling the many new drivers in the staging tree[2] would make sense in rawhide in order to support a wider range of hardware such as the EeePC's ralink wireless chipset.

Opinion was roughly split between those who were completely against the idea and those who suggested avoiding codifying a rigid policy. Matthew Garrett believed[3] that it would be "somewhat user-hostile" to, for example enable the ralink drivers in rawhide but possibly remove them for a general release. He argued that the ralink drivers were a dead-end[4] which would never merge upstream. On the other hand Dave Jones preferred[5] to take a case-by-case approach as long as "[...] we have someone responsible for working on it, with the goal of getting it out of staging, and dealing with bugs etc. Not unlike the same reasoning for us adding various not-yet-upstream drivers to the Fedora kernel really."

While preferring to completely disable the staging drivers Thorsten Leemhuis expressed[6] the intention to provide RPM Fusion kmods in that case. Dan Williams made[7] a strong argument that "-staging" itself was a bad idea as it gave "legitimacy to drivers of questionable quality" and John Linville limned[8] the tortured history of the at76 driver.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00459.html

[2] "linux-staging" is a kernel tree whose purpose is to test drivers and filesystems for later inclusion in mainline http://lkml.org/lkml/2008/6/10/329

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00462.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00474.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00472.html

[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00465.html

[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00473.html

[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00476.html

git-* Commands Moved to /usr/libexec/git-core/

Adam Tkac worried[1] that scripts would break due to the latest git branch in rawhide which had moved all the git-* binaries to /usr/libexec/git-core in order to comply with upstream practice. The issue was previously discussed (see FWN#141[2)] with the resolution that updating to git-1.6.0 would be a flag day for this change. Adam suggested that the new location could be added to the PATH environment variable but this received no support.

Karel Zak advocated[3] that such scripts should be fixed as the change had been coming since 2006.

Bryn Reeves wondered[4] if compatibility symlinks and a release note would ease the transition over a couple of releases. Although the symlinks were generally felt to be a non-effective strategy Todd Zulinger was encouraged[5] by Paul W. Frields to open a bugzilla entry against the Release Notes to ensure that the documentation team take care of highlighting the issue for Fedora 11.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00404.html

[2] http://fedoraproject.org/wiki/FWN/Issue141#Git-1.6.0_Commands_to_be_Moved_Out_of_PATH

[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00408.html

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00410.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00460.html

Mandatory FHS Adherence

JasonTibbitts posted[1] a summary and links to the 2009-01-06 FPC meeting deliberations. Interest on @fedora-devel was mostly sparked by the item which declared that the FPC would "Make adherence to the FHS a MUST [.]" Jason encouraged reading of the full minutes in order to understand this item.

Doug Ledford discussed[2] the problem his MPI[3] implementations experienced with the FHS and Richard W. M. Jones expressed [4] concern that the FHS was a moribund standard and adhering to it would block projects such as MinGW without any method to evolve the standard. Toshio Kuratomi responded in detail in both threads and pointed out[5] that the MinGW case had been addressed in the meeting and also that there were problems with changing the FHS.

[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00362.html

[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00424.html

[3] http://www.open-mpi.org/papers/ipdps-2006/

[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00469.html

[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00483.html

@@ Line 7: / Line 7: @@
 Contributing Writer: [[OisinFeeley|Oisin Feeley]]
-=== Nautilus Spatial-mode Flamewar ===
+=== Default ssh-agent Dialog Pop-up ===
-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.
+Confusion abounded when user "nodata" reported[1] that running <code>ssh-add</code> from the command-line popped up a gnome dialog requesting his private SSH key. "nodata" disliked handing out his private key in such a manner. The confusion resulted from the availability of at least two possible <code>ssh-agents</code>[2] and also a change in configuration between <code>Fedora 9</code> and <code>Fedora 10</code> which presents the authentication dialog by default.
-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]].
+[[RickyZhou|Ricky Zhou]] was among those who suggested (with a manpage quote) that the <code>SSH_ASKPASS</code> environment variable determined whether the passphrase was read from a terminal or by an X11 dialog. Separately [[JesseKeating|Jesse Keating]][3] and [[NalinDahyabhai|Nalin Dahyabhi]] explained[4] that the dialog was presented by <code>gnome-keyring</code> and not <code>gnome-ssh-askpass</code>.
-[[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."
+"nodata" questioned[5] whether the behavior had changed between <code>Fedora 9</code> and <code>Fedora 10</code> and expressed irritation that a "[...] GUI is popping up when I am using a command line app." [[JesseKeating|Jesse Keating]] responded[6]: "You're using a command line app from a graphical terminal. Also, cli apps aren't the only use for ssh and ssh keys." This did not appeal to many respondents including [[JohnLinville|John Linville]] who questioned[7] the benefit of changing focus to a new window to type a passphrase. [[CallumLerwick|Callum Lerwick]] rather tartly outlined[8] some benefits including preventing key logging attacks.
-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."
+[[MatthiasClasen|Matthias Clasen]] suggested[9] using
+<pre>
+gconftool-2 -s -t bool /apps/gnome-keyring/daemon-components/ssh false
+</pre>
+to turn off the behavior for those who dislike it and this led to several requests to make this the default. [[AndrewHaley|Andrew Haley]] put[10] the case that "[t]he key argument against a pop-up dialog box that asks for the passphrase is that we're training people to type secrets into pop-up dialog boxes. Bad psychology, bad security."
-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.
+][MatthiasClasen|Matthias Clasen]] and [[TomasMraz|Tomas Mraz]] with [[JerryAmundson|Jerry Amundson]] explored[11] the use of <code>SSH_ASKPASS</code> as an alternate method to disable the GUI dialog.
-It is possible to choose which behavior one wants by at least two methods. One can either use the <code>GUI</code>
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00486.html
-<pre>Nautilus -> Preferences -> Behavior -> Always open in browser windows</pre>
+[2] Private keys are stored by ssh agents so that they may handle all key related operations requested by clients. The passphrase to decrypt the key thus need only be typed into the agent once instead of per-operation.
-or else change the <code>GConf</code> setting using
+[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00487.html
-<code>gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true</code>
+[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00536.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.
+[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00492.html
-[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02089.html
+[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00495.html
-[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02286.html
+[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00523.html
-[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02305.html
+[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00533.html
-[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02416.html
+[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00498.html
-[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02392.html
+[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00517.html
-[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02387.html
+[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00540.html
-[7] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02213.html
+=== Intel Graphics Installation Woes ===
-[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02189.html
+"Mike" requested[1] information on when a working <code>xorg-x11-drv-i810</code> driver for Intel graphics chipsets had a chance of appearing. He was disappointed that it was non-trivial to get two machines with <code>82945G</code> and <code>82845G</code> chipsets installed and had needed to fall back to using the <code>vesa</code> driver instead of the intel one.
-[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02389.html
+Others listed outstanding bugzilla entries for a wide range of Intel chipsets. [[DanWilliams|Dan Williams]] asked[2] if using Option "EXANoComposite" "true" as a workaround for problems with the <code>i830</code> chipsets was succesfull and received mixed reports. It seemed that he was making some progress with resolving some of the issues.
-=== Font Package Naming Guidelines ===
+MAYoung suggested[3] that setting "NoAccel true" in <code>xorg.conf</code> might work for some people but that "[...] intel graphics are highly flaky on Fedora 10."
-[[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.
+[[RobertArendt|Robert Arendt]] laid[4] the blame at the door of upstream merges of <code>GEM/DRM</code> into the kernel and noted that other distributions were suffering identical problems. "Mike" later confirmed[5] this with a list of bugzilla entries from upstream GNOME: "It would be nice if Intel would help to get this fixed, and there are indeed problems with Suse, Ubuntu and Mandriva also with newer drivers and Intel graphics chipsets of various flavors - this is really bad!"
-[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02597.html
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00435.html
-=== How to become a Co-Maintainer ===
+[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00475.html
-[[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.
+[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00443.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.
+[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00445.html
-[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02253.html
+[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00467.html
-[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02255.html
+=== KPackageKit Auto-update Bug ===
-=== Proposed Package Re-Naming Guidelines ===
+[[MichaelAllen|Michael B Allen]] reported[1] that his system had performed an update without his permission and asked how to completely disable such behavior.
-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]].
+It appeared[2] that this was due to a bug in <code>KPackageKit</code> which has been unfixable[3] for over a month due in part to the complexity of the code.
-[[PatriceDumas|Patrice Dumas]] and [[DennisGilmore|Dennis Gilmore]] remembered[2] that a re-review followed by EOL of the old package was the current practice.
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00461.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.
+[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00504.html
-[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02052.html
+[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00510.html
-[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02054.html
+=== Disabling Staging Drivers ? ===
-[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02058.html
+[[RahulSundaram|Rahul Sundaram]] asked[1] if enabling the many new drivers in the staging tree[2] would make sense in <code>rawhide</code> in order to support a wider range of hardware such as the <code>EeePC</code>'s <code>ralink</code> wireless chipset.
-[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02056.html
+Opinion was roughly split between those who were completely against the idea and those who suggested avoiding codifying a rigid policy. [[MatthewGarrett|Matthew Garrett]] believed[3] that it would be "somewhat user-hostile" to, for example enable the <code>ralink</code> drivers in <code>rawhide</code> but possibly remove them for a general release. He argued that the <code>ralink</code> drivers were a dead-end[4] which would never merge upstream. On the other hand [[DaveJones|Dave Jones]] preferred[5] to take a case-by-case approach as long as "[...] we have someone responsible for working on it, with the goal of getting it out of staging, and dealing with bugs etc. Not unlike the same reasoning for us adding various not-yet-upstream drivers to the Fedora kernel really."
-[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02060.html
+While preferring to completely disable the staging drivers [[ThorstenLeemhuis|Thorsten Leemhuis]] expressed[6] the intention to provide <code>RPM Fusion</code> <code>kmods</code> in that case. [[DanWilliams|Dan Williams]] made[7] a strong argument that "-staging" itself was a bad idea as it gave "legitimacy to drivers of questionable quality" and [[JohnLinville|John Linville]] limned[8] the tortured history of the <code>at76</code> driver.
-=== Exiv2 Bump in Rawhide ===
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00459.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.
+[2] "linux-staging" is a kernel tree whose purpose is to test drivers and filesystems for later inclusion in mainline http://lkml.org/lkml/2008/6/10/329
-When [[MatejCepl|Matej Cepl]] struggled with some odd results [[MichaelJChudobiak|Michael Chudobiak]] answered[4] that the API had changed a good deal.
+[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00462.html
-[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.
+[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00474.html
-[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02068.html
+[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00472.html
-[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02244.html
+[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00465.html
-=== wxGTK2 to wxGTK Re-name ===
+[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00473.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.
+[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00476.html
-[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01897.html
+=== git-* Commands Moved to /usr/libexec/git-core/ ===
-[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01972.html
+[[AdamTkac|Adam Tkac]] worried[1] that scripts would break due to the latest git branch in rawhide which had moved all the <code>git-*</code> binaries to <code>/usr/libexec/git-core</code> in order to comply with upstream practice. The issue was previously discussed (see FWN#141[2)] with the resolution that updating to <code>git-1.6.0</code> would be a flag day for this change. Adam suggested that the new location could be added to the <code>PATH</code> environment variable but this received no support.
-[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01975.html
+[[KarelZak|Karel Zak]] advocated[3] that such scripts should be fixed as the change had been coming since 2006.
-[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg02046.html
+[[BrynReeves|Bryn Reeves]] wondered[4] if compatibility symlinks and a release note would ease the transition over a couple of releases. Although the symlinks were generally felt to be a non-effective strategy [[ToddZulinger|Todd Zulinger]] was encouraged[5] by [[PaulFrields|Paul W. Frields]] to open a bugzilla entry against the Release Notes to ensure that the documentation team take care of highlighting the issue for <code>Fedora 11</code>.
-=== RFC: Description Text in Packages ===
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00404.html
-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>.
+[2] http://fedoraproject.org/wiki/FWN/Issue141#Git-1.6.0_Commands_to_be_Moved_Out_of_PATH
-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.
+[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00408.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."
+[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00410.html
+[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00460.html
-[1] http://fedoraproject.org/wiki/FWN/Issue153#RFC:_Fix_Summary_Text_for_Lots_of_Packages
+=== Mandatory FHS Adherence ===
-[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01550.html
+[[JasonLTibbittsIII|JasonTibbitts]] posted[1] a summary and links to the 2009-01-06 FPC meeting deliberations. Interest on @fedora-devel was mostly sparked by the item which declared that the FPC would "Make adherence to the FHS a MUST [.]" Jason encouraged reading of the full minutes in order to understand this item.
-[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01555.html
+[[DougLedford|Doug Ledford]] discussed[2] the problem his MPI[3] implementations experienced with the FHS and [[RichardJones|Richard W. M. Jones]] expressed [4] concern that the FHS was a moribund standard and adhering to it would block projects such as MinGW without any method to evolve the standard. [[ToshioKuratomi|Toshio Kuratomi]] responded in detail in both threads and pointed out[5] that the MinGW case had been addressed in the meeting and also that there were problems with changing the FHS.
-[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01577.html
+[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00362.html
-[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01927.html
+[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00424.html
+[3] http://www.open-mpi.org/papers/ipdps-2006/
+[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00469.html
+[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00483.html

Search