news July 2007

news@lists.fedoraproject.org

8 participants
15 discussions

news lead, reply to and new packages list
by Rahul Sundaram 01 Aug '07

01 Aug '07

Hi, Since the weekly news has a high volume of content we have added a ToC for a while now. What would be complimentary to this effort is a summary/lead paragraph which has some of the best highlights and invites/encourages/teases the reader to go further. Also the reply to is currently set to fedora-list and probably a cc should be set to this list too since not many editors seem to be following the fedora list and we get comments occasionally which I have been replying or forwarding to Thomas Chung. Thorsten (CC'ed) said he uses a script to generate the summary of new packages for EPEL. I would like to have that so that I contribute a weekly list of new packages (which is several dozens. we are growing massively!). Rahul

4 10

Re: Update of "FWN/Beats/AskFedora" by PaulFrields
by Thomas Chung 30 Jul '07

30 Jul '07

RE: http://fedoraproject.org/wiki/FWN/Beats/AskFedora Thank you Paul for adding a good looking note in the beat page. :) I realized we can't use any fancy wiki format in the beat page since its raw text will be used to compose FWN Issue for email announcement so I've decided to create a new page for "AskFedora" and move the content over. http://fedoraproject.org/wiki/AskFedora Now, I'm going to add as much content I could think of but feel free to add more and make any improvements since it's going to be very popular page in coming weeks. :) Cheers! -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

Improvements for News Beats
by Thomas Chung 30 Jul '07

30 Jul '07

Based on feedbacks from our contributors and users, following improvments have been made for our News Beats. We now have an Overview for News Beats. It's more like a Preview for next Issue. :) http://fedoraproject.org/wiki/FWN/Beats/Overview BTW, it's no longer necessary to change status for " Is this news beat ready to post?" Also beginning next issue, we're adding Anchors for each News Beat for easy reference. For example, http://fedoraproject.org/wiki/FWN/Issue99#Developments Cheers! -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

Beats and overview
by Rahul Sundaram 30 Jul '07

30 Jul '07

Hi In the beats section for FWM, each beat has its own page and there is no central overview. In the release notes, there is and it is very helpful that I don't have to click on dozens of links to quickly verify the content. What do folks think about adopting the same strategy? Rahul

2 4

Fedora Weekly News Issue 98
by Thomas Chung 30 Jul '07

30 Jul '07

= Fedora Weekly News Issue 98 = Welcome to Fedora Weekly News Issue 98 for the week of July 22nd, 2007. http://fedoraproject.org/wiki/FWN/Issue98 In this week, we have great announcements for Extra Packages for Enterprise Linux (EPEL), 3000 Fedora 7 Installations as well as FESCo Election Results. Also we are launching a special section called 'Ask Fedora' where you can ask questions to Fedora Project. In Developmets, there are more than enough interesting discussions including RPM Roadmap, Fedora Sound System, Desktop Menus, Licensing and more. In Security Week, our Security Response Team reports a dangerous Firefox Flaw. In Daily Package, you'll find reviews of Fedora packages including Incron, eSpeak, Syslog, Seamonkey, BSD-Games. To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join. 1. Announcements 1. Extra Packages for Enterprise Linux (EPEL) Now Open 2. 3000 Fedora 7 installations 3. FESCo Election Results 2. Planet Fedora 1. Improving package and system management 2. First rpm.org-RPM version released 3. Ask Fedora 4. Marketing 1. Fedora 8 To Integrate OpenJDK 2. A computer in every pot 3. Fedora stats offer insight into Linux usage 5. Developments 1. RPM Roadmap ... Panu Opens Pandora's Box 2. Package Management Craic[*] 3. Pulseaudio Improving Fedora Sound 4. What Should Appear In Desktop Menus 5. Kmods Deprecated 6. New Yum-updatesd (Rawhide Report 20070725) 7. NOTE: Please publicize any license changes to your packages (CONT.) 8. Extra Packages for Enterprise Linux (EPEL) Now Open 9. Abuse Of Fedora Trademark 10. XFS In Anaconda 6. Translation 1. F7 Release Notes Update 7. Infrastructure 1. Sponsor HowTo's 8. Artwork 1. Echo Icons Moved 2. Nodoka Engine 0.5 Released 3. Fedora 8 Theme Decisions 9. Security Week 1. Dangerous Firefox Flaw 10. Daily Package 1. Incron - Execute commands based on filesystem activity 2. eSpeak - Voice synthesizer 3. Wednesday Why: Syslog 4. Seamonkey - Mozilla suite 5. BSD-Games: Text games 11. Advisories and Updates 1. Fedora 7 Security Advisories 2. Fedora Core 6 Security Advisories 12. Events and Meetings 1. Fedora Board Meeting Minutes 2007-MM-DD 2. Fedora Ambassadors Meeting 2007-07-26 3. Fedora Documentation Steering Committee 2007-MM-DD 4. Fedora Engineering Steering Committee Meeting 2007-07-26 5. Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-07-26 6. Fedora Infrastructure Meeting (Log) 2007-07-26 7. Fedora Packaging Committee Meeting 2007-MM-DD 8. Fedora Release Engineering Meeting 2007-07-23 9. Fedora Translation Project Meeting (Log) 2007-07-24 == Announcements == In this section, we cover announcements from various projects. Contributing Writer: ThomasChung === Extra Packages for Enterprise Linux (EPEL) Now Open === KarstenWade announces in fedora-announce-list[1], "If you use enterprise-class Linux (EL) distributions derived from Fedora, such as Red Hat Enterprise Linux or CentOS, we have something very exciting for you." "EPEL[2] is a community of package maintainers working from inside of Fedora. Many are the same people who maintain the Fedora version. Yet, there room for new packages and contributors. Currently, around 1000 packages are available, and we've been growing at the rate of several dozen packages every week." [1] https://www.redhat.com/archives/fedora-announce-list/2007-July/msg00012.html [2] http://fedoraproject.org/wiki/EPEL === 3000 Fedora 7 installations === NayyarAhmad announces in fedora-ambassadors-list[1], "After a long discussions and few presentation, i have convinced Mozambique[2] Ministry of Finance (SISTAFE) to migrate their workstation around the country from MS Windows to Linux (Fedora 7), now they have officially approved the migration country wide and i will supervise this migration, plus will help them in end user training, its the first time in Mozambique that a Govt. department have opt for Linux (Fedora) and in my opinion it has been a big achievement, as after their migration i will be able to speak with other ministries and private firms." [1] https://www.redhat.com/archives/fedora-ambassadors-list/2007-July/msg00075.… [2] http://en.wikipedia.org/wiki/Mozambique === FESCo Election Results === BrianPepple announces in fedora-announce-list[1], "The FESCo[2] election is over, and the members for the 2007/2008 FESCo are (in alphabetical order): ChristopherAillon, JoshBoyer, TomCallaway, KevinFenzi, DennisGilmore, ChristianIseli, JeremyKatz, JesseKeating, BillNottingham, BrianPepple, JasonTibbitts, WarrenTogami, DavidWoodhouse" [1] https://www.redhat.com/archives/fedora-announce-list/2007-July/msg00011.html [2] http://fedoraproject.org/wiki/Development/SteeringCommittee == Planet Fedora == In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors. http://fedoraproject.org/wiki/Planet Contributing Writers: ThomasChung === Improving package and system management === RahulSundaram points out in his blog[1], "The most important improvement of course is the ongoing development of wevisor[2], which as the name indicates is a web interface to revisor that lets you do custom spins of Fedora. Kickstart configuration files can be fed into a number of places such as live cd tools, revisor and wevisor and adds a whole lot of customisability to Fedora." [1] http://rahulsundaram.livejournal.com/12108.html [2] http://hosted.fedoraproject.org/projects/wevisor === First rpm.org-RPM version released === RolandWolters points out in his blog[1], "Recently the first version of rpm.org[2]'s RPM tool was released. While it is only a minor version (4.4.2.1) this release is a milestones because it is a coordinated release between the participating distributions." [1] http://liquidat.wordpress.com/2007/07/24/first-rpmorg-rpm-version-released/ [2] http://rpm.org/ == Ask Fedora == Beginning this week, we will collect good and useful questions from users for this special section called 'Ask Fedora'. Contributing Writers: RahulSundaram, ThomasChung, PaulFrields, ChrisTyler Questions should exclude topics which are best answered through existing mechanisms. This shouldn't be for "my soundcard doesn't work" questions; it should be for big-picture questions of general interest. Esoteric hardware troubleshooting problems are a deal-killer, but more general help questions like "How do I edit my menus?" or "How do I find source code for <FOO>?" are good targets. To submit your questions, please use askfedora(a)fedoraproject.org and our news team will *try* to find the best answers and post in the following issue. == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung === Fedora 8 To Integrate OpenJDK === RahulSundaram reports in fedora-marketing-list[1], ""One of the most recently added features to the Fedora 8 feature list is IcedTea[2], which is the open-source version of Java (OpenJDK). The plan is to make IcedTea the default JPackage environment and will replace GCJ. There are Fedora packages for IcedTea already maintained (at ClassPath.org) and the dependencies needed to build IcedTea can already be found in Fedora Rawhide." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00067.ht… [2] http://fedoraproject.org/wiki/Features/IcedTea === A computer in every pot === RahulSundaram reports in fedora-marketing-list[1], "The user interface is called Sugar and not the OS itself but a good article nevertheless. BBC published a couple of articles with more technical information and videos featuring Christopher Blizzard, lead OLPC team in Red Hat." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00057.ht… === Fedora stats offer insight into Linux usage === RahulSundaram reports in fedora-marketing-list[1], Joe 'Zonker' Brockmeier talks with Fedora's Max Spevack about some recently released statistics. "The Fedora Project offered a peek under its kimono recently with details about Fedora 7 adoption and other statistics. Fedora 7 has snagged more than 300,000 users since its release at the end of May. While that sounds pretty good, Fedora Core 6 managed to attract more than 400,000 in roughly the same amount of time after its release. We asked Max Spevack, the Fedora project leader, whether the numbers are telling the full story." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00050.ht… == 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 Writer: OisinFeeley === RPM Roadmap ... Panu Opens Pandora's Box === A "slightly bored" PanuMatilainen solicited[1] suggestions for how rpm could be improved. Panu was concerned that non-subscribers to @rpm-maint[2] should get an opportunity to point out deficiencies which could be corrected now that 4.4.x was branched to maintenance mode and it was time to plan the next major release. The result was a thoughtful thread which largely failed to deliver the evil which Panu feared. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01537.html [2] https://lists.rpm.org/mailman/listinfo/rpm-maint The issue of multilib support was first raised[3] by "Dragoran", who thought that "arch requires and provides" should be automatic unless the packager manually intervened. TomCallaway (spot) was strongly in agreement. DavidWoodhouse followed up later by referencing[4] the tracker bugzilla entry which shows the extensive thought and discussion he has put into the issue of multilib support. [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01541.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01557.html DimiPaun posted[5] an extensive list of suggestions including version-control of meta-information to allow admins to pinpoint specific changes due to package updates and the provision of more fine-grained transaction information to external tools. The issue of transactions was also raised separately[6] by MatthiasClasen who requested "a working %posttrans". This prompted requests as to what he found broken, and lead to JeremyKatz explaining that multiple, small transactions were preferable to fewer, large ones due to their robustness in the face of power failure and that once this was achieved there was little advantage of "%posttrans" after "%post". ColinWalters linked[7] to the Stateless Client approach to avoiding power failure problems. Dimi argued that Jeremy might be right about the power-failure scenario, but that for all others multiple transactions would diminish the atomicity and integrity of rpm's workings. SethVidal didn't precisely disagree[8] but seemed to consider that Jeremy's scheme would provide more of the granularity of information that Dimi wanted. [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01543.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01545.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01569.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01599.html Responding[9] to Dimi's point OwenTaylor returned to the stateless-client model emphasizing that it was important to make '''system''' transactions as ACID as possible and not necessarily '''rpm''' transactions. Dimi agreed[10] that this was a non-trivial problem and suggested that LVM's snapshot capabilities could help out. [9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01612.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01618.html JeffSpaleta wanted[11] some way of marking packages which were installed explicitly (rather than automatically to satisfy dependencies). "Topher" suggested reference counting, prompting Jef to wonder what would be counted and to restate the problem[12] from a dependency-tree perspective. SethVidal was in agreement with Jef that avoiding an external database was prudent, but was cautious[13] about how long it would take to implement labelling such packages. [11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01607.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01613.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01610.html A sarcastic response from RobertScheck[14] argued that most of what Panu and others were talking about was either already in the rpm5 fork or else planned to be in it. Robert asked for clarification on a couple of points, including MatthiasClasen's wish for smart directory handling. Matthias specified[15] that he thought a package should own all directories it creates or else explicitly require a package which creates a directory which it uses. [14] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01605.html [15] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01606.html There many other interesting suggestions and also some great incidental information about rpm usage. In this category BrunoWolff wished[16] that there were some way of extending the length of rpm's argument list leading JeremyKatz and BillCrawford to point out that hidden away in the manpage is the info that a manifest list (which can include globs) can be used instead of a specific package name. [16] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01590.html Similarly MikeChamber's musing about a way to recover from the accidental removal of essential rpm libraries led ManuelWolfshant to point[17] to the "--repackage" option which the manpages say can be used in conjunction with an erase. RobertScheck's claim that rpm5 had a special rollback feature that did this spurred Panu to respond[17] that the "--repackage" option was ancient. [17] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01659.html === Package Management Craic[*] === In an independently initiated discussion which overlapped with many of the issues discussed in another thread covered here (FWN#98 "RPM Roadmap ... Panu Opens Pandora's Box") RichardHughes asked[1] for comments on one of his recent blog postings. Richard argued[2] that software install and updating tools were prone to information loss, were user-unfriendly, were hard to maintain, and that Ubuntu was at the head of an inferior pack. Richard's main thrust seemed to be to make package management a D-BUS integrated system service and to make the various dependency solvers backends, leading to separation out of the GUI or other interfaces. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01523.html [2] http://hughsient.livejournal.com/31429.html An enthusiastic affirmation from "Dragoran" on fixing the problem of "hung" progress-bars in the US by making the API asynchronous was initially squashed by JeremyKatz as rpm/sqlite wouldn't play well with multithreading. DavidZeuthen clarified[3] that multithreading wasn't necessary for an asynchronous API or proposed by Richard. [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01625.html BillNottingham reminded[4] the list that a similar discussion had been had before with regard to "yum-updatesd" and the choices roughly boiled down to making yum-updatesd so simple that it would not even check the currently installed packages, or extending it to a being a package-manager which could run unprivileged. Bill thought that latter would be a yum/rpm specific version of what Richard was proposing. He noted that the goal of making it work with .debs or other packaging specifications didn't seem interesting to him. SethVidal was highly skeptical[4a] that working to get a common API between the different packager formats was possible, noted the huge amount of coding that would be required and pointed out that rescue-mode would be complicated. Richard had specific rebuttals[4b] of these points and also discussed with Bill the amount of startup time that would be occasioned by his approach. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01551.html [4a] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01578.html [4b] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01580.html In specific response to Bill's lack of interest in a common API MatthiasClasen thought that escaping the ghettoization of distro-specific tools to a common upsteam was important and RichardHughes confirmed[5] that the goal of making it simple for users to try new software was important. Bill wondered whether packages as opposed to "mugshot-style distributed apps" were what Richard really had in mind. [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01570.html SethVidal was also unhappy with having to use D-BUS on webservers (due to what he claimed was its impact on RAM and unnecessary extra complication). ColinWalters disputed[6] the RAM usage claim and DavidZeuthen thought[7] that there would be nothing making Seth install the proposed D-BUS activated simple package management interface. He emphasized "simple". [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01595.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01626.html Offering some mugshot originating code ColinWalters[8] was another enthusiast. [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01572.html [*] Craic is the healthy Hibernian version of "crack", denoting fun, discussion and general insanity. See http://en.wikipedia.org/wiki/Crack_(craic) === Pulseaudio Improving Fedora Sound === There was a happy conclusion to a thread on the state of sound and audio in Fedora which had been opened[1] by a frustrated DimiPaun. Recounting a series of failures of ALSA since FC6, which were apparently due to kernel updates Dimi concluded that such flakiness with very standard hardware was unacceptable. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01140.html TomBrinkman thought[2] that @fedora-devel wasn't the place for such support questions and pointed out that Googling indicated that updating ALSA might work. In response to this and to JosefBacik's request for specific details Dimi explained[3] that it wasn't easy to pin down which kernel caused the problem and that he felt there was a general,underlying malaise in the development process. Dimi expanded on particular flakiness among what he regarded as essential desktop functionality which had become worse in his opinion. [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01142.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01151.html A polite response[4] from HansdeGoede asked for Dimi to substitute high-quality feedback (in the form of filing bugs) instead of inflammatory emails which no one would look at later. RahulSundaram similarly asked whether Dimi had filed bug reports and Dimi answered[5] that he had done so to no effect and that this revealed a process problem which would result in a deluge of useless bug reports were Rahul's advice to be followed. A great response[6] from JosefBacik regretted the problem but suggested that as Fedora merely packages upstream and could benefit from Dimi filing reports against the test-release of F8 so that ICH8 (the culpable sound hardware) would work in F8, Josef also suggested that a more slow-moving distro (e.g. RHEL, CentOS) might carry fewer frustrations. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01153.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01158.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01168.html "Nodata" wanted to look at the actual bugs, so Dimi provided[7] the bugzilla entry and expanded on his point that an apparent cycle of reporting bugs, spending time on them and then being told to report the bugs upstream was being repeated and that it was too great a burden on users. [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01173.html To complicate the issue "MarkG"[8] and HenkBreimer[9] reported that the apparently same hardware worked fine for them with F7. [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01187.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01169.html A post[10] by "Kelly" recommending the advantages of PulseAudio appeared to provide hope for the positive resolution of this problem. Confirmation of this as a solution was provided[11] when Rahul pointed out that PulseAudio was the default daemon in Fedora8. Kelly helpfully added[12] that s/he had a package which redirected the Adobe Flash through PulseAudio. [10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01210.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01213.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01233.html Finally, Rahul asked[13] Dimi to try some potted commands to update ALSA and to let him know if it fixed the sound problem. [13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01486.html === What Should Appear In Desktop Menus === The debate over whether applications' .desktop files should be setting ShowOnlyIn (see FWN#97 "ShowOnlyIn Another GNOME Conspiracy Unmasked"[1]) continued to yield disagreement. "Nodata" held out SuSE's "disastrous clutter" as the likely result of bowing to ChristopherStone's desire to make all applications show up in the menu. Chris refused[2] to set foot on this slippery slope and asked again why shouldn't an application which he chose to install show up in the menu? [1] http://fedoraproject.org/wiki/FWN/Issue97#head-dfd181f0727edbc287e9ee6b942c… [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01221.html So far this was a rehash of already covered ground and positions, but JefSpaleta and MattMiller trod a middle course[3] between complete menu mayhem and a straightjacketed system which prevent users from adding icons to their menus as they wished. [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01226.html Chris didn't think much thought was going into the default menu choices as evidenced by the fact that someone using Xfce (instead of GNOME or KDE) would not see applications like Kate or Banshee show up in their menu. BillNottingham riposted[4] that it also woouldn't make sense to show kreversi and iagno in both GNOME and KDE and wished for a DoNotShowIn in addition to OnlyShowIn. VilleSkyttä drew[5] everyone's attention to NotShowIn. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01274.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01282.html It seemed that Chris was still in high dudgeon and JesseKeating tried[6] to refocus the discussion on the problem of shared systems and the need to avoid the application menu becoming contaminated with applications installed by users who preferred different desktop environments. Jesse thought the solution was to teach the Xfce equivalent of gnome-menu to ignore the ShowOnlyIn entries in .desktop files. [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01275.html JonathanUnderwood recalled the old days when there was a KDE submenu in the GNOME menu but "nodata" thought the user experience of having to know about this and hunt around for applications would be unpleasant and it would be better to just provide KDE apps for KDE users and GNOME apps for GNOME users. Chris thought this was "so dumb it makes Microsoft engineers look like friggin' geniuses", but later[8] backed off from the personal element in this remark. [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01302.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01354.html In closing arguments JesseKeating drew Chris's attention[9] again to the problem of multiuser systems and developed the point further when requested. [9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01361.html The discussion seemed to peter out with Chris and Jesse agreeing[10] on the previously stated ideal of working toward making gnome-menu and equivalents able to override ShowOnlyIn. [10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01365.html MarkG was shown by ChristopherStone how to remove the problematic lines from .desktop ''# desktop-file-install --remove-only-show-in GNOME /usr/share/applications/gnome-banshee.desktop'' and ChristopherAillon provided a expansion[11] on the idea. [11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01592.html === Kmods Deprecated === After an invitation from BrianPepple to add items to the agenda for the FESCo meeting an interesting thread developed from HansdeGoede's request[1] for clarity on the "current somewhat grey state of kmods". His proximate reason for this was that ParagN's experience suggested to him[2] that kmods were unlikely to find favour in Fedora because they were not upstream. FlorianLaRoche felt[3] that kmods were worth the pain and also was keen on seeing the gspca kmods supported in Fedora. (See FWN#). [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01428.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01444.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01446.html An argument for the straight-out deprecation of kmods in Fedora was made[4] by DavidWoodhouse who thought that instead those using them should be given CVS commit access to maintain patches to the kernel which could be trivially enabled/disabled. A partial disagreement was registered[5] by ThorstenLeemhuis who lobbied[5] for deprecation in the F8 Everything spin and update-proper repository, but the creation of a replacement test repository which would make kmods available to those that needed them. Thorsten argued that there were developers not as comfortable with kernel development as David (or HansdeGoede) who nevertheless produced kmods which were useful to users. Thorsten also thought that some code which had a high probablility of not making it into the upstream (kernel) had a value for select users. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01462.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01464.html Adding his voice[6] to David's desire to avoid troublesome kernel code was JesseKeating who thought that the overhead imposed on yum/rpm was too high. Thorsten replied[7] to David's statement that "If we don't want it Fedora's kernel RPM, then we don't want it in Fedora at all" with a reiteration of the idea that users may want lots of things that the distro doesn't so a "play" area with clear warning signs should allow them to shoot themselves in the foot if they so desire. [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01468.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01469.html Thorsten also conceded[8] that David had a strong position, but linked the discussion to one happening within the FAB about who comprises Fedora's target audience and suggested that allowing a safe area for experimentation would have benefits in terms of stimulating and retaining interest among people that may later become Fedora developers or maintainers. [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01474.html HansdeGoede was broadly approving[9] of David's position, not least because it avoided having to delay kernel security updates while waiting for kmods to be fixed. After some discussion JesseKeating's worries[10] that this would result in more frequent kernel updates were dispelled[11] after David outlined how he saw the process playing out in updates and rawhide. [9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01471.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01476.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01482.html In a related thread RalfCorsepius reported[12] a bizarre result from updating which resulted in an apparently older kmod being installed. Posts by SethVidal suggested[2] that this was due to the proper yum plugin for kmods being absent[13]. [12]https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01639.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01673.html === New Yum-updatesd (Rawhide Report 20070725) === A heads-up was called[1] by JeremyKatz drawing attention to a completely re-worked yum-updatesd (see "RPM Roadmap ... Panu Opens Pandora's Box" in this same FWN issue). Jeremy noted that it had been split into a two parts: a small DBUS-enabled daemon and a forked memory process which is unthreaded. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01383.html HansdeGoede wanted to know[2] if this fixed his number one reason for not running yum-updatesd: that yum would fail if yum-updatesd was checking for updates. Hans suggested some ways of working around this problem. Jeremy responded[3] that this could still be a problem, but that it was mitigated somewhat by the fact that the process holding a lock on the database would now die-off quickly as it would not get "hung up in thread-land". [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01385.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01387.html In response to Jeremy's rebuttals Hans continued to press some further suggested changes[4] concerning the detection of a collision between the two processes and the response to it. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01456.html === NOTE: Please publicize any license changes to your packages (CONT.) === JefSpaleta agreed[1] with ThorstenLeemhuis that automatic checking of package licenses with upstream would help ease maintainer load in the simple cases of entire codebases migrating to GPLv3 from a previous license. RalfCorsepius reiterated[2] his assertions that it would not help codebases migrating from license:FOOx to license:BARy, or packages pointing to websites, and furthermore would require a large bureaucracy which would drive away contributors. AndyGreen responded[3] that these cases would be flagged as problems requiring human intervention. Ralf remained unconvinced[4] and invited the Board and the "dark forces" around it to do so without Ralf's help. This drew a certain amount of derision and disbelief and led to the revelation[5] of SethVidal as a self-confessed pusher of the changes to which Ralf objects. Seth wondered how exactly the process he was a part of could be construed as evidence of dark forces and explained that t Ralf replied with a list of "mushrooming" committees trying to "push volunteering contributors around". [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01232.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01235.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01236.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01240.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01320.html While expressing envy of Ralf's imagination NilsPhilippsen drew attention[6] to the distinction between labour-saving automation (of license checking) and bureaucracy. [6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01555.html Further dispuation saw JesseKeating stating[7] that until the FSF figured out how to resolve the incompatibility between GPLv2 and GPLv3 the relicensed GNU toolchain couldn't be allowed in the distribution. Ralf recommended that he check out a discussion on the subject on the GCC list and Jesse replied[8] that he was aware of it and that it underscored the need for Fedora to be on top of any and all license changes. [7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01328.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01330.html ArjanvandeVen corrected[9] Jesse's statement of the problem, noting that co-existence of GPLv2 and GPLv3 packages was no problem, but rather in making derived works. In turn, JakubJelinek corrected[10] this statement, saying that LGPLv3 was the problem and not GPLv3. A further clarification[11] came from TomasMraz who stated the constraint as merely '''we just have to ensure that we don't link any gplv2 only program to such library. Such as we have to ensure that we don't link any gpl program to openssl library and so on.''' [9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01331.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01333.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01334.html At this point RalfEtzinger posted a list[12] of packages which appeared to contravene this principle, again underscoring the need for this sort of information. FabioComolli posted[13] a useful link to MarkMcLoughlin's useful notes on the GPL and OpenSSL exemption. ChrisAdams provided[14] some package specific information and noted that these were "good example[s] of why license changes need to be clearly announced and researched." [12] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01338.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01343.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01344.html JeffSpaleta argued[15] that the absolutely best people to be the "we" of "we need to ensure that we don't link any gpl program to openssl library and so on" are the package maintainers as they are the experts in the libraries they maintain. ArjanVanDeVen suggested that tools could help parsing the "License" tag for mistakes and JesseKeating agreed and pointed[16] out that the FPC had been working on a syntax for the tags to enable this (see also FWN#97 "Allo Allo Wot's This 'Ere License?"[17].) [15] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01345.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01350.html [17] http://fedoraproject.org/wiki/FWN/Issue97?action=show&redirect=FWN%2FLatest… === Extra Packages for Enterprise Linux (EPEL) Now Open === KarstenWade announced[1] that the Extras Packages for Enterprise Linux (EPEL) repository was now open. This is of particular interest to anyone currently rebuilding packages from Fedora to use on one of the RHEL-derivatives such as CentOS, Scientific Linux or even on RHEL itself. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01516.html Apart from the obvious advantages to those of us maintaing such systems there is also a unique opportunity for those in academia to gain experience in curating enterprise applications for a large user base. === Abuse Of Fedora Trademark === A sharp-eyed HansdeGoede spotted[1] an announcement in LWN (Linux Weekly Net) of a piece of software which called itself "EasyFedora" used a proprietary license. Hans was pretty sure that this was abusing the "Fedora" trademark. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01451.html "Nicolas"(kwizart) noted[2] that a thread in FedoraForum requested the author to release under a non-proprietary license, but JesseKeating pointed out that regardless of the license the author had no right to use Fedora(TM) in the name of his software. [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01457.html A possible further problem was identified by KevinKofler who suggested[3] that unless the developer had a commercial Qt license then he was also violating the GPL! [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01493.html A helpful TimLauridsen supplied the information about how to report trademark violations to the Fedora Project which prompted AlainPortal to ask[4] whether this was overkill and it would be better to just write to the developer and ask him to remove the offending wording. "Dragoran" thought this was a good approach, but RahulSundaram argued that "legal" would handle it politely and were the appropriate people to do so. [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01522.html === XFS In Anaconda === A developer at Fermilab (DanYocum) requested[1] the enabling of the XFS filesystem in anaconda (the installer). Dan attested to the succesful inclusion of XFS upstream in the kernel, the realworld experience of successful installs and circa 1 Petabyte of running disks at Fermilab. [1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01496.html JesseKeating asked how SELinux support was these days and why he couldn't boot from XFS. EricSandeen confessed[2] that errors in FC6 with regard to SELinux could be blamed on him, but that they seemed to be fixed now after a trivial error had been corrected. Eric noted that booting from XFS in SuSE worked fine and suggested that a since resolved GRUB error may have been responsible for corruption in both ext3 and xfs. Finally Eric admitted that it wasn't possible to install GRUB to an XFS partition but the MBR worked fine. [2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01506.html In response to Eric's questioning Jesse provided the information that anaconda consistently choked on XFS for him and Eric wondered[3] whether GRUB was to blame still and how hard it would be to create a test anaconda. Jesse thought it wouldn't be too difficult and pointed[4] to exactly how this could be done. [3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01509.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01512.html == Translation == This section, we cover the news surrounding the Fedora Translation (L10n) Project. http://fedoraproject.org/wiki/L10N Contributing Writer: JasonMatthewTaylor === F7 Release Notes Update === PaulFrields mentioned here[1] that an update of the release notes package is on the horizon. There are a few locales that need fixes, as of 28-Jul-07 they were el es fi pa pt_BR sr uk zh_CN. [1] https://www.redhat.com/archives/fedora-trans-list/2007-July/msg00094.html == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure Contributing Writer: JasonMatthewTaylor === Sponsor HowTo's === MikeMcGrath has put some documentation up[1] on how to sponsor, how to get a sponsor and what the different groups are and what they do. Additions and clarifications are always welcome. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-July/msg001… == Artwork == In this section, we cover Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: JonathanRoberts === Echo Icons Moved === LuyaTshimbalanga wrote to the list suggesting that it might be a good idea to move the Echo icons to a host other than the wiki[1]. This will result in faster upload speeds, making it easier for contributors to make improvements to existing icons and to create new ones. As well as improving speeds, this should allow the use of a revision control system, rather than relying on the current echo-pull script. A ticket was opened with the Fedora infrastructure team, and work is underway to move the Echo icon theme to hosted.fedoraproject.org[2], and will use the Git revision control system. Currently the Echo icons are hosted at luya.fedorapeople.org/images/echo[3]. [1] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00144.html [2] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00149.html [3] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00153.html === Nodoka Engine 0.5 Released === The Nodoka theme engine has released its 0.5 version, including a significant number of updates[1]. [1] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00152.html === Fedora 8 Theme Decisions === MairinDuffy has sent a message informing the Art team that they have been given the authority to determine the final artwork and themes for Fedora 8. While this is great news, there are now decisions for the team to make, including which theme engine and icon theme to use as default in Fedora 8[1]. [1] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00154.html == Security Week == In this section, we highlight the security stories from the week in Fedora. Contributing Writer: JoshBressers === Dangerous Firefox Flaw === This week there has been a fair amount of talk regarding a new Firefox flaw that can allow a web site to execute arbitrary commands as the user running Firefox. Window Snyder has more information about this here[1]. [1] http://blog.mozilla.com/security/2007/07/25/launching-local-programs-throug… It turns out that the issue here is how Firefox launches helper applications. Specifically, how Firefox launches helper applications in Windows. In the Linux version of Firefox, when a helper is launched Firefox will do a forkexec of the binary. This basically means that the way the arguments are passed to the helper are well understood. In the windows world, this is not well understood and has led to confusion and a rather dangerous security flaw. What's happening is basically that the URL is handed to a special Windows function that builds the argument list, then launches the URL handler. This is a perfect example of why relying on closed source solutions are a problem. Nobody actually understood this problem for several days, and even now how can it be proven the Firefox fix will be correct? Without the ability to view the source, or adhere to standards, application writers are at a serious disadvantage. It is very likely that there are countless other applications that suffer from this same bug, but since they lack the attention Firefox has, the bug will never be fixed. IE even suffers from this flaw, which Microsoft claims isn't really a security bug. It's easy to say that open source has significant security advantages, but situations like this make it hard to believe any argument in favor of a closed system. == Daily Package == In this section, we recap the packages that have been highlighted as a Fedora Daily Package. We're looking for suggestions for packages to feature -- please suggest your favorites using the ''Suggest a Package'' box on the right-hand side of the Fedora Daily Package home page[1]. [1] http://dailypackage.fedorabook.com/ Contributing Writer: ChrisTyler === Incron - Execute commands based on filesystem activity === ''Productive Mondays'' highlight a timesaving tool. This Monday[1] we covered Incron[2]: "Incron is a new tool modeled after cron which executes commands when a filesystem event occurs. Without polling, Incron can watch a specific file or an entire directory for new files, file writes, closures, deletions, or other activity." [1] http://dailypackage.fedorabook.com/index.php?/archives/102-Productive-Monda… [2] http://inotify.aiken.cz/ === eSpeak - Voice synthesizer === ''Artsy Tuesdays'' highlight a graphics, video, or sound application. This Tuesday[1] eSpeak[2] was featured: "eSpeak is a speech synthesis package which provides an alternative to the better-know Festival synthesizer." [1] http://dailypackage.fedorabook.com/index.php?/archives/103-Artsy-Tuesday-eS… [2] http://espeak.sourceforge.net/ === Wednesday Why: Syslog === The ''Wednesday Why'' article[1] took a look at Fedora's syslog configuration: "The /var/log directory contains a number of different log files. Many of these logs are generated by syslogd, which accepts log messages from programs and routes them to log files, the screen, and remote log monitors." [1] http://dailypackage.fedorabook.com/index.php?/archives/104-Wednesday-Why-Sy… === Seamonkey - Mozilla suite === ''GUI Thursdays'' highlight software that provides, enhances, or effectively uses a GUI interface. This Thursday[1], Seamonkey[2] was discussed: "If you miss the bundled features of the Mozilla Suite, the Seamonkey package will give you what you want: web browser, e-mail and newsgroup client, address book, WYSIWYG page editor, IRC client, DOM inspector, and JavaScript debugger, all integrated into a single program." [1] http://dailypackage.fedorabook.com/index.php?/archives/105-GUI-Thursday-Sea… [2] http://www.mozilla.org/projects/seamonkey/ === BSD-Games: Text games === ''Friday Fun'' highlights fun, interesting, and amusing programs. This Friday[1], we took a look at BSD-Games[2]: "In the 70's and 80's, many Unix systems came with several dozen text-based games and amusements... if you're feeling nostalgic or if you've never encountered these classic games, it's worth checking out the bsd-games package." [1] http://dailypackage.fedorabook.com/index.php?/archives/106-Friday-Fun-BSD-G… [2] ftp://metalab.unc.edu/pub/Linux/games/ == Advisories and Updates == In this section, we cover Security Advisories and Package Updates from fedora-package-announce. Contributing Writer: ThomasChung === Fedora 7 Security Advisories === * [SECURITY] bind-9.4.1-7.P1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1247 * [SECURITY] drupal-5.2-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1295 * [SECURITY] lighttpd-1.4.16-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1299 === Fedora Core 6 Security Advisories === * [SECURITY] bind-9.3.4-7.P1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-647 == Events and Meetings == In this section, we cover event reports and meeting summaries from various projects. Contributing Writer: ThomasChung === Fedora Board Meeting Minutes 2007-MM-DD === * https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01560.html === Fedora Ambassadors Meeting 2007-07-26 === * https://www.redhat.com/archives/fedora-ambassadors-list/2007-July/msg00090.… === Fedora Documentation Steering Committee 2007-MM-DD === * No Report === Fedora Engineering Steering Committee Meeting 2007-07-26 === * https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01560.html === Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-07-26 === * https://www.redhat.com/archives/epel-devel-list/2007-July/msg00225.html === Fedora Infrastructure Meeting (Log) 2007-07-26 === * https://www.redhat.com/archives/fedora-infrastructure-list/2007-July/msg001… === Fedora Packaging Committee Meeting 2007-MM-DD === * No Report === Fedora Release Engineering Meeting 2007-07-23 === * https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01366.html === Fedora Translation Project Meeting (Log) 2007-07-24 === * https://www.redhat.com/archives/fedora-trans-list/2007-July/msg00072.html -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

Development beat ready for editing
by Oisin Feeley 28 Jul '07

28 Jul '07

Hi all, The latest FWN Development news beat is ready for editing here: https://fedoraproject.org/wiki/FWN/Beats/Developments It's a bit long again this week but there was no easy way to shorten the discussions without making them misleading. Have fun! Oisin Feeley -- http://www.fastmail.fm - Does exactly what it says on the tin

2 1

Fedora Weekly News Issue 97
by Thomas Chung 25 Jul '07

25 Jul '07

= Fedora Weekly News Issue 97 = Welcome to Fedora Weekly News Issue 97 for the week of July 15th through July 21st 2007. The latest issue can always be found here[2] and RSS Feed can be found here[3]. To join or give us a feedback, please visit our project join page[4]. [1] http://fedoraproject.org/wiki/FWN/Issue97 [2] http://fedoraproject.org/wiki/FWN/LatestIssue [3] http://fedoranews.org/cms/FWN/feed [4] http://fedoraproject.org/wiki/NewsProject/Join 1. Announcements 1. fedorapeople.org is now available 2. Smolt, Open Invitation 2. Planet Fedora 1. Ohio Linux Fest Keynote Address 2. GNOME Cookbook 3. Repoview-0.6.0 4. Mascots and Fedora. Do we need one? Do we want one? 3. Marketing 1. Volunteers needed for GITEX (8-12 September) 2. New in Fedora: Jack Aboutboul 3. Proposed Fedora 8 Features 4. Smolt to be a Linux Thing 4. Developments 1. Plans for tickless kernel for x86_64 architecture in Fedora 8 2. 'Allo 'Allo Wot's This 'Ere License? 3. Yum Integration For Applications 4. Java Based Web Interface To Fedora Repositories? 5. Sysklogd Replaced With Rsyslogd in Fedora 8 6. Presto-digitation 7. Seahorse: Reducing The Number Of Passphrase And Password Challenges 8. Nodoka Theme: Clean, Easy On The Eyes, Featured in Fedora 8 9. RUM RHUM RHUME REDRUM OPIUM OPYUM: Offline Fedora Package Manager 10. Another GNOME Conspiracy Unmasked: ShowOnlyIn 5. Infrastructure 1. Fedorapeople.org is up 6. Security Week 1. Computer Viruses are 25 Years old 2. Serious Security Issues in Samsung Linux Drivers 3. Firefox 2.0.0.5 Released 7. Daily Package 1. Krecipes - Recipe manager 2. Pulseaudio - Next-generation audio server 3. Crontab 4. Hwbrowser - Display hardware info 5. Ri-li - Run a wooden train 8. Advisories and Updates 1. Fedora 7 Security Advisories 2. Fedora Core 6 Security Advisories 9. Events and Meetings 1. Fedora Board Meeting Minutes 2007-07-17 2. Fedora Ambassadors Meeting 2007-07-19 3. Fedora Documentation Steering Committee 2007-07-17 4. Fedora Engineering Steering Committee Meeting 2007-07-19 5. Fedora Extra Packages for Enterprise Linux Meeting 2007-07-18 6. Fedora Infrastructure Meeting (Log) 2007-07-19 7. Fedora Packaging Committee Meeting 2007-07-17 8. Fedora Release Engineering Meeting 2007-07-16 9. Fedora Translation Project Meeting 2007-07-17 10. Extras Extras 1. LiveCD for Red Hat High == Announcements == In this section, we cover announcements from various projects. Contributing Writer: ThomasChung === fedorapeople.org is now available === SethVidal announces in fedora-announce-list[1], "What is fedorapeople.org[2]?: It is a site where fedora contributors can upload files for sharing out with the world. It is perfect for uploading specfiles, srpms, patches, etc, etc. Each fedora contributor has 150M of quota-controlled space. Users can upload using scp, sftp or rsync. Once uploaded into the users public_html directory the files are available via http at: http://your_username.fedorapeople.org/. To connect to fedorapeople.org just use the ssh key you uploaded to your fedora account and then you can login via ssh to: fedorapeople.org" [1] https://www.redhat.com/archives/fedora-announce-list/2007-July/msg00009.html [2] http://fedorapeople.org/ === Smolt, Open Invitation === MikeMcGrath announces in fedora-announce-list[1], "Smolt[1] will reach 75,000 profiles in the next 24 hours and with that news I'm excited to announce functional clients that work in SuSE, Debian, and Ubuntu. With the help of the Linux community at large we could start to better understand what is out there. Look to changes in the near future like a ratings system, better reporting tools and other such improvements." [1] https://www.redhat.com/archives/fedora-announce-list/2007-July/msg00007.html [2] http://smolt.fedoraproject.org/ == Planet Fedora == In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors. http://fedoraproject.org/wiki/Planet Contributing Writers: ThomasChung === Ohio Linux Fest Keynote Address === MaxSpevack points out in his blog[1], "I've just purchased a plane ticket to Ohio Linux Fest[2], which is on Saturday September 29th. Joe Brockmeier is one of the primary organizers, and he asked me today if I would be willing to give one of the two keynote addresses. On behalf of all of Fedora, I am both flattered and excited to be given this opportunity." [1] http://spevack.livejournal.com/23470.html [2] http://www.ohiolinux.org/ === GNOME Cookbook === JohnPalmieri points out in his blog[1], "A little birdy reminded me that GNOME's 10 year anniversary is coming up and I thought it would be nice to do something a little bit unusual to commemorate the creativity and passion which exemplifies our members. Since I have been talking about cooking classes and so many people in the GNOME community have also expressed their love for the culinary arts I thought it would be nice to publish a Creative Commons Attribution-ShareAlike 3.0[2] licensed cook book full of recipes from members of the GNOME community." [1] http://www.j5live.com/?p=392 [2] http://creativecommons.org/licenses/by-sa/3.0/ === Repoview-0.6.0 === KonstantinRyabitsev points out in his blog[1], "Repoview[2] version 0.6.0 is available and should make life much easier -- this version introduces state tracking, so now repoview is aware of changes between runs. This means that it only generates and writes the files that have actually changed, which makes it extremely fast for small changes and also makes it rsync-friendly." [1] http://mricon.livejournal.com/379633.html [2] http://mricon.com/trac/wiki/Repoview === Mascots and Fedora. Do we need one? Do we want one? === NicuBuculei points out in his blog[1], "Back in the release cycle for Fedora 7 we had an initiative: create an open process where anyone can play and see if we can come with a Mascot for Fedora[2]. It generated a lot of long talks on mailing lists with strong supporters and opponents of the idea but also a number of contributions (about which I planned to blog but never came to it until now, shame on me!)." [1] http://nicubunu.blogspot.com/2007/07/mascots-and-fedora-do-we-need-one-do-w… [2] http://fedoraproject.org/wiki/Artwork/Mascot == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung === Volunteers needed for GITEX (8-12 September) === JohnBabich reports in fedora-marketing-list[1], "I am doing my best to get a Fedora presence in the Red Hat EMEA booth at GITEX[2], being held this year on 8-12 September." "I can use all the help I can get to man the booth, answer questions, produce and distribute live CDs, etc. If you are attending GITEX this year and can spare some time to help out, I think it will be a productive and fun time for all involved." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00033.ht… [2] http://fedoraproject.org/wiki/FedoraEvents/GITEX === New in Fedora: Jack Aboutboul === RahulSundaram reports in fedora-marketing-list[1], "Jack Aboutboul talks about what's new and interesting in Fedora in a Linux World podcast[2] with Don Marti. Why does the core/extras merge matter, custom spins of Fedora, relationship between Fedora and OLPC, KVM and virt-manager virtualization, does user space in Linux still suck like Dave Jones says it did, boot up speed and much more..." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00026.ht… [2] http://www.linuxworld.com/podcasts/linux/2007/062507-linuxcast.html === Proposed Fedora 8 Features === RahulSundaram reports in fedora-marketing-list[1], "A pretty good look with screenshots and short descriptions though the list of features[2] are a bit premature to say at this point. I think we can do something similar to officially while announcing the list of features for Fedora 8 which will happen when we hit feature freeze during the development cycle." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00025.ht… [2] http://linuxupdate.blogspot.com/2007/07/proposed-fedora-8-features.html === Smolt to be a Linux Thing === MarcWiriadisastra reports in fedora-marketing-list[1], "Smolt, the Linux hardware profiler that was introduced by the Fedora project for automatically reporting installed hardware and other system attributes, reached a new milestone last week and is in the process of another. Last week, Smolt reached 75,000 profiles for Fedora after being introduced back in January of this year. At the time of writing, there are now over 78,300 profiles.[2]" [1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00023.ht… [2] http://www.phoronix.com/?page=news_item&px=NTg5Ng == 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 Writer: OisinFeeley === Plans for tickless kernel for x86_64 architecture in Fedora 8 === (Editor's Note: This news beat was written by ThomasChung) 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" === '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 Fedora Project 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 Packaging Committee to standardize some naming convention and RalfCorsepius stated[4] that the Packaging Committee 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 Fedora Project'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 Packaging Committee 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 === 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-c93cd512fdf8e965869b3db1ff4b… [5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01025.html MattMiller suggested[6] that a yum-plugin that 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 that 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 that 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 Fedora Project 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-25047e8f0c3a56912a6f251d72c6… [9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01068.html Wishing to move things along practically, DavidTimms asked[10] whether Fedora Infrastructure 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 Fedora Project'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 Fedora Project. 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 Fedora Infrastructure 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 SteveGrubb (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 name, 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 that 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 rsyslogd 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] JeffOllie 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, F7, and Rawhide (the development branch). The generally favorable and pro-active approach of the Fedora Project 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-be4027a212fef872b9d408a95126… 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 === (Editor Note: See http://fedoraproject.org/wiki/DebarshiRay/rum#Naming for 'Naming Blues') 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 that 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. ToddZullinger 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 == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure Contributing Writer: JasonMatthewTaylor === Fedorapeople.org is up === SethVidal and others have been working on the fedorapeople.org site for a while and their work is now available for use[1]. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-July/msg001… == Security Week == In this section, we highlight the security stories from the week in Fedora. Contributing Writer: JoshBressers === Computer Viruses are 25 Years old === I ran across this story this week. http://www.sciam.com/article.cfm?chanId=sa003&articleId=C0C3AC3C-E7F2-99DF-… The computing world is still suffering from computer viruses. They're a serious problem that waste a great deal of time and money. Given past trends, it's very likely that computer viruses will see their 50th birthday. === Serious Security Issues in Samsung Linux Drivers === This story is absolutely amazing http://it.slashdot.org/article.pl?sid=07/07/18/0319203 It seems that by installing certain Samsung Linux drivers modify numerous applications on the local system, setting a number of them setuid-root. It's easy to claim open source produces higher quality software, this is a fine example of this. If the source is being scrutinized by the community at large, someone is likely to send a patch which can fix a plain stupid bug such as this. It's also quite likely that a developer will be more willing to "do it right" if the source is going to be available for the whole world to see. === Firefox 2.0.0.5 Released === A new version of the Mozilla products (Firefox, Seamonkey, Thunderbird) were released this week. http://www.mozilla.org/projects/security/known-vulnerabilities.html#firefox… It's rather important you ensure you've installed this update as the browser is certainly the most abused application these days. If you run Fedora, this update has been available via yum for several days. == Daily Package == In this section, we recap the packages that have been highlighted as a Fedora Daily Package. http://dailypackage.fedorabook.com/ Contributing Writer: ChrisTyler === Krecipes - Recipe manager === ''Productive Mondays'' highlight a timesaving tool. This Monday[1] we covered Krecepies[2]: "Krecipes is a KDE recipe manager. It will store, seach for, and resize recipes, rate their nutritional content, and manage shopping lists. Recipes can be stored in plan files for personal access, or in MySQL or PostgreSQL databases for shared access (or very large recipe collections)" [1] http://dailypackage.fedorabook.com/index.php?/archives/98-Productive-Monday… [2] http://krecipes.sourceforge.net/ === Pulseaudio - Next-generation audio server === ''Artsy Tuesdays'' highlight a graphics, video, or sound application. This Tuesday[1] PulseAdudio[2] was featured: "PulseAudio is a next-generation audio server designed to be a 'Compiz for audio'. It enables you to start multiple audio applications (with different output systems) and direct each playback stream to the sink (destination) of your choice, even changing the destination on-the-fly, and to adjust the level of each individual channel." [1] http://dailypackage.fedorabook.com/index.php?/archives/97-Artsy-Tuesday-Pul… [2] http://pulseaudio.org/ === Crontab === The ''Wednesday Why'' article[1] took a look at the ways that Fedora packages interact with the cron execution scheduler: "Packages that requires scheduled execution of jobs can be configued in either of two ways: they can include a crontab file which will be placed in /etc/cron.d (the approach used by the smolt package), or they can include a script file which will be placed in /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, or /etc/cron.monthly (which is the approach used by cups)." [1] http://dailypackage.fedorabook.com/index.php?/archives/99-Wednesday-Why-Cro… === Hwbrowser - Display hardware info === ''GUI Thursdays'' highlight a software that provides, enhances, or effectively uses a GUI interface. This Thursday[1], hwbrowser was discussed: "Hwbrowser is a very simple tool that provides read-only access to hardware information." [1] http://dailypackage.fedorabook.com/index.php?/archives/100-GUI-Thursday-Hwb… === Ri-li - Run a wooden train === ''Friday Fun'' highlights fun, interesting, and amusing programs. This Friday[1], we took a look Ri-li[2]: "Do you remember having a wooden train set when you were little? Ri-li is a neat little amusement that will remind you of those days." [1] http://dailypackage.fedorabook.com/index.php?/archives/101-Friday-Fun-Ri-li… [2] http://ri-li.org/ == Advisories and Updates == In this section, we cover Secuirity Advisories and Package Updates from fedora-package-announce. Contributing Writer: ThomasChung === Fedora 7 Security Advisories === * [SECURITY] blam-1.8.3-5.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1157 * [SECURITY] bochs-2.3-5.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1153 * [SECURITY] centericq-4.21.0-13.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1160 * [SECURITY] chmsee-1.0.0-0.20.beta2.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1159 * [SECURITY] clamav-0.90.3-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1154 * [SECURITY] devhelp-0.13-9.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1143 * [SECURITY] epiphany-2.18.3-2.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1138 * [SECURITY] epiphany-extensions-2.18.3-2 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1155 * [SECURITY] firefox-2.0.0.5-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1142 * [SECURITY] galeon-2.0.3-10.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1145 * [SECURITY] gimp-2.2.17-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1099 * [SECURITY] kernel-2.6.22.1-27.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1130 * [SECURITY] liferea-1.2.19-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1146 * [SECURITY] nginx-0.5.28-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1158 * [SECURITY] seamonkey-1.1.3-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1181 * [SECURITY] thunderbird-2.0.0.5-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1180 * [SECURITY] yelp-2.18.1-5.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1144 === Fedora Core 6 Security Advisories === * [SECURITY] firefox-1.5.0.12-4.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-642 * [SECURITY] gimp-2.2.17-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-627 * [SECURITY] thunderbird-1.5.0.12-2.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-641 == Events and Meetings == In this section, we cover event reports and meeting summaries from various projects. Contributing Writer: ThomasChung === Fedora Board Meeting Minutes 2007-07-17 === * https://www.redhat.com/archives/fedora-advisory-board/2007-July/msg00102.ht… === Fedora Ambassadors Meeting 2007-07-19 === * https://www.redhat.com/archives/fedora-ambassadors-list/2007-July/msg00063.… === Fedora Documentation Steering Committee 2007-07-17 === * https://www.redhat.com/archives/fedora-docs-list/2007-July/msg00067.html === Fedora Engineering Steering Committee Meeting 2007-07-19 === * https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01092.html === Fedora Extra Packages for Enterprise Linux Meeting 2007-07-18 === * https://www.redhat.com/archives/epel-devel-list/2007-July/msg00182.html === Fedora Infrastructure Meeting (Log) 2007-07-19 === * https://www.redhat.com/archives/fedora-infrastructure-list/2007-July/msg001… === Fedora Packaging Committee Meeting 2007-07-17 === * No Meeting === Fedora Release Engineering Meeting 2007-07-16 === * No Meeting === Fedora Translation Project Meeting 2007-07-17 === * No Meeting == Extras Extras == In this section, we cover any noticeable extras news from various Linux Projects. Contributing Writer: ThomasChung === LiveCD for Red Hat High === RobinNorwood reports in fedora-livecd-list[1], "Last week, we held the second annual Red Hat High[2] here in Raleigh. I helped with the software side of things, and used the livecd tools to do it." "In a nutshell, it's a technology camp for incoming high school freshmen, using all open source software." "For the classrooms, we used lab space donated by NCSU. However, a couple of the labs were being used for NCSU classes during the week of the camp, so we couldn't just format the drives and install Fedora. Our solution was to use a live cd[3]." [1] https://www.redhat.com/archives/fedora-livecd-list/2007-July/msg00132.html [2] http://www.redhat.com/redhathigh/ [3] http://people.redhat.com/rnorwood/rhh-livecd/ -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

5 10

Fedoraproject servers non-responsive. Copy of @fedora-devel newsbeat
by Oisin Feeley 22 Jul '07

22 Jul '07

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-c93cd512fdf8e965869b3db1ff4b… [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-25047e8f0c3a56912a6f251d72c6… [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-be4027a212fef872b9d408a95126… 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(a)imapmail.org -- http://www.fastmail.fm - And now for something completely different

2 1

Development beat ready for editing
by Oisin Feeley 22 Jul '07

22 Jul '07

OK, Got a chance to check it and it seems that my previous changes were saved and the @fedora-devel newsbeat is ready for editing: http://fedoraproject.org/wiki/FWN/Beats/Developments -- Oisin Feeley oisinfeeley(a)imapmail.org -- http://www.fastmail.fm - Send your email first class

2 1

Back doing the FWN Development Beat
by Oisin Feeley 20 Jul '07

20 Jul '07

Hi everyone, Just a quick note to confirm that I'm back in the saddle and will be rolling out the Development news beat for FWN#97. Thanks for covering for me, and I'll reply later to issues raised by Karsten as soon as we get this one out the door! Best, Oisin -- Oisin Feeley oisinfeeley(a)imapmail.org -- http://www.fastmail.fm - The way an email service should be

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

news July 2007