devel August 2010

devel@lists.stg.fedoraproject.org

293 participants
312 discussions

systemd acceptance, packaging guidelines (was Re: systemd and changes)
by Bill Nottingham 05 Sep '10

05 Sep '10

(intentionally breaking thread) Toshio Kuratomi (a.badger(a)gmail.com) said: > Maybe I should start a new thread since this isn't really a bug, but it is > a blocker -- we need to get some packaging guidelines out for systemd. > I think that the last message on the subject was this one: > > http://lists.fedoraproject.org/pipermail/devel/2010-July/139483.html > > Could I get a reply as to whether that looks right? - At the moment, /bin/systemctl is in systemd-units. (I think this is a bug. Filed.) - As long as we're still shipping upstart, the sysv scripts would still need included, and would still need to be set up with chkconfig the same way. > As noted in the post, I'm not sure if the outlined procedure correctly > implements level 1. I believe it does. > We should probably also have the scriptlets for implementing level 3 for the > things basic to the system that require that. My reading of your mail is different - the case we want to handle is case #2 (installation of something that starts by default - dbus, NM, etc.) As I understand it, they would be the same, with the addition of: %post if [ 0$1 -eq ]; then /bin/systemctl enable <foo.service> fi with foo.service having the appropriate [Install] stanza that says where it should start up. As with SysV scripts, we generally do not start services by default, so this is rare. Case #3 that you mentioned is something I don't think we have in Fedora - we never start services on package installation. This, however, is just packaging guidelines. From readng the thread, there are many things that I think people would like covered with systemd before they would feel comfortable with it. So, I'm going to attempt to quantify what would need to be tested and verified. This document focuses on backwards compatibility. THIS IS GOING TO BE VERY VERBOSE. Comments, changes, etc. welcome. BOOTUP - System boots successfully to GUI, when configured. - System boots successfully to text mode, when configured. - System properly handles being passed [1-5], 'single', 'S', 's', '-s', booting to the appropriate 'runlevel' (0 and 6 can still work, but they're sort of pointless anyway) When booted in this manner, '5' will bring up a GUI, and '3' will not. SINGLE USER MODE - Exiting single user mode properly returns to the default state. - single-user mode output is correctly displayed on the console. PLYMOUTH - plymouth is shown on startup. - plymouth is quit correctly. - plymouth is shown on shutdown. - 'esc' to show details still functions in plymouth. - an equivalent to /var/log/boot.log still exists, and is populated (can be normal syslog) - plymouth transition from grub -> boot -> X is seamless for KMS cards, similar to Fedora 13. RUNTIME TOOLS - telinit [0123456] does the proper thing. - the 'runlevel' command displays correct output if we are in a target that is aliased to a runlevel. - 'halt' shuts down, but does not poweroff. -- 'halt' supports -p, to power off. - 'poweroff' shuts down, and powers off. - 'reboot' shuts down and reboots. - 'halt', 'poweroff', 'reboot' all support '-f', to force the action. - 'halt', 'poweroff', 'reboot' all properly log to utmp, wtmp, and the audit layer. - 'shutdown' shall support the following arguments in a compatible manner: 'r', 'h', 'H', 'P', 'c', 'k', <time>. - 'telinit' does not error when passed '[Qq]' (to reload its configuration) and '[Uu]' to re-exec itself. It can optionally make systemd do a similar action, if valid. - init shall support a mechanism to re-exec itself to not cause dirty inodes on shutdown; initscripts will use this method on shutdown. - the kbdrequest job currently in systemd will be disabled for final release. - 'ctrl-alt-delete' will reboot the system. PREFDM - prefdm starts a configured display manager correctly. - prefdm starts a installed display manager correctly without additional configuration. CONSOLEKIT - ConsoleKit properly logs system start, stop, and restart. - The ConsoleKit shutdown/reboot/halt methods work as expected. SERIAL CONSOLES - Booting with a primary serial console (via console=) automatically sets up a getty on the console, and sets up securetty to allow for root login. - (optional) Booting with secondary serial consoles does the same. NON-SERIAL CONSOLES - By default, 6 gettys will be started in text mode, on tty1-6. 5 gettys will be started in GUI mode, on tty2-6. - getty and X will not be started on the same tty. - (optional) The number of ttys started can be configurable. ERROR HANDLING - SELinux automatic relabelling will still function. - fsck will still function. - Dropping to an emergency shell in the case where either of these fails shall still function. SELINUX - No AVCs from the init system in normal use. - No AVCs when executing any of the cases specified here - systemd shall still function if booted with selinux=0. PACKAGING - Guidelines for packaging systemd units shall be formalized. - The behavior when both systemd units and SysV services are present on the system shall be defined. This includes defined behavior when a service appears to be 'enabled' for SysV links while 'disabled' for systemd (and vice-versa). - The syntax of systemd units shall be frozen for the release (all future releases? Some set number of releases?) SERVICE HANDLING - Running 'chkconfig <foo> <(null)|on|off>' on a service managed by systemd will return the correct code/perform an appropriate action. - Running 'service <foo> <start|stop|...>' on a service managed by systemd will perform the appropriate action (via systemctl), and return similar errors. - Running '/etc/init.d/<foo> <start|stop|...>' will not break the systemd environment, while still performing the action specified, and shall return similar errors. GENERAL SANITY - Booting a system shall achieve a similar result as booting in upstart: -- The same set of services will be started. -- The services shall function the same. -- The same set of devices and filesystems shall be mounted. -- The same set of devices and filesystems shall be fscked. ORDERING - rc.local will run as the final service on bootup. - gettys will not start until after rc.local. - prefdm will start coincident to gettys (earlier?) ADMIN INTERFACE - The files and paths used by systemd shall be frozen for future releases. - The basic syntax of systemd commands shall be frozen for future releases. - The syntax of systemd units shall be frozen for future releases. ASSORTED RANDOM CONFIGURATIONS - The system shall properly function with: -- encrypted / -- encrypted non-/ -- nfs / -- iSCSI / -- LDAP user information -- IPA/AD user information -- NIS user information -- ext* filesystems -- btrfs filesystems -- xfs filesystems ANY REMAINING UPSTART JOBS - All packaged upstart jobs are modified to have some SysV or systemd-native equivalent. ... that's all I have at the moment. I'm sure I'm missing something. Bill

25 83

systemd and filesystems with noauto
by Matthew Miller 05 Sep '10

05 Sep '10

I have a fstab entry like this: /dev/sde1 /mnt/sdcard autonoexec,noauto,users,ro,sync,shortname=lower 0 0 which I use in a script to take pictures off my camera's SD card and transfer them to my photo management system. I've been doing it this way for a long time, and now with modern Linux I recognize that there's better ways of doing it. But I was surprised when I updated this system to latest rawhide and rebooted, because it came up with that filesystem mounted. Is this expected behavior? -- Matthew Miller <mattdm(a)mattdm.org> Senior Systems Architect -- Instructional & Research Computing Services Harvard School of Engineering & Applied Sciences

73 353

Deactivating LVDS display when laptop lid is closed
by Orion Poplawski 04 Sep '10

04 Sep '10

Apparently[1] it is up to the desktop environment now to deactivate the LVDS display if the laptop lid is closed at boot (or whenever?). I now have several F13 laptops in docks with external monitors that boot with the lid closed, but kdm_greet puts the login panel on the closed LVDS display (see bug[2]). I've also filed a Fedora bug for similar stuff here [3]. I don't know how gdm behaves. Any other comments/help? I tried doing: # Disable LVDS if another output is up if xrandr --current | grep -qE '^(DVI|VGA).* connected' then lvds=$(xrandr --current | awk '$1 ~ /LVDS/ { print $1 }') xrandr --output $lvds --off fi in /etc/kde/kdm/Xsetup, but kdm_greet appears to get stuck in an infinite loop and I only see the small round black spinner cursor, never the login panel. I thought about posting to the Fedora KDE list, but I'd like to get some wider input. 1 - https://bugs.freedesktop.org/show_bug.cgi?id=28936 2 - https://bugs.kde.org/show_bug.cgi?id=243807 3 - https://bugzilla.redhat.com/show_bug.cgi?id=539180 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

3 2

fedpkg prep
by Steve Dickson 03 Sep '10

03 Sep '10

Just curious.... Why does 'fedpkg prep' care that the repo is in an inconsistent state? I just did a rebase to the latest f14 code on a private branch. So yes he repo in an inconsistent but that is ok. I'm going to make some changes to put it back in a consistent state but I can not do that without a source tree. So is there a way to do what the old 'make prep' did? That is stupidity untar the tarball an apply all the current patch without checking any state?? tia, steved.

8 23

Starting Java SIG
by Stanislav Ochotnicky 03 Sep '10

03 Sep '10

Hi everyone, There has been an effort few years back to start Java SIG but it didn't work out in the end (no idea why). I decided it's time to try again :-) I would like to start Java SIG for a lot of reasons. Some of them: * Packaging guidelines are in need of an update (badly) * Consistency in java packages is somewhat lacking * More eyes see more approach, I'd like for all java related commits to go through an alias so we can all watch out for changes that can break our stuff * Have a place where we can collect tips & tricks, solutions to common problems etc. Currently this information is scattered through people's wiki pages * Java needs collaboration more than most other areas, because problems cannot be safely discovered automatically when someone changes dependency. This can cause serious headaches (to me at least). Java SIG to the rescue! :-) * Other languages have their own SIGs and we don't! :-) Who am I? Owner/Co-maintainer of a bunch of Java packages (mostly maven plugins, apache-commons, junit, velocity, checkstyle, plexus libraries). Involved in recent update of maven to v2.2.1. Reply if you're interested with helping out and being able to see/influence where Java packaging in Fedora is going. I know there will be at least a few people joining in. I'll be starting Java SIG wiki page soon, plus I guess we can peruse java-devel mailing list for SIG discussions. -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com

12 21

yum appmarket
by Seth Vidal 01 Sep '10

01 Sep '10

I mentioned this on: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ last night but I thought I'd bring it up here: Yesterday someone was talking about installing apps in fedora and how it was hard to figure out what to install/try b/c there were too much STUFF in fedora. They suggested an ‘app store’ like functionality. I explained that all the resources to do something like that exist in the infrastructure yum and friends offer now. I decided to prove that concept a bit. The concept of an ‘app’ is pretty amorphous but I decided to just use what Colin Walters said was his definition of an ‘app’ – which is any pkg containing a .desktop file. So I just whipped up a simple tool to dump out an xml-file of a format yum is already familiar with based on that criteria: http://skvidal.fedorapeople.org/misc/appfinder.py Running that generates an xml file with only the ‘apps’ defined. Great. Then I wrote a yum plugin to access and use this data. and I stuck it in this repo 1. copy this file into /etc/yum.repos.d/ 2. run: yum install yum-plugin-appmarket Now yum will have a few new commands available to it: app-install Install an App app-list List Apps app-remove Remove an App app-search Search for an App Some examples: yum app-search yum won’t turn up ‘yum’ but it will turn up ‘yumex’. Fancy, huh? Now, the concept of an app can be refined in many ways but this is just to prove that the infrastructure has been available. -sv

15 27

Fedora Notifications System.
by Mahmoud Abdul Jawad 01 Sep '10

01 Sep '10

Hi all,, before two weeks, a discussion started in ambassadors mailing-list about a work around to deliver the important notifications to the fedora desktop (whatever the desktop is). after some discussion, we started with some guide lines & putted them on the wiki: https://fedoraproject.org/wiki/Fedora_notifications_system Continuing, I created an early prototype i want people to check & gives feedbacks about it. you can reach it through gitweb: http://fedorapeople.org/gitweb?p=megenius/public_git/fns.git;a=summary or, you can grab your own clone from the git repo: git://fedorapeople.org/megenius/fns.git keep in mind that last_check file should be writeable by the world, & you should change its value to an earlier date, so you can see some notifications. -- Regards,, Mahmoud Abdul Jawad @meGenius

29 60

clutter -> 1.3
by Colin Walters 01 Sep '10

01 Sep '10

Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 (master) branch. I've tested GNOME Shell and quadrapassel, feel free to CC me for other fallout.

6 10

Nautilus misbehaving
by Paul F. Johnson 31 Aug '10

31 Aug '10

Hi, After the recent rawhide to nautilus 2.90.1-1.fc15.i686, it's stopped working claiming that I don't have Settings schema 'org.gnome.desktop.lockdown' installed. What is this and how do I fix the problem? TTFN Paul

3 2

Re: [kernel/f14/master] add in patch from lmacken to support more mac models with efifb
by Luke Macken 31 Aug '10

31 Aug '10

Thanks for taking care of this, Kyle. Should I send this patch upstream? if so, 1 patch per hardware? do/should I get sign-off's? Thanks, luke On 08/31/2010 05:23 PM, Kyle McMartin wrote: > commit 3c5d4de07ca16d799f1ca63454b56a03456191fe > Author: Kyle McMartin<kyle(a)dreadnought.i.jkkm.org> > Date: Tue Aug 31 17:23:33 2010 -0400 > > add in patch from lmacken to support more mac models with efifb > > efifb-add-more-models.patch | 59 +++++++++++++++++++++++++++++++++++++++++++ > kernel.spec | 10 ++++++- > 2 files changed, 68 insertions(+), 1 deletions(-) > --- > diff --git a/efifb-add-more-models.patch b/efifb-add-more-models.patch > new file mode 100644 > index 0000000..3351970 > --- /dev/null > +++ b/efifb-add-more-models.patch > @@ -0,0 +1,59 @@ > +--- vanilla-2.6.35.3.orig/drivers/video/efifb.c > ++++ vanilla-2.6.35.3/drivers/video/efifb.c > +@@ -39,7 +39,11 @@ enum { > + M_I20, /* 20-Inch iMac */ > + M_I20_SR, /* 20-Inch iMac (Santa Rosa) */ > + M_I24, /* 24-Inch iMac */ > ++ M_I24_8_1, /* 24-Inch iMac, 8,1th gen */ > ++ M_I24_10_1, /* 24-Inch iMac, 10,1th gen */ > + M_MINI, /* Mac Mini */ > ++ M_MINI_3_1, /* Mac Mini, 3,1th gen */ > ++ M_MINI_4_1, /* Mac Mini, 4,1th gen */ > + M_MB, /* MacBook */ > + M_MB_2, /* MacBook, 2nd rev. */ > + M_MB_3, /* MacBook, 3rd rev. */ > +@@ -47,6 +51,7 @@ enum { > + M_MBA, /* MacBook Air */ > + M_MBP, /* MacBook Pro */ > + M_MBP_2, /* MacBook Pro 2nd gen */ > ++ M_MBP_2_2, /* MacBook Pro 2,2nd gen */ > + M_MBP_SR, /* MacBook Pro (Santa Rosa) */ > + M_MBP_4, /* MacBook Pro, 4th gen */ > + M_MBP_5_1, /* MacBook Pro, 5,1th gen */ > +@@ -64,11 +69,16 @@ static struct efifb_dmi_info { > + [M_I20] = { "i20", 0x80010000, 1728 * 4, 1680, 1050 }, /* guess */ > + [M_I20_SR] = { "imac7", 0x40010000, 1728 * 4, 1680, 1050 }, > + [M_I24] = { "i24", 0x80010000, 2048 * 4, 1920, 1200 }, /* guess */ > ++ [M_I24_8_1] = { "imac8", 0xc0060000, 2048 * 4, 1920, 1200 }, > ++ [M_I24_10_1] = { "imac10", 0xc0010000, 2048 * 4, 1920, 1080 }, > + [M_MINI]= { "mini", 0x80000000, 2048 * 4, 1024, 768 }, > ++ [M_MINI_3_1]= { "mini31", 0x40010000, 1024 * 4, 1024, 768 }, > ++ [M_MINI_4_1]= { "mini41", 0xc0010000, 2048 * 4, 1920, 1200 }, > + [M_MB] = { "macbook", 0x80000000, 2048 * 4, 1280, 800 }, > + [M_MBA] = { "mba", 0x80000000, 2048 * 4, 1280, 800 }, > + [M_MBP] = { "mbp", 0x80010000, 1472 * 4, 1440, 900 }, > + [M_MBP_2] = { "mbp2", 0, 0, 0, 0 }, /* placeholder */ > ++ [M_MBP_2_2] = { "mbp22", 0x80010000, 1472 * 4, 1440, 900 }, > + [M_MBP_SR] = { "mbp3", 0x80030000, 2048 * 4, 1440, 900 }, > + [M_MBP_4] = { "mbp4", 0xc0060000, 2048 * 4, 1920, 1200 }, > + [M_MBP_5_1] = { "mbp51", 0xc0010000, 2048 * 4, 1440, 900 }, > +@@ -92,7 +102,11 @@ static struct dmi_system_id __initdata d > + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "iMac6,1", M_I24), > + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac6,1", M_I24), > + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac7,1", M_I20_SR), > ++ EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac8,1", M_I24_8_1), > ++ EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac10,1", M_I24_10_1), > + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "Macmini1,1", M_MINI), > ++ EFIFB_DMI_SYSTEM_ID("Apple Inc.", "Macmini3,1", M_MINI_3_1), > ++ EFIFB_DMI_SYSTEM_ID("Apple Inc.", "Macmini4,1", M_MINI_4_1), > + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBook1,1", M_MB), > + /* At least one of these two will be right; maybe both? */ > + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBook2,1", M_MB), > +@@ -104,6 +118,7 @@ static struct dmi_system_id __initdata d > + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookAir1,1", M_MBA), > + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro1,1", M_MBP), > + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro2,1", M_MBP_2), > ++ EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro2,2", M_MBP_2_2), > + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookPro2,1", M_MBP_2), > + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro3,1", M_MBP_SR), > + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookPro3,1", M_MBP_SR), > diff --git a/kernel.spec b/kernel.spec > index d5c3638..77630ec 100644 > --- a/kernel.spec > +++ b/kernel.spec > @@ -48,7 +48,7 @@ Summary: The Linux kernel > # reset this by hand to 1 (or to 0 and then use rpmdev-bumpspec). > # scripts/rebase.sh should be made to do that for you, actually. > # > -%global baserelease 13 > +%global baserelease 14 > %global fedora_build %{baserelease} > > # base_sublevel is the kernel version we're starting with and patching > @@ -663,6 +663,8 @@ Patch1824: drm-intel-next.patch > Patch1825: drm-intel-make-lvds-work.patch > Patch1900: linux-2.6-intel-iommu-igfx.patch > > +Patch2000: efifb-add-more-models.patch > + > # linux1394 git patches > Patch2200: linux-2.6-firewire-git-update.patch > Patch2201: linux-2.6-firewire-git-pending.patch > @@ -1262,6 +1264,8 @@ ApplyOptionalPatch drm-intel-next.patch > ApplyPatch drm-intel-make-lvds-work.patch > ApplyPatch linux-2.6-intel-iommu-igfx.patch > > +ApplyPatch efifb-add-more-models.patch > + > # linux1394 git patches > #ApplyPatch linux-2.6-firewire-git-update.patch > #ApplyOptionalPatch linux-2.6-firewire-git-pending.patch > @@ -1892,6 +1896,10 @@ fi > # and build. > > %changelog > +* Tue Aug 31 2010 Kyle McMartin<kyle(a)redhat.com> 2.6.35.4-14 > +- efifb-add-more-models.patch: Add patch from Luke Macken to > + support more Mac models (rhbz#528232) > + > * Tue Aug 31 2010 Dave Jones<davej(a)redhat.com> 2.6.35.4-13 > - Fix incorrect DMA size freeing error in via-velocity. >

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2010