FWN/Beats/Developments

Developments

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

Contributing Writer: Oisin Feeley

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.

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

Apparently similar failures were reported[2] by Jonathon Roberts for a Dell Mini[3] ,Tim Lauridsen on a ThinkPad T60[4] and Christoph Hoger[5] on a ThinkPad R61. Tim's problem seemed to be related to compiz.

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

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

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

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

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)."

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

[7] http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html

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

Jesse Barnes (of the Intel Open Source Technology Center[9]) asked whether suspend worked from the console using:

echo mem > /sys/power/state

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:

dbus-send --system --print-reply --dest=org.freedesktop.Hal \
/org/freedesktop/Hal/devices/computer \
org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0

Matthew begged[10] "Please (please, please) don't attempt to add resume quirks for anything with Intel video hardware now. It's only hiding kernel bugs."

[9] http://software.intel.com/sites/oss/

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

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."

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

[2] http://fedoramagazine.wordpress.com/2008/10/21/interview-fedora-10s-better-startup/

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

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 [.]"

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

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 rationle: "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.

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

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

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

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

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.

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

[10] Kernel Mode Setting: http://kerneltrap.org/node/8242

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

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."

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

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

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

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."

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

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

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.

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

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.

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

[19] http://fedoraproject.org/wiki/Features/BetterStartup

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

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.

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

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

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

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

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

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

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

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

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.

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

[2] .la are libtool archive files: http://www.gnu.org/software/libtool/manual/html.node/index.html#Top

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

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

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

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."

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

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

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.

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

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

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

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 [.]"

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

Richard W. M. Jones decided[12] to do some testing to determine whether MinGW needed "[...] the *.la files for MinGW packages" or "[...] the .la files in MinGW packages[.]"

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