December 2010 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Yesterdays X86-64 load
by Donn Washburn 01 Dec '10

01 Dec '10

Hey Group; Question about a openSuSE 11.4 M3 x86-64 DVD system load leaving a 11.0 system behind (which worked). 1. How and where is the current location of a file similar to xorg.conf. This machine has a NVidia GeForce 7300 GS which is not guessed or driven correctly. The brightness is way down and looks yellow (not white). -- 73 de Donn Washburn 307 Savoy Street Email:" n5xwb(a)comcast.net " Sugar Land, TX 77478 LL# 1.281.242.3256 Ham Callsign N5XWB HAMs : " n5xwb(a)arrl.net " VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg BMW MOA #: 4146 - Ambassador " http://counter.li.org " #279316 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

1 0

[opensuse-factory] systemd integration
by Kay Sievers 01 Dec '10

01 Dec '10

Hey, here is a list of things that still need to be done, or need to be discussed how to be done. Note: there is a wiki page about this: http://en.opensuse.org/openSUSE:Systemd_status And for any non-SUSE-specific bugs or requests, please use the upstream mailing list and bug tracker, not this list or the SUSE bugtracker. - systemd service files - a bunch of services need native systemd service files to replace the SYSV init script - some just need to be enabled in the build with: --with-systemdsystemunitdir=/lib/systemd/system - some needs to be packaged and taken from the Fedora packages - some needs to written - systemd/SYSV service management - the init scripts should call systemd if systemd is used, e.g. /etc/init.d/cups start" should either print a warning or call "systemctl start cups.service" directly - Fedora's systemd calls 'chkconfig' for SYSV scripts, so all services can be managed with 'systemctl'. - the YaST2 runlevel editor needs to be modified for systemd, the API of the runlevel editor is used by other YaST modules to enable/disable/query services - RPM package upgrade and systemd service files - systemd services should be enabled only the first time a systemd service files is shipped, depending on the current state of the sysv service. - systemd services are currently only enabled when the package is installed the first time, not with an update. - some SUSE packages ship systemd files, but don't enable the systemd service - replace SUSE-specific config files to new cross-distro configs: /etc/os-release (like /etc/SuSE-release) /etc/locale (replaces /etc/sysconfig/language) /etc/tmpfiles.d/ (replaces /etc/tmpdirs.d/) /etc/vconsole.conf (replaces /etc/sysconfig/keyboard,console) /etc/modules-load.d/ (replaces /etc/sysconfig/kernel::MODULES_LOADED ...) - some of the old SUSE-specific config files are read by systemd, but we should start using the new "Linux default" - splash integration - systemd supports only plymouth at the moment, possibly just switch to plymouth? - move X to tty1 - to avoid VT switch on bootup - to match systemd's getty1 logic - future systemd will support on-demand getty (getty2-6 are only started on VT switch) - getty1/X will be special, depending which "runlevel" is used - sort out the /etc/init.d/xdm config mess (how to convert that beast to a _proper_ systemd service?) - sort out the mess in /etc/init.d/syslog - probably just provide native service file for rsyslog, and disable the this weird script - systemd wants a syslog with socket activation, upstream rsyslog supports this already - sort out NetworkManager vs. sysconfig mess - starting NetworkManager from a the sysconfig init script, depending on a config variable is just weird - on Fedora NM can always be started and just leaves interfaces alone, that are configured in the "old scripts", all unconfigured interfaces are managed by NM. That way, NM can always run, without interfering with static config, or it just be entirely disabled with its own initscript/systemd service. - YaST2 2nd stage/first boot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

12 24

[opensuse-factory] Policykit dependency
by Guido Berhoerster 01 Dec '10

01 Dec '10

Hello, gnome-packagekit misses a dependecy on a Policykit authentication agent. Rather than adding a dependency on polkit-gnome, would it make sense for all three Policykit authentication agent implementations (polkit-gnome, polkit-kde-1, lxpolkit) to provide something like polkit-agent which dependent packages could require instead? -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

3 9

[opensuse-factory] improve installation experience by opportunistically getting a countrycode
by Per Jessen 01 Dec '10

01 Dec '10

Carlos E. R. wrote: > On Wednesday, 2010-12-01 at 08:06 +0100, Per Jessen wrote: > >> Agree. Still, how many (apart from dial-up users perhaps) would have >> to set up the network manually? If we take a single PC, connected to >> the internet, somewhere there will likely be a DHCP service, either >> in the router or direct from the provider. > > Wifi. And network card setup. For example, my computer has two cards, > one disconnected. Automatic discovery would take a longish time. Exceptions, exceptions. :-) > I think that the idea of displaying a map upfront is nice. > Geodiscovery too, but it is not so simple. Perhaps if the network can > be tried in the background, and if found guess the location, but else, > nothing. My thinking is to do something along these lines: a) as early as possible and in the background, attempt network setup of the first nic with dhcp. b) if it works, get a countrycode (and zoom in map as we do today), make semi-educated guesses about language and keyboard. We should not wait for a countrycode to become available, if it isn't ready by the time we're ready to display the map, we forget it. -- Per Jessen, Zürich (-2.1°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

1 0