Bug#934811: webrtc-audio-processing 1.0 available, pipewire will require >= 1.2
On Thu, Sep 14, 2023 at 4:46 PM Jeremy Bícha wrote: > On Thu, Sep 14, 2023 at 3:39 PM Felipe Sateler > wrote: > > This patch adds support for big endian architectures. Are there any in > the archive? > > s390x is the only remaining big-endian Release Architecture for Debian. > > There are other big-endian architectures in ports. > https://wiki.debian.org/ArchitectureSpecificsMemo Would it be to terrible to drop support for that? -- Saludos, Felipe Sateler
Bug#934811: webrtc-audio-processing 1.0 available, pipewire will require >= 1.2
Hi, On Wed, Sep 13, 2023 at 12:29 PM Dylan Aïssi wrote: > Hello all, > > The next version of pipewire depends on webrtc-audio-processing-1 >= 1.2 > for > its echo-canceller module. Although it is an optional dependencies, > upstream > advised me not to disable it to avoid too many complaints. That means, I > won't be able to update pipewire in debian anymore until we have a newer > version > of webrtc-audio-processing-1. > By checking the upstream pulseaudio repo, latest commits are adding > support of > this new webrtc-audio-processing. So, it looks like we'll have to make the > transition soon. > Apart the Jonas's uploads last year, I don't see any recent work on this > pkg, > is there any plan around this transition? > I tried to update webrtc to the latest version, but quickly hit a roadblock: patch big-endian-support.patch does not apply, and the method in question changed enough that I don't know how to port the patch forward. This patch adds support for big endian architectures. Are there any in the archive? -- Saludos, Felipe Sateler
Bug#1005118: module-udev-detect dont work resulting no output device
Control: severity -1 normal Control: tags -1 unreproducible moreinfo On Mon, Feb 7, 2022 at 12:15 PM Elias Tsolis wrote: > Package: pulseaudio > > Version: 14.2 > Severity: serious > Usertags: pulseaudio, alsa, sound card, module-udev-detect, > module-alsa-sink > > BUG after update: PulseAudio: `module-alsa-sink` cannot be loaded > automatically by `module-udev-detect` related also to `sudo alsa > force-reload` which does not solve the problem reporting fail to unload > some modules. > Your installation seems to be broken in some way: > Feb 07 15:48:55 eliasc pulseaudio[110879]: module-detect is deprecated: Please use module-udev-detect instead of module-detect! For some reason module-udev-detect is not found. Did you reboot after upgrading pulseaudio? Or at least, `systemctl --user restart pulseaudio`. Saludos -- Saludos, Felipe Sateler
Bug#1003641: systemd-oomd.service already active, refusing
On Thu, Jan 13, 2022 at 10:03 AM Michael Biebl wrote: > Am 13.01.22 um 08:36 schrieb Jérémy Lal: > > Package: systemd-oomd > > Version: 250.2-2 > > Severity: normal > > > > Hi, > > > > i've installed systemd-oomd 250.2-1 and on upgrade, > > noticed this: > > > > systemd-oomd.socket: Socket service systemd-oomd.service already active, > refusing. > > Failed to listen on Userspace Out-Of-Memory (OOM) Killer Socket. > > > > I'm not sure what should be done. Stop the service, disable the socket ? > > > The behaviour of dh_installsystemd is to treat systemd-oomd.service and > systemd-oomd.socket as completely separate services. > So it generates code for both units to enable/disable and restart those > units (more or less independently). > > You can't really restart a socket unit though which is bound to a > running service. > > What you see is basically a duplicate of > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955483 > > We don't have a good answer here. This probably needs support from > upstream as well. > > As a workaround, we could probably drop the restart/start of > systemd-oomd.socket and only keep the enable/disable/stop-on-removal bits. > > For that we'd need separate calls to the dh_installsystemd override. One > for systemd-oomd.service and one for systemd-oomd.socket. > > This is untested: > > override_dh_installsystemd: > ... > dh_installsystemd -Psystemd-oomd systemd-oomd.service > dh_installsystemd -Psystemd-oomd --no-start --no-stop-on-upgrade > systemd-oomd.socket > > (not quite sure if we need --no-restart-after-upgrade as well). > > This has the downside that the socket is no longer restarted on > upgrades, so changes to the socket unit are not applied. > It has the upside, that it doesn't interfere with the currently running > .service unit. > > Ideally, this would be handled better by systemctl and/or debhelper by > knowing that those units belong together and restarting them in the > correct order. > > I believe the ultimate fix is to actually fix https://github.com/systemd/systemd/issues/8102 upstream. AFAICT, that would resolve everything? > Balint had some thoughts in #955483, but nothing really happened since then > > > > > -- Saludos, Felipe Sateler
Bug#983421: init-system-helpers: please respect DPKG_ROOT when checking for /usr/sbin/policy-rc.d
On Wed, Dec 15, 2021, 13:29 Johannes Schauer Marin Rodrigues < jo...@debian.org> wrote: > Hi Felipe, > > Quoting Felipe Sateler (2021-12-15 19:56:29) > > THanks for your patience. Your MRs are very much welcome. > > thank you for your review! > > > On Mon, Nov 15, 2021 at 10:09 AM Johannes Schauer Marin Rodrigues < > jo...@debian.org> wrote: > > > > https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/17 > > > > > > If you like those changes, I can rebase the DPKG_ROOT patch on top of > it > > > and run the entire test suite with DPKG_ROOT enabled instead of > fakechroot. > > I think we should run both (so that we test both pathways). > > Yes. That's what's implemented in MR 12 already. See override_dh_auto_test > in > debian/rules: > > > https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/12/diffs#8756c63497c8dc39f7773438edf53b220c773f67_41_41 > > Maybe you can merge MR 18 first? Then it becomes easier to make sure that > any > additional changes break nothing because then any change I do to a MR will > trigger the salsa CI: > > https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/18 But this should require mr 17 first, no? > > > Thanks! > > cheers, josch
Bug#983421: init-system-helpers: please respect DPKG_ROOT when checking for /usr/sbin/policy-rc.d
Hi Johannes, THanks for your patience. Your MRs are very much welcome. On Mon, Nov 15, 2021 at 10:09 AM Johannes Schauer Marin Rodrigues < jo...@debian.org> wrote: > Quoting Johannes Schauer Marin Rodrigues (2021-11-15 10:28:49) > > > This is the test I'd like. More precisely, that the tools are doing > what > > > they are supposed to do. > > > > I see that the test suite is using an unpackaged Perl module and > requires root > > to execute. I can rewrite the testsuite to be runnable without root and > to not > > require that unpackaged Perl module. Would you like me to do that? Then > I'd > > first file a merge request for the improved test suite and then rebase my > > DPKG_ROOT patch on top of that once you are satisfied with the testsuite > > improvements. > > https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/17 > > If you like those changes, I can rebase the DPKG_ROOT patch on top of it > and > run the entire test suite with DPKG_ROOT enabled instead of fakechroot. > I think we should run both (so that we test both pathways). -- Saludos, Felipe Sateler
Bug#983421: init-system-helpers: please respect DPKG_ROOT when checking for /usr/sbin/policy-rc.d
On Thu, Nov 11, 2021, 11:45 Johannes Schauer Marin Rodrigues < jo...@debian.org> wrote: > Hi all, > > Quoting Felipe Sateler (2021-11-11 15:14:06) > > Sorry for the delay. > > thank you for your reply. :) > > > I have not been able to look much into this either. I looked at the > patch, > > and it looks somewhat ok, even if a bit extensive. > > if desired, I can greatly reduce the size of the patch by removing the > assertdpkgroot() and assertnotdpkgroot() functions. I used those to make > sure > that the paths as they are passed around in deb-systemd-helper are having > DPKG_ROOT prepended only if desired and if yes, only once. Since our tests > did > not trigger any errors and produces bit-by-bit identical results, I assume > that > it works correctly and theoretically the two assert functions could be > removed, > thus reducing the size of the patch significantly. > My concern is more the non-DRYness of it. What if a new path is added? Do I need to check dpkgroot or not? I think some abstraction is missing in the tools (that is, am I operating on the target or the host?) > > From my own POV, I think the main issue is precisely that we have no way > of > > knowing if this patch would break things or not. Given the centrality of > this > > package, it makes for a slow patch inclusion process. Additionally, I'm > not > > very proficient in perl, which is the primary language here. > > For normal installations, the value of $DPKG_ROOT is the empty string. I > think > it's easy to see that in the normal case, the behaviour of the script > would not > change. > This is the test I'd like. More precisely, that the tools are doing what they are supposed to do. > > What could be very helpful is to actually have some CI that would give me > > (some) certainty a given patch does not break anything. Would it be > possible > > to move (some) of that CI you mention into this repo? > > Yes, certainly. What kind of tests would you like? Right now, there are > still > six source packages that need patching so that the DPKG_ROOT approach > works for > the essential package set. Would you like me to add an autopkgtest that > does > the same thing our CI does, i.e. patches packages, compiles them and then > builds a unstable chroot and makes sure that the chroot tarball is > bit-by-bit > identical to one produced without DPKG_ROOT? > > Or do you want tests for the normal case without DPKG_ROOT? Isn't piuparts > doing installation testing already? What kind of tests would you like me to > write for you? > Honestly I'm a bit uncomfortable here. It is my belief that those who do get to decide. Since I'm not doing much, I believe I don't get to block other's work. I'm thus inclined to merge, and if Johannes can help create a test suite, even better. Since it is very early in the release cycle, I think we can manage the risk. Michael, what do you think? >
Bug#983421: init-system-helpers: please respect DPKG_ROOT when checking for /usr/sbin/policy-rc.d
Hi all, On Wed, Nov 3, 2021 at 11:30 AM Michael Biebl wrote: > On 23.10.21 11:12, Johannes Schauer Marin Rodrigues wrote: > > Hi Michael, > > > > Quoting Johannes Schauer Marin Rodrigues (2021-09-24 21:11:26) > >>> Didn't have time yet to look at this. Sorry. From a cursory glance it > >>> feels inelegant having to sprinkle env vars across everything. > >> > >> indeed, our patch to init-system-helpers is the largest of all the > changes. > >> The advantage of changing init-system-helpers is, that then we don't > have to > >> touch many other maintainer scripts instead. On the up side, the > $DPKG_ROOT > >> variable is empty during normal operation, so prepending $DPKG_ROOT in > front of > >> all paths is unlikely to break anything without > --force-script-chrootless > >> active. > >> > >> Do you have ideas how the diff could be improved? I added the > assertdpkgroot > >> and assertnotdpkgroot functions to make sure that I'm not accidentally > working > >> on paths that have already been modified or should not be modified. > >> > >>> This also feels like it could get easily broken when changes are made. > So I'm > >>> not too enthusiastic tbh. > >> > >> in case things break in the future, our CI job would catch that > breakage and > >> then I'd send you another patch. I see this like other efforts like > cross > >> building or reproducible builds. It's not your task to make sure it's > not > >> breaking but we run a CI system and send you patches once we observe a > >> regression. > >> > >> Needless to say, if something unrelated breaks because of this change, > I'm > >> also here to work on fixing that. > > > > a month passed since my last mail to this bug. Is there anything else I > can do > > to help with this bug? > > > > Unfortunately, I didn't find the time to further look into it. > > Luca, Felipe, Martin, what are your thoughts? > > Sorry for the delay. I have not been able to look much into this either. I looked at the patch, and it looks somewhat ok, even if a bit extensive. >From my own POV, I think the main issue is precisely that we have no way of knowing if this patch would break things or not. Given the centrality of this package, it makes for a slow patch inclusion process. Additionally, I'm not very proficient in perl, which is the primary language here. What could be very helpful is to actually have some CI that would give me (some) certainty a given patch does not break anything. Would it be possible to move (some) of that CI you mention into this repo? -- Saludos, Felipe Sateler
Bug#995941: apt: tries to autoremove currently running kernel
Package: apt Version: 2.3.9 Severity: important Dear Maintainer, apt is trying to autoremove the currently running kernel: % uname -r 5.14.0-1-amd64 % sudo apt autoremove --dry-run Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: linux-image-5.14.0-1-amd64 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. Remv linux-image-5.14.0-1-amd64 [5.14.6-3] % dpkg -l | grep linux-image | grep '^ii' ii linux-image-5.14.0-1-amd64 5.14.6-3 amd64Linux 5.14 for 64-bit PCs (signed) ii linux-image-5.14.0-2-amd64 5.14.9-2 amd64Linux 5.14 for 64-bit PCs (signed) ii linux-image-amd64 5.14.9-2 amd64Linux for 64-bit PCs (meta-package) According to [1], apt should always keep the currently booted kernel. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979631#10 -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::LastInstalledKernel "5.14.0-2-amd64"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^postgresql.*-12"; APT::NeverAutoRemove:: "^postgresql.*-13"; APT::NeverAutoRemove:: "^postgresql.*-14"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null || true; fi"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "false"; APT::Compressor::zstd::Cost "60"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg ""; APT::Compressor::xz::CompressArg:: "-6"; APT::Compressor::xz::UncompressArg ""; APT::Compressor::xz::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::bzip2::CompressArg ""; APT::Compressor::bzip2::CompressArg:: "-6"; APT::Compressor::bzip2::UncompressArg ""; APT::Compressor::bzip2::UncompressArg:: "-d"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "xz"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--format=lzma"; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg ""; APT::Compressor::lzma::UncompressArg:: "--format=lzma"; APT::Compressor::lzma::UncompressArg:: "-d"; Dir "/"; Dir::State "var/lib/apt"; Dir::State::lists "lists/"; Dir::State::cdroms "cdroms.list"; Dir::State::extended_states "extended_states"; Dir::State::status "/var/lib/dpkg/status"; Dir::Cache "var/cache/apt"; Dir::Cache::archives "archives/"; Dir::Cache::srcpkgcache "srcpkgcache.bin"; Dir::Cache::pkgcache "pkgcache.bin"; Dir::Etc "etc/apt"; Dir::Etc::sourcelist "sources.list"; Dir::Etc::sourceparts "sources.list.d"; Dir::Etc::main "apt.conf"; Dir::Etc::netrc "auth.conf"; Dir::Etc::netrcparts "auth.conf.d"; Dir::Etc::parts "apt.conf.d"; Dir::Etc::preferences "preferences"; Dir::Etc::preferencesparts "preferences.d"; Dir::Etc::trusted "trusted.gpg"; Dir::Etc::trustedparts "trusted.gpg.d"; Dir::Etc::apt-listchanges-main "listchanges.conf"; Dir::Etc::apt-listchanges-parts
Bug#994182: headset functionality broken after recent update
On Wed, Sep 15, 2021 at 2:04 PM debian-bugs wrote: > > Hi, > > > > I'm not sure what to do about this issue. > > Well, to me it seems pulseaudio 15 should not not be promoted to testing > until this is sorted out -- given the current boom in video conferencing > due to working from home, a suddenly broken headset will cause a lot of > trouble. (Thankfully, I did not have to work this week so I could spend > three days figuring out what's wrong, couldn't afford this in a work week.) > > AFAIU the issue is caused by a change in the btusb kernel driver and > thus affects most bluetooth devices connected via USB, fixed only in 5.13. I don't know about most. Mine did not have this problem. > So either the fix needs to be back-ported to the current kernel or > pulseaudio needs to include the workaround outlined in the linked report. > At the very, very least users should be warned about a potential > breakage and how to work around that. > By I don't know what to do, I mean that this is strictly speaking not a bug in pulseaudio. The workaround you applied just disables the relevant functionality. -- Saludos, Felipe Sateler
Bug#994182: headset functionality broken after recent update
Hi, I'm not sure what to do about this issue. On Wed, Sep 15, 2021 at 10:57 AM debian-bugs wrote: > Back to pulseaudio and following > > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1247 > > first answer by Igor Kovalenko > This suggest the problem is a kernel problem, but is uncovered by the new HFP profile in pulse. > I edited > > /etc/pulse/default.pa > > to match > > load-module module-bluetooth-discover enable_native_hfp_hf=false > > and with that parameter (enable_native_hfp_hf=false) things are back to > normal. > Couldn't find out what the equivalent setting for pipewire would be, > that's why I went back to pulse. > > Positive side effect: ofono seems not to be necessary anymore. > This is the new feature :) -- Saludos, Felipe Sateler
Bug#993947: Time lost, /etc/systemd/timesyncd.conf gets replaced with a default one
On Thu, Sep 9, 2021 at 5:01 PM Michael Biebl wrote: > Am 09.09.21 um 16:15 schrieb Michael Biebl: > > Am 09.09.21 um 15:15 schrieb Felipe Sateler: > >> It should give us the guarantees[1]: > >> > >> > The postinst script may be called in the following ways: > >> > postinst configure most-recently-configured-version > >> > The files contained in the package will be unpacked. > >> > All package dependencies will at least be “Unpacked”. > >> > If there are no circular dependencies involved, > >> > all package dependencies will be configured > >> > >> AFAICS we don't have circular dependencies, but maybe the versioned > >> breaks/replaces + versioned depends makes dpkg think there is one? > > > > Hm, we do have systemd -> systemd-timesyncd | time-daemon and > > systemd-timesyncd -> systemd > > > > This is a circular dep afaiu. > > > > I guess the only way to break this dep cycle is to drop (or rather > demote) the Depends: systemd-timesyncd | time-daemon to a Recommends. > > To ensure that systemd-timesyncd is installed during the initial > bootstrap, we'd have to bump it's prio, similar to what we did for > libpam-systemd. Either important or standard. > > Related here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986651 > > If we can get such a change into bullseye remains to be seen. > > Does anyone else have a different idea how to approach this? > > No, I don't have any other idea. Perhaps the installer or apt teams have any ideas? -- Saludos, Felipe Sateler
Bug#993947: Time lost, /etc/systemd/timesyncd.conf gets replaced with a default one
Hi, On Thu, Sep 9, 2021 at 5:12 AM Michael Biebl wrote: > Hi Felipe > > Am 08.09.21 um 19:25 schrieb Michael Biebl: > > systemd-timesyncd was split into a separate binary package in bullseye. > > Transferring the ownership of the conffile from systemd to > > systemd-timesyncd is a tricky business as dpkg does not have native > > support for that and so we need to go behind dpkg's back for that. > > > > We do have some custom maintainer scripts code where we try to preserve > > local modifications: > > > https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd-timesyncd.postinst > > This code is based on > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797048 > i.e. > > https://salsa.debian.org/systemd-team/systemd/commit/f5f5028055f25fa733a45265e7c008e06960e0a7 > > A typescript log from an upgrade is attached. > One can see, that systemd-timesyncd.postinst is run before > systemd.postinst and as a result timesyncd.conf.dpkg-bak does not exist > yet. > > Afaics, this could only be fixed with a versioned Pre-Depends on systemd > (>= 245.4-2). I don't think a Depends gives us any guarantees regarding > the order postinst is run? > It should give us the guarantees[1]: > The postinst script may be called in the following ways: > postinst configure most-recently-configured-version > The files contained in the package will be unpacked. > All package dependencies will at least be “Unpacked”. > If there are no circular dependencies involved, > all package dependencies will be configured AFAICS we don't have circular dependencies, but maybe the versioned breaks/replaces + versioned depends makes dpkg think there is one? [1] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called -- Saludos, Felipe Sateler
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#982907: init-system-helpers: use new needs-reload/needs-restart unit interface
Hi! On Tue, Aug 24, 2021 at 2:38 PM Niels Thykier wrote: > Control: reassign -1 init-system-helpers > > Reassigning to init-system-helpers, quoting in full for the > init-system-helpers maintainer's sake. > > On Tue, 16 Feb 2021 21:46:28 +0100 Niels Thykier > wrote: > > Luca Boccassi: > > > Source: debhelper > > > Priority: wishlist > > > Tags: bookworm > > > X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org > > > > > > Dear Maintainer(s), > > > > > > systemd v248 will ship with a new dbus/systemctl interface to mark a > > > unit as needing reload/restart, and a new dbus/systemctl to queue all > > > reload/restart jobs in a single command. > > > The RPM packaging/scripts are changing to use this instead of custom > > > batching. > > > > > > I'm opening this ticket to explore whether it would be > > > possible/good/desirable to switch the debhelper tools to use this as > > > well in the future. > > > > > > It looks like this: > > > > > > systemctl set-property foo.service Markers=needs-restart > > > systemctl set-property bar.service Markers=needs-reload > > > ... > > > systemctl reload-or-restart --marked > > > > > > (or equivalent DBUS calls) > > > > > > References: > > > > > > > https://github.com/systemd/systemd/commit/ff68472a20c208121b69ea13586f3105a219bc14 > > > > https://github.com/systemd/systemd/commit/c9615f73521986b3607b852c139036d58973043c > > > https://github.com/systemd/systemd/pull/18481/commits > > > > > > The advantage being, you can mark a unit inline, but then batch the > > > actual jobs later/asynchronously. > > > > > > Note that, given the interface has just been merged and is not yet > > > released, there is scope for improvements if there are debhelper- > > > specific concerns to address, given the feature first use is the RPM's > > > side of things. > > > > > > Thoughts? > > > > > > > By the sound of it, this is something that might need to go into the > > init system helpers that debhelper invokes in the maintscripts (possibly > > with a trigger in the systemd side to do the batch reload/restart). > > > > @Michael: What is your view? > > > Not Michael, but if I can offer my thoughts, this is not something that could be done in i-s-h (or at least, not something that we could do transparently). This is because presumably there are postinst scripts that assume post-debhelper-block the new version is already running. So I believe what would be needed is: 1. Support in i-s-h to activate this mode, probably via a new flag. 2. Support in debhelper to enable/disable this new method. 3. A trigger in systemd to do the final reload. I believe requiring the new daemon version to be already updated by postinst time would be quite rare, so I think point 2 could be enabled by default in a new compat level. Thoughts? -- Saludos, Felipe Sateler
Bug#991597: pulseaudio: Please enable GStreamer support
Hi! On Wed, Jul 28, 2021 at 5:24 AM Laurent Bigonville wrote: > Source: pulseaudio > Version: 14.99.2+dfsg1-1 > Severity: wishlist > > Hello, > > Would be nice to enable the GStreamer support in pulseaudio so more > codecs are supported for the bluetooth headsets (LDAC, AptX and maybe > AAC later) > > ATM the support/elements in GStreamer are still missing (coming in the > next release), but we could already prepare the pulseaudio side. > Does that mean that enabling it, would only add some dependencies but not actually do anything? -- 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#989845: pulseaudio: Needless Depends: on libasound2-plugins should be turned back into Recommends:
Control: tags -1 help On Mon, Jun 14, 2021 at 2:51 PM Dennis Filder wrote: > Package: pulseaudio > Version: 14.2-2 > Severity: normal > Control: found -1 0.99.1-1 > X-Debbugs-CC: d.fil...@web.de > > While investigating #963582 I took a closer look at the dependencies > of pulseaudio, and I noticed something odd: As part of the changes for > 0.99.1-1 the Recommends: on libasound2-plugins hard-coded in > debian/control was turned into a Depends:. The commit message in > question[0] just reads: "tweak depends slightly" which is very quaint > considering that the transitive Depends: closure of libasound2-plugins > includes (among others) libavcodec58 and weighs in at a grand total of > 200 MB. The context of the changelog suggests that this was done to > make the package more similar to how Ubuntu packages pulseaudio, and > the maintainer just didn't realize the ramifications. > > Considering that this was probably just a mistake and the inordinate > amount of additional disk space usage incurred by it I think this > change should be undone. > Well, without libasound2-plugins plain alsa apps cannot output to pulseaudio. That's the reason we want it. OTOH, this may fit the definition of "all but unusual installations". Happy to review a salsa MRs, especially if they also address 963582. It is obviously too late for bullseye, but we can target the next release, and doing this sort of change at the beginning of the cycle might be a good idea. -- 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#986007: Merge request to close this bug
Hi, Sorry, I have not had time for this in a while (and things are not looking good in the near future). I have granted the debian group commit access. Please do NMU and push the changes to the git repository. On Sat, Mar 27, 2021, 17:09 Thomas Goirand wrote: > Hi, > > Please merge this: > > > https://salsa.debian.org/docker-compose-team/python-docker/-/merge_requests/3 > > > Cheers, > > Thomas Goirand (zigo) > >
Bug#803329: pulseaudio: Bash completion files provided by wrong package
On Sun, Mar 7, 2021 at 9:20 PM Kevin Locke wrote: > On Fri, 2015-10-30 at 08:55 +0100, Francois Gouget wrote: > > On Wed, 28 Oct 2015, Felipe Sateler wrote: > >> What problem does this cause? Or what benefits does it cause to use > >> the correct package? I don't really want to complicate the packaging. > > > > Anyway, here's another reason: it's possible to install pulseaudio-utils > > without installing pulseaudio. > > I just ran into this issue as you described. I have pulseaudio-utils > installed, but not pulseaudio (because I am using PipeWire as a > PulseAudio substitute[1]). > > I sympathize with your desire to avoid complicating the packaging. > Splitting the completion file looks non-trivial. Might I suggest > shipping a copy of the completion file in the pulseaudio package as > /usr/share/bash-completion/completions/pulseaudio and a copy in the > pulseaudio-utils package as /usr/share/bash-completion/completions/pacmd > with symlinks for the other commands provided by that package? This way > a completion for each command is shipped in the same package. The 15kB > of duplicated data seems reasonable, if not ideal, to avoid divergence > from upstream, or the packaging work of creating a -common package just > for completions. This is not really needed. pulseaudio already depends on pulseaudio-utils. I would accept a patch moving the completion files to the pulseaudio-utils package. -- Saludos, Felipe Sateler
Bug#979281: pulseaudio should reduce unnecessary Build-Depends
Control: tags -1 pending
On Mon, Jan 4, 2021 at 7:12 PM Helmut Grohne wrote:
> Source: pulseaudio
> Version: 13.0-5
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> pulseaudio is involved in a number of dependency cycles relevant to
> architecture bootstrapping. Those are hard to solve, but without looking
> into detail, a number of dependencies can be easily dropped:
>
> * check is only used for unittests. Therefore it can be skipped with
>the build profile.
> * libsamplerate0-dev is deprecated in pulseaudio and only enabled when
>explicitly passing --enable-libsamplerate. The package hasn't done
>this and therefore libsamplerate is unused.
> * libjson-c-dev is unused since version 10.0 where pulseaudio adopted
>its own json parsing library. See NEWS.
>
> This seems all quite straight forward, no? Please apply the attached
> patch
>
Thanks! Applied.
I suspect this won't help you very much in the bootstrap process. I figure
what is needed is a build profile that builds only libpulse{0,-dev}. Happy
to take patches for it.
--
Saludos,
Felipe Sateler
Bug#979113: libpulse-dev: lib .so files in -dev package, cause other programs to fail
Control: reassign -1 xcwcp
Control: retitle -1 xcwcp: should dlopen SO-versioned libpulse-simple
On Sun, Jan 3, 2021 at 4:30 PM Christoph Berg wrote:
> Re: To Federico Grau
> > const char *library_name = "libpulse-simple.so";
> > if (!cw_dlopen_internal(library_name, &(cw_pa.handle))) {
> >
> > Federico: do you want to do that change? (Please check if the fix is
> > only for xcwcp or also for the other binaries in the unixcw source.)
>
> Or perhaps better, change the above to library_name =
> "libpulse-simple.so.0";
>
Indeed, this is what needs to be done. Should libpulse-simple change it's
ABI, xcwcp might crash instead of giving the correct error message
(libpulse-simple not found).
--
Saludos,
Felipe Sateler
Bug#973736: buster-pu: package pulseaudio/12.2-4+deb10u2
Hi Salvatore, Sorry for the delay. On Sun, Nov 22, 2020, 13:18 Salvatore Bonaccorso wrote: > hi stable release managers, hi Felipe, > > On Wed, Nov 04, 2020 at 09:33:21AM +0100, Salvatore Bonaccorso wrote: > > Package: release.debian.org > > Severity: normal > > Tags: buster > > User: release.debian@packages.debian.org > > Usertags: pu > > X-Debbugs-Cc: car...@debian.org,fsate...@debian.org > > > > Hi SRM, hi Felipe > > > > [ Reason ] > > > > pulseaudio's deamon.conf uses the (for that version of upstream) the > > default of yes for flat-volumes. The flat-volumes value enables to > > 'flat' volumes, the sink volume equal the maximum of the volumes of > > the inputs connected to it. But this can cause quite some surprised > > and problems and can hurt ears depending on e.g. headphones values. > > > > So some distributions have changed that already in past > > and upstream did as well in later versions. > > > > In unstable the change was done in the 13.0-3 upload. > > > > [ Impact ] > > > > So far users probably stumpling over the problem have changed away > > form the default in their configuration. > > Any comment on this proposed update? Although I completely see the > point as it is changing a default in stable, I still wonder if we > should do it because it has been switched upstream and was a problem > several times for reporting user. > I don't think this change is in scope for a stable update. While I agree it has been problematic for many users, and that this setting has great relevance, this same impact makes me doubt it is fit for a stable update. This is not a bugfix, it is a change in the default value of a setting. Even if I agree with the new value, I don't think it is the sort of change people expect in a stable update. For the RT: this setting changes the behavior of the volume controls. Current behavior in stable is to move the master volume along with the loudest app volume (which creates the problem of a single app raising your volume to very high levels). Current behavior in unstable is to decouple them: app volume is now relative to the master volume. This is all based on my understanding of how stable should remain stable. I have no technical issue with backporting the setting change. Therefore, if the release team deems the change in setting as appropriate, I won't object (and very much welcome if you could upload it). Saludos
Bug#466946: On starting (and stopping) rngd
ts version 6.x, > but the version “traditionally shipped with Debian” contains > a lot of new functionality that never made it upstream and > as such has many users; arngc, for example, requires this > functionality, as do others (cf. #951799). > > Thanks in advance, > //mirabilos > -- > 22:20⎜ The crazy that persists in his craziness becomes a master > 22:21⎜ And the distance between the craziness and geniality is > only measured by the success 18:35⎜ "Psychotics are consistently > inconsistent. The essence of sanity is to be inconsistently inconsistent > > -- Saludos, Felipe Sateler
Bug#971282: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d
On Mon, Oct 5, 2020 at 1:02 PM Michael Biebl wrote: > Am 05.10.20 um 17:25 schrieb Felipe Sateler: > > I think the plan should be: > > > > 1. Change debhelper and i-s-h to install to /usr > > I assume you mean, that dh_installsystemd/dh_systemd should install > debian/foo.service and debian/foo.udev to /usr/lib? > Correct, that's what I mean. > > Should debhelper also actively move files from /lib to /usr/lib when > they are installed to /lib by the upstream build system? > Hmm, interesting idea. On the one hand, we didn't do it for /lib. On the other hand, it would probably save a lot of churn. > > We need to decide whether to tie that to a compat bump (in which case it > would be a very slow process) or whether to do that unconditionally. > I think the lintian maintainers would have a preference here. If we do it, I would prefer unconditionally, but they might prefer a new compat level. I'm not sure if debhelper does look in /usr/lib/systemd/system. If not, that needs to be fixed. > > > 2. Change the lintian warnings to point to /usr > > 3. Drop the /lib mangling from all the manpages > > 4. Wait a lot :(. At least a full release cycle, I think. > > 5. Drop the split and install fully to /usr, with some compat links for > > non-merged-/usr. > > I guess we only need compat symlinks for binaries in /bin. We need to > determine if we create symlinks for all of them or only for a select few > ones, which would have a high impact and would cause unnecessary churn. > > A few more bullet points > - Add support to udev to run udev helper binaries from both paths (see > the patch in my MR). > Right. Ideally, only for the transition period. > > - Change systemd.pc and udev.pc and point udevdir to /usr/lib/udev and > let the various systemd paths point to /usr/lib/. > This will likely break a few packages, so it would probably be good to > do a archive wide rebuild of packages build-depending on systemd or udev. > I believe doing systemd first is easier (it already has the logic for multi-path search). Do you think doing both udev and systemd at the same time is better? -- Saludos, Felipe Sateler
Bug#971282: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d
On Thu, Oct 1, 2020 at 4:09 PM Michael Biebl wrote: > On Mon, 28 Sep 2020 20:43:30 -0300 Felipe Sateler > wrote: > > On Mon, Sep 28, 2020 at 4:03 PM Michael Biebl wrote: > > > > > Package: systemd > > > Version: 246.6-1 > > > Severity: important > > > > > > Upstream changed the paths in systemd.pc from prefix to rootprefix in > > > v246 for sysusers_dir, sysctl_dir, binfmt_dir and modules-load_dir: > > > > > > > https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b > > > > > > This breaks packages which use pkg-config to determine those paths and > > > where .install files reference /usr/. An example is mandos. > > > > > > I think we should revert this change. I don't see a compelling reason > to > > > move those files from /usr to /lib given that we require /usr to be > > > pre-mounted by initramfs, if it's separate. > > > Moving files from /usr to /lib files kinda backwards nowadays. > > > > > > I intend to apply a patch like the attached one in Debian. > > > That said, I hope I can convince Lennart to revert this change upstream > > > as well. > > > > > > > Looks good to me. > > Ok, thanks for the review. Will apply it to Debian then. > It doesn't look like upstream is interested in changing this back > > > https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b#commitcomment-42793750 > > > > > > > > > Thoughts, Comments? > > > > > > > I wonder if systemd can be fully installed into `/usr` now that we > require > > premounting. Maybe we should start changing lintian and other tools to > > install into /usr instead of /lib for the tools that currently used > > rootprefix (I believe systemd searches in /usr anyway). > > I gave this a try. It can. > See https://salsa.debian.org/systemd-team/systemd/-/merge_requests/104 > Still very rough, but the package is usable and able to boot a system, > reading udev rules and systemd services from both /lib and /usr/lib. > We probably need quite a few more compat symlinks though. > > This is only the systemd/udev side, though. > The i-s-h/debhelper side is still missing and we'd need to hash out a > plan for this. I'd need help with doing that. > Anyone interested? > I think this is where we should start (i-s-h/debhelper/lintian). I'll try to take a look over the weekend. It's a long weekend over here so I might have some time to take a look. I think the plan should be: 1. Change debhelper and i-s-h to install to /usr 2. Change the lintian warnings to point to /usr 3. Drop the /lib mangling from all the manpages 4. Wait a lot :(. At least a full release cycle, I think. 5. Drop the split and install fully to /usr, with some compat links for non-merged-/usr. What do you think? -- Saludos, Felipe Sateler
Bug#971282: ABI breakage: paths changed for sysusers.d/sysctl.d/binfmt/modules-load.d
On Mon, Sep 28, 2020 at 4:03 PM Michael Biebl wrote: > Package: systemd > Version: 246.6-1 > Severity: important > > Upstream changed the paths in systemd.pc from prefix to rootprefix in > v246 for sysusers_dir, sysctl_dir, binfmt_dir and modules-load_dir: > > https://github.com/systemd/systemd/commit/4a56315a990b802860170ecd1bbd3eb68e14a38b > > This breaks packages which use pkg-config to determine those paths and > where .install files reference /usr/. An example is mandos. > > I think we should revert this change. I don't see a compelling reason to > move those files from /usr to /lib given that we require /usr to be > pre-mounted by initramfs, if it's separate. > Moving files from /usr to /lib files kinda backwards nowadays. > > I intend to apply a patch like the attached one in Debian. > That said, I hope I can convince Lennart to revert this change upstream > as well. > Looks good to me. > > Thoughts, Comments? > I wonder if systemd can be fully installed into `/usr` now that we require premounting. Maybe we should start changing lintian and other tools to install into /usr instead of /lib for the tools that currently used rootprefix (I believe systemd searches in /usr anyway). This is likely to be a multi-release effort, but if we never start, we will never end. -- Saludos, Felipe Sateler
Bug#965230: closed by Felipe Sateler (Re: Bug#965230: pulseaudio: writes to mount point prior to /tmp being mounted)
(Please keep the bug on CC). On Tue, Jul 28, 2020 at 11:27 AM Edmund H. Ramm wrote: > Estimado Felipe, > > Felipe Sateler writes: > > > [...] > > Anyway, those directories are created when there is no runtime directory > > for pulseaudio to use. That this is happening before /tmp is mounted, it > > means that something is trying to use pulseaudio that early during boot. > > That then it is created again, means some other user (or your own user, > but > > in an unclean environment) is trying to use pulseaudio. > > > > Who owns that directory? Do you have logs that may show who is creating > > that? > >if I had, I'd supplied them. The user is (was) root, and the temporary > directory is created from initramfs without leaving a trace in the journal. > The only hint that something went wrong is when /tmp gets mounted on a then > no longer clean mount point. > This is very weird. The initramfs should have an in-memory /tmp. Are you sure it is created in the intiramfs? -- Saludos, Felipe Sateler
Bug#965230: closed by Felipe Sateler (Re: Bug#965230: pulseaudio: writes to mount point prior to /tmp being mounted)
Control: reopen -1 On Sat, Jul 18, 2020 at 3:25 PM Edmund H. Ramm wrote: > Estimado Felipe, > >what further information apart from that provided by reportbug, the > questions I answered to reportbug, the subject "pulseaudio writes to > /tmp mount point prior to /tmp being mounted" and a name pattern > (pulse-PKdhtXMmr18n) of the directories pulseaudio writes to the > /tmp mount point prior to /tmp being mounted, do you require? Maybe > that, a few seconds later, after /tmp (sda9 in my case) finally has > been mounted, a directory with exactly the same name gets created > there? > Sorry. I didn't see the last part of the message (I saw the empty template questions). Sorry for the blunt message. >Please let me know what further information is needed. > Anyway, those directories are created when there is no runtime directory for pulseaudio to use. That this is happening before /tmp is mounted, it means that something is trying to use pulseaudio that early during boot. That then it is created again, means some other user (or your own user, but in an unclean environment) is trying to use pulseaudio. Who owns that directory? Do you have logs that may show who is creating that? -- Saludos, Felipe Sateler
Bug#769895: init-system-helpers: deb-systemd-helper should remove timestamps on timer unit purge
Hi Michael, Sorry for the delay, I forgot to actually send :( On Sat, Jul 4, 2020, 14:06 Michael Biebl wrote: > Hi Felipe > > On Tue, 20 Dec 2016 09:46:38 -0300 Felipe Sateler > wrote: > > Control: forwarded -1 https://github.com/systemd/systemd/issues/4930 > > > > On Mon, 17 Nov 2014 12:46:38 +0100 Alexandre Detiste > > wrote: > > > Package: init-system-helpers > > > Version: 1.21 > > > Severity: minor > > > > > > Dear Maintainer, > > > > > > When a timer unit with flag "Persistant=true" is purged, > > > a loose time stamp (0 byte file) is left loose > > > in /var/lib/systemd/timers/stamp-.timer > > > > > > This file could be safely removed by deb-systemd-helper during a purge. > > > > I'd really rather not rely on implementation details. I have forwarded > > the bug to systemd upstream so they provide an interface to clear the > > stamp files. When that is done, we can add that invocation in > > deb-systemd-helper. > > We now do have a "systemctl clean" interface. > Should we simply run that unconditionally on deb-systemd-helper purge? > For all unit types or only timers? > Maybe we could just have a trigger in systemd? > I also note, that this apparently doesn't work in chroots: > # systemctl clean apt-daily.timer > Running in chroot, ignoring request: clean > Bummer, but I don't think it is too important. After all, chroots wouldn't have run systemd in the first place, and thus wouldn't have the file. > Not sure if this is something we should be concerned about. > I don't think it is too important. After all, this is mostly a nice to have. Saludos > Regards, > Michael > > > >
Bug#963211: libmu-dbm6: Tries to overwrite `libmu_dbm.so.6.0.0` from `libmailutils6`
Control: severity -1 serious On Sat, 20 Jun 2020 18:08:58 +0200 Paul Menzel wrote: > Package: libmu-dbm6 > Version: 1:3.9-2 > > > Dear Debian folks, > > > Trying to update my Debian Sid/unstable system, `apt full-upgrade` > failed with the messages below. > > > dpkg: Fehler beim Bearbeiten des Archivs /tmp/apt-dpkg-install-9C7NlK/00-libmu-dbm6_1%3a3.9-2_i386.deb (--unpack): > > Versuch, »/usr/lib/i386-linux-gnu/libmu_dbm.so.6.0.0« zu überschreiben, welches auch in Paket libmailutils6:i386 1:3.7-2.1 ist > > dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Datenübergabe unterbrochen (broken pipe)) getötet > > It looks like some conflict needs to be added? Raising severity to serious since this makes the package uninstallable
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#958286: pavucontrol: Missing escaping of & in device names
On Sat, Apr 25, 2020 at 2:34 AM Tollef Fog Heen wrote: > ]] Felipe Sateler > > > So, I could not reproduce the issue by setting bluez.alias either. > > > > Does the console error happen on applicatin startup? Or when switching > to a given tab? > > It shows up when the device connects, so either at startup or when I > turn on the headphones. > > I think maybe the problem is related to the «Configuration» tab, since > the headset is listed there with just «Card Name» as the name. It's > shown correctly on both the Playback and Output Devices tabs. > Ah, so it is the "card" that is the problem, not the sink. That explains why I couldn't reproduce. > > --- pavucontrol-4.0.orig/src/mainwindow.cc > +++ pavucontrol-4.0/src/mainwindow.cc > @@ -368,7 +368,7 @@ void MainWindow::updateCard(const pa_car > > description = pa_proplist_gets(info.proplist, > PA_PROP_DEVICE_DESCRIPTION); > w->name = description ? description : info.name; > -w->nameLabel->set_markup(w->name.c_str()); > +w->nameLabel->set_text(w->name.c_str()); > > icon = pa_proplist_gets(info.proplist, PA_PROP_DEVICE_ICON_NAME); > set_icon_name_fallback(w->iconImage, icon ? icon : "audio-card", > Gtk::ICON_SIZE_SMALL_TOOLBAR); > > seems to fix it for me. (You could also use g_markup_printf_escaped, I > guess). > I see now that this is already fixed in upstream git. I'll upload the fix shortly. -- Saludos, Felipe Sateler
Bug#958286: pavucontrol: Missing escaping of & in device names
On Tue, Apr 21, 2020 at 2:04 PM Tollef Fog Heen wrote: > ]] Felipe Sateler > > > Could you share the output of `pactl list sinks`? It appears the problem > is not really in the device description. > > Sink #11 > State: IDLE > Name: bluez_sink.EC_66_D1_XX_XX_XX.headset_head_unit > Description: Bowers & Wilkins PX > Driver: module-bluez5-device.c > Sample Specification: s16le 1ch 8000Hz > Channel Map: mono > Owner Module: 31 > Mute: no > Volume: mono: 37987 / 58% > balance 0.00 > Base Volume: 65536 / 100% > Monitor Source: > bluez_sink.EC_66_D1_XX_XX_XX.headset_head_unit.monitor > Latency: 24995 usec, configured 28000 usec > Flags: HARDWARE HW_VOLUME_CTRL LATENCY > Properties: > bluetooth.protocol = "headset_head_unit" > device.intended_roles = "phone" > device.description = "Bowers & Wilkins PX" > device.string = "EC:66:D1:XX:XX:XX" > device.api = "bluez" > device.class = "sound" > device.bus = "bluetooth" > device.form_factor = "headphone" > bluez.path = "/org/bluez/hci0/dev_EC_66_D1_XX_XX_XX" > bluez.class = "0x240418" > bluez.alias = "Bowers & Wilkins PX" > device.icon_name = "audio-headphones-bluetooth" > Ports: > headphone-output: Hovudtelefonar (priority: 0, available) > Active Port: headphone-output > Formats: > pcm > > So, I could not reproduce the issue by setting bluez.alias either. Does the console error happen on applicatin startup? Or when switching to a given tab? -- Saludos, Felipe Sateler
Bug#958286: pavucontrol: Missing escaping of & in device names
Control: tags -1 moreinfo On Mon, Apr 20, 2020 at 2:24 AM Tollef Fog Heen wrote: > Package: pavucontrol > Version: 4.0-1 > Severity: minor > > I have a bluetooth headset from Bowers & Wilkins. It seems like > pavucontrol fails to escape the «&» in the name before feeding it to > GTK, leading to console errors like: > > (pavucontrol:416883): Gtk-WARNING **: 20:28:02.902: Failed to set text > 'Bowers & Wilkins PX' from markup due to error parsing markup: Error on > line 1: Entity did not end with a semicolon; most likely you used an > ampersand character without intending to start an entity — escape > ampersand as > I can't reproduce: % pactl load-module module-null-sink sink_name="test-sink" 32 % pacmd update-sink-proplist test-sink device.description='"A & B"' % pavucontrol % Could you share the output of `pactl list sinks`? It appears the problem is not really in the device description. -- Saludos, Felipe Sateler
Bug#958178: pavucontrol: segfault on quit
Control: forcemerge 947376 -1 On Sun, Apr 19, 2020 at 8:15 AM David Bremner wrote: > Package: pavucontrol > Version: 4.0-1 > Severity: normal > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > Pavucontrol crashes with a segfault when quitting (C-q). > > Thread 1 "pavucontrol" received signal SIGSEGV, Segmentation fault. > 0x77d8b2b1 in Gtk::Main::quit() () from > /usr/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1 > (gdb) bt > #0 0x77d8b2b1 in Gtk::Main::quit() () at > /usr/lib/x86_64-linux-gnu/libgtkmm-3.0.so.1 > This is #947376. Anyway, I have filed https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/merge_requests/31 upstream which should work around the issue. -- Saludos, Felipe Sateler
Bug#956672: rtkit activation fails, because service unit is installed at the wrong place
On Sun, Apr 19, 2020 at 4:45 PM Boyuan Yang wrote:
> Control: tags -1 -pending +patch
> X-Debbugs-CC: sate...@debian.org
>
> Alright -- I think I got the reason.
>
> Since we switched to meson buildsystem, all variable handling happens in
> meson.build. Starting at
>
> https://salsa.debian.org/multimedia-team/rtkit/-/blob/0a0f6d58f792f8dcf38f9b0b4cf925e9f4f4337d/meson.build#L61
> :
>
> systemunitdir = ''
> if systemunitdir == '' and systemd_dep.found()
> systemunitdir = systemd_dep.get_pkgconfig_variable(
> 'systemdsystemunitdir',
> default: '',
> )
> endif
> if systemunitdir == ''
> systemunitdir = get_option('libdir') / 'systemd' / 'system'
> endif
>
>
OK, so the problem is that the `systemunitdir = ''` at the first line is
wrong. It should be `systemunitdir = get_option('systemd_systemunitdir')`
(like the polkit_actiondir block a few lines up).
NMU welcome ;). Otherwise I'll take a look over the weekend.
--
Saludos,
Felipe Sateler
Bug#956573: pulseaudio: Pulseaudio crashes when playing stepmania/performous
Control: tags -1 moreinfo On Mon, Apr 13, 2020 at 4:09 AM Bernat Arlandis wrote: > Package: pulseaudio > Version: 12.2-4+deb10u1 > Severity: normal > > Dear Maintainer. > > These games played fine before updating the kernel. Version 4.19.0-6 works > well, but 4.19.0-8 crashes pulseaudio. > > I've tried the kernel in backports (5.4) and it crashes pulseaudio too. > Please provide a backtrace and a verbose log. -- Saludos, Felipe Sateler
Bug#955483: Alphanumeric ordering of depending sockets breaks restart
On Thu, Apr 2, 2020, 04:53 Guido Günther wrote: > control: reassign -1 systemd > control: retitle -1 systemd fails to restart socket unit of already > running service > > Dear systemd maintainers > On Wed, Apr 01, 2020 at 03:52:35PM +0200, Christian Ehrhardt wrote: > > Thanks, from that POV it makes sense. > > I'm not good at re-assigning debian bugs could one of you please do so > > to affect system as well? > > The tl;dr; version is that > > systemctl restart libvirtd.socket > > fails like > > Job failed. See "journalctl -xe" for details. > > Apr 02 09:29:57 foo systemd[1]: libvirtd.socket: Socket service > libvirtd.service already active, refusing. > Apr 02 09:29:57 foo systemd[1]: Failed to listen on Libvirt local > socket. > > if libvirtd.service is already running (libvirtd.socket has): > > [Socket] > ListenStream=/run/libvirt/libvirt-sock > Service=libvirtd.service > SocketMode=0666 > > and libvirtd.service is > https://salsa.debian.org/libvirt-team/libvirt/-/blob/debian/sid/src/remote/libvirtd.service.in > > The issue that this also happens in libvirt-daemon-system's postinst so > a restart of the socket unit does not seem to be possible. This could > be worked around by not restarting the socket units (changes in the > socket units seem to be picked up when restarting libvirtd.service > as well) but that would give problems when switching to socket only > activation. > > Since this looks like a common problem i'm likely missing something. > I have always thought that every service should have Requires= all the sockets it uses. Does it fix the problem? Stooping only the socket should either crash the daemon or stop it gracefully first. I would think the latter is much better.
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#954434: pulseaudio-module-bluetooth: Adds Sony LDAC, aptX, aptX HD, AAC codecs (A2DP Audio) support to PulseAudio on Linux
Control: tags -1 moreinfo On Sat, Mar 21, 2020 at 12:33 PM Stefano F. wrote: > Package: pulseaudio-module-bluetooth > Version: 13.99.1-1 > Severity: wishlist > Tags: upstream > > Dear Maintainer, > > it would be nice to have non-free alternative package for A2DP codecs for > modern true wireless earbuds supporte codecs with the packaging of[1]. > > See also[2][3][4] > > [1]https://github.com/EHfive/pulseaudio-modules-bt > [2] > https://github.com/EHfive/pulseaudio-modules-bt/wiki#are-there-any-plans-to- > upstream-this-into-pulseaudio > <https://github.com/EHfive/pulseaudio-modules-bt/wiki#are-there-any-plans-to-upstream-this-into-pulseaudio> > [3]https://github.com/EHfive/pulseaudio-modules-bt/issues/3 > [4] > https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality- > on-linux/ > <https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality-on-linux/> I'm not sure what you are proposing. If you want these modules to be packaged, please help with getting #794692 resolved and then file a RFP for the modules. -- Saludos, Felipe Sateler
Bug#954030: pulseaudio: Pulseaudio does not start in xrdp session. Error in startup script.
Control: tags -1 moreinfo On Sun, Mar 15, 2020 at 9:15 PM Bob Hauck wrote: > Package: pulseaudio > Version: 13.0-5 > Severity: normal > Tags: patch > > Dear Maintainer, > > I run KDE in a virtual machine using XRDP. For sound support I installed > pulseaudio-module-xrdp from github: > > https://github.com/neutrinolabs/pulseaudio-module-xrdp > > But pulseaudio does not start. There is an error in .xsession-errors > regarding"illegal number" on line 27 of /usr/bin/start-pulseaudio-x11. > That should not prevent pulseaudio from starting > The script attempts to parse $DESKTOP_SESSION.desktop, but the CWD is > not correct. The fix is to add the correct path to the desktop session > files. > Does that fix the pulseaudio startup? I wouldn't expect it to. -- Saludos, Felipe Sateler
Bug#946456: systemd: Provide systemd-sysusers as an independent package
On Thu, Feb 6, 2020 at 12:34 AM Felipe Sateler wrote:
>
>
> On Mon, Feb 3, 2020 at 3:50 PM Felipe Sateler wrote:
>
>>
>>
>> On Sun, Feb 2, 2020, 17:04 Zbigniew Jędrzejewski-Szmek
>> wrote:
>>
>>> On Thu, Jan 30, 2020 at 11:51:48PM -0300, Felipe Sateler wrote:
>>> > On Thu, Jan 30, 2020 at 6:40 PM Michael Biebl
>>> wrote:
>>> >
>>> > > Hi Felipe
>>> > >
>>> > > Am 30.01.20 um 22:30 schrieb Felipe Sateler:
>>> > > >
>>> > > >
>>> > > > On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl >> > > > <mailto:bi...@debian.org>> wrote:
>>> > > >
>>> > > > Am 28.01.20 um 17:27 schrieb Ansgar:
>>> > > > > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
>>> > > > >> Am 28.01.20 um 14:59 schrieb Ansgar:
>>> > > > >>> I tried linking systemd-{sysusers,tmpfiles} statically
>>> against
>>> > > > >>> systemd's private library earlier this month. It
>>> increases the
>>> > > > >>> binaries size by ~100 kB (compared to Installed-Size: 14.2
>>> MB of
>>> > > > >>> systemd that is just one percent).
>>> > > > >>
>>> > > > >> Is that 100K per binary?
>>> > > > >
>>> > > > > I checked my notes at it was 100 kB per binary: they are 212
>>> kB
>>> > > larger
>>> > > > > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested
>>> with
>>> > > > > systemd 243-8.
>>> > > > >
>>> > > > > It might be possible to make it a bit smaller if one was to
>>> somehow
>>> > > > > link libsystemd0 for functions available there
>>> (libsystemd-shared
>>> > > > > currently duplicates those).
>>> > > >
>>> > > >
>>> > > > That is not possible. There is global state that is not to be
>>> shared.
>>> > > > See
>>> https://github.com/systemd/systemd/pull/3516#issuecomment-227482524
>>> > >
>>> > > What's your thought on how to solve this libsystemd-shared issue
>>> should
>>> > > we consider splitting out systemd-{sysusers,tmpfiles}
>>> > >
>>> > > - link statically (and carry a downstream patch for eternity)
>>> > > - move libsystemd-shared to systemd-utils and risk the breakage that
>>> can
>>> > > result from a partial/aborted upgrade
>>> > > - copy, instead of move, the binaries + libsystemd-shared and make
>>> the
>>> > > resulting systemd-utils package Conflict with systemd (instead of
>>> having
>>> > > systemd depend on systemd-utils)
>>> > > - something else?
>>> > >
>>> >
>>> > I tried linking statically the "can run without systemd-pid1 tools"
>>> with
>>> > the attached patch.
>>> >
>>> > Disk usage appears to increase by about 400 kb:
>>> > % dpkg --info systemd_244.1-1_amd64.deb|grep Installed
>>> >
>>> > Installed-Size: 13908
>>> > % dpkg --info ../systemd_244-3_amd64.deb|grep Installed
>>> > Installed-Size: 14319
>>> >
>>> > Maybe upstream can be persuaded to merge something like this?
>>> >
>>> > --
>>> >
>>> > Saludos,
>>> > Felipe Sateler
>>>
>>> > diff --git a/meson.build b/meson.build
>>> > index b8dff8cd94..39cef6b301 100644
>>> > --- a/meson.build
>>> > +++ b/meson.build
>>> > @@ -1493,6 +1493,29 @@ make_autosuspend_rules_py =
>>> find_program('tools/make-autosuspend-rules.py')
>>> >
>>> >
>>> >
>>> > +
>>> > +libutil = static_library(
>>> > +'util',
>>> > +[
>>> > +'src/shared/acl-util.c',
>>> > +'src/shared/enable-mempool.c',
>>> > +'src/shared/id128-print.c',
>>> > +'src/shared/pager.c',
>>> > +'src/shared/path-lookup.c',
>>> > +'src/shared/pr
Bug#946456: systemd: Provide systemd-sysusers as an independent package
On Mon, Feb 3, 2020 at 3:50 PM Felipe Sateler wrote:
>
>
> On Sun, Feb 2, 2020, 17:04 Zbigniew Jędrzejewski-Szmek
> wrote:
>
>> On Thu, Jan 30, 2020 at 11:51:48PM -0300, Felipe Sateler wrote:
>> > On Thu, Jan 30, 2020 at 6:40 PM Michael Biebl wrote:
>> >
>> > > Hi Felipe
>> > >
>> > > Am 30.01.20 um 22:30 schrieb Felipe Sateler:
>> > > >
>> > > >
>> > > > On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl > > > > <mailto:bi...@debian.org>> wrote:
>> > > >
>> > > > Am 28.01.20 um 17:27 schrieb Ansgar:
>> > > > > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
>> > > > >> Am 28.01.20 um 14:59 schrieb Ansgar:
>> > > > >>> I tried linking systemd-{sysusers,tmpfiles} statically
>> against
>> > > > >>> systemd's private library earlier this month. It increases
>> the
>> > > > >>> binaries size by ~100 kB (compared to Installed-Size: 14.2
>> MB of
>> > > > >>> systemd that is just one percent).
>> > > > >>
>> > > > >> Is that 100K per binary?
>> > > > >
>> > > > > I checked my notes at it was 100 kB per binary: they are 212
>> kB
>> > > larger
>> > > > > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested
>> with
>> > > > > systemd 243-8.
>> > > > >
>> > > > > It might be possible to make it a bit smaller if one was to
>> somehow
>> > > > > link libsystemd0 for functions available there
>> (libsystemd-shared
>> > > > > currently duplicates those).
>> > > >
>> > > >
>> > > > That is not possible. There is global state that is not to be
>> shared.
>> > > > See
>> https://github.com/systemd/systemd/pull/3516#issuecomment-227482524
>> > >
>> > > What's your thought on how to solve this libsystemd-shared issue
>> should
>> > > we consider splitting out systemd-{sysusers,tmpfiles}
>> > >
>> > > - link statically (and carry a downstream patch for eternity)
>> > > - move libsystemd-shared to systemd-utils and risk the breakage that
>> can
>> > > result from a partial/aborted upgrade
>> > > - copy, instead of move, the binaries + libsystemd-shared and make the
>> > > resulting systemd-utils package Conflict with systemd (instead of
>> having
>> > > systemd depend on systemd-utils)
>> > > - something else?
>> > >
>> >
>> > I tried linking statically the "can run without systemd-pid1 tools" with
>> > the attached patch.
>> >
>> > Disk usage appears to increase by about 400 kb:
>> > % dpkg --info systemd_244.1-1_amd64.deb|grep Installed
>> >
>> > Installed-Size: 13908
>> > % dpkg --info ../systemd_244-3_amd64.deb|grep Installed
>> > Installed-Size: 14319
>> >
>> > Maybe upstream can be persuaded to merge something like this?
>> >
>> > --
>> >
>> > Saludos,
>> > Felipe Sateler
>>
>> > diff --git a/meson.build b/meson.build
>> > index b8dff8cd94..39cef6b301 100644
>> > --- a/meson.build
>> > +++ b/meson.build
>> > @@ -1493,6 +1493,29 @@ make_autosuspend_rules_py =
>> find_program('tools/make-autosuspend-rules.py')
>> >
>> >
>> >
>> > +
>> > +libutil = static_library(
>> > +'util',
>> > +[
>> > +'src/shared/acl-util.c',
>> > +'src/shared/enable-mempool.c',
>> > +'src/shared/id128-print.c',
>> > +'src/shared/pager.c',
>> > +'src/shared/path-lookup.c',
>> > +'src/shared/pretty-print.c',
>> > +'src/shared/spawn-ask-password-agent.c',
>> > +'src/shared/spawn-polkit-agent.c',
>> > +'src/shared/specifier.c',
>> > +'src/shared/sysctl-util.c',
>> > +'src/shared/sysctl-util.h',
>> > +'src/shared/tmpfile-util-label.c',
>> > +'src/shared/uid-range.c',
>> > +'src/shared/verbs.c',
>> > +] + id128_sources,
>> > +link_with: [libbasic, libsystemd_static],
>> > +include_directories: includes
>> > +)
>>
>> Is creating a separate static library actually necessary? What would
>> the results be if those binaries were linked to the static version of
>> libshared that we already provide support for? I hope the compiler
>> would be able to drop any unused objects and achieve the same size,
>> without having to maintain yet another list of files.
>>
>
> I'd have to recheck, but that was my first idea and didn't pan out (at
> least with the flags we use for the debian package).
>
It appears I messed up earlier. Indeed using libshared_static (plus
libbasic and libsystemd_static) does the job as well.
--
Saludos,
Felipe Sateler
Bug#946456: systemd: Provide systemd-sysusers as an independent package
On Sun, Feb 2, 2020, 17:04 Zbigniew Jędrzejewski-Szmek
wrote:
> On Thu, Jan 30, 2020 at 11:51:48PM -0300, Felipe Sateler wrote:
> > On Thu, Jan 30, 2020 at 6:40 PM Michael Biebl wrote:
> >
> > > Hi Felipe
> > >
> > > Am 30.01.20 um 22:30 schrieb Felipe Sateler:
> > > >
> > > >
> > > > On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl > > > <mailto:bi...@debian.org>> wrote:
> > > >
> > > > Am 28.01.20 um 17:27 schrieb Ansgar:
> > > > > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
> > > > >> Am 28.01.20 um 14:59 schrieb Ansgar:
> > > > >>> I tried linking systemd-{sysusers,tmpfiles} statically
> against
> > > > >>> systemd's private library earlier this month. It increases
> the
> > > > >>> binaries size by ~100 kB (compared to Installed-Size: 14.2
> MB of
> > > > >>> systemd that is just one percent).
> > > > >>
> > > > >> Is that 100K per binary?
> > > > >
> > > > > I checked my notes at it was 100 kB per binary: they are 212 kB
> > > larger
> > > > > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested
> with
> > > > > systemd 243-8.
> > > > >
> > > > > It might be possible to make it a bit smaller if one was to
> somehow
> > > > > link libsystemd0 for functions available there
> (libsystemd-shared
> > > > > currently duplicates those).
> > > >
> > > >
> > > > That is not possible. There is global state that is not to be shared.
> > > > See
> https://github.com/systemd/systemd/pull/3516#issuecomment-227482524
> > >
> > > What's your thought on how to solve this libsystemd-shared issue should
> > > we consider splitting out systemd-{sysusers,tmpfiles}
> > >
> > > - link statically (and carry a downstream patch for eternity)
> > > - move libsystemd-shared to systemd-utils and risk the breakage that
> can
> > > result from a partial/aborted upgrade
> > > - copy, instead of move, the binaries + libsystemd-shared and make the
> > > resulting systemd-utils package Conflict with systemd (instead of
> having
> > > systemd depend on systemd-utils)
> > > - something else?
> > >
> >
> > I tried linking statically the "can run without systemd-pid1 tools" with
> > the attached patch.
> >
> > Disk usage appears to increase by about 400 kb:
> > % dpkg --info systemd_244.1-1_amd64.deb|grep Installed
> >
> > Installed-Size: 13908
> > % dpkg --info ../systemd_244-3_amd64.deb|grep Installed
> > Installed-Size: 14319
> >
> > Maybe upstream can be persuaded to merge something like this?
> >
> > --
> >
> > Saludos,
> > Felipe Sateler
>
> > diff --git a/meson.build b/meson.build
> > index b8dff8cd94..39cef6b301 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1493,6 +1493,29 @@ make_autosuspend_rules_py =
> find_program('tools/make-autosuspend-rules.py')
> >
> >
> >
> > +
> > +libutil = static_library(
> > +'util',
> > +[
> > +'src/shared/acl-util.c',
> > +'src/shared/enable-mempool.c',
> > +'src/shared/id128-print.c',
> > +'src/shared/pager.c',
> > +'src/shared/path-lookup.c',
> > +'src/shared/pretty-print.c',
> > +'src/shared/spawn-ask-password-agent.c',
> > +'src/shared/spawn-polkit-agent.c',
> > +'src/shared/specifier.c',
> > +'src/shared/sysctl-util.c',
> > +'src/shared/sysctl-util.h',
> > +'src/shared/tmpfile-util-label.c',
> > +'src/shared/uid-range.c',
> > +'src/shared/verbs.c',
> > +] + id128_sources,
> > +link_with: [libbasic, libsystemd_static],
> > +include_directories: includes
> > +)
>
> Is creating a separate static library actually necessary? What would
> the results be if those binaries were linked to the static version of
> libshared that we already provide support for? I hope the compiler
> would be able to drop any unused objects and achieve the same size,
> without having to maintain yet another
Bug#950413: libpulse0: obsolete-conffile /etc/pulse/client.conf.d/00-disable-autospawn.conf
Control: tags -1 confirmed newcomer On Sat, Feb 1, 2020 at 6:39 AM Sebastian Ramacher wrote: > Package: libpulse0 > Version: 13.0-4 > Severity: minor > > adequate reports: > > libpulse0:amd64: obsolete-conffile > /etc/pulse/client.conf.d/00-disable-autospawn.conf > > Please remove it using dpkg-maintscript-helper. Thanks > Thanks for the report. The maintscript snippet is in the pulseaudio package, rather than in libpulse0, which is of course wrong. Patches welcome, otherwise I'll fix for next upload. -- Saludos, Felipe Sateler
Bug#904098: pulseaudio: Pulseaudio only provides Dummy Output until timidity is killed
Control: reassign -1 timidity Reassigning to timidity as it is claiming the device for itself. Quoting full bug below for context. On Thu, 19 Jul 2018 11:34:02 -0400 Sam Imberman wrote: > Package: pulseaudio > Version: 11.1-5 > Severity: important > > Dear Maintainer, > > I'm reporting what appears to be a problem with either pulseaudio, timidity, or > both. The nature of the bug is that pulseaudio does not work until I kill > timidity. Notably pavucontrol shows no outputs, and GNOME's sound control panel > shows only a dummy output. If I execute 'service timidity stop', then suddenly > audio output works fine again. > > The computer is a Thinkpad T430. > > I'm a longtime intermediate-level Debian Testing user but this is the first > time I'm > reporting what seems to be pretty clearly a bug, so please bear with me! I have > seen references to similar bugs on various forums, but I didn't find anything > in the Debian bug tracker. > > I am attaching a debug-level log of pulseaudio (sudo journalctl -b | grep > pulse), but please let me know if any logfiles would be interesting. > > > > -- Package-specific info: > File '/etc/default/pulseaudio' does not exist > > > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages pulseaudio depends on: > ii adduser 3.117 > ii libasound2 1.1.6-1 > ii libasound2-plugins 1:1.1.6-dmo1 > ii libc62.27-3 > ii libcap2 1:2.25-1.2 > ii libdbus-1-3 1.12.8-3 > ii libgcc1 1:8.1.0-10 > ii libice6 2:1.0.9-2 > ii libltdl7 2.4.6-2.1 > ii liborc-0.4-0 1:0.4.28-2 > ii libpulse011.1-5 > ii libsm6 2:1.2.2-1+b3 > ii libsndfile1 1.0.28-4 > ii libsoxr0 0.1.2-3 > ii libspeexdsp1 1.2~rc1.2-1+b2 > ii libstdc++6 8.1.0-10 > ii libsystemd0 239-5
Bug#946456: systemd: Provide systemd-sysusers as an independent package
On Thu, Jan 30, 2020 at 6:40 PM Michael Biebl wrote:
> Hi Felipe
>
> Am 30.01.20 um 22:30 schrieb Felipe Sateler:
> >
> >
> > On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl > <mailto:bi...@debian.org>> wrote:
> >
> > Am 28.01.20 um 17:27 schrieb Ansgar:
> > > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
> > >> Am 28.01.20 um 14:59 schrieb Ansgar:
> > >>> I tried linking systemd-{sysusers,tmpfiles} statically against
> > >>> systemd's private library earlier this month. It increases the
> > >>> binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of
> > >>> systemd that is just one percent).
> > >>
> > >> Is that 100K per binary?
> > >
> > > I checked my notes at it was 100 kB per binary: they are 212 kB
> larger
> > > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested with
> > > systemd 243-8.
> > >
> > > It might be possible to make it a bit smaller if one was to somehow
> > > link libsystemd0 for functions available there (libsystemd-shared
> > > currently duplicates those).
> >
> >
> > That is not possible. There is global state that is not to be shared.
> > See https://github.com/systemd/systemd/pull/3516#issuecomment-227482524
>
> What's your thought on how to solve this libsystemd-shared issue should
> we consider splitting out systemd-{sysusers,tmpfiles}
>
> - link statically (and carry a downstream patch for eternity)
> - move libsystemd-shared to systemd-utils and risk the breakage that can
> result from a partial/aborted upgrade
> - copy, instead of move, the binaries + libsystemd-shared and make the
> resulting systemd-utils package Conflict with systemd (instead of having
> systemd depend on systemd-utils)
> - something else?
>
I tried linking statically the "can run without systemd-pid1 tools" with
the attached patch.
Disk usage appears to increase by about 400 kb:
% dpkg --info systemd_244.1-1_amd64.deb|grep Installed
Installed-Size: 13908
% dpkg --info ../systemd_244-3_amd64.deb|grep Installed
Installed-Size: 14319
Maybe upstream can be persuaded to merge something like this?
--
Saludos,
Felipe Sateler
diff --git a/meson.build b/meson.build
index b8dff8cd94..39cef6b301 100644
--- a/meson.build
+++ b/meson.build
@@ -1493,6 +1493,29 @@ make_autosuspend_rules_py = find_program('tools/make-autosuspend-rules.py')
+
+libutil = static_library(
+'util',
+[
+'src/shared/acl-util.c',
+'src/shared/enable-mempool.c',
+'src/shared/id128-print.c',
+'src/shared/pager.c',
+'src/shared/path-lookup.c',
+'src/shared/pretty-print.c',
+'src/shared/spawn-ask-password-agent.c',
+'src/shared/spawn-polkit-agent.c',
+'src/shared/specifier.c',
+'src/shared/sysctl-util.c',
+'src/shared/sysctl-util.h',
+'src/shared/tmpfile-util-label.c',
+'src/shared/uid-range.c',
+'src/shared/verbs.c',
+] + id128_sources,
+link_with: [libbasic, libsystemd_static],
+include_directories: includes
+)
+
# binaries that have --help and are intended for use by humans,
# usually, but not always, installed in /bin.
public_programs = []
@@ -1537,6 +1560,7 @@ test_dlopen = executable(
include_directories : includes,
link_with : [libbasic],
dependencies : [libdl],
+b_lto: false,
build_by_default : want_tests != 'false')
foreach tuple : [['myhostname', 'ENABLE_NSS_MYHOSTNAME'],
@@ -2407,7 +2431,7 @@ install_data('src/sleep/sleep.conf',
exe = executable('systemd-sysctl',
'src/sysctl/sysctl.c',
include_directories : includes,
- link_with : [libshared],
+ link_with : [libutil],
install_rpath : rootlibexecdir,
install : true,
install_dir : rootlibexecdir)
@@ -2440,7 +2464,7 @@ public_programs += exe
exe = executable('systemd-escape',
'src/escape/escape.c',
include_directories : includes,
- link_with : [libshared],
+ link_with : [libutil],
install_rpath : rootlibexecdir,
install : true,
install_dir : rootbindir)
@@ -2474,7 +2498,7 @@ executable('systemd-cgroups-agent',
exe = executable('systemd-id128',
'src/id128/id128.c',
include_directories : includes,
- link_with : [libshared],
+
Bug#923201: it's already Recommends, but please support elogind
On Thu, Jan 30, 2020 at 5:15 PM Adam Borowski wrote: > On Fri, Jan 17, 2020 at 10:43:35AM -0300, Felipe Sateler wrote: > > Pulseaudio needs not only logind for user tracking (which could be > replaced > > by other logind), but right now requires it for actually starting up (it > > requires systemd --user). Please help > > https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/6 get > > merged and then we can do this. > > I've looked at the PR again, and as expected, reversing the order of > /lib/systemd/pulseaudio-enable-autospawn.service /dev/null > to > /dev/null /lib/systemd/pulseaudio-enable-autospawn.service > makes it all goodness. > Thanks, I have pushed the change. If you could please test it one more time before clicking merge, it would be great. I'll include this with the next upload. -- Saludos, Felipe Sateler
Bug#946456: systemd: Provide systemd-sysusers as an independent package
On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl wrote:
> Am 28.01.20 um 17:27 schrieb Ansgar:
> > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote:
> >> Am 28.01.20 um 14:59 schrieb Ansgar:
> >>> I tried linking systemd-{sysusers,tmpfiles} statically against
> >>> systemd's private library earlier this month. It increases the
> >>> binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of
> >>> systemd that is just one percent).
> >>
> >> Is that 100K per binary?
> >
> > I checked my notes at it was 100 kB per binary: they are 212 kB larger
> > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested with
> > systemd 243-8.
> >
> > It might be possible to make it a bit smaller if one was to somehow
> > link libsystemd0 for functions available there (libsystemd-shared
> > currently duplicates those).
>
That is not possible. There is global state that is not to be shared.
See https://github.com/systemd/systemd/pull/3516#issuecomment-227482524
--
Saludos,
Felipe Sateler
Bug#923201: it's already Recommends, but please support elogind
On Mon, 25 Feb 2019 01:27:50 +0100 Adam Borowski wrote: > Control: tags -1 +patch > > > pulseaudio has a hard dependency on libpam-systemd. Violates "Depends: > > This declares an absolute dependcy... > > > Fix: change Depends: libpam-systemd to Recommends: libpam-systemd > > It already _is_ "Recommends". > > I guess the submitter got confused by apt's handling which indeed acts as if > the dependency was absolute if there's any way to satisfy the Recommends, > and failing with a wrong message if there's a hold or pin. > > But, since recently there's a way: > Change: > Recommends: libpam-systemd > to > Recommends: default-logind | logind > > which is satisfied by libpam-systemd and libpam-elogind. It'd be nice if it > could apply this. > Pulseaudio needs not only logind for user tracking (which could be replaced by other logind), but right now requires it for actually starting up (it requires systemd --user). Please help https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/6 get merged and then we can do this. Saludos
Bug#947908: pulseaudio: sound doesn't play on first launch of pulseaudio at login; restarting it always results in working sound but will reoccur on next boot
On Fri, Jan 3, 2020 at 12:16 AM Joshua Hudson wrote: > > Does `journalctl --user-unit pulseaudio.service` have anything to say? > > Says "daemon already running" quite a few times. > > > You can set the debug flags on daemon.conf to force it to verbose mode. > > Spectacular: > > E: [pulseaudio] pid.c: Daemon already running. > E: [pulseaudio] main.c: pa_pid_file_create() failed. > Is there actually a pulseaudio daemon running? Where? Is it managed by systemd? You didn't attach your client.conf -- Saludos, Felipe Sateler
Bug#947908: pulseaudio: sound doesn't play on first launch of pulseaudio at login; restarting it always results in working sound but will reoccur on next boot
Control: tags -1 moreinfo On Wed, Jan 1, 2020 at 8:39 PM Joshua wrote: > Package: pulseaudio > Version: 12.2-4+deb10u1 > Severity: normal > > After installing systemd, the following problem appeared in pulseaudio: > Please attach the entire client.conf (/etc/pulse and ~/.config/pulse). > > The first login after boot launches a non-working pulseaudio. Killing and > restarting pulseaudio results in > a working pulseaudio. It's not a wait for device to initialize problem. It > doesn't matter how long I stare > at the login screen before logging in. > Does `journalctl --user-unit pulseaudio.service` have anything to say? > > The normal debug steps are useless as the problem won't recur when > pulseaudio is not restarted. > You can set the debug flags on daemon.conf to force it to verbose mode. -- Saludos, Felipe Sateler
Bug#947376: Core dumps when pressing Ctrl-w
Control: reassign -1 libgtkmm-3.0-1v5 Control: affects -1 pavucontrol Control: retitle -1 Gtk::Main::quit() dumps core On Wed, Dec 25, 2019 at 6:45 PM Martin Zobel-Helas wrote: > Package: pavucontrol > Version: 4.0-1 > Severity: important > > When i press ctrl+w pavucontrol core dumps for me. > So, pavucontrol is crashing at Gtk::Main::quit(), which is deprecated. Switching to the non-deprecated Gtk::Application::quit() makes it go away. I suppose this means Gtk::Main::quit compat is borked, so assigning to gtkmm. I'm proposing upgrading of these deprecated methods in pavucontrol upstream anyway. Saludos -- Saludos, Felipe Sateler
Bug#946104: autopkgtest fails with "Failed to retrieve max realtime priority: Input/output error"
Control: tags -1 moreinfo Hi Michael, On Tue, Dec 3, 2019 at 5:45 PM Michael Biebl wrote: > Source: rtkit > Version: 0.12-4 > Severity: normal > > Hi Felipe, > > today I was investigating why an update of systemd (v244) was blocked by > a failing autopkgtest in rtkit from testing migration. > > When trying to investigate the issue, I could reproduce the failure with > both systemd v243 and v244 locally. So I assume it's the rtkit > autopkgtest which is flaky since [1] shows autopkgtest passing. > I've attached logs for both sid and bullseye. > The tests are run on Debian sid. > I can't reproduce the failures. How are you running the tests? -- Saludos, Felipe Sateler
Bug#946375: pulseaudio: Please make autopkgtests cross-test-friendly
Control: tags -1 pending On Sun, Dec 8, 2019 at 2:57 AM Steve Langasek wrote: > Package: pulseaudio > Version: 13.0-1 > Severity: minor > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu focal ubuntu-patch > > Dear maintainers, > > In Ubuntu, we are in the process of moving the i386 architecture to a > compatibility-only layer on amd64, and therefore we are also moving our > autopkgtest infrastructure to test i386 binaries in a cross-environment. > > This requires changes to some tests so that they are cross-aware and can do > the right thing. > > The pulseaudio tests currently fail in this environment, because they are > build tests that do not invoke the toolchain in a cross-aware manner. I've > verified that the attached patch lets the tests successfully build (and > run) > i386 tests on an amd64 host. > Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this > is a complete no-op in Debian for the moment. Support for cross-testing in > autopkgtest is currently awaiting review at > https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once > landed, will still have no effect unless autopkgtest is invoked with a '-a' > option. So this change should be safe to land in your package despite this > not being upstream in autopkgtest. Thanks for the patch, I have applied it. However, wouldn't it be better if autopkgtest provided CC and friends directly to the test? Or provide a tool that does? I have commented on the autopkgtest merge request. -- Saludos, Felipe Sateler
Bug#946301: Should depend on php-twig < 3
On Fri, Dec 6, 2019 at 5:36 PM David Prévot wrote:
> Package: php-twig-extensions
> Version: 1.5.4-1
> Severity: wishlist
>
> Hi,
>
> Thanks for packaging twig-extensions (feel free and welcome to maintain
> it within the Debian PHP PEAR Maintainers team
> by the way).
>
> With php-twig 3 now in experimental, you may wish to add an explicit
> Depends: php-twig < 3
> override in your control file (due to #765899, the composer.json
> versioned dependency is not fully translated into
> ${phpcomposer:Debian-require}) if you update this package before
> upgrading it to the next upstream version (looking further, I noticed
> the next upstream version should not be affected by this issue [1]).
> 1:
> https://github.com/twigphp/Twig-extensions/blob/master/composer.json#L15
>
> I noticed this issue while trying to make the phpmyadmin package work on
> my box (where I was also using the latest php-twig package). Thanks also
> for resurrecting phpMyAdmin in Debian!
>
I looked at the upstream page to look if the new upstream version added
compat for twig 3,
and it says:
WARNING: This repository is abandoned in favor of Twig Core Extra
extensions.
Maybe php-twig should just Breaks: php-twig-extensions, and phpmyadmin
should migrate to Twig Core Extra extensions
--
Saludos,
Felipe Sateler
Bug#944975: pulseaudio user daemon degraded state
Control: tags -1 moreinfo On Sun, Nov 17, 2019, 19:18 Eduard Bloch wrote: > Package: pulseaudio > Version: 13.0-3 > Severity: normal > > $ systemctl --user |grep failed > ● pulseaudio.service > loaded failed failedSound Service > ● pulseaudio.socket > loaded failed failedSound System > $ systemctl --user status pulseaudio.service > ● pulseaudio.service - Sound Service >Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; enabled; > vendor preset: enabled) >Active: failed (Result: exit-code) since Sun 2019-11-17 23:02:42 CET; > 4min 54s ago > Process: 21056 ExecStart=/usr/bin/pulseaudio --daemonize=no > (code=exited, status=1/FAILURE) > Main PID: 21056 (code=exited, status=1/FAILURE) > $ sudo journalctl --user -u pulseaudio > No journal files were found. > -- No entries -- > $ systemctl --user restart pulseaudio > Job for pulseaudio.service failed because the control process exited with > error code. > See "systemctl --user status pulseaudio.service" and "journalctl --user > -xe" for details. > $ systemctl --user status pulseaudio.service > ● pulseaudio.service - Sound Service >Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; enabled; > vendor preset: enabled) >Active: failed (Result: exit-code) since Sun 2019-11-17 23:10:32 CET; > 13s ago > Process: 21409 ExecStart=/usr/bin/pulseaudio --daemonize=no > (code=exited, status=1/FAILURE) > Main PID: 21409 (code=exited, status=1/FAILURE) > $ journalctl --user -xe > No journal files were found. > > Am I missing something? How to debug this? > You need to access the journal as root (or add yourself to the systemd-journal group). Please get the logs for the user units (both the service and the socket). Also, have you edited any pulseaudio configuration file? Saludos
Bug#944897: sensible-utils: typo-in-debhelper-override-target override_dh_autoconfigure -> override_dh_auto_configure
Package: sensible-utils Version: 0.0.12 Severity: normal Hi, Lintian reports the above warning. And indeed, debian/rules has: override_dh_autoconfigure-indep: CFLAGS="$(CFLAGS)" ./configure --prefix=/usr \ --mandir=/usr/share/man $(CONFARGS) It seems to me the override is not necessary since CONFARGS and CFLAGS only set things already set by debhelper/dpkg. -- 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.3.0-2-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 -- no debconf information
Bug#944895: lintian: missing-depends-on-sensible-utils triggers on package sensible-utils
Package: lintian Version: 2.36.0 Severity: minor It would be quite weird to have sensible-utils depend on itself :) -- 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.3.0-2-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 lintian depends on: ii binutils 2.33.1-2 ii bzip21.0.8-2 ii diffstat 1.62-1+b1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.37-6 ii gettext 0.19.8.1-9 ii gpg 2.2.17-3 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b2 ii libarchive-zip-perl 1.67-1 ii libberkeleydb-perl 0.62-1+b1 ii libcapture-tiny-perl 0.48-1 ii libcgi-pm-perl 4.44-1 ii libclass-accessor-perl 0.51-1 ii libclass-xsaccessor-perl 1.19-3+b3 ii libclone-perl0.43-1 ii libdpkg-perl 1.19.7 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libio-async-loop-epoll-perl 0.20-1 ii libio-async-perl 0.74-1 ii libipc-run-perl 20180523.0-2 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii libmldbm-perl2.05-2 ii libmoo-perl 2.003006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl0.108-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl1.004004-1 ii liburi-perl 1.76-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.80+repack-2+b1 ii man-db 2.9.0-1 ii patchutils 0.3.4-2+b1 ii perl [libdigest-sha-perl]5.30.0-9 ii t1utils 1.41-3 ii xz-utils 5.2.4-1+b1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b6 Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b4 ii libtext-template-perl 1.58-1 -- no debconf information
Bug#927022: sensible-utils: diff for NMU version 0.0.12+nmu1
Control: tags 927022 + pending Dear maintainer, I've prepared an NMU for sensible-utils (versioned as 0.0.12+nmu1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. -- Saludos, Felipe Sateler diff -Nru sensible-utils-0.0.12/debian/changelog sensible-utils-0.0.12+nmu1/debian/changelog --- sensible-utils-0.0.12/debian/changelog 2018-03-12 07:17:53.0 -0300 +++ sensible-utils-0.0.12+nmu1/debian/changelog 2019-11-17 09:21:22.0 -0300 @@ -1,3 +1,17 @@ +sensible-utils (0.0.12+nmu1) unstable; urgency=medium + + [ Felipe Sateler ] + * Non-maintainer upload. + * Do not attempt to discover the executable path of empty variables. +Otherwise, which outputs a message like `usage: which [-as] program ... `. +Instead of invoking which without arguments, lets skip the check +(Closes: #927022) + + [ Boyuan Yang ] + * debian/control: Update Vcs-* fields and use git packaging repo under Salsa Debian group. + + -- Felipe Sateler Sun, 17 Nov 2019 09:21:22 -0300 + sensible-utils (0.0.12) unstable; urgency=medium * Fix sensible-browser launches $BROWSER with empty argument diff -Nru sensible-utils-0.0.12/debian/control sensible-utils-0.0.12+nmu1/debian/control --- sensible-utils-0.0.12/debian/control 2018-03-12 07:17:53.0 -0300 +++ sensible-utils-0.0.12+nmu1/debian/control 2019-11-17 09:21:22.0 -0300 @@ -8,8 +8,8 @@ ed Uploaders: Bastien Roucariès Standards-Version: 4.1.3 -Vcs-Git: https://anonscm.debian.org/git/collab-maint/sensible-utils.git -Vcs-Browser: https://anonscm.debian.org/git/collab-maint/sensible-utils.git +Vcs-Git: https://salsa.debian.org/debian/sensible-utils.git +Vcs-Browser: https://salsa.debian.org/debian/sensible-utils Package: sensible-utils Architecture: all diff -Nru sensible-utils-0.0.12/man/po4a/sensible-utils.pot sensible-utils-0.0.12+nmu1/man/po4a/sensible-utils.pot --- sensible-utils-0.0.12/man/po4a/sensible-utils.pot 2018-03-12 07:17:53.0 -0300 +++ sensible-utils-0.0.12+nmu1/man/po4a/sensible-utils.pot 1969-12-31 21:00:00.0 -0300 @@ -1,111 +0,0 @@ -# SOME DESCRIPTIVE TITLE -# Copyright (C) YEAR Free Software Foundation, Inc. -# This file is distributed under the same license as the sensible-utils package. -# FIRST AUTHOR , YEAR. -# -#, fuzzy -msgid "" -msgstr "" -"Project-Id-Version: sensible-utils VERSION\n" -"POT-Creation-Date: 2018-03-12 12:18+0100\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" -"Language-Team: LANGUAGE \n" -"Language: \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" - -#. type: TH -#: sensible-editor.man -#, no-wrap -msgid "SENSIBLE-EDITOR" -msgstr "" - -#. type: TH -#: sensible-editor.man -#, no-wrap -msgid "14 Nov 2010" -msgstr "" - -#. type: TH -#: sensible-editor.man -#, no-wrap -msgid "Debian" -msgstr "" - -#. type: SH -#: sensible-editor.man -#, no-wrap -msgid "NAME" -msgstr "" - -#. type: Plain text -#: sensible-editor.man -msgid "" -"sensible-editor, sensible-pager, sensible-browser - sensible editing, " -"paging, and web browsing" -msgstr "" - -#. type: SH -#: sensible-editor.man -#, no-wrap -msgid "SYNOPSIS" -msgstr "" - -#. type: Plain text -#: sensible-editor.man -msgid "B [OPTIONS...]" -msgstr "" - -#. type: Plain text -#: sensible-editor.man -msgid "B [OPTIONS...]" -msgstr "" - -#. type: Plain text -#: sensible-editor.man -msgid "B url" -msgstr "" - -#. type: SH -#: sensible-editor.man -#, no-wrap -msgid "DESCRIPTION" -msgstr "" - -#. type: Plain text -#: sensible-editor.man -msgid "" -"B, B and B make sensible " -"decisions on which editor, pager, and web browser to call, respectively. " -"Programs in Debian can use these scripts as their default editor, pager, or " -"web browser or emulate their behavior." -msgstr "" - -#. type: SH -#: sensible-editor.man -#, no-wrap -msgid "SEE ALSO" -msgstr "" - -#. type: Plain text -#: sensible-editor.man -msgid "" -"Documentation of the EDITOR, VISUAL and PAGER variables in B(7) " -"and B(1) for changing a user's default editor" -msgstr "" - -#. type: SH -#: sensible-editor.man -#, no-wrap -msgid "STANDARD" -msgstr "" - -#. type: Plain text -#: sensible-editor.man -msgid "" -"Documentation of behavior of sensible-utils under a debian system is " -"available under section 11.4 of debian-policy usually installed under " -"/usr/share/doc/debian-policy (you might need to install debian-policy)" -msgstr "&
Bug#886831: phpmyadmin: Package postinst script database backup fails during Jessie to Stretch migration.
On Wed, 10 Jan 2018 10:56:27 + Simon Byrnand wrote: > Package: phpmyadmin > Version: 4:4.6.6-4 > Severity: important > > Dear Thijs Kinkhorst, > > A problem has been noticed with the package upgrade process of phpmyadmin when migrating an OSMC (Debian) Jessie system to Stretch. > > The postinst script appears to fail to back up the old database, this leads to the entire postinst script failing thus causing a partially failed dist-upgrade and inconsistent APT state. The following is logged: > > Setting up phpmyadmin (4:4.6.6-4) ... > Installing new version of config file /etc/phpmyadmin/apache.conf ... > Installing new version of config file /etc/phpmyadmin/config.inc.php ... > Installing new version of config file /etc/phpmyadmin/lighttpd.conf ... > Determining localhost credentials from /etc/mysql/debian.cnf: succeeded. > dbconfig-common: writing config to /etc/dbconfig-common/phpmyadmin.conf > Replacing config file /etc/dbconfig-common/phpmyadmin.conf with new version > Replacing config file /etc/phpmyadmin/config-db.php with new version > creating database backup in /var/cache/dbconfig-common/backups/phpmyadmin_4:4.2.12-2+deb8u2.2018-01-10-10.30.29. > dumping database as user failed, retrying with administrator credentials. > error encountered backing up the old database: > mysqldump: Couldn't execute 'SHOW FUNCTION STATUS WHERE Db = 'phpmyadmin'': Cannot load from mysql.proc. The table is probably corrupted (1728) > dbconfig-common: phpmyadmin configure: aborted. > dbconfig-common: flushing administrative password > ESC[1mdpkg:ESC[0m error processing package phpmyadmin (--configure): > subprocess installed post-installation script returned error exit status 1 I'm not sure there's anything we can do about this anymore. What should we do about this report? Saludos
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#944855: dgit: History contains tainted commit -- but tags were accepted by the dgit server, making subsequent dgit push fail
Package: dgit Version: 9.9 Severity: normal If one attempts to push a tainted history (because a package was rejected from NEW, for example), one gets the "History contains tainted commit" message. If the questionable history is OK, a dgit push with --deliberately flag will fail with Made pseudo-merge of 2.1-2 into dgit view. Version 2.1-3 has already been tagged (pushed?) If this was a failed (or incomplete or rejected) upload by you, just add a new changelog stanza for a new version number and try again. dgit: error: Tag archive/debian/2.1-3 already exists. I suppose dgit should remove the archive/foo tag if the push fails -- 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.3.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, 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 dgit depends on: ii apt1.8.4 ii ca-certificates20190110 ii coreutils 8.30-3+b1 ii curl 7.66.0-1+b1 ii devscripts 2.19.7 ii dpkg-dev 1.19.7 ii dput-ng [dput] 1.28 ii git [git-core] 1:2.24.0-1 ii git-buildpackage 0.9.17 ii libdpkg-perl 1.19.7 ii libjson-perl 4.02000-1 ii liblist-moreutils-perl 0.416-1+b5 ii liblocale-gettext-perl 1.07-4 ii libtext-csv-perl 2.00-1 ii libtext-glob-perl 0.10-1 ii libtext-iconv-perl 1.7-7 ii libwww-curl-perl 4.17-6 ii perl [libdigest-sha-perl] 5.30.0-9 Versions of packages dgit recommends: ii distro-info-data 0.43 ii liburi-perl 1.76-1 ii openssh-client [ssh-client] 1:8.1p1-1 Versions of packages dgit suggests: ii cowbuilder 0.88 ii pbuilder0.230.4 ii sbuild 0.78.1-2 -- no debconf information
Bug#944228: stretch-pu: package phpmyadmin/4:4.6.6-4+deb9u1
On Wed, Nov 6, 2019 at 8:51 AM Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On 2019-11-06 11:23, Felipe Sateler wrote: > > This update fixes several security issues, plus an important bug. > > Additionally we fix the metadata reflecting the maintainership change. > > > > Here is the changelog, with debdiff attached. > > > > phpmyadmin (4:4.6.6-4+deb9u1) stretch; urgency=medium > > > > [ Matthias Blümel ] > > * Several security fixes > > - Cross-site scripting (XSS) vulnerability in > > db_central_columns.php > > (PMASA-2018-1, CVE-2018-7260, Closes: #893539) > > - Remove transformation plugin includes > > (PMASA-2018-6, CVE-2018-19968) > > - Fix Stored Cross-Site Scripting (XSS) in navigation tree > > (PMASA-2018-8, CVE-2018-19970) > > - Fix information leak (arbitrary file read) using SQL queries > > (PMASA-2019-1, CVE-2019-6799, Closes: #920823) > > - a specially crafted username can be used to trigger a SQL > > injection attack > > (PMASA-2019-2, CVE-2019-6798, Closes: #920822) > > - SQL injection in Designer feature > > (PMASA-2019-3, CVE-2019-11768, Closes: #930048) > > - CSRF vulnerability in login form > > (PMASA-2019-4, CVE-2019-12616, Closes: #930017) > > According to the BTS and Security Tracker, at least some of these issues > affect the package in unstable and aren't currently fixed there. Is that > correct? > Yes, it is correct. This is because in unstable we are aiming for version 4.9, but we are waiting on some NEW packages for that upload to happen. -- Saludos, Felipe Sateler
Bug#944228: stretch-pu: package phpmyadmin/4:4.6.6-4+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu This update fixes several security issues, plus an important bug. Additionally we fix the metadata reflecting the maintainership change. Here is the changelog, with debdiff attached. phpmyadmin (4:4.6.6-4+deb9u1) stretch; urgency=medium [ Matthias Blümel ] * Several security fixes - Cross-site scripting (XSS) vulnerability in db_central_columns.php (PMASA-2018-1, CVE-2018-7260, Closes: #893539) - Remove transformation plugin includes (PMASA-2018-6, CVE-2018-19968) - Fix Stored Cross-Site Scripting (XSS) in navigation tree (PMASA-2018-8, CVE-2018-19970) - Fix information leak (arbitrary file read) using SQL queries (PMASA-2019-1, CVE-2019-6799, Closes: #920823) - a specially crafted username can be used to trigger a SQL injection attack (PMASA-2019-2, CVE-2019-6798, Closes: #920822) - SQL injection in Designer feature (PMASA-2019-3, CVE-2019-11768, Closes: #930048) - CSRF vulnerability in login form (PMASA-2019-4, CVE-2019-12616, Closes: #930017) * Set Vcs-* to point to salsa * Remove Thijs Kinkhorst and Michal Čihař from Uploaders. Thanks for all your work! [ Juri Grabowski ] * Fix Vcs- URLs [ William Desportes ] * Add debian gitlab pipelines config. [ Felipe Sateler ] * Set phpMyAdmin team as Maintainer [ Michal Čihař ] * Fix open_basedir setting for PHP 7 (Closes: #867882). > This is the non-security fix. THe default config was not updated for > changes in the php-gettext path for 7.0. -- Felipe Sateler Wed, 06 Nov 2019 08:12:18 -0300 Thanks for your consideration -- 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.2.0-3-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 diff -Nru phpmyadmin-4.6.6/debian/changelog phpmyadmin-4.6.6/debian/changelog --- phpmyadmin-4.6.6/debian/changelog 2017-04-07 11:54:26.0 -0300 +++ phpmyadmin-4.6.6/debian/changelog 2019-11-06 08:12:18.0 -0300 @@ -1,3 +1,40 @@ +phpmyadmin (4:4.6.6-4+deb9u1) stretch; urgency=medium + + [ Matthias Blümel ] + * Several security fixes +- Cross-site scripting (XSS) vulnerability in db_central_columns.php + (PMASA-2018-1, CVE-2018-7260, Closes: #893539) +- Remove transformation plugin includes + (PMASA-2018-6, CVE-2018-19968) +- Fix Stored Cross-Site Scripting (XSS) in navigation tree + (PMASA-2018-8, CVE-2018-19970) +- Fix information leak (arbitrary file read) using SQL queries + (PMASA-2019-1, CVE-2019-6799, Closes: #920823) +- a specially crafted username can be used to trigger a SQL injection attack + (PMASA-2019-2, CVE-2019-6798, Closes: #920822) +- SQL injection in Designer feature + (PMASA-2019-3, CVE-2019-11768, Closes: #930048) +- CSRF vulnerability in login form + (PMASA-2019-4, CVE-2019-12616, Closes: #930017) + * Set Vcs-* to point to salsa + * Remove Thijs Kinkhorst and Michal Čihař from Uploaders. Thanks for all +your work! + + [ Juri Grabowski ] + * Fix Vcs- URLs + + [ William Desportes ] + * Add debian gitlab pipelines config. + + [ Felipe Sateler ] + * Set phpMyAdmin team as Maintainer + + [ Michal Čihař ] + * Fix open_basedir setting for PHP 7 (Closes: #867882). + + + -- Felipe Sateler Wed, 06 Nov 2019 08:12:18 -0300 + phpmyadmin (4:4.6.6-4) unstable; urgency=medium * Build depend on locales-all to ensure en_US.UTF-8 is available (see diff -Nru phpmyadmin-4.6.6/debian/conf/apache.conf phpmyadmin-4.6.6/debian/conf/apache.conf --- phpmyadmin-4.6.6/debian/conf/apache.conf2016-12-01 04:42:43.0 -0300 +++ phpmyadmin-4.6.6/debian/conf/apache.conf2019-11-06 08:12:18.0 -0300 @@ -29,7 +29,7 @@ php_value include_path . php_admin_value upload_tmp_dir /var/lib/phpmyadmin/tmp -php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/php/php-gettext/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/ +php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/php/php-php-gettext/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/ php_admin_value mbstring.func_overload 0 diff -Nru phpmyadmin-4.6.6/debian/control phpmyadmin-4.6.6/debian/control --- phpmyadmin-4.6.6/debian/c
Bug#937338: pulseaudio-equalizer python3 patch in fedora
Control: tags -1 pending On Fri, Oct 25, 2019 at 5:03 AM Andreas Henriksson wrote: > Hello, > > FYI it seems fedora have switched their packaging over to python3 > already and they carry this (trivial) patch: > > https://src.fedoraproject.org/rpms/pulseaudio/blob/master/f/pulseaudio-qpaeq_python3.patch > > See also their dependency specification at: > > https://src.fedoraproject.org/rpms/pulseaudio/blob/master/f/pulseaudio.spec#_133 Thanks, I'll be uploading this soon. -- Saludos, Felipe Sateler
Bug#942260: pulseaudio: The pulseaudio use id for normal user.
Control: tags -1 moreinfo unreproducible On Sun, Oct 13, 2019 at 7:21 AM Corcodel Marian wrote: > Package: pulseaudio > Version: 10.0-1+deb9u1 > Severity: normal > > Inspect /etc/passwd and see on user pulse uid and guid number upper 1000 , > this > is bad wich in not normal user, i replaced with 999 on both places , > solved on > kdm manager to hide user pulse on login. > Mine has id 114. The postinst script does use the --system flag. Did you create that user yourself? I can't reproduce the problem. -- Saludos, Felipe Sateler
Bug#941794: pulseaudio: please drop obsolete gconf build-dependency
On Sun, Oct 6, 2019 at 9:42 AM Simon McVittie wrote: > On Sat, 05 Oct 2019 at 15:52:10 +0200, Andreas Henriksson wrote: > > Please remove the obsolete build-dependency on libgconf2-dev. > > > > The package currently already builds with --disable-gconf configure > > flag. I've also test-built the package without the libgconf2-dev > > build-dependency. > > I've checked this with diffoscope and there doesn't seem to be any > difference between the resulting binaries, other than the varying path > to the build tree being encoded into the binaries in a few places. > So this change seems entirely safe to make. > Thanks, I have pushed the patch to salsa. Indeed gconf is no longer used as we now use the gsettings backend. I am not carrying my gpg keys now, so I can't upload. Please feel free to upload if you need to unblock your work. -- Saludos, Felipe Sateler
Bug#935526: pulseaudio: Pulseaudio no longer recognizes USB devices
On Sun, Sep 15, 2019 at 9:42 AM Guus Sliepen wrote:
> On Mon, Sep 09, 2019 at 08:53:46PM -0300, Felipe Sateler wrote:
>
> > Could you please attach a verbose log of pulseaudio, both versions?
> > https://wiki.ubuntu.com/PulseAudio/Log
>
> Attached are the logs from both versions. Let me know if I need to
> provide any other information.
The log has this:
( 2.849| 0.000) D: [pulseaudio] conf-parser.c: Failed to open
configuration file
'/usr/share/pulseaudio/alsa-mixer/profile-sets/steelseries-arctis-usb-audio.conf':
No such file or directory
This is weird, because that file is not loaded anymore:
% grep steelseries /lib/udev/rules.d/90-pulseaudio.rules
ATTRS{idVendor}=="1038", ATTRS{idProduct}=="1250",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-5-usb-audio.conf"
ATTRS{idVendor}=="1038", ATTRS{idProduct}=="1260",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
ATTRS{idVendor}=="1038", ATTRS{idProduct}=="12ad",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
ATTRS{idVendor}=="1038", ATTRS{idProduct}=="1294",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
ATTRS{idVendor}=="1038", ATTRS{idProduct}=="1730",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
So, it seems udev has not picked up the change. There are two options:
1. Have you rebooted your computer since the upgrade? If so, please try
running `udevadm trigger` as root. Maybe udev for some reason did not pick
up the change.
2. Do you have any other file in /{lib,etc}/udev/rules.d mentioning that
file?
--
Saludos,
Felipe Sateler
Bug#940710: Fails to load pkcs8_key_parser module
Control: reassign -1 linux-image-5.2.0-2-amd64 Control: retitle -1 Please enable CONFIG_PKCS8_PRIVATE_KEY_PARSER Hi Andreas, On Tue, Sep 24, 2019 at 1:32 PM Andreas Henriksson wrote: > Hello Felipe Sateler, > > On Tue, Sep 24, 2019 at 10:03:19AM -0300, Felipe Sateler wrote: > > Control: reopen -1 > [...] > > This causes failed boots on debian by default [...] > > Really? Please share more info! It certainly doesn't for me. > Sorry, I was a bit sloppy in my wording. What I mean is that systemd considers the boot degraded because `systemd-modules-load` fails: % systemctl is-system-running degraded % systemctl --no-legend --failed systemd-modules-load.service loaded failed failed Load Kernel Modules % systemctl --no-legend status systemd-modules-load.service ● systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2019-04-11 12:28:36 -04; 5 months 13 days ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 530 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 530 (code=exited, status=1/FAILURE) Apr 11 12:28:36 felipeasus systemd[1]: Starting Load Kernel Modules... Apr 11 12:28:36 felipeasus systemd-modules-load[530]: Failed to find module 'pkcs8_key_parser' Apr 11 12:28:36 felipeasus systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE Apr 11 12:28:36 felipeasus systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'. Apr 11 12:28:36 felipeasus systemd[1]: Failed to start Load Kernel Modules. > (Would also be nice if you reported a dedicated bug report about that > instead of repurposing this.) > Well, the root cause is the same, so I thought I'd just reopen. > > > [...] since the debian kernels don't enable that module: > > > > % grep CONFIG_PKCS8_PRIVATE_KEY_PARSER /boot/config-* > > /boot/config-5.2.0-2-amd64:# CONFIG_PKCS8_PRIVATE_KEY_PARSER is not set > > /boot/config-5.3.0-rc5-amd64:# CONFIG_PKCS8_PRIVATE_KEY_PARSER is not set > > I'm aware that it doesn't (at the moment). AFAIK the usual debian kernel > team policy is to enable things on request, so someone just needs to > request it. Since you're not the first to ask *me* (even though I'm not > on the kernel team) I've already asked on #debian-kernel if they can > enable it while at the same time asking people to please not use me as a > proxy. > I'm sorry you feel like I'm using you as middleman. As I said in the part quoted below, I didn't know if requesting the kernel maintainers to add this option makes sense. I'm happy to request it myself: #941098. > > > > > Since I have no idea what does pkcs8_key_parser do, I don't know if it > > would be best to have linux enable that option or to have iwd not ship > this > > file. > > It is needed if you want to use iwd to connect to wpa enterprise > networks. Thanks for the explanation. This means the best solution (from the iwd POV) is to have the kernel enable the option. I have requested that feature now on #941098. -- Saludos, Felipe Sateler
Bug#941098: linux-image-5.2.0-2-amd64: Please enable CONFIG_PKCS8_PRIVATE_KEY_PARSER
Package: src:linux Version: 5.2.9-2 Severity: wishlist Dear Maintainer, As detailed in #940710, iwd needs this option in order to support enterprise WPA networks. The lack of this module means iwd causes systemd-modules-load to fail at boot. It would be great if it would be enabled. -- Kernel: Linux 5.3.0-rc5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-5.2.0-2-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.135 ii kmod26-3 ii linux-base 4.6 Versions of packages linux-image-5.2.0-2-amd64 recommends: ii apparmor 2.13.3-5 ii firmware-linux-free 3.4 Versions of packages linux-image-5.2.0-2-amd64 suggests: pn debian-kernel-handbook ii grub-efi-amd64 2.04-3 pn linux-doc-5.2 Versions of packages linux-image-5.2.0-2-amd64 is related to: ii firmware-amd-graphics 20190717-2 ii firmware-atheros 20190717-2 ii firmware-bnx2 20190717-2 ii firmware-bnx2x20190717-2 ii firmware-brcm8021120190717-2 ii firmware-cavium 20190717-2 ii firmware-intel-sound 20190717-2 ii firmware-intelwimax 20190717-2 ii firmware-ipw2x00 20190717-2 ii firmware-ivtv 20190717-2 ii firmware-iwlwifi 20190717-2 ii firmware-libertas 20190717-2 ii firmware-linux-nonfree20190717-2 ii firmware-misc-nonfree 20190717-2 ii firmware-myricom 20190717-2 ii firmware-netxen 20190717-2 ii firmware-qlogic 20190717-2 ii firmware-realtek 20190717-2 ii firmware-samsung 20190717-2 ii firmware-siano20190717-2 ii firmware-ti-connectivity 20190717-2 pn xen-hypervisor -- no debconf information
Bug#940710: Fails to load pkcs8_key_parser module
Control: reopen -1 Hi Andreas, On Fri, 20 Sep 2019 15:17:28 +0200 Andreas Henriksson wrote: > Hello Yuri D'Elia, > > Thanks for your bug report. > > On Thu, Sep 19, 2019 at 12:39:32PM +0200, Yuri D'Elia wrote: > > Package: iwd > > Version: 0.21-1 > > Severity: normal > > > > iwd includes /usr/lib/modules-load.d/pkcs8.conf to load pkcs8_key_parser > > when available. This however causes an error message during startup in > > my case, which I'd like to silence. > > Ok. > This causes failed boots on debian by default since the debian kernels don't enable that module: % grep CONFIG_PKCS8_PRIVATE_KEY_PARSER /boot/config-* /boot/config-5.2.0-2-amd64:# CONFIG_PKCS8_PRIVATE_KEY_PARSER is not set /boot/config-5.3.0-rc5-amd64:# CONFIG_PKCS8_PRIVATE_KEY_PARSER is not set Since I have no idea what does pkcs8_key_parser do, I don't know if it would be best to have linux enable that option or to have iwd not ship this file. Saludos
Bug#933192: lintian-brush: complains repository is dirty, but git status lists no files
On Sun, Sep 22, 2019 at 8:52 PM Jelmer Vernooij wrote: > On Sun, Sep 22, 2019 at 08:02:56PM -0300, Felipe Sateler wrote: > > On Sat, Aug 31, 2019 at 7:45 AM Jelmer Vernooij > wrote: > > > On Sun, Jul 28, 2019 at 11:01:29PM -0400, Felipe Sateler wrote: > > > > On Sun, Jul 28, 2019, 18:36 Jelmer Vernooij > wrote: > > > > > On Sat, Jul 27, 2019 at 08:54:17AM -0400, Felipe Sateler wrote: > > > > > > lintian-brush complains repository is dirty, but repo is clean: > > > > > > > > > > > > felipe@felipedell:csound% lintian-brush > > > > > > /home/felipe/src/deb/pkg-multimedia/csound: Please commit pending > > > > > changes first. > > > > > > % git status > > > > > > On branch master > > > > > > Your branch is ahead of 'origin/master' by 3 commits. > > > > > > (use "git push" to publish your local commits) > > > > > > > > > > > > nothing to commit, working tree clean > > > > > > > > > > > > > > > > > > Turns out there are gitignored files: > > > > > > > > > > > > % git clean -fdX > > > > > > Removing .pc/ > > > > > > Removing .vscode/ > > > > > > Removing test.wav > > > > > > > > > > > > After this lintian-brush can work. > > > > > > > > > > > > I think lintian-brush should also ignore gitignored files > > > > > > > > > > lintian-brush attempts to ignore gitignored files, but it seems > that > > > > > this doesn't always work. > > > > > > > > > > In this particular case, it appears that it does properly ignore > > > > > test.wav because "*.wav" exists in .gitignore. > > > > > > > > > > I don't see any matches for .pc/ or .vscode/ in .gitignore though. > Do > > > > > you perhaps have them in ~/.git/ignore ? > > > > Yes, I have .vscode in the global gitignore. > > > > > > > > Were there any files under > > > > > .pc/ or .vscode/ that you can remember? > > > > > > > > > I don't know if .pc had anything in it, but .vscode probably did. > > > Can you try again with dulwich currently in unstable? Several > > > gitignore fixes have gone in that may have addressed this. > > It's still failing. I think global gitignore is not processed by > > lintian-brush. > It does attempt to read global ignore files, and also did at > the time your reported this bug - but it's of course possible that there > is a bug in the way this is done. > > The next version of lintian-brush will spit out what files it > considers still having pending changes when --verbose is specified, so > that should hopefully make it easier to understand what's happening > here. > > How many files does 'git ignore' list as being in use by this repo? > It lists a directory. Perhaps that is the problem? Ignored files: (use "git add -f ..." to include in what will be committed) .vscode/ > > > > I wonder why not just rely on git status (or the plumbing equivalent) > > > > instead of detecting changes manually? > > > Mostly to avoid shelling out - lintian-brush runs the equivalent of > > > git status times before and after running each fixer - that can be > > > quite slow on large repositories, where each run takes ~.5 seconds. > > > > > > > Rather than statting, it uses inotify to watch what files have > > > changed by each fixer, and then checks if those are ignored files or > > > not. > > But why is it necessary to run after each fixer? Perhaps a single one at > > the start is necessary. > Yes - it does this to check if the fixer actually made any changes. > OK. -- Saludos, Felipe Sateler
Bug#940987: rdetails fails: TypeError: sequence item 0: expected str instance, bytes found
Package: apt-xapian-index
Version: 0.50
Severity: important
Hi,
Trying to issue axi-cache rdetails fails:
% axi-cache rdetails apt-xapian-index
Traceback (most recent call last):
File "/usr/bin/axi-cache", line 861, in
sys.exit(ui.perform())
File "/usr/bin/axi-cache", line 852, in perform
return f(self.args)
File "/usr/bin/axi-cache", line 718, in do_rdetails
print(name, tag, " ".join(deps))
TypeError: sequence item 0: expected str instance, bytes found
It seems the query is returning bytes instead of strings. Converting
with utf-8 makes it work (but I have no idea if this fix is correct):
deps = map(lambda x: x.decode('utf-8'), db.get_rdeps(name, pfx))
-- 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.2.0-2-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 apt-xapian-index depends on:
ii python3 3.7.3-1
ii python3-apt 1.8.4
ii python3-debian 0.1.36
ii python3-xapian 1.4.12-2
apt-xapian-index recommends no packages.
Versions of packages apt-xapian-index suggests:
ii python3-xdg 0.25-5
-- no debconf information
Bug#933192: lintian-brush: complains repository is dirty, but git status lists no files
Hi, On Sat, Aug 31, 2019 at 7:45 AM Jelmer Vernooij wrote: > On Sun, Jul 28, 2019 at 11:01:29PM -0400, Felipe Sateler wrote: > > On Sun, Jul 28, 2019, 18:36 Jelmer Vernooij wrote: > > > On Sat, Jul 27, 2019 at 08:54:17AM -0400, Felipe Sateler wrote: > > > > lintian-brush complains repository is dirty, but repo is clean: > > > > > > > > felipe@felipedell:csound% lintian-brush > > > > /home/felipe/src/deb/pkg-multimedia/csound: Please commit pending > > > changes first. > > > > % git status > > > > On branch master > > > > Your branch is ahead of 'origin/master' by 3 commits. > > > > (use "git push" to publish your local commits) > > > > > > > > nothing to commit, working tree clean > > > > > > > > > > > > Turns out there are gitignored files: > > > > > > > > % git clean -fdX > > > > Removing .pc/ > > > > Removing .vscode/ > > > > Removing test.wav > > > > > > > > After this lintian-brush can work. > > > > > > > > I think lintian-brush should also ignore gitignored files > > > > > > lintian-brush attempts to ignore gitignored files, but it seems that > > > this doesn't always work. > > > > > > In this particular case, it appears that it does properly ignore > > > test.wav because "*.wav" exists in .gitignore. > > > > > > I don't see any matches for .pc/ or .vscode/ in .gitignore though. Do > > > you perhaps have them in ~/.git/ignore ? > > Yes, I have .vscode in the global gitignore. > > > > Were there any files under > > > .pc/ or .vscode/ that you can remember? > > > > > I don't know if .pc had anything in it, but .vscode probably did. > Can you try again with dulwich currently in unstable? Several > gitignore fixes have gone in that may have addressed this. > It's still failing. I think global gitignore is not processed by lintian-brush. > > > I wonder why not just rely on git status (or the plumbing equivalent) > > instead of detecting changes manually? > Mostly to avoid shelling out - lintian-brush runs the equivalent of > git status times before and after running each fixer - that can be > quite slow on large repositories, where each run takes ~.5 seconds. > Rather than statting, it uses inotify to watch what files have > changed by each fixer, and then checks if those are ignored files or > not. > But why is it necessary to run after each fixer? Perhaps a single one at the start is necessary. -- Saludos, Felipe Sateler
Bug#935526: pulseaudio: Pulseaudio no longer recognizes USB devices
On Fri, Aug 23, 2019 at 10:42 AM Guus Sliepen wrote: > Package: pulseaudio > Version: 12.99.2-1 > Severity: normal > > After upgrading to 12.99.2-1, pulseaudio no longer recognizes USB audio > devices, even though ALSA sees them correctly. It is possible to > manually add a USB audio device after pulseaudio has started, by running > "pactl load-module module-alsa-sink device=hw:X", but this is of course > sub-optimal. Downgrading pulseaudio to version 12.2-4 from Buster fixes > the issue. > > Output of "aplay -l | grep card": > > card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] > card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] > card 0: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2] > card 0: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3] > card 1: Generic [HD-Audio Generic], device 0: ALC1220 Analog [ALC1220 > Analog] > card 1: Generic [HD-Audio Generic], device 1: ALC1220 Digital [ALC1220 > Digital] > card 2: S7 [SteelSeries Arctis 7], device 0: USB Audio [USB Audio] > card 2: S7 [SteelSeries Arctis 7], device 1: USB Audio [USB Audio #1] > card 3: Microphone [Yeti Stereo Microphone], device 0: USB Audio [USB > Audio] > > Output of "pactl list short sinks" with pulseaudio 12.99.2-1: > > 0alsa_output.pci-_09_00.1.hdmi-stereo-extra1 module-alsa-card.c > s16le 2ch 44100HzIDLE > 1alsa_output.pci-_0b_00.4.analog-stereo module-alsa-card.c > s16le 2ch 44100HzIDLE > > Output of "pactl list short sinks" with pulseaudio 12.2-4: > > 0alsa_output.pci-_09_00.1.hdmi-stereo-extra1 module-alsa-card.c > s16le 2ch 44100HzIDLE > 1alsa_output.pci-_0b_00.4.analog-stereo module-alsa-card.c > s16le 2ch 44100HzIDLE > 2alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.analog-mono > module-alsa-card.cs16le 1ch 44100HzIDLE > 3alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.analog-stereo > module-alsa-card.c s16le 2ch 44100HzIDLE > > Could you please attach a verbose log of pulseaudio, both versions? https://wiki.ubuntu.com/PulseAudio/Log -- Saludos, Felipe Sateler
Bug#933911: buster-pu: package pulseaudio
On Tue, Aug 20, 2019 at 4:47 PM Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2019-08-15 at 11:28 -0400, Felipe Sateler wrote: > > Control: tags -1 -moreinfo > > > > On Sun, Aug 11, 2019 at 9:53 AM Jonathan Wiltshire > > wrote: > > > Control: tag -1 moreinfo > > > > > > Hi, > > > > > > On Sun, Aug 04, 2019 at 09:31:37PM -0400, Felipe Sateler wrote: > [...] > > > > There is a bug affecting pulseaudio users: #913102. This bug > > > causes the > > > > mute state to be incorrectly restored. Some users have asked for > > > the fix > > > > (which is now on unstable), to be backported to buster given that > > > GDM is > > > > affected by this bug. The upstream patch fixing this issue is > > > very > > > > small[1]. > > Please go ahead; thanks. > Done, thank you -- Saludos, Felipe Sateler
Bug#935405: Please drop static user service symlinks
Control: severity -1 important On Thu, Aug 22, 2019 at 6:39 AM Michael Biebl wrote: > Package: pulseaudio > Version: 12.99.2-1 > Severity: normal > > Hi Felipe, > > I noticed that you bumped compat level to 12 for pulseaudio, i.e. > dh_installsystemduser is now active by default and the symlinks for > pulseaudio.socket and pulseaudio.service are now created dynamically as > /etc/systemd/user/default.target.wants/pulseaudio.service > /etc/systemd/user/sockets.target.wants/pulseaudio.socket > > Please consider dropping the static symlink in > /usr/lib/systemd/user/sockets.target.wants/pulseaudio.socket > Right, thanks for noticing. -- Saludos, Felipe Sateler
Bug#935047: pulseaudio: regularly stops producing sound over USB interface
Control: reassign -1 linux-image-5.2.0-2-amd64 On Tue, Aug 20, 2019 at 3:51 AM Adrian Heine wrote: > Sigh, after doing this I downgraded to pulseaudio 10.0 in the same > session and still have the issue; I rebooted to be sure but it's still > there. I swear it worked reliably for days after downgrading for the > first time. Since the pulseaudio output doesn't show anything helpful as > far as I can see it probably makes sense to have a look at alsa? > The only hint I can see is that there is a buffer overrun and then pulseaudio tries to rewind. This most likely signals a bug in the driver, possibly pulseaudio does something the driver did not expect. As an additional debugging step, could you try adding tsched=0 to your config? https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Glitches.2C_skips_or_crackling Sometimes driver bugs area avoided by using that option -- Saludos, Felipe Sateler
Bug#887736: stretch-pu: package openvswitch/2.6.2~pre+git20161223-3
On Tue, Aug 20, 2019 at 6:23 PM Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Fri, 2018-01-19 at 15:21 +0100, Thomas Goirand wrote: > > I started maintaining OpenVSwitch long after the Stretch release, and > > discovered #858418, which is very annoying for OpenVSwitch users. > > > > tl;dr: #858418 prevent anyone that has a valid > > /etc/network/interfaces > > with OpenVSwitch directive from having a working network at boot. The > > init script uses a non-documented, not-to-be-used systemd internal, > > which is miserably failing. > > > > After a long discussion with the bug reporter (which can be read on > > the BTS), I came to the conclusion that he's right, and that the most > > reasonable and safe way to fix the current situation is to apply the > > patch he suggested (and which resulting debdiff I attached to this > > bug). > > As I understand things, that fix swaps use of one systemd internal for > another, which doesn't seem like a great plan. > > When this was discussed (some time ago) on IRC, one of the systemd > maintainers essentially said "don't do that". With apologies for the > delay in doing so, I've CCed the maintainer list to see if we can find > a mutually acceptable solution. > Both `service` and `invoke-rc.d` wrappers have a few safeguards against running in unwanted contexts. Have you tried using one of them? -- Saludos, Felipe Sateler
Bug#917222: znc: please provide a znc-plugin-$version that external plugins can depend on
On Mon, Aug 19, 2019, 11:04 Mattia Rizzolo wrote: > Hi Felipe, > > On Sun, Aug 11, 2019 at 07:23:24PM -0400, Felipe Sateler wrote: > > > znc-backlog is a single 253 lines file, whereas znc-push is ~2000 > lines. > > > Both change very rarely, so I think it would be feasible to just put > > > both of them within src:znc's debian/ and build them from there. Then > > > put them in separate binary packages, with the description explicitly > > > saying they are contrib modules. > > > I'll also be happy to help out with the maintenance of these parts if > > > you'd like to, not to mention provide a full patch. > > Patrick gave me a green light to do this, together with access to his > svn server, so we can co-maintain znc. > Would you be ok if I just took over znc-backlog from you? > I would be just embedding the few files within debian/, and building a > znc-backlog binary versioned as 0.20180824+$(znc version), so that > upgrades are easy, and an eventual de-embedding in the future also > stays simple to do. > Sure, go ahead! Backlog is pretty much "finished" so updates should be rare. Thank you!
Bug#935047: pulseaudio: regularly stops producing sound over USB interface
Control: tags -1 moreinfo On Sun, Aug 18, 2019 at 11:54 AM Adrian Heine wrote: > Package: pulseaudio > Version: 12.2-5 > Severity: important > > I'm using a Focusrite Scarlett Solo attached over USB. Every few minutes, > the setup goes quiet until I disconnect and reconnect the USB interface. > The pulseaudio log doesn't show anything when the sound stops working. > > This bug is reproducible on two different computers when they run > pulseaudio > from stable (I think it started with 12.0-1), but stopped appearing once I > downgraded to 10.0-1+deb9u1 from oldstable. > Could you please attach a pulseaudio verbose log? % systemctl --user --edit --runtime pulseaudio.service # insert this ExecStart= ExecStart=/usr/bin/pulseaudio --daemonize=no - % systemctl --user restart pulseaudio.service # Wait for the problem to occur again journalctl --user-unit pulseaudio.service --since= > pulseaudio.log Also, please attach the output of `pactl list` both when the interface is working and when it isn't. -- Saludos, Felipe Sateler
Bug#933911: buster-pu: package pulseaudio
Control: tags -1 -moreinfo
On Sun, Aug 11, 2019 at 9:53 AM Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
>
> Hi,
>
> On Sun, Aug 04, 2019 at 09:31:37PM -0400, Felipe Sateler wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: buster
> > User: release.debian@packages.debian.org
> > Usertags: pu
> >
> > Dear release team,
> >
> > There is a bug affecting pulseaudio users: #913102. This bug causes the
> > mute state to be incorrectly restored. Some users have asked for the fix
> > (which is now on unstable), to be backported to buster given that GDM is
> > affected by this bug. The upstream patch fixing this issue is very
> > small[1].
> >
> > The full diff is attached.
>
> The attachment looks like the change as it was uploaded to sid; please
> prepare a proposed update to buster and attach a source debdiff and remove
> the moreinfo tag from this bug.
>
Please find the debdiff attached
--
Saludos,
Felipe Sateler
diff -Nru pulseaudio-12.2/debian/changelog pulseaudio-12.2/debian/changelog
--- pulseaudio-12.2/debian/changelog 2019-02-14 20:05:41.0 -0300
+++ pulseaudio-12.2/debian/changelog 2019-08-15 11:21:19.0 -0400
@@ -1,3 +1,10 @@
+pulseaudio (12.2-4+deb10u1) buster; urgency=medium
+
+ * Pick upstream patch fixing mute state restoring (Closes: #913102)
+ * Add gbp config for buster branch
+
+ -- Felipe Sateler Thu, 15 Aug 2019 11:21:19 -0400
+
pulseaudio (12.2-4) unstable; urgency=medium
[ Jan Graichen ]
diff -Nru pulseaudio-12.2/debian/gbp.conf pulseaudio-12.2/debian/gbp.conf
--- pulseaudio-12.2/debian/gbp.conf 2019-02-14 20:05:41.0 -0300
+++ pulseaudio-12.2/debian/gbp.conf 2019-08-15 11:21:19.0 -0400
@@ -1,2 +1,3 @@
[DEFAULT]
pristine-tar = True
+debian-branch = debian/buster
diff -Nru pulseaudio-12.2/debian/patches/series pulseaudio-12.2/debian/patches/series
--- pulseaudio-12.2/debian/patches/series 2019-02-14 20:05:41.0 -0300
+++ pulseaudio-12.2/debian/patches/series 2019-08-15 11:21:19.0 -0400
@@ -2,3 +2,4 @@
alsa-mixer-Update-to-support-Arctis-Pro-Wireless-headset.patch
alsa-mixer-Add-support-for-2018-Arctis-7.patch
Don-t-compile-with-ffast-math.patch
+sink-source-Don-t-change-suspend-cause-when-unlinking.patch
diff -Nru pulseaudio-12.2/debian/patches/sink-source-Don-t-change-suspend-cause-when-unlinking.patch pulseaudio-12.2/debian/patches/sink-source-Don-t-change-suspend-cause-when-unlinking.patch
--- pulseaudio-12.2/debian/patches/sink-source-Don-t-change-suspend-cause-when-unlinking.patch 1969-12-31 21:00:00.0 -0300
+++ pulseaudio-12.2/debian/patches/sink-source-Don-t-change-suspend-cause-when-unlinking.patch 2019-08-15 11:21:19.0 -0400
@@ -0,0 +1,47 @@
+From: Tanu Kaskinen
+Date: Mon, 10 Jun 2019 14:18:47 +0300
+Subject: sink, source: Don't change suspend cause when unlinking
+
+See the added comments for why this is necessary.
+
+Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/667
+(cherry picked from commit 7fb85e0a5bfdec339fda9f7584f65cf9ddbd50a1)
+---
+ src/pulsecore/sink.c | 6 +-
+ src/pulsecore/source.c | 6 +-
+ 2 files changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
+index 38e8e50..4a0 100644
+--- a/src/pulsecore/sink.c
b/src/pulsecore/sink.c
+@@ -760,7 +760,11 @@ void pa_sink_unlink(pa_sink* s) {
+ }
+
+ if (linked)
+-sink_set_state(s, PA_SINK_UNLINKED, 0);
++/* It's important to keep the suspend cause unchanged when unlinking,
++ * because if we remove the SESSION suspend cause here, the alsa sink
++ * will sync its volume with the hardware while another user is
++ * active, messing up the volume for that other user. */
++sink_set_state(s, PA_SINK_UNLINKED, s->suspend_cause);
+ else
+ s->state = PA_SINK_UNLINKED;
+
+diff --git a/src/pulsecore/source.c b/src/pulsecore/source.c
+index 02ae87a..c11d89b 100644
+--- a/src/pulsecore/source.c
b/src/pulsecore/source.c
+@@ -702,7 +702,11 @@ void pa_source_unlink(pa_source *s) {
+ }
+
+ if (linked)
+-source_set_state(s, PA_SOURCE_UNLINKED, 0);
++/* It's important to keep the suspend cause unchanged when unlinking,
++ * because if we remove the SESSION suspend cause here, the alsa
++ * source will sync its volume with the hardware while another user is
++ * active, messing up the volume for that other user. */
++source_set_state(s, PA_SOURCE_UNLINKED, s->suspend_cause);
+ else
+ s->state = PA_SOURCE_UNLINKED;
+
Bug#917222: znc: please provide a znc-plugin-$version that external plugins can depend on
On Sat, Aug 10, 2019 at 6:12 AM Mattia Rizzolo wrote: > On Mon, Dec 24, 2018 at 08:44:25AM -0300, Felipe Sateler wrote: > > > > 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. > > ivodd proposed the other day on #-relase to instead have these type of > plugins embedded in src:znc. > > I'm also extremely interested in this as, following on the shoes of > znc-backlog, I've packaged znc-push. > > znc-backlog is a single 253 lines file, whereas znc-push is ~2000 lines. > Both change very rarely, so I think it would be feasible to just put > both of them within src:znc's debian/ and build them from there. Then > put them in separate binary packages, with the description explicitly > saying they are contrib modules. > I'll also be happy to help out with the maintenance of these parts if > you'd like to, not to mention provide a full patch. > /me wonders why are we pushing manual work to developers when all it takes to fix this problem is to automatically rebuild reverse dependencies on new uploads. Don't we have a solution for this already? How do go or haskell packages do this? -- 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#933911: buster-pu: package pulseaudio
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
There is a bug affecting pulseaudio users: #913102. This bug causes the
mute state to be incorrectly restored. Some users have asked for the fix
(which is now on unstable), to be backported to buster given that GDM is
affected by this bug. The upstream patch fixing this issue is very
small[1].
The full diff is attached.
[1]
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/105/diffs?commit_id=7fb85e0a5bfdec339fda9f7584f65cf9ddbd50a1
-- 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 4.19.0-5-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
diff --git a/debian/changelog b/debian/changelog
index 02916c2a1..1b9633855 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+pulseaudio (12.2-5) unstable; urgency=medium
+
+ * Pick upstream patch fixing mute state restoring (Closes: #913102)
+
+ -- Felipe Sateler Sun, 04 Aug 2019 21:18:02 -0400
+
pulseaudio (12.2-4) unstable; urgency=medium
[ Jan Graichen ]
diff --git a/debian/patches/series b/debian/patches/series
index 3e43a7538..37a72b94f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ volume-test.patch
alsa-mixer-Update-to-support-Arctis-Pro-Wireless-headset.patch
alsa-mixer-Add-support-for-2018-Arctis-7.patch
Don-t-compile-with-ffast-math.patch
+sink-source-Don-t-change-suspend-cause-when-unlinking.patch
diff --git
a/debian/patches/sink-source-Don-t-change-suspend-cause-when-unlinking.patch
b/debian/patches/sink-source-Don-t-change-suspend-cause-when-unlinking.patch
new file mode 100644
index 0..efa780834
--- /dev/null
+++ b/debian/patches/sink-source-Don-t-change-suspend-cause-when-unlinking.patch
@@ -0,0 +1,47 @@
+From: Tanu Kaskinen
+Date: Mon, 10 Jun 2019 14:18:47 +0300
+Subject: sink, source: Don't change suspend cause when unlinking
+
+See the added comments for why this is necessary.
+
+Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/667
+(cherry picked from commit 7fb85e0a5bfdec339fda9f7584f65cf9ddbd50a1)
+---
+ src/pulsecore/sink.c | 6 +-
+ src/pulsecore/source.c | 6 +-
+ 2 files changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
+index 38e8e50..4a0 100644
+--- a/src/pulsecore/sink.c
b/src/pulsecore/sink.c
+@@ -760,7 +760,11 @@ void pa_sink_unlink(pa_sink* s) {
+ }
+
+ if (linked)
+-sink_set_state(s, PA_SINK_UNLINKED, 0);
++/* It's important to keep the suspend cause unchanged when unlinking,
++ * because if we remove the SESSION suspend cause here, the alsa sink
++ * will sync its volume with the hardware while another user is
++ * active, messing up the volume for that other user. */
++sink_set_state(s, PA_SINK_UNLINKED, s->suspend_cause);
+ else
+ s->state = PA_SINK_UNLINKED;
+
+diff --git a/src/pulsecore/source.c b/src/pulsecore/source.c
+index 02ae87a..c11d89b 100644
+--- a/src/pulsecore/source.c
b/src/pulsecore/source.c
+@@ -702,7 +702,11 @@ void pa_source_unlink(pa_source *s) {
+ }
+
+ if (linked)
+-source_set_state(s, PA_SOURCE_UNLINKED, 0);
++/* It's important to keep the suspend cause unchanged when unlinking,
++ * because if we remove the SESSION suspend cause here, the alsa
++ * source will sync its volume with the hardware while another user is
++ * active, messing up the volume for that other user. */
++source_set_state(s, PA_SOURCE_UNLINKED, s->suspend_cause);
+ else
+ s->state = PA_SOURCE_UNLINKED;
+
Bug#913102: Re[2]: Bug#913102: pulseaudio does not restore correct mic/speaker state
Control: tags -1 =patch help On Sun, Jul 28, 2019 at 1:45 PM Алексей Шилин wrote: > This is a pulseaudio bug [1]. It is triggered by recent changes in GDM > (which began to > terminate itself shortly after a user logs in) and seems to affect all GDM > users. > > Given that GDM is part of a default Debian desktop installation, is it > possible to fix this > issue in the next stable point release? > The patch looks very simple, so I think yes. Unfortunately the first point release is very close (possibly this weekend) so I'm not sure we can make it. Help appreciated to prepare the stable update. > > (The patch that I sent previously was cherry-picked from pulseaudio git > master.) > > [1] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/667 > > -- Saludos, Felipe Sateler
Bug#933192: lintian-brush: complains repository is dirty, but git status lists no files
On Sun, Jul 28, 2019, 18:36 Jelmer Vernooij wrote: > Hi Felipe, > > Thanks for the bug report. > > On Sat, Jul 27, 2019 at 08:54:17AM -0400, Felipe Sateler wrote: > > lintian-brush complains repository is dirty, but repo is clean: > > > > felipe@felipedell:csound% lintian-brush > > /home/felipe/src/deb/pkg-multimedia/csound: Please commit pending > changes first. > > % git status > > On branch master > > Your branch is ahead of 'origin/master' by 3 commits. > > (use "git push" to publish your local commits) > > > > nothing to commit, working tree clean > > > > > > Turns out there are gitignored files: > > > > % git clean -fdX > > Removing .pc/ > > Removing .vscode/ > > Removing test.wav > > > > After this lintian-brush can work. > > > > I think lintian-brush should also ignore gitignored files > > lintian-brush attempts to ignore gitignored files, but it seems that > this doesn't always work. > > In this particular case, it appears that it does properly ignore > test.wav because "*.wav" exists in .gitignore. > > I don't see any matches for .pc/ or .vscode/ in .gitignore though. Do > you perhaps have them in ~/.git/ignore ? Yes, I have .vscode in the global gitignore. Were there any files under > .pc/ or .vscode/ that you can remember? > I don't know if .pc had anything in it, but .vscode probably did. I wonder why not just rely on git status (or the plumbing equivalent) instead of detecting changes manually? >
Bug#933192: lintian-brush: complains repository is dirty, but git status lists no files
Package: lintian-brush Version: 0.17 Severity: normal Hi, lintian-brush complains repository is dirty, but repo is clean: felipe@felipedell:csound% lintian-brush /home/felipe/src/deb/pkg-multimedia/csound: Please commit pending changes first. % git status On branch master Your branch is ahead of 'origin/master' by 3 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean Turns out there are gitignored files: % git clean -fdX Removing .pc/ Removing .vscode/ Removing test.wav After this lintian-brush can work. I think lintian-brush should also ignore gitignored files -- 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 4.19.0-5-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 lintian-brush depends on: ii devscripts 2.19.6 ii python3 3.7.3-1 ii python3-breezy 3.0.1-1 ii python3-debian 0.1.35 ii python3-distro-info 0.21 ii python3-dulwich 0.19.11-2 ii python3-levenshtein 0.12.0-3 ii python3-pkginfo 1.4.2-2 ii python3-ruamel.yaml 0.15.34-1+b1 Versions of packages lintian-brush recommends: ii dos2unix 7.4.0-2 ii gpg 2.2.17-3 ii lintian 2.16.0 lintian-brush suggests no packages. -- no debconf information
Bug#927022: /usr/bin/sensible-editor: Prints stderr from which
Package: sensible-utils Version: 0.0.12 Followup-For: Bug #927022 Control: tags -1 patch > sensible-editor is not discarding the stderr from which, thus its error > messages are printed when EDITOR VISUAL and SELECTED_EDITOR are empty: I have posted a MR on salsa eliding the check if the variable is empty on all three sensible- utils. https://salsa.debian.org/debian/sensible-utils/merge_requests/2 -- 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 4.19.0-5-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 -- no debconf information
Bug#933044: dgit: should not require --overwrite when debian/changelog contains the version in unstable
Package: dgit Version: 9.6 Severity: normal Hi, --overwrite does not trust debian/changelog. If debian/changelog says it contains version 1.2.3-1, then dgit should trust it and do the fake merge if required. Or maybe rephrase this as a question: why doesn't dgit consider the debian/changelog information authoritative? As things currently stand, --overwrite is required for most upload operations, since (a) dgit is not that popular yet, and (b) most packages use the patches-unapplied layout. -- 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 4.19.0-5-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 dgit depends on: ii apt 1.8.2 ii ca-certificates 20190110 ii coreutils 8.30-3 ii curl7.65.1-1 ii devscripts 2.19.6 ii dpkg-dev1.19.7 ii dput-ng [dput] 1.28 ii git [git-core] 1:2.22.0-1 ii git-buildpackage0.9.14 pn libdigest-sha-perl ii libdpkg-perl1.19.7 ii libjson-perl4.02000-1 ii liblist-moreutils-perl 0.416-1+b4 ii liblocale-gettext-perl 1.07-3+b4 ii libtext-glob-perl 0.10-1 ii libtext-iconv-perl 1.7-6 ii libwww-curl-perl4.17-5 ii perl5.28.1-6 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:8.0p1-3 Versions of packages dgit suggests: ii cowbuilder 0.88 ii pbuilder0.230.4 ii sbuild 0.78.1-2 -- no debconf information
Bug#932767: gnome-shell: Segmentation fault in js engine
Control: retitle -1 gnome-shell: crash on monitor unplug On Tue, Jul 23, 2019 at 9:58 AM Felipe Sateler wrote: > > > On Mon, Jul 22, 2019 at 5:02 PM Simon McVittie wrote: > >> I think this is the actual crash: >> >> On Mon, 22 Jul 2019 at 16:31:43 -0400, Felipe Sateler wrote: >> > #24 0x7f1624226c1a in malloc_printerr (str=str@entry=0x7f162432943b >> "free(): invalid pointer") at malloc.c:5341 >> > #25 0x7f162422842c in _int_free (av=, p=> out>, have_lock=) at malloc.c:4165 >> > #26 0x7f1621ef35cd in js::jit::MCallGetProperty::name() const >> (this=) at ./js/src/jit/shared/Assembler-shared.h:253 >> >> Unfortunately this is often a result of prior memory corruption, so >> it's unlikely to be feasible to debug without knowing how to reproduce it. >> >> Are there any interesting assertion messages from gnome-shell in the >> system log? >> > > So, I think there are more interesting logs without filtering for > gnome-shell. It appears the cause is unplugging my usb C hub, which in turn > has the HDMI connector for the external monitor. > This suspicion appears correct. I have just crashed gnome-shell by unplugging the hub, and then just unplugging the HDMI cable. Same `malloc_printerr`, but this time it is a SIGABRT though: Core was generated by `/usr/bin/gnome-shell'. Program terminated with signal SIGABRT, Aborted. #0 raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. [Current thread is 1 (Thread 0x7fe809d891c0 (LWP 18208))] (gdb) bt #0 0x7fe8109b85cb in raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x5643279b2e2b in () #2 0x7fe8109b8730 in () at /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x7fe81081c7bb in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #4 0x7fe810807535 in __GI_abort () at abort.c:79 #5 0x7fe81085e508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fe81096928d "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #6 0x7fe810864c1a in malloc_printerr (str=str@entry=0x7fe81096743b "free(): invalid pointer") at malloc.c:5341 #7 0x7fe81086642c in _int_free (av=, p=, have_lock=) at malloc.c:4165 #8 0x7fe810c763f1 in clutter_text_set_font_description_internal (is_default_font=0, desc=0x564328791690, self=0x5643287eb070) at clutter-text.c:757 #9 0x7fe810c763f1 in clutter_text_set_font_description (self=0x5643287eb070, font_desc=0x564328791690) at clutter-text.c:5219 #10 0x7fe8107a582e in _st_set_text_from_style () at /usr/lib/gnome-shell/libst-1.0.so #11 0x7fe8107a49f7 in () at /usr/lib/gnome-shell/libst-1.0.so #12 0x7fe8116850c6 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #13 0x7fe8116a157d in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x7fe8116a1b6f in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x7fe8107be443 in () at /usr/lib/gnome-shell/libst-1.0.so #16 0x7fe810c0b3bd in clutter_actor_set_mapped (self=0x56432be23fc0, mapped=) at clutter-actor.c:1285 #17 0x7fe810c0e1a2 in clutter_actor_update_map_state (self=0x56432be23fc0, change=) at clutter-actor.c:1468 #18 0x7fe810c0e480 in clutter_actor_real_map (self=) at clutter-actor.c:1532 #19 0x7fe8107bf4e9 in () at /usr/lib/gnome-shell/libst-1.0.so #20 0x7fe810c0b3bd in clutter_actor_set_mapped (self=0x56432a393540, mapped=) at clutter-actor.c:1285 #21 0x7fe810c0e1a2 in clutter_actor_update_map_state (self=0x56432a393540, change=) at clutter-actor.c:1468 #22 0x7fe810c0e480 in clutter_actor_real_map (self=) at clutter-actor.c:1532 #23 0x7fe8107bf4e9 in () at /usr/lib/gnome-shell/libst-1.0.so #24 0x7fe810c0b3bd in clutter_actor_set_mapped (self=0x564329d80550, mapped=) at clutter-actor.c:1285 #25 0x7fe810c0e1a2 in clutter_actor_update_map_state (self=0x564329d80550, change=) at clutter-actor.c:1468 #26 0x7fe810c0e480 in clutter_actor_real_map (self=) at clutter-actor.c:1532 #27 0x7fe8107bf4e9 in () at /usr/lib/gnome-shell/libst-1.0.so #28 0x7fe810c0b3bd in clutter_actor_set_mapped (self=0x56432cf88510, mapped=) at clutter-actor.c:1285 #29 0x7fe810c0e1a2 in clutter_actor_update_map_state (self=0x56432cf88510, change=) at clutter-actor.c:1468 #30 0x7fe810c0e480 in clutter_actor_real_map (self=) at clutter-actor.c:1532 #31 0x7fe8107bf4e9 in () at /usr/lib/gnome-shell/libst-1.0.so #32 0x7fe810c0b3bd in clutter_actor_set_mapped (self=0x564328395930, mapped=) at clutter-actor.c:1285 #33 0x7fe810c0e1a2 in clutter_actor_update_map_state (self=0x564328395930, change=) at clutter-actor.c:1468 #34 0x7fe810c0e480 in clutter_actor_real_map (self=) at clutter-actor.c:1532 #35 0x7fe8107bf4e9 in () at /usr/lib/gnome-shell/libst-1.0.so #36 0x7fe810c0b3b
Bug#932767: gnome-shell: Segmentation fault in js engine
On Mon, Jul 22, 2019 at 5:02 PM Simon McVittie wrote: > I think this is the actual crash: > > On Mon, 22 Jul 2019 at 16:31:43 -0400, Felipe Sateler wrote: > > #24 0x7f1624226c1a in malloc_printerr (str=str@entry=0x7f162432943b > "free(): invalid pointer") at malloc.c:5341 > > #25 0x7f162422842c in _int_free (av=, p= out>, have_lock=) at malloc.c:4165 > > #26 0x7f1621ef35cd in js::jit::MCallGetProperty::name() const > (this=) at ./js/src/jit/shared/Assembler-shared.h:253 > > Unfortunately this is often a result of prior memory corruption, so > it's unlikely to be feasible to debug without knowing how to reproduce it. > > Are there any interesting assertion messages from gnome-shell in the > system log? > So, I think there are more interesting logs without filtering for gnome-shell. It appears the cause is unplugging my usb C hub, which in turn has the HDMI connector for the external monitor. -- Logs begin at Sun 2019-03-24 17:30:04 -03, end at Tue 2019-07-23 09:55:32 -04. -- Jul 22 14:50:26 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-11ms) Jul 22 14:50:26 felipedell google-chrome.desktop[2665]: [3230:3230:0722/145026.621040:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL comm Jul 22 14:50:27 felipedell google-chrome.desktop[2665]: [3160:3160:0722/145027.070494:ERROR:os_exchange_data_provider_aurax11.cc(498)] Not implemented reached in virtual uint32_t ui::OSExchangeDataProviderAuraX11: Jul 22 14:50:27 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-1ms) Jul 22 14:50:42 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce: offset negative (-0ms) Jul 22 14:50:42 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce: offset negative (-7ms) Jul 22 14:50:42 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-20ms) Jul 22 14:50:51 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-0ms) Jul 22 14:51:00 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-3ms) Jul 22 14:51:05 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-6ms) Jul 22 14:53:08 felipedell kernel: perf: interrupt took too long (4055 > 4048), lowering kernel.perf_event_max_sample_rate to 49250 Jul 22 14:56:54 felipedell gnome-shell[2665]: Object St.Button (0x5631b4ff6e30), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using s Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: == Stack trace for context 0x5631b21531f0 == Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #0 5631b563d6b8 i /home/felipe/.local/share/gnome-shell/extensions/hibernate-status@dromi/extension.js:202 (7f15e2e3ac10 @ 353) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #1 7ffcc6b61610 b resource:///org/gnome/gjs/modules/_legacy.js:82 (7f15e3fb0b80 @ 71) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #2 5631b563d5f8 i resource:///org/gnome/shell/ui/extensionSystem.js:83 (7f15e3b54d30 @ 436) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #3 5631b563d578 i resource:///org/gnome/shell/ui/extensionSystem.js:354 (7f15e3b5b8b0 @ 13) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #4 7ffcc6b625b0 b self-hosted:261 (7f15e3fc1dc0 @ 223) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #5 5631b563d4f8 i resource:///org/gnome/shell/ui/extensionSystem.js:353 (7f15e3b5b820 @ 64) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #6 5631b563d478 i resource:///org/gnome/shell/ui/extensionSystem.js:371 (7f15e3b5b940 @ 87) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #7 7ffcc6b63700 b resource:///org/gnome/gjs/modules/signals.js:128 (7f15e3fc18b0 @ 386) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #8 7ffcc6b64330 b resource:///org/gnome/shell/ui/sessionMode.js:206 (7f15e3a40790 @ 254) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #9 7ffcc6b64fb0 b resource:///org/gnome/gjs/modules/_legacy.js:82 (7f15e3fb0b80 @ 71) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #10 5631b563d338 i resource:///org/gnome/shell/ui/sessionMode.js:168 (7f15e3a40550 @ 40) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #11 7ffcc6b65f30 b resource:///org/gnome/gjs/modules/_legacy.js:82 (7f15e3fb0b80 @ 71) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #12 5631b563d290 i resource:///org/gnome/shell/ui/screenShield.js:127
Bug#932767: gnome-shell: Segmentation fault in js engine
On Mon, Jul 22, 2019 at 5:02 PM Simon McVittie wrote: > I think this is the actual crash: > > On Mon, 22 Jul 2019 at 16:31:43 -0400, Felipe Sateler wrote: > > #24 0x7f1624226c1a in malloc_printerr (str=str@entry=0x7f162432943b > "free(): invalid pointer") at malloc.c:5341 > > #25 0x7f162422842c in _int_free (av=, p= out>, have_lock=) at malloc.c:4165 > > #26 0x7f1621ef35cd in js::jit::MCallGetProperty::name() const > (this=) at ./js/src/jit/shared/Assembler-shared.h:253 > > Unfortunately this is often a result of prior memory corruption, so > it's unlikely to be feasible to debug without knowing how to reproduce it. > > Are there any interesting assertion messages from gnome-shell in the > system log? > This is the log leading up to the crash: -- Logs begin at Sun 2019-03-24 17:30:04 -03, end at Mon 2019-07-22 17:11:13 -04. -- Jul 22 14:50:27 felipedell google-chrome.desktop[2665]: [3160:3160:0722/145027.070494:ERROR:os_exchange_data_provider_aurax11.cc(498)] Not implemented reached in virtual uint32_t ui::OSExchangeDataProviderAuraX11::DispatchEvent(const ui::PlatformEvent &) Jul 22 14:50:27 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-1ms) Jul 22 14:50:42 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce: offset negative (-0ms) Jul 22 14:50:42 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce: offset negative (-7ms) Jul 22 14:50:42 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-20ms) Jul 22 14:50:51 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-0ms) Jul 22 14:51:00 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-3ms) Jul 22 14:51:05 felipedell org.gnome.Shell.desktop[2665]: libinput error: client bug: timer event7 debounce short: offset negative (-6ms) Jul 22 14:56:54 felipedell gnome-shell[2665]: Object St.Button (0x5631b4ff6e30), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs. Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: == Stack trace for context 0x5631b21531f0 == Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #0 5631b563d6b8 i /home/felipe/.local/share/gnome-shell/extensions/hibernate-status@dromi/extension.js:202 (7f15e2e3ac10 @ 353) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #1 7ffcc6b61610 b resource:///org/gnome/gjs/modules/_legacy.js:82 (7f15e3fb0b80 @ 71) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #2 5631b563d5f8 i resource:///org/gnome/shell/ui/extensionSystem.js:83 (7f15e3b54d30 @ 436) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #3 5631b563d578 i resource:///org/gnome/shell/ui/extensionSystem.js:354 (7f15e3b5b8b0 @ 13) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #4 7ffcc6b625b0 b self-hosted:261 (7f15e3fc1dc0 @ 223) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #5 5631b563d4f8 i resource:///org/gnome/shell/ui/extensionSystem.js:353 (7f15e3b5b820 @ 64) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #6 5631b563d478 i resource:///org/gnome/shell/ui/extensionSystem.js:371 (7f15e3b5b940 @ 87) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #7 7ffcc6b63700 b resource:///org/gnome/gjs/modules/signals.js:128 (7f15e3fc18b0 @ 386) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #8 7ffcc6b64330 b resource:///org/gnome/shell/ui/sessionMode.js:206 (7f15e3a40790 @ 254) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #9 7ffcc6b64fb0 b resource:///org/gnome/gjs/modules/_legacy.js:82 (7f15e3fb0b80 @ 71) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #10 5631b563d338 i resource:///org/gnome/shell/ui/sessionMode.js:168 (7f15e3a40550 @ 40) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #11 7ffcc6b65f30 b resource:///org/gnome/gjs/modules/_legacy.js:82 (7f15e3fb0b80 @ 71) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #12 5631b563d290 i resource:///org/gnome/shell/ui/screenShield.js:1279 (7f15e3a284c0 @ 188) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #13 7ffcc6b66eb0 b resource:///org/gnome/gjs/modules/_legacy.js:82 (7f15e3fb0b80 @ 71) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #14 5631b563d1e0 i resource:///org/gnome/shell/ui/screenShield.js:1328 (7f15e3a28550 @ 391) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #15 7ffcc6b67e30 b resource:///org/gnome/gjs/modules/_legacy.js:82 (7f15e3fb0b80 @ 71) Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #16 5631b563d1
Bug#932767: gnome-shell: Segmentation fault in js engine
Package: gnome-shell Version: 3.30.2-9 Severity: important Hi, Today, gnome-shell crashed with the following backtrace. I was not at the computer at the time of the crash. #0 0x7f1622285714 in js::InterpreterFrame::trace(JSTracer*, JS::Value*, unsigned char*) (this=0x5631b2248b10, trc=0x7f1614335f10, sp=0x5631b28bc870, pc=0xdf ) at ./js/src/vm/Stack.cpp:348 #1 0x7f1622287bac in js::LifoAlloc::allocImpl(unsigned long) (n=1, this=0x0) at ./js/src/ds/LifoAlloc.h:527 #2 0x7f1622287bac in js::LifoAlloc::alloc(unsigned long) (n=1, this=0x0) at ./js/src/ds/LifoAlloc.h:593 #3 0x7f1622287bac in js::InterpreterStack::allocateFrame(JSContext*, unsigned long) (size=1, cx=0x7f1614335fd0, this=0x0) at ./js/src/vm/Stack-inl.h:237 #4 0x7f1622287bac in js::InterpreterStack::pushExecuteFrame(JSContext*, JS::Handle, JS::Value const&, JS::Handle, js::AbstractFramePtr) (this=0x0, cx=0x7f1614335fd0, script=..., newTargetValue=..., envChain=..., evalInFrame=...) at ./js/src/vm/Stack.cpp:456 #5 0x7f162221e8a4 in JSScript::partiallyInit(JSContext*, JS::Handle, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) (cx=, script=..., nscopes=338911184, nconsts=, nobjects=, ntrynotes=573078444, nscopenotes=, nyieldoffsets=, nTypeSets=) at ./js/src/vm/JSScript.cpp:2847 #6 0x7f162221eb04 in js::GSNCache::purge() (this=0x0) at ./debian/build/dist/include/js/HashTable.h:92 #7 0x5631afde2100 in () #8 0x7f1624363680 in _IO_2_1_stderr_ () at /lib/x86_64-linux-gnu/libc.so.6 #9 0x5631b2248a00 in () #10 0x5631b6da3100 in () #11 0x27993b5cf4a5d800 in () #12 0x5631b6da3100 in () #13 0x5631b6da3100 in () #14 0x5631b21531f0 in () #15 0x7f1624755d13 in _gjs_profiler_setup_signals () at /lib/libgjs.so.0 #16 0x0041 in () #17 0x5631afde2140 in __bss_start () #18 0x0006 in () #19 0x5631afddee1c in () #20 0x7f162437a730 in () at /lib/x86_64-linux-gnu/libpthread.so.0 #21 0x7f16241de7bb in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #22 0x7f16241c9535 in __GI_abort () at abort.c:79 #23 0x7f1624220508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f162432b28d "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #24 0x7f1624226c1a in malloc_printerr (str=str@entry=0x7f162432943b "free(): invalid pointer") at malloc.c:5341 #25 0x7f162422842c in _int_free (av=, p=, have_lock=) at malloc.c:4165 #26 0x7f1621ef35cd in js::jit::MCallGetProperty::name() const (this=) at ./js/src/jit/shared/Assembler-shared.h:253 #27 0x7f1621ef35cd in js::jit::CodeGenerator::visitCallGetProperty(js::jit::LCallGetProperty*) (this=0x7f15e4008490, lir=0x7f1614336c30) at ./js/src/jit/CodeGenerator.cpp:10412 #28 0x7f1621f6a4d8 in js::detail::BumpChunk::begin() (this=) at ./js/src/ds/LifoAlloc.h:405 #29 0x7f1621f6a4d8 in js::detail::BumpChunk::release() (this=0x0) at ./js/src/ds/LifoAlloc.h:405 #30 0x7f1621f6a4d8 in js::detail::BumpChunk::~BumpChunk() (this=0x0, __in_chrg=) at ./js/src/ds/LifoAlloc.h:326 #31 0x7f1621f6a4d8 in js_delete (p=0x0) at ./debian/build/dist/include/js/Utility.h:541 #32 0x7f1621f6a4d8 in JS::DeletePolicy::operator()(js::detail::BumpChunk const*) (this=0x0, ptr=0x0) at ./debian/build/dist/include/js/Utility.h:643 #33 0x7f1621f6a4d8 in mozilla::UniquePtr >::reset(js::detail::BumpChunk*) (aPtr=0x0, this=0x0) at ./debian/build/dist/include/mozilla/UniquePtr.h:343 --Type for more, q to quit, c to continue without paging--c #34 0x7f1621f6a4d8 in mozilla::UniquePtr >::~UniquePtr() (this=0x0, __in_chrg=) at ./debian/build/dist/include/mozilla/UniquePtr.h:288 #35 0x7f1621f6a4d8 in js::detail::SingleLinkedListElement::~SingleLinkedListElement() (this=0x0, __in_chrg=) at ./js/src/ds/LifoAlloc.h:47 #36 0x7f1621f6a4d8 in js::detail::BumpChunk::~BumpChunk() (this=0x0, __in_chrg=) at ./js/src/ds/LifoAlloc.h:325 #37 0x7f1621f6a4d8 in js_delete (p=0x0) at ./debian/build/dist/include/js/Utility.h:541 #38 0x7f1621f6a4d8 in JS::DeletePolicy::operator()(js::detail::BumpChunk const*) (this=0x0, ptr=0x0) at ./debian/build/dist/include/js/Utility.h:643 #39 0x7f1621f6a4d8 in mozilla::UniquePtr >::reset(js::detail::BumpChunk*) (aPtr=0x0, this=0x7fff) at ./debian/build/dist/include/mozilla/UniquePtr.h:343 #40 0x7f1621f6a4d8 in mozilla::UniquePtr >::~UniquePtr() (this=0x7fff, __in_chrg=) at ./debian/build/dist/include/mozilla/UniquePtr.h:288 #41 0x7f1621f6a4d8 in js::detail::SingleLinkedListElement::~SingleLinkedListElement() (this=0x0, __in_chrg=) at ./js/src/ds/LifoAlloc.h:47 #42 0x7f1621f6a4d8 in js::detail::BumpChunk::~BumpChunk() (this=0x7fff, __in_chrg=) at ./js/src/ds/LifoAlloc.h:325 #43 0x7f1621f6a4d8 in js_delete (p=0x7fff) at ./debian/build/dist/include/js/Utility.h:541 #44
Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"
On Tue, Jun 25, 2019, 17:12 Michael Biebl wrote: > Control: severity -1 important > > Hi Raphael > > On Wed, 19 Jun 2019 22:33:21 +0200 Michael Biebl wrote: > > Hi Raphael, > > > > On Tue, 11 Jun 2019 15:51:14 +0200 Raphael Hertzog > > wrote: > > > Hi, > > > > > > On Wed, 05 Jun 2019, Michael Biebl wrote: > > > > systemd-networkd.service in v241 is locked down more tightly then > v232. > > > > It might be worth a try to comment out the hardening features one by > one > > > > to see if one of them causes your problem. > > > > > > Thanks for the idea! I tried that but it did not help. I found the > issue > > > after a few more tries tweaking the network configuration file. It's > > > simply that the system has IPv6 disabled in the kernel policy while the > > > .network file instructs to configure an IPv6 address. > > > > > > Both are contradictory but they happily lived together up-to-now. > > > I don't know what changed but if we don't improve systemd-networkd > > > to just skip IPv6 configuration when the kernel has a policy disabling > > > IPv6, then we will have plenty of servers broken on upgrades because > > > it's quite common to keep the network configuration file provided by > > > the hoster and just disable IPv6 at the kernel level with sysctl: > > > > > > $ grep ipv6 /etc/sysctl.conf > > > # Disable ipv6 > > > net.ipv6.conf.all.disable_ipv6 = 1 > > > net.ipv6.conf.default.disable_ipv6 = 1 > > > net.ipv6.conf.lo.disable_ipv6 = 1 > > > > Ok, thanks for figuring out the root cause. > > Given that this only happens under very special circumstances and > > networkd not being enabled by default, I'm not entirely sure if this > > issue should qualify as RC. > > Cherry-picking the 6 upstream commits leads to a merge conflict when > > applied on top of v241 and I haven't yet investigated if those can > > easily be resolved. > > TBH, I feel a bit uneasy doing this change so late in the release cycle > > and personally I would downgrade this issue to non-RC and fix this via a > > v243 upload to buster-backports. > > > > If you feel strongly about this though, please feel free ask the release > > team if the change is ok. A tested patch set would be great in this case. > > I haven't heard back from you and my current gut feeling is that this > issue is not RC, so I'm downgrading it to important. > I'm open to be persuaded otherwise though. > > Whether we are going to fix this via a stable point release or > stretch-backports remains to be decided. The latter is easier for me, as > it doesn't mean all the administrative overhead of a stable upload. > Perhaps the problem can be mitigated by a NEWS or release guide update. Honestly, I don't think networkd should keep quiet about ipv6 being disabled when you explicitly set up an ipv6 address. Saludos >
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#879741: next steps / request for help with phpmyadmin for debian buster
On Wed, May 29, 2019 at 10:59 AM Blümel Matthias < matthias.blue...@krumedia.com> wrote: > Here we go: unit-tests are back in debian/rules :D. > > I'm stuggling at the moment with my setup for selenium-tests. This has > nothing to do with package-related suff, the tests on a git-checkout > are also failing. > > As long as I can see, the unit-tests are only testing basic stuff. > There seems to be nothing with twig-templates, shapefiles, 2fa, pdf- > export, … > > Tomorrow is public holiday in Germany, but I already "catched" one of > our trainees for testing the package and it's dependencies starting on > friday. > > @felipe: can you enable the issues-feature on the project? Sorry for the delay, done now. > Are you fine > with the way I mentioned in comment #62 to update to the current > version? If so, who triggers the update? Am I able to push to master > with the "developer"-role? > Yes, the developer role should be sufficient. Should any permission be missing, just tell me. I think the best plan is what you outlined: > Make a new update to 4.8.5 based on master and rebase the work currently laying around in three repositories? I also have some patches I didn't push so I guess they make more sense to apply on top (if still needed). > What do you think is the best way to get the changes into the main project? pushing directly to master? pushing to a new branch? making a PR? I think PRs are best for changes that require input from others. Unfortunately, they are not very good for the upstream/pristine-tar/master trio needed for a new upstream update. So I think upstream updates should go directly to master. I think most teams push directly to master. After all, a revert is not that difficult to do in case a commit was not ok :) -- Saludos, Felipe Sateler
