Bug#917161: pulseaudio: Pulseaudio takes longer to start than default systemd timeout (again)
Thanks for letting me know. I just checked and I do have 240-4 installed now for udev (and libudev1). So i timed a restart of pulseaudio through systemd again and this is the result: $ time systemctl --user restart pulseaudio.service real 0m1.660s user 0m0.003s sys 0m0.000s So it seems like it's no longer timing out (again). When I reported this, I had version 240-1 installed for udev. If you think that this confirms that this problem was caused by udev, I guess this can be closed. I'll remove my manual timeout again and let you know if it happens again. Thanks for your help again. On Friday, January 18, 2019, 7:10:21 PM GMT+1, Felipe Sateler wrote: On Sun, Dec 23, 2018 at 10:48 AM Riaas Mokiem wrote: Package: pulseaudio Version: 12.2-2 Severity: important Dear Maintainer, the problem previously reported in #910512 has appeared again. That bug went away by itself after a later system update. Now the problem has occurred again, again after a system update. However, during this system update pulseaudio itself was not updated so the problem seems to be related to how pulseaudio interacts with the system. The most noteworthy part of the update was the linux kernel upgrade from 4.18 to 4.19 and systemd from 239-15 to 240-1. Have you tried again with udev 240-4? This could be caused by a bug solved in udev 240-4. -- Saludos, Felipe Sateler
Bug#910512: pulseaudio: Pulseaudio takes longer to start than default systemd timeout
Package: pulseaudio Version: 12.2-2 Severity: grave Justification: renders package unusable Dear Maintainer, Pulseaudio is taking longer to start up than the default 90 seconds that systemd allows for a service. This means that Pulseaudio does not work on startup and no matter how much you try to restart it (through systemd), it won't start up correctly. Not sure if this is the cause, but this happened after a recent upgrade that removed consolekit and upgraded the linux kernel from 4.18.0-1 to 4.18.0-2 I changed the timeout of pulseaudio.service to 5 minutes which allowed Pulseaudio sufficient time to start up correctly. I have pretty decent hardware though, so I would have expected the default timeout for Pulseaudio to be more than sufficient. It has been sufficient on this hardware until now. I'm not sure what's relevant for Pulseaudio, but my system uses the motherboard's onboard sound chip (Realtek ALC S1220A) on an AMD Ryzen system. I'm not sure why Pulseaudio is suddenly taking so much longer to start (or maybe systemd shortened the default timeout). But it's worth noting that for some reason I still had HDMI audio output, even with pulseaudio timed out. This is something that actually hadn't worked before and I haven't really tested it since the kernel with amdgpu dc has been available. Not sure if that's relevant. -- Package-specific info: File '/etc/default/pulseaudio' does not exist -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pulseaudio depends on: ii adduser 3.118 ii libasound2 1.1.6-1 ii libasound2-plugins 1.1.6-1+b1 ii libc62.27-6 ii libcap2 1:2.25-1.2 ii libdbus-1-3 1.12.10-1 ii libgcc1 1:8.2.0-7 ii libice6 2:1.0.9-2 ii libltdl7 2.4.6-4 ii liborc-0.4-0 1:0.4.28-3 ii libpulse012.2-2 ii libsm6 2:1.2.2-1+b3 ii libsndfile1 1.0.28-4 ii libsoxr0 0.1.2-3 ii libspeexdsp1 1.2~rc1.2-1+b2 ii libstdc++6 8.2.0-7 ii libsystemd0 239-10 ii libtdb1 1.3.16-1 ii libudev1 239-10 ii libwebrtc-audio-processing1 0.3-1 ii libx11-6 2:1.6.6-1 ii libx11-xcb1 2:1.6.6-1 ii libxcb1 1.13-3 ii libxtst6 2:1.2.3-1 ii lsb-base 9.20170808 ii pulseaudio-utils 12.2-2 Versions of packages pulseaudio recommends: ii dbus-user-session 1.12.10-1 ii libpam-systemd 239-10 ii rtkit 0.11-6 Versions of packages pulseaudio suggests: pn paman pn paprefs ii pavucontrol 3.0-4 pn pavumeter ii udev 239-10 -- Configuration Files: /etc/pulse/daemon.conf changed: ; daemonize = no ; fail = yes ; allow-module-loading = yes ; allow-exit = yes ; use-pid-file = yes ; system-instance = no ; local-server-type = user ; enable-shm = yes ; enable-memfd = yes ; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB ; lock-memory = no ; cpu-limit = no ; high-priority = yes ; nice-level = -11 ; realtime-scheduling = yes ; realtime-priority = 5 ; exit-idle-time = 20 ; scache-idle-time = 20 ; dl-search-path = (depends on architecture) ; load-default-script-file = yes ; default-script-file = /etc/pulse/default.pa ; log-target = auto ; log-level = notice ; log-meta = no ; log-time = no ; log-backtrace = 0 ; resample-method = speex-float-1 ; avoid-resampling = false ; enable-remixing = yes ; remixing-use-all-sink-channels = yes enable-lfe-remixing = yes lfe-crossover-freq = 120 flat-volumes = no ; rlimit-fsize = -1 ; rlimit-data = -1 ; rlimit-stack = -1 ; rlimit-core = -1 ; rlimit-as = -1 ; rlimit-rss = -1 ; rlimit-nproc = -1 ; rlimit-nofile = 256 ; rlimit-memlock = -1 ; rlimit-locks = -1 ; rlimit-sigpending = -1 ; rlimit-msgqueue = -1 ; rlimit-nice = 31 ; rlimit-rtprio = 9 ; rlimit-rttime = 20 ; default-sample-format = s16le ; default-sample-rate = 44100 ; alternate-sample-rate = 48000 default-sample-channels = 6 ; default-channel-map = front-left,front-right ; default-fragments = 4 ; default-fragment-size-msec = 25 ; enable-deferred-volume = yes ; deferred-volume-safety-margin-usec = 8000 ; deferred-volume-extra-delay-usec = 0 -- no debconf information # This file i
Bug#829425: libktorrent: Package version and package information outdated
Source: libktorrent Severity: important Dear Maintainer, it seems like the libktorrent version is not kept up-to-date. It is at v1.3.1, though v2.0.1 has been available since mid-April. This might be because the package doesn't seem to have a watch file. The latest version can be found here: http://download.kde.org/stable/ktorrent/5.0/ The watch file should be practically the same as the latest watch file for the ktorrent package so it might be easier to just copy and edit that one. Additionally, I noticed that the homepage URL still points to ktorrent.org. This is no longer the correct URL for KTorrent. You could use this URL as the homepage: https://www.kde.org/applications/internet/ktorrent/ Kind regards, Riaas -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/3 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)
Bug#819170: KDE packages not receiving updates
This bug seems to be holding up the updates to many KDE packages since they only see the latest unstable and not the latest stable from upstream. It's reported in #821187 for plasma-workspace but this seems to occur with practically all of the Plasma and Frameworks packages. So could this be fixed soon (or at least given a higher priority)?
Bug#821187: plasma-workspace: Problem searching for upstream version due to watch file
Package: plasma-workspace Severity: important Dear Maintainer, looking at the package tracker page, I noticed that there was a problem searching for upstream versions, probably because of the watch file. The watch file seems to contain 2 URLs, the first one for unstable, the second one for stable releases. The package tracker page seems to show that version 5.5.95 is the latest upstream, which is the latest package available from the unstable URL. However, the 5.6.0 (and 5.6.1 and 5.6.2) are already available from the stable URL, but these aren't recognized. Can the watch file be fixed so the latest stable versions are also recognized correctly? I think this may affect some other KDE packages as well. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/3 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)
Bug#788701: partitionmanager: Package does not receive updated versions from upstream
Package: partitionmanager Version: 1.0.3-2.1 Severity: important Dear Maintainer, * What led up to the situation? Using the KDE Partition Manager, I noticed that it was lacking many features that it should have * What exactly did you do (or not do) that was effective (or ineffective)? I tried to update my partitionmanager packages with the latest version * What was the outcome of this action? I could not update to a later version even though many newer versions have been released upstream for years * What outcome did you expect instead? I expect that I can update to the latest upstream version (or at least close to it) This problem seems to be two-fold: 1. The first part is related to #745290. It seems like there is a typo in the name used in the package description but also in the Debian SVN link (it says partionmanager instead of partitionmanager, note the missing "...it..." after "part..."). This means that the Debian SVN can't be reached for this package. I'm not that familiar with the Debian workflow, but I assume that this is necessary in order to receive updates. 2. The MAIN problem though, is that the Debian SVN seems to contain older code and isn't updated to the latest upstream code. Considering the fact that the Debian SVN is at v1.0.3, it seems like this is referring to the older SVN repository from upstream KDE which seems to stop at v1.0.3 (http://websvn.kde.org/tags/partitionmanager/). The newer git repository from upstream KDE is still being updated, with versions available up to v1.2.1 (http://quickgit.kde.org/?p=partitionmanager.git). So the Debian repository should probably be updated to refer to the newer git repository from upstream KDE in order to get those updated versions. I hope this can be resolved soon so we can receive more up-to-date versions from upstream. It should be noted that it is entirely possible that this problem (Debian referring to KDE SVN instead of git) occurs with other KDE packages as well. So it would probably be useful to check if this is indeed the case with other KDE packages. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/3 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 partitionmanager depends on: ii kde-runtime 4:4.14.2-2 ii libblkid1 2.26.2-2 ii libc6 2.19-18 ii libgcc1 1:5.1.1-5 ii libkdecore5 4:4.14.2-5 ii libkdeui5 4:4.14.2-5 ii libkio5 4:4.14.2-5 ii libparted-fs-resize0 3.2-7 ii libparted23.2-7 ii libqtcore44:4.8.6+git155-g716fbae+dfsg-2 ii libqtgui4 4:4.8.6+git155-g716fbae+dfsg-2 ii libstdc++65.1.1-5 ii libuuid1 2.26.2-2 partitionmanager recommends no packages. Versions of packages partitionmanager suggests: ii dosfstools 3.0.27-1 pn hfsplus pn hfsutils pn jfsutils pn ntfsprogs pn reiser4progs pn reiserfsprogs pn xfsprogs -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704457: gd extension broken due new embedded libgd functions not added to gd_compat layer
I also had this problem, so I was happy to see it was already fixed. Though i noticed on php.net that another php beta release should be available in a few days, I was hoping that this an interim version (5.5.0~beta2-2 perhaps?) could be uploaded already, because the owncloud 5.0.3 package was uploaded yesterday and it seems to require gd to work. So this is no longer a matter of merely having persistent error notifications. If this is not possible, I will just have to wait a little while longer (it's all from experimental anyway, so it's to be expected). It might still be useful to communicate this to the owncloud maintainers though.
