Hi all, As of 18:20 EST (22:20 UTC) July 21 the wiki has become completely non-responsive (just as I was uploading the last two sections too!). I will be unable to attempt to upload these last two sections for another few hours, so here's the raw text in case it becomes urgent. I'll try again in approximately 4 hours. Best wishes, Oisin || (!) Is this news beat ready to post? No || == Developments == In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on Fedora Developments. http://www.redhat.com/mailman/listinfo/fedora-devel-list Contributing Writers: OisinFeeley, ThomasChung === 'Allo 'Allo Wot's This 'Ere License? === Following on from the Thursday, July 19th FESCo meeting[1] a request was posted[2] by BillNottingham to remind maintainers of the importance of keeping everyone informed about changing licenses. [1] http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070719 [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01096.html The request noted that even changes to license versions were important and that maintainers should ensure that the FedoraProject was notified about them via either of the lists: @fedora-devel-announce or @fedora-devel. Questions should be directed to FESCo. JakubJelinek wanted to know[3] whether the "License:" tags should be updated to reflect their exact versions now. JoshBoyer and BrianPepple answered that something such as the scheme which Jakub was proposing had been discussed in the FESCo IRC meeting[1]. That discussion was concerned with the technical aspects of how to provide license combinations in a compact, searchable space within current RPM strictures and TomCallaway (spot) expressed an objection to writing License tags of the form "License:GPL|MPL|BSD|X11|KitchenSink". There seemed to be plenty of practical objections to most of the suggestions and the meeting cohered around the proposal above, and also recognizing that much further work needed to be done. Dark murmurings about using a packagedb to hold the licenses were heard! [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01098.html A slightly different answer was given by BillNottingham[4], who said that it was up to the PackagingCommittee to standardize some naming convention and RalfCorsepius stated[4] that the PackagingCommittee had already rejected versioned licensing due to considering the "License:" tag to be merely informative and not a legal statement, and to versioned licences introducing too much overhead. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01154.html Ralf followed up[5] on this with a strongly-worded riposte to Bill's original announcement, asking whether FESCo was now going to be the "Fedora license police". JefSpaleta thought[6] that Ralf's negativity was getting a bit too consistent and suggested the more positive construction which saw the development as a way of making sure that those that depend on particular packages aren't suddenly blindsided by a change to a license. Ralf gave further depth[7] to his objections, arguing that ignorance on the legal issues and a bureaucratic burden would hamper the FedoraProject's efforts to give substance to these proposals, he also dismissed GPLv3 as a consideration. JoshBoyer specifically countered[8] the latter point. ToshioKuratomi (abadger) agreed[9] that exotic licenses introduced complications, that the PackagingCommittee had rejected guidelines for "License:" tags, but drew attention to the audience (end users) which had been considered in those deliberations. [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01156.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01157.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01167.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01170.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01177.html === Plans for tickless kernel for x86_64 architecture in Fedora 8 === WarrenTogami reports to FWN, "Hi Dave, Could you write up a paragraph describing Fedora's plan for x86_64 dyntick?" "We plan on releasing F8 with 2.6.23. Upstream seems against the idea of merging the 64bit tickless patches just yet, so will probably wait until 2.6.24 As a result of this, we'll carry patches in F8 to ship this feature early. Right now, as the 2.6.23 merge window is open, the tree is changing a lot, so adding patches at this stage would involve a lot of rediffing, so we'll remain without the tickless patches until things calm down when 2.6.23-rc1 is released. The plan of putting 64bit tickless in FC6/F7 updates has been put on hold until it's stabilised in rawhide, and may even wait until after F8 has been released, depending on how well testing goes. -- DaveJones" === Yum Integration For Applications === Ignacio Vazquez-Abrams proposed [1] rewriting some system tools (e.g. ''authconfig'', ''system-config-network'' and ''desktop-effects'') to access ''system-install-packages'' so that they could install other packages "on the fly" to enable missing functionaility. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00990.html There was a muted reaction to the proposal. JochenSchmitt expressed[2] disquiet with the idea of doing something as intrusive as automatically installing a package on a running system without the explicit consent of an administrator. JesseKeating thought[3] that what was meant by "automatic" in this context was "automatically launch Pirut which would of course prompt for the root password." Further discussion between Jesse, Jochen and Ignacio clarified that Ignacio was interested in using s-i-p with a Text User Interface instead of Pirut. [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00995.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00997.html JefSpaleta asked[4] whether a hand-created listing of packages for each tool would need to be made or if the process could be abstracted. Ignacio answered that s-i-p would be able to work exactly like yum in resolving needed packages and dependencies. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01003.html An alternate approach using "soft dependencies" (also discussed in the last paragraph of FWN#92 "Yelping Over Bloated Firefox And Flash"[4a]) was preferred[5] by KevinKofler. Kevin noted that this approach would avoid lock-in to yum/s-i-p. [4a] http://fedoraproject.org/wiki/FWN/Issue92#head-c93cd512fdf8e965869b3db1ff4bc7e152ef26ea [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01025.html MattMiller suggested[6] that a yum-plugin which allowed users to install what he termed "user level" applications using their own credentials would be useful. SethVidal was dubious, arguing that there was no easy distinction between user-level or other software. A detailed discussion[7] between HorstVonBrand and Matt over the dangers of Matt's suggestion versus the advantages of just using sudo followed and provided much food for thought. BennyAmorsen thought[8] that due to the difficulty of stopping users on UNIX systems making their own programs that the level of security which Horst wanted was already compromised. [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01035.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01082.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01134.html === Java Based Web Interface To Fedora Repositories? === Recalling the use of repoview in the past, ThorstenLeemhuis wondered[1] what were the plans for a similar interface in the new merged Fedora and drew attention to a new project[2] named "Repowatch" run by RichardKörber (Shred). [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00954.html [2] http://repowatch.fedorablog.de/ KonstantinRyabitsev (icon) responded[3] that he was completing work on a rewrite of repoview which had major speed-ups due to state-tracking. Icon pointed out that one advantage of repoview was that it did not require an engine to view the repository, being instead browsable simply as a collection of static pages. JesseKeating liked the sound of this and volunteered[4] to integrate into mash[4a] or pungi[4b]. [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00960.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00976.html [4a] Mash is a tool to query the koji buildsystem for particular RPMs and create a repository of them [4b] Pungi is a set of python libraries which can be used to build composition tools. It is also a means of producing iso images and/or installation trees. A response from the author/developer of repowatch clarified[5] that it was not a replacement for repoview, but instead provided a method to monitor data from sources such as repoview. RahulSundaram suggested requesting some FedoraProject resources officially (helpfully pointing to the place to do this) and ThorstenLeemhuis also encouraged[6] this, adding that repowatch could provide an easy way for users to find the latest versions of packages. [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00963.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01018.html JesseKeating noted[7] that it was possible to examine Koji to see what packages were available (see also FWN#88 "Making Koji A Complete rpmfind Replacement"[8]), but ThorstenLeemhuis was prepared for this and pointed back[9] to his earlier mail emphasising the need to cater to users. [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01051.html [8] http://fedoraproject.org/wiki/FWN/Issue88#head-25047e8f0c3a56912a6f251d72c6cf3512b6bbf5 [9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01068.html Wishing to move things along practically, DavidTimms asked[10] whether FedoraInfrastructure could provide any parameters for Shred before he commenced a rewrite. Shred's response detailed his use of Tomcat leading to a negative reaction[11] from JesseKeating who made it clear that Java apps (or PHP which was not under discussion here) were not something which he personally welcomed within the FedoraProject's essential infrastructure. A brief discussion of his reasons for this led Shred to decline[12] to enter the shopworn arguments about Java's performance and to conclude that there was no point in pursuing resource support within the FedoraProject. Jesse backed off from this conclusion and emphasized[13] that he had been merely expressing his own opinion. [10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01072.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01078.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01081.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01084.html An interesting conclusion to the thread was provided[14] by NicolasMailhot who noted that the advent of Free Java and the importance of JBoss made it important for Fedora to be able to mount a credible working alternative to Microsoft's .NET stack and that FedoraInfrastructure should work with Red Hat/JBoss to mitigate any problems such as the ones Jesse claimed. [14] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01093.html === Sysklogd Replaced With Rsyslogd in Fedora 8 === A replacement of the "sysklogd" kernel logging daemon was announced[1] by PeterVrabec. The reason[2] for this change is that sysklogd is no longer under active development. Very quickly there was disagreement over how this transition should be handled, with specific objections resting on the issues of what to call the the configuration files and whether the new daemon should be automatically started. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00941.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01040.html MattMiller suggested that using rsyslog.conf instead of syslog.conf as the name of the configuration file replicated one of the problems which had been identified with syslog-ng. PeterVrabec thought that a simple ''cp syslog.conf rsyslog.conf'' took care of that problem, but ChuckAnderson pressed home[3] the point that a drop-in replacement ought to use the exact same names for configuration files. [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01048.html A refinement of this point was made[4] by SethVidal who emphasized that it wasn't simple a replacement, but actually packaged as an "obsoletes". A direct response[5] from "SteveG" stated that this had indeed been the original intent and that a sysconfig option had been originally present. SteveG also detailed some complicated hackery to conditionally use either of the filenames depending on the existence of sysconf.conf. There were some strong objections[6] from TomasMraz and KarelZak citing the simplicity of just settling on one nane, using the ReleaseNotes to inform users of the change, and avoiding the use of a configuration file with a different base name to its daemon. LeszekMatok disagreed with the latter and posted[7] some examples during an exchange with RahulSundaram. MattMiller made a similar point elsewhere with a different example. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01052.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01053.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01073.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01133.html The proposal to simply standardize on a new name was not congenial to DavidLutterkort who noted[7a] that it would require modification of all scripts which relied on the old names. SethVidal agreed and suggested[7b] a transition which would delay the final full switch until F9. [7a] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01123.html [7b] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01128.html RahulSundaram[8] and SethVidal[8a] voiced the other major objection: the case of users that upgrade using '''yum'''. Peter's announcement had made it clear that an '''anaconda''' upgrade to F8 would start the new rsyslogd daemon automatically, but otherwise an update would cause the old sysklogd to be erased and the new rsyslogd would need a ''su -c; /sbin/service rsyslod start''. ManuelWolfshant thought[9] that leaving the system without a logger was enough of a problem to make an exception to packaging recommendations and start the daemon automatically from the %post section of the package. JeremyKatz objected[10] that this should only be done if sysklogd had been running previously or else there were negative effects for initing chroots, creating live-images and installing some systems. [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00942.html [8a] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00952.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00944.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00964.html In response to ThorstenLeemhuis' suggestion to test whether sysklogd was running JeremyKatz provided[11] an overview of how other scripts currently use a ''condrestart'' in %post but thought there would be problems depending on whether the sysklogd package had been removed before any tests could be run. BillNottingham amplified[12] this response, pointing out to MikeChambers that the PID file is what is examined. [11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00971.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00994.html ManuelWolfshant concluded[13] that although there were potential problems for admins running other logging daemons for testing purposes the proposed original scheme seemed mostly workable with the service starting after a reboot, and separately[14] JeffreyOllie noted that even in the case of "yum upgrade" from F7->F8 a reboot would be needed to use the new kernel and libraries anyway. [13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01021.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00967.html === Presto-digitation === "Nodata" recalled[1] the discussion on including Presto (a way to reduce the amount of downloaded package data during updates by using diffs of RPMs) and wondered what was happening now, noting that the integration hadn't happened due to a lack of testing then and that the same thing seemed to happening again. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00889.html This summary was corrected[2] by DanHorák, who noted that contrary to Nodata's assertion there were Presto-enabled repositories in existence for FC6, FC7 and Rawhide (the development branch). The generally favorable and pro-active approach of the FedoraProject to Presto had also been documented in FWN#93[3] and earlier. [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00891.html [3] http://fedoraproject.org/wiki/FWN/Issue93#head-be4027a212fef872b9d408a95126bb6684cfec12 JeremyKatz added[4] that JonathanDieter (main Presto developer with AhmedKamal) had taken some patches from Jeremy and that the automatic generation of deltarpms into the buildsystem was being worked on. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00896.html Separately FESCo supported[5] the idea of fully integrating Presto into Fedora 8, with some minor worries being expressed as to whether fedora-infrastructure would be able to make the necessary changes in time for the Test1 freeze, and the clarification that as long as it made it by Test2 then it would make the cut. [5] http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070719 A positive user experience with the existing Presto repositories was reported[6] by YuanYijun, with the caveat that a couple of errors needed to be worked around. FlorianLaRoche posted[7] an interesting link to an alternate GPL-licensed implementation of the binary-delta generating algorithm. [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00927.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01070.html === Seahorse: Reducing The Number Of Passphrase And Password Challenges === Following up on an earlier discussion, JesseKeating asked[1] whether it was possible to cut down the number of prompts for passphrases by managing ssh-agent passphrases within gnome-keyring. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00876.html RalfEtzinger explained[2] that OpenSSH currently uses a bundle of helpers (in openssh-askpass) and it ought to be easy to add a new one for gnome-keyring-ssh-askpass. [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00881.html A suggestion[3] by ToddZullinger to use the pam_ssh module[4] provoked some minor debate as Todd admitted that this approach required the password entered to GDM (the display manager) to be the same as the SSH passphrase. JonathanUnderwood was opposed to the idea, but Todd argued[5] that enabling gnome-keyring to do what Jesse wanted would provide a similarly weak security model also compromisable at one single point. [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00884.html [4] http://pam-ssh.sourceforge.net/ [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00897.html AlexanderDalloz thought that "keychain" might be useful but wouldn't eliminate initial onetime password requests. This and the pam_ssh discussion led Jesse to clarify[6] that he envisioned a key storing application accessed by a single password which was different from each of the stored passwords/passphrases. GawainLynch pointed[7] out a Gentoo HOWTO and JonathanUnderwood advertised[8] SethVidal's Seahorse packages which apparently provide exactly the integration which Jesse had been seeking. [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00909.html [7] http://gentoo-wiki.com/HOWTO_Use_gnome-keyring_to_store_SSH_passphrases [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01089.html === Nodoka Theme: Clean, Easy On The Eyes, Featured in Fedora 8 === An announcement[1] of a new graphics theme for Fedora named "Nodoka" was posted by MartinSourada. Along with DanielGeiger, Martin aims[2] to provide a non-intrusive, consistent look throughout the desktop (exclusive of wallpaper which is release-dependent) using the "Echo" icons. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00863.html [2] http://fedoraproject.org/wiki/Artwork/NodokaTheme Martin provided links to RPMs for those that wish to provide feedback and also sought further help in hosting the project. RahulSundaram followed up[3] on previous help he had given to Martin and suggested that the best course was to contact fedora-infrastructure to ask for resources. [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00904.html It seems[4] that the theme will only be usable for GTK2 (as opposed to GTK1) applications (which hopefully are nearly eliminated at this stage) and KevinKofler wondered[5] whether someone was working to make this work usable with KDE as an alternative to Bluecurve/Quarticurve. Martin responded[6] that volunteers to do so were welcome. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00879.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00917.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00923.html The proposal that Nodoka be included in Fedora8 was later approved[7] by FESCo. [7] http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070719 === RUM RHUM RHUME REDRUM OPIUM OPYUM: Offline Fedora Package Manager === One of the Google SoC projects was reported[1] to yield some usable results by Fedora users according to DebarshiRay (Rishi). Rishi has been working on a way to allow Fedora users without internet connections to benefit from the package management infrastructure already developed around YUM. The result has been a tool[2] tentatively named "RUM" which exists to allow users to update a bandwidth poor machine by hooking it up to another machine which has updated packages on it. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00795.html [2] https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay There was a certain amount of discussion about the name, with RahulSundaram drawing attention[3] to a conflict in namespace and querying some of the implementation choices, such as the use of uncompressed tar archives. Rishi seemed to settle[4] for "OPYUM" as the name. "Jima" commented[5] that as the contents of rpms were already compressed anyway there was probably not much gain in further compression. [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00842.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00935.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00873.html A mild amount of skepticism about the value of this particular approach was expressed, especially by MikeChambers, who wondered[6] why Rishi couldn't just integrate his changes into Pirut. Rishi re-iterated[7] that the goal of the project was to allow even the extreme case of completely networkless machines being updated with a CD containing a "yumpack" specially built for them, and also explained that Pirut-maintainer JeremyKatz wasn't receptive to the idea so far. [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00977.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00999.html In response to Mike's wish for the ability of yum to update simply from a local network, ThomasSpringer provided[8] the exact command: '''su -c; yum update --disablerepo=\* --enablerepo=local-network''' [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00982.html === Another GNOME Conspiracy Unmasked: ShowOnlyIn === An upset ChristopherStone asked[1] why so many applications were setting "ShowOnlyIn=GNOME" in their ''.desktop'' files and wondered if it was ''Fedora *trying* to cripple KDE or what⁈'' [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01103.html RexDieter pointed out[2] the flaw in Christopher's approach and AlanCox suggested[3] that simple imitation of a flawed example rather than malice was a better working hypothesis and asked Christopher to file bugs if necessary. ToddZulinger posted[4] a revised grep which indicated that GNOME users were actually victims of a KDE instigated desktop-cleansing campaign. [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01106.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01107.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01108.html The plight of Xfce users was raised[5] by AndyShevchenko as they are affected by the preferential setting of the flag for both GNOME and KDE. [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01159.html "TarekW" explained[6] that the advantage of the current setup is that it provides a sane default for non-power-users, shielding them from the potential bloat of having both desktops load their dependencies into memory. Power-users have the option to tweak ShowOnlyIn on a case-by-case basis. [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01176.html -- Oisin Feeley oisinfeeley@xxxxxxxxxxxx -- http://www.fastmail.fm - And now for something completely different? _______________________________________________ Fedora-news-list mailing list Fedora-news-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-news-list
