Bug#915076: plasma-discover: Segfaults when using menus while upgrading
Package: plasma-discover Version: 5.8.5-3 Severity: important Application: plasma-discover (5.8.5) Qt Version: 5.7.1 Frameworks Version: 5.28.0 Operating System: Linux 4.9.0-8-amd64 x86_64 Distribution: DebianEdu/Skolelinux -- Information about the crash: I started an update, then moved around in the menus looking at packages, and finally clicked on the menu to have a look at the upgrade, when the program crashed. I got the KDE bug reporter, tried to report the bug, only to discover that it seem to be already reported to KDE with three duplicates, all closed. Unfortunately I did not write down the bug reports and have been unable to find them on https://bugs.kde.org/ >. Just wanted to make sure the Debian maitainers are aware of the crash problem in case you want to fix it in stable. On the positive side, the package upgrade seem to be complete despite the crash (or perhaps wrapping up the upgrade caused the crash? :-). -- Backtrace: Application: Discover (plasma-discover), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7feb855470c0 (LWP 14511))] Thread 9 (Thread 0x7feb57fff700 (LWP 14529)): #0 0x7feb90dd26ed in read () at ../sysdeps/unix/syscall-template.S:84 #1 0x7feb8c622d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7feb8c5de4be in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7feb8c5de994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7feb8c5deb0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7feb919ef06b in QEventDispatcherGlib::processEvents (this=0x7feb4c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #6 0x7feb919989ca in QEventLoop::exec (this=this@entry=0x7feb57ffed00, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #7 0x7feb917c60f3 in QThread::exec (this=) at thread/qthread.cpp:507 #8 0x7feb917cada8 in QThreadPrivate::start (arg=0x55865ba47e90) at thread/qthread_unix.cpp:368 #9 0x7feb8e713494 in start_thread (arg=0x7feb57fff700) at pthread_create.c:333 #10 0x7feb90ddfacf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 8 (Thread 0x7feb5e676700 (LWP 14519)): #0 0x7feb90dd667d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7feb8c5de9f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7feb8c5ded82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7feb64932656 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #4 0x7feb8c6063d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7feb8e713494 in start_thread (arg=0x7feb5e676700) at pthread_create.c:333 #6 0x7feb90ddfacf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 7 (Thread 0x7feb5ee77700 (LWP 14518)): #0 0x7feb90dd667d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7feb8c5de9f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7feb8c5deb0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7feb8c5deb51 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7feb8c6063d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7feb8e713494 in start_thread (arg=0x7feb5ee77700) at pthread_create.c:333 #6 0x7feb90ddfacf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 6 (Thread 0x7feb7114d700 (LWP 14516)): #0 0x7feb8c5de3e0 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7feb8c5de994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7feb8c5deb0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7feb919ef06b in QEventDispatcherGlib::processEvents (this=0x7feb68c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #4 0x7feb919989ca in QEventLoop::exec (this=this@entry=0x7feb7114cd00, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x7feb917c60f3 in QThread::exec (this=) at thread/qthread.cpp:507 #6 0x7feb917cada8 in QThreadPrivate::start (arg=0x7feb68003650) at thread/qthread_unix.cpp:368 #7 0x7feb8e713494 in start_thread (arg=0x7feb7114d700) at pthread_create.c:333 #8 0x7feb90ddfacf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 Thread 5 (Thread 0x7feb7194e700 (LWP 14515)): #0 0x7feb90dd26ed in read () at ../sysdeps/unix/syscall-template.S:84 #1 0x7feb8c622d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7feb8c5de4be in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7feb8c5de994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7feb8c5deb0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7feb919ef06b in QEventDispatcherGlib::processEvents (this=0x7feb680008c0, flags=...) at
Bug#881333: tracking OpenGL support for specific boards
El jueves, 29 de noviembre de 2018 19:00:28 -03 Re4son escribió: [snip] > > Many of those chipsets you list, as I understand, have a mesa driver > > for them that support opengl and gles. > > Such as freedreno which supports Mali A4XX series. https://mesamatrix.net/ > > > > Keep in mind, only the proprietary drivers seem to not support opengl > > while the hardware is perfectly capable of doing so. > > Not necessarily. > If the manufacturer specifies OpenGL ES support, then - on the hardware > level - it is a GLES renderer and may or may not support the entire > OpenGL specification natively. It usually requires considerable work to > make GLES hardware support OpenGL. > Eric Anhold can tell you all about the hard work he has put into > bastardising his VC4 mesa driver to make up for the lack of hardware > support: > > https://github.com/anholt/mesa/wiki/VC4-OpenGL-support Ah, so there was the gotcha. I was really surprised to learn that it was "just" a driver issue. Clearly the Desktop OpenGL support is almost there, but not entirely. So the real place which should be fixed is, somehow, in Qt itself, and preferably by not hacking libs. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#881333: tracking OpenGL support for specific boards
On 28/11/18 1:19 am, bret curtis wrote >> Great that you collected that dataset, and put it public. >> >> What would help further would be for such information having references >> to sources, and each information point be referencable (not only the >> dataset as a whole). >> > Isn't this already done for us here? > https://gpuinfo.org/ > > If anything, it should be used to fill in that list. Great data, thanks. I'll add that. I basically used data from the Khronos website to point me in a general direction and then I used manufacturers specifications to fill in the GL/GLES columns. > Many of those chipsets you list, as I understand, have a mesa driver > for them that support opengl and gles. > Such as freedreno which supports Mali A4XX series. https://mesamatrix.net/ > > Keep in mind, only the proprietary drivers seem to not support opengl > while the hardware is perfectly capable of doing so. Not necessarily. If the manufacturer specifies OpenGL ES support, then - on the hardware level - it is a GLES renderer and may or may not support the entire OpenGL specification natively. It usually requires considerable work to make GLES hardware support OpenGL. Eric Anhold can tell you all about the hard work he has put into bastardising his VC4 mesa driver to make up for the lack of hardware support: https://github.com/anholt/mesa/wiki/VC4-OpenGL-support Hope that helps, Re4son > > Cheers, > Bret
Bug#915039: CVE-2018-19516: HTML email can open browser window automatically
Source: kf5-messagelib Version: 4:18.08.1-1 Severity: grave Tags: upstream security Hi, KDE published the following security advisory (CVE-2018-19516): > messagelib by default displays emails as plain text, but gives the user > an option to "Prefer HTML to plain text" in the settings and if that option > is not enabled there is way to enable HTML display when an email contains > HTML. > > Some HTML emails can trick messagelib into opening a new browser window when > displaying said email as HTML. > > This happens even if the option to allow the HTML emails to access > remote servers is disabled in KMail settings. > > This means that the owners of the servers referred in the email can see > in their access logs your IP address. https://www.kde.org/info/security/advisory-20181128-1.txt Cheers, Felix
[bts-link] source package src:qtbase-opensource-src
# # bts-link upstream status pull for source package src:qtbase-opensource-src # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #899274 (http://bugs.debian.org/899274) # Bug title: KMail does not always remember the desired message list columns # * https://bugreports.qt.io/browse/QTBUG-65478 # * remote resolution changed: Fixed -> Done usertags 899274 - resolution-Fixed usertags 899274 + resolution-Done thanks
[bts-link] source package juk
# # bts-link upstream status pull for source package juk # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #531008 (http://bugs.debian.org/531008) # Bug title: Whenever PC starts juk from autostart directory, application crashes # * http://bugs.kde.org/show_bug.cgi?id=193850 # * remote status changed: NEEDSINFO -> RESOLVED # * remote resolution changed: WAITINGFORINFO -> WORKSFORME # * closed upstream tags 531008 + fixed-upstream usertags 531008 - status-NEEDSINFO resolution-WAITINGFORINFO usertags 531008 + status-RESOLVED resolution-WORKSFORME thanks
[bts-link] source package qtbase-opensource-src
# # bts-link upstream status pull for source package qtbase-opensource-src # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #867974 (http://bugs.debian.org/867974) # Bug title: libqt5gui5: new-delete-type-mismatch in QOpenGLContext destructor # * https://bugreports.qt.io/browse/QTBUG-57773 # * remote resolution changed: Fixed -> Done usertags 867974 - resolution-Fixed usertags 867974 + resolution-Done thanks
Processed: [bts-link] source package juk
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package juk > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # https://bts-link-team.pages.debian.net/bts-link/ > # > user debian-bts-l...@lists.debian.org Setting user to debian-bts-l...@lists.debian.org (was debian-bts-l...@lists.debian.org). > # remote status report for #531008 (http://bugs.debian.org/531008) > # Bug title: Whenever PC starts juk from autostart directory, application > crashes > # * http://bugs.kde.org/show_bug.cgi?id=193850 > # * remote status changed: NEEDSINFO -> RESOLVED > # * remote resolution changed: WAITINGFORINFO -> WORKSFORME > # * closed upstream > tags 531008 + fixed-upstream Bug #531008 [juk] Whenever PC starts juk from autostart directory, application crashes Added tag(s) fixed-upstream. > usertags 531008 - status-NEEDSINFO resolution-WAITINGFORINFO Usertags were: resolution-WAITINGFORINFO status-NEEDSINFO. Usertags are now: . > usertags 531008 + status-RESOLVED resolution-WORKSFORME There were no usertags set. Usertags are now: status-RESOLVED resolution-WORKSFORME. > thanks Stopping processing here. Please contact me if you need assistance. -- 531008: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531008 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#883100: marked as done (ksudoku FTBFS on armel/armhf: error: conflicting declaration 'typedef ptrdiff_t GLsizeiptr')
Your message dated Thu, 29 Nov 2018 18:51:17 +0200
with message-id <20181129165117.GA3209@localhost>
and subject line With #894076 fixed this now builds
has caused the Debian Bug report #883100,
regarding ksudoku FTBFS on armel/armhf: error: conflicting declaration 'typedef
ptrdiff_t GLsizeiptr'
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
883100: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883100
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: ksudoku
Version: 4:17.08.3-1
Severity: serious
Tags: patch
https://buildd.debian.org/status/package.php?p=ksudoku
...
In file included from /usr/include/GL/gl.h:2055:0,
from /<>/src/gui/views/ArcBall.h:43,
from /<>/src/gui/views/roxdokuview.h:34,
from /<>/src/gui/views/ksview.cpp:35:
/usr/include/GL/glext.h:466:19: error: conflicting declaration 'typedef
ptrdiff_t GLsizeiptr'
typedef ptrdiff_t GLsizeiptr;
^~
In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:107:0,
from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:45,
from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/QGL:1,
from /<>/src/gui/views/roxdokuview.h:26,
from /<>/src/gui/views/ksview.cpp:35:
/usr/include/GLES3/gl3.h:75:25: note: previous declaration as 'typedef
khronos_ssize_t GLsizeiptr'
typedef khronos_ssize_t GLsizeiptr;
^~
In file included from /usr/include/GL/gl.h:2055:0,
from /<>/src/gui/views/ArcBall.h:43,
from /<>/src/gui/views/roxdokuview.h:34,
from /<>/src/gui/views/ksview.cpp:35:
/usr/include/GL/glext.h:467:19: error: conflicting declaration 'typedef
ptrdiff_t GLintptr'
typedef ptrdiff_t GLintptr;
^~~~
In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:107:0,
from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:45,
from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/QGL:1,
from /<>/src/gui/views/roxdokuview.h:26,
from /<>/src/gui/views/ksview.cpp:35:
/usr/include/GLES3/gl3.h:76:26: note: previous declaration as 'typedef
khronos_intptr_t GLintptr'
typedef khronos_intptr_t GLintptr;
^~~~
src/gui/CMakeFiles/ksudoku_gui.dir/build.make:321: recipe for target
'src/gui/CMakeFiles/ksudoku_gui.dir/views/ksview.cpp.o' failed
make[4]: *** [src/gui/CMakeFiles/ksudoku_gui.dir/views/ksview.cpp.o] Error 1
Fix is attached.
Description: OpenGL support doesn't build when Qt is compiled with OpenGL ES
Author: Adrian Bunk
--- ksudoku-17.08.3.orig/CMakeLists.txt
+++ ksudoku-17.08.3/CMakeLists.txt
@@ -26,7 +26,9 @@ find_package(KF5 ${KF5_MIN_VERSION} REQU
find_package(KF5KDEGames 4.9.0 REQUIRED)
-find_package(OpenGL)
+if(NOT ${Qt5Gui_OPENGL_IMPLEMENTATION} MATCHES "GLES")
+find_package(OpenGL)
+endif()
set_package_properties(OpenGL PROPERTIES DESCRIPTION "API for developing
portable, interactive 2D and 3Dgraphics applications" TYPE REQUIRED PURPOSE
"Kubrick will not be built and KSudoku will not have Roxdoku support without
OpenGL.")
include(FeatureSummary)
--- End Message ---
--- Begin Message ---
With #894076 fixed this now builds.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed--- End Message ---
