Bug#993011: pulseaudio-module-bluetooth: no longer detects bluetooth headphones
Control: tags -1 moreinfo On Thu, Aug 26, 2021 at 6:27 AM Vincent Lefevre wrote: > On 2021-08-26 12:08:03 +0200, Vincent Lefevre wrote: > > Package: pulseaudio-module-bluetooth > > Version: 15.0+dfsg1-2 > > Severity: grave > > Justification: renders package unusable > > > > After the upgrade to 15.0+dfsg1-2, pulseaudio no longer detects > > my bluetooth headphones when I switch them on. > > Reverting to the stable version (14.2-2) allows them to be detected > again. > Could you attach verbose logs of both a succesful and an unsuccesful run? https://fedoraproject.org/wiki/How_to_debug_PulseAudio_problems -- Saludos, Felipe Sateler
Bug#989103: closed by Felipe Sateler (DMO is not supported)
Control: found -1 14.2-2 Control: fixed -1 14.99-1 Hi Michał! On Thu, Jul 29, 2021 at 9:27 AM Michał Mirosław wrote: > On Thu, Jul 29, 2021 at 12:57:03PM +, Debian Bug Tracking System wrote: > > Date: Thu, 29 Jul 2021 08:51:50 -0400 > > From: Felipe Sateler > > To: 989103-d...@bugs.debian.org, 991337-d...@bugs.debian.org > > Subject: DMO is not supported > > > > deb-multimedia.org is not supported here. Please ask the maintainers of > > that repository for support. Closing the bug. > > The bug is in bullseye package. I'm not sure where deb-multimedia came > from? > (It's not enabled in my sources.list) > Sorry, I got confused by the last message from Keith Edmunds[1]. On a more detailed look, this is fixed in experimental but not on bullseye. Help with an update for bullseye would be appreciated. [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989103#53 -- Saludos, Felipe Sateler
Bug#989103: pulseaudio crashes on startup
Control: tags -1 unreproducible moreinfo On Tue, May 25, 2021 at 10:27 PM Michał Mirosław wrote: > Package: pulseaudio > Version: 14.2-2 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: mirq-debo...@rere.qmqm.pl > > After upgrade to bullseye, pulseaudio crashes on startup in > pa_alsa_sink_new() -> find_mixer() due to mapping==NULL. > You have this in your config: load-module module-alsa-sink device=hw:1,0 control=Wave Does it crash if you remove that line? -- Saludos, Felipe Sateler
Bug#982740: marked as pending in pulseaudio
Control: tag -1 pending Hello, Bug #982740 in pulseaudio reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/pulseaudio-team/pulseaudio/-/commit/d11d6825e023e818fde8bf1f664fdb98eec7f601 Fix test failure in ppc64el Thanks to Faidon Liambotis for the patch. Closes: #982740 (this message was generated automatically) -- Greetings https://bugs.debian.org/982740
Bug#964810: gimp: Unable to start gimp in debian unstable
After investigating further, I found the problematic package to be mesa-opencl-icd. After removing the package above, gimp works again.
Bug#960259: marked as pending in csound
Control: tag -1 pending Hello, Bug #960259 in csound reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/csound/-/commit/af28017c591518f530e6abcf8da74ecaebede8d6 Only call dh_doxygen for builds includin arch:all Otherwise we might not have doxygen installed Closes: #960259 (this message was generated automatically) -- Greetings https://bugs.debian.org/960259
Bug#960128: marked as pending in csound
Control: tag -1 pending Hello, Bug #960128 in csound reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/csound/-/commit/3b4a687bc70ea27e2f87f9b779e9f8e4edfb0761 Restore patch to ctcsound to import the SOVERSIONed library It was dropped by mistake when updating csound to 6.14 Closes: #960128 (this message was generated automatically) -- Greetings https://bugs.debian.org/960128
Bug#958577: Uploaded fix to delay/2
Thank you. Feel free to upload directly to unstable.
Saludos,
Felipe Sateler
On Fri, May 8, 2020, 04:57 Thomas Goirand wrote:
> Hi,
>
> Since nobody seem to care, I uploaded the fix to delay/2:
>
> --- a/debian/control
> +++ b/debian/control
> @@ -19,7 +19,7 @@
>
> Package: python3-docker
> Architecture: all
> -Depends: ${misc:Depends}, ${python3:Depends}
> +Depends: python3-distutils, ${misc:Depends}, ${python3:Depends}
> Description: Python 3 wrapper to access docker.io's control socket
> This package contains oodles of routines that aid in controlling
> docker.io over it's socket control, the same way the docker.io
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
Bug#956672: marked as pending in rtkit
Control: tag -1 pending Hello, Bug #956672 in rtkit reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/rtkit/-/commit/ded7abdfeb6ffce87ffea43111a5ebc78fb3b922 Fix systemd service install location Closes: #956672 (this message was generated automatically) -- Greetings https://bugs.debian.org/956672
Bug#946104: marked as pending in rtkit
Control: tag -1 pending Hello, Bug #946104 in rtkit reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/rtkit/-/commit/46ece9aa4dc416b7880310d7b0333ff360ba411a Mark installed-tests as having isolation-machine restriction Turns out that depending on the container manager, realtime operations might not be allowed. Thus, let's require a machine for it' Closes: #946104 (this message was generated automatically) -- Greetings https://bugs.debian.org/946104
Bug#955027: php-recode: uninstallable due to php7.4-recode dependency
Package: php-recode Version: 2:7.4+74 Severity: grave Justification: renders package unusable Dear Maintainer, The php-recode package is currently not installable because it depends on php7.4-recode, which doesn't exist. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages php-recode depends on: ii php-common 2:74 ii php7.3-recode 7.3.15-3 php-recode recommends no packages. php-recode suggests no packages. -- no debconf information
Bug#944711: Failed to set session cookie
Control: severity -1 important On Thu, Nov 14, 2019 at 5:36 AM Jörg Frings-Fürst wrote: > Package: phpmyadmin > Version: 4:4.9.1+dfsg1-2 > Severity: grave > Tags: upstream > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello, > > > I get on login > > [quote] > Failed to set session cookie. Maybe you are using HTTP instead of HTTPS to > access phpMyAdmin. > [/quote] > > Upstream has fix this issue: > > > https://github.com/phpmyadmin/phpmyadmin/pull/15273/files/45d46a6316c7a79d8c110ccbd18035c4d0c633fb > > I don't think this issue qualifies as release-critical. You really should not be using phpmyadmin over http, and nstead have your http server redirect to https. I'm thus downgrading. William, is the entire PR required, or just a section of it? -- Saludos, Felipe Sateler
Bug#933268: closed by Josue Ortega (Bug#933268: fixed in rpcbind 1.2.5-5)
On Tue, Aug 6, 2019 at 3:15 AM Michael Biebl wrote: > Am 06.08.19 um 04:48 schrieb Debian Bug Tracking System: > > rpcbind (1.2.5-5) unstable; urgency=medium > > . > >* debian/rules: Add --no-restart-after-upgrade option to > > dh_installsystemd to avoid race condition at rpcbind.socket > > initialization (Closes: #933268) > > > https://salsa.debian.org/debian/rpcbind/commit/6bdd9256f811ed312173eeb9e9ca7f600720769b > > I don't think this is a proper fix. After all, you typically want a > daemon to be restarted after upgrades so (security) fixes are applied. > I also notice, that the above commit contains other (unrelated) changes > which are not mentioned in the changelog. > > > A quick test shows, that debhelper creates the following code and > executing that manually triggers the same error: > > # systemctl restart rpcbind.service rpcbind.socket > > Job for rpcbind.socket failed. > See "systemctl status rpcbind.socket" and "journalctl -xe" for details. > A dependency job for rpcbind.service failed. See 'journalctl -xe' for > details. > > This needs further investigation, where the underlying problem is. > For the time being, I would suggest a different workaround, ie. > restarting rpcbind.service and rpcbind.socket sequentially (or only > rpcbind.service, I think that should be sufficient) > > > So somehting like this: > override_dh_installsystemd: >  dh_installsystemd rpcbind.socket > dh_installsystemd rpcbind.service > > > I'm not yet sure if this is a bug in systemd itself, in rpcbind or > debhelper for generating such a code sequence, so CCing all affected > parties. > The idea was to let systemctl/systemd order the jobs in whatever way it saw fit, according to the ordering requirements of the units. If there is a bug somewhere, it is either in systemd, or in rpcbind where an ordering requirement is missing. Does the problem persist if you add After=rpcbind.socket to rpcbind.service? -- Saludos, Felipe Sateler
Bug#923203: pulseaudio: fails to start without manual configuration
Control: severity -1 normal On Fri, Jun 21, 2019 at 4:57 PM Adam Borowski wrote: > Control: severity -1 grave > I don't think this issue is RC. However, I'm not interested in playing severity ping pong. Please involve the release team if you think the severity should be grave, and an update for this issue would be allowed. > Control: tags -1 +patch > > (patch is > https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/5) > > On Fri, Jun 21, 2019 at 11:37:48AM +0200, Tobias Hansen wrote: > > I just updated by system from stretch to buster and after that there was > no sound in GNOME because pulseaudio was not started. > > It can be easily worked around by setting "autospawn = yes" in > ~/.config/pulse/client.conf but it's quite an annoying regression. > > > > Can this still be fixed for buster? Can we make it an RC bug? > > It should have been tagged a long time ago, but I believe that's a good > idea. The bug is severe -- makes the package effectively useless for a > good > part of users (those on any inits other than systemd), has a pending fix, > and the fix has went through maintainer's review with no comments since 3 > weeks ago. > Sorry about that, I interpreted "haven't tested beyond a simple install yet" as implying you would ping back once the testing had been done. Reviewed again, it has a few issues (but mostly ok). I'd like long term to revert the order: disable autospawn by default, and have non-systemd run something to enable it. Honestly, I'm a bit annoyed about all this rushing. This behaviour has been present since 2017, and all of a sudden this is unacceptable and needs to be fixed less than a month before release. -- Saludos, Felipe Sateler
Bug#923674: systemd: FTBFS (failing tests)
Control: severity -1 important. Resetting severity because this is not a problem in buildds, nor on my own laptop. On Sun, Mar 3, 2019 at 1:21 PM Santiago Vila wrote: > > Package: src:systemd > Version: 240-2 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > I tried to build this package in sid but it failed: > > The above is just how the build ends and not necessarily the most relevant > part. > > I was able to build this package on buster just fine until version 239-15. > Starting with version 240-2 it always fail for me. > > I'm using sbuild + schroot. I've tried so far: > > Self-hosted KVM machines with one CPU and 6 GB of RAM. > 1-XS instances from Scaleway with one CPU and 1GB of RAM. > 1-S instances from Scaleway with *two* CPUs and 2GB of RAM: > n1-standard-1 instances from GCE with one CPU and 3.75 GB of RAM. > > You will see there is not a pattern here at all. Neither the amount of > RAM or the number of CPUs seem to have any relation with the failure. > (While monitoring RAM usage, I've never seen systemd build to require > more than 500 MB to build anyway). > > It is possible that the package now requires an extraordinary amount > of bogomips to build? I checked a couple and they both fail on test-stat-util. Any chance you could get a backtrace of the failing test? My guess is that sbuild setups something in /dev in a way that test-stat-util is not liking. What is your sbuild setup? It's not failing for me with sbuild either. -- Saludos, Felipe Sateler
Bug#919231: Salt-master unable to access directories
Control: found -1 241-5 Control: tags -1 confirmed upstream Control: forwarded -1 https://github.com/systemd/systemd/issues/11842 I was able to reproduce the issue, and forwarded this upstream. -- Saludos, Felipe Sateler
Bug#922350: udevd does not start after reboot
Control: severity -1 important Control: retitle -1 udev: can't start when architecture != systemd On Fri, Feb 15, 2019 at 4:19 AM Vincent Danjean wrote: > Le 15/02/2019 à 08:01, Vincent Danjean a écrit : > > Le 14/02/2019 à 22:59, Felipe Sateler a écrit : > >> Is udev by any chance i386 instead of amd64? > > > > I don't think so: > > vdanjean@eyak:~$ apt-cache policy udev:i386 > > udev:i386: > > Installé : (aucun) > > However, systemd was installed as i386: > vdanjean@eyak:~$ apt-cache policy systemd:i386 > systemd:i386: > Installé : 240-5 > Candidat : 240-5 > Table de version : > *** 240-5 500 > 500 http://ftp.fr.debian.org/debian testing/main i386 Packages > 500 http://ftp.fr.debian.org/debian unstable/main i386 Packages > 100 /var/lib/dpkg/status > 239-12~bpo9+1 100 > 100 http://ftp.fr.debian.org/debian stretch-backports/main i386 > Packages > 232-25+deb9u8 500 > 500 http://security.debian.org stretch/updates/main i386 Packages > 232-25+deb9u6 500 > 500 http://ftp.fr.debian.org/debian stretch/main i386 Packages > vdanjean@eyak:~$ apt-cache policy systemd:amd64 > systemd: > Installé : (aucun) > Candidat : 240-5 > Table de version : > 240-5 500 > 500 http://ftp.fr.debian.org/debian testing/main amd64 Packages > 500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages > 239-12~bpo9+1 100 > 100 http://ftp.fr.debian.org/debian stretch-backports/main amd64 > Packages > 232-25+deb9u8 500 > 500 http://security.debian.org stretch/updates/main amd64 Packages > 232-25+deb9u6 500 > 500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages > > It probably comes from the fact that: > 1) using apt-listbugs, I blocked the upgrade of systemd due to >919231 > 2) the upgrade fails due to another package. So I've to go with >'apt install -f' > 3) 'apt install -f' alone was removing packages I would like to keep >(such as digikam), so I forced some packages on the command line > 4) due to (1), apt probably solved some problem by selecting the >i386 version of systemd (I did not remark anything during the >installation) > > So, the severity can be lowered and I will test with a reboot > as soon as possible. > I'm downgrading the severity and retitling. -- Saludos, Felipe Sateler
Bug#922350: udevd does not start after reboot
rted with systemctl and also after > a reboot) > > I did not try to find the specific feature that was problematic > as I quickly needed the computer for (long) production. If you need > more info or tests, I should be able to reboot the system in a few > days. > > Regards, > Vincent > > -- Package-specific info: > > -- System Information: > Debian Release: buster/sid > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, > 'testing'), (500, 'stable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, armel, mipsel > Is udev by any chance i386 instead of amd64? -- Saludos, Felipe Sateler
Bug#918764: Bug #918764 in systemd marked as pending
Control: tag -1 pending Hello, Bug #918764 in systemd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/systemd-team/systemd/commit/617ee70c31c45ea5d5c6c7b30766d47f0b89446c udev: Backport upstream preventing mass killings when not running under systemd Closes: #918764 (this message was generated automatically) -- Greetings https://bugs.debian.org/918764
Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init
On Mon, Feb 4, 2019 at 11:34 AM Axel Beckert wrote: > Hi Felipe, > > Felipe Sateler wrote: > > Upstream asks if cgroup is in v2-mode in the affected systems. > > How do I recognize this? I have no idea of how to check that. > With `findmnt -R /sys/fs/cgroup`. It should list controllers in the cgroup or cgroup2 filesystems. -- Saludos, Felipe Sateler
Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init
On Sun, Feb 3, 2019 at 6:41 PM Felipe Sateler wrote: > Control: forwarded -1 https://github.com/systemd/systemd/issues/11645 > > I have forwarded the bug upstream, and proposed two solutions. If upstream > likes one, we can apply that in the debian package. > > Upstream asks if cgroup is in v2-mode in the affected systems. This might cause the detection logic to get tripped. If you can report back whether that is the case, preferably directly on the upsteam issue, it would be great. -- Saludos, Felipe Sateler
Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init
Control: forwarded -1 https://github.com/systemd/systemd/issues/11645 I have forwarded the bug upstream, and proposed two solutions. If upstream likes one, we can apply that in the debian package. Saludos
Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init
On Wed, Jan 30, 2019 at 7:47 PM Axel Beckert wrote: > Hi Felipe, > > a short reply with that information I can gather without much effort: > > Felipe Sateler wrote: > > > But we also had reports where this happend > > > with systemd, so this doesn't seem to be depend on the init system (at > > > most at the init system's default features) and hence also the package > > > cgroupfs-mount can't be held guilty for this. > > > > Can you point me at one? (sorry, I'm late to this bug and currently > ENOTIME > > to read the entire backlog). It seems this should not happen on systemd > > systems, because systemd properly isolates udev to its own cgroup when > > starting. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918764#122 Ah, thanks. That example is running with systemd as pid1, but not running udev as a systemd-managed daemon. This is good, because it means the diagnosis has not been refuted. -- Saludos, Felipe Sateler
Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init
On Tue, Jan 29, 2019 at 9:39 PM Axel Beckert wrote:
>
> Then I uninstalled not all of them at once but each of them one by
> one. And the one after whose purging
>
> # service udev restart
> # udevadm control --reload-rules
>
> didn't kill my processes anymore was cgroupfs-mount.
>
> So for some reason this killing only seems to happen on my box if
> cgroupfs-mount is installed. Then again, this is only necessary if
> systemd is not installed.
Thanks everyone for the detailed debugging. This appears to be the culprit:
udev tries to detect if running under systemd, and if so will kill its
entire cgroup (to cleanup leftover processes). Looks like cgroupfs-mount is
fooling udev into thinking it is running under systemd.
Could someone attach gdb to udev, break on the function `on_post`, trigger
the bug, and report what does `manager->cgroup` contain?
> But we also had reports where this happend
> with systemd, so this doesn't seem to be depend on the init system (at
> most at the init system's default features) and hence also the package
> cgroupfs-mount can't be held guilty for this.
>
Can you point me at one? (sorry, I'm late to this bug and currently ENOTIME
to read the entire backlog). It seems this should not happen on systemd
systems, because systemd properly isolates udev to its own cgroup when
starting.
>
> Which IMHO again leaves either src:systemd or src:linux as rc-buggy
> package.
>
I think something like this might be sufficient to work around the bug in
sysvinit systems:
% git diff
diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index fb8724ea87..a03b65a773 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -1814,7 +1814,7 @@ static int run(int argc, char *argv[]) {
dev_setup(NULL, UID_INVALID, GID_INVALID);
-if (getppid() == 1) {
+if (getppid() == 1 && sd_booted()) {
/* get our own cgroup, we regularly kill everything udev
has left behind
we only do this on systemd systems, and only if we are
directly spawned
by PID1. otherwise we are not guaranteed to have a
dedicated cgroup */
--
Saludos,
Felipe Sateler
Bug#919390: Bug #919390 in systemd marked as pending
Hi Martin, On Sun, Jan 27, 2019, 17:37 Martin Pitt Hello Felipe, > > Felipe Sateler [2019-01-26 0:04 +]: > > Bug #919390 in systemd reported by you has been fixed in the > > Git repository and is awaiting an upload. You can see the commit > > message below and you can check the diff of the fix at: > > > > > https://salsa.debian.org/systemd-team/systemd/commit/ca9bf5fdd69e1f6bb137d905f90225de7fc057e4 > > > > > > Pick patch proposed upstream to reduce journald memory usage > > > > Closes: #919390 > > This should have been #920018. I was about to do the cherry-picks, but I'm > really confused here. Where *did* your two commits land? They are clearly > not > on master, and there are no other (recent) branches. Even trying to show > the > SHA directly doesn't work (no such object). > > Did you force-unpush them? Or was this an unnamed branch somehow? Should I > pick > them from the salsa web UI and push them to master (and fixing the bug > number > while I'm at it), and upload? > I picked the patches, but before I uploaded I had to leave. I also accidentally pushed those picks to the wrong branch (adding salsa CI integration), and then unpushed them. I am not on my pc now so if you can upload the fixes that would be cool. Sorry about the confusion. We should probably restrict the notification hook to themaster branch. Saludos, Felipe Sateler
Bug#919390: Bug #919390 in systemd marked as pending
Control: tag -1 pending Hello, Bug #919390 in systemd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/systemd-team/systemd/commit/ca9bf5fdd69e1f6bb137d905f90225de7fc057e4 Pick patch proposed upstream to reduce journald memory usage Closes: #919390 (this message was generated automatically) -- Greetings https://bugs.debian.org/919390
Bug#919390: Bug #919390 in systemd marked as pending
Control: tag -1 pending Hello, Bug #919390 in systemd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/systemd-team/systemd/commit/3eea472b0c1c171f86c0cf5c6f47884077ab3da3 Backport upstream patch reverting interface renaming changes. Closes: #919390 (this message was generated automatically) -- Greetings https://bugs.debian.org/919390
Bug#869896: Bug#909974: backports.ssl-match-hostname should be removed for buster
Control: severity 909974 important On Fri, Jan 11, 2019 at 10:15 AM Felipe Sateler wrote: > > > On Tue, Oct 2, 2018 at 4:22 PM Felipe Sateler wrote: > >> Hi Matthias, Ivo, >> >> On Sun, 30 Sep 2018 22:59:26 +0200 Ivo De Decker >> wrote: >> > clone 869896 -1 >> > retitle -1 remove unneeded dependency on backports.ssl-match-hostname >> > block 869896 by -1 >> > clone -1 -2 -3 -4 -5 >> > reassign -1 libcloud >> > reassign -2 python-docker >> > reassign -3 websocket-client >> > reassign -4 docker-compose >> > reassign -5 sagemath >> > thanks >> > > Turns out the version of match_hostname in py2 does not accept ip > addresses: > > py2: > ssl.match_hostname = match_hostname(cert, hostname) > Verify that *cert* (in decoded format as returned by > SSLSocket.getpeercert()) matches the *hostname*. RFC 2818 and RFC 6125 > rules are followed, but IP addresses are not accepted for *hostname*. > > CertificateError is raised on failure. On success, the function > returns nothing. > > py3 > ssl.match_hostname = match_hostname(cert, hostname) > Verify that *cert* (in decoded format as returned by > SSLSocket.getpeercert()) matches the *hostname*. RFC 2818 and RFC 6125 > rules are followed. > > The function matches IP addresses rather than dNSNames if hostname is a > valid ipaddress string. IPv4 addresses are supported on all platforms. > IPv6 addresses are supported on platforms with IPv6 support (AF_INET6 > and inet_pton). > > CertificateError is raised on failure. On success, the function > returns nothing. > > So, if python2 backport of match_hostname does not match behavior of > python3.5, I cannot drop the dependency. I have reverted the change and > reopened this bug. > > I urge you to reconsider if the py2 version really needs to be dropped. > > I'm downgrading severity to prevent autoremoval. I don't think ssl-match-hostname can be dropped from buster. -- Saludos, Felipe Sateler
Bug#919213: irqbalance: endless loop during configure, system reaches maximum of open files
On Sun, 13 Jan 2019 18:10:57 +0100 Axel Beckert wrote: > Package: irqbalance > Version: 1.5.0-2 > Severity: serious > > On one of my systems (not the one I'm writing the report on), a > Raspberry Pi 2 with Debian Sid armhf and sysvinit, the terminal which I > ran the upgrade in, looked like this (excerpt): > > Synchronizing state for irqbalance.service with sysvinit using update-rc.d... > Executing /usr/sbin/update-rc.d irqbalance defaults > Executing /usr/sbin/update-rc.d irqbalance enable > Synchronizing state for irqbalance.service with sysvinit using update-rc.d... > Executing /usr/sbin/update-rc.d irqbalance defaults > Executing /usr/sbin/update-rc.d irqbalance enable > Synchronizing state for irqbalance.service with sysvinit using update-rc.d... What are the versions of init-system-helpers and systemd? Since version 1.56, we use systemctl to enable links (which seems the case with your log), but for some reason SYSTEMCTL_SKIP_SYSV environment variable appears to not be respected. Saludos
Bug#917199: pivy, unbuildable on mips* due to testsuite failures in patchelf.
On Mon, Jan 14, 2019 at 6:30 AM Raphael Hertzog wrote: > Hi, > > On Sun, 13 Jan 2019, Adrian Bunk wrote: > > Test cases that passed in patchelf 0.8 fail since 0.9, > > and segmentation fault on things like setting rpath > > might be close enough to "entirely broken". > > In that case, it would certainly help upstream if someone > (maintainer/porter) could try to "git bisect" the issue so that we can > better identify the issue. > > And maybe we want to revert to the former patchelf in Debian > (i.e. 0.9+really0.8) if it lasts too long. > The failing tests in 0.9 are new, in that the test is not the same as in 0.8. As I commented in the arch-RM bug, I don't think this is a regression (but I haven't checked at all). James Cowgill mentioned a change in glibc as the possible cause[1]. One way to test would be to run the test from 0.9 with the binary from 0.8. That said, I certainly welcome help. I'm completely overloaded right now so I can't look at this. [1] Thread at https://lists.debian.org/debian-mips/2016/04/msg4.html -- Saludos, Felipe Sateler
Bug#909974: backports.ssl-match-hostname should be removed for buster
On Tue, Oct 2, 2018 at 4:22 PM Felipe Sateler wrote: > Hi Matthias, Ivo, > > On Sun, 30 Sep 2018 22:59:26 +0200 Ivo De Decker wrote: > > clone 869896 -1 > > retitle -1 remove unneeded dependency on backports.ssl-match-hostname > > block 869896 by -1 > > clone -1 -2 -3 -4 -5 > > reassign -1 libcloud > > reassign -2 python-docker > > reassign -3 websocket-client > > reassign -4 docker-compose > > reassign -5 sagemath > > thanks > Turns out the version of match_hostname in py2 does not accept ip addresses: py2: ssl.match_hostname = match_hostname(cert, hostname) Verify that *cert* (in decoded format as returned by SSLSocket.getpeercert()) matches the *hostname*. RFC 2818 and RFC 6125 rules are followed, but IP addresses are not accepted for *hostname*. CertificateError is raised on failure. On success, the function returns nothing. py3 ssl.match_hostname = match_hostname(cert, hostname) Verify that *cert* (in decoded format as returned by SSLSocket.getpeercert()) matches the *hostname*. RFC 2818 and RFC 6125 rules are followed. The function matches IP addresses rather than dNSNames if hostname is a valid ipaddress string. IPv4 addresses are supported on all platforms. IPv6 addresses are supported on platforms with IPv6 support (AF_INET6 and inet_pton). CertificateError is raised on failure. On success, the function returns nothing. So, if python2 backport of match_hostname does not match behavior of python3.5, I cannot drop the dependency. I have reverted the change and reopened this bug. I urge you to reconsider if the py2 version really needs to be dropped. -- Saludos, Felipe Sateler
Bug#916764: znc-backlog: overly strict dependency on znc?
On Fri, Dec 28, 2018 at 10:33 AM Patrick Matthäi wrote: > Hola, > Am 24.12.2018 um 12:44 schrieb Felipe Sateler: > > > Perhaps znc could Provide: znc-plugin-$somenumber, which could be used by > >> > out-of-tree plugins? Adding the znc maintainers to the loop for their >> input >> >> That's being used successfully by some packages ... >> > > I'm creating a new bug for tracking this (better) solution. > > > I dont know how this would help now after the relaxed dependency from > znc-backlog, because..: > > * on changes znc-backlog still needs a binNMU or code changes, like now > Right. But the current solution is still suboptimal. For example, if you upload a new package changing only metadata (say, the Vcs-* fields), znc-backlog would need a binNMU. In the more general case, a new upstream version of znc might not break the plugin ABI. > * I can provide a znc-plugin-$foobar package, but who ensures at an non > stable api, if a change is necessary or not? I think it will make it more > complicated or is there a nice solution for it? > Indeed, this implies a lot more work for you. -- Saludos, Felipe Sateler
Bug#916764: znc-backlog: overly strict dependency on znc?
Control: clone -1 -2
Control: reopen -2
Control: reassign -2 znc
Control: affects -2 znc-backlog
Control: retitle -2 znc: please provide a znc-plugin-$version that external
plugins can depend on
On Tue, Dec 18, 2018 at 3:39 PM Andreas Beckmann wrote:
> On 2018-12-18 18:13, Felipe Sateler wrote:
> > Hi,
> > On Tue, Dec 18, 2018 at 8:33 AM Andreas Beckmann
> wrote:
> >
> >> Package: znc-backlog
> >> Version: 0.20170713-1
> >> Severity: serious
> >>
> >
> > Hmm, not sure this is warranted.
>
> It's currently uninstallable in sid.
> Instead of requesting a binNMU (and doing so everytime znc changes), I
> asked this question here.
>
Well, just like libraries need transitions, applications having plugin APIs
need transitions too.
Anyway, I've relaxed the dependency as advised by
https://wiki.debian.org/binNMU
> >> do you really need a dependency on the exact binary version of znc
> >> available at the build time of znc-backlog? I.e., every time znc
> >> gets uploaded *or binNMUed*, a binNMU of znc-backlog is needed, too.
> >> Wouldn't a dependency computed from the upstream version be sufficient?
> >> E.g. znc (>= ${znc:upstreamversion}), znc (<< ${znc:upstreamversion}+)
> >>
> >>
> > I'm using the same as the znc plugins shipped by znc itself. AFAIK, the
> znc
> > ABI is not stable, so backporting an upstream patch could potentially
> break
> > other plugins.
>
> But that's unlikely to happen on binNMUs, isn't it?
>
If znc needs rebuilding, the plugins might need too, wouldn't they?
> > Perhaps znc could Provide: znc-plugin-$somenumber, which could be used by
> > out-of-tree plugins? Adding the znc maintainers to the loop for their
> input
>
> That's being used successfully by some packages ...
>
I'm creating a new bug for tracking this (better) solution.
--
Saludos,
Felipe Sateler
Bug#916764: znc-backlog: overly strict dependency on znc?
Hi,
On Tue, Dec 18, 2018 at 8:33 AM Andreas Beckmann wrote:
> Package: znc-backlog
> Version: 0.20170713-1
> Severity: serious
>
Hmm, not sure this is warranted.
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> do you really need a dependency on the exact binary version of znc
> available at the build time of znc-backlog? I.e., every time znc
> gets uploaded *or binNMUed*, a binNMU of znc-backlog is needed, too.
> Wouldn't a dependency computed from the upstream version be sufficient?
> E.g. znc (>= ${znc:upstreamversion}), znc (<< ${znc:upstreamversion}+)
>
>
I'm using the same as the znc plugins shipped by znc itself. AFAIK, the znc
ABI is not stable, so backporting an upstream patch could potentially break
other plugins.
Perhaps znc could Provide: znc-plugin-$somenumber, which could be used by
out-of-tree plugins? Adding the znc maintainers to the loop for their input
--
Saludos,
Felipe Sateler
Bug#913620: Happened before in #905187
Hi Ondrej, On Wed, Nov 14, 2018 at 11:42 AM Ondřej Surý wrote: > The previous fix was not a real fix, it only rebuilt the package in a > non-merged environment. > > > Umm, what? > > > https://salsa.debian.org/php-team/php/blob/master-7.3/debian/patches/0048-Don-t-use-sed-found-by-configure-use-the-sed-command.patch > I meant the fix for #905187, and based on the changelog entry. Anyway, I see you have already tagged an upload containing that commit. Let's just wait for it to enter unstable. Thanks! -- Saludos, Felipe Sateler
Bug#913620: Happened before in #905187
On Wed, Nov 14, 2018 at 11:01 AM Michael Biebl wrote:
> Hi Felipe
>
> On Wed, 14 Nov 2018 10:42:55 -0300 Felipe Sateler
> wrote:
> > + SED=/bin/sed dh_auto_configure --builddirectory $${target}-build
> $(PARALLEL) -- $$(eval echo \$${$${target}_config}); \
>
> Reading
>
> https://stackoverflow.com/questions/13848154/passing-environment-variables-to-autoconfs-configure
> it appears to me that setting SED=/bin/sed as an argument to
> configure/dh_auto_auto_configure is preferred over passing as env var.
>
Thanks. Please find an attached patch. However, I don't think this makes a
practical difference for debian packages, since they run configure only
once per builddir.
--
Saludos,
Felipe Sateler
From ed1b5bb488c9b9b026e27bf273f668fe825ca9fe Mon Sep 17 00:00:00 2001
From: Felipe Sateler
Date: Wed, 14 Nov 2018 10:36:47 -0300
Subject: [PATCH] Always use /bin/sed as sed command
Autodetection by configure script might find /usr/bin/sed in systems where
/ has been merged with /usr, which then doesn't work on non-merged systems.
Closes: #913228
---
debian/rules | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index c32856580..f953c2cb8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -206,7 +206,8 @@ COMMON_CONFIG := \
--with-zlib-dir=/usr \
$(CONFIGURE_ZTS) \
$(CONFIGURE_DTRACE_ARGS) \
- $(CONFIGURE_PCRE_JIT)
+ $(CONFIGURE_PCRE_JIT) \
+ SED=/bin/sed
# disable all SAPIs in extension build
export ext_config = \
--
2.19.1
Bug#913620: Happened before in #905187
Control: tags -1 patch
Control: user m...@linux.it
Control: usertags -1 usrmerge
On Tue, 13 Nov 2018 01:27:41 -0800 Kunal Mehta
wrote:
> This is the same regression as #905187 - is there a good way we can
> prevent this from happening again?
The previous fix was not a real fix, it only rebuilt the package in a
non-merged environment. Please find attached a patch that sets SED to a
known-good value, thus making the build work for both merged and non-merged
systems.
Saludos,
Felipe Sateler
From 1b4df9e00b2093cd688f2d4d455912c8da48494e Mon Sep 17 00:00:00 2001
From: Felipe Sateler
Date: Wed, 14 Nov 2018 10:36:47 -0300
Subject: [PATCH] Always use /bin/sed as sed command
Autodetection by configure script might find /usr/bin/sed in systems where
/ has been merged with /usr, which then doesn't work on non-merged systems.
Closes: #913228
---
debian/rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index c32856580..932c23ffd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -333,7 +333,7 @@ override_dh_auto_configure-indep:
override_dh_auto_configure-arch: prepared
for target in $(TARGETS); do \
- dh_auto_configure --builddirectory $${target}-build $(PARALLEL) -- $$(eval echo \$${$${target}_config}); \
+ SED=/bin/sed dh_auto_configure --builddirectory $${target}-build $(PARALLEL) -- $$(eval echo \$${$${target}_config}); \
done
override_dh_auto_build-indep:
--
2.19.1
Bug#913133: Acknowledgement (pulseaudio crashes (SIGSEGV) after failing to set 48000 sample rate in pcm_a52.c)
Control: reassign -1 libasound2 Control: found -1 1.1.7-1 On Sat, Nov 10, 2018 at 2:48 AM ewe2 wrote: > Hi, > > I just wanted to add that I'd been having this issue too and rolling > back libasound2 altogether, not just the plugins packages was > required. With the plugins packages rolled back I stopped having > segv's but the bigger issue was that nothing in a dbus session could > see the changes; alsa could see all devices yet pulseaudio was unable > to find or connect to anything but a secondary usb interface, indeed > it seemed to be trying to open non-existent devices under /dev/snd/. I > also rolled back the kernel upgrade just in case and rebooted and took > care to check with alsactl init and store. Only then did I recover > access to my internal sound card. I'm also wondering whether a recent > udisks2 upgrade may have also contributed, but it's very difficult to > pin down where exactly the breakdown is, I don't think it's pulseaudio > itself, it's what it depends on. > Based on this information I'm reassigning to the alsa library. -- Saludos, Felipe Sateler
Bug#913133: Acknowledgement (pulseaudio crashes (SIGSEGV) after failing to set 48000 sample rate in pcm_a52.c)
On Thu, Nov 8, 2018 at 3:57 AM Haworth, David wrote: > Here's the gdb backtrace from pulseaudio -vvv (the last few lines of the > verbose output are at the top) Looks like the crash is happening inside libasound2-plugins. Does the crash go away if you downgrade that back to version 1.1.6-1? -- Saludos, Felipe Sateler
Bug#913133: pulseaudio crashes (SIGSEGV) after failing to set 48000 sample rate in pcm_a52.c
Control: tags -1 moreinfo On Wed, Nov 7, 2018 at 8:16 AM David Haworth wrote: > Package: pulseaudio > Version: 12.2-2 > Severity: grave > Justification: renders package unusable > Dear Maintainer, > >* What led up to the situation? > update/dist-upgrade of debian unstable on 2018-11-06. The problem first > showed itself when I > started my machine the next day. > >* What exactly did you do (or not do) that was effective (or > ineffective)? > I first noticed that I had no sound (in firefox). Further investigation > showed that pulseaudio wasn't running. > So I attempted to run it from the command line. > >* What was the outcome of this action? > A segmentation violation (SIGSEGV) > >* What outcome did you expect instead? > pulsaudio should continue running and allow connections from other programs > > Further information: > * "strace pulseaudio" didn't provide any useful information. > * "pulseaudio -vvv" showed the last message before the crash was a failure > to set 48000 sample rate in pcm_a52.c > Could you please send the log output? Also, please install pulseaudio-dbgsym (you might need to add the debug archive to sources.list), and attach the backtrace of the fault. -- Saludos, Felipe Sateler
Bug#911164: gnome-genius: Depends on unmaintained gtksourceview2
On Tue, Oct 16, 2018 at 1:42 PM Jeremy Bicha wrote: > Package: gnome-genius > Version: 1.0.24-2 > Severity: serious > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: oldlibs gtksourceview2 > Tags: sid buster > > gnome-genius depends on gtksourceview2. The Debian GNOME team is > trying to remove gtksourceview2 from Debian. Please port to gtk3 and > gtksourceview4. Otherwise, I guess you can stop building gnome-genius. > > I apologize for not filing this bug sooner. I was only looking at > packages in Testing and this package was removed from Testing earlier > because of https://bugs.debian.org/790171 (which was fixed). > > Because of the late timing of this RC bug in the Buster cycle and > because there might be a few other packages that won't be ported in > time, please let me know if you object to gtksourceview2's removal > from Buster. > > While I sympathize with the desire to get rid of old libraries, I think this bug comes too late. This bug should have been filed before stretch was released if the target was buster. I object to the serious severity, at least for this release cycle. -- Saludos, Felipe Sateler
Bug#911363: RM: patchelf [mips mipsel] -- ANAIS; Does not work properly
Control: reassign -1 ftp.debian.org Control: retitle -1 RM: patchelf [mips mipsel] -- ANAIS; Does not work properly On Fri, Oct 19, 2018 at 3:39 AM Tobias Frost wrote: > Package: patchelf > Version: 0.9+52.20180509-1 > Severity: serious > Tags: ftbfs > > Dear maintainer, > > patchelf fails to build on the buildds [1] for mips64el, but previously > did. > Please note that this impairs migration of your dependencies, so it > would be great if an solution can be found, or maybe temporarily remove > the mips64el packages to have at least the other release archs. > Hmm. I wonder why does mips64el have an old binary. This is #821435, and I requested removal on #822211. Maybe mips64el was not an offical arch back then? Anyway, dear FTP master team, please RM patchelf from mips64el. -- Saludos, Felipe Sateler
Bug#901405: systemd-shim: Please add a sysvinit service to create directories on /run at boot
On Fri, Oct 19, 2018 at 10:45 AM Chris Ruvolo wrote: > > In particular, we patch some code to continue even if > > /run/systemd/machines/ and /run/systemd/machines/ don't exist[1][2]. > > Hi. Can you clarify the two directory names? I see the same one listed > twice. > Sorry, copy paste fail. The other directory is /run/systemd/seats/ . -- Saludos, Felipe Sateler
Bug#910512: pulseaudio: Pulseaudio takes longer to start than default systemd timeout
Control: severity -1 important Control: tags -1 moreinfo Hi, On Sun, Oct 7, 2018 at 11:21 AM Riaas Mokiem wrote: > Package: pulseaudio > Version: 12.2-2 > Severity: grave > Justification: renders package unusable > > Lowering severity since it does not appear to affect everyone. > 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. > Possibly. Could you attach a verbose log? $ systemctl --user --runtime edit pulseaudio Add the following lines to the file [Service] ExecStart=/usr/bin/pulseaudio --daemonize=no - Then restart pulseaudio, and get the log with `journalctl --user-unit pulseaudio --since "$when_you_restarted_pulseaudio"` -- Saludos, Felipe Sateler
Bug#909974: backports.ssl-match-hostname should be removed for buster
Hi Matthias, Ivo, On Sun, 30 Sep 2018 22:59:26 +0200 Ivo De Decker wrote: > clone 869896 -1 > retitle -1 remove unneeded dependency on backports.ssl-match-hostname > block 869896 by -1 > clone -1 -2 -3 -4 -5 > reassign -1 libcloud > reassign -2 python-docker > reassign -3 websocket-client > reassign -4 docker-compose > reassign -5 sagemath > thanks Next time, please CC the affected packages, otherwise it's easy to miss. > On Thu, Jul 27, 2017 at 03:10:33PM +0200, Matthias Klose wrote: > > The python3 and python2 versions already have that fix (and had it in stretch > > too). This package should be removed for the buster release. > > Making clones for the rdeps to track the removal there. Wouldn't it be better for python to Provide: python-backports.ssl-match-hostname (= 3.5.0.1-1) ? This would save the other packages from having to patch the (not wrong) upstream install scripts. Saludos
Bug#906504: Bug #906504 in pulseaudio marked as pending
Control: tag -1 pending Hello, Bug #906504 in pulseaudio reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/pulseaudio-team/pulseaudio/commit/0b8f91adb022d4baf6d6a7ae74e7edc48fdd214a Allow rounding without having to allow a random number of errors in tests/volume-test.c (Closes: #906504) (this message was generated automatically) -- Greetings https://bugs.debian.org/906504
Bug#903612: Bug #903612 in csound marked as pending
Control: tag -1 pending Hello, Bug #903612 in csound reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/csound/commit/5ea243bb7accd67700bebeaeb22e1cb819ff3cd5 Pick upstream patch to convert update to new-style atomic builtins Usage of __atomic_* builtins can be done even on platforms (like mipsel) without sufficient hardware instructions by linking in libatomic. Fixes a FTBFS on several archs. Closes: #903612 (this message was generated automatically) -- Greetings https://bugs.debian.org/903612
Bug#906504: Bug #906504 in pulseaudio marked as pending
Control: tag -1 pending Hello, Bug #906504 in pulseaudio reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/pulseaudio-team/pulseaudio/commit/84d1788830cdc246b33c31ac3f79a2297c95b452 Add patch to allow a higher deviation for volume-test.c Closes: #906504 (this message was generated automatically) -- Greetings https://bugs.debian.org/906504
Bug#904652: pulseaudio: looses device and replace it with dummy package so no sound possible
On Sat, Aug 11, 2018 at 9:54 AM Meinolf Gödde wrote: > The problem is back again. So i hope it helps. > The log file is empty :(. Anyway, are you using MATE? Another bug with the same symptoms seems to be caused by the mate volume manager (see bug #906622). Saludos -- Saludos, Felipe Sateler
Bug#907486: libpam-systemd: Depends: systemd-shim (>= 10-4~) but it is not going to be installed
Control: forcemerge 903295 -1 On Tue, Aug 28, 2018, 14:00 Robbie Harwood wrote: > Package: libpam-systemd > Version: 238-5 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > (This bug has been reported also against systemd-shim: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903295 ) > Merging with that report, since it is systemd-shim that needs fixing. There is no need to file additional reports. > libpam-systemd requires systemd-shim version >=10-4~. No such version > exists. > > This would make systemd-shim unusable. > Indeed. See bugs #901404 and #901405 for things that need to be fixed in 10-4. Systemd-shim is currently broken, and is not working in its current form. Saludos
Bug#903612: marked as done (csound FTBFS on !x86: test hang)
Control: reopen -1 Control: found -1 1:6.11.0~dfsg-2 Control: retitle -1 csound: tests hang when atomic builtins are unavailable On Thu, Aug 23, 2018 at 10:09 AM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > >* Unconditionally enable atomic builtins. > It was disabled in !x86 a long time ago for unclear reasons. > The lack of atomics causes a test exercising the async features to > hang > (Closes: #903612) > > Turns out mips and mipsel do not support the atomic builtins used by csound. Reopening the bug until a new solution is found. -- Saludos, Felipe Sateler
Bug#903612: Bug #903612 in csound marked as pending
Control: tag -1 pending Hello, Bug #903612 in csound reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/csound/commit/0bb1b184933425fc22f87a86c24a2a9a8c20a035 Unconditionally enable atomic builtins It was disabled a long time ago for unclear reasons. The lack of atomics causes a test exercising the async features to hang Closes: #903612 (this message was generated automatically) -- Greetings https://bugs.debian.org/903612
Bug#906421: invoke-rc.d: service not started from package postinst anymore
On Fri, Aug 17, 2018 at 10:59 AM Michael Biebl wrote: > Am 17.08.2018 um 15:45 schrieb Michael Biebl: > > Am 17.08.2018 um 15:37 schrieb Felipe Sateler: > > > >> Well, as long as we support the --skip-systemd-native, we can't drop the > >> check :/ > > > > I don't understand. > > I thought the idea was that dh_installsystemd would generate code to > > always pass --skip-systemd-native to invoke-rc.d? > > Nvm, I think you meant that we already have packages out there using > dh_installsystemd. Those would all need a rebuild (assuming we apply the > --skip-systemd-native check to compat 11, or a switch to compat 12, > assuming we tie that change to a compat bump) > Correct. So we could only remove this line in the very far future :/ -- Saludos, Felipe Sateler
Bug#906421: invoke-rc.d: service not started from package postinst anymore
On Fri, Aug 17, 2018 at 10:33 AM Michael Biebl wrote: > Am 17.08.2018 um 15:27 schrieb Felipe Sateler: > > I'll revert the change to unbreak things soon. For the longer term, > > maybe we can switch the check to > > > > /lib/systemd/systemd-sysv-install is-enabled $service > > I wouldn't bother introducing new code here and simply revert the change > to get the old code back, which we know works under the current > circumstances. > > Long term, i.e. after we have the dh_installsystemd fixes, we should be > able to simply use "systemctl is-enabled " again and drop the fallback > altogether. The fallback should not be needed then. > Well, as long as we support the --skip-systemd-native, we can't drop the check :/ Alternatively, debhelper could move dh_installsystemd before dh_installinit. Then the first would be a nop under sysvinit systems, and the second would be a nop in systemd systems. -- Saludos, Felipe Sateler
Bug#906421: invoke-rc.d: service not started from package postinst anymore
On Fri, Aug 17, 2018 at 10:24 AM Michael Biebl wrote: > Am 17.08.2018 um 15:13 schrieb Felipe Sateler: > > > Hmm. Commit 6f95680ffc9b1605841eb7d3d8eb92c790e6c73a looks like the > > culprit of the regression. But I'd like to understand why this happens. > > Shouldn't update-rc.d have enabled the service? > > The lldpad or corosync package ship a native systemd unit. > Looking at the generated postinst: > > > # Automatically added by dh_installinit/11.2.1 > > if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = > "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then > > if [ -x "/etc/init.d/corosync" ]; then > > update-rc.d corosync defaults >/dev/null > > if [ -n "$2" ]; then > > _dh_action=restart > > else > > _dh_action=start > > fi > > invoke-rc.d corosync $_dh_action || exit 1 > > fi > > fi > > # End automatically added section > > # Automatically added by dh_installsystemd/11.2.1 > > if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = > "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then > > # This will only remove masks created by d-s-h on package removal. > > deb-systemd-helper unmask 'corosync.service' >/dev/null || true > > > > # was-enabled defaults to true, so new installations run enable. > > if deb-systemd-helper --quiet was-enabled 'corosync.service'; then > > # Enables the unit on first installation, creates new > > # symlinks on upgrades if the unit file has changed. > > deb-systemd-helper enable 'corosync.service' >/dev/null || > true > > else > > # Update the statefile to add new symlinks (if any), which > need to be > > # cleaned up on purge. Also remove old symlinks. > > deb-systemd-helper update-state 'corosync.service' > >/dev/null || true > > fi > > fi > > # End automatically added section > > The problem is, that dh_installsystemd enables the service *after* a > start attempt has been made and > systemctl is-enabled checks for the state of the native service unit. > > With dh_systemd_enable/start, the enable part was before the start. > It's a bit like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887904 > > The old code worked, as it checked the status of the SysV init script, > not the enabled state of the native service file. > Right, the problem is that update-rc.d does not enable the systemd links, so we cannot drop this unless --skip-systemd-native was passed. I'll revert the change to unbreak things soon. For the longer term, maybe we can switch the check to /lib/systemd/systemd-sysv-install is-enabled $service ? This way we avoid some code duplication. -- Saludos, Felipe Sateler
Bug#906421: invoke-rc.d: service not started from package postinst anymore
Control: severity -1 serious
On Fri, Aug 17, 2018 at 9:57 AM Valentin Vidic
wrote:
> On Fri, Aug 17, 2018 at 02:40:53PM +0200, Michael Biebl wrote:
> > Could you add "set -x" to /usr/sbin/invoke-rc.d, then re-install the
> > lldapd package and attach the output please.
>
> Sure, here it goes:
>
> Preparing to unpack .../lldpad_1.0.1+git20150824.036e314-4_amd64.deb ...
> Unpacking lldpad (1.0.1+git20150824.036e314-4) ...
> Setting up lldpad (1.0.1+git20150824.036e314-4) ...
> + RUNLEVELHELPER=/sbin/runlevel
> + POLICYHELPER=/usr/sbin/policy-rc.d
> + INITDPREFIX=/etc/init.d/
> + RCDPREFIX=/etc/rc
> + BEQUIET=
> + MODE=
> + ACTION=
> + FALLBACK=
> + NOFALLBACK=
> + FORCE=
> + RETRY=
> + RETURNFAILURE=
> + RC=
> + is_systemd=
> + is_openrc=
> + SKIP_SYSTEMD_NATIVE=
> + set +e
> + test 2 -eq 0
> + state=I
> + test 2 -gt 0
> + test I '!=' III
> + case "$1" in
> + case ${state} in
> + verifyparameter lldpad
> + test 1 -eq 0
> + test 1 -ne 1
> + return
> + INITSCRIPTID=lldpad
> + state=II
> + shift
> + test 1 -gt 0
> + test II '!=' III
> + case "$1" in
> + case ${state} in
> + verifyparameter start
> + test 1 -eq 0
> + test 1 -ne 1
> + return
> + ACTION=start
> + state=III
> + shift
> + test 0 -gt 0
> + test III '!=' III
> + test -d /run/systemd/system
> + is_systemd=1
> + UNIT=lldpad.service
> + '[' '!' -x /sbin/runlevel ']'
> ++ /sbin/runlevel
> + RL='N 5'
> + RL=5
> + test x5 = x0
> + test x5 = x6
> + test x5 = x0
> + test x5 = x6
> + RC=
> + '[' -n 1 ']'
> + case ${ACTION} in
> + systemctl --quiet is-enabled lldpad.service
> + systemctl --quiet is-active lldpad.service
> + RC=101
>
Hmm. Commit 6f95680ffc9b1605841eb7d3d8eb92c790e6c73a looks like the culprit
of the regression. But I'd like to understand why this happens. Shouldn't
update-rc.d have enabled the service?
This looks like the same as #906051.
Setting severity to serious. I'll revert the change, until I find some time
to fully investigate the issue.
--
Saludos,
Felipe Sateler
Bug#904652: pulseaudio: looses device and replace it with dummy package so no sound possible
(Please keep the bug in CC) On Fri, Aug 10, 2018 at 4:06 PM Meinolf Gödde wrote: > Hi, > > Here is the output. > > Hope you can find a hint. > > Greetings > Unfortunately it is not useful unless it is a log of the problem occurring. Saludos > > Meinolf > > Am 07.08.2018 17:39 schrieb Felipe Sateler: > > On Sat, Jul 28, 2018 at 8:24 AM Charlemagne Lasse < > > charlemagnela...@gmail.com> wrote: > > > >> found 904652 11.1-5 > >> thanks > >> > >> > i didn't do anything. > >> > Upgrading the system like always. > >> > Suddenly there was no sound available. > >> > >> Change /etc/pulse/default.pa to automatically load module-alsa-sink on > >> boot (module-udev-detect is broken and will not load the alsa-sink > >> anymore) > >> > >> This is also a problem in buster (which is still using 11.1-5) > >> > > > > Seems like pulseaudio is not starting. Please attach the output of > > `pulseaudio - --daemonize=no`, without applying your workaround. -- Saludos, Felipe Sateler
Bug#905729: laptop-mode-tools causes `sda` disk to stop indefinitely when disconnect AC power.
Package: laptop-mode-tools Version: 1.72-2 Severity: critical Justification: breaks the whole system Dear Maintainer, * What led up to the situation? Installing kernel 4.17. * What exactly did you do (or not do) that was effective (or ineffective)? Configured laptop-mode-tools to package defaults. But didn't work. * What was the outcome of this action? The disk stopped again after unplugged the AC power. * What outcome did you expect instead? I expected that the battery mode on laptop changed to power saving, but working done. I read bug #889544 and my problem is the same except my disk never leave the stopped status, exactly as Jean-Marie reported. After that, I observed the same issues, the whole system starts to fail to write down to the disk reporting that it's damaged, and the last entry that persist at syslog is that `sda` stopped. My problem started when I installed kernel 4.17 and is not happening with kernel 4.16. My hardware is Asus n46vj, disk drive: ata1.00: ATA-10: Crucial_CT1050MX300SSD1, M0CR040, max UDMA/133 BIOS has enabled AHCI. Thank you. -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to es_CL.UTF-8), LANGUAGE=es_CL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to es_CL.UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages laptop-mode-tools depends on: ii lsb-base9.20170808 ii psmisc 23.1-1+b1 ii util-linux 2.32-0.4 Versions of packages laptop-mode-tools recommends: ii ethtool 1:4.16-1 ii hdparm 9.56+ds-2 ii net-tools 1.60+git20161116.90da8a0-3 ii python3-pyqt5 5.11.2+dfsg-1 ii rfkill 2.32-0.4 ii sdparm 1.08-1+b1 ii udev239-7 ii wireless-tools 30~pre9-12+b1 Versions of packages laptop-mode-tools suggests: ii acpid 1:2.0.28-1+b1 -- Configuration Files: /etc/laptop-mode/conf.d/usb-autosuspend.conf [Errno 2] No existe el fichero o el directorio: '/etc/laptop-mode/conf.d/usb-autosuspend.conf' -- no debconf information
Bug#904652: pulseaudio: looses device and replace it with dummy package so no sound possible
On Sat, Jul 28, 2018 at 8:24 AM Charlemagne Lasse < charlemagnela...@gmail.com> wrote: > found 904652 11.1-5 > thanks > > > i didn't do anything. > > Upgrading the system like always. > > Suddenly there was no sound available. > > Change /etc/pulse/default.pa to automatically load module-alsa-sink on > boot (module-udev-detect is broken and will not load the alsa-sink > anymore) > > This is also a problem in buster (which is still using 11.1-5) > Seems like pulseaudio is not starting. Please attach the output of `pulseaudio - --daemonize=no`, without applying your workaround. -- Saludos, Felipe Sateler
Bug#893167: Stack smashing protection trigged in eboard
lor[2] = priv->color[COLORSEL_BLUE];
> 2578 color[3] = priv->has_opacity ? priv->color[COLORSEL_OPACITY] :
> 65535; <--- Here we access memory beyond the variable
> "gdouble c[3];"
> 2579}
>
>
>
>
> (gdb) list colorb_csok
> 358
> 359 void colorb_csok(GtkWidget *b,gpointer data) {
> 360 ColorButton *me;
> 361 me=(ColorButton *)data;
> 362 gdouble c[3];
> 363 int v[3];
> 364
>
> gtk_color_selection_get_color(GTK_COLOR_SELECTION(GTK_COLOR_SELECTION_DIALOG(me->colordlg)->colorsel),c);
> 365 v[0]=(int)(c[0]*255.0);
> 366 v[1]=(int)(c[1]*255.0);
> 367 v[2]=(int)(c[2]*255.0);
> 368 me->ColorValue=(v[0]<<16)|(v[1]<<8)|v[2];
> 369 gtk_grab_remove(me->colordlg);
> 370 gtk_widget_destroy(me->colordlg);
> 371 me->updateButtonFace();
> 372 }
>
>
>
>
>
> https://developer.gnome.org/gtk2/stable/GtkColorSelection.html#gtk-color-selection-get-color
> Parameters
> ...
> color: an array of 4 gdouble to fill in with the current color.
>
--
-- Felipe
Bug#885038: Bug #885038 in paprefs marked as pending
Control: tag -1 pending Hello, Bug #885038 in paprefs reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/pulseaudio-team/paprefs/commit/2e76ca4ea884f1470b15a9f94331b67df5c9352a Port to GSettings and GTK-3 from GConf and GTK-2 1. Pick upstream patches that accomplish this. 2. Build-Depend on gtkmm-3 3. Adjust package dependencies for the new gsettings module Closes: #885038 Closes: #885076 (this message was generated automatically) -- Greetings https://bugs.debian.org/885038
Bug#885076: Bug #885076 in paprefs marked as pending
Control: tag -1 pending Hello, Bug #885076 in paprefs reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/pulseaudio-team/paprefs/commit/2e76ca4ea884f1470b15a9f94331b67df5c9352a Port to GSettings and GTK-3 from GConf and GTK-2 1. Pick upstream patches that accomplish this. 2. Build-Depend on gtkmm-3 3. Adjust package dependencies for the new gsettings module Closes: #885038 Closes: #885076 (this message was generated automatically) -- Greetings https://bugs.debian.org/885076
Bug#902181: pulseaudio: new pulseaudio update try to remove kde stuff
Hi, On Mon, Jun 25, 2018 at 11:39 AM Boris Pek wrote: > Hi, > > > Both plasma-pa and paprefs need porting. Each have their respective > > (severity serious) bug. Pulseaudio itself does not need fixing. Therefore > > I'm closing this bug. > > Could you explain why there were no transition (via experimental)? > Indeed, I failed to notify beforehand the plasma-pa maintainers. I apologize for that. However, plasma-pa upstream has know for years that this needs fixing. See https://bugs.kde.org/show_bug.cgi?id=386665 I'm not sure why do you think a transition would have helped: 1. None of the involved packages will be part of buster unless this is fixed. 2. Delaying this for either package would harm users of the other packages. Remember that neither paprefs not plasma-pa are installed in most computers[1]. [1] https://qa.debian.org/popcon-graph.php?packages=pulseaudio-module-gconf%2Cplasma-pa%2Cpaprefs%2Cpulseaudio&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 -- Saludos, Felipe Sateler
Bug#886048: Bug#902181: Bug#886048: plasma-pa: Depends on gconf
Hello Debian QT/KDE maintainers First, let me apologize for having uploaded the new pulseaudio without gconf without notifying you. For some reason, I forgot there was plasma-pa as reverse dependency. On Sun, Jun 24, 2018 at 2:48 AM Boyuan Yang <073p...@gmail.com> wrote: > On Mon, 01 Jan 2018 17:31:55 -0500 Jeremy Bicha wrote: > > Source: plasma-pa > > Version: 4:5.10.5-2 > > Severity: important > > User: pkg-gnome-maintain...@lists.alioth.debian.org > > Usertags: oldlibs gconf > > Tags: sid buster > > > > Your package depends or build-depends on gconf, but gconf will be > > removed from Debian soon. > > > > gconf's last release was about 5 years ago. It has been replaced by > > gsettings (provided in Debian by source glib2.0 ) > > > > I assume this depends on pulseaudio. > > > > References > > -- > > https://developer.gnome.org/gio/stable/ch34.html > > https://developer.gnome.org/gio/stable/GSettings.html > > > > On behalf of the Debian GNOME team, > > Jeremy Bicha > > Dear Debian KDE Developers, > > With Debian's pulseaudio 12.0 upload, pulseaudio has removed pulseaudio- > module-gconf in favour of pulseaudio-module-gsettings, which would break > current plasma-pa. > Indeed. While pulseaudio can build a gconf or a gsettings backend, building both is not advisable and would lead to confusion, as changes would not be synchronized between the modules. Therefore I have removed the gconf module. The only reverse dependencies are plasma-pa and paprefs. paprefs is already fixed upstream and I'm only waiting on a release to upload to debian. That would leave plasma-pa to be fixed. > (See also pulseaudio's bug https://bugs.debian.org/902181) > > This raises the urgency of dealing with the bug in plasma-pa to remove > gconf > dependency. Please look into this issue (Debian Bug #886048) again and > solve > it ASAP. > Indeed. Note that I do not plan to reintroduce the gconf module, so fixing this in plasma-pa is important. -- Saludos, Felipe Sateler
Bug#893167: source repository update
This debian package appears to be based on the old repository (CVS at sourceforge) that was last updated around 2008. I did some cleanup on the code (I am the eboard author) and moved the repository to github in 2016 ( https://github.com/fbergo/eboard ). I am unable to reproduce the bug with the current code (which has 1.1.2 as the version). If the debian package is still maintained, it should probably be updated to the updated code.
Bug#896326: python-csoundac: CsoundAC fails to import
Control: severity -1 important Control: forwarded -1 https://github.com/gogins/csound-extended/issues/27 Hi Helmut, Thanks for your bug report. On Fri, Apr 20, 2018 at 5:00 PM, Helmut Grohne wrote: > Package: python-csoundac > Version: 1:6.10.0~dfsg-1 > Severity: serious > User: helm...@debian.org > Usertags: python-import > > After installing python-csoundac importing the module CsoundAC > into a python interpreter fails with the following error: > > 0dBFS level = 32768.0 > --Csound version 6.10 (double samples) 2018-01-27 > [commit: none] > libsndfile-1.0.28 > Csound tidy up: Segmentation fault > backtrace() returned 14 addresses > /usr/lib/libcsound64.so.6.0(+0x40c43) [0x7f6745d52c43] > /lib/x86_64-linux-gnu/libc.so.6(+0x34f00) [0x7f6746cdff00] > python(PyImport_AddModule+0x1c) [0x55ca472194ac] > python(PyRun_SimpleStringFlags+0x19) [0x55ca47292409] > /usr/lib/python2.7/dist-packages/_csnd6.x86_64-linux-gnu.so(+0x288d9) > [0x7f674159c8d9] > /usr/lib/libcsound64.so.6.0(csoundMessage+0xa1) [0x7f6745d532a1] > /usr/lib/libcsound64.so.6.0(csoundCleanup+0x33e) [0x7f6745d7706e] > /usr/lib/libcsound64.so.6.0(+0x4239c) [0x7f6745d5439c] > /usr/lib/libcsound64.so.6.0(csoundDestroy+0xa0) [0x7f6745d55120] > /usr/lib/libcsound64.so.6.0(+0x431c0) [0x7f6745d551c0] > /lib/x86_64-linux-gnu/libc.so.6(+0x37831) [0x7f6746ce2831] > /lib/x86_64-linux-gnu/libc.so.6(+0x3792a) [0x7f6746ce292a] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xee) [0x7f6746ccca8e] > python(_start+0x2a) [0x55ca4720db1a] The crash actually happens upon module unload (when the interpreter is exiting). I'm therefore lowering the severity since it doesn't make the module unusable. -- Saludos, Felipe Sateler
Bug#881342: stretch update for rtkit
On Wed, Mar 14, 2018 at 2:35 PM, Adrian Bunk wrote: > On Wed, Feb 21, 2018 at 03:24:08PM +, Debian Bug Tracking System wrote: > >... > > rtkit (0.11-6) unstable; urgency=medium > > . > >* Move dbus and polkit from Recommends to Depends > > rtkit can't do much really without either of them so bump them to > Depends. > > (Closes: #881342) > >... > > Thanks a lot for fixing this bug for unstable. > > It is still present in stretch, could you also fix it there? > Alternatively, I can fix it for stretch if you don't object. > I'd be happy if you do. I'm currently suffering from ENOTIME so I'm not likely to get around to doing that soon. -- Saludos, Felipe Sateler
Bug#790171: genius: depends on vte which is deprecated
Hi Jiří, On Thu, Dec 28, 2017 at 1:46 AM, Jeremy Bicha wrote: > Control: severity -1 serious > Control: tags -1 -stretch > > We do not intent to release Debian 10 "Buster" with src: vte. > Therefore, I am raising the severity of this bug. > > > > It appears the time has come to migrate away... -- Saludos, Felipe Sateler
Bug#883269: Default curl_option '--compress' is invalid
Package: prey Version: 0.6.2-1.1 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, curl no support the option --compress: -8<- $ curl --compress -i http://www.example.org curl: option --compress: is ambiguous curl: try 'curl --help' or 'curl --manual' for more information -8<- So you must change the line 62 of the default config file: https://sources.debian.net/src/prey/0.6.2-1.1/config.default/?hl=62#L62 to enabled '--compressed' option instead of '--compress'. Thank you, Felipe Sologuren -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (600, 'testing'), (500, 'stable-updates'), (500, 'stable'), (100, 'unstable'), (40, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to es_CL.UTF-8), LANGUAGE=es_CL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to es_CL.UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages prey depends on: ii bash 4.4-5 ii curl 7.56.1-1 ii debconf [debconf-2.0]1.5.65 ii imagemagick 8:6.9.7.4+dfsg-16 ii imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-16 ii libio-socket-ssl-perl2.052-1 ii libnet-ssleay-perl 1.80-1+b2 ii openssl 1.1.0g-2 ii perl 5.26.1-2 ii python 2.7.14-1 ii scrot0.8-18 ii streamer 3.103-4+b2 Versions of packages prey recommends: ii python-gtk2 2.24.0-5.1+b1 prey suggests no packages. -- Configuration Files: /etc/cron.d/prey changed [not included] /etc/prey/config changed [not included] -- debconf information: * prey/reporting_frequency: 25 * prey/edit_config: * prey/active_modules: webcam, geo, lock, session, network, system, alert, alarm --- /etc/prey/config.dpkg-dist 2013-12-06 08:23:20.0 -0300 +++ /etc/prey/config2017-12-01 10:44:19.734162726 -0300 @@ -59,7 +59,7 @@ # include additional options for curl here. if you're having trouble getting # requests across your firewall, you can try adding '-0' to make curl perform # HTTP 1.0 requests -curl_options='--compress --connect-timeout 60' +curl_options='--compressed --connect-timeout 60' # by adding proxy here, prey will attempt to use it in case a direct request is # unsuccessful. example: http://proxy.server.com:3378
Bug#881753: local-apt-repository: breaks apt operation if removed
Hi Joachim, On Tue, Nov 14, 2017 at 4:35 PM, Joachim Breitner wrote: > > Hi Felipe, > > this just came in. Since you last worked on this package, would you be > interesting in fixing this bug? > Sorry, I'm currently lacking time to do this. -- Saludos, Felipe Sateler
Bug#877773: groovebasin crashes
Control: reassign -1 libleveldb1v5 1.20-1 Control: retitle -1 libleveldb1v5: breaks ABI without SONAME bump On Thu, Oct 5, 2017 at 8:38 AM, Thadeu Lima de Souza Cascardo wrote: > > Package: groovebasin > Version: 1.4.0-1 > Severity: grave > > groovebasin crashes when simply running with 'groovebasin'. Setting this > as grave as it seems to make it unusable for any user. > > I was using groovebasin during the stretch release cycle and though I > found some problems related to filename encoding, it was a great player. > > After the release, some nodejs updates seemed to require binary NMUs due > to ABI incompatibilities for some of the libraries used by groovebasin. > After they were completed, I could upgrade nodejs and groovebasin. But > for a while, I didn't run groovebasin, so didn't notice the issue. So, > it's possible that it's related to the nodejs upgrade. Thanks for this info, it proved helpful. I think the problem is that leveldb broke ABI without SONAME bump (and transition). Downgrading to 1.19 or rebuilding node-leveldown fixes the crash. I think (but my C++ fu is not very strong) that the problem is the addition of the max_file_size to the Options class. ABI tracker seems to agree with me[1]. Dear leveldb maintainers, please bump soname and do a transition. [1] https://abi-laboratory.pro/tracker/compat_report/leveldb/1.19/1.20/ecd6d/abi_compat_report.html -- Saludos, Felipe Sateler
Bug#878346: marked as pending
tag 878346 pending thanks Hello, Bug #878346 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://anonscm.debian.org/git/pkg-multimedia/supercollider.git/commit/?id=0e4c6b4 --- commit 0e4c6b42b7fafac98baa93ef5efac5d766f1ce75 Author: Felipe Sateler Date: Thu Oct 12 21:21:08 2017 -0300 Release diff --git a/debian/changelog b/debian/changelog index 00df070..951a392 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,17 @@ +supercollider (1:3.8.0~repack-2) unstable; urgency=medium + + * Demote Depends of supercollider-language on supercollider-server to a Recommends. +Normal users are expected to install the supercollider package, and +this allows advanced users to install only the language and have a +remote server. (Closes: #810006) + * Don't let the build system enable sse on i386. +It's not part of mainline. (Closes: #878346). + * Remove autodetection of raspberry cpus. +In debian we don't actually target raspberries, and guessing based on the build machine +is wrong too (Closes: #878347) + + -- Felipe Sateler Thu, 12 Oct 2017 21:20:37 -0300 + supercollider (1:3.8.0~repack-1) unstable; urgency=medium [ Dan Stowell ]
Bug#878347: marked as pending
tag 878347 pending thanks Hello, Bug #878347 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://anonscm.debian.org/git/pkg-multimedia/supercollider.git/commit/?id=0e4c6b4 --- commit 0e4c6b42b7fafac98baa93ef5efac5d766f1ce75 Author: Felipe Sateler Date: Thu Oct 12 21:21:08 2017 -0300 Release diff --git a/debian/changelog b/debian/changelog index 00df070..951a392 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,17 @@ +supercollider (1:3.8.0~repack-2) unstable; urgency=medium + + * Demote Depends of supercollider-language on supercollider-server to a Recommends. +Normal users are expected to install the supercollider package, and +this allows advanced users to install only the language and have a +remote server. (Closes: #810006) + * Don't let the build system enable sse on i386. +It's not part of mainline. (Closes: #878346). + * Remove autodetection of raspberry cpus. +In debian we don't actually target raspberries, and guessing based on the build machine +is wrong too (Closes: #878347) + + -- Felipe Sateler Thu, 12 Oct 2017 21:20:37 -0300 + supercollider (1:3.8.0~repack-1) unstable; urgency=medium [ Dan Stowell ]
Bug#878911: avahi FTBFS with debhelper 10.9.2
On Sat, Oct 21, 2017 at 3:44 AM, Niels Thykier wrote: > Control: reassign -1 debhelper 10.9.2 > > Michael Biebl: >> On Tue, 17 Oct 2017 19:45:11 +0300 Adrian Bunk wrote: >>> Source: avahi >>> Version: 0.7-3 >>> Severity: serious >>> >>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/avahi.html >>> >>> ... >>>dh_systemd_start >>> dh_systemd_start: Could not find "avahi-daemon.socket" in the >>> /lib/systemd/system directory of avahi-dnsconfd. This could be a typo, or >>> using Also= with a service file from another package. Please check >>> carefully that this message is harmless. >>> dh_systemd_start: Cannot open(avahi-daemon.socket) for extracting the Also= >>> line(s) >>> debian/rules:4: recipe for target 'binary' failed >>> make: *** [binary] Error 2 >>> >>> >>> 19:35 < nthykier> bunk: Ideally, avahi would fix this on their end. >>> Without the fail-on-error, debhelper will silently "not do things" >>> when the file is unreadable (even if only temporarily). >>> I.e. a "fail-to-fail"-case >>> >> > > Hi, > >> avahi-daemon.socket is provided by avahi-daemon, a binary package which >> is built from the same source package and avahi-dnsconfd depends on >> avahi-daemon. > > Ok, when I spoke with Adrian about this, I had a different understanding > of what happened and why it broke. > >> Niels, can you be a bit more specific why this fails now and what you >> think is the proper fix? > > I can explain why it fails; dh_systemd_start basically reads the Also= > line and pretends it was a part of the services listed on the cmdline/in > the package. As it is now mandatory for us to be able to read the > service files, this will fail as the service is not where we expect to > find it. > > The comment related to that part of the code reads: > > """ > # Handle all unit files specified via Also= explicitly. > # This is not necessary for enabling, but for disabling, as we > # cannot read the unit file when disabling (it was already > # deleted). > """ > > @biebl/@fsateler: when a unit has an Also= that points to a unit in a > different package can we then just ignore the relation? I assume that > we should not disable/stop services from another package on removal. I think that in this case, the correct fix is to drop the Also= line. 1. We don't want to stop avahi-daemon socket if dnsconfd is removed 2. It appears the Also line is being treated as some form of dependency manager (ie, to ensure that the avahi-daemon is started when dnsconfd is started), but it is not necessary, because avahi-daemon.socket is already Required. So, I think we have not yet found a compelling case for dropping the debhelper error. The Also line is not needed, and can be safely dropped from the avahi-dnsconfd unit. -- Saludos, Felipe Sateler
Bug#877656: kodi: supports insecure download of non-free addons
On Tue, Oct 3, 2017 at 7:04 PM, Jonas Smedegaard wrote: > Quoting Felipe Sateler (2017-10-03 23:32:24) >> On Tue, Oct 3, 2017 at 5:49 PM, Jonas Smedegaard wrote: >> > Package: kodi >> > Version: 2:17.3+dfsg1-2 >> > Severity: grave >> >> This severity feels a bit inflated. After all, you can download and >> run non-free programs using a web browser too! > > When you browse into <https://evil.example.com/>, download scarycode.sh > from there and execute it in a shell, then you are to blame if your foot > gets blown away. > > If instead you open your media center, it automatically updates an addon > but the http connection gets hijacked and redirected to > http://evil.example.com/ where scarycode.sh instead gets loaded and > blows off your foot, then I dare say not you but your media center is to > blame. Ah, this was key information I was missing (the automatic part). >> > Tags: security upstream patch >> > Justification: user security hole > > What severity would you use for user security hole? Or do you disagree > that using hardcoded http in an _internal_ interface is a user security > hole? > No, I don't disagree. I just misunderstood. > >> > Kodi supports downloading and loading addons at runtime. >> > >> > Official addon feed is served only via http and contain non-free >> > addons. >> > >> > Allowing to extend the system with non-free addons at runtime by >> > default is arguably an anti-feature in itself. Doing so insecurely >> > poses a risk of malicious code getting into users' home and executed >> > by Kodi. >> > >> > Attached patch relaxes to make addon feed optional. >> >> Making plugin feeds optional sounds good though. > > Right. > > I realize my choice of words might be confusing: feed is optional in > code with the patch, meaning it won't fail to start if missing. On the > packaging level I however intend at first to have kodi _recommend_ the > feed, so it will be pulled in by default - so until an alternative exist > it is an "opt-out" not an "opt-in". BTW, I think there are two issues conflated here: 1. Insecure downloading of code 2. Non-free addons available by default. I think your patch mainly addresses issue number 2, doesn't it? Fixing issue 1 would require asking upstream to provide https://mirrors.kodi.tv/addons/krypton/addons.xml.gz.md5 (and upgrade to a better hash algorithm). -- Saludos, Felipe Sateler
Bug#877656: kodi: supports insecure download of non-free addons
On Tue, Oct 3, 2017 at 5:49 PM, Jonas Smedegaard wrote: > Package: kodi > Version: 2:17.3+dfsg1-2 > Severity: grave This severity feels a bit inflated. After all, you can download and run non-free programs using a web browser too! > Tags: security upstream patch > Justification: user security hole > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Kodi supports downloading and loading addons at runtime. > > Official addon feed is served only via http and contain non-free addons. > > Allowing to extend the system with non-free addons at runtime by default > is arguably an anti-feature in itself. Doing so insecurely poses a risk > of malicious code getting into users' home and executed by Kodi. > > Attached patch relaxes to make addon feed optional. Making plugin feeds optional sounds good though. > > I intend to move the addons feed configuration file to a separate > package "kodi-repository-kodi" and, at first, ship that package in main > recommended by kodi. > > Later when an alternate package "kodi-repository-curated" is available¹, > I intend to favor that over kodi-repository-kodi and move the latter to > contrib. I don't think moving to contrib makes sense. Either the package fits the requirements for main or it doesn't. I don't think this package should go in contrib, as it doesn't *need* any software not available in main. So it should not be moved there. -- Saludos, Felipe Sateler
Bug#853671: marked as pending
tag 853671 pending thanks Hello, Bug #853671 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://anonscm.debian.org/git/pkg-multimedia/supercollider.git/commit/?id=8438806 --- commit 8438806ab1b811372341efbc86a36704ff6b5d6d Author: Felipe Sateler Date: Thu Sep 7 19:52:21 2017 -0300 Release diff --git a/debian/changelog b/debian/changelog index ce09536..c1d42f1 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +supercollider (1:3.7.0~repack-5) unstable; urgency=medium + + * Fix FTBFS with gcc 7. +Thanks to Adrian Bunk for the patches. (Closes: #853671) + * Remove copyright_hints. +We no longer use CDBS + * Bump standards version + + -- Felipe Sateler Thu, 07 Sep 2017 19:52:02 -0300 + supercollider (1:3.7.0~repack-4) unstable; urgency=medium [ Dan Stowell ]
Bug#872860: marked as pending
tag 872860 pending thanks Hello, Bug #872860 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://anonscm.debian.org/git/pkg-multimedia/csound.git/commit/?id=550dc39 --- commit 550dc39611a3ea1cf33ab8bdd73b103e0f3d5faf Author: Felipe Sateler Date: Wed Aug 23 13:12:54 2017 -0300 Release diff --git a/debian/changelog b/debian/changelog index 364c9b5..c6dd98f 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +csound (1:6.09.1~dfsg-2) unstable; urgency=medium + + * Fix build failure with GMM 5.2+ (Closes: #872860) + + -- Felipe Sateler Wed, 23 Aug 2017 13:12:48 -0300 + csound (1:6.09.1~dfsg-1) unstable; urgency=medium * New upstream version 6.09.1~dfsg
Bug#872860: csound FTBFS with libgmm++-dev 5.2+dfsg1-5
Control: forwarded -1 https://github.com/csound/csound/pull/839 On Tue, Aug 22, 2017 at 4:07 PM, Anton Gladky wrote: > tags 872860 +patch > thanks > > Dear maintainers, > > in attachment you will find a patch which fixes FTBFS due to a new > getfem (gmm) version. It would be good if somebody reviews and tests > it properly. Thanks for the patch. There is a problem though: the `<
Bug#872598: udev-udeb: no input in graphical installer
On Sat, Aug 19, 2017 at 9:38 AM, Cyril Brulebois wrote: > Control: tag -1 patch > > Hi, > > (Again, please keep debian-boot@ in copy.) > > Raphael Hertzog (2017-08-19): >> > I've only quickly glanced at the contents of both packages, and >> > debdiff mentions no obvious issues (file lists are the same). >> >> I believe this is precisely the problem. The new udev-udeb should >> include a new file: >> diff --git a/debian/udev-udeb.install b/debian/udev-udeb.install >> index 6a8e2108f..6758fef06 100644 >> --- a/debian/udev-udeb.install >> +++ b/debian/udev-udeb.install >> @@ -5,6 +5,7 @@ lib/udev/ata_id >> lib/udev/scsi_id >> lib/udev/cdrom_id >> lib/udev/rules.d/50-udev-default.rules >> +lib/udev/rules.d/60-input-id.rules >> lib/udev/rules.d/60-cdrom_id.rules >> lib/udev/rules.d/60-persistent-input.rules >> lib/udev/rules.d/60-persistent-storage.rules >> >> I won't have the time to test this now but I believe it's the problem. > > That's absolutely correct. I've started by copying the file manually into > the netboot-gtk mini.iso, and confirmed the fix. To be extra sure, I've > rebuilt a systemd package with your change, and used the new udev udebs > for a clean build, and that works as well. > > A timely fix would be appreciated, the breakage(s) in the graphical > installer prevented us from releasing debian-installer over the past few > weeks, and it would be great not to wait too long before we're able to do > so, esp. with linux 4.12.6-1 having reached testing lately. > > Thinking about this, I'll check with debian-release@ and I might just > freeze all udeb-producing packages right away. Winter has come. > > >> It would be nice to have a fixed udev soon. Thank you Cyril for the >> investigation! >> >> I wonder if it would be possible to have autopkgtest tests covering >> udev-udeb... > > I'm still new to the whole autopkgtest thing, but from where I stand, the > fact d-i is broken has been known for quite a while; the core issue is > that nobody investigated this before I found some time. An easy way to be > more proactive on the systemd side would be to make sure that new (and/or > deleted) files in the udev and libudev1 binaries are detected by > maintainers (esp. since udev.install uses wildcards for rules files, while > udev-udeb.rules uses a static list), so that the update can be propagated > to the udebs if relevant. --fail-missing is broken on the udeb builds at the moment, so it is not enabled. I'll try to fix this and enable it. This should help catch these sort of issues in the future. -- Saludos, Felipe Sateler
Bug#872438: src:nodejs: FTBFS on mips64el: Can't determine the arch of ./node
Package: src:nodejs Version: 6.11.2~dfsg-2 Severity: serious nodejs failed to build with this error: make[1]: Entering directory '/<>' # Clean up any leftover processes but don't error if found. ps awwx | grep Release/node | grep -v grep | cat /usr/bin/python tools/test.py -p tap \ --mode=release --flaky-tests=dontcare \ --arch=mips64el --timeout=3000 message parallel sequential Can't determine the arch of: './node' Can't determine the arch of: './node' Can't determine the arch of: './node' No tests to run. Makefile:220: recipe for target 'test-ci-js' failed make[1]: *** [test-ci-js] Error 1 make[1]: Leaving directory '/<>' Full log at https://buildd.debian.org/status/fetch.php?pkg=nodejs&arch=mips64el&ver=6.11.2~dfsg-2&stamp=1502862893&raw=0 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#871814: marked as pending
tag 871814 pending thanks Hello, Bug #871814 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://anonscm.debian.org/git/pkg-multimedia/csound-manual.git/commit/?id=42e656a --- commit 42e656abae76c8b1ae881e57c58210b7faf3accf Author: Felipe Sateler Date: Fri Aug 11 19:58:27 2017 -0400 Release diff --git a/debian/changelog b/debian/changelog index 2efb7ba..8f15c17 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +csound-manual (1:6.09.0~dfsg-2) unstable; urgency=medium + + * Add missing build-dependencies (Closes: #871814) + + -- Felipe Sateler Fri, 11 Aug 2017 19:58:07 -0400 + csound-manual (1:6.09.0~dfsg-1) unstable; urgency=medium * New upstream version 6.09.0~dfsg
Bug#865439: marked as pending
tag 865439 pending thanks Hello, Bug #865439 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://anonscm.debian.org/git/pkg-multimedia/csound.git/commit/?id=57e0082 --- commit 57e0082975b7359a681fe975f94ab36c4e5c3978 Author: Felipe Sateler Date: Wed Aug 9 21:28:19 2017 -0400 Release diff --git a/debian/changelog b/debian/changelog index c8dbf32..364c9b5 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,8 +1,16 @@ -csound (1:6.09.1~dfsg-1) UNRELEASED; urgency=medium +csound (1:6.09.1~dfsg-1) unstable; urgency=medium * New upstream version 6.09.1~dfsg +- Fixes build failure on 32bit. Closes: #865439 +- Remove unused cmake options from build script +- Refresh patches + * Override *_MODULE_INSTALL_DIR to set it to global install dir + * Add new functions to symbols file + * Bump standards version + * Fix symbols file version for csoundA4. +Remove debian revision - -- Felipe Sateler Wed, 12 Jul 2017 21:11:45 -0400 + -- Felipe Sateler Wed, 09 Aug 2017 21:27:24 -0400 csound (1:6.09.0~dfsg-1) unstable; urgency=medium
Bug#864829: screen reader stops speaking
Control: tags -1 - moreinfo Control: reassign -1 espeakup 1:0.80-5 Control: retitle -1 espeakup is incompatible with default pulseaudio configuration On Thu, Jun 15, 2017 at 6:18 PM, Luke Yelavich wrote: > On Thu, Jun 15, 2017 at 11:39:35PM AEST, Mika Hanhijärvi wrote: > > I am using the Gnome desktop. > > I have espeakup and Orca installed. I would like to use espeakup on > console and > > Orca on desktop. I also would like to be able to switch between text mode > > console and graphical nome desktop without logging out from the desktop. > > ESpeakup is running as root, and everything is running as a user. I think > the > easiest solution here is to configure Pulse to run system-wide. I know > there > is an option in one of the Pulse configuration files to enable this, but I > don't think Debian ships a startup script or systemd service file to use > PulseAudio in system mode. Happy to be corrected. > If that is so, then espeakup is incompatible with a default pulseaudio configuration. Maybe this should be documented somewhere. On Mon, Jul 3, 2017 at 7:52 AM, Scott Leggett wrote: > Hi, > > I've been able to reproduce this bug. A not-very-helpful workaround is > to restart espeakup whenever sound goes missing. > > I've dug into the issue a bit and found it discussed on > pulseaudio-discuss back in 2010. The discussion on the thread seems to > indicate that espeakup and pulseaudio couldn't coexist at the time due > to espeakup not being multi-seat aware. Lennart summarised what needs to > be done to get them working together[0]. > > I'm not sure what the situation is now. Looking briefly at espeakup > upstream [1], it doesn't seem to be very active, so maybe the situation is > the same? > > [0] > https://lists.freedesktop.org/archives/pulseaudio-discuss/20 > 10-January/006033.html > [1] https://github.com/williamh/espeakup I'm reassigning this bug to espeakup because it should really be modified to work as non-root as Lennart suggested. AFAICT, the only reasong for running as root is to access the softsynth device, but that could be managed via regular uaccess and group mechanism like /dev/snd/* does. We shouldn't require running pulseaudio as root, as it would be better if espeakup would run unprivileged. I'll leave it to the espeakup maintainers to adjust severity. -- Saludos, Felipe Sateler
Bug#853671: supercollider: ftbfs with GCC-7
Hi Dan, On Tue, Jan 31, 2017 at 6:36 AM, Matthias Klose wrote: > Package: src:supercollider > Version: 1:3.7.0~repack-4 > Severity: normal > Tags: sid buster > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-7 > > The package fails to build in a test rebuild on at least amd64 with > gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The > severity of this report may be raised before the buster release. > There is no need to fix this issue in time for the stretch release. The severity was raised so now it is RC. I also see that there are newer upstream releases. Maybe this issue does not exist in the newer release? -- Saludos, Felipe Sateler
Bug#864829: screen reader stops speaking
Control: tags -1 moreinfo Hi Mika Hanhijärvi, On Thu, Jun 15, 2017 at 9:39 AM, Mika Hanhijärvi wrote: > Package: pulseaudio > Version: 10.0-1 > Severity: grave > > Hi > > I am sorry that I repport this so close to release of Stretch. > > I am not really sure to which package I should report this bug. I am not > 100% > sure if this g is in Pulseaudio, speech-eispatcher or someething else. I > think > it might be a problem with Pulseaudio. > > I am blind so I have to use computer using the screen reader. So it is > important for me that screen reader works relealibly. > I am very much ignorant about how screen readers work. Could you describe a bit how the stack works please? In particular, what program is actually responsible for playing the synthesized speech to speakers, and how does it run? Also, the audio-related configuration (if any) of these programs would be useful. > > I am using the Gnome desktop. > I have espeakup and Orca installed. I would like to use espeakup on > console and > Orca on desktop. I also would like to be able to switch between text mode > console and graphical nome desktop without logging out from the desktop. > Currently that does not work. I have two laptops and both have this > problem. > Note that I have not made clean Stretch installation, Ihave upgraded my > systems > to Stretch. > > > For some reason if espeakup sppeaks something when the computer is booting > then > screen reader does not speak anytging on GDM login screen. If that happens > then > screen reader also does not speak at all on desktop. This makes it > impossible > for me to login to desktop or use the deshtop. I have noticed that if I go > to > text console then eseakup speaks just fin. > > If espeakup does not speak anytging then screen reader speaks on GDM login > screen. If I go to text console then espeakup does not speak at all. If I > login > to desktop then Orca screen reader speaks just fine. If I login to desktop > then > this also happens: If I switch from desktop to GDM login screen thusing the > ctrl + alt + f1 then screen reader does not speak on GDM login screen at > all. > If I then return to desktop then Orca screen reader on desktop speaks again > just fine. If I switch form desktop to text console using e.g ctrl + alt + > f3 > then espeakup does not speak at all on console. If I then switch back to > desktothen Orca speaks again on desktop just fine. > > > If I logout from desktop to gdm login screen then screen reader speaks on > gdm > login screen. > So it seems that the sc reader works just on one of the following views: > console, gdm or desktop. It is not possible to switch between those. That > is > not good. > It sounds like the programs that play the speech to the speakers are grabbing the sound device and not letting it go - thus making it impossible for the alternative programs to actually play the sound. Some information that would be useful: 1. Is your user part of the audio group? 2. Does any of the programs that actually play the sound run as root or a user that is in the audio group? 3. Please attach the output of `lsof /dev/snd/*` for each of the problematic states (this should answer question 2). -- Saludos, Felipe Sateler
Bug#863082: pulseaudio: debian/copyright does not contain AGPL-3+ text, and references missing file instead
Control: tags -1 help gift On Sun, May 21, 2017 at 7:11 PM, Felipe Sateler wrote: > On Sun, May 21, 2017 at 10:36 AM, Mattia Rizzolo > wrote: > > Source: pulseaudio > > Version: 10.0-1 > > Severity: serious > > > > the copyright file has this paragraph: > > > > |Files: src/utils/qpaeq > > |Copyright: 2009 Jason Newton > > |License: AGPL-3+ > > | This program is free software: you can redistribute it and/or modify > > | it under the terms of the GNU Affero General Public License as > > | published by the Free Software Foundation, either version 3 of the > > | License, or (at your option) any later version. > > | . > > | This program is distributed in the hope that it will be useful, > > | but WITHOUT ANY WARRANTY; without even the implied warranty of > > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > | GNU Affero General Public License for more details. > > | . > > | On Debian systems, the complete text of the AGPL 3 can be found in > > | /usr/share/doc/pulseaudio/AGPL > > > > > > This is not acceptable for our current policy for the same points: > > > > * said file /usr/share/doc/pulseaudio/AGPL is missing, it appears to be > > compressed instead > > * so /use/share/doc/pulseaudio/AGPL.gz iscompressed, and quoting the > > policy "This file must neither be compressed nor be a symbolic link" > > Indeed, it was compressed by dh_compress. I need to add an exclusion > > > * there are binaries shipped by src:pulseaudio which do not depend on > > the pulseaudio binary package, thus totally missing the AGPL-3 text > > All packages ship AGPL file, but indeed the reference is to the > pulseaudio package directory. Will fix. > > > * policy does not consider files different than > > /usr/share/doc//copyright to be possible, except for a few cases > > explicitly listed there (where this is not one of those) > > `grep usr/share/doc /usr/share/doc/*/copyright` in my system lists > several files making references to copyright in other files. Policy > might need to be updated. > I've found myself lacking the time to do this. NMU welcome. -- Saludos, Felipe Sateler
Bug#864044: pasystray: Segmentation fault on startup (under wayland?)
Package: pasystray Version: 0.6.0-1 Severity: serious pasystray crashes on startup when running under gnome wayland: #0 0xedc7 in x11_property_init () at x11-property.c:46 #1 0xb10a in init (settings=0x7fffdf10) at pasystray.c:65 #2 0x8f63 in main (argc=1, argv=0x7fffe018) at pasystray.c:52 Turns out the ScreenOfDisplay is NULL. I'm not sure if that is is a problem in pasystray usage or X/Wayland. But this effectively makes pasystray unusable. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages pasystray depends on: ii gnome-icon-theme 3.12.0-2 ii libatk1.0-0 2.22.0-1 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libavahi-glib1 0.6.32-2 ii libc62.24-11 ii libcairo-gobject21.14.8-1 ii libcairo21.14.8-1 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-0 3.22.12-1 ii libnotify4 0.7.7-2 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpulse-mainloop-glib0 10.0-1 ii libpulse010.0-1 ii libx11-6 2:1.6.4-3 pasystray recommends no packages. Versions of packages pasystray suggests: pn paman ii paprefs 0.9.10-2+b1 ii pavucontrol 3.0-3.1 pn pavumeter ii pulseaudio-module-zeroconf 10.0-1 -- no debconf information
Bug#863082: pulseaudio: debian/copyright does not contain AGPL-3+ text, and references missing file instead
On Sun, May 21, 2017 at 10:36 AM, Mattia Rizzolo wrote: > Source: pulseaudio > Version: 10.0-1 > Severity: serious > > the copyright file has this paragraph: > > |Files: src/utils/qpaeq > |Copyright: 2009 Jason Newton > |License: AGPL-3+ > | This program is free software: you can redistribute it and/or modify > | it under the terms of the GNU Affero General Public License as > | published by the Free Software Foundation, either version 3 of the > | License, or (at your option) any later version. > | . > | This program is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > | GNU Affero General Public License for more details. > | . > | On Debian systems, the complete text of the AGPL 3 can be found in > | /usr/share/doc/pulseaudio/AGPL > > > This is not acceptable for our current policy for the same points: > > * said file /usr/share/doc/pulseaudio/AGPL is missing, it appears to be > compressed instead > * so /use/share/doc/pulseaudio/AGPL.gz iscompressed, and quoting the > policy "This file must neither be compressed nor be a symbolic link" Indeed, it was compressed by dh_compress. I need to add an exclusion > * there are binaries shipped by src:pulseaudio which do not depend on > the pulseaudio binary package, thus totally missing the AGPL-3 text All packages ship AGPL file, but indeed the reference is to the pulseaudio package directory. Will fix. > * policy does not consider files different than > /usr/share/doc//copyright to be possible, except for a few cases > explicitly listed there (where this is not one of those) `grep usr/share/doc /usr/share/doc/*/copyright` in my system lists several files making references to copyright in other files. Policy might need to be updated. -- Saludos, Felipe Sateler
Bug#858957: marked as pending
tag 858957 pending thanks Hello, Bug #858957 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://anonscm.debian.org/git/pkg-multimedia/stk.git/commit/?id=7b2ec31 --- commit 7b2ec31c8f7bbdcad893502e21533056ad5a26b9 Author: Felipe Sateler Date: Wed Mar 29 10:40:12 2017 -0300 Release to unstable diff --git a/debian/changelog b/debian/changelog index d293d44..29fcf7d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +stk (4.5.2+dfsg-5) unstable; urgency=medium + + * Use debian RAWWAVE_PATH in stk-demo. (Closes: #858895) + * Fix link targets for RtAudio and RtMidi header files (Closes: #858957) + + -- Felipe Sateler Wed, 29 Mar 2017 10:39:43 -0300 + stk (4.5.2+dfsg-4) unstable; urgency=medium [ Petter Reinholdtsen ]
Bug#858895: marked as pending
tag 858895 pending thanks Hello, Bug #858895 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://anonscm.debian.org/git/pkg-multimedia/stk.git/commit/?id=7b2ec31 --- commit 7b2ec31c8f7bbdcad893502e21533056ad5a26b9 Author: Felipe Sateler Date: Wed Mar 29 10:40:12 2017 -0300 Release to unstable diff --git a/debian/changelog b/debian/changelog index d293d44..29fcf7d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +stk (4.5.2+dfsg-5) unstable; urgency=medium + + * Use debian RAWWAVE_PATH in stk-demo. (Closes: #858895) + * Fix link targets for RtAudio and RtMidi header files (Closes: #858957) + + -- Felipe Sateler Wed, 29 Mar 2017 10:39:43 -0300 + stk (4.5.2+dfsg-4) unstable; urgency=medium [ Petter Reinholdtsen ]
Bug#856487: pulseaudio: SIGSEGV upon streaming to bluetooth headset
On Sat, Mar 4, 2017 at 6:27 PM, Linus Lüssing wrote: >> Are you sure it's definitely related to the gcc version? Did you actually >> try rebuilding with gcc-4.9 on the target machine? >> >> The thing is that assembly code is not interpreted by gcc but by the >> assembler >> which is part of the binutils package. Since binutils is updated >> in Debian very often, it may be well related to a bug in binutils. > > I didn't try from a chroot, but tried 2.28 as you suggested as > well as a few downgraded versions, which all failed: > > binutils 2.28-1 -> not > binutils 2.27.51.20161220-1 > binutils 2.27-9 -> not working > binutils 2.26-1 -> not working > binutils 2.26.1-1 -> not working > binutils 2.26-12 -> not working > > I also tried downgrading gcc-6, which didn't help either: > gcc 6.0.1-2 > > What worked then: > * gcc 4.9.4-2 + binutils 2.26.1-1 > * gcc 4.9.4-2 + binutils 2.28-1 > Thanks for the extensive testing! > Not really familiar with how binaries get created or uploaded in > Debian, but is it possible to determine the gcc + binutils > versions with which libsbc 1.3-1 and 1.3-1+b2 were created? Just > to double check whether the official uploads were indeed created > with gcc-4.9 for libsbc 1.3-1 and gcc-5/gcc-6 for 1.3-1+b2? The build logs are publicly available, for this build[1] the versions used were: binutils_2.25-8 gcc-4.9_4.9.2-19 [1] https://buildd.debian.org/status/fetch.php?pkg=sbc&arch=armhf&ver=1.3-1&stamp=1433137735&raw=0 -- Saludos, Felipe Sateler
Bug#856487: pulseaudio: SIGSEGV upon streaming to bluetooth headset
Control: retitle -1 libsbc1: compiling with gcc > 4.9 causes stack corruption On Fri, Mar 3, 2017 at 3:24 PM, Linus Lüssing wrote: > On Fri, Mar 03, 2017 at 01:14:56PM -0300, Felipe Sateler wrote: >> It has been pointed out to me that this may be unrelated to PIE, but >> just caused by a newer GCC version. Could you check if disabling PIE >> makes the binary work again? To do so: >> >> apt-get source sbc >> sudo apt-get build-dep sbc >> cd sbc-1.3 >> DEB_BUILD_OPTIONS=hardening=-pie dpkg-buildpackage -us -uc >> sudo dpkg -i ../libsbc1_*.deb > > Tried it, but still crashes. I also tried: > > 0) dpkg-buildpackage -us -uc > 1) > DEB_BUILD_OPTIONS=hardening=-stackprotectorstrong,-stackprotector,-pie,-fortify > dpkg-buildpackage -us -uc > 2) DEB_BUILD_OPTIONS=hardening=-all dpkg-buildpackage -us -uc > 3) CC=gcc-5 dpkg-buildpackage -us -uc > > But the resulting packages/libraries crash, too. > > ~~~ > $ gcc --version > gcc (Debian 6.3.0-8) 6.3.0 20170221 > $ gcc-5 --version > gcc-5 (Debian 5.4.1-5) 5.4.1 20170205 > ~~~ > > What seems to work though: > ~~~ > $ CC=clang dpkg-buildpackage -us -uc > [...] > $ sudo dpkg -i ../libsbc1_*.deb > ~~~ Thanks for verifying! The problem would not be PIE then. It appears the custom assembler is not compatible with current gcc versions. -- Saludos, Felipe Sateler
Bug#856487: pulseaudio: SIGSEGV upon streaming to bluetooth headset
On Fri, Mar 3, 2017 at 11:06 AM, Felipe Sateler wrote: > Control: tags -1 - help > Control: reassign -1 libsbc1 1.3-1+b2 > Control: retitle -1 libsbc1: build with PIE causes stack corruption > Control: affects -1 pulseaudio > Control: severity -1 serious > > > On Fri, Mar 3, 2017 at 10:52 AM, Linus Lüssing > wrote: >> On Thu, Mar 02, 2017 at 08:36:29PM -0300, Felipe Sateler wrote: >>> Indeed. However, from what I can see the most likely (only?) way to >>> get there is via a sbc_encode that is called in module-bluez5-device. >>> However, that part of the code does not look changed since 9.0. Have >>> you confirmed downgrading to 9.0 fixes the issue? >> >> Oh, sorry, good point. I think we are narrowing it down now: >> >> It's actually not the pulsaudio upgrade from 9.0 to 10 but the >> update of libsbc1 from 1.3-1 to 1.3-1+b2, which I did during the >> same "apt-get dist-upgrade". >> >> Downgrading libsbc1 to 1.3-1 is enough to make the crash vanish! > > OK. That rebuild was done to enable PIE. So it looks like PIE > conflicts with the hand-written asm code, at least for armhf. It seems > to me PIE will have to be disabled there. It has been pointed out to me that this may be unrelated to PIE, but just caused by a newer GCC version. Could you check if disabling PIE makes the binary work again? To do so: apt-get source sbc sudo apt-get build-dep sbc cd sbc-1.3 DEB_BUILD_OPTIONS=hardening=-pie dpkg-buildpackage -us -uc sudo dpkg -i ../libsbc1_*.deb Fortunately the library is small so it shouldn't take that long to build. -- Saludos, Felipe Sateler
Bug#855259: nodejs: FTBFS on alpha architecture
Control: severity -1 important On Wed, 15 Feb 2017 23:15:33 -0600 Bob Tracy wrote: > Source: nodejs > Version: 4.7.2~dfsg-2 > Severity: serious > Justification: fails to build from source alpha is not a release architecture. Thus downgrading to important. Saludos
Bug#855208: runc: 1.0 release candidate breaks docker 1.11 - oci runtime error: flag provided but not defined: -bundle
Package: runc Version: 1.0.0~rc2+git20161109.131.5137186-1 Severity: grave Justification: renders docker unusable Control: affects -1 docker.io After upgrading to 1.0.0~rc2+git20161109.131.5137186-1 , docker containers fail to start: Cannot start service web: rpc error: code = 2 desc = "oci runtime error: flag provided but not defined: -bundle" I don't know what docker version allows usage of runc 1.0 rc. I'm tagging the severity as grave since runc appears to be a component of docker (there are no other rdeps), and docker fails to work with this version. Saludos -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages runc depends on: ii libapparmor1 2.11.0-2 ii libc6 2.24-9 ii libseccomp2 2.3.1-2.1 runc recommends no packages. runc suggests no packages. -- no debconf information
Bug#854896: exim4: Dpkg fails to upgrade exim4 on debian sid.
Hi Andreas! Indeed this host does have ipv6 disabled. After reconfiguring exim4 it finishes the installation and it has been working normally since then. You can close this, as it seems it was a configuration problem on my end rather than a bug with exim4. Thank you for helping out! On 12-02-2017 13:15, Andreas Metzler wrote: > On 2017-02-12 felipe wrote: >>> On 11-02-2017 23:25, Vincent Lefevre wrote: >>>> fev 11 13:57:11 fx8350 exim4[21370]: ALERT: exim paniclog >>>> /var/log/exim4/paniclog has non-zero size…broken > >>> There may be interesting information in this file. > > >> This is the output: > >> $ sudo cat /var/log/exim4/paniclog >> 2017-02-10 11:20:36 socket bind() to port 25 for address ::1 failed: Cannot >> assign requested address: daemon abandoned > [...] > > Hello, > > Have you disabled IPv6 support on this host? If that that the case you'll > need to change the listening interfaces, excluding IPv6 addresses. > > dpkg-reconfigure exim4-config > > cu Andreas >
Bug#854896: exim4: Dpkg fails to upgrade exim4 on debian sid.
Hi, > On 11-02-2017 23:25, Vincent Lefevre wrote: >> fev 11 13:57:11 fx8350 exim4[21370]: ALERT: exim paniclog >> /var/log/exim4/paniclog has non-zero size…broken > > There may be interesting information in this file. > This is the output: $ sudo cat /var/log/exim4/paniclog 2017-02-10 11:20:36 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-10 22:20:48 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 10:57:38 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 11:00:36 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 11:05:42 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 11:13:31 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 11:19:12 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 11:42:11 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 11:51:45 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 13:39:54 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 13:54:40 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 14:01:41 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 14:14:31 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 17:27:53 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 20:56:30 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-11 21:32:06 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned 2017-02-12 12:21:45 socket bind() to port 25 for address ::1 failed: Cannot assign requested address: daemon abandoned >> fev 11 13:57:11 fx8350 systemd[1]: exim4.service: PID file >> /var/run/exim4/exim.pid not readable (y…rectory > I would be interested what this line reads in full, and whether /var/run is a > proper link to /run, and whether /run/exim4 exists. Sorry for the truncated line: fev 12 12:26:49 fx8350 systemd[1]: exim4.service: PID file /var/run/exim4/exim.pid not readable (yet?) after start: No such file or directory $ ll /var/run lrwxrwxrwx 1 root root 4 set 12 2014 /var/run -> /run $ ll /run drwxr-x--- 2 Debian-exim Debian-exim 40 fev 12 12:17 exim4 $ sudo journalctl -xe fev 12 12:26:48 fx8350 systemd[1]: Starting LSB: exim Mail Transport Agent... -- Subject: Unit exim4.service has begun start-up -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit exim4.service has begun starting up. fev 12 12:26:49 fx8350 exim4[3606]: Starting MTA: exim4. fev 12 12:26:49 fx8350 exim4[3606]: ALERT: exim paniclog /var/log/exim4/paniclog has non-zero size, mail system possibly broken fev 12 12:26:49 fx8350 systemd[1]: exim4.service: PID file /var/run/exim4/exim.pid not readable (yet?) after start: No such file or directory fev 12 12:27:29 fx8350 ntpd[822]: 52.67.60.175 local addr 10.1.1.2 -> fev 12 12:28:38 fx8350 ntpd[822]: 52.67.63.45 local addr 10.1.1.2 -> fev 12 12:28:41 fx8350 ntpd[822]: 192.99.2.8 local addr 10.1.1.2 -> fev 12 12:28:41 fx8350 ntpd[822]: 192.155.90.13 local addr 10.1.1.2 -> fev 12 12:29:19 fx8350 ntpd[822]: 200.192.232.8 local addr 10.1.1.2 -> fev 12 12:29:43 fx8350 ntpd[822]: 52.67.171.238 local addr 10.1.1.2 -> fev 12 12:30:01 fx8350 CRON[4122]: pam_unix(cron:session): session opened for user felipe by (uid=0) fev 12 12:30:06 fx8350 CRON[4122]: pam_unix(cron:session): session closed for user felipe fev 12 12:31:19 fx8350 systemd[1]: exim4.service: Daemon never wrote its PID file. Failing. fev 12 12:31:19 fx8350 systemd[1]: Failed to start LSB: exim Mail Transport Agent. -- Subject: Unit exim4.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit exim4.service has failed. -- -- The result is failed. fev 12 12:31:19 fx8350 systemd[1]: exim4.service: Unit entered failed state. fev 12 12:31:19 fx8350 systemd[1]: exim4.service: Failed with result 'resources'. fev 12 12:31:21 fx8350 sudo[2294]: pam_unix(sudo:session): session closed for user root fev 12 12:32:26 fx8350 systemd[1]: Starting Cleanup of Temporary Directories... -- Subject: Unit systemd-tmpfiles-clean.service has begun start-up -- Defined-By: systemd
Bug#854896: exim4: Dpkg fails to upgrade exim4 on debian sid.
Hello! This is the output: $ cat /etc/default/exim4 # /etc/default/exim4 EX4DEF_VERSION='' # 'combined' - one daemon running queue and listening on SMTP port # 'no' - no daemon running the queue # 'separate' - two separate daemons # 'ppp' - only run queue with /etc/ppp/ip-up.d/exim4. # 'nodaemon' - no daemon is started at all. # 'queueonly' - only a queue running daemon is started, no SMTP listener. # setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4 QUEUERUNNER='combined' # how often should we run the queue QUEUEINTERVAL='30m' # options common to quez-runner and listening daemon COMMONOPTIONS='' # more options for the daemon/process running the queue (applies to the one # started in /etc/ppp/ip-up.d/exim4, too. QUEUERUNNEROPTIONS='' # special flags given to exim directly after the -q. See exim(8) QFLAGS='' # Options for the SMTP listener daemon. By default, it is listening on # port 25 only. To listen on more ports, it is recommended to use # -oX 25:587:10025 -oP /var/run/exim4/exim.pid SMTPLISTENEROPTIONS='' On 11-02-2017 15:11, Andreas Metzler wrote: > On 2017-02-11 felipe wrote: >> Package: exim4 >> Version: 4.89~RC3-1 >> Severity: normal > >> Dear Maintainer, > >> apt upgrade fails to upgrade exim4 and exim4-daemon-light. > > [...] > >> fev 11 13:57:10 fx8350 systemd[1]: Starting LSB: exim Mail Transport Agent... >> fev 11 13:57:11 fx8350 exim4[21370]: Starting MTA: exim4. >> fev 11 13:57:11 fx8350 exim4[21370]: ALERT: exim paniclog >> /var/log/exim4/paniclog has non-zero size…broken >> fev 11 13:57:11 fx8350 systemd[1]: exim4.service: PID file >> /var/run/exim4/exim.pid not readable (y…rectory >> fev 11 14:01:41 fx8350 systemd[1]: exim4.service: Daemon never wrote its PID >> file. Failing. >> fev 11 14:01:41 fx8350 systemd[1]: Failed to start LSB: exim Mail Transport >> Agent. >> fev 11 14:01:41 fx8350 systemd[1]: exim4.service: Unit entered failed state. >> fev 11 14:01:41 fx8350 systemd[1]: exim4.service: Failed with result >> 'resources'. > > Hello, > > what is in the exim logfiles? Could you please show your > /etc/default/exim4? > > TIA, cu Andreas >
Bug#853132: pulseaudio-module-jack: modules fail to load due to real-time scheduling
Control: severity -1 normal On 5 February 2017 at 12:06, Vít Novotný wrote: > On Sat, Feb 04, 2017 at 09:59:50AM -0300, Felipe Sateler wrote: >> On 30 January 2017 at 13:33, Vít Novotný wrote: >> > ( 631.872| 0.000) I: [pulseaudio] module-stream-restore.c: Restoring >> > volume for sink input sink-input-by-application-name:mpv Media Player. >> > ( 631.872| 0.000) I: [pulseaudio] module-stream-restore.c: Restoring >> > mute state for sink input sink-input-by-application-name:mpv Media Player. >> > ( 631.872| 0.000) D: [pulseaudio] module-suspend-on-idle.c: Sink >> > alsa_output.pci-_00_1f.3.analog-stereo becomes busy, resuming. >> > ( 631.872| 0.000) D: [pulseaudio] module-suspend-on-idle.c: Sink >> > alsa_output.pci-_00_1f.3.analog-stereo becomes idle, timeout in 5 >> > seconds. >> > ( 631.872| 0.000) D: [pulseaudio] memblockq.c: memblockq requested: >> > maxlength=33554432, tlength=0, base=4, prebuf=0, minreq=1 maxrewind=0 >> > ( 631.872| 0.000) D: [pulseaudio] memblockq.c: memblockq sanitized: >> > maxlength=33554432, tlength=33554432, base=4, prebuf=0, minreq=4 >> > maxrewind=0 >> > ( 631.872| 0.000) I: [pulseaudio] sink-input.c: Created input 9 >> > "audio stream" on alsa_output.pci-_00_1f.3.analog-stereo with sample >> > spec s16le 2ch 44100Hz and channel map front-left,front-right >> >> This shows mpv, in the first attempt, still tries to output to the >> sound card and not to the jack sound server. You can use pavucontrol >> to move the stream from the sound card to the jack server. > > Which is strange, since I changed the default source / sink before I ran > mpv. Not really. As the name suggests, the command only sets the default sink. But there is also the stream-restore module, that remembers where each stream goes, and tries to restore them to the same output they were playing to. > Perhaps this could be the doing of the KDE Plasma component which > spawns pulseaudio, since this beavior no longer occurs if I kill and > manually run pulseaudio. You can also test this by using the KDE control panel to alter the priority of the jack output. > I will test whether this bug persists on > pulseaudio-module-jack 10.0-1 and if so, I will give it a further look > next week. OK. In the meantime, I'm downgrading the severity. -- Saludos, Felipe Sateler
