June 2017 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1043734] Certain applications segfault when using ibus rather than XIM for input method.
by bugzilla_noreply＠novell.com 12 Jun '17

12 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1043734 http://bugzilla.suse.com/show_bug.cgi?id=1043734#c3 --- Comment #3 from Wolfgang Bauer <wbauer(a)tmo.at> --- *** Bug 1043754 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1043754] New: kopete crashes whenever I enter anything
by bugzilla_noreply＠novell.com 12 Jun '17

12 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1043754 Bug ID: 1043754 Summary: kopete crashes whenever I enter anything Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: gp(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since the last update (for at least six days now) whenever I enter anything in a chat window or the search box for contacts, kopete crashes. This reproduces 100%, which implies that kopete is completely unusable for me right now. Application: Kopete (kopete), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7fe808deb900 (LWP 17259))] Thread 5 (Thread 0x7fe7dae1f700 (LWP 17290)): #0 0x00007fe80505b08d in poll () at /lib64/libc.so.6 #1 0x00007fe8000a2ce9 in () at /usr/lib64/libglib-2.0.so.0 #2 0x00007fe8000a3082 in g_main_loop_run () at /usr/lib64/libglib-2.0.so.0 #3 0x00007fe7f6f223b6 in () at /usr/lib64/libgio-2.0.so.0 #4 0x00007fe8000c9bb5 in () at /usr/lib64/libglib-2.0.so.0 #5 0x00007fe80223b4e7 in start_thread () at /lib64/libpthread.so.0 #6 0x00007fe805064a2f in clone () at /lib64/libc.so.6 Thread 4 (Thread 0x7fe7e89c8700 (LWP 17289)): #0 0x00007fe805056dfd in read () at /lib64/libc.so.6 #1 0x00007fe8000e67e0 in () at /usr/lib64/libglib-2.0.so.0 #2 0x00007fe8000a27cb in g_main_context_check () at /usr/lib64/libglib-2.0.so.0 #3 0x00007fe8000a2c90 in () at /usr/lib64/libglib-2.0.so.0 #4 0x00007fe8000a2dfc in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #5 0x00007fe8000a2e41 in () at /usr/lib64/libglib-2.0.so.0 #6 0x00007fe8000c9bb5 in () at /usr/lib64/libglib-2.0.so.0 #7 0x00007fe80223b4e7 in start_thread () at /lib64/libpthread.so.0 #8 0x00007fe805064a2f in clone () at /lib64/libc.so.6 Thread 3 (Thread 0x7fe7e91c9700 (LWP 17263)): #0 0x00007fe805056dfd in read () at /lib64/libc.so.6 #1 0x00007fe8000e67e0 in () at /usr/lib64/libglib-2.0.so.0 #2 0x00007fe8000a27cb in g_main_context_check () at /usr/lib64/libglib-2.0.so.0 #3 0x00007fe8000a2c90 in () at /usr/lib64/libglib-2.0.so.0 #4 0x00007fe8000a2dfc in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #5 0x00007fe8067e6f0e in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4 #6 0x00007fe8067b53f4 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4 #7 0x00007fe8067b575e in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4 #8 0x00007fe7e9d48833 in QCA::SyncThread::run() () at /usr/lib64/libqca.so.2 #9 0x00007fe8066aa514 in () at /usr/lib64/libQtCore.so.4 #10 0x00007fe80223b4e7 in start_thread () at /lib64/libpthread.so.0 #11 0x00007fe805064a2f in clone () at /lib64/libc.so.6 Thread 2 (Thread 0x7fe7ec62e700 (LWP 17260)): #0 0x00007fe80505b08d in poll () at /lib64/libc.so.6 #1 0x00007fe8000a2ce9 in () at /usr/lib64/libglib-2.0.so.0 #2 0x00007fe8000a2dfc in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #3 0x00007fe8067e6f0e in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4 #4 0x00007fe8067b53f4 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4 #5 0x00007fe8067b575e in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4 #6 0x00007fe8066a7c56 in QThread::exec() () at /usr/lib64/libQtCore.so.4 #7 0x00007fe806795943 in () at /usr/lib64/libQtCore.so.4 #8 0x00007fe8066aa514 in () at /usr/lib64/libQtCore.so.4 #9 0x00007fe80223b4e7 in start_thread () at /lib64/libpthread.so.0 #10 0x00007fe805064a2f in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7fe808deb900 (LWP 17259)): [KCrash Handler] #6 0x00007fe8058fe2de in QApplication::x11ProcessEvent(_XEvent*) () at /usr/lib64/libQtGui.so.4 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1043734] Certain applications segfault when using ibus rather than XIM for input method.
by bugzilla_noreply＠novell.com 12 Jun '17

12 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1043734 Gerald Pfeifer <gp(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gp(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1043414] umount hangs on ppc64le -> reduced build power on OBS
by bugzilla_noreply＠novell.com 12 Jun '17

12 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1043414 http://bugzilla.suse.com/show_bug.cgi?id=1043414#c15 --- Comment #15 from Jan Kara <jack(a)suse.com> --- Thanks for the data, I'll have a look into it tomorrow. I forgot one directory level in the workaround command. It should have been: echo 0 >/sys/block/<dev>/queue/wbt_lat_usec -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1041277] GCC 7: poedit fails to build
by bugzilla_noreply＠novell.com 12 Jun '17

12 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1041277 Andreas Stieger <astieger(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P4 - Low Status|NEW |CONFIRMED -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1043833] Better installer support for SSD drivers
by bugzilla_noreply＠novell.com 12 Jun '17

12 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1043833 Arvin Schnell <aschnell(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aschnell(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1042764] Xserver: Sig11 after Reset and following Xclient terminates
by bugzilla_noreply＠novell.com 12 Jun '17

12 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1042764 http://bugzilla.suse.com/show_bug.cgi?id=1042764#c11 --- Comment #11 from Takashi Iwai <tiwai(a)suse.com> --- I checked again, and upgrading Mesa package fixed on Leap 42.3, at least. That is, building the current TW package for Leap 42.3 (together with libdrm update), and the problem is gone. I don't know why the previous test with the update of TW package didn't work. In anyway, it's an issue of Mesa. So a quicky fix for Leap 42.3 is to upgrade Meas to the current TW vesrion (17.1.1), or 17.1.2 as on X11:XOrg. But for older version and also for SLE12, I'm not sure what's the best option. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 997757] fstrim takes almost an hour, starves other IO-bound processes
by bugzilla_noreply＠novell.com 12 Jun '17

12 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=997757 http://bugzilla.suse.com/show_bug.cgi?id=997757#c9 Robert Munteanu <robert.munteanu(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(robert.munteanu@g | |mail.com) | --- Comment #9 from Robert Munteanu <robert.munteanu(a)gmail.com> --- For some reason this looks considerably better to me: # time fstrim -a -v | tee fstrim.log /home: 49.3 GiB (52971085824 bytes) trimmed /boot: 264.1 MiB (276962304 bytes) trimmed real 0m0.143s user 0m0.001s sys 0m0.016s /boot is an ext4 partition belonging to /dev/sda ( INTEL SSDSC2BB60 ) /home is a logical volume composed out of the above Intel SSD and a SAMSUNG MZ7LN512 SSD. I am not sure if anything else is left to be done here, feel free to close. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1043602] systemd fstrim timer defaults is insanely long
by bugzilla_noreply＠novell.com 12 Jun '17

12 Jun '17

http://bugzilla.opensuse.org/show_bug.cgi?id=1043602 http://bugzilla.opensuse.org/show_bug.cgi?id=1043602#c8 --- Comment #8 from Stanislav Brabec <sbrabec(a)suse.com> --- Well, as it is a sensitive area that can affect hardware lifetime, I do not want to diverge from the upstream. As a user of a standard SSD, you don't see internal processes of each write or TRIM command. Typical Flash memory has three sizes of blocks: - Read block: typically tens of bytes - Write block: typically kilobytes. It can change bits in one direction. - Erase block: typically hundreds of kilobytes. It can change bits in reverse direction. Standard sector write means abandoning of the old sector contents and flagging it as garbage, allocation of a new clean block, writing, and remapping the block. When SSD runs out of clean blocks, it attempts to find a complete erase block with all sectors flagged as garbage. If no such block is found, SSD has to pick one half-full erase block, move live blocks outside to get an completely free erase-block. In worst case most of erase blocks are nearly full and the device needs to re-allocate tens of sectors just to get one erase block. Once erase block is allocated, it is erased, one sector is written, and the rest is ready for further use. In case of TRIM, SSD moves used sectors out of erase blocks that contain garbage, and then pre-erases them. In the worst case mentioned above, it means that the >90% of the whole contents of the SSD has to be re-allocated. The worst case happens in case of nearly full disc and random writes of small chunks of data once per each erase block. Real life algorithms are often even more complicated, as it attempts to spread writes evenly over all cells. Linux has absolutely no control over the proprietary wear leveling processes inside the SSD. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1043270] yast2-live-installer in Leap 42.2 crash right after copying into hard disk
by bugzilla_noreply＠novell.com 12 Jun '17

12 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1043270 http://bugzilla.suse.com/show_bug.cgi?id=1043270#c10 --- Comment #10 from Mindaugas Baranauskas <opensuse.lietuviu.kalba(a)gmail.com> --- I hope openSUSE 42.2 will have maintenance update of yast2-live-installer. -- You are receiving this mail because: You are on the CC list for the bug.

1 0