January 2017 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 916587] New: zypper does not update package when used with -C
by bugzilla_noreply＠novell.com 06 Feb '19

06 Feb '19

http://bugzilla.opensuse.org/show_bug.cgi?id=916587 Bug ID: 916587 Summary: zypper does not update package when used with -C Classification: openSUSE Product: openSUSE Factory Version: 201502* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)forge.provo.novell.com Reporter: tchatzimichos(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When I try to `zypper in -C pkg`, zypper only checks if the package is installed. I would expect it to update it as well, like when specifying the original name of it. zypper outputs below, let me know if you need further info from me please. # zypper lu ... v | home:tampakrap | dummy | 0.0.1-2.1 | 0.0.1-3.1 | noarch # zypper -v in -C dummy Verbosity: 1 Non-option program arguments: 'dummy' Initializing Target ... Loading repository data... Reading installed packages... Force resolution: No 'dummy' is already installed. Resolving package dependencies... Force resolution: No Nothing to do. # zypper -v in dummy Verbosity: 1 Non-option program arguments: 'dummy' Initializing Target ... Loading repository data... Reading installed packages... Force resolution: No Selecting 'dummy-0.0.1-3.1.noarch' from repository 'home:tampakrap' for installation. Resolving package dependencies... Force resolution: No The following package is going to be upgraded: dummy 0.0.1-2.1 -> 0.0.1-3.1 1 package to upgrade. Overall download size: 5.7 KiB. Already cached: 0 B No additional space will be used or freed after the operation. Continue? [y/n/? shows all options] (y): -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 987900] New: selecting Wayland with Plasma 5 (plasma5-session-wayland) from sddm produces black screen and then returns to login screen
by bugzilla_noreply＠novell.com 05 Feb '19

05 Feb '19

http://bugzilla.opensuse.org/show_bug.cgi?id=987900 Bug ID: 987900 Summary: selecting Wayland with Plasma 5 (plasma5-session-wayland) from sddm produces black screen and then returns to login screen Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: rainer.klier(a)gmx.at QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 683225 --> http://bugzilla.opensuse.org/attachment.cgi?id=683225&action=edit journald log with unsuccessfull wayland session i am using openSUSE x86_64 Tumbleweed on a notebook with a geforce gtx 765m with the latest proprietary nvidia driver 367.27. Xorg is working fine without problems. today i updated to latest kde framework 5.7.0, and had the idea of trying out wayland, as i read that kde framework 5.7.0 should at least support wayland in some way. but it does not work at all. if i select the Wayland plasma session from the wayland sessions from sddm (the one which comes from the config file /usr/share/wayland-sessions/plasmawayland.desktop which comes from the package plasma5-session-wayland) and trying to login, i only see a black screen for some seconds, and then i am back at the sddm greetings screen. i have attached the part of journald logs where the unsuccessfull login happens: at 17:18:04 you can see the attempt to start new session using /usr/share/wayland-sessions/plasmawayland.desktop. at about 17:18:11 you can see that it was not successfull and then i selected the normal Xorg based session /usr/share/xsessions/kde-plasma.desktop and loged in successfully. what did i wrong? why does it not even start the session? -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 738050] New: server:database/mongodb: Failure on db.dropDatabase() using the RPM version
by bugzilla_noreply＠novell.com 04 Feb '19

04 Feb '19

https://bugzilla.novell.com/show_bug.cgi?id=738050 https://bugzilla.novell.com/show_bug.cgi?id=738050#c0 Summary: server:database/mongodb: Failure on db.dropDatabase() using the RPM version Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: x86-64 OS/Version: SLES 11 Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software AssignedTo: asn(a)cryptomilk.org ReportedBy: patrick.meinusch(a)seitenbau.net QAContact: opensuse-communityscreening(a)forge.provo.novell.com Found By: --- Blocker: --- to reproduce: 1. install mongodb-2.0.1-5.2.x86_64.rpm from http://download.opensuse.org/repositories/server:/database/SLE_11_SP1/x86_6… 2. start mongod: /etc/init.d/mongodb start 3. open a mongo shell to localhost:27017 4. use new database: use testdb (optional) 5. insert document to a collection: db.coll.insert( { "key":"value" } ) 6. try to drop database: db.dropDatabase() expected: database is dropped without any error got: database is dropped but getting this error: in shell: { "errmsg" : "exception: assertion db/pdfile.cpp:2158", "code" : 0, "ok" : 0 } in log: Wed Dec 21 13:31:23 [conn1] dropDatabase newdb Wed Dec 21 13:31:23 [conn1] removeJournalFiles Wed Dec 21 13:31:23 [conn1] Assertion failure i <= DiskLoc::MaxFiles db/pdfile.cpp 2158 0x56ec5e 0x577d4f 0x811b9a 0x8121d8 0x8a0fdc 0x89d661 0x89df85 0x88df2a 0x89071b 0x7f54fa 0x973c3c 0x60c06a 0x7f1841eb45f0 0x7f184065684d /usr/sbin/mongod(_ZN5mongo12sayDbContextEPKc+0x9e) [0x56ec5e] /usr/sbin/mongod(_ZN5mongo8assertedEPKcS1_j+0xbf) [0x577d4f] /usr/sbin/mongod(_ZN5mongo19_applyOpToDataFilesEPKcRNS_6FileOpEbRKSs+0x45a) [0x811b9a] /usr/sbin/mongod(_ZN5mongo16_deleteDataFilesEPKc+0xc8) [0x8121d8] /usr/sbin/mongod(_ZN5mongo15CmdDropDatabase3runERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0xec) [0x8a0fdc] /usr/sbin/mongod(_ZN5mongo11execCommandEPNS_7CommandERNS_6ClientEiPKcRNS_7BSONObjERNS_14BSONObjBuilderEb+0x871) [0x89d661] /usr/sbin/mongod(_ZN5mongo12_runCommandsEPKcRNS_7BSONObjERNS_11_BufBuilderINS_16TrivialAllocatorEEERNS_14BSONObjBuilderEbi+0x565) [0x89df85] /usr/sbin/mongod(_ZN5mongo11runCommandsEPKcRNS_7BSONObjERNS_5CurOpERNS_11_BufBuilderINS_16TrivialAllocatorEEERNS_14BSONObjBuilderEbi+0x3a) [0x88df2a] /usr/sbin/mongod(_ZN5mongo8runQueryERNS_7MessageERNS_12QueryMessageERNS_5CurOpES1_+0x12eb) [0x89071b] /usr/sbin/mongod(_ZN5mongo16assembleResponseERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE+0x6fa) [0x7f54fa] /usr/sbin/mongod(_ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0xdc) [0x973c3c] /usr/sbin/mongod(_ZN5mongo3pms9threadRunEPNS_13MessagingPortE+0x29a) [0x60c06a] /lib64/libpthread.so.0(+0x75f0) [0x7f1841eb45f0] /lib64/libc.so.6(clone+0x6d) [0x7f184065684d] Wed Dec 21 13:31:23 [conn1] command newdb.$cmd command: { dropDatabase: 1.0 } ntoreturn:1 reslen:99 113ms When using the binary package from mongodb.org this bug is not reproducible -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 8

[Bug 731320] New: server:database/mongodb: mongod does not respect --noprealloc
by bugzilla_noreply＠novell.com 04 Feb '19

04 Feb '19

https://bugzilla.novell.com/show_bug.cgi?id=731320 https://bugzilla.novell.com/show_bug.cgi?id=731320#c0 Summary: server:database/mongodb: mongod does not respect --noprealloc Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software AssignedTo: asn(a)cryptomilk.org ReportedBy: jmatejek(a)suse.com QAContact: opensuse-communityscreening(a)forge.provo.novell.com Found By: --- Blocker: --- to reproduce: 1. install mongodb 2. edit /etc/mongodb.conf to say "noprealloc = true" 3. optionally, run mongod manually with --noprealloc option expected result: mongo starts without preallocating journals actual result: mongo does not care. from mongodb.log: note: noprealloc may hurt performance in many applications Fri Nov 18 12:24:02 [initandlisten] MongoDB starting : pid=4902 port=27017 dbpath=/var/lib/mongodb 64-bit host=limetka.suse.cz Fri Nov 18 12:24:02 [initandlisten] db version v2.0.1, pdfile version 4.5 Fri Nov 18 12:24:02 [initandlisten] git version: nogitversion Fri Nov 18 12:24:02 [initandlisten] build info: Linux build05 2.6.37.6-0.7-xen #1 SMP 2011-07-21 02:17:24 +0200 x86_64 BOOST_LIB_VERSION=1_44 Fri Nov 18 12:24:02 [initandlisten] options: { auth: "true", bind_ip: "127.0.0.1", config: "/etc/mongodb.conf", dbpath: "/var/lib/mongodb", fork: "true", logappend: "true", logpath: "/var/log/mongodb/mongodb.log", nohttpinterface: "true", noprealloc: true, quiet: true } Fri Nov 18 12:24:02 [initandlisten] journal dir=/var/lib/mongodb/journal Fri Nov 18 12:24:02 [initandlisten] recover : no journal files present, no recovery needed Fri Nov 18 12:24:05 [initandlisten] preallocateIsFaster=true 25.86 Fri Nov 18 12:24:07 [initandlisten] preallocateIsFaster=true 25.88 Fri Nov 18 12:24:10 [initandlisten] preallocateIsFaster=true 24.26 Fri Nov 18 12:24:10 [initandlisten] preallocateIsFaster check took 8.42 secs Fri Nov 18 12:24:10 [initandlisten] preallocating a journal file /var/lib/mongodb/journal/prealloc.0 well yes, preallocate might as well be "IsFaster=true", but that still doesn't justify spending extra three minutes at startup and eating 3GB for no good reason whatsoever in a friggin development environment where performance does not matter but 3GB of storage do </frustratedRant> -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 1

[Bug 928328] New: VUL-1: libnettle: off-by-one in the test suite
by bugzilla_noreply＠novell.com 03 Feb '19

03 Feb '19

http://bugzilla.suse.com/show_bug.cgi?id=928328 Bug ID: 928328 Summary: VUL-1: libnettle: off-by-one in the test suite Classification: openSUSE Product: openSUSE Factory Version: 201503* Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: vpereira(a)novell.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Address Sanitizer found a problem in the des-compat-test.c the line: for (i=0; i<(NUM_TESTS-1); i++) should be: for (i=0; i<(NUM_TESTS-2); i++) we found a simila problem, in the 13.2, however in Factory it was already fixed. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1015478] New: printing an a4 pdf from okular comes out scaled down to apprx a5
by bugzilla_noreply＠novell.com 30 Jan '19

30 Jan '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1015478 Bug ID: 1015478 Summary: printing an a4 pdf from okular comes out scaled down to apprx a5 Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Printing Assignee: jsmeix(a)suse.com Reporter: per(a)computer.org QA Contact: jsmeix(a)suse.com Found By: --- Blocker: --- Printing an A4 size PDF from okular comes out scaled down to what looks like A5, but with about 2cm truncated on the right. Printing to this printer via our local printserver works fine from other systems - Windows, openSUSE 10/12/13 and Leap421. The Leap422 installation is vanilla, not much changed. Printer is a Kyocera C5015N. -- You are receiving this mail because: You are on the CC list for the bug.

1 24

[Bug 663358] New: [zypper] can not install src rpm available on the local disk
by bugzilla_noreply＠novell.com 29 Jan '19

29 Jan '19

https://bugzilla.novell.com/show_bug.cgi?id=663358 https://bugzilla.novell.com/show_bug.cgi?id=663358#c0 Summary: [zypper] can not install src rpm available on the local disk Classification: openSUSE Product: openSUSE 11.4 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers(a)forge.provo.novell.com ReportedBy: ma(a)novell.com QAContact: qa(a)suse.de Found By: --- Blocker: --- While zypper in /tmp/my.rpm works by creating a temp. repo containing my.rpm, zypper si /tmp/my.src.rpm does not work. Probably possible to use the same trick here as for ordinary rpms. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 2

[Bug 1002456] New: lxcc refuses to start without an icon
by bugzilla_noreply＠novell.com 28 Jan '19

28 Jan '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1002456 Bug ID: 1002456 Summary: lxcc refuses to start without an icon Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: LXDE Assignee: andrea(a)opensuse.org Reporter: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- $ lxcc Traceback (most recent call last): File "/usr/bin/lxcc", line 157, in <module> app = Simple() File "/usr/bin/lxcc", line 141, in __init__ pixbuf=it.load_icon('gtk-stop',48,gtk.ICON_LOOKUP_FORCE_SVG) glib.GError: Icon 'gtk-stop' not present in theme changing the icon theme is a workaround but the error is printed only in the terminal -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 990374] New: linuxrc: comparision of buildid vs initrd id makes TW installers only valid for 24 hours
by bugzilla_noreply＠novell.com 27 Jan '19

27 Jan '19

http://bugzilla.opensuse.org/show_bug.cgi?id=990374 Bug ID: 990374 Summary: linuxrc: comparision of buildid vs initrd id makes TW installers only valid for 24 hours Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- There was apparently a nice bug well hidden in linuxrc, that was recently fixed: https://github.com/openSUSE/linuxrc/commit/b51ff997fee906777d4cde23ddbc0d3a… It has the very negative side effect on Tumbleweed though that any downloaded NET installer is now only valid until the FTP tree is updated to a new snapshot: something that makes Tumleweed Net installers very impracticable, as the same disk can't be used for very long. This was first observed and caught by openQA: https://openqa.opensuse.org/tests/227377#step/welcome/7: this test uses the LATEST TW snapshot NET installer (to be tested, not yet published) and installs the 'previous' (currently published TW snapshot). This entire check feels like we need something more suitable for Tumbleweed, ensuring to not make the NET installer incompatible every day with what is published -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 966870] New: LVM+LUKS encrypted root partition created by Tumbleweed (and Leap) has on 10 GB space
by bugzilla_noreply＠novell.com 24 Jan '19

24 Jan '19

http://bugzilla.suse.com/show_bug.cgi?id=966870 Bug ID: 966870 Summary: LVM+LUKS encrypted root partition created by Tumbleweed (and Leap) has on 10 GB space Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: x86-64 OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: peter.simons(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Last week I installed two machines with Tumbleweed and Leap 42.1, respectively, and in both cases I chose an LVM/LUKS-encrypted installation using ext4 and no separate /home partition. The installation process worked fine. However, in both cases the installer created an install plan that reserved only 10 GB of space for the system's (encrypted) root partition -- leaving some ~450 GB of available disk space unused. That choice seems odd to me. I realize that it's a good idea to have some free space available on an LVM-managed disk so that people can create additional partitions, performs snapshots, etc. From that point of view, I think it's fine that the root partition didn't take up *all* the remaining disk space despite the fact that I chose the "use the entire disk" option. However, allocating only 10 GB for the root disk seems way too conservative, and I reckon that many users will not be happy with that default (like myself). My suggestion would be to implement behavior in the installer that works the other way round: rather than allocating a default partition that's minimal and trust that people will enlarge it when required, I'd rather see the installer create a root partition that's maximal and trust that people will shrink it if they want additional volumes in the /system group. In any case, 10GB for the root disk seems like an odd choice that's not going to work out for virtually anyone. -- You are receiving this mail because: You are on the CC list for the bug.

1 12