December 2015 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 941862] New: GNOME Software won't open RPM files
by bugzilla_noreply＠novell.com 03 Sep '18

03 Sep '18

http://bugzilla.opensuse.org/show_bug.cgi?id=941862 Bug ID: 941862 Summary: GNOME Software won't open RPM files Classification: openSUSE Product: openSUSE Distribution Version: 42.1 Milestone 1 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: castar(a)cipelli.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0 Build Identifier: When downloading RPMs from the internet, the option is given to open them with GNOME Software (presumably to install them). However, when doing so, Software opens with an error: "GetDetailsLocal not supported by backend". Reproducible: Always Steps to Reproduce: 1. Download an RPM for openSUSE. 2. Open it using GNOME Software. Actual Results: Gave error "GetDetailsLocal not supported by backend" Expected Results: Given details about the package. This happened on my old laptop and my new computer (HP G56 with AMD V140 and custom-built with AMD A10-7700K respectively). -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 909418] New: when ejecting DVD using hardware button, system thinks DVD is still mounted
by bugzilla_noreply＠novell.com 27 Aug '18

27 Aug '18

http://bugzilla.opensuse.org/show_bug.cgi?id=909418 Bug ID: 909418 Summary: when ejecting DVD using hardware button, system thinks DVD is still mounted Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: Ulrich.Windl(a)rz.uni-regensburg.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When I used a mounted DVD (in a BluRay writer) and press eject-button on the drive, the media ejects, and I close the tray. In GNOME (at least) the system still thinks the media is mounted, even if I inserted another DVD into the drive in the meantime. -- You are receiving this mail because: You are on the CC list for the bug.

1 40

[Bug 953723] New: mksquashfs corrupts files
by bugzilla_noreply＠novell.com 08 Aug '18

08 Aug '18

http://bugzilla.opensuse.org/show_bug.cgi?id=953723 Bug ID: 953723 Summary: mksquashfs corrupts files Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: seife(a)novell.slipkontur.de QA Contact: qa-bugs(a)suse.de CC: duwe(a)suse.com, ms(a)suse.com Found By: --- Blocker: --- IMPORTANT: I have seen this both on 13.2 and on a patched SLES12 installation (no wonder, they have the same version of squashfs :-) While working with KIWI (OEM image, deployed either via PXE or as an ISO), I got spurious checksum errors when unpacking the image. A rebuild of the image often fixed the issue. Until yesterday, when there was no possibility to create a working image anymore. I was assuming something changed with my KIWI setup or a bug in kiwi. I investigated the issue and it comes down to the following: vbox-seife:~/oem # cat SLES_12_image1.x86_64-0.3.4.md5 b6a50a9e4a509b40ee192ee977cc5b48 312192 8192 vbox-seife:~/oem # md5sum SLES_12_image1.x86_64-0.3.4.raw b6a50a9e4a509b40ee192ee977cc5b48 SLES_12_image1.x86_64-0.3.4.raw vbox-seife:~/oem # mksquashfs SLES_12_image1.x86_64-0.3.4.raw SLES_12_image1.x86_64-0.3.4.md5 /tmp/SLES_12_image1.x86_64-0.3.4.raw.squashfs -no-progress Parallel mksquashfs: Using 2 processors Creating 4.0 filesystem on /tmp/SLES_12_image1.x86_64-0.3.4.raw.squashfs, block size 131072. Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072 compressed data, compressed metadata, compressed fragments, compressed xattrs duplicates are removed Filesystem size 642142.91 Kbytes (627.09 Mbytes) 25.71% of uncompressed filesystem size (2497612.67 Kbytes) Inode table size 42177 bytes (41.19 Kbytes) 53.94% of uncompressed inode table size (78188 bytes) Directory table size 59 bytes (0.06 Kbytes) 64.13% of uncompressed directory table size (92 bytes) Number of duplicate files found 0 Number of inodes 3 Number of files 2 Number of fragments 2 Number of symbolic links 0 Number of device nodes 0 Number of fifo nodes 0 Number of socket nodes 0 Number of directories 1 Number of ids (unique uids + gids) 1 Number of uids 1 root (0) Number of gids 1 root (0) vbox-seife:~/oem # mount -t squashfs /tmp/SLES_12_image1.x86_64-0.3.4.raw.squashfs /mnt/ vbox-seife:~/oem # md5sum /mnt/SLES_12_image1.x86_64-0.3.4.raw 4f2653aea2424557a4341d1416d21389 /mnt/SLES_12_image1.x86_64-0.3.4.raw So the file got altered when packing up with mksquashfs. vbox-seife:~/oem # cmp -l /mnt/SLES_12_image1.x86_64-0.3.4.raw SLES_12_image1.x86_64-0.3.4.raw |head -1 2557459969 0 110 vbox-seife:~/oem # dd if=SLES_12_image1.x86_64-0.3.4.raw skip=$((2557459969/512))|hexdump -C 33+0 records in 33+0 records out 16896 bytes (17 kB) copied, 0.000102726 s, 164 MB/s 00000000 48 61 68 21 49 64 6f 6e 74 4e 65 65 64 45 46 49 |Hah!IdontNeedEFI| 00000010 f1 d9 c8 c6 e2 3f bd 48 89 b6 17 29 bc 94 dd 67 |.....?.H...)...g| 00000020 00 08 00 00 00 00 00 00 03 18 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 6c 00 65 00 67 00 61 00 |........l.e.g.a.| 00000040 63 00 79 00 00 00 00 00 00 00 00 00 00 00 00 00 |c.y.............| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 28 73 2a c1 1f f8 d2 11 ba 4b 00 a0 c9 3e c9 3b |(s*......K...>.;| 00000090 f6 f0 20 26 9a 16 1e 40 a7 03 f1 5a ea c8 80 90 |.. &...@...Z....| 000000a0 00 20 00 00 00 00 00 00 03 60 06 00 00 00 00 00 |. .......`......| 000000b0 00 00 00 00 00 00 00 00 55 00 45 00 46 00 49 00 |........U.E.F.I.| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000100 a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7 |......3D..h..&..| 00000110 8b 4b b5 64 5c 86 ab 49 87 f5 13 a2 ba 7b 8f 98 |.K.d\..I.....{..| 00000120 00 68 06 00 00 00 00 00 03 c8 0f 00 00 00 00 00 |.h..............| 00000130 00 00 00 00 00 00 00 00 6c 00 78 00 62 00 6f 00 |........l.x.b.o.| 00000140 6f 00 74 00 00 00 00 00 00 00 00 00 00 00 00 00 |o.t.............| 00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000180 a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7 |......3D..h..&..| 00000190 b2 0b ef 75 36 86 a4 4f 8a 7c 42 20 08 af 33 28 |...u6..O.|B ..3(| 000001a0 00 d0 0f 00 00 00 00 00 80 37 4c 00 00 00 00 00 |.........7L.....| 000001b0 00 00 00 00 00 00 00 00 6c 00 78 00 6c 00 76 00 |........l.x.l.v.| 000001c0 6d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |m...............| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00004000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART....\...| 00004010 82 ba 8f 32 00 00 00 00 ff 37 4c 00 00 00 00 00 |...2.....7L.....| 00004020 01 00 00 00 00 00 00 00 22 00 00 00 00 00 00 00 |........".......| 00004030 de 37 4c 00 00 00 00 00 8e 28 e4 1a a7 84 ae 48 |.7L......(.....H| 00004040 b2 d1 ff 8a 8b 14 2c 11 df 37 4c 00 00 00 00 00 |......,..7L.....| 00004050 80 00 00 00 80 00 00 00 3f cd f4 5d 00 00 00 00 |........?..]....| 00004060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00004200 vbox-seife:~/oem # dd if=/mnt/SLES_12_image1.x86_64-0.3.4.raw skip=$((2557459969/512))|hexdump -C 33+0 records in 33+0 records out 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00004200 16896 bytes (17 kB) copied, 0.000606308 s, 27.9 MB/s The last ~16.5kB are just zeroes. I then looked at the upstream git and found this: http://sourceforge.net/p/squashfs/code/ci/de03266983ceb62e5365aac84fcd3b2fd… Note that this bug is present in at least 13.2 and SLES12, and looking at the package I have no reason to believe it is not in Factory/Tumbleweed. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 915996] New: LibreOffice doesn't show internal Help
by bugzilla_noreply＠novell.com 07 Aug '18

07 Aug '18

http://bugzilla.opensuse.org/show_bug.cgi?id=915996 Bug ID: 915996 Summary: LibreOffice doesn't show internal Help Classification: openSUSE Product: openSUSE Factory Version: 201502* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: LibreOffice Assignee: bnc-team-ooo(a)forge.provo.novell.com Reporter: lazy.kent(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- LibreOffice v4.4.0.2 doesn't show internal Help. Using locale "ru_RU". Calling Help from the menu "Help" or "F1" key opens a browser with URL https://help.libreoffice.org/scalc/.uno:HelpIndex?Language=ru&System=UNIX&V… (in case of calc) or https://help.libreoffice.org/swriter/.uno:HelpIndex?Language=ru&System=UNIX… (in case of writer). Installed packages: % rpm -qa | grep libreoffice libreoffice-math-4.4.0.2-1.1.x86_64 libreoffice-draw-4.4.0.2-1.1.x86_64 libreoffice-l10n-en-4.4.0.2-1.1.noarch libreoffice-icon-theme-crystal-4.4.0.2-1.1.noarch libreoffice-calc-extensions-4.4.0.2-1.1.x86_64 libreoffice-calc-4.4.0.2-1.1.x86_64 libreoffice-gnome-4.4.0.2-1.1.x86_64 libreoffice-icon-theme-oxygen-4.4.0.2-1.1.noarch libreoffice-writer-4.4.0.2-1.1.x86_64 libreoffice-branding-openSUSE-4.0-5.1.noarch libreoffice-4.4.0.2-1.1.x86_64 libreoffice-impress-4.4.0.2-1.1.x86_64 libreoffice-mailmerge-4.4.0.2-1.1.x86_64 libreoffice-base-4.4.0.2-1.1.x86_64 libreoffice-pyuno-4.4.0.2-1.1.x86_64 libreoffice-templates-ru-3.3-13.1.noarch libreoffice-icon-theme-galaxy-4.4.0.2-1.1.noarch libreoffice-filters-optional-4.4.0.2-1.1.x86_64 libreoffice-writer-extensions-4.4.0.2-1.1.x86_64 libreoffice-l10n-ru-4.4.0.2-1.1.noarch openSUSE Tumbleweed x86_64. And I remember, it was OK in 4.4.0.1. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 953297] New: grub2-xen.rpm should be noarch
by bugzilla_noreply＠novell.com 06 Aug '18

06 Aug '18

http://bugzilla.suse.com/show_bug.cgi?id=953297 Bug ID: 953297 Summary: grub2-xen.rpm should be noarch Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: ohering(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- grub2 contains pvgrub for Xen PV guests. The subpackage should be noarch because the resulting single binary runs only in guest context. It is firmware. It would be nice of there would be two subpackages: grub2-x86_64-xen.noarch.rpm and grub2-i386-xen.noarch.rpm, this would allow to both 32bit and 64bit PV guests. I think right now the 64bit pvgrub can not boot 32bit PV and via versa. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 800701] New: X windows is corrupt after logging in on an AMD A10-5800K APU
by bugzilla_noreply＠novell.com 31 Jul '18

31 Jul '18

https://bugzilla.novell.com/show_bug.cgi?id=800701 https://bugzilla.novell.com/show_bug.cgi?id=800701#c0 Summary: X windows is corrupt after logging in on an AMD A10-5800K APU Classification: openSUSE Product: openSUSE Factory Version: 12.3 Beta 1 Platform: x86-64 OS/Version: Other Status: NEW Severity: Critical Priority: P5 - None Component: Xen AssignedTo: jdouglas(a)suse.com ReportedBy: ajbiii(a)comcast.net QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Installed 12.3. The regular kernel and X windows works fine. Reboot to the xen kernel. The login screen is displayed correctly. After logging in, the display is corrupt. The mouse pointer is ok and I can see that the menu is active by putting the cursor in the lower left corner and clicking but the display is unusable. Just an aside: The xen kernel wouldn't even boot on the APU with 12.1 or 12.2. Reproducible: Always Steps to Reproduce: 1. Install 12.3 on an AMD Trinity APU. 2. Boot regular kernel, log in and verify X is working. 3. Reboot with the xen kernel. 4. Log in and observe the corruption Actual Results: Screen is corrupt Expected Results: Normal X windows operation -- 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 23

[Bug 902352] New: snapperd crashed shortly after boot
by bugzilla_noreply＠novell.com 29 Jul '18

29 Jul '18

http://bugzilla.opensuse.org/show_bug.cgi?id=902352 Bug ID: 902352 Summary: snapperd crashed shortly after boot Classification: openSUSE Product: openSUSE Factory Version: NO 13.2 BUGS!! Hardware: i686 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: aschnell(a)suse.com Reporter: mpluskal(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After reboot of recent opensuse factory, I have noticed that snapperd crashed (for no apparent reason): # systemd-coredumpctl gdb 3614 TIME PID UID GID SIG EXE Tue 2014-10-21 22:11:37 CEST 3614 0 0 6 /usr/sbin/snapperd GNU gdb (GDB; openSUSE Factory) 7.8 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i586-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.opensuse.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... warning: /etc/gdbinit.d/gdb-heap.py: No such file or directory Reading symbols from /usr/sbin/snapperd...Reading symbols from /usr/lib/debug/usr/sbin/snapperd.debug...done. done. [New LWP 3614] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `/usr/sbin/snapperd'. Program terminated with signal SIGABRT, Aborted. #0 0xb77bae60 in __kernel_vsyscall () (gdb) bt full #0 0xb77bae60 in __kernel_vsyscall () No symbol table info available. #1 0xb73f2437 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 resultvar = <optimized out> resultvar = <optimized out> pid = -1219051520 selftid = 3614 #2 0xb73f3b8e in __GI_abort () at abort.c:78 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x83fd424, sa_sigaction = 0x83fd424}, sa_mask = {__val = {64, 3074638989, 3075918176, 3078479804, 3077059232, 5, 3220034192, 3078403714, 3077059672, 3070747136, 1, 5, 0, 3075915776, 3075918176, 3075922024, 3220034164, 3076988956, 3076153812, 3076093316, 138392728, 3075915776, 3075918176, 3074203892, 3075918176, 3074619692, 3076988928, 3076988928, 3075919228, 138400804, 138399352, 3078429072}}, sa_flags = 138392632, sa_restorer = 0xb73f3a80 <__GI_abort>} sigs = {__val = {32, 0 <repeats 31 times>}} #3 0xb75ddfe5 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95 terminating = true t = <optimized out> #4 0xb75dbc53 in __cxxabiv1::__terminate (handler=0xb75dde50 <__gnu_cxx::__verbose_terminate_handler()>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38 No locals. #5 0xb75dab75 in __cxa_call_terminate (ue_header=0x83fb468) at ../../../../libstdc++-v3/libsupc++/eh_call.cc:54 No locals. #6 0xb75db791 in __cxxabiv1::__gxx_personality_v0 (version=1, actions=6, exception_class=5138137972254386944, ue_header=0x83fb468, context=0xbfedd550) at ../../../../libstdc++-v3/libsupc++/eh_personality.cc:670 action_record = <optimized out> p = <optimized out> thrown_ptr = 0x0 info = {Start = 3078108587, LPStart = 0, ttype_base = 0, TType = 0x0, action_table = 0xfffffffc <error: Cannot access memory at address 0xfffffffc>, ttype_encoding = 0 '\000', call_site_encoding = 192 '\300'} landing_pad = <optimized out> ip = <optimized out> handler_switch_value = 0 foreign_exception = false found_type = <optimized out> language_specific_data = 0xb779200c "\377\233\021\001\005>\005\342\001\003" ip_before_insn = 0 #7 0xb758506c in _Unwind_RaiseException_Phase2 (exc=exc@entry=0x83fb468, context=context@entry=0xbfedd550) at ../../../libgcc/unwind.inc:62 fs = {regs = {reg = {{loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = { reg = 4294967276, offset = -20, exp = 0xffffffec <error: Cannot access memory at address 0xffffffec>}, how = REG_SAVED_OFFSET}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = { reg = 4294967288, offset = -8, exp = 0xfffffff8 <error: Cannot access memory at address 0xfffffff8>}, how = REG_SAVED_OFFSET}, {loc = {reg = 4294967280, offset = -16, exp = 0xfffffff0 <error: Cannot access memory at address 0xfffffff0>}, how = REG_SAVED_OFFSET}, {loc = {reg = 4294967284, offset = -12, exp = 0xfffffff4 <error: Cannot access memory at address 0xfffffff4>}, how = REG_SAVED_OFFSET}, {loc = {reg = 4294967292, offset = -4, exp = 0xfffffffc <error: Cannot access memory at address 0xfffffffc>}, how = REG_SAVED_OFFSET}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = { reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}}, prev = 0x0, cfa_offset = 64, cfa_reg = 4, cfa_exp = 0x0, cfa_how = CFA_REG_OFFSET}, pc = 0xb772a690 <snapper::Snapper::~Snapper()+144>, personality = 0x8053950 <__gxx_personality_v0@plt>, data_align = -4, code_align = 1, retaddr_column = 8, fde_encoding = 27 '\033', lsda_encoding = 27 '\033', saw_z = 1 '\001', signal_frame = 0 '\000', eh_ptr = 0x0} match_handler = 4 code = _URC_NO_REASON #8 0xb75855ad in _Unwind_Resume (exc=exc@entry=0x83fb468) at ../../../libgcc/unwind.inc:230 this_context = {reg = {0xbfedd5d4, 0x0, 0xbfedd5d8, 0xbfedd5dc, 0x0, 0xbfedd5e8, 0xbfedd5e0, 0xbfedd5e4, 0xbfedd5ec, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, cfa = 0xbfedd5f0, ra = 0xb774b85f <snapper::logStreamClose(snapper::LogLevel, char const*, unsigned int, char const*, std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >*)+431>, lsda = 0x0, bases = { tbase = 0x0, dbase = 0xb758c000, func = 0xb7585550 <_Unwind_Resume>}, flags = 1073741824, version = 0, args_size = 0, by_value = '\000' <repeats 17 times>} cur_context = {reg = {0xbfedd5d4, 0x0, 0xbfedd5d8, 0xbfedd62c, 0x0, 0xbfedd638, 0xbfedd630, 0xbfedd634, 0xbfedd63c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, cfa = 0xbfedd640, ra = 0xb772a6dd <snapper::Snapper::~Snapper()+221>, lsda = 0xb779200c, bases = {tbase = 0x0, dbase = 0xb779b000, func = 0xb772a600 <snapper::Snapper::~Snapper()>}, flags = 1073741824, version = 0, args_size = 0, by_value = '\000' <repeats 17 times>} code = <optimized out> #9 0xb774b85f in ~basic_string (this=<optimized out>, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/basic_string.h:539 No locals. #10 snapper::logStreamClose (level=level@entry=snapper::MILESTONE, file=file@entry=0xb777ade3 "Snapper.cc", line=line@entry=112, func=func@entry=0xb777b348 <snapper::Snapper::~Snapper()::__FUNCTION__> "~Snapper", stream=stream@entry=0x83fca40) at Log.cc:64 No locals. #11 0xb772a6dd in snapper::Snapper::~Snapper (this=0xb67007f0, __in_chrg=<optimized out>) at Snapper.cc:112 __buf = 0x83fca40 ---Type <return> to continue, or q <return> to quit--- #12 0x08063118 in MetaSnapper::~MetaSnapper (this=0x83fd498, __in_chrg=<optimized out>) at MetaSnapper.cc:117 No locals. #13 0x08063197 in ~_List_node (this=0x83fd490, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_list.h:106 No locals. #14 destroy<std::_List_node<MetaSnapper> > (this=<optimized out>, __p=0x83fd490) at /usr/include/c++/4.8/ext/new_allocator.h:124 No locals. #15 _M_clear (this=0x80788e8 <meta_snappers>) at /usr/include/c++/4.8/bits/list.tcc:75 __tmp = 0x83fd490 __cur = 0x80788e8 <meta_snappers> #16 ~_List_base (this=0x80788e8 <meta_snappers>, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_list.h:378 No locals. #17 ~list (this=0x80788e8 <meta_snappers>, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_list.h:438 No locals. #18 MetaSnappers::~MetaSnappers (this=0x80788e8 <meta_snappers>, __in_chrg=<optimized out>) at MetaSnapper.cc:196 No locals. #19 0xb73f52f1 in __run_exit_handlers (status=status@entry=0, listp=0xb756c3c4 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82 atfct = <optimized out> onfct = <optimized out> cxafct = <optimized out> f = <optimized out> #20 0xb73f534d in __GI_exit (status=0) at exit.c:104 No locals. #21 0xb73dd99b in __libc_start_main (main=0x8053ca0 <main(int, char**)>, argc=1, argv=0xbfedd7a4, init=0x8069a10 <__libc_csu_init>, fini=0x8069a80 <__libc_csu_fini>, rtld_fini=0xb77cc660 <_dl_fini>, stack_end=0xbfedd79c) at libc-start.c:319 result = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1219051520, 0, 0, 0, -2067208107, 617901124}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x1, 0x805462f <_start>}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1}}} not_first_call = <optimized out> #22 0x08054650 in _start () at ../sysdeps/i386/start.S:115 No locals. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 879402] New: date format of atq is unusable for sorting
by bugzilla_noreply＠novell.com 29 Jul '18

29 Jul '18

https://bugzilla.novell.com/show_bug.cgi?id=879402 https://bugzilla.novell.com/show_bug.cgi?id=879402#c0 Summary: date format of atq is unusable for sorting Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: martin(a)oneiros.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 The atq in 13.1 uses a date/time format that is unsuitable for sorting by date/time and there is no way to set the date format used (e.g. to ISO8601). Reproducible: Always Steps to Reproduce: 1. Set up some jobs with at 2. Run atq Actual Results: > atq 1377 Thu May 29 15:04:00 2014 a ms 1387 Thu May 22 21:59:00 2014 a ms 1376 Thu May 29 18:39:00 2014 a ms 1372 Wed May 28 21:32:00 2014 a ms 1 Fri May 23 21:04:00 2014 a ms 1361 Sun May 25 08:04:00 2014 a ms 1373 Thu May 29 09:29:00 2014 a ms 1367 Tue May 27 20:02:00 2014 a ms 4 Fri May 23 22:03:00 2014 a ms 1369 Wed May 28 21:04:00 2014 a ms 7 Sat May 24 19:04:00 2014 a ms 10 Sat May 24 23:03:00 2014 a ms Expected Results: The date format should be ISO 8601 - or there should be a switch to set the date format used. The atq up to 12.3 used ISO 8601, so this is a regression. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612075 -- 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 13

[Bug 936320] New: update to tumbleweed snapshot 12.06.2015 from a freshly installed 13.2 fails reliably.
by bugzilla_noreply＠novell.com 20 Jul '18

20 Jul '18

http://bugzilla.opensuse.org/show_bug.cgi?id=936320 Bug ID: 936320 Summary: update to tumbleweed snapshot 12.06.2015 from a freshly installed 13.2 fails reliably. Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Critical Priority: P5 - None Component: Upgrade Problems Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: stakanov(a)freenet.de QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 639432 --> http://bugzilla.opensuse.org/attachment.cgi?id=639432&action=edit last yast2log Trying to update a 13.2 fresh install to tumbleweed. The first error I was able to capture was: undefined method split for it_IT:Array caller /usr/lib64/addr ruby/2.20/yast/builtimg.rb:455:in "splitsting" Then there comes a second error and it all aborts anyway. The installer calls for bugreport and requests yast2logs. Well, I attach you all I have. Interrupting the installation gives a normal 13.2 system. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 939506] New: iBus tray icon cannot display in Plasma 5
by bugzilla_noreply＠novell.com 20 Jul '18

20 Jul '18

http://bugzilla.opensuse.org/show_bug.cgi?id=939506 Bug ID: 939506 Summary: iBus tray icon cannot display in Plasma 5 Classification: openSUSE Product: openSUSE Distribution Version: 42.1 Milestone 1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: cycharlie(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- iBus functions under 42.1, but the tray icon does not show on the toolbar in Plasma 5. -- You are receiving this mail because: You are on the CC list for the bug.

1 5