March 2008 - openSUSE Factory - openSUSE Mailing Lists

[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, 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

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 of inconsistency within BS... for the moment, the kernel-source matching the kernel-syms can not be found). There are two things to be installed in your VM: vmware-kmp-<kernelflavour> and open-vm-tools The KMP contains 5 kernel modules: vmblock vmhgfs mvmemctl vmsync vmxnet open-vm-tools installs the service vmware-guest (get's automatically activated) and the toolbox. In my tests, the mouse was after installation freely going in and out the VM (normally one of the easiest indices that the VM tools work), I could mount a shared host (mount.vmhgfs .host:/test /mnt) and access it and the clipboard was shared between host and guest... so now I have to ask you fellows to help me improve it, to make it undergo a lot of testing so we can convince coolo that he wants to include this package in the upcoming alphas and betas and finals of openSUSE (ups... we still don't have the procedures in place for community maintained packages). so for now that's it from my side... any sort of comment is highly appreciated. Have a good time, Dominique [0] http://lists.opensuse.org/opensuse-factory/2008-03/msg00068.html --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

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 change > it if he wishes). > > On the other hand, most of the things that can be configured in that second > stage make sense to be configured at that point. What that second stage > does is remind the user of all that stuff that makes sense to be > configured. I don't remember when I last configured anything during 2nd stage (well, I'm probably not typical user, anyway). I always just run through the workflow, clicking only the Next button. I've seen several reports of unexperienced users, who were confused by some of the dialogs. Configuring everything automatically helps here. Most of the users can run with the defaults, the others can configure missing parts after the installation. > That's a whole lot simpler than going through the control center (which is > increasingly cluttered with entries of minor importance). > > So if we remove that second stage, we might make some journalists happy who > write reviews about the installation process and some very few power users > who know by heart what's left to configure. > > But what about the rest of all users, which I estimate to be ~90%? > Do we really make life easier for them if we leave much of the system > unconfigured? Will they be happy about not being able to print when they > need to just because it never occured to them to configure a printer? Not "unconfigured", but "configured to default values" which should work for most of them. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz

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 for base - mls wants "perl" to be what upstream releases as sources, including _everything_ - so the idea is to split perl into several smaller packages and leave "perl" to require all of these - for base system, we would not need "perl", but the modules/subpackage we require - question is: how to solve the dependency problem - rpm finds perl requires and perl provides already, but rpm requires is often too much - e.g. optional module - evaluated build service project with all perl packages and automatic rpm requires, stripped out explicit perl requires and looked at fallouts - there were many problems, but not unfixables - e.g. by black- or whitelist of perl requires to be ignored / taken into account - Anicka is rather afraid of any change - we could enlarge perl-base, split perl into perl-docs and perl-modules and let perl-<FOO> require perl-modules and no longer perl - review basesystem requires if they can rather require perl-base instead of perl-modules - AI: rguether - dig out spec files for splitting docs (not found, done) - AI: coolo - present this to mls (done) - AI: coolo,matz - backport the patches to Factory even if disabled (tbd) -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- 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] 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 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

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 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

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----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

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. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

1 0