FWN/Beats/Developments: Difference between revisions

Revision as of 01:14, 17 November 2008

Developments

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

Contributing Writer: Oisin Feeley

Features Policy Modified

The latest FESCo discussions (2008-11-12) clarified[1] the Features[2] process. The changes make explicit the need for testing to be complete one week prior to the final freeze. Failure to meet that condition can result in FESCo deciding to drop the feature or implement a contingency plan or other suitable action.

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

[2] Features are "a significant change or enhancement to the version of Fedora currently under development": http://fedoraproject.org/wiki/Features/Policy/Definitions

The spur to these discussions was several last-minute changes for Fedora 10 which included dropping the instant-messaging client Empathy as the default, and the late addition of LiveConnect (see FWN#151[3]) and AMQP[4]. Earlier confusion about the Feature process had been expressed (see FWN#147[5]) after the decision to drop the Lightweight X11 Desktop Environment as a feature.

[3] http://fedoraproject.org/wiki/FWN/Issue151#LiveConnect_Feature_Approved_for_Fedora_10

[4] The Advanced Messaging Queue Protocol is a vendor-neutral middleware transport for business processes: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol

[5] http://fedoraproject.org/wiki/FWN/Issue147#LXDE_Feature_Removal_Disappointment_-_How_to_Avoid

The other major changes to the process include the emailing of the Feature owner to inform them when their feature is being discussed by FESCo and any decisions made concerning said feature. The extra work involved in tracking down email addresses was anticipated to be an over-burdening of the committee chair, Brian Pepple To ease this problem it was decided that Feature owners must include current email addresses on their Feature pages.

Server SIG

DanHorák announced[1] that a "[...] formal entity to coordinate [...] the server fundamentals that later create a successful enterprise product [...]" had been launched as a SIG. He invited constructive ideas and the wiki page[2] suggests that the SIG has many important initial goals including: a spin for headless servers, CLI equivalents of GUI tools, a lightweight installer and maintenance of the /etc/sysconfig/network-scripts.

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

[2] https://fedoraproject.org/wiki/DanHorak/ServerSIG

The extensive discussion which followed mostly consisted of approval for the idea. Dennis Gilmore expressed[3] enthusiasm for the general idea and specifically requested kickstart files for different types of servers and "best practice" whitepapers. An example of one of the issues the SIG might deal with was[4] the observation by Chris Adams that an installation of ntop had resulted in seventy dependencies, including metacity, being pulled down. Peter Robinson attributed[5] this to graphviz and suggested that while such problems were declining in number it would be useful for the ServerSIG to co-ordinate bug filing for these issues. Chris provided[6] a script which allowed test installs into a subdirectory to determine "what gets pulled in." Later James Antill mentioned two useful scripts written by himself and Seth Vidal which show package dependencies and provides as a tree structure. Dominik "rathan" Mierzejewski added[7] a mention of rpmreaper, a utility which eases the removal of unnecessary dependencies.

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

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

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

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

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

After Chris observed that "[w]ith rawhide, it appears impossible to install a kernel without pulling in X libraries (because of plymouth), so I guess the base X libraries can be considered "core" now" the conversation took a more adversarial turn. The accuracy of this statement turned out[8] to depend on whether libpng and pango were considered to be "X libraries" and Chris demonstrated the dependency chain as originating with the plymouth-plugin-solar. Les Mikesell commented[9]: "This is all pretty strange from a server perspective. And plymouth is there to keep the screen from blinking while you boot?" When Jesse Keating replied that Plymouth "handl[ed] the passphrase prompting for encrypted volumes" Les argued[10] that it should be optional for remote, headless boxes. Dominik "rathann" Mierzejewski was shocked[11] when Jesse Keating pointed out that plymouth also provided working /var/log/boot.logs: " Hm, you're right, all my boot.log files are 0 bytes (F-9). So instead of fixing the bug, a new package was introduced? Amazing." Dominik's dissatisfaction continued[12] to be unabated when he was informed that the absence of the kernel commandline parameter "rhgb" would result in plymouthd running but without any graphical plugins.

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

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

[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00795.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00814.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00859.html

The automatic selection of plymouth-plugin-solar as opposed to the alternate "plymouth-text-and-details-only" resulted[13] in a discussion around whether it was possible to make yum behave differently in such ambiguous situations. Enrico Scholz wished to add a "fail, warn and/or prompt when multiple packages satisfy a (virtual) dependency[.]" Seth Vidal reminded[14] him that the constraint of non-interactive defaults meant that this might not work. James Antill posted[15] that he had a patch to yum which "[...] would allow Fedora (or any active repo.) to configure these choices manually. We could then also easily have different defaults for the desktop vs. the server spins." James received some questions from Jesse Keating and Bill Nottingham who asked how per-spin defaults would be stored and how to deal with conflicting information from multiple repositories. His answer suggested[16] that introducing new repositories for the metadata or changing its syntax would be necessary.

[13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00858.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00907.html

[15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00995.html

[16] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01030.html

Dan Horák's desire to remove plymouth entirely was dismissed[17] as non-optional by Bill Nottingham as it will take on an even more important role in storage handling in the future. Bill suggested that the default plugin was optional however. He reassured[18] Dan that as regards headless machines there had been "[...] some testing on PPC boxes via serial/hvc consoles. Please test that it works in your scenarios as well, of course." When Enrico Scholz rejected disk encryption as important for servers Jesse Keating made[19] the case that "In a colo environment I /would/ want some encryption on the disk, and if I have to use a remote kvm to input the passphrase at reboot time, that's OK. Reboots are either planned events, or emergencies, both of which are going to require the attention of the people who have the passphrase." Alan Cox backed[20] this up: "If you are storing personal data on a system in a colo its practically mandatory to have encryption, and if you are storing anything sensitive its a big deal indeed - at least in those parts of the world with real data and privacy law ;)"

[17] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00784.html

[18] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00792.html

[19] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00798.html

[20] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00823.html

The thread continued in fits and starts. Adam Tkac raised[21] the problem of handling static IPs with NetworkManager (see this same FWN#152 "NetworkManager keyfiles for Pre-login Static Routes" for a discussion of as yet undocumented features). Chuck Anderson disputed[22] that the problem existed and provided commandline and GUI solutions: "[...] for system-wide connections which you would presumably want for a server, you edit /etc/sysconfig/networkscripts/ifcfg-* as usual and NM will bring the interface up at boot. From the desktop, you can Edit Connections and create a new static connection and select it instead of the System or Auto connection which is very handy when moving between networks that don't support DHCP."

An important addendum was provided[23] by Olivier Galibert "Try a "chkconfig -list network". It should be on for levels 2-5. If it isn't, you haven't enabled the old-style networking [.]" The same point was made by Chuck[24] "Are you using NetworkManager or network service? chkconfig -list NetworkManager; chkconfig -list network If NetworkManager is enabled and network is not, then you need to change ifcfg-eth0: NM_CONTROLLED=yes" and by Bill Nottingham[25] "You need to either set NM_CONTROLLED to something other than 'no', or enable the 'network' service. In either case, NM's static network support is not your problem."

[21] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00863.html

[22] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00871.html

[23] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00892.html

[24] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00887.html

[25] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00938.html

The LSB[26] also came in for a bashing due to infrequently used, old tools (such as ypbind and the insecure r-commands) being installed to achieve compliance. Patrice Dumas clarified[27] that ypbind was necessary in @base to provide NIS functionality. Later discussion separated[28] out LSB-Core and LSB-Desktop which should simplify making a minimal install LSB compliant. Bill Nottingham and Chris Adams performed[29] a dissection of @core with the intent of separating out items such as hdparm , prelink , dhclient , ed and others into @base.

[26] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00718.html

[27] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00753.html

[28] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00759.html

[29] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00802.html

Jeremy Katz outlined[30][31] a perspective from the Quality Assurance point of view. The burden imposed by preserving the modularity that many of the participants advocated sounds quite high: "[...] trying to preserve that modularity combinatorially adds to the testing matrix and also makes it significantly more difficult to write code since you can no longer depend on functionality. It also makes things slower as you have to conditionally check for things constantly [...] It's more than just /etc/init.d/network that has to be maintained. There's oodles of stuff in install-time configuration that will have to be maintained, tested, and have things fixed when people report them." Seth Vidal acknowledged[32] this but cautioned against dismissing the objections to particular changes as merely "neoluddite".

[30] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01023.html

[31] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01025.html

[32] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01027.html

The massive thread included much more discussion and resists easy summary. Those interested should probably plow through the messages. Among the issues raised were finding DBus documentation[33] and contention between class devices to set default routes[34].

A quote from DanHorak which seems to offer the perspective of the ServerSIG concisely is appropriate in closing: "It is really time to look back at the roots of Unix systems. It should be a combination of small pieces with well defined interfaces doing well their tasks. Only the time had changed those pieces from simple command line utilities to more complex ones."

[33] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01071.html

[34] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00911.html

NetworkManager keyfiles for Pre-login Static Routes

In the course of the ServerSIG discussions (see this same FWN#152 "Server SIG") an interesting question about NetworkManager was asked[1] by Les Mikesell: "If you bring up a mix of static and dynamically assigned interfaces, can you control which gets to assign the default route and DNS servers?"

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

Dan Williams provided[2] a useful description of how NetworkManager currently decides the default route. In response to Olivier Galibert he added[3] that static routes could be set up using the "[...] connection editor see the "Routes..." button in the IPv4 tab. Routes from ifcfg files aren't yet supported, but could be. Routes from keyfile-based system connections (ie, prelogin) are supported." After this tidbit Chuck Anderson prodded[4] Dan into explaining that keyfiles were a way to support things like "VPN, 3G, WPA" which were difficult or impossible to support with the ifcfg files in /etc/sysconfig/network-scripts. "NM has a system settings 'keyfile' plugin that allows editing system connections from the connection editor, or your favorite text editor if you don't use a GUI at all. Add `keyfile' to the -plugins argument in the /usr/share/dbus-1/systemservices/org.freedesktop.NetworkManagerSystemSettings.service file, and then 'killall -TERM nm-system-settings'."

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

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

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

Jesse Keating wondered when and where the documentation for this was placed and Dan replied[5] "[w]hen I struggle up for air from the tarpit that is the concurrent release of NM 0.7 + F10 + RHEL 5.3? :) "

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

Flash 10 in 64-bit Fedora 9

Jos Vos asked[1] for comparative data on using nspluginwrapper with Firefox to access Flash content in 64-bit Fedora 9. He was experiencing "[...] error messages about not finding 'soundwrapper' in my $PATH [.]"

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

Although Chris Adams reported success Orcan Ogetbil described[2] a "gray rectangle bug" which seemed to be manifested mostly when multiple tabs were open. Brennan Ashton claimed[3] that it was due to a PulseAudio "bug".

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

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

Ignacio Vazquez-Abrams and others reported[4] no problems and Jos posted[5] that there appeared to be a dependency on libcurl.i386 in the Adobe supplied rpm. This was later stated[6] by Paul Howarth to be changed so that either libcurl.so.3 or libcurl.so.4 will be used via a dlopen() and there is no explicit requires:libcurl in the rpm. Gianluca Szforna supplied[7] a link[8] which suggests that libflashsupport should be completely removed as it may cause crashes.

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

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

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

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

[8] http://macromedia.mplug.org/

@@ Line 7: / Line 7: @@
 Contributing Writer: [[OisinFeeley|Oisin Feeley]]
-=== Security Exceptions to the Mass ACL Opening ===
+=== Features Policy Modified ===
-[[MichaelDeHaan|MichaelDeHaan]] initiated[1] discussion on why he had chosen not to open access (previously covered in FWN#148[2], FWN#136[3]) on some of his systems management software packages. His main reasoning was that obtaining provenpackager[4] status was too easy and could lead to at least two undesirable security outcomes: "(A) provenpackager decides to correct what he thinks is an rpmlint error and thus unintentionally breaks the security of the packaged application, (B) credentials of provenpackager are compromised allowing $evil to replace the contents of a said package. In either case, the change could either be making a new release of an application (which contains an exploit and/or unwitting bug), or updating the specfile in a way that breaks file permissions in a way that may not be immediately obvious (whether intentional or not)." The packages omitted by Michael were <code>koan</code>, <code>cobbler</code>, <code>func</code> and <code>certmaster</code> all of which could, if compromised, "[...] allow reprogramming of an entire datacenter in very easy steps."
+The latest FESCo discussions (2008-11-12) clarified[1] the Features[2] process. The changes make explicit the need for testing to be complete one week prior to the final freeze. Failure to meet that condition can result in FESCo deciding to drop the feature or implement a contingency plan or other suitable action.
-[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00382.html
+[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00847.html
-[2] http://fedoraproject.org/wiki/FWN/Issue148#The_Big_ACL_Opening
+[2] Features are "a significant change or enhancement to the version of Fedora currently under development": http://fedoraproject.org/wiki/Features/Policy/Definitions
-[3] http://fedoraproject.org/wiki/FWN/Issue136#New_libraw1394_Rebuild_Exposes_Closed_ACLs
+The spur to these discussions was several last-minute changes for Fedora 10 which included dropping the instant-messaging client Empathy as the default, and the late addition of LiveConnect (see FWN#151[3]) and AMQP[4]. Earlier confusion about the Feature process had been expressed (see FWN#147[5]) after the decision to drop the Lightweight X11 Desktop Environment as a feature.
-[4] After a flamewar (see FWN#148 "PackageGurus, SpecMentats or UeberPackagers?") the group name for packagers with access to any package in CVS is provenpackager: https://fedorahosted.org/packagedb/browser/fedora-packagedb-stable/ChangeLog#L45
+[3] http://fedoraproject.org/wiki/FWN/Issue151#LiveConnect_Feature_Approved_for_Fedora_10
-[[ToshioKuratomi|Toshio Kuratomi]] shared[5] Michael's concerns but pointed out that it would be possible to introduce compromised code into his packages' dependencies: "I'd like to mention, though, that func depends on the following packages with open acls: pyOpenSSL, python, python-simplejson So in terms of protecting against $EVIL, restricting provenpackager isn't very effective."
+[4] The Advanced Messaging Queue Protocol is a vendor-neutral middleware transport for business processes: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
-[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00384.html
+[5] http://fedoraproject.org/wiki/FWN/Issue147#LXDE_Feature_Removal_Disappointment_-_How_to_Avoid
-[[DanielBerrange|Daniel Berrange]] thought[6] it would be more effective to have more co-maintainers: "The ideal should be for every package in the distro to have at least 1 extra comaintainer, or preferrably 3 or 4. People with a little domain knowledge for the package who can handle both the low-hanging fruit the main maintainer misses, with less risk of making mistakes due to lack of package specific knowledge." Toshio countered[7] with a detailed reply which investigated the problems of non-responsiveness and trust which would be encountered by such a change. [[MichaelSchwendt|Michael Schwendt]] added[8] his experiences of the practical problems involving non-responsive maintainers and the difficulty of informing people without overloading them.
+The other major changes to the process include the emailing of the Feature owner to inform them when their feature is being discussed by FESCo and any decisions made concerning said feature. The extra work involved in tracking down email addresses was anticipated to be an over-burdening of the committee chair, [[BrianPepple.|Brian Pepple]] To ease this problem it was decided that Feature owners must include current email addresses on their Feature pages.
-[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00387.html
+=== Server SIG ===
-[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00392.html
+DanHorák announced[1] that a "[...] formal entity to coordinate [...] the server fundamentals that later create a successful enterprise product [...]" had been launched as a SIG. He invited constructive ideas and the wiki page[2] suggests that the SIG has many important initial goals including: a spin for headless servers, CLI equivalents of GUI tools, a lightweight installer and maintenance of the <code>/etc/sysconfig/network-scripts</code>.
-[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00405.html
+[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00645.html
-[[JesseKeating|Jesse Keating]] returned[9] to the main topic and remarked that he agreed with [[MichaelDeHaan|Michael DeHaan's]] logic with regard to these specific packages but that membership of "provenpackagers" was now obtainable by requesting membership via the account system and approval of said request by a provenpackager. The requirement to have at least five packages was merely for initial seeding.
+[2] https://fedoraproject.org/wiki/DanHorak/ServerSIG
-[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00385.html
+The extensive discussion which followed mostly consisted of approval for the idea. [[DennisGilmore|Dennis Gilmore]] expressed[3] enthusiasm for the general idea and specifically requested kickstart files for different types of servers and "best practice" whitepapers. An example of one of the issues the SIG might deal with was[4] the observation by [[ChrisAdams|Chris Adams]] that an installation of <code>ntop</code> had resulted in seventy dependencies, including <code>metacity</code>, being pulled down. [[PeterRobinson|Peter Robinson]] attributed[5] this to <code>graphviz</code> and suggested that while such problems were declining in number it would be useful for the ServerSIG to co-ordinate bug filing for these issues. Chris provided[6] a script which allowed test installs into a subdirectory to determine "what gets pulled in." Later [[JamesAntill|James Antill]] mentioned two useful scripts written by himself and [[SethVidal|Seth Vidal]] which show package dependencies and provides as a tree structure. [[DominikMierzejewski|Dominik "rathan" Mierzejewski]] added[7] a mention of <code>rpmreaper</code>, a utility which eases the removal of unnecessary dependencies.
-[[TimLauridsen|Tim Lauridsen]] wondered[10] when co-maintainers would be enabled to submit updates to packages through <code>bodhi</code> and subsequent discussion with [[MichaelSchwendt|Michael Schwendt]] suggested that it should be possible. [[KevinKofler|Kevin Kofler]] had similar concerns and Michael shared[11] the last public information on the topic which was that anyone with commit access to the devel branch can submit updates.
+[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00652.html
-[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00407.html
+[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00730.html
-[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00411.html
+[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00736.html
-=== Who Moved My Bug ? ===
+[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00778.html
-[[DebarshiRay|Debarshi Ray's]] question sounded[1] alluringly like a parody of a self-help book but expressed genuine concern over why the status of bugs assigned to him were being changed. [[TillMaas|Till Maas]] reassured[2] Debarshi that the status ASSIGNED means "that the bug has been triaged, i.e. it is assigned to the rigth component and all necessary information is provided. A member of the Fedora Triage Team probably did the changes to your bugs [,]" he included a useful link[3] to the BugZappers wikipage. [[BrynReeves|Bryn Reeves]] explained[4] how to see every change made to a bug. [[JohnPoelstra|John Poelstra]] also suggested[5] using the "history" link and explained that the use of the "FutureFeature" keyword was to insure that bugs would continue to be given the version "rawhide" even after the GA release of <code>Fedora 10</code>.
+[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00932.html
-[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00273.html
+After Chris observed that "[w]ith rawhide, it appears impossible to install a kernel without pulling in X libraries (because of plymouth), so I guess the base X libraries can be considered "core" now" the conversation took a more adversarial turn. The accuracy of this statement turned out[8] to depend on whether <code>libpng</code> and <code>pango</code> were considered to be "X libraries" and Chris demonstrated the dependency chain as originating with the <code>plymouth-plugin-solar</code>. [[LesMikesell|Les Mikesell]] commented[9]: "This is all pretty strange from a server perspective. And plymouth is there to keep the screen from blinking while you boot?" When [[JesseKeating|Jesse Keating]] replied that Plymouth "handl[ed] the passphrase prompting for encrypted volumes" Les argued[10] that it should be optional for remote, headless boxes. [[DominikMierzejewski|Dominik "rathann" Mierzejewski]] was shocked[11] when [[JesseKeating|Jesse Keating]] pointed out that <code>plymouth</code> also provided working <code>/var/log/boot.log</code>s: " Hm, you're right, all my boot.log files are 0 bytes (F-9). So instead of fixing the bug, a new package was introduced? Amazing." Dominik's dissatisfaction continued[12] to be unabated when he was informed that the absence of the kernel commandline parameter "rhgb" would result in <code>plymouthd</code> running but without any graphical plugins.
-[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00274.html
+[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00787.html
-[3] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
+[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00787.html
-[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00279.html
+[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00795.html
-[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00290.html
+[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00814.html
-It appeared[6] that this was a different process to that used to handle package review submissions and this had difference had caused some confusion.  Confusion also reigned[7] about when this use of the ASSIGNED keyword had become standard and [[DominikMierzejewski|Dominik Mierzejewski]] argued[8] that it had not been approved by FESCo, but [[BrianPepple|Brian Pepple]] posted the FESCo logs and [[JesseKeating|Jesse Keating]] suggested[9] following the discussions on @fedora-devel. Dominik declined to rely on following such a high-volume list and [[SteveGrubb|Steve Grubb]] agreed[10].
+[12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00859.html
-[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00325.html
+The automatic selection of <code>plymouth-plugin-solar</code> as opposed to the alternate "plymouth-text-and-details-only" resulted[13] in a discussion around whether it was possible to make <code>yum</code> behave differently in such ambiguous situations. [[EnricoScholz|Enrico Scholz]] wished to add a "fail, warn and/or prompt when multiple packages satisfy a (virtual) dependency[.]" [[SethVidal|Seth Vidal]] reminded[14] him that the constraint of non-interactive defaults meant that this might not work. [[JamesAntill|James Antill]] posted[15] that he had a patch to <code>yum</code> which "[...] would allow Fedora (or any active repo.) to configure these choices manually. We could then also easily have different defaults for the desktop vs. the server spins." James received some questions from [[JesseKeating|Jesse Keating]] and [[BillNottingham|Bill Nottingham]] who asked how per-spin defaults would be stored and how to deal with conflicting information from multiple repositories. His answer suggested[16] that introducing new repositories for the metadata or changing its syntax would be necessary.
-[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00285.html
+[13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00858.html
-[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00285.html
+[14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00907.html
-[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00310.html
+[15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00995.html
-[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00420.html
+[16] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01030.html
-[[KevinKofler|Kevin Kofler]] added[11] some useful information for those working in teams: "[...] when you're actively working on fixing something (so you don't duplicate work in the team), you can use the ON_DEV status for that purpose."
-[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00283.html
+[[DanHorák|Dan Horák's]] desire to remove <code>plymouth</code> entirely was dismissed[17] as non-optional by [[BillNottingham|Bill Nottingham]] as it will take on an even more important role in storage handling in the future. Bill suggested that the default plugin was optional however. He reassured[18] Dan that as regards headless machines there had been "[...] some testing on PPC boxes via serial/hvc consoles. Please test that it works in your scenarios as well, of course." When [[EnricoScholz|Enrico Scholz]] rejected disk encryption as important for servers [[JesseKeating|Jesse Keating]] made[19] the case that "In a colo environment I /would/ want some encryption on the disk, and if I have to use a remote kvm to input the passphrase at reboot time, that's OK. Reboots are either planned events, or emergencies, both of which are going to require the attention of the people who have the passphrase." [[AlanCox|Alan Cox]] backed[20] this up: "If you are storing personal data on a system in a colo its practically mandatory to have encryption, and if you are storing anything sensitive its a big deal indeed - at least in those parts of the world with real data and privacy law ;)"
-=== HOWTO: Get an SELinux Policy Change ===
+[17] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00784.html
-[[JerryJames|Jerry James]] requested[1] information on how to get the correct security context in place for the <code>GCL</code> binaries which he was packaging. He needed to know both whether it was acceptable to use a <code>chcon -t java_exec_t</code> within the Makefile and how to have this reflected explicitly in Fedora policy.
+[18] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00792.html
-[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00259.html
+[19] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00798.html
-[[HansdeGoede|Hans de Goede]] suggested[2] filing a bug against <code>selinux-policy</code> as [[DanWalsh|Dan Walsh]] was "[...] usually very fast and correct in fixing issues like this one." Dan posted that Jerry could get the final destination of the file with a <code>chcon `matchpathcon -n /usr/bin/gcl` LOCALPATH/gcl</code>.
+[20] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00823.html
-[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00261.html
+The thread continued in fits and starts. [[AdamTkac|Adam Tkac]] raised[21] the problem of handling static IPs with <code>NetworkManager</code> (see this same FWN#152 "NetworkManager keyfiles for Pre-login Static Routes" for a discussion of as yet undocumented features). [[ChuckAnderson|Chuck Anderson]] disputed[22] that the problem existed and provided commandline and GUI solutions: "[...] for system-wide connections which you would presumably want for a server, you edit /etc/sysconfig/networkscripts/ifcfg-* as usual and NM will bring the interface up at boot. From the desktop, you can Edit Connections and create a new static connection and select it instead of the System or Auto connection which is very handy when moving between networks that don't support DHCP."
-[[JochenSchmitt|Jochen Schmitt]] suggested[3] that Jerry create a <code>SELinux</code> module to fix the issue and then actually did it himself and shared[4] it with the list, which impressed Jerry.
+An important addendum was provided[23] by [[OlivierGalibert|Olivier Galibert]] "Try a "chkconfig -list network". It should be on for levels 2-5. If it isn't, you haven't enabled the old-style networking [.]" The same point was made by Chuck[24] "Are you using NetworkManager or network service? chkconfig -list NetworkManager; chkconfig -list network If NetworkManager is enabled and network is not, then you need to change ifcfg-eth0: NM_CONTROLLED=yes" and by [[BillNottingham|Bill Nottingham]][25] "You need to either set NM_CONTROLLED to something other than 'no', or enable the 'network' service. In either case, NM's static network support is not your problem."
-[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00289.html
+[21] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00863.html
-[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00294.html
+[22] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00871.html
-The problem evolved[5] to be a little deeper than modifying the Makefile as Jerry explained[6]: "I need a non-default security context for binaries that are both built and executed in the %build script, when the policy module has not yet been installed. It appears to me that there are only two ways to accomplish this: keep abusing java_exec_t like I have been, or get a GCL policy incorporated into selinux-policy* prior to building GCL. Am I wrong?" After [[PaulHowarth|Paul Howarth]] pointed out that <code>selinux-policy</code> needed to provide a context type for <code>/usr/bin/gcl</code> Dan modified[7] his previous <code>matchpathcon</code> suggestion and advised that this would be provided in <code>selinux-policy-3.5.13-19.fc10</code>.
+[23] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00892.html
-[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00307.html
+[24] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00887.html
-[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00350.html
+[25] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00938.html
-[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00367.html
+The LSB[26] also came in for a bashing due to infrequently used, old tools (such as <code>ypbind</code> and the insecure r-commands) being installed to achieve compliance. [[PatriceDumas|Patrice Dumas]] clarified[27] that <code>ypbind</code> was necessary in <code>@base</code> to provide <code>NIS</code> functionality. Later discussion separated[28] out LSB-Core and LSB-Desktop which should simplify making a minimal install LSB compliant. [[BillNottingham|Bill Nottingham]] and [[ChrisAdams|Chris Adams]] performed[29] a dissection of <code>@core</code> with the intent of separating out items such as <code>hdparm</code> , <code>prelink</code> , <code>dhclient</code> , <code>ed</code> and others into <code>@base</code>.
-=== Comps Czar Appointed to Encourage Modifications ===
+[26] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00718.html
-An important decision made[1] by FESCo in its 2008-10-29 deliberations was to try and encourage further modification of <code>comps.xml</code>[2] by defining some clearer procedures. These included the appointment of [[BillNottingham|Bill Nottingham]] as a "Grand Arbitrator of Comps" to decide which packages should be included in comps. The main concern expressed during the deliberation was that packagers tended not to modify comps and that awareness of its purpose had not been clearly communicated. It was hoped that extending the wiki page[3] and making one person formally responsible would help. Currently there are filters in place and only those with uberpackager status can commit changes. [[JesseKeating|Jesse Keating]] (f13) wanted to "[...] rather correct bad behavior than prevent good behavior [.]"
+[27] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00753.html
-[1] http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.html
+[28] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00759.html
-[2] Comps is an XML file which is used by anaconda (the installer) to present groups of available packages for selection by the administrator during the installation of a new operating system. See: https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
+[29] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00802.html
-[3] https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
+[[JeremyKatz|Jeremy Katz]] outlined[30][31] a perspective from the Quality Assurance point of view. The burden imposed by preserving the modularity that many of the participants advocated sounds quite high: "[...] trying to preserve that modularity combinatorially adds to the testing matrix and also makes it significantly more difficult to write code since you can no longer depend on functionality. It also makes things slower as you have to conditionally check for things constantly [...] It's more than just /etc/init.d/network that has to be maintained. There's oodles of stuff in install-time configuration that will have to be maintained, tested, and have things fixed when people report them." [[SethVidal|Seth Vidal]] acknowledged[32] this but cautioned against dismissing the objections to particular changes as merely "neoluddite".
-One worry was to ensure that not everything is added to comps as this would produce an unreadable, large list. This latter problem was foregrounded when [[ChristopherStone|Christopher Stone]] advocated[4] that "[a]ll packages should go in comps. I don't know why notting is against this?!!? Why should my php-pear-* packages be excluded from comps for example? Just because some newb might not want to install them does not mean a php web developer would not use comps to install them." [[MattMiller|Matt Miller]] explained[5] that the current scheme was inflexible: "If comps ends up with a thousand programs under Games and Entertainment, another thousand under Graphical Internet, etc., it's even more useless than having nothing in comps at all. What would be the point? On the other hand, having a thousand small comps groups is also no good."
+[30] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01023.html
-[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00098.html
+[31] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01025.html
-[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00120.html
+[32] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01027.html
-[[SethVidal|Seth Vidal]] and [[ToshioKuratomi|Toshio Kuratomi]] seemed[6] interested in the idea of allowing Flickr-like tagging of package as a replacement for the problem of assigning them to groups. [[DenisLeroy|Denis Leroy]] also suggested[7] such a system: "Comps evolved over time into something that doesn't make a whole bunch of sense to me. Is the main use of comps still for installation groups within yum and anaconda ? A lot of packages are not installation "targets" but simply libraries that should only be installed by being pulled in from dependency resolution. Now if we're trying to "categorize" all packages nonetheless, it'd be better to have a tagbased system from packagedb, where packages can be "tagged" a-la-gmail, and also belong into multiple tag groups as some things really belong into multiple categories..."
+The massive thread included much more discussion and resists easy summary. Those interested should probably plow through the messages. Among the issues raised were finding DBus documentation[33] and contention between class devices to set default routes[34].
-[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00134.html
+A quote from DanHorak which seems to offer the perspective of the ServerSIG concisely is appropriate in closing: "It is really time to look back at the roots of Unix systems. It should be a combination of small pieces with well defined interfaces doing well their tasks. Only the time had changed those pieces from simple command line utilities to more complex ones."
-[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00107.html
+[33] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01071.html
-[[NicolasMailhot|Nicolas Mailhot]] listed[8][9] the advantages of the current format of comps as: human-editable, version-controllable, diff-able, grep-able, platform-agnostic and scalable. Toshio leaned[10] towards having tag information stored in <code>packagedb</code> which could generate static "[...] separate files for the installer and general use (so that the installer isn't sprinkled with thousands of libraries but one could still use yum to search for "all packages that have a 'python' 'library' to do 'ssl'")."
+[34] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00911.html
-[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00108.html
+=== NetworkManager keyfiles for Pre-login Static Routes ===
-[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00158.html
+In the course of the ServerSIG discussions (see this same FWN#152 "Server SIG") an interesting question about <code>NetworkManager</code> was asked[1] by [[LesMikesell|Les Mikesell]]: "If you bring up a mix of static and dynamically assigned interfaces, can you control which gets to assign the default route and DNS servers?"
-[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00122.html
+[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00872.html
-In another post Nicolas raised[11] another series of pertinent questions which included thinking about other repositories and alternate views of any data which might shoehorned into a particular model. [[BillNottingham|Bill Nottingham]] wondered[12] where Nicolas was going with all this and re-capped the current purpose of comps as both an input to a graphical package selector and an input to tree composition tools. The discussion with Bill revealed that Nicolas advocated[13] "[...] just add everything in comps and run basic scripts that check every package we ship appears there (say in a dev-null group for libs or such stuff). You can easily cull the dev-null group at comps.xml.in -> comps.xml stage if needed" in order to ease the QA burden.
+[[DanWilliams|Dan Williams]] provided[2] a useful description of how <code>NetworkManager</code> currently decides the default route. In response to [[OlivierGalibert|Olivier Galibert]] he added[3] that static routes could be set up using the "[...] connection editor see the "Routes..." button in the IPv4 tab. Routes from ifcfg files aren't yet supported, but could be. Routes from keyfile-based system connections (ie, prelogin) are supported." After this tidbit [[ChuckAnderson|Chuck Anderson]] prodded[4] Dan into explaining that keyfiles were a way to support things like "VPN, 3G, WPA" which were difficult or impossible to support with the ifcfg files in <code>/etc/sysconfig/network-scripts</code>. "NM has a system settings 'keyfile' plugin that allows editing system connections from the connection editor, or your favorite text editor if you don't use a GUI at all. Add `keyfile' to the -plugins argument in the /usr/share/dbus-1/systemservices/org.freedesktop.NetworkManagerSystemSettings.service file, and then 'killall -TERM nm-system-settings'."
-[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00125.html
+[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00880.html
-[12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00165.html
+[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00897.html
-[13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00226.html
+[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00900.html
-[[JeremyKatz|Jeremy Katz]] wondered[14] who was the audience and task for [[SethVidal|Seth Vidal's]] "tree hierarchy plus tags" interface and distinguished between users looking for an application and administrators installing a system. Seth suggested[15] that using kickstart to install a minimal base and then the desired packages was the appropriate solution for the latter problem. He later explained[16] that having a tag-based presentation of the packages online would make it easier to determine which packages were available. [[LesMikesell|Les Mikesell]] wished to reproduce specific machine configurations easily which led[17] Seth to suggest using <code>yum-groups-manager</code> to create a comps.xml file and then <code>createrepo -g that_comps.xml somedir</code> which produces "[...] a repository that ONLY has comps.xml in it that is then instantly usable by any site which can get to the baseurl where it lives."
+[[JesseKeating|Jesse Keating]] wondered when and where the documentation for this was placed and Dan replied[5] "[w]hen I struggle up for air from the tarpit that is the concurrent release of NM 0.7 + F10 + RHEL 5.3? :) "
-[14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00147.html
+[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00912.html
-[15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00148.html
+=== Flash 10 in 64-bit Fedora 9 ===
-[16] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00150.html
+[[JosVos|Jos Vos]] asked[1] for comparative data on using <code>nspluginwrapper</code> with <code>Firefox</code> to access <code>Flash</code> content in 64-bit Fedora 9. He was experiencing "[...] error messages about not finding 'soundwrapper' in my $PATH [.]"
-[17] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00152.html
+[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00432.html
-=== LiveConnect Feature Approved for Fedora 10 ===
+Although [[ChrisAdams|Chris Adams]] reported success [[OrcanOgetbil|Orcan Ogetbil]] described[2] a "gray rectangle bug" which seemed to be manifested mostly when multiple tabs were open. [[BrennanAshton|Brennan Ashton]] claimed[3] that it was due to a <code>PulseAudio</code> "bug".
-FESCo's 2008-10-29 discussions[1] contained a decision to include the LiveConnect[2] feature in Fedora 10. LiveConnect is a way for web browsers to allow JavaScript and Java classes to call each other's methods. The project to develop a completely FLOSS implementation was initiated[3] by [[TomFitzsimmons|Tom Fitzsimmons]] and brought to completion by [[DeepakBhole|Deepak Bhole]]. Tom's work[4] on a rewrite of <code>gcjwebplugin</code> as an XPCOM plugin has been named <code>IcedTeaPlugin</code> and is the default in <code>IcedTea6</code>.
+[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00439.html
-[1] http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.html
+[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00443.html
-[2] http://fedoraproject.org/wiki/Features/Liveconnect
+[[IgnacioVazquez-Abrams|Ignacio Vazquez-Abrams]] and others reported[4] no problems and Jos posted[5] that there appeared to be a dependency on <code>libcurl.i386</code> in the Adobe supplied <code>rpm</code>. This was later stated[6] by [[PaulHowarth|Paul Howarth]] to be changed so that either <code>libcurl.so.3</code> or <code>libcurl.so.4</code> will be used via a <code>dlopen()</code> and there is no explicit <code>requires:libcurl</code> in the rpm. [[GianlucaSzforna|Gianluca Szforna]] supplied[7] a link[8] which suggests that <code>libflashsupport</code> should be completely removed as it may cause crashes.
-[3] http://people.redhat.com/fitzsim/fosdem-2008/fosdem-2008-liveconnect.pdf
-[4] http://fitzsim.org/blog/?p=23
-The practical implications for end users are that many popular sites[5][6] are now usable without the problems associated with the installation of Sun Microsystems' non-FLOSS Java plugin.
+[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00437.html
-[5] http://www.jigzone.com/
+[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00445.html
-[6] http://games.yahoo.com/
+[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00479.html
-There was[7] some agonizing over the problem that <code>LiveConnect</code> was being approved as a Feature post freeze date while other exciting projects had been dropped because they were not complete at that time. [[BrianPepple|Brian Pepple]] worried: "Those folks we booted since they weren't complete would be justified in being pissed about us." Although this seemed to be a non-controversial opinion Deepak's work was also felt to be very important and fully tested. In addition Deepak submitted that "[...] no new packages introduced for this feature. Just an update to an existing package, that now installs a different Java plugin."
+[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00484.html
-[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00097.html
+[8] http://macromedia.mplug.org/

Search