Bug#851216: plasma-workspace: Freezes for long periods of time or indefinitely
Informed this to the upstream KDE bug tracker as well https://bugs.kde.org/show_bug.cgi?id=374983 On 12 January 2017 at 22:12, Alex Henry wrote: > Package: plasma-workspace > Version: 4:5.8.2-1 > Severity: important > Tags: upstream > > From time to time the entire workspace will freeze, without apparent > cause. In earlier versions it would take something around 5 minutes > for it to get back to normal (after that time the menus, tray icons, > desktop, etc would resume working, often carrying out the actions > executed in the meantime). The current version seems to be worse: > the workspace will halt indefintely. > > Thinks like global shortcut keys and application shortcuts still > work, as do other KDE applications and functionality like moving > windows between virtual desktops, the task switcher (alt+tab) and > others like window actions. Taskbars and icons do not respond. > > There is no CPU activity while the workspace is frozen. > > Logging the user out and in again will solve the issue but this > includes closing all applications, etc as normal, which is not > at all an optimal workaround - but necessary since just waiting > doesn't help. The log out takes a couple of minutes to follow > through after the command is issued (via ctrl+alt+del since > kickoff - the "K menu" or "start menu" - won't respond). I > assume this delay happens because of a timer that waits for the > workspace to respond for a while but after running out > it just logs the user off without any response anyway. > > I suggest the maintaner up the severity at his own discretion > because in such a state the KDE desktop shouldn't reach stable. > > > -- System Information: > Debian Release: stretch/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages plasma-workspace depends on: > ii dbus-x11 1.10.14-1 > ii frameworkintegration 5.27.0-1 > ii gdb-minimal [gdb]7.12-4 > ii iso-codes3.72-1 > ii kactivitymanagerd5.8.2-1 > ii kde-cli-tools4:5.8.2-1 > ii kded55.27.0-1 > ii kinit5.27.0-1 > ii kio 5.27.0-2 > ii kpackagetool55.27.0-1 > ii libc62.24-8 > ii libcln6 1.3.4-2 > ii libdbusmenu-qt5-20.9.3+16.04.20160218-1 > ii libgcc1 1:6.2.1-5 > ii libgps22 3.16-4 > ii libice6 2:1.0.9-1+b1 > ii libkf5activities55.27.0-1 > ii libkf5auth5 5.27.0-1 > ii libkf5baloo5 5.27.0-1 > ii libkf5bookmarks5 5.27.0-1 > ii libkf5calendarevents55.27.0-1+b1 > ii libkf5completion55.27.0-1 > ii libkf5configcore55.27.0-1 > ii libkf5configgui5 5.27.0-1 > ii libkf5configwidgets5 5.27.0-1 > ii libkf5coreaddons55.27.0-1 > ii libkf5crash5 5.27.0-1 > ii libkf5dbusaddons55.27.0-1 > ii libkf5declarative5 5.27.0-1+b1 > ii libkf5globalaccel-bin5.27.0-1 > ii libkf5globalaccel5 5.27.0-1 > ii libkf5guiaddons5 5.27.0-1 > ii libkf5holidays5 16.04.2-1 > ii libkf5i18n5 5.27.0-2 > ii libkf5iconthemes55.27.0-1 > ii libkf5idletime5 5.27.0-1 > ii libkf5itemviews5 5.27.0-1 > ii libkf5jobwidgets55.27.0-1 > ii libkf5js55.27.0-1 > ii libkf5jsembed5 5.27.0-1 > ii libkf5kdelibs4support5 5.27.0-1 > ii libkf5kiocore5 5.27.0-2 > ii libkf5kiofilewidgets55.27.0-2 > ii libkf5kiowidgets55.27.0-2 > ii libkf5networkmanagerqt6 5.28.0-1 > ii libkf5newstuff5 5.27.0-1 > ii libkf5notifications5 5.27.0-1 > ii libkf5notifyconfig5 5.27.0-1 > ii libkf5package5 5.27.0-1 > ii libkf5plasma55.27.0-1 > ii libkf5plasmaquick5 5.27.0-1 > ii libkf5quickaddons5 5.27.0-1+b1 > ii libkf5runne
Bug#851216: plasma-workspace: Freezes for long periods of time or indefinitely
Package: plasma-workspace Version: 4:5.8.2-1 Severity: important Tags: upstream >From time to time the entire workspace will freeze, without apparent cause. In earlier versions it would take something around 5 minutes for it to get back to normal (after that time the menus, tray icons, desktop, etc would resume working, often carrying out the actions executed in the meantime). The current version seems to be worse: the workspace will halt indefintely. Thinks like global shortcut keys and application shortcuts still work, as do other KDE applications and functionality like moving windows between virtual desktops, the task switcher (alt+tab) and others like window actions. Taskbars and icons do not respond. There is no CPU activity while the workspace is frozen. Logging the user out and in again will solve the issue but this includes closing all applications, etc as normal, which is not at all an optimal workaround - but necessary since just waiting doesn't help. The log out takes a couple of minutes to follow through after the command is issued (via ctrl+alt+del since kickoff - the "K menu" or "start menu" - won't respond). I assume this delay happens because of a timer that waits for the workspace to respond for a while but after running out it just logs the user off without any response anyway. I suggest the maintaner up the severity at his own discretion because in such a state the KDE desktop shouldn't reach stable. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages plasma-workspace depends on: ii dbus-x11 1.10.14-1 ii frameworkintegration 5.27.0-1 ii gdb-minimal [gdb]7.12-4 ii iso-codes3.72-1 ii kactivitymanagerd5.8.2-1 ii kde-cli-tools4:5.8.2-1 ii kded55.27.0-1 ii kinit5.27.0-1 ii kio 5.27.0-2 ii kpackagetool55.27.0-1 ii libc62.24-8 ii libcln6 1.3.4-2 ii libdbusmenu-qt5-20.9.3+16.04.20160218-1 ii libgcc1 1:6.2.1-5 ii libgps22 3.16-4 ii libice6 2:1.0.9-1+b1 ii libkf5activities55.27.0-1 ii libkf5auth5 5.27.0-1 ii libkf5baloo5 5.27.0-1 ii libkf5bookmarks5 5.27.0-1 ii libkf5calendarevents55.27.0-1+b1 ii libkf5completion55.27.0-1 ii libkf5configcore55.27.0-1 ii libkf5configgui5 5.27.0-1 ii libkf5configwidgets5 5.27.0-1 ii libkf5coreaddons55.27.0-1 ii libkf5crash5 5.27.0-1 ii libkf5dbusaddons55.27.0-1 ii libkf5declarative5 5.27.0-1+b1 ii libkf5globalaccel-bin5.27.0-1 ii libkf5globalaccel5 5.27.0-1 ii libkf5guiaddons5 5.27.0-1 ii libkf5holidays5 16.04.2-1 ii libkf5i18n5 5.27.0-2 ii libkf5iconthemes55.27.0-1 ii libkf5idletime5 5.27.0-1 ii libkf5itemviews5 5.27.0-1 ii libkf5jobwidgets55.27.0-1 ii libkf5js55.27.0-1 ii libkf5jsembed5 5.27.0-1 ii libkf5kdelibs4support5 5.27.0-1 ii libkf5kiocore5 5.27.0-2 ii libkf5kiofilewidgets55.27.0-2 ii libkf5kiowidgets55.27.0-2 ii libkf5networkmanagerqt6 5.28.0-1 ii libkf5newstuff5 5.27.0-1 ii libkf5notifications5 5.27.0-1 ii libkf5notifyconfig5 5.27.0-1 ii libkf5package5 5.27.0-1 ii libkf5plasma55.27.0-1 ii libkf5plasmaquick5 5.27.0-1 ii libkf5quickaddons5 5.27.0-1+b1 ii libkf5runner55.27.0-1 ii libkf5service-bin5.27.0-1 ii libkf5service5 5.27.0-1 ii libkf5solid5 5.27.0-1 ii libkf5texteditor55.27.0-1 ii libkf5textwidgets5 5.27.0-1 ii libkf5wallet-bin
Bug#851170: libqt5webengine5: h.264 video does not seem to work
(sorry for the double mail Sandro, I am very bad at email!!!) I'm trying to figure out what exactly use_system_ffmpeg and use_proprietary_codecs does. It seems to me that use_system_ffmpeg will do exactly as it sounds and will use system libav* libraries. I went and downloaded webengine 5.7 source: git clone https://code.qt.io/qt/qtwebengine.git -b 5.7 and did some digging in there. In src/core/renderer/content_renderer_client_qt.cpp I found: #if defined(USE_PROPRIETARY_CODECS) info.supported_init_data_types |= media::kInitDataTypeMaskCenc; info.supported_codecs |= media::EME_CODEC_MP4_ALL; #endif // defined(USE_PROPRIETARY_CODECS) After some searching around, I found that media::EME_CODEC_MP4_ALL is defined in chromium, see: https://chromium.googlesource.com/chromium/src.git/+/lkcr/media/base/eme_constants.h So it looks like to me with my non-expert eyes, that use_proprietary_codecs is just setting the bits that the underlying browser engine reports that certain codecs are available to use. It seems that if you have use_proprietary_codecs and use_system_ffmpeg both on, it will still delegate the video to the system libraries. I could be wrong, these are just the results of some preliminary digging! On 01/12, Sandro Knauß wrote: > Hey, > > > please be gentle as this is my first bug report :) > > feel welcome! I hope your first experience with Debian bug reporting is a > good > one. > > > I'm excited that Qt WebEngine is being packaged, so I could use it with > > qutebrowser. > > that is great and we need packages using QtWebEngine to get an idea if we > packaged it correctly. > > > It seems to work beautifully, except that H.264 video is not working. > > I've talked to the developer of qutebrowser and he said that qtwebengine > > might not be configured to use proprietary codecs (see: > > http://doc.qt.io/qt-5/qtwebengine-features.html#audio-and-video-codecs ) > > We were in a rush to get QtWebEngine ready for Debian, so we couldn't > evaluate > all the potentials of QtWebEngine. But on Debian we can't simply include > proprietary codecs, because that would mean, that QtWebEngine will move from > main to non-free and all software using it would endup in contrib. And I > think > must use cases are not include sing proprietary codecs. > > The solution would be, that we would able to use ffmpeg/libh264 from the > system, if available, like other media player do this. And we actually push > this information into the build. So in theory it should be picked up and use > the system ffmpeg libs: > qmake WEBENGINE_CONFIG+="use_system_ffmpeg=1" > > Did you try to just install the necessary libs? > > Under [0] you find the complete build script for Debian. > > >I know that multimedia codecs can be very hairy things in general, but I'm > hoping that since H.264 is enabled in chromium, that the same can be done for > Qt WebEngine. > > I hope so too, but the build of QtWebEngine is another layer on top of the > complex build of the internal chromium. > > Any help how to push QtWebEngine to use system h264 is very welcomed! > > Best Regards, > > sandro > > [0] https://anonscm.debian.org/git/pkg-kde/qt/qtwebengine.git/tree/debian/ > rules -- Robert Cross - OpenPGP key ID: AA332044 Uphold your right to privacy, encrypt your email! https://emailselfdefense.fsf.org/
Bug#851170: libqt5webengine5: h.264 video does not seem to work
Hey, > please be gentle as this is my first bug report :) feel welcome! I hope your first experience with Debian bug reporting is a good one. > I'm excited that Qt WebEngine is being packaged, so I could use it with > qutebrowser. that is great and we need packages using QtWebEngine to get an idea if we packaged it correctly. > It seems to work beautifully, except that H.264 video is not working. > I've talked to the developer of qutebrowser and he said that qtwebengine > might not be configured to use proprietary codecs (see: > http://doc.qt.io/qt-5/qtwebengine-features.html#audio-and-video-codecs ) We were in a rush to get QtWebEngine ready for Debian, so we couldn't evaluate all the potentials of QtWebEngine. But on Debian we can't simply include proprietary codecs, because that would mean, that QtWebEngine will move from main to non-free and all software using it would endup in contrib. And I think must use cases are not include sing proprietary codecs. The solution would be, that we would able to use ffmpeg/libh264 from the system, if available, like other media player do this. And we actually push this information into the build. So in theory it should be picked up and use the system ffmpeg libs: qmake WEBENGINE_CONFIG+="use_system_ffmpeg=1" Did you try to just install the necessary libs? Under [0] you find the complete build script for Debian. >I know that multimedia codecs can be very hairy things in general, but I'm hoping that since H.264 is enabled in chromium, that the same can be done for Qt WebEngine. I hope so too, but the build of QtWebEngine is another layer on top of the complex build of the internal chromium. Any help how to push QtWebEngine to use system h264 is very welcomed! Best Regards, sandro [0] https://anonscm.debian.org/git/pkg-kde/qt/qtwebengine.git/tree/debian/ rules signature.asc Description: This is a digitally signed message part.
Bug#824939: (no subject)
I can confirm this. Without kwin installed, there are no window title bars, which makes it pretty unusable. Best regards, Patrick
Bug#851175: plasma-workspace - All shell packages missing. This is an installation issue, please contact your distribution - missing dependency on plasma-desktop-data
Package: plasma-workspace Severity: grave X-Debbugs-CC: whonix-de...@whonix.org Installing plasma-workspace alone on Debian stretch (after a jessie -> stretch upgrade) leads to leads to the KDE desktop being totally unusable only showing the following error popup. All shell packages missing. This is an installation issue, please contact your distribution As per http://stackoverflow.com/a/39765593/2605155 installing plasma-desktop-data solved this very issue. Therefore plasma-desktop-data included it is a missing dependency of plasma-workspace. Please add. Best regards, Patrick
Bug#851170: libqt5webengine5: h.264 video does not seem to work
Package: libqt5webengine5 Version: 5.7.1+dfsg-4 Severity: normal Hello, please be gentle as this is my first bug report :) I'm excited that Qt WebEngine is being packaged, so I could use it with qutebrowser. It seems to work beautifully, except that H.264 video is not working. I've talked to the developer of qutebrowser and he said that qtwebengine might not be configured to use proprietary codecs (see: http://doc.qt.io/qt-5/qtwebengine-features.html#audio-and-video-codecs ) I know that multimedia codecs can be very hairy things in general, but I'm hoping that since H.264 is enabled in chromium, that the same can be done for Qt WebEngine. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (650, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libqt5webengine5 depends on: ii libc6 2.24-8 ii libqt5core5a [qtbase-abi-5-7-1] 5.7.1~20161021+dfsg-6 ii libqt5gui55.7.1~20161021+dfsg-6 ii libqt5qml5 [qtdeclarative-abi-5-7-0] 5.7.1-1 ii libqt5quick5 5.7.1-1 ii libqt5webchannel5 5.7.1-1 ii libqt5webengine-data 5.7.1+dfsg-4 ii libqt5webenginecore5 5.7.1+dfsg-4 ii libstdc++66.2.1-5 libqt5webengine5 recommends no packages. libqt5webengine5 suggests no packages. -- no debconf information
Bug#834750: Please test with Qt 5.7.1
On domingo, 8 de enero de 2017 14:57:58 ART Lisandro Damián Nicanor Pérez Meyer wrote: > On sábado, 7 de enero de 2017 16:06:43 ART Lisandro Damián Nicanor Pérez > Meyer wrote: > [snip] > > > Hi Vrishab! Please test if this bug is still happening with Qt 5.7.1 > > (current testing/sid). According to upstream this might have got solved > > already. > > Actually not, the supossed fiz it's on our repo but not in the archive yet. And now it is. Please test version 5.7.1+dfsg-3 currently in sid. I know we closed this bug with it, but I would really like you to double check. Thans in advance! -- "Los promotores del software privativo demonizan algo tan básico y ético como el hecho de compartir imponiendo términos como el de 'pirata'. Equiparan ayudar al prójimo con atacar barcos. Cuando me preguntan qué pienso de la piratería musical e informática digo que atacar barcos es muy malo y, que yo sepa, los piratas no usan computadoras.” Richard Stallman, 05/11/2008, anexo de la Cámara de Diputados, Argentina 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#846389: plasma-workspace: random plasmashell freezes
Package: plasma-workspace Version: 4:5.8.4-1 Bug: #846389 Today was released xserver 1.19.1. So I have reinstalled xserver-xorg-core 2:1.19.0-3 and verified the return of the problem. Subsequently I have compiled new source and reinstalled it on existing packages. After logout and relogin I have tested my system and... no problem! Then I Restored previous version 2:1.18.4-2, I will wait new version provided by the distro. Thanks
