January 2013 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 599698] New: interrupted zypper, now it's hung and won't exit
by bugzilla_noreply＠novell.com 24 Jan '13

24 Jan '13

http://bugzilla.novell.com/show_bug.cgi?id=599698 http://bugzilla.novell.com/show_bug.cgi?id=599698#c0 Summary: interrupted zypper, now it's hung and won't exit Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: x86-64 OS/Version: openSUSE 11.2 Status: NEW Severity: Normal Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers(a)forge.provo.novell.com ReportedBy: jnelson-suse(a)jamponi.net QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100317 SUSE/3.5.9-0.1.1 Firefox/3.5.9 I ran: sudo zypper .... and almost immediately realized I gave it the wrong commandline. I hit control-c several times. [jnelson@worklaptop:~] sudo zypper install search ^C^C OK OK! Exiting immediately... ^C^C^C^C^C^C^C^C^C^C ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C ^C^C^C^C^C it never quit. It's hung. I became root, and used gdb to attach to zypper, and ran this backtrace: (gdb) bt #0 __lll_lock_wait_private () at ./nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 #1 0x00007f7bf202a7e3 in _L_lock_11371 () from /lib64/libc.so.6 #2 0x00007f7bf2029b24 in __libc_realloc (oldmem=0x7f7bf2307e60, bytes=81) at malloc.c:3813 #3 0x00007f7bf2097ff5 in __vasprintf_chk (result_ptr=0x7fff57047dd0, flags=1, format=0x7f7bf32b8d60 "%s <%d> %s(%d) [%s] %s(%s):%d %s", args=<value optimized out>) at vasprintf_chk.c:90 #4 0x00007f7bf324e0a2 in zypp::str::form(char const*, ...) () from /usr/lib64/libzypp.so.619 #5 0x00007f7bf3253b03 in zypp::base::LogControl::LineFormater::format(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, zypp::base::logger::LogLevel, char const*, char const*, int, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib64/libzypp.so.619 #6 0x00007f7bf32582a3 in zypp::base::logger::Loglinebuf::writeout(char const*, long) () from /usr/lib64/libzypp.so.619 #7 0x00007f7bf3255a7e in zypp::base::logger::Loglinebuf::overflow(int) () from /usr/lib64/libzypp.so.619 #8 0x00007f7bf2813b00 in sputc (__c=<value optimized out>, this=<value optimized out>) at /usr/src/debug/gcc-4.4.1-20090817/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/streambuf:410 #9 std::basic_ostream<char, std::char_traits<char> >::put (__c=<value optimized out>, this=<value optimized out>) at /usr/src/debug/gcc-4.4.1-20090817/obj-x86_64-suse-linux/x86_64-suse-linux/libstdc++-v3/include/bits/ostream.tcc:163 #10 0x000000000043365d in Zypper::cleanup() () #11 0x0000000000455e9a in signal_handler(int) () #12 <signal handler called> #13 0x00007f7bf2051616 in __libc_fork () at ./nptl/sysdeps/unix/sysv/linux/fork.c:130 #14 0x00007f7bf3167c77 in zypp::ExternalProgram::start_program(char const* const*, std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const&, zypp::ExternalProgram::Stderr_Disposition, int, bool, char const*) () from /usr/lib64/libzypp.so.619 #15 0x00007f7bf316a3ab in zypp::ExternalProgram::ExternalProgram(char const* const*, zypp::ExternalProgram::Stderr_Disposition, bool, int, bool, zypp::filesystem::Pathname const&) () from /usr/lib64/libzypp.so.619 #16 0x00007f7bf31829ef in zypp::KeyRing::Impl::importKey(zypp::filesystem::Pathname const&, zypp::filesystem::Pathname const&) () from /usr/lib64/libzypp.so.619 #17 0x00007f7bf3182c68 in zypp::KeyRing::Impl::importKey(zypp::PublicKey const&, bool) () from /usr/lib64/libzypp.so.619 #18 0x00007f7bf30d9bd0 in zypp::target::rpm::RpmDb::exportTrustedKeysInZyppKeyRing() () from /usr/lib64/libzypp.so.619 #19 0x00007f7bf30e24cc in zypp::target::rpm::RpmDb::initDatabase(zypp::filesystem::Pathname, zypp::filesystem::Pathname, bool) () from /usr/lib64/libzypp.so.619 #20 0x00007f7bf310bdc4 in zypp::target::TargetImpl::TargetImpl(zypp::filesystem::Pathname const&, bool) () from /usr/lib64/libzypp.so.619 #21 0x00007f7bf31fb211 in zypp::Target::Target(zypp::filesystem::Pathname const&, bool) () from /usr/lib64/libzypp.so.619 #22 0x00007f7bf321003c in zypp::zypp_detail::ZYppImpl::initializeTarget(zypp::filesystem::Pathname const&, bool) () from /usr/lib64/libzypp.so.619 #23 0x000000000046e70a in init_target(Zypper&) () #24 0x00000000004853cc in ?? () #25 0x00000000004908a5 in void init_repos<std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >(Zypper&, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) () #26 0x0000000000486d68 in init_repos(Zypper&) () #27 0x000000000043ee72 in Zypper::doCommand() () #28 0x0000000000445d88 in Zypper::safeDoCommand() () #29 0x0000000000446968 in Zypper::main(int, char**) () #30 0x0000000000456094 in main () (gdb) The other zypper process is zombied: 25531 pts/6 T+ 0:00 zypper install search 25641 pts/6 Z+ 0:00 [zypper] <defunct> obviously a bug, somewhere. Only occasionally reproduceable. Reproducible: Sometimes Steps to Reproduce: 1. 2. 3. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 20

[Bug 798471] New: After the lates grub update: LVM system volume not found, system unbootable.
by bugzilla_noreply＠novell.com 24 Jan '13

24 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=798471 https://bugzilla.novell.com/show_bug.cgi?id=798471#c0 Summary: After the lates grub update: LVM system volume not found, system unbootable. Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Critical Priority: P5 - None Component: Bootloader AssignedTo: jsrain(a)suse.com ReportedBy: stakanov(a)freenet.de QAContact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Firefox/17.0 The system in question is a laptop running opensuse 64bit V.12.2 with /boot and /LVM2 system device (devided then in 4 partitions /kvm /home /root /swap I installed the latest update to grub2 yesterday. While trying to reboot afterwards, the system went into a loop saying: cannot find "system"volume, registering, this can take a while. This is very fast and cannot be paused. So the exact notice I cannot give it here, only the "3D fast shutter cinema version" LOL. The system does not arrive at the point where it asks for the LUKS password but loops before, shortly after "doing fast boot". I was able to enter the LVM and eventually verify the correctness of the volumes. The LVM2 system volume is there and all the other sub volumes are there too. I can mount normally /boot. I can also access /home and all the data. A complete description of the commands emitted you may find here: https://forums.opensuse.org/english/get-technical-help-here/install-boot-lo… Maybe you jump right to the last two posts and you see the problem. It took me a week to customize all the settings and to set up the system from the scratch (it is a new install, not even two weeks old) and I would rather like to recover it. Reproducible: Always Steps to Reproduce: 1.apply patch to grub2 2.reboot 3.system loops, complaining that "system" folder cannot be found. Actual Results: The system apparently is not able to mount an LUKS encrypted LVM partition after applying the update to grub. Expected Results: the system should mount the LVM partition normally, decrypt and mount system volume. -- 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 37

[Bug 799489] New: latex takes forever to install.
by bugzilla_noreply＠novell.com 24 Jan '13

24 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=799489 https://bugzilla.novell.com/show_bug.cgi?id=799489#c0 Summary: latex takes forever to install. Classification: openSUSE Product: openSUSE Factory Version: 12.3 Beta 1 Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Maintenance AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: nrickert(a)ameritech.net QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 I normally wait till the final release before installing latex. However, because of the reorganization, I decided to test install with 12.3 Beta1. The output of "ps" shows that I started Yast at 2:12 pm. I took perhaps 5 minutes or so making selections in Software Manager. It is now 3:40 pm. It shows as 83% complete, and that number (83%) has been steady for a while. Individual packages are installing, but very slowly. My best guess - there is probably a finishing script that is run after each package, to update the database. With a large number of packages - I seem to recall around 750, but Yast is too busy for me to be able to scroll back and check - this involves a lot of unnecessary work. Maybe the reorganization was not a good idea after all. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3. -- 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 3

[Bug 577790] New: aria2 makes libzypp slow till unusable
by bugzilla_noreply＠novell.com 24 Jan '13

24 Jan '13

http://bugzilla.novell.com/show_bug.cgi?id=577790 http://bugzilla.novell.com/show_bug.cgi?id=577790#c0 Summary: aria2 makes libzypp slow till unusable Classification: openSUSE Product: openSUSE 11.3 Version: Factory Platform: All OS/Version: openSUSE 11.3 Status: NEW Severity: Major Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers(a)forge.provo.novell.com ReportedBy: lmuelle(a)novell.com QAContact: qa(a)suse.de Found By: Development Blocker: --- While calling zypper dup (after a zypper refresh) one system fetched packages with a noticeable delay. While a second system failed to download at all. Using ZYPP_ARIA2C=0 zypper refresh|up zypper|dup works as expected. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 12

[Bug 793336] New: Automount maps no accessible + AutoFS sometimes hangs with 100% CPU
by bugzilla_noreply＠novell.com 24 Jan '13

24 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=793336 https://bugzilla.novell.com/show_bug.cgi?id=793336#c0 Summary: Automount maps no accessible + AutoFS sometimes hangs with 100% CPU Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: joschibrauchle(a)gmx.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11 I have experienced some problems with autofs 5.0.7 on openSUSE 12.2 with multiple machines lately. Sometimes right after booting the machine, sometimes after some operation time, direct maps become "unavailable", that is, for example # cd /opt/<direct map> No such file or directory If i then issue # rcautofs restart I get the following lines in the logs: -------------- Dec 6 10:33:57 lab05 automount[2758]: mapent cache rwlock busy Dec 6 10:33:57 lab05 automount[2758]: do_umount_autofs_direct: couldn't get ioctl fd for direct mount /opt/servershare Dec 6 10:33:57 lab05 automount[2758]: mapent cache rwlock busy Dec 6 10:33:57 lab05 automount[2758]: do_umount_autofs_direct: couldn't get ioctl fd for direct mount /opt/lnt Dec 6 10:33:57 lab05 automount[2758]: mapent cache rwlock busy Dec 6 10:33:57 lab05 automount[2758]: do_umount_autofs_direct: couldn't get ioctl fd for direct mount /doc Dec 6 10:33:57 lab05 automount[2758]: mapent cache rwlock busy Dec 6 10:33:57 lab05 automount[2758]: do_umount_autofs_direct: couldn't get ioctl fd for direct mount /group -------------- All of the above entries are direct maps, managed via kerberized LDAP... I am not sure if it happens with indirect maps as well. After AutoFS restart, all dirs become available! The problem may (or may not) have something to do with automount getting stuck in some kind of loop sometimes right after boot, taking 100% CPU and not responding. I was not yet able to check if both conditions (maps not available and AutoFS hanging) always coincide. I did an strace -fF on the hanging process after boot and got the following: -------------- ... 2861 poll([{fd=7, events=POLLIN}], 1, -217828) = 1 ([{fd=7, revents=POLLIN}]) 2861 poll([{fd=7, events=POLLIN}], 1, -217828) = 1 ([{fd=7, revents=POLLIN}]) 2861 poll([{fd=7, events=POLLIN}], 1, -217828) = 1 ([{fd=7, revents=POLLIN}]) 2861 poll([{fd=7, events=POLLIN}], 1, -217828) = 1 ([{fd=7, revents=POLLIN}]) 2861 poll([{fd=7, events=POLLIN}], 1, -217828) = 1 ([{fd=7, revents=POLLIN}]) 2861 poll([{fd=7, events=POLLIN}], 1, -217828) = 1 ([{fd=7, revents=POLLIN}]) 2861 poll([{fd=7, events=POLLIN}], 1, -217829) = 1 ([{fd=7, revents=POLLIN}]) 2861 poll([{fd=7, events=POLLIN}], 1, -217829) = 1 ([{fd=7, revents=POLLIN}]) 2861 poll([{fd=7, events=POLLIN}], 1, -217829) = 1 ([{fd=7, revents=POLLIN}]) 2861 poll([{fd=7, events=POLLIN}], 1, -217829) = 1 ([{fd=7, revents=POLLIN}]) 2861 poll([{fd=7, events=POLLIN}], 1, -217829) = 1 ([{fd=7, revents=POLLIN}]) ... -------------- The number -21782... is repeating multiple times before decreases by one (i.e. magnitude increases). This continues indefinitely (or longer than I was wanting to wait). I have now turned autofs logging to "debug" and will wait for the problem to reappear... possibly, the two described problems are the same or separate ones. Reproducible: Didn't try -- 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 24

[Bug 800260] New: zypp-plugin-spacewalk ignores zypper status enabled
by bugzilla_noreply＠novell.com 24 Jan '13

24 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=800260 https://bugzilla.novell.com/show_bug.cgi?id=800260#c0 Summary: zypp-plugin-spacewalk ignores zypper status enabled Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: All OS/Version: SLES 11 Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software AssignedTo: opensuse-communityscreening(a)forge.provo.novell.com ReportedBy: mopp(a)gmx.net QAContact: opensuse-communityscreening(a)forge.provo.novell.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 The zypp-plugin-spacewalk cannot be disabled with zypper. I'd like to do the following. Disable the zypp-plugin-spacewalk, but still use it for communication with the spacewalk server. I just want to disable it for the patch download. It works if I disable the spacewalk source in YaST, but it does not show the status in zypper. It is always enabled in zypper. The enabled status of zypper and yast repositories are not in sync. To make a long story short. It is not possible to disable the zypp-plugin-spacewalk with zypper, but it works with YaST. Reproducible: Always Steps to Reproduce: Using: zypper-1.6.167-0.7.2 & zypp-plugin-spacewalk-0.8-2.1 First test with enabled spacewalk service: # zypper ls -u # | Alias | Name | Enabled | Refresh | Type | URI --+--------------------------------------------------+--------------------------------------------------+---------+---------+--------+---------------------------------------------------------------------------------- 1 | spacewalk | spacewalk | Yes | Yes | plugin | file:/usr/lib/zypp/plugins/services/spacewalk [...] # zypper lu Refreshing service 'spacewalk'. Loading repository data... Reading installed packages... S | Repository | Name | Current Version | Available Version | Arch --+---------------------------+------------------------------+-----------------------+-----------------------+------- v | SLES11_SP2_Channel_x86_64 | MozillaFirefox | 10.0-0.3.2 | 10.0.7-0.3.1 | x86_64 [...] => Everything as expected # zypper ms -d "spacewalk" Service 'spacewalk' has been sucessfully disabled. # zypper ls -u # | Alias | Name | Enabled | Refresh | Type | URI --+--------------------------------------------------+--------------------------------------------------+---------+---------+--------+---------------------------------------------------------------------------------- 1 | spacewalk | spacewalk | Yes | Yes | plugin | file:/usr/lib/zypp/plugins/services/spacewalk [...] => Error: Still shows enabled # zypper lu Refreshing service 'spacewalk'. Loading repository data... Reading installed packages... S | Repository | Name | Current Version | Available Version | Arch --+---------------------------+------------------------------+-----------------------+-----------------------+------- v | SLES11_SP2_Channel_x86_64 | MozillaFirefox | 10.0-0.3.2 | 10.0.7-0.3.1 | x86_64 [...] => Error: Still shows updates # zypper ms -e "spacewalk" Nothing to change for service 'spacewalk'. => Error: Enabling it again shows nothing to change, because it was not disabled. # yast repositories -> Disabled spacewalk in yast # zypper ls -u # | Alias | Name | Enabled | Refresh | Type | URI --+--------------------------------------------------+--------------------------------------------------+---------+---------+--------+---------------------------------------------------------------------------------- 1 | spacewalk | spacewalk | Yes | Yes | plugin | file:/usr/lib/zypp/plugins/services/spacewalk [...] => After disabling it in YaST it still shows enabled, but it is disabled now # zypper lu Refreshing service 'spacewalk'. Loading repository data... Reading installed packages... No updates found. => YaST can disable the source # zypper ms -e "spacewalk" Nothing to change for service 'spacewalk'. => But zypper still thinks it is enabled # zypper lu Refreshing service 'spacewalk'. Loading repository data... Reading installed packages... No updates found. Actual Results: Configuration of zypp-plugin-spacewalk only works with YaST Expected Results: zypper can enable and disable zypp-plugin-spacewalk, but the communication to the spacewalk server should always work independent from the enable / disable status. -- 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 0

[Bug 774754] New: 2nd stage hang due to SYSTEMD_NO_WRAP not honored by /sbin/service
by bugzilla_noreply＠novell.com 24 Jan '13

24 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=774754 https://bugzilla.novell.com/show_bug.cgi?id=774754#c0 Summary: 2nd stage hang due to SYSTEMD_NO_WRAP not honored by /sbin/service Classification: openSUSE Product: openSUSE 12.2 Version: RC 2 Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: P5 - None Component: Basesystem AssignedTo: lnussel(a)suse.com ReportedBy: lnussel(a)suse.com QAContact: qa-bugs(a)suse.de CC: fcrozat(a)suse.com Found By: --- Blocker: --- yast2 2nd stage uses /sbin/service to restart the network. It can't use systemd for that otherwise installation hangs. /sbin/service needs to honor SYSTEMD_NO_WRAP again to make this work. -- 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 732083] New: kmix: won't put volume above 100% but pulseaudio / alsa can.
by bugzilla_noreply＠novell.com 24 Jan '13

24 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=732083 https://bugzilla.novell.com/show_bug.cgi?id=732083#c0 Summary: kmix: won't put volume above 100% but pulseaudio / alsa can. Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Workspace AssignedTo: kde-maintainers(a)suse.de ReportedBy: jnelson-suse(a)jamponi.net QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0 Please bear with me, I know this sounds a little silly. Lots of newer laptops have their volume artificially limited to avoid hearing damage or something. Especially lenovo laptops are known for this. The problem (and I'm only guessing at this) is when apps like kmix only go to 100%. I know that sounds crazy, but if I open up 'pavucontrol' I can set it to 153% (11.0dB) vs. 100% (0.00dB). Since kmix is what the volume buttons activate, it ought to go all the way up to 11. ;-) Reproducible: Always Steps to Reproduce: 1. 2. 3. -- 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 800155] New: KDE Pager draws window sizes slightly larger than should be, sometimes overdrawing its own image
by bugzilla_noreply＠novell.com 24 Jan '13

24 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=800155 https://bugzilla.novell.com/show_bug.cgi?id=800155#c0 Summary: KDE Pager draws window sizes slightly larger than should be, sometimes overdrawing its own image Classification: openSUSE Product: openSUSE Factory Version: 12.3 Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: P5 - None Component: KDE4 Workspace AssignedTo: kde-maintainers(a)suse.de ReportedBy: jdluhos(a)suse.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=521639) --> (http://bugzilla.novell.com/attachment.cgi?id=521639) The pager when overdrawn by a miscalculated window rectangle. When the KDE Pager is set to show boundaries of windows with their icons (a useful feature because you know immediately what is where), the window rectangles are shown slightly larger in the pager than would be proportional to their real size. Normally this only manifests itself as an off-centered icon for maximized (or almost maximized) windows, but when the pager is clicked on (when switching desktops), the rectangle gets visibly overdrawn over the pager itself, which disturbs the (otherwise very nice) appearance. Please see the attached screenshot. (The desktop theme used here is SUSE Air; the default dark SUSE theme has the same bug.) -- 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 728216] New: KDE logoff button corrupts the screen
by bugzilla_noreply＠novell.com 24 Jan '13

24 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=728216 https://bugzilla.novell.com/show_bug.cgi?id=728216#c0 Summary: KDE logoff button corrupts the screen Classification: openSUSE Product: openSUSE 12.1 Version: RC 1 Platform: x86-64 OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: KDE4 Workspace AssignedTo: kde-maintainers(a)suse.de ReportedBy: rcoe(a)wi.rr.com QAContact: qa(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 I clicked on the Logoff button at the bottom of the KDE desktop and the screen gets totally corrupted. See attached picture. Switching from vt2 and back does not redraw screen. I shutdown the system from vt2, and when I brought it back up, KDE login stuck at the progress drawing icons at startup. The startup never completed. The previously time this happened, I left the computer, and when I came back the lock screen 'unlock' reset the screen. xorg-x11-server-7.6_1.10.4-37.3.x86_64 Reproducible: Always -- 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 11