Bug#948274: KDE/Plasma version numbers in dependencies too lax
Package: kde-full Version: 5:104 Severity: important Dear Maintainer, this bug report was originally intended to be a reply on #907301 [1], #907416 [2], and #907696 [3], but those are already archived. Bernhard Übelacker wrote: > I hope closing this three bugs is ok, since this was just > a temporary situation and resolved by plasma-framework > migrating to testing several months ago. Although the bug was made visible only by a temporary situation, the actual (reason for the) bug still persists. I also stumbled over this bug recently (and I guess not the first time) because I have not used "apt upgrade" or "apt full-upgrade", but instead I have upgraded the single package kde-full. (That's why I file the bug report on kde-full, but the actual bug is distributed over several packages.) I ended up in a totally broken KDE environment. Luckily I found the bug reports mentioned above, and, even more luckily, most KDE/Plasma libraries/programs share the same version numbers. So I solved most[4] of the broken KDE upgrade by launching aptitude and upgrading all packages with these version numbers. However, my point is: the version numbers in the dependencies are wrong. They possibly are not wrong in the meaning that it would not *compile*, but they are wrong in the meaning that it does not *run correctly*. If (for some reasons I don't understand) the version numbers cannot be fixed in the Depends relationship, can they at least be correct (in case of doubt simply >= the matching version number) in the Recommends relationship? Thank you. Stephan References and Footnotes. 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907301 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907416 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907696 4. Some desktop effects like animations when changing the virtual desktop still do not work. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kde-full depends on: ii kde-plasma-desktop 5:104 ii kde-standard 5:104 ii kdeadmin 4:17.08.3+5.102 ii kdeedu 4:17.08.3+5.104 ii kdegames 4:17.08.3+5.102 ii kdegraphics 4:17.08.3+5.104 ii kdemultimedia4:17.08.3+5.102 ii kdenetwork 4:17.08.3+5.104 ii kdepim 4:17.12.3+5.104 ii kdeutils 4:17.08.3+5.102 ii plasma-workspace-wallpapers 4:5.14.5-1 Versions of packages kde-full recommends: ii kdeaccessibility 4:17.08.3+5.102 ii kdesdk4:17.08.3+5.102 ii kdetoys 4:17.08.3+5.102 ii kdewebdev 4:17.08.3+5.102 Versions of packages kde-full suggests: pn calligra ii xorg 1:7.7+19 -- no debconf information
Bug#691406: some KDE programs take very long to start
Package: kde-standard Version: 5:77 Severity: important Hi, I have installed yesterday's Debian testing nightly build ISO for amd64. KDE works but takes very long to start up. Other KDE programs have the same problem whereas e.g. firefox or icedove work just well. I have also described the problem in bug #691366 [1] against the pseudo-package "installation-report". 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691366 In the meantime I upgraded some packages to unstable. KDE tools that come up immediately are: - kdm - konsole (with two identical D-Bus warning messages: QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.) - kdialog - konqueror (now, after upgrading to unstable ... somehow this does not make sense, perhaps it is caused by some cached library or something...) - kaddressbook (with the two D-Bus warning messages) - kcalc - kfind - kfontview (with 2 D-Bus warning messages) - kinfocenter - kmail (with 2 D-Bus warning messages) - knotes (with 2 D-Bus warning messages) - krunner (with 2 D-Bus warning messages, but the first run in one KDE session takes some seconds, too) KDE tools that take minutes to start: - KDE startup itself (4 minutes!) - k3b (the splash screen comes after the mentioned D-Bus warning messages, but it gets stuck at "Creating GUI...") - konqueror (yesterday, a fresh testing installation) - dolphin - kate (with D-Bus warning message but only one) - kopete (with 2 D-Bus warning messages, an empty window comes up immediately but then it gets stuck) - korganizer - kwrite - the logout dialog of KDE I have compared the dependencies of those packages. When I exclude konqueror and kmail, possible candidates for causing the startup delay turn out to be: - libkde3support4 - libqt4-qt3support - libphonon4 or phonon Since phonon is used for mixing audio, I have to mention that the standard Debian installation runs PulseAudio. However, stopping the PulseAudio service did not help. Hence I suspect the other two libraries being the bad guys (I may be totally wrong though). Best Stephan -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-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 Versions of packages kde-standard depends on: ii akregator 4:4.4.11.1+l10n-3+b1 ii ark 4:4.8.4-2 ii dragonplayer 4:4.8.4-2 ii gwenview 4:4.8.4-2 ii juk 4:4.8.4-2 ii kaddressbook 4:4.4.11.1+l10n-3+b1 ii kate 4:4.8.4-1 ii kcalc 4:4.8.4-2 ii kde-plasma-desktop5:77 ii kdeplasma-addons 4:4.8.4-1 ii khelpcenter4 4:4.8.4-1 ii kmail 4:4.4.11.1+l10n-3+b1 ii kmix 4:4.8.4-2 ii knotes4:4.4.11.1+l10n-3+b1 ii kopete4:4.8.4-1+b1 ii korganizer4:4.4.11.1+l10n-3+b1 ii kscreensaver 4:4.8.4-2 ii ksnapshot 4:4.8.4-1 ii kwalletmanager4:4.8.4-2 ii okular4:4.8.4-2 ii plasma-desktopthemes-artwork 4:4.8.4-2 ii polkit-kde-1 0.99.0-3 ii sweeper 4:4.8.4-1 Versions of packages kde-standard recommends: ii freespacenotifier4:4.8.4-4 ii konq-plugins 4:4.8.4-2 ii plasma-widget-networkmanagement 0.9.0.3-1 ii update-notifier-kde 1.2.4 Versions of packages kde-standard suggests: pn kde-l10n ii kde-plasma-desktop 5:77 pn kde-plasma-netbook pn skanlite -- no debconf information -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50890dfe.2000...@uni-jena.de
Bug#691406: some KDE programs take very long to start
On 10/25/2012 12:32 PM, Pino Toscano wrote: Hi, Alle giovedì 25 ottobre 2012, Stephan Beyer ha scritto: I have installed yesterday's Debian testing nightly build ISO for amd64. KDE works but takes very long to start up. Do you have "gamin" installed? If so, try to either uninstall it altogether, or replace it with "fam" (installing it will replace gamin), and see whether things change. No, I had neither gamin nor fam installed. However, I did an strace and I got the bug. The affected programs do some communication and hence needed localhost (127.0.0.1) to be up. The debian-installer or the ifupdown package did something wrong, perhaps f**ked up /etc/network/interfaces such that lo did not get up. An "ifup lo" fixed the problem and everything works fine now. However, the question may be asked if KDE programs should throw an error message if connection to localhost fails/timeouts. Should the bug be reassigned to debian-installer or ifupdown? Best Stephan -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508929d2.9050...@uni-jena.de
Bug#691406: some KDE programs take very long to start
Control: severity -1 wishlist Control: retitle -1 kde-standard: KDE should issue warning if connection to localhost fails Hi, On 10/25/2012 08:23 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > On Thu 25 Oct 2012 09:00:18 Stephan Beyer escribió: > [snip] >> Should the bug be reassigned to debian-installer or ifupdown? > > As long as you have the installations logs still available, you can reassign > it to the instaler. If you don't, you need to reproduce the bug and get the > log. I still have the logs in /var/log/installer but they won't help much. I think, when the (known) /etc/network/interfaces bugs are fixed, the loopback interface will always come up well and then KDE just works. However, the question is still open if KDE programs should handle the "oh, there was a timeout when connecting to 127.0.0.1!" case differently, like, for example, issuing a warning message telling the user that 127.0.0.1 is not reachable and therefore KDE is not guaranteed to work correctly. I think this is kind of a wishlist bug now (see BTS control lines). Perhaps reissuing as a whislist bug would have been cleaner, but now the reason should become more clear. I am sorry if I am doing anything wrong ;-) Best Stephan -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508a7ab4.7060...@uni-jena.de
