March 2008

[opensuse-factory] Re: [yast-devel] Getting Rid of 2nd Stage Installation
by Johannes Meixner 11 Mar '08

11 Mar '08

Hello, On Mar 10 13:52 Jiri Srain wrote (shortened): > Dne Monday 10 of March 2008 13:31:35 Stefan Hundhammer napsal(a): > > > > Setting up a printer comes to mind ... > > Printer can be detected and configured automatically without user's > interaction Since openSUSE 10.3 we have the new RPM "cups-autoconfig" which contains a utility for auto-configuring USB printers which is triggered by udev/HAL device events. On the one hand this tool is limited to USB printers, … [View More]on the other hand it works independent of YaST e.g. even after the installation: E.g. when the USB printer was disconnected or switched off during installation, cups-autoconfig could automatiocally configure it once it is connected or switched on at any time later. Note that this tool neither comes from the CUPS authors nor is the RPM a sub-package of the cups RPM. >From CUPS's point of view it is a "third-party" tool. Since cups-autoconfig exists, there is actually no longer any need to let the YaST printer module do the autoconfiguration. Since cups-autoconfig the YaST printer setup module can focus on manual printer setup (i.e. all those cases where cups-autoconfig cannot/doesn't work). By the way: Have a look at http://en.opensuse.org/YaST/Development/Printer_Enhancement in particular regarding "cups-autoconfig" see http://en.opensuse.org/Image:Printer_mschmidkunz_rc2_overview_autoconfig.png By default cups-autoconfig disables/enables print queues when udev/HAL events appear that a USB printer is disconnected/connected. Its /etc/cups-autoconfig.conf contains by default: -------------------------------------------------------------- [CUPS] ConfigureNewPrinters=yes DisablePrintersOnRemoval=yes DefaultCUPSPolicy=relaxed Debug=yes -------------------------------------------------------------- It is triggered via /usr/share/hal/fdi/policy/10osvendor/10-cups-autoconfig.fdi which runs /usr/lib/cups-autoconfig/cups-autoconfig which does the actual stuff, see /usr/lib/cups-autoconfig/cups-autoconfig --help (you must run even '--help' as root, otherwise you get errors) Debugging output is in /var/log/cups-autoconfig.log For some background information, see http://code.google.com/p/cups-autoconfig/ Regarding automated scanner configuration, see https://bugzilla.novell.com/show_bug.cgi?id=347943 If automated printer or scanner configuration doesn't work and the user has problems to find the YaST printer or scanner module for a manual setup, it is a usability problem of the YaST control centre which is also already worked on as far as I know. Summary: I appreciate "Getting Rid of 2nd Stage Installation" very much. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org [View Less]

3 3

[opensuse-factory] Call for test: open-vm-tools in OBS
by Dominique Leuenberger 10 Mar '08

10 Mar '08

Hello! Recently, somebody (Sunny) requested some RPMs offering the open-vm-tools in our nice distribution [0]. I opted to create some packages and have a look into this. So here I am, just a few days later with a working (as for me, my house did not burn down) example of those packages. They can be found at http://download.opensuse.org/repositories/home:/dimstar and are currently built for: openSUSE 10.3 stock openSUSE 10.3 updated openSUSE Factory (for fActory, i586 fails to compile because … [View More]

4 7

[opensuse-factory] Re: [yast-devel] Getting Rid of 2nd Stage Installation
by Jiri Srain 10 Mar '08

10 Mar '08

Hi! Dne Monday 10 of March 2008 12:07:35 Stefan Hundhammer napsal(a): > There are two sides to this. > > On one hand, getting rid of that second stage of installation makes the > installation appear (!) shorter. And yes, of course we should set up > automatically everything we can, but I have strong doubts if it's a good > idea to not let the user change those settings - this is what the proposals > are all about (figure out a good automatic setting, but let the user … [View More]

1 0

[opensuse-factory] glibc update on opensuse 10.2
by reinhard schwab 10 Mar '08

10 Mar '08

is it possible that i update glibc on opensuse 10.2 to the glibc factory packages? regards reinhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

6 8

[opensuse-factory] Dist meeting minutes 2008-03-06
by Stephan Kulow 10 Mar '08

10 Mar '08

Present: maw, anicka, nadvornik, kukuk, meissner, rguenther, holgi, matz, milli, coolo, jpr - Branding policy - No objections to put it into place - branding installation not yet done, wip - AI: Stanislav will look into splitting and submitting bug reports for packages to be changed (tbd) - need more documentation how to package branding (may be product specific) - perl splitting - mls not part of the meeting unfortunately - perl should be split because it's pretty big … [View More]

1 0

[opensuse-factory] Is it true that after an update we don't need to reboot?
by Carlos E. R. 10 Mar '08

10 Mar '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, After the last YOU update of dbus things, a run of this code: lsof | grep -E 'RPMDELETE|;|path inode=' detects a long list of applications and libraries that are still running the old non updated library; a sample: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME console-k 2962 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) hald 3027 haldaemon mem REG 22,70 … [View More]1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) hald-runn 3028 root mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) hald-addo 3074 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) avahi-dae 4559 avahi mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) powersave 4837 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) login 5313 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gdm 5551 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gnome-ses 21496 kar mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gnome-scr 21562 kar mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gnome-pan 21573 kar mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) nautilus 21582 kar mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) beagled 21585 kar mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) resapplet 21591 kar mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gnome-cup 21592 kar mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) nm-applet 21602 kar mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) gnome-vfs 21604 kar mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) gnome-pow 21610 kar mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gnome-vol 21611 kar mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) main-menu 21638 kar mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) tomboy 21640 kar mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) mixer_app 21642 kar mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gnome-ses 29456 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) nautilus 29531 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gnome-vfs 29537 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) resapplet 29556 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gnome-scr 29557 cer mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) gnome-cup 29568 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) opensuse- 29595 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) apparmora 29620 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) nm-applet 29623 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) seahorse- 29648 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gweather- 29707 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) mini_comm 29709 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) deskbar-a 29713 cer mem REG 22,70 1381793 /usr/lib/python2.5/site-packages/_dbus_bindings.so (path inode=1577045) stickynot 29715 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) evolution 29930 cer mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) This is known, is not new: but I believe YOU should warn users of this situation and advise to restart services/programs and list them (yes, there is a Bugzilla, ignored) Obviously, a lot of those are reloaded after login out of the X11 sessions. But not all: gdm remains, needing an "init 3; init 5". Then, there are still some pending: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME console-k 2962 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) console-k 2962 root mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) hald 3027 haldaemon mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) hald 3027 haldaemon mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) hald-runn 3028 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) hald-runn 3028 root mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) hald-addo 3074 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) hald-addo 3074 root mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) hald-addo 3088 haldaemon mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) hald-addo 3435 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) hald-addo 3435 root mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) avahi-dae 4559 avahi mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) powersave 4837 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) powersave 4837 root mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) login 5313 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) login 5315 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gnome-vfs 29537 cer mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) gnome-vfs 29537 cer mem REG 22,70 1560834 /usr/lib/libdbus-glib-1.so.2.1.0 (path inode=1560833) Notice that gnome-vfs did not die after closing login out, nor after killing X11. That's another bug, reported, I think. I know that after login out of gnome I have to manually kill some apps like this: cer@nimrodel:~> beagle-shutdown ; killall beagled gnome-vfs-daemon gnome-vfs-daemon dbus-daemon dbus-daemon gpg-agent ; sleep 5; killall -9 beagled (yes, beagle normally refuses to die...) Some services have to be restarted: nimrodel:~ # rcpowersaved restart Shutting down powersaved done Starting powersaved: done nimrodel:~ # rchal restart Shutting down HAL daemon done Starting HAL daemon done Loading CPUFreq modules (CPUFreq not supported) nimrodel:~ # rcconsolekit restart Shutting down ConsoleKit done Starting ConsoleKit done nimrodel:~ # nimrodel:~ # rcavahi-daemon restart Shutting down Avahi daemon done Starting Avahi daemon done Still one more remaining: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME login 5313 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) login 5315 root mem REG 22,70 1349371 /lib/libdbus-1.so.3.2.0 (path inode=1007980) which clears after I log out of all text sessions. So... in the end, a reboot was not required, but after running YOU and doing a security update, the machine is still at risk because the update is not really applied till many services and applications are restarted. Or recomend a "init 1 ; init 5". But being silent about this problem may leave many at risk, because the hole plugged by the security update is very open if the unsuspecting user does nothing. IMO, of course :-) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH0Z9vtTMYHG2NR9URAsGvAJ4iBPB1nID+2jkQbzw2fLeWcE2g7gCcCqJ3 U4JCtpn1XvGEktw1+pnheqo= =4dRe -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org [View Less]

5 6

[opensuse-factory] GIMP dependencies
by Rajko M. 08 Mar '08

08 Mar '08

Factory updated from Alpha2 to current today. I guess this would be Alpha2+. Running in VirtualBoox. YaST Software Management gives the same as: zypper in gimp one of dependencies "bundle-lang-gnome-ar". The system language is en_US. According to YaST: The "bundle-lang-gnome-en" is already installed The "bundle-lang-gnome" is not. Acording to zypper nothing is installed. -- Regards, Rajko. See http://en.opensuse.org/Portal ----------------------------------------------------------… [View More]

2 2

[opensuse-factory] Problems updating from factory
by Chema 08 Mar '08

08 Mar '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi: Is download.opensuse.org down? I try connect to upgrade my system but I can't. Regards - -- Chema Ollés Usuario Linux: #198057 openSUSE 11.0 (i586) Alpha2 kernel-2.6.24.1-6-default #1 SMP 2008/02/22 15:49:32 UTC i686 GNU/Linux -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (GNU/Linux) iEYEARECAAYFAkfSUswACgkQm5lTdgS9W1/zFgCfepqmKh7QLO1mYKn1leLAXpBI iv4AnjepbhDsdpso2MsSaVQThsoZrXd6 =069j -----END PGP SIGNATURE----- ------------------------… [View More]

2 1

[opensuse-factory] Just one question about plane to release openSUSE 11.0 with KDE 4.1
by Rastislav Krupanský 07 Mar '08

07 Mar '08

KDE 4.1 will be released over one month after openSUSE 11.0 So haven´t you thought yet to release it with KDE 4.1?It would be just one month later. Thanks Regards, Rasto ------------------- MAPY.SK - Najpresnejsie vyhladavanie aj podla cisiel domu, planovanie trasy. http://mapy.atlas.sk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

3 2

[opensuse-factory] kded4 endless loop
by Volker Kuhlmann 07 Mar '08

07 Mar '08

I am seeing kded4 going into an endless loop with >90% CPU use frequently. Is this more common? strace'ing the process shows naught, so it's stuck in a loop without a system call in it. Is there a suggested way to get more info for a bug report, other than install ..-debuginfo and try and attach gdb (once half the system is updated ;)? Thanks, Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. ---------------… [View More]

1 0

Main

Development

Information

Community

Social Media

Other

openSUSE Factory