From Fedora Project Wiki

< FWN
Revision as of 16:29, 24 May 2008 by Ravidiip (talk | contribs) (1 revision(s))

Fedora Weekly News Issue 91

Welcome to Fedora Weekly News Issue 91[1] for the week of June 3rd through June 9th, 2007. The latest issue can always be found here[2] and RSS Feed can be found here[3] .

[1] http://fedoraproject.org/wiki/FWN/Issue91

[2] http://fedoraproject.org/wiki/FWN/LatestIssue

[3] http://feeds.feedburner.com/fwn


Announcements

In this section, we cover announcements from various projects.

Contributing Writer: ThomasChung

Cooperative Bug Isolation for Fedora 7

BenLiblit announces in fedora-announce-list[1] ,

"The Cooperative Bug Isolation Project (CBI) is now available for Fedora 7. CBI[2] is an ongoing research effort to find and fix bugs in the real world. We distribute specially modified versions of popular open source software packages. These special versions monitor their own behavior while they run, and report back how they work (or how they fail to work) in the hands of real users like you. Even if you've never written a line of code in your life, you can help make things better for everyone simply by using our special bug-hunting packages."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-June/msg00001.html

[2] http://www.cs.wisc.edu/cbi/

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

OLPC: Mesh Networking Overview in Red Hat Magazine

ChristopherBlizzard points out in his blog[1] ,

"Dan Williams, John Palmieri and Miguel Alvarez talk about the mesh networking in the laptop[2] . They talk about the low level connectivity bits as well as the higher level set of activities and architecture that we’re building. Great job guys!"

[1] http://www.0xdeadbeef.com/weblog/?p=295

[2] http://www.redhatmagazine.com/2007/06/08/inside-one-laptop-per-child-episode-03/

Fedora for ARM and cross compilation

AnthonyGreen points out in his blog[1] ,

"It's great to see the more discussion around Fedora on embedded architectures happening over the last two weeks. To play catch up, these are the three threads I've found that matter:

  • Lennert Buytenhek's "fedora for ARM" thread[2] . Lennert has a Fedora build for ARM with patches ready to be merged.
  • Brendan Conoboy's cross-compilation thread[3] . I've worked with Brendan for years in the embedded tools and OS arena, and he definitely knows what he's talking about.
  • spot's Secondary Architectures thread[4] discusses proposed policies for handling secondary architectures in Fedora.

The issues are many, varied and complex, but I hope something comes of this."

[1] http://spindazzle.org/greenblog/index.php?/archives/67-Fedora-for-ARM-and-cross-compilation.html

[2] http://thread.gmane.org/gmane.linux.redhat.fedora.devel/55880

[3] http://thread.gmane.org/gmane.linux.redhat.fedora.devel/56709

[4 ] http://thread.gmane.org/gmane.linux.redhat.fedora.devel/55377

Innovation in virtualization management tools

DanielBerrange points out in his blog[1] ,

"For the last couple of years all the hype wrt open source virtualization has been about Xen. Unfortunately after several years Xen is still not upstream in LKML, the main codebase being a huge out of tree patch persistently stuck on obsoleted kernel versions. The Xen paravirt_ops implementation is showing promise, but its a long way off being a full solution since it doesn't provide Dom0 or ia64/ppc/x86_64 yet. Then out of nowhere, 6 months ago, a newer contender arrived in the form of KVM almost immediately finding itself merged upstream. Now you can't claim to be offerring state of the art virtualization without including both KVM and Xen. We had to have KVM in Fedora 7. With excellant forsight, when working to integrate Xen in Fedora Core 5, Daniel Veillard had the idea to create a technology independant management library for virtualization platforms. This is libvirt[2] ."

[1] http://berrange.com/personal/diary/2007/06/innovation-in-virtualization-management

[2] http://libvirt.org/

Marketing

In this section, we cover Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: ThomasChung

Revisor utility creates custom install images for Fedora

PaulFrields reports in fedora-marketing-list1[1] ,

"Nice to see this is getting even more traction and notice.[2] "

"Imagine a customized GNU/Linux distribution, built to your specifications with a minimal amount of effort on your part. If you are running Fedora 7, that dream is now a reality, thanks to Revisor, a graphical interface for building custom install images for Fedora."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00106.html

[2] http://enterprise.linux.com/article.pl?sid=07/06/06/2017215

Review: Fedora 7 Advances on Rivals (eweek.com)

RahulSundaram reports in fedora-marketing-list[1] ,

"This review[2] has focused on virt-manager, revisor and package management improvements"

"In addition to the structural changes that the Fedora project has made to its software repository framework, the team has noticeably sped up the distribution's Red Hat Package Manager/Yum package management backend. Also, as we mentioned earlier, Fedora's graphical tool for creating and managing virtual machines is much improved as well. For one thing, the tool now lists idle VMs alongside running VMs, which is something that only the system's command-line tool was capable of in previous releases."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00096.html

[2] http://www.eweek.com/article2/0,1895,2142494,00.asp

Review: Fedora 7 (linux.com)

RahulSundaram reports in fedora-marketing-list[1] ,

"Fedora 7 was released last week, a little bit behind schedule, with a spate of new features, updates, and live CD installable "spins" of Fedora in KDE and GNOME flavors. I found a lot of good in this release, but a bug in the FireWire stack that attacked my external backup drive made this release just a little shy of perfect.[2] "

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00094.html

[2] http://www.linux.com/article.pl?sid=07/06/06/1327234

Review: First look at Fedora 7 (distrowatch.com)

LuyaTshimbalanga reports in fedora-marketing-list[1] ,

"A very positive review[2] from Distrowatch submitted by Chris Smart, Kororaa developer

From the initial boot of the installer the system exuded a sense of stability which filled me with confidence the more I used it. The installer is probably the best I have ever used and is very powerful while remaining simple to use. Top marks for that. Overall, the default GNOME install of Fedora is very good and (non-free software idiosyncrasies aside) as a Linux distribution in itself I thought it was excellent. If what you are after is a reliable, stable, easy-to-use yet powerful Linux distribution out of the box, then Fedora fits the bill nicely."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00040.html

[2] http://distrowatch.com/weekly.php?issue=20070604#feature

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

Community Control And Documentation Of New Workflows

The shifting sands of power within the Fedora Project continued to cause a scramble for surer footing within a thread that started[1] last week. ThorstenLeemhuis clarified[2] to JasonTibbitts that one of the problems he perceived. Although the merge of Core/Extras was widely desired, it had happened in a confusing way that required very close attention to high-volume mailing lists, or else packagers were suddenly ignorant of the procedures to build or push. Thorsten emphasized that he did not blame FESCo, but that lots of people were unhappy with the addition of ACLs (Access Control Lists) to CVS and the sudden enabling of Koji, Bodhi, and the freeze. Pulling fewer punches, RalfCorsepius voiced[3] a suspicion that FESCo was impotent and the real decisions were made elsewhere.

[1] http://fedoraproject.org/wiki/FWN/Issue90?action=show&redirect=FWN%2FLatestIssue#head-d6f0b8d5bcf1e95e8d776ca23d4d8837c27fdfe5

[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00338.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00340.html


Thorsten suggested[4] that "spare-time packagers" should have some form of representation as they tend not to get their voices heard. He also wanted to clarify the roles of the Fedora Project Board and FESCo, especially in the light of upcoming elections to FESCo. JoshBoyer responded later[5] that he needed time to respond to Thorsten's email and that silence shouldn't be taken as acquiescence on any points made in the discussion so far. JesseKeating also requested[6] that Ralf hold-off on his darker thoughts until sufficient reasonable time had elapsed for discussion.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00345.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00373.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00375.html

Responding to NicolasMailhot's earlier points about giving the Infrastructure team more credit, PatriceDumas replied[7] that it wasn't about giving or withholding credit, but trying to focus on why specific processes had been made mandatory despite some packagers' objections and preference for shortcuts. Nicolas responded[8] that while Extras had been good at packaging policy and build tools, Core had been good at release-engineering and leaving those decisions up to individual packagers would be like herding cats. Patrice thought that education rather than heavy-handed rules were the answer, but Jesse invoked[9] the weighty counter-argument of experience.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00347.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00350.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00374.html

Confessing that he felt that the F7 workflow had not been ideal, Jesse suggested a series of release-engineering meetings for anyone interested. HansdeGoede thought[10] that discontent was not necessarily due to the freeze workflow, but more likely to the absence of an updates policy and the absence of proper documentation for new tools and workflows. Jesse pleaded[11] for anyone that saw inadequate wiki pages to help out and make the changes. He also defended[12] against Hans' charge of information being hidden on @fedora-maintainers by asserting that he had tried to start a new thread for each new procedure. Jesse further expressed frustration that there were no positive suggestions for how to improve communication.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00379.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00386.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00389.html

KevinKofler attested[13] that he just changed incorrect wiki entries when he came across them, for which Jesse thanked him and then HansdeGoede provided[14] links to pages that he believed should be edited by the people introducing changes. Hans made the argument that those introducing new tools and workflows were best placed to edit these pages, preferably before making radical changes to the workflow. Jesse responded[15] that he had been frankly unaware of the NewPackageProcess page referred to by Hans and suggested that there be a FESCo requirement that any workflow changes require a draft that includes a requirement to update the appropriate wiki pages.

[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00397.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00410.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00413.html

A semi-humorous suggestion[16] from HansdeGoede proposed that only those who maintained thirty or more packages should be allowed to make rules. There was general agreement that there was an issue to be addressed with rule-makers being out of touch with the majority of packagers and also a general disagreement, best expressed[17] by NigelJones, that there should be any sort of weighting of votes based on number of maintained packages.

[16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00213.html

[17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00334.html

A fork of the original thread was made by JonathanUnderwood to encourage[18] people to write documentation so that the community could re-engage. JesseKeating thought this was a great idea and sought[19] someone to take on the task of co-ordination.

[18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00399.html

[19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00406.html

Fedora On ARM Architecture Opens Up Cross-Compilation Discussion

A (re)introduction[1] from LennertBuytenhek contained a brief resume of Lennert's impressive hacking history and a tantalizing glimpse of what the opening up of Fedora to other architectures could mean. The opening for architectures was originally discussed last week[2] , FWN#90 "Fedora Secondary Architectures Proposal". Lennert had been maintaining ports of Fedora Core {2,3,4,6} and wanted to merge his changes back upstream. DaveJones was happy[3] with what he saw and made the suggestion that the config file shouldn't be monolithic, but should be generated out of templates, as is done currently for the Fedora kernel RPM.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00189.html

[2] http://fedoraproject.org/wiki/FWN/Issue90#head-271f52b8e5603cd40d00d7c44ec8632cae42b1aa

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00292.html

As an aside TomCallaway(spot) noted[4] that SPARC-32 support was probably going to be dropped in F8, leading to some jokes about the devastation of its two users. AlanCox thought[5] that Fedora should track upstream, meaning that if it was supported in the Linux kernel trees then it should be in Fedora. However, even the fans of the architecture were unwilling to defend[6] it and pointed out that upstream were making noises about dropping it.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00463.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00487.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00594.html

Responding to DaveJones' comments, Lennert provided[7] a wealth of information about the diversity and non-similarity of ARM CPUs in the course of explaining why a kernel image RPM wasn't actually built at this point.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00899.html

Also welcoming[8] Lennert was LinusWalleij, who suggested that Lennert should open bugzilla reports for each package for which he had diffs. Linus also asked about Lennert's native build strategy as opposed to cross-compiling and his target system, something in which PeteZaitcev was also interested[9] . ManasSaksena provided specific details[10] and also added the information that, unlike other architectures, it would not be useful to produce an ISO, but instead to produce a package repository and tools to create custom root filesystems.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00501.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00632.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00761.html

HansdeGoede thought that cross-compiling seemed to be difficult unless the packages had been designed with that in mind from their inception[11] . AndyGreen had his own experience with cross-compiling for arm9 and avr to add[12] , and argued that improving common packages to make cross-compiling easier would be a great advantage for Fedora. ManasSaksena agreed[13] with this and provided encouragement about the practicality of dealing with Perl and Python. KrzysztofHalasa and AndyGreen exchanged details[14] of their build procedures.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00505.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00509.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00762.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00545.html

A detailed exploration of the problems of cross-compiling, with special reference to rpmbuild, was undertaken[15] by Andy and RalfCorsepius.

[15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00783.html

AdamJackson(ajax) felt that the Xorg packages looked sane and thanked[16] Lennert for his good work, while noting that the main change in migrating the packages to F7 was to change ExcludeArch from ExclusiveArch.

[16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00542.html

A sub-thread evolved to investigate the problems of cross-compilation[17] . This sprouted many intricate offshoots, for instance one in which BrendanConoboy and RalfCorsepius discussed[18] whether redhat-rpm-config was fundamentally broken or could be modified to become cross-compilation friendly. Another scion took root in a discussion[19] of generic cross-compilation on Fedora. ManasSaksena tipped a nod[20] to a possibly useful tool from ChrisFaylor called tsrpm, which would allow the systematic derivation of customized root filesystems for cross-compilation to specific devices.

[17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01006.html

[18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00837.html

[19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00895.html

[20] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00960.html

Brendan opened[21] a wider discussion with the Fedora community in which he recounted the experiences of his Red Hat group (GES) that has largely abandoned native builds and emulators in favor of cross-compilation. Brendan was enthused by the discussion about ARM and identified a need for cross-compilers, modified packages, and volunteers to avoid extra burdens on packagers.

[21] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01006.html

OliverFalk (Alpha ArchTeam) wanted to know[22] specifically if cross-compilation was always as reliable as native compilation in exposing errors, and also thought that if specific ArchTeams chose to eschew cross-compilation then they should be allowed to do so. AndyGreen backed up[23] Brendan's recommendations (due to his own experimentation) and answered that there ought to be no difference between the object code emitted by a cross-compiler or a native-compiler.

[22] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01075.html

[23] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01078.html

Hastening to make sure that cross-compilation and new secondary architectures were not conflated, Brendan replied[24] to Oliver that there while there were some problems unique to cross-compilation it was nevertheless reliable. Brendan suggested the idea of a CrossTeam similar to the ArchTeams.

[24] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01186.html

A World Of Hurt: Making F7 Install CD Set From DVD Using FC6 Pungi

Several posters have expressed disappointment in the past that the Fedora 7 images were available only as DVD images and not as a set of CDs. TonyNelson sought help[1] in filling this need. JesseKeating made[2] some helpful suggestions about how this splitting could be achieved using Fedora 7 and drew Tony's attention to the novel use of a manifest file by Pungi instead of comps.xml. In response[3] Tony clarified that he was specifically only interested in using Pungi from (and on) FC6 to try to split the F7 DVD.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00638.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00660.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00680.html

JarodWilson thought[4] that Tony had taken on a tough job because the .manifest was only in post-FC6 Pungi and it wasn't easy to backport. Tony argued[5] that Jarod was suggesting that CD-only upgraders would have to install F7 in order to have a way to install F7! He wondered what problems might occur besides missing 20 packages from comps.xml. JesseKeating listed[6] some of the huge changes (to pungi, the yum API, anaconda-runtime calls etc) that would complicate the task that Tony was tackling.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00684.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00693.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00697.html

Continue probing from Tony prompted[7] Jesse to explain that the manifest file is of kickstart syntax, the files listed in it are taken by Pungi, then anaconda tools are run on them. The version of anaconda must match the one in the distribution.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00699.html

After Tony seemed ready to give up Jesse wondered why he didn't use the LiveCD image. Tony responded[8] that it was only useful for a clean install and put the use case of someone with low-bandwidth and not enough harddrive space for the DVD iso.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00708.html

"Vnpenguin" and JarodWilson had both suggested installing "mock" and using the resulting chroot to run pungi and Jesse pointed to the docs explaining how to run pungi in mock[9] .

[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00801.html

Splitting Terminfo Out Of The ncurses RPM

The burst of OLPC inspired activity (see "Eliminating Unwanted RPM Dependencies And Statically Linked Binaries" elsewhere in this issue) from BernardoInnocenti had the positive side-effect of slimming the standard Fedora distro. One piece of bloat identified[1] by Bernardo was the bundling of 2MB of terminfo data with ncurses, which Bernardo suggested be split out into a separate sub-package. The discussion was irritatingly split between @olpc-devel and @fedora-devel, which made it hard to follow.

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

MiroslavLichvar warned[2] that the terminfo data shouldn't be eliminate entirely but agreed that it could probably be split out. Referencing[3] Ubuntu's practice, ArndBergmann agreed and suggested a shortlist of terminals that could be included in the ncurses package as a safe minimum. Arnd later described[4] the current split of a small subset into /lib/terminfo while the exhaustive collection is in /usr/share/terminfo and brought up the problem of 32 and 64 bit libraries.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00510.html

[3] http://marc.info/?l=olpc-devel&m=118099052410892&w=2

[4] http://marc.info/?l=olpc-devel&m=118113689230162&w=2

The multilib problem was also addressed[5] by BillNottingham who argued that in order to make upgrades sane, it would be best to keep the libraries within a package with the same name as the original. SimoSorce thought[6] that Bill's approach was improperly constrained by the brokenness of multilib detection. RexDieter agreed[7] that multilib detection should be fixed but disagreed that Bill's proposal resulted in substandard packaging. Bill returned to the problem of making the upgrade work, which JeremyKatz agreed[8] with but suggested that a work-in-progress from SethVidal might offer a resolution.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00920.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00930.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00936.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00962.html

Eliminating Unwanted RPM Dependencies And Statically-linked Binaries

Following from the decision[1] to open up the Fedora Project infrastructure to the OLPC, BernardoInnocenti queried[2] whether it would be possible to remove some hard dependencies for particular RPM packages. The advantage for OLPC would be the ability to use pristine Fedora packages without pulling in unnecessary bloat. This advantage would accrue to other projects basing themselves off the Fedora Project.

[1] http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070607

[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00478.html

DavidTimms posted[3] a lovely dependency tree diagram for GRUB, showing that there would be advantages in separating out the fedora-logos into their own package. David also noted that glibc-common was severely bloated by localization (which slowed install time and presented problems for small harddrives). David suggested that similar to OpenOffice, the localisations could be split into sub-packages and hacked into comps.xml. Finally, David wondered whether there was a tool that would correlate disk-access to files and thus to RPM packages, allowing an analysis of unused files in particular RPMs. "SteveG" (StevenGrubb) suggested[4] using auditctl and aureport for this purpose.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00519.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00550.html

JeremyKatz cautioned[5] against David's suggested approach as it's result would be an increase in metadata size, an increased rpmdb size, and unpredictable side-effects due to comps being a bit hackish. Jeremy also noted that if one were willing to give up being able to use DeltaRPMs then setting the %_install_langs rpm macro properly will exclude non-desired locales.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00560.html

David and Jeremy dug deeper into the size trade-offs, with Jeremy estimating[6] that the increase in metadata and rpmdb size would be larger than David expected. David had asked whether the installer could take note of the %_install_langs setting and Jeremy replied that it didn't (although it used to) and that setting it via kickstart would be appropriate for small-footprint installs.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00616.html

A suggestion[7] by Bernardo to provide just one mega-locale package, which would allow the space-constrained (e.g. embedded developers) or lovers of the plain "C" locale an advantage, was countered[8] by JeremyKatz as too Western-centric. Jeremy also argued that a frequent request in the past had been post-installation addition of language support and the current setup made this much easier. Jeremy then provided further details of the workings of DeltaRPMs in response to Bernardo.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00735.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00745.html

As regards the GRUB dependencies, NicolasMailhot pointed out[9] that the problem would be obviated once the default display of a themed GRUB menu is removed. After Jesse suggested that the policy on directory ownership could be relaxed in the case of the fedora-logos package, DavidTimms was keen[10] to get things rolling or else hear a definite "No".

[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00595.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00609.html

Another of Bernardo's suggestions was to remove mkinitrd's dependency on lvm2 and dmraid, but JeremyKatz[11] pointed out that this would lead to problems with initrd creation in the kernel's %post and suggested that this was an area that would benefit from some creative solutions. DavidZeuthen thought[12] that the OLPC's kernel wouldn't need mkinitrd because it had all the drivers built-in. Bernardo thought otherwise[13] due to both the dependency and because of the need to boot from USB with the ext3 image. The need for any static binaries at all was also questioned, and Bernardo dismissed the "disk space is cheap" argument. David replied[14] with the suggestion of using a dummy RPM package to satisfy the dependency and pointed to UlrichDrepper's post on @fedora-devel on the subject of static linking.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00559.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00582.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00637.html

An ensuing discussion of static vs. dynamic linking between a skeptical PatriceDumas and BernardoInnocenti led to ChrisAdams providing[14] some concrete proof that dynamic-linked binaries are smaller than statically-linked "in the real world". Later Bernardo diverged slightly into a discussion[15] of how Linux has become bloated. NicolasMailhot argued that the solution was optimized, co-ordinated dynamic libraries (citing Pango and Qt's co-operation on Harfbuzz), to which Bernardo agreed and noted that OSX had banned static linking with system libraries.

[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00805.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00888.html

[16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01032.html

A dependency of HAL on crypsetup-luks turned out[17] to not be needed according to PeterJones, helping Bernardo to eliminate 1.2MB.

[17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00591.html

F7 Images For Mass Production

Since the release of Fedora 7 ISO images to the mirrors, there have been several bugs reported and fixed. The availability of these fixes led to a dilemma[1] for MaxSpevack who was just about to start pressing DVDs for the FreeMedia program and FedoraEvents, and wondered whether the original "GOLD" images should be used for Fedora LiveCDs and DVDs or if updates should be somehow incorporated.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01119.html

The ensuing discussion saw three main viewpoints emerge. The first was that the GOLD images should be used exactly as though they'd been pressed immediately upon release of F7 with the simple addition of an updates.img to fix simple anaconda problems. ChristopherAillon and JesseKeating were strongly in favor[2] of doing this and adding a sleeve-note about known bugs and work-arounds. ThomasChung (coordinator of the FreeMedia program) was also in favor[3] , and Max deferred[4] to their opinions as Jesse has an overview of the ReleaseEngineering problems while Thomas has his finger on the pulse of the users of these DVDs. Jesse gave a good quick rundown[4a] of all the potential problems with regressions that a respin would involve. PaulFrields pointed to a serious problem with localization that seemed like it was a simple updates.img fix, but which Jesse's dissection[4b] revealed as a slightly more complicated, but fixable problem.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01141.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01130.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01151.html

[4a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01133.html

[4b] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01155.html

Another approach was advocated[5] by WarrenTogami, who suggested that all that should change would be to update the both the kernel and anaconda (using an updates.img) to fix some of the egregious bugs such as non-booting Dell Core2Duo machines and e1000 NIC problems. ChrisLumens thought[5a] that the updates.img would avoid getting a fresh-round of bug-reports on known issues. RahulSundaram tried[6] to figure out why a public point-release wasn't being considered so that anyone could benefit from the work which Max thought was worth doing. Suspend/resume breakage was also suggested as a candidate for this sort of patching, but Rahul's query[6a] as to whether there was a fix for this remained unanswered.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01122.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01143.html

[6a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01137.html

Expanding[7] the previous respin idea a bit, HansdeGoede wanted to add network security fixes. Jesse extrapolated[8] to the likely outcome of this approach, which he saw as a series of slow-moving bug-fix releases similar to Red Hat's approach to RHL. AxelThimm noted[9] the emerging consensus against a respin this time but suggested that in future there would always be a post-GA respin. Jesse was against[10] this being done as an "official" Fedora Project undertaking, due both to the QA problems and because users would simple ignore the GA and wait for the respin instead, thus deferring the problem. BrunoWolff thought[11] it might work because the ability to upgrade would be guaranteed, making it different from a test-release. FedoraUnity had been mentioned by several people in the discussion and Axel wondered[12] if something similar were offered on a weekly basis.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01145.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01150.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01212.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01225.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01246.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01249.html

Exploding Trees and SCM

JeffOllie got the ball rolling[1] for an @fedora-devel discussion of possible ways and means of replacing the current CVS system with a more useful SCM (Source Configuration Management system). The discussion had been started[2] on @fedora-infrastructure and JeremyKatz had supplied some helpful discussion points.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00839.html

[2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00074.html

JesseKeating thought[3] that with F8T1 being a mere two months away it was unrealistic to attempt to make the transition before F9. In addressing the specific desiderata listed by JeremyKatz, it seemed that Jesse leaned towards using exploded source trees to make it easier for package maintainers to adapt their patches to changing upstream, and the "git" SCM to distribute changesets.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00835.html

Jeffrey agreed[4] with Jesse's post-F8 timeframe, but suggested that it might be possible to implement a system that didn't disturb packagers' workflows, yet laid the groundwork for a more radical change in the future. In response Jesse forwarded an @fedora-infra post from Jeremy that argued[5] that this would actually require people retraining twice.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00842.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00845.html

Responding to the original discussion points, AxelThimm thought that easing packagers tracking of upstream depended on what those upstreams were using as SCMs. Axel also leaned[6] towards a distributed SCM such as git or Hg to facilitate Fedora downstream fixes making it back into the Fedora Project easily, with the choice being left up to the Koji developers who would have to do the actual implementation.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00844.html

A request from Jesse during the discussion was that participants list features in which they were interested, rather than particular SCMs. The discussion seemed to peter out on @fedora-devel with a discussion between Axel and Jesse as to whether or not Hg supported renames[7] .

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01012.html

A related thread from @fedora-infrastructure was cross-posted[8] separately by JeremyKatz. ChristopherBlizzard advanced[9] the idea that because Fedora tries to reflect the upstream of each project it should possibly do that with regard to SCM choice. Jeremy argued[10] against this as it made it hard to coral changes of Fedora-specific interest and also introduced a requirement for knowledge and inter-operation of multiple, different SCMs. Some parts of the discussion stayed on @fedora-infrastructure.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00855.html

[9] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00091.html

[10] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00093.html

ToshioKuratomi(abadger) suggested[11] looking at what Ubuntu was doing (albeit for different reasons) with their "Hypothetical Changeset Tool". In response JesseKeating drew the distinction[12] that exploded trees with patch management weren't exclusive to generating SRPMS, but was a layer that could operate as an input to the buildsystem which would then produce the SRPMS. BillNottingham was skeptical[13] about how much this would help the drive to cohere with upstream.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00935.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00969.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00976.html

At this point[14] a discussion between NicolasMailhot and ToshioKuratomi became far too complex for your humble observer to follow and those interested should probably look at the thread themselves. The main arguments seemed to be that Toshio liked[15] the ability to pull specific subsets of patches to submit upstream, which is given by DRCS. Nicolas thought Toshio's premises were unrealistic in assuming that Fedora would fork upstream so heavily and also that his approach would not separate patches specific to Fedora with patches for upstream[15] . For a full understanding, refer to the relevant thread.

[14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00964.html

[15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01010.html

Why Emacs Is Not Installed By Default

After "Shams" asked[1] why Emacs was not installed by default, ManuelWolfshant shook the hornets' nest by suggesting that not everyone wanted a second OS installed. OlivierGalbert was the first to react[2] , pointing out that if Emacs were axed then it wouldn't be long before vi followed, Olivier surmised that "windows envy" was determining desktop choices. MatejCepl[3] and LinusWallej[4] drew attention to the POSIX/IEEE 1003.1 requirement for vi, but not for Emacs.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00470.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00494.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00615.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00502.html

PatriceDumas suggested that the tools for re-spinning Fedora would allow userbases that had different visions of the desktop to build a Fedora that they liked, but NicolasMailhot had apparently been stung by Olivier's comment and bravely plunged on[5] , arguing that Emacs was "going the way of the dodo because it targets 1995-ish desktops". A swarm of questioners including AndrewHaley sought clarification from Nicolas, to which he responded[6] that Emacs didn't use the desktop font infrastructure, i18n, a11y, one of the main GUI toolkits, or integrate with the printing infrastructure. TomTromey returned[7] to the question of what specific maintenance burden was imposed by Emacs, and reminded everyone that Emacs wasn't being removed, it just wasn't included in the default install. JeremyKatz agreed[8] and pointed out that the situation had been like this for a while. Nicolas answered[9] Tom with the information that Emacs' dependency on the legacy font system was the main problem.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00500.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00540.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00557.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00558.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00593.html

Taking a stab at answering Shams's question, NigelJones guessed[10] that popularity was probably the answer. Going one better, JefSpaleta posted[11] statistics from Mugshot that showed Emacs having marginally more users. AlexandreOliva explained[12] that Emacs did a lot more than mere text-editing.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00476.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00583.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00644.html

Metalink: A New Way Of Distributing Fedora ISOs?

A suggestion[1] from AnthonyBryan about a new way to distribute Fedora using Metalinker[2] has gained some traction. Metalink is an open standard that puts an XML wrapper around all the possible available URIs for common protocols such as HTTP and FTP. It allows segmenting of the source and hence simultaneous downloading from multiple mirrors. JesseKeating suggested using MirrorManager to automatically create the metalinks, to which RahulSundaram replied[3] that he'd suggested this a while ago. A tool authored[4] by DavidTimms to allow reconstruction of ISO images from previous versions may be useful for this problem.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01160.html

[2] http://www.metalinker.org/

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01164.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01207.html

Responding to the positive reception, Anthony (as the author of Metalink[5] ) wondered whether he should supply[6] a patch to MirrorManager, and was advised to open a discussion with MattDomsch on @fedora-infrastructure. Anthony pointed out that no other distribution was generating dynamic .metalinks on a large scale. Matt responded[7] briefly on @fedora-devel to indicate that he would be happy to accept and review patches.

[5] http://www.packtpub.com/article/Downloading-evolved-with-Metalink

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01200.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01230.html

Quick Notes On Update Image Installer And F8 Desiderata

Last week's thread[1] on providing a grub-entry for an installer image to facilitate upgrading kept going. WillWoods posted[2] a modified plan of attack leading JesseKeating to add[3] that yum/rpm would be needed for depsolving and a pessimistic BillNottingham to warn[4] about Python ABI changes, JeremyKatz confirmed[5] this pessimism to an optimistic[6] ColinWalters

[1] http://fedoraproject.org/wiki/FWN/Issue90#head-4fa2b381c1834f3104cff9fe61bf9e49d1b1e1db

[2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00704.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00705.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00725.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00742.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00744.html

In a completely separate thread initiated[7] by HansdeGoede, a laundry list of desired features for F8 was under construction. Among Hans' more controversial proposals were a plugin-buddy, a firmware-buddy, and a proprietary-software-installer-buddy. BillNottingham wondered[8] which wireless cards the firmware-buddy would be useful for and didn't like the bug-chasing that would introduced by the proprietary-software. Hans listed the ralink, BCM43xx, and SIL cards and agreed with JeremyKatz who expressed[8] a preference for working upstream with the vendors so that the firmware could be shipped in perfect working order. Interested thread participants started[9] a wiki page[9a] to collect and document missing firmware.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00890.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00927.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00955.html

[9a] http://fedoraproject.org/wiki/SIGs/FirmWare

BernardoInnocenti noted[10] that Firefox's plugin system would, if applied by many applications, lead to Linux "becoming as maintainable and robust as Windows". RalfErtzinger liked the RPM-free nature of Firefox plugin installation and TillMaas showed[11] how difficult it might be for non-root privileged users to install RPMs.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01022.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01290.html

Documentation

In this section, we cover the Fedora Documentation Project.

http://fedoraproject.org/wiki/DocsProject

Contributing Writer: JonathanRoberts

CVS Walkthrough in IRC

BartCouvreur held a session in #fedora-docs on freenode, explaining how to use CVS as part of the Docs Project. This session was also useful as a general introduction to CVS if you've never used it before. If you're interested in learning how to use CVS, as part of the Docs Project or more generally, the log of the session was posted to the fedora-docs-list[1] and is also available as nicely formated HTML[2] . You can also find detailed information in the Documentation Guide[2] .

[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00037.html

[2] http://fedoraproject.org/wiki/JohnBabich/CvsLesson

[3] http://docs.fedoraproject.org/documentation-guide/ch-cvs.html

RPM Guide

JoseManimala volunteered to maintain the RPM guide[1] . This led to a discussion about the best place for this guide to be maintained. As the Fedora Project's software aims to stay as close to upstream as possible, is there any reason why content should not as well?[2] . It turned out that upstream had already pointed to the guide, and suggested that people wanting to work on it should do so through the Fedora Documentation Project[3] .

At this point this guide does not have a team around it. If anybody has experience with RPM and wants to help Jose Manimala, post to the fedora-docs-list and co-ordinate from there.

[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00006.html

[2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00038.html

[3] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00061.html

Fedora Documentation Steering Committee Meeting

The log for the FDSCo meeting of the 5th June was published to the fedora-docs-list[1] .

[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00054.html

Fedora 7 FAQ

RahulSundaram forwarded a message to the fedora-docs-list, requesting that a link to the Fedora 7 FAQ be added to the docs.fedoraproject.org front page[1] . The message that was forwarded also included a request for a link to the FAQ to be included on the new fedoraproject.org home page, which led to a debate over whether this was appropriate, given that the home page has just been given a minimalist redesign[2] .

[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00057.html

[2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00058.html

Translation

This section, we cover the news surrounding the Fedora Translation (L10n) Project.

http://fedoraproject.org/wiki/L10N

Contributing Writer: JasonMatthewTaylor

Bugzilla for Trans Team

DimitrisGlezos and others have been discussing the idea of adding a Translation team component[1] to Bugzilla in order to better track changes, change-requests, suggestions, etc.

[1] https://www.redhat.com/archives/fedora-trans-list/2007-June/msg00014.html

Infrastructure

In this section, we cover the Fedora Infrastructure Project.

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: JasonMatthewTaylor

Backups

With recent changes and additions to the project infrastructure, MikeMcGrath and others have decided to look into new backup [1] options.

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00065.html

Fedora 7 Upgrade

Fedora 7 being released prompted some discussion[1] about whether or not to upgrade infrastructure systems. After some discussion it seemed to be agreed to review each systems requirement and upgrade accordingly.

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg00098.html

Artwork

In this section, we cover Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: JonathanRoberts

Fedora 8 Artwork

MatthiasClasen sent a message to the fedora-art-list, hoping to prompt discussion on the art work for Fedora 8[1] . The central points of his message were:

  • Diana Fong is no longer employed by Red Hat and so it is probable there will be no full time artist to work on the F8 release
  • He proposes trying a different approach to the art work for F8, less branded and less image based
  • The graphical boot is changing and may result in less art work (and less restrictive art work) for the boot sequence
  • Questioned the state of the Echo icon theme - will it be ready for F8?

NicuBuculei proposed that a similar system to Fedora 7 is followed, where the art work is decided upon through a 3 round competition[2] . As part of this MarekMahut suggested that we try to get schools involved. It was suggested a possible problem with this would be that they use proprietary software; virtual workshops about FOSS art tools was proposed as a possible solution[3] .

RahulSundaram reminded the list that one comment that has appeared fairly often in early reviews of Fedora 7 is that Clearlooks looks dry compared to the polished appearance of the rest of the distribution[4] . Following this two new threads were started, creating mock-ups of new default themes for Fedora 7[5] [6] .

MairinDuffy has proposed a milestone based approach for the Fedora 8 art work, which was received well as a preliminary schedule[7] . Highlights of the proposed schedule include a "promo kit" and the discussion of tag lines and promo banners for the fedoraproject.org websites, in co-operation with the fedora-marketing-list.

[1] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00002.html

[2] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00003.html

[3] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00019.html

[4] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00012.html

[5] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00052.html

[6] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00069.html

[7] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00039.html

Echo Icon Theme

Following the thread about Fedora 8 art work, LuyaTshimbalanga updated the list on the state of the Echo icon theme[1] . The problems with the SVG icons encountered before the release of Fedora 7 are now fixed, although a few will need reworking; the Echo pull script is currently broken on x86_64; work on Echo icons is now resuming.

[1] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00011.html

Security Week

In this section, we highlight the security stories from the week in Fedora.

Contributing Writer: JoshBressers

Google: Attack code more likely on Microsoft IIS

"Computer World Security reports[1] Google's malware team discovered[2] that a server running Microsoft IIS is twice as likely to be hosting malicious software as are other web servers.

The Google team doesn't draw many conclusions from this data. It is suspected that it's likely a number of these machines are not automatically installing security updates for one reason or another.

The most disturbing part of the reports is that there are about 70000 domains hosting malware or browser exploits. This is a huge number of hosts. No doubt some of those domains are purposely hosting exploits, but it's also disturbing to consider that there are thousands of administrators who have no idea their server is being used for dubious purposes."

[1] http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9023538

[2] http://googleonlinesecurity.blogspot.com/2007/06/web-server-software-and-malware.html

Bruce Schneier: Department of Homeland Security Research Solicitation

"Bruce Schneier points[1] out a paper from the DHS. They are looking for researching into how to deter and prevent malware on the Internet. As Bruce points out, it's about time someone is investing in this sort of thing. It is shameful how bad computer security is today. As more and more computers attach to the Internet, the number of infected machines will continue to increase. Educating users and administrators isn't working and probably won't. The best solution is going to be to stop the malware before it has a chance to cause any damage. There is no doubt a great deal of money to be made in whoever solves this rather difficult problem."

[1] http://www.schneier.com/blog/archives/2007/06/department_of_h_1.html

Advisories and Updates

In this section, we cover Secuirity Advisories and Package Updates from fedora-package-announce.

Contributing Writer: ThomasChung

Fedora 7 Security Advisories

Fedora Core 6 Security Advisories

Events and Meetings

In this section, we cover event reports and meeting summaries from various projects.

Contributing Writer: ThomasChung

Fedora Event Help Needed: 2007 Libre Software Meeting - France

MaximeCarron reports in fedora-ambassadors-list[1] and requesting help on his Fedora Event at Amiens, France[2] ,

"From July the 10th to 14th will occur the RMLL (Rencontres Mondiales du Logiciel Libre) ie "Free Software World Meetings" in Amiens, France. RMLL is a big and great event in France. Lots of poeple are coming from all over the world, and both high level and beginner conferences are planed during the week."

"Currently we're just 2,5 volunteers for this events (ChristophePolyte, CharlesVinchon, MaximeCarron [i'm the half] ), which is really not enough. We need your help."

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2007-June/msg00045.html

[2] http://www.rmll.info/?lang=en

Editor's Note: Here are online photo albums[1] from 2006 and 2005 events.

[1] http://photo.rmll.info/main.php

Fedora Event Report: LinuxTag 2007 - Germany

FabianAffolter reports in fedora-ambassadors-list[1] ,

"LinuxTag[2] is over...we have had a good time there and the attendance of the Fedora Project at this event was a success. If you want to know what was going on there, check out the blogs of the attendees."

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2007-June/msg00035.html

[2] http://www.linuxtag.org/2007/

Fedora Ambassadors Meeting Minutes 2007-06-07

Fedora Documentation Steering Committee 2007-06-05

Fedora Engineering Steering Committee Meeting 2007-06-07

Fedora Packaging Committee Meeting 2007-06-05

Fedora Release Engineering Meeting 2007-06-04

Feedback

This document is maintained by the Fedora News Team[1] . Please feel free to contact us to give your feedback. If you'd like to contribute to a future issue of the Fedora Weekly News, please see the Join[2] page to find out how to help.

[1] http://fedoraproject.org/wiki/NewsProject

[2] http://fedoraproject.org/wiki/NewsProject/Join

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Issue91&oldid=7997"