October 2014 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Dependency problem with virt-manager 13.2
by Mustafa Muhammad 01 Nov '14

01 Nov '14

Hi, not sure this is the place to post this, please tell me if this doesn't belong here. I am testing 13.2, trying to install virt-manager gave me: localhost:/ # zypper in virt-manager Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides libvte2_90-9 needed by virt-manager-1.0.1-14.3.1. noarch Solution 1: do not install virt-manager-1.0.1-14.3.1.noarch Solution 2: break virt-manager-1.0.1-14.3.1.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): Can somebody fix this, please. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

9 17

[opensuse-factory] Fwd: is dkms package banned from (open)?SUSE?
by Andrei Dziahel 01 Nov '14

01 Nov '14

Hello list, What is the story behind the fact that dkms package seems to be absent[1] in official oS repositories? Thanks. [1]: http://software.opensuse.org/package/dkms -- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] [VMware-Workstation KO] Failed to build vmnet after last openSUSE update
by James PEARSON 01 Nov '14

01 Nov '14

Hello all I just did a mega zypper update of opensuse Factory tonight - I thought that I would avoid the rush :) This was a big mistake as far as VMware-Workstation is concerned because after updating some ~530 packages (new kernal etc) VMware Workstation can no longer compile the vmnet module. ERROR : Failed to build vmnet. Failed to execute the build command. Everthing else works ok. Side note 1 : I have been running Vmware Workstation on Factory fine with zero problems for at least the last 3 weeks. I just updated to the lastest version of VMware Workstation] yesterday (v10.0.4). Everything worked fine for 24 hours unitil I did a "zypper up" tonight (20141031) I am running : VMware-Workstation-Full-10.0.4-2249910.x86_64.bundle Side note 2 : I experienced no problems updaing another 64 bit installation that did not have VMware-Workstation and everything is working OK on a 32 bit installation. # OS details follow Linux Asus 3.17.1-1.g5c4d099-desktop #1 SMP PREEMPT Sat Oct 18 23:36:23 UTC 2014 (5c4d099) x86_64 x86_64 x86_64 GNU/Linux # Listing the versions of installed support packages... kernel-source-3.17.1-1.2.g5c4d099.noarch kernel-desktop-3.17.1-1.2.g5c4d099.x86_64 kernel-desktop-devel-3.17.1-1.2.g5c4d099.x86_64 gcc-4.8-8.1.x86_64 make-4.0-4.4.x86_64 gcc-c++-4.8-8.1.x86_64 cat vmware-modconfig-19171.log ... snip 2014-10-31T20:25:32.487+01:00| modconfig| I120: "/usr/lib/vmware-installer/2.1.0/vmware-installer" exited with status 0. 2014-10-31T20:25:32.487+01:00| modconfig| I120: Setting destination path for vmnet to "/lib/modules/3.17.1-1.g5c4d099-desktop/misc/vmnet.ko". 2014-10-31T20:25:32.487+01:00| modconfig| I120: Extracting the vmnet source from "/usr/lib/vmware/modules/source/vmnet.tar". 2014-10-31T20:25:32.490+01:00| modconfig| I120: Successfully extracted the vmnet source. 2014-10-31T20:25:32.490+01:00| modconfig| I120: Building module with command "/usr/bin/make -j6 -C /tmp/modconfig-Kua8Vn/vmnet-only auto-build HEADER_DIR=/lib/modules/3.17.1-1.g5c4d099-desktop/build/include CC=/usr/bin/gcc IS_GCC_3=no" 2014-10-31T20:25:33.649+01:00| modconfig| W110: Failed to build vmnet. Failed to execute the build command. 2014-10-31T20:25:33.654+01:00| modconfig| I120: We are now shutdown. Ready to die! I have also posted this issue on the VMware communties thread url: https://communities.vmware.com/community/vmtn/workstation/content?filterID=… Regards James -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] Raspberry Version
by gm1mqe＠aol.com 31 Oct '14

31 Oct '14

Will there be a version available for the Raspberry when the factory release goes Golden? Thanks, Andy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] After upgrade from 13.1 boot process is stuck at 'Loading initial ramdisk...'
by Robert Munteanu 31 Oct '14

31 Oct '14

Hi, I just upgraded from 13.1 to 13.2 using zypper dup. I am running a W520 with encrypted LVM. Bootloader is grub2. Booting now gets stuck with the message in $SUBJECT. The root/path to initrd are correct, I've verified them with the grub2 console. The linux line correctly contains pci=noacpi, which is required to boot with this laptop. Keyboard input is still available, as I can press 'Caps Lock' and the corresponding LED lights up or down, but nothing is echoed on the console. How can I debug/fix the boot process? Thanks, Robert -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 9

[opensuse-factory] .changes file merging
by Adrian Schröter 30 Oct '14

30 Oct '14

Just wanted to do something useful again this morning :) build.opensuse.org has now a new special merge tool installed, which will be used to merge suse style changelog files (<package>.changes). This is supposed to solve the typical breakage when you branch from some package and upstream and you are applying modifications. While most modifications can just get merged, the .changes file always lead to a broken package. This was because the diff3 tool, which we use (as almost every other SCM) does not understand the format of it and just saw conflicting lines. .changes files are now merged by the new bs_mergechanges tool. It is merging by parsing the files and sorting by timestamps. In case it does still fail, eg. upstream and you did change an existing entry in different ways, the standard diff3 tool will be used to display the conflicts. You do not need to update any client tools, osc will get the merged files directly from the source server. In short, most of you will not even notice a difference to before. You will just see less often merge conflicts in your branches. Already existing conflicts from the time before deployment will be detected automatically over the next days. But it takes some time. -- Adrian Schroeter email: adrian(a)suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Tumbleweed: systemd cannot start privoxy
by Patrick Shanahan 30 Oct '14

30 Oct '14

up to date Tumbleweed (13.1) systemctl start privoxy 18:26 Crash: ~ # systemctl start privoxy Job for privoxy.service failed. See 'systemctl status privoxy.service' and 'journalctl -xn' for details. 18:27 Crash: ~ # systemctl status privoxy privoxy.service - Privoxy Web Proxy With Advanced Filtering Capabilities Loaded: loaded (/usr/lib/systemd/system/privoxy.service; disabled) Active: failed (Result: exit-code) since Wed 2013-11-20 18:27:09 EST; 15s ago Process: 9430 ExecStart=/usr/sbin/privoxy --pidfile /run/privoxy.pid --user privoxy /etc/privoxy/config (code=exited, status=1/FAILURE) Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1 Nov 20 18:27:09 Crash systemd[1]: Failed to start Privoxy Web Proxy With Advanced Filtering Capabilities. Nov 20 18:27:09 Crash systemd[1]: Unit privoxy.service entered failed state. 18:27 Crash: ~ # journalctl -xn -- Logs begin at Sat 2013-03-30 18:27:22 EDT, end at Wed 2013-11-20 -- 18:27:35 EST. -- Nov 20 18:27:08 Crash systemd[1]: Starting Privoxy Web Proxy With Advanced Filtering Capabilities... -- Subject: Unit privoxy.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit privoxy.service has begun starting up. Nov 20 18:27:09 Crash systemd[1]: privoxy.service: control process exited, code=exited status=1 Nov 20 18:27:09 Crash systemd[1]: Failed to start Privoxy Web Proxy With Advanced Filtering Capabilities. -- Subject: Unit privoxy.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: -- http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba4… -- -- Unit privoxy.service has failed. -- -- The result is failed. Nov 20 18:27:09 Crash systemd[1]: Unit privoxy.service entered failed state. Nov 20 18:27:15 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=282 TOS=0x00 PREC=0x00 TTL=64 ID=51684 DF PROTO=UDP SPT=631 DPT=631 LEN=262 Nov 20 18:27:15 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=282 TOS=0x00 PREC=0x00 TTL=64 ID=51685 DF PROTO=UDP SPT=631 DPT=631 LEN=262 Nov 20 18:27:34 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=247 TOS=0x00 PREC=0x00 TTL=64 ID=51686 DF PROTO=UDP SPT=631 DPT=631 LEN=227 Nov 20 18:27:34 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=247 TOS=0x00 PREC=0x00 TTL=64 ID=51687 DF PROTO=UDP SPT=631 DPT=631 LEN=227 Nov 20 18:27:35 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=263 TOS=0x00 PREC=0x00 TTL=64 ID=51688 DF PROTO=UDP SPT=631 DPT=631 LEN=243 Nov 20 18:27:35 Crash kernel: SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC= SRC=192.168.1.10 DST=192.168.1.255 LEN=263 TOS=0x00 PREC=0x00 TTL=64 ID=51689 DF PROTO=UDP SPT=631 DPT=631 LEN=243 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

9 20

[opensuse-factory] Is plymouth supposed to be animated in openSUSE 13.2
by Roman Bysh 29 Oct '14

29 Oct '14

Hello all, I just installed plymouth and gfx boot. All I see is a copy of the green wallpaper as part of plymouth for a number of seconds and switches to black. Isn't plymouth supposed to have some animation? -- Cheers! Roman ------------------------------------------------ openSUSE -- Open Minds Open Sources Open Future ------------------------------------------------ http://linuxcounter.net/ #179293 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 5

[opensuse-factory] another serious systemd bug: systemd automounting umounted 'devices'/partitions.
by Linda Walsh 28 Oct '14

28 Oct '14

x-posted to factory, as this is 13.2 behavior... Carlos E. R. wrote: > On 2014-10-24 21:57, Ruediger Meier wrote: > >> So what kind of automount is this? How to disable this odd >> behaviour? Is this a known bug? > > Yes. ---- Um... this sounds like a different bug than the one you mention below. The previous discussion that you quote had auto-remounting happen despite inclusion of "noauto". Now it "only" happens in situations that should ***NEVER*** occur unless someone (or something -- like a kernel) with administrative privileges has manually unmounted. If that's the case --- then something automounting it again is horrible problem -- if there was file corruption causing the unmount, or if suspected file corruption causes an admin to unmount a file system, having a something in the background try to auto-remount such an file system could cause a severe increase of corruption -- not just on that file system, but on the system as a whole -- where it could very easily crash the system. I.e. if a file system that was set for auto-mounting at boot is found to be "unmounted", than any attempt to mount it is "glossing over" the reason why the file system became unmounted in the first place and quite possibly contributing to its corruption or, in worst case, loss of the data on the file system. >>>>>>>>>> /etc/fstab != /etc/auto.xxx... <<<<<<<<<<<<< > > Date: Sat, 24 May 2014 19:07:18 -0400 > From: Michael Fischer <> > To: opensuse(a)opensuse.org > Subject: [opensuse] Why is systemd[1] is mounting noauto partitions? > > You participated in that thread :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] (proposal) Persistent Live USB more trouble than help, fix or remove
by Roger Luedecke 28 Oct '14

28 Oct '14

Many users notice performance problems with the persistent live images, particularly in relation to what is needed for them to be persistent. In my personal experience, I can never use them more than once since they will stop working after the first boot. Many other users report incredibly slow booting and horrible performance lag. Users propose a means to toggle the behavior from GRUB when the Live image is being used. If infeasible, I think we should remove it altogether and instead direct users to roll their own with SUSE Studio. -- Roger Luedecke <roger.luedecke(a)gmail.com> openSUSE Project -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 4