In this week's issue, featured content includes announcements on a new Fedora Sugar Spin, and development freeze for Fedora 10. The Translation beat this week features an interview with Fedora Translation project member Diego Zacarao (Rasther). In Developments, details on resume from suspend problems with Intel i945s, details on "[a] gigantic multi-thread flamewar consum[ing] many list participants" over moving X from VT7 to VT1 and POSIX file capabilities for Fedora 11. The Artwork beat features discussion of new wallpaper extras, and final fixes for the Fedora 10 Solar backgrounds. The Security Advisory beat rounds out this issue and updates us with fixes released in the last week for Fedora 8 and 9.

If you are interested in contributing to Fedora Weekly News, please see our 'join' page[1].

If you are interested in contributing to Fedora Weekly News, please see our 'join' page[1].

Fedora Weekly News Issue 150

In this week's issue, featured content includes announcements on a new Fedora Sugar Spin, and development freeze for Fedora 10. The Translation beat this week features an interview with Fedora Translation project member Diego Zacarao (Rasther). In Developments, details on resume from suspend problems with Intel i945s, details on "[a] gigantic multi-thread flamewar consum[ing] many list participants" over moving X from VT7 to VT1 and POSIX file capabilities for Fedora 11. The Artwork beat features discussion of new wallpaper extras, and final fixes for the Fedora 10 Solar backgrounds. The Security Advisory beat rounds out this issue and updates us with fixes released in the last week for Fedora 8 and 9.

If you are interested in contributing to Fedora Weekly News, please see our 'join' page[1].

Translation packagers: Rebuild before devel freeze

Dimitris Glezos wrote[3] to remind "maintainers of Fedora-translatable packages to issue a build before the Development Freeze of tomorrow, 28/10, in order to have all translations submitted until the translation deadline of 21/10 included in Fedora 10 (otherwise our translator's hard work will go to the gutter)."

Fedora Sugar Spin

Sebastian Dziallas announced[4] the "availability of our Fedora Sugar Spin, which incorporates the Sugar Desktop Environment on a Fedora Live CD." To get the spin, and to contribute to its further development, read the full announcement below.

Frozen for Fedora 10

Jesse Keating reminded[5] everyone that we are now frozen for Fedora 10. "At this point, builds for F10 are not automatically brought into Rawhide, and won't be in the Fedora 10 release. To request a freeze override, please use the Final Freeze Policy[6]."

Translation

FTP Meeting to be held on 4th November 2008

FLSCo member Noriko Mizumoto announced the next meeting of the Fedora Translation Project to be held on the 4th of November 2008[1]. The time for the meeting is yet to be determined, with 1900 UTC and 2000 UTC being the two probable candidates. The meeting and agenda is open for all[2].

Package Rebuild requested by FTP

Dimitris Glezos has requested the maintainers of the Fedora packages that were translated for Fedora 10 to rebuild them[3]. This would ensure that the translations submitted by the Fedora Translation Project members are included for all these packages.

TQSG repository set to be moved

Fabian Affolter has initiated discussions to move the the Translation Quick Start Guide (TQSG) to fedorahosted[4]. The move has been endorsed by Paul Frields on behalf of the Fedora Documentation team, subject to confirmation by FLSCo about the move and the ownership of the document[5]. The final decision, particularly about the VCS to be used, is pending at the moment.

Dimitris Glezos nominated for the Fedora Board

FLSCo Leader Dimitris Glezos has been nominated[6] by Max Spevack as one of the candidates for the upcoming Fedora Board elections to be held in December 2008. These elections would be held to elect two new members for the Fedora Board.

Diego Zacarao interviewed

Fedora Translation project member Diego Zacarao (Rasther) was recently interviewed about his contributions to Transifex and Fedora Translation Project [7].(The Original version in Brazilian Portuguese[8].)

Developments

Resume from Suspend Problems with Intel i945

Peter Robinson solicited[1] experiences with problems on netbooks in resuming from suspend from those using the latest Intel-2.5.0drivers. His problem suddenly manifested itself on a previously working EeePC 901: "It had worked previously and resumes OK but I get a black screen with a cursor and around that a square of garbled bits." Peter wondered what had changed recently in order to make suspend-resume stop working.

Jeremy Katz suggested[6] using the suspend quirks[7] , especially vbepost. Matthew Garret believed[8] this to be unnecessary as "i945 is perfectly capable of handling resume on its own in-kernel. The problem is more likely to be an excess of quirks interfering with that (or, alternatively, someone's broken the kernel)."

as this would indicate that there had been a regression in 2.5.0 as opposed to a kernel bug. Matthew Garrett thought that Jesse's suggestion would not test the same suspend pathway and that it would be better to do a:

Moving X from VT7 to VT1

A gigantic multi-thread flamewar consumed many list participants after Will Woods made sure[1] that everyone knew that in Rawhide "X HAS MOVED FROM VT7 TO VT1. GDM specifically starts X on tty1, and upstart does not start a getty on tty1 in runlevel 5." The reason behind this change was that the boot process no longer uses the old RHGB but instead a flicker-free and faster replacement named Plymouth (see Fedora Magazine[2] for a full explanation).

Fuel for the fire was provided by the surprise experienced by many posters who solely followed @fedora-devel for their information. A perception that changes made for the purposes of improving the desktop experience were occurring at the expense of the traditional server experience also seemed to irritate many. This was despite the fact that, as Dan Nicholson explained[3]: "Users who do not want a graphical boot set rc 3 as their default runlevel, and everything is the same as it always was with getty on tty1-6. If you then run startx, it will start on tty7. In rc 5, X is started on tty1 and getty is not. That's all there is to it."

In answer to a question from Till Maas it was confirmed[4] by Felix Miata that if one "[...] rebooted into runlevel 3, logged in on tty1, did telinit 5, got kdm on vt7, switched to tty1, [then there was] a normal shell prompt following typical X startup messages, and kdm still on vt7 [.]"

Dan Nicholson also corrected[5] assumptions that the changes were made to improve boot speed with the information that it was to prevent the ugly flicker of VT switching during boot and asked "Why is it significant what tty any program runs on? Isn't the assumption that getty will be on tty1 just as faulty as the assumption X will be on tty7?" Shmuel Siegel gave[6] an answer which was repeated many times in the threads: "Because you are changing a user interface. What is going to happen when the user switches to tty1 and nothing happens? The basic logic of putting X on tty7 is to get it out of the way. Humans will use the lowest numbered ttys first. Besides breaking existing documentation, including advice on various forums, is not a good idea." Bill Nottingham added[7] to Dan's rationale: "1) Reducing the amount of flicker and useless mode switching on startup is definitely a good thing 2) From a logical standpoint, the first tty should be for the most important user interaction. If you're booting in text mode, that's a getty. If you're booting with a GUI login... that's the GUI." Callum Lerwick and Brian Wheeler exchanged[8] details of the "vast improvement[s]" including removal of up to twelve seconds which resulted from the lack of monitor resync delays.

Gerd Hoffman made[9] an interesting suggestion about how Plymouth could do a VT switch immediately after KMS[10] had entered graphics mode but before printing anything to screen. In the course of this he clarified that "The flicker / resync delay comes from the *mode switch*, not the *vt switch*. And, no, a vt switch does *not* imply a mode switch. The reason you'll have flicker today when switching from/to X11 is that X11 does a mode switch when you switch from/to the terminal X11 is running on." BillNottingham was skeptical but Gerd insisted [11] that his approach would work.

After Till Maas suggested "[...] the kernel should be patched to start booting graphically using tty7 and not tty1." Bill Nottingham passed[12] on the idea as it would involve: "Having the kernel parse its own commandline for a runlevel (a concept that has nothing to do with the kernel, and doesn't even exist under some init systems) and then choosing to rearrange the tty init sequence based on that?" and in further discussion with Matthew Woehlke reiterated[13] "You're having the kernel operate on Fedora specific commandline options to start on a completely different tty, one that could be configured by anyone locally to do something else entirely. (Unless you do it in userspace, which means you jump away and then jump back for text mode, which...)" Casey Dahlin modified[14] the idea to "[...] either offer a getty on tty7 (not too hard) or we could instead add a small API to the kernel that would allow remapping which F key went to which tty, so you could have ctrl+alt+f1 bring up tty7. That way we could remap things so the user got the correct behavior. We wouldn't have to actually /do/ this, but if the API were there, we can tell the people who care to go figure it out."

Will Woods explained[15] how to revert the change, but this was contested[16] by Dan Nicholson on the basis that the latest gdm does not support FirstVT. Dan provided an untested patch and explained that "[s]ince plymouth writes the /var/spool/gdm file on boot and then gdm removes it, any subsequent starts will put X on the first available VT, which is tty7 in the common configuration. With my patch, prefdm writes the file every time it's executed. I don't know if that's the correct behavior for all cases where prefdm would be run. I'm looking at upstream gdm right now, and FirstVT isn't respected. Looking at the rawhide patches, I don't see anything that would enable that functionality again."

Later Dax Kelson reopened[17] the thread with a list of objections which pointed out the negative impact upon documentation and user habit of the change. He garnered a good deal of support from many other respected contributors.

At the end of the thread Bill Nottingham asked[18] the interesting question of why the change appeared to come as such a surprise given that it had been telegraphed in advance by a formal feature proposal[19] and had been implemented in rawhide: "Are people not running rawhide and the test releases? Are they not looking at features as they are proposed and being involved in the process? Are they just sitting around waiting to be outraged?" Dax rejoined[20] that it was not obvious from the documentation that there would be a side-effect which disturbed an expected convention.

Fedora 11: POSIX File Capabilities

Panu Matilainen announced[1] that he had added file capability support to rpm. With kernel support for storing capabilities on filesystem since 2.6.24 and the most recent libcap he asked if now was the time to "[...] start considering moving away from SUID bits to capabilities, in Fedora 11 maybe?"

SethVidal wondered how this would affect networked file systems and David Quigley answered[2] that "[...] capabilities are stored in xattrs they will run into the same problems that SELinux does. Labeled NFS is working to address this by providing a per file attribute through NFSv4 for extra security information."

Another show-stopper was the erasure of file-based capabilities by prelink. It appeared[3] that there was a certain amount of desire to examine whether prelink might cause more trouble than it was worth on faster hardware. Prelink's problems also included incorrectly stripping OCaml binaries and preventing rpm -V from working correctly.

Colin Walters noted[4] that the desktop team had "been moving the OS away from exec-based domain transitions to message passing (e.g. PolicyKit) for a variety of reasons. I think it might be worth considering introducing a rule actually in Fedora for "no new SUID/fcap binaries"[.]" Steve Grubb was worried[5] that this direction resulted in the introduction of another MAC system and that auditing from userspace was untrustworthy. Concern was also raised[6] by Michael Stone on the affects on solid-state memory consumption.

Steve Grubb sought details on how rpm would work with kernels lacking file capabilities and wanted[7] to "start removing some of the setuid bits." He suggested[8] to Chris Adams that tar and star should be capable of storing these new extended attributes and that aide would be useful in tracking changes to them.

Purging Unnecessary .la Files

An apparent contravention of the packaging guidelines was noticed[1] by Debarshi Ray in the dia package. It contained %{_libdir}/%{name}/*.la files[2]. Colin Walters was[3][4] enthusiastic about the idea of "not encourag[ing] the libtool agenda to redefine how shared libraries work on our platform." Jerry James found[5] that he had quite a number of them on his x86_64 machine.

Dan Nicholson argued[6] that it would be best to convince libtool upstream to support some way to choose whether or not the library archives were installed at build time, but Colin was unrelenting and argued[7]: "Or alternatively convince the automake people that it shouldn't be in the business of software lifecycle management (make uninstall) any more than people should be coding/overriding build systems (make;make install) inside RPM spec files. This seems possible; probably worth trying to at least have an environment variable AUTOMAKE.OPTIONS = i-dont-need-uninstall."

David Woodhouse also wanted[8] to see the back of libtool "[...]you can just throw it away and forget it ever existed? I just write proper Makefiles, and if I ever _want_ to spend a couple of minutes watch some bizarre script trying to work out what type of FORTRAN compiler I have on my system, I can write myself a little bash script for that too[...]" but Richard W. M. Jones disagreed[9] sharply as he found it useful for building shared libraries on a wide variety of platforms. In response to Colin Walters' suggestion to build a hook in RPM to nuke .la files he stated[10] that they were essential for the MinGW packages.

Toshio Kuratomi and Michael Schwendt discussed[11] how newer versions of libltld can work without missing libtool archives and that it was desirable to remove them because a "[...] private copy of a system library would be a violation of the Packaging Guidelines for security reasons [.]"

Artwork

Wallpaper Extras

Ian Weller asked[1] on #fedora-art about a better way to handle and package the collection of extra wallpapers gathered from various Fedora contributors: "The current gallery system for the Wallpaper Extras isn't working. It doesn't do us good for keeping track of attributions, especially if we start taking lots of outside contributions from Flickr or the like (which I plan on doing soon)[.]" Ian also proposed that: "[t]he entire wallpaper extras framework for submission and tracking will be on the wiki, through MediaWiki's category system. The main category will be Category:Wallpaper extras[2], which will contain only other categories and unsorted wallpapers. Subcategories to that will be along the lines of Category:Abstract wallpaper extras, which can also contain other subcategories if we want to categorize further. Categories have a built-in gallery setup. The image page itself will contain a template (which we'll need to write) that will contain information such as the creator, the URL it was taken from (if applicable), and who added it to the wiki, and what license was originally under."

Jóhann B. Guðmundsson opted[3] for a contest, possibly held in cooperation with Fedora Magazine[4] "I personally think we should hold a wallpaper contest photo artwork etc with a specific subject/theme in conduction with fedoramagazine each month or so then top 3 picture ( or top in each category ) would be picked added to the wiki and package". Nicu Buculei argued for RSS feeds instead of votes "My tendency is to decouple packaging and contests. Have the images in a proper gallery and the users can use RSS feeds and see 'best rated', 'most viewed', 'last uploaded' images with no effort. And they really need the packaging? They have the photos open in their browser and Firefox has an 'Set As Desktop Background' command (it appears broken if Firefox/GNOME, but that is just a bug which needs a patch). And from this large pile of images, a packager may make a manual selection with the 'most usable' images (or more packagers can to their own selections and packages)."

Jonathan Roberts, the editor of 'Fedora Magazine', got into the discussion and opined[6] against a reinvention of the wheel: "Why reinvent the wheel - why not just take advantage of Gnome look? Or set up a Flickr pool - I think one already exists possibly?" and for a manual image selection for the magazine "With respect to the magazine, I'd be more than happy if someone from the art team would be interested in doing a monthly post that would share work that members of the art team were involved with - whether it was Fedora related or just created using tools exclusively in Fedora"

Fedora 4 F's buttons

Following last week's "Four F's" posters made by Máirín Duffy (see our coverage in FWN#149[0]) Clint Savage posted[1] on @fedora-art a set of buttons made in the same style, which were received[2] with open arms "SWEET! I really like the pattern in the background of the logo2 file. Logo3 is really strong, well done!"

From there the discussion went[2] into printing preparation details. Clint was asked "Do you know how to scribus-ify these into print-ready, color-safe PDF artwork?" This was no problem for Clint: "I have done that before many times. I'll look into doing that on sunday. I assume you are referring to the fact that I need to make the images CMYK and making them pdfs so printers won't complain. I'm capable of doing that :)" Scribus's limitations were raised[4]: "However Scribus SVG support is rather flaky and most of the time (except for really simple 'kosher' SVG files) you will get an error stating that some features of the file were not supported. Also it tends to get the size 'wrong', not the actual size of the drawing, but rather it kind of adds an additional 'holding box' to the drawing. My personal recommendation when handling graphics with Scribus would be to export to EPS and then import that into Scribus, or export to bitmap[.]"

The need to use a recent version of the application was also expressed[5]: "You're probably using mrdocs' svn build for Fedora then right? (My head would have gone thru the monitor glass long ago if I was stuck with 1.3.4) If not, you should give it a try, it makes life so much easier!"

Final Fixes for the Solar Backgrounds

Charlie Brej spotted[1] an imperfection in the default Fedora 10 wallpaper "In the 3200x1200 dual screen images there is a column at X=1151 which has a slight transparency. It is in fact very difficult to see it in gimp but it does become visible on desktop backgrounds with a contrasting solid colour behind" and also proposed[2] a patch to decrease the overall size of the backgrounds package "Current solar background's consume 33Mb. This a bit on the heavy side, especially on the Live CD which is over its image limit. Currently there are 4 different images (morning, noon, evening, night) sent out in 4 different sizes (4:3, 16:10, 5:4 and 8:3 for dual screen). What we could do is to send out just one 3200:1200 image and patch up gnome-desktop background handling to support cropping to the right aspect."

Martin Sourada announced[3] a split of the backgrounds in 3 packages, to distribute the file size optimally "I've just built an updated Solar Backgrounds Package with many fixes provided by Mo, and more resolutions/ratios [1]. As per request from both gnome and kde folks the package has been split into solar-backgrounds (for Desktop Live Spin) solar-backgrounds-common (for KDE) and solar-backgrounds-extras (containing everything not included in the previous two)" and at the last minute Kevin Kofler noticed[4] and fixed[5] a bug "the 1280x1024 image is only 1280x1014".

Fedora 10 Countdown

Following an earlier request[1] from the website team's Ricky Zhou for a count down graphic for the Fedora 10 release, Paolo Leoni submitted[2] to fedora-art for review a couple of proposals and after a couple of rounds of feedback forwarded the proposals to the @fedora-websites, with an additional round of improvements[3] incorporating feedback[4] from Máirín Duffy "I think 'CAMBRIDGE' is a little hard to read because of a combination of the thin font and the low contrast with the background. I also think the text doesn't have enough breathing space from the right and bottom edges of the
banner."

An OLPC Illustration

Karlie Robinson, from the OLPC team, used[1] the Design Services queue[2] to request an OLPC illustration: "I need an image or series of images illustrating how to insert a SD card into the OLPC XO. This will be used for instructions on how to load F10 onto the XO" The request was taken[3] by Mike Langlie "I can render the process of positioning the XO and inserting an SD card in several steps as technical illustrations. Dan Williams demonstrated for me and it looks like a drawing may also be needed for removing the SD card."

A Bit of Flame War

With the huge flame war about X and ttys going strong on the main development list, @fedora-art couldn't remain behind, and pursued its own dispute, started with the topic quality of the quality of its works (we reported about it in our previous issue) and continued with the relation between the Red Hat Desktop Team and the Fedora Art Team.

Max Spevack stepped in[1], outlined the Fedora objectives, one of the points in debate: "1) The premiere community development platform in the OSS world. 2) An open R&D lab for new technologies that Red Hat is interested in from a RHEL server point of view (witness virtualization's path through Fedora over the years) 3) An open R&D lab for new ideas and technologies that Red Hat's desktop team is interested in", raised a set the question to clarify the team's relations and concluded "I submit to you all that this isn't a problem that the Fedora Marketing team can solve. This Artwork v Desktop squabble is a problem about the fundamental way in which Fedora prioritizes the needs of its different constituencies. Red Hat has asked that Fedora be many things, as I said earlier. One of the things Red Hat asks is that Fedora be the best community development platform in the OSS world, and we strive for that every day. However, Red Hat has also asked that Fedora be the incubator for the Red Hat Desktop Team. If those two requests are so incompatible with each other that only one of those goals can be achieved, that is a RED HAT problem and not a FEDORA problem, and we should take that conversation to our managers internally."

The position was reinforced[2] by Paul Frields "For what it's worth, I've talked about this with the Desktop team's leader in Red Hat, Jonathan Blandford, on a couple occasions since I came on board. There are indeed multiple masters to serve, and it's vital that Fedora also preserve the ability for the people who work on technologies like virtualization or SELinux to use Fedora for R&D" who proposed the use of the next FUDCON to discuss and clarify the situation "As am I -- there's a good opportunity to do this at FUDCon in January, but certainly I don't want to just let things stew until then. That happens to be a perfect time to communicate this vision to a sizable portion of the community that will be gathered for that event."