Bug#1057052: Acknowledgement (amd64 install DVD 1 puts "contrib" component on target's sources.list)
For those wondering, my first message wasn't signed since my email client (Icedove, based on Thunderbird) no longer used Enigmail or the system's gpg-agent. Here is a signed message as proof that I have sent the bug report. OpenPGP_signature Description: OpenPGP digital signature
Bug#1057052: amd64 install DVD 1 puts "contrib" component on target's sources.list
Package: debian-cd
Source: debian-cd
Version: 3.1.17
Severity: important
# How to reproduce?
Do as follows:
1. get the installation DVD 1 from [1];
2. use it to install Debian, optionally selecting a mirror;
3. notice that the target's "/etc/apt/sources.list" has both "security"
and "updates" distributions/repositories for the "contrib" component. If
no mirror was selected, only "security" distribution/repository is enabled.
# How often it is reproduced?
For "security" distribution/repository, it is always reproducible. In
the case of "updates" distribution/repository, it applies only if a
mirror was selected.
# Other information
No test was made for other architectures, download methods (e.g.:
jiglo), or media types/variants (e.g.: CD, netinstall).
These assume that you did `git clone --recursive
"https://salsa.debian.org/images-team/debian-cd.git; && cd "debian-cd" `.
## Commits related to "contrib" component
The following procedure was used to find what implemented "contrib"
component:
1. use `git grep -Ei 'contrib' | sed -E '/(^|\/)(doc|info|man)|\.pot?:/d' `;
2. for each file, do a `git blame`, and look for related lines and
corresponding commits that implemented "contrib" component;
3. checkout the previous from that commit (`git checkout hash~1`);
4. repeat from step 1 until there is no other match for that path;
5. do `git checkout master` and repeat from step 1 until there are no
more paths matching the search for implementations of "contrib" component.
This led to the following possibly problematic commits:
Commit: e83ef58217c4f830ed12ecb314517818417c984d
Date: 1999-11-11T17:10:37+
Note: "contrib" added for the first time.
Commit: 916440cf9a265370facae13776213aefaa8a28d6
Date: 2002-12-07T10:22:40+
Note: makes the usage of "contrib" an opt-out.
## Commits related to popcon/popularity-contest
The following procedure was used to find what added
popcon/popularity-contest:
1. do `git log -p tasks/{,*/}popularity-contest* | less -I '+/contrib'
+GN `, and take the coomit hash of the nearest line from above, to do
so, type “?^commit”, Enter;
2. checkout the previous from that commit (`git checkout hash~1`);
3. repeat from step 1 until there is no other match for contrib on popcon.
This results in the following list of possibly problematic commits:
Commit: 8e74984498ffaff1d64fe125a5d09ca6d521c035
Date: 1999-12-27T23:11:18+
Note: adds popcon/popularity-contest which by default takes the most
used packages, which as of today takes stuff from "main" and "contrib".
# Possible list of affected paths
The possibly related files, across all iterations of the steps from the
procedures described earlier are as follows:
tasks/*/popularity-contest
tasks/popularity-contest*
tasks/README
CONF.sh
tools/apt-selection
tools/create_control
tools/generate_di_list
tools/grab_source_list
tools/make_disc_trees.pl
tools/sort_deps
tools/start_new_disc
tools/which_deb
update-cd
# Possible affected versions
Based on the fact that the commits found date back to 1999, version tag
3.1.17, from 2015, was selected, since it is the oldest one which is
still present in the pool ([2]).
# Rationale and suggestions
All in all, due to the way that which the DVD/CD process is done as of
today, the inclusion of the packages that came from "contrib" also
inserts this repository on the target's "/etc/apt/sources.list" since
the apt-setup source package sees the list of sources.
The reasoning for reporting this is that, according to the Debian Policy
Manual, only the "main" component is part of Debian distribution ([3],
[4]), while "contrib" is not ([5]), so the target's
"/etc/apt/sources.list" should reflect that.
Possible solutions include:
a) make "contrib" an opt-in (instead of the current opt-out), and use
opt-in for the Debian-provided media;
b) move this bug to Debian Policy team so that the "contrib" component
is also considered as part of the Debian distribution;
c) since the only package that is currently fetched is "iucode-tool",
find a way to detect which processors would need "iucode-tool", and ask
for the user themselves to insert an extra media with the firmware, and
only use that during install;
d) remove "contrib" from popcon/popularity-contest.
# References
[1]:
https://get.debian.org/images/release/current/amd64/bt-dvd/debian-11.0.0-amd64-DVD-1.iso.torrent
.
[2]: https://deb.debian.org/debian/pool/main/d/debian-cd/ .
[3]: https://www.debian.org/social_contract#guidelines , search for
“Works that do not meet our free software standards”.
[4]:
https://www.debian.org/doc/debian-policy/ch-archive#the-main-archive-area .
[5]:
https://www.debian.org/doc/debian-policy/ch-archive#the-contrib-archive-area
.
--
* https://libreplanet.org/wiki/User:Adfeno
* Ativista não advogado, nem técnico de informática
* Compre dos vendedores locais
* Use e contribua ao software livre (diferente do gratuito)
* Enviando docs.? Use OpenDocument. Outros tipos: vide endereço anterior
* Use XMPP
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#967275: Bug#967582: libgtkdatabox: depends on deprecated GTK 2
Hi Graham, nice to hear all this! Klavaro is again linking against the library externally, from release 3.12, see: https://sourceforge.net/p/klavaro/news/2021/04/release-312/ Em dom., 2 de jan. de 2022 às 10:11, Graham Inggs escreveu: > Control: tags -1 + pending fixed-in-experimental > Control: block 967275 by -1 > Control: severity 967275 important > Control: block 967831 by -1 > Control: severity 967831 important > > Hi Felipe > > On Sun, 6 Jun 2021 at 23:42, Felipe Castro wrote: > > Hi, I'm the new upstream maintainer of GtkDatabox and we have released > version 1.0.0 this year, which depends now on GTK3, please update it on > Debian. > > The packages which depend on it are klavaro, xoscope and brp-pacu. > > From those, the only upstream which still depends on old gtkdatabox is > brp-pacu, but there is a fork which has done the upgrade to use the new > GTK3 version at GitHub, see: https://github.com/matthew-dews/brp-pacu > > The problem is that they have not released this new version yet, but I > could provide another fork and release, if that is the case. > > Thanks for your work on these packages! > > I've uploaded libtgkdatabox 1.0.0 to experimental. Once it clears NEW > [1], I will prepare uploads of xoscope and brp-pacu which I have > already tested. klavaro seems to be using an embedded copy of > libgtkdatabox. > > Regards > Graham > > > [1] https://ftp-master.debian.org/new.html >
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#995357: pipewire: rtkit-daemon race condition causes realtime scheduling and nice-level failure
Package: pipewire Version: 0.3.37-2 Severity: normal X-Debbugs-Cc: joaodefel...@gmail.com Dear Maintainer, on boot, pipewire.service and pipewire-pulse.service can be started by systemd before rtkit-daemon.service, causing the following errors: systemd[1302]: Started PipeWire PulseAudio. pipewire-pulse[1410]: RTKit error: org.freedesktop.DBus.Error.AccessDenied pipewire-pulse[1410]: could not set nice-level to -11: Permission denied pipewire-pulse[1410]: RTKit error: org.freedesktop.DBus.Error.AccessDenied pipewire-pulse[1410]: could not make thread realtime: Permission denied systemd[1302]: Started Multimedia Service. pipewire[1408]: RTKit error: org.freedesktop.DBus.Error.AccessDenied pipewire[1408]: could not set nice-level to -11: Permission denied pipewire[1408]: RTKit error: org.freedesktop.DBus.Error.AccessDenied pipewire[1408]: could not make thread realtime: Permission denied In my case, rtkit-daemon starts, on average, 80ms after the pipewire processes. Restarting them while making sure rtkit-daemon was running was enough for a temporary solution. Perhaps due to the difference in the number of systemd units, I wasn't able to reproduce the issue on a clean install, but from reading the unit files, it doesn't look like pipewire needs to wait for multi-user.target to complete or for rtkit-daemon.service to be started. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pipewire depends on: ii init-system-helpers 1.60 ii libpipewire-0.3-modules 0.3.37-2 ii pipewire-bin 0.3.37-2 pipewire recommends no packages. pipewire suggests no packages. -- no debconf information
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#969110: gemrb: New upstream release 0.8.7
A new version has just been uploaded! GemRB v0.9.0 (2021-06-18): New features: - basic resolution independence - python3 support - arbitrary window dragging support - improved debug console - subtitle support for BIK videos Improved features: - window management, drawing and input handling - performance: SDL2 video playback, general and text rendering - smoother movement animations, demo - bugfixes Would be really nice to have this updated to unstable at least, considering the next freeze.
Bug#967582: libgtkdatabox: depends on deprecated GTK 2
Hi, I'm the new upstream maintainer of GtkDatabox and we have released version 1.0.0 this year, which depends now on GTK3, please update it on Debian. The packages which depend on it are klavaro, xoscope and brp-pacu. >From those, the only upstream which still depends on old gtkdatabox is brp-pacu, but there is a fork which has done the upgrade to use the new GTK3 version at GitHub, see: https://github.com/matthew-dews/brp-pacu The problem is that they have not released this new version yet, but I could provide another fork and release, if that is the case. Thanks, Felipe Castro
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#970478: ERROR: Renderer process crashed when using qtwebengine backend.
Hi! > As we now have Qt WebEngine 5.15.2 in testing and sid, can we mark this > bug as fixed? As suggested before, I avoided qtwebengine version 5.15.1 first by downgrading to 5.15.0 and then upgrading to 5.15.2 when it did become available. It worked without incidents on my 2 machines, so it was fixed for me.
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#981837: pipewire:amd64: Fails to play audio and video
After asking for some help on #pipewire channel, I could make pipewire work again by creating the following file: $ sudo touch /etc/pipewire/media-session.d/with-pulseaudio and restarting pipewire service. This bug can be closed, but it would be better if there was a changelog (apt-listchanges) mentioning the removal of this file, which is necessary even if I don't have pulseaudio in this system.
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#970478: ERROR: Renderer process crashed when using qtwebengine backend.
Hey,
> For 1), do you see those QtWebEngineProcess crashes when you run
> "coredumpctl list"? If so, can you please show "coredumpctl info PID"
> with the PID from the list? If not, can you check whether you can
> reproduce them (making the entire browser crash) when you run with
> "--qt-flag single-process"?
I have attached coredumpctl info when it crashes using --temp-basedir.
Running with:
$ qutebrowser --qt-flag single-process
[1]5850 illegal hardware instruction (core dumped) qutebrowser
--qt-flag single-process
The browser starts with a blank page and when I try to open any webpage, it
crashes.
I have also attached coredumpctl of this crash.
> For 2), it looks like there's no libqt5webengine5-dbg{,sym} package in
> the debian archives. Could you check if you find them if you run e.g.
> find-dbgsym-packages on /usr/lib/x86_64-linux-gnu/libQt5WebEngine.so.5.14.2
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
After adding deb 'http://deb.debian.org/debian-debug/ unstable-debug main' to
my '/etc/apt/sources.list' and installing
'libfile-slurper-perl' and 'libfile-which-perl', I find some debug symbols
available:
$ find-dbgsym-packages
/usr/lib/x86_64-linux-gnu/libQt5WebEngine.so.5.14.2
I have attached the file 'find-dbgsym-packages.txt'
> (If there are no debug symbols available at all, I wonder if a bug should
> be opened against libqt5webengine5a - Axel/Fritz, if you have an opinion
> on that, I'd like to hear more)
>
> If getting more info via coredumpctl didn't work, but you can reproduce
> with --qt-flag single-process, can you please do something like:
>
>gdb -ex r --args /usr/bin/python3 -m qutebrowser --temp-basedir --qt-flag
> single-process
$ sudo gdb -ex r --args /usr/bin/python3 -m qutebrowser --temp-basedir
--qt-flag single-process
(No debugging symbols found in /usr/bin/python3)
Starting program: /usr/bin/python3 -m qutebrowser --temp-basedir --qt-flag
single-process
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 12318]
[New Thread 0x7fffdd4e2700 (LWP 12329)]
12:12:36 WARNING: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
'/tmp/runtime-root'
[New Thread 0x7fffd075c700 (LWP 12332)]
[New Thread 0x7fffcff5b700 (LWP 12333)]
[New Thread 0x7fffcf75a700 (LWP 12334)]
[New Thread 0x7fffcef59700 (LWP 12335)]
[New Thread 0x7fffce758700 (LWP 12336)]
[New Thread 0x7fffcdf57700 (LWP 12337)]
[New Thread 0x7fffcd756700 (LWP 12338)]
[New Thread 0x7fffccf55700 (LWP 12339)]
[New Thread 0x7fffa700 (LWP 12340)]
[New Thread 0x7fffaf7fe700 (LWP 12341)]
[New Thread 0x7fffaeffd700 (LWP 12342)]
[New Thread 0x7fffae7fc700 (LWP 12343)]
[New Thread 0x7fffadffb700 (LWP 12344)]
[New Thread 0x7fffad7fa700 (LWP 12345)]
[New Thread 0x7fffacff9700 (LWP 12346)]
[New Thread 0x7fff8bfff700 (LWP 12347)]
[Detaching after fork from child process 12348]
[New Thread 0x7fff8b7fe700 (LWP 12349)]
[Thread 0x7fff8b7fe700 (LWP 12349) exited]
[New Thread 0x7fff8b7fe700 (LWP 12350)]
[New Thread 0x7fff8a470700 (LWP 12351)]
[New Thread 0x7fff89c6f700 (LWP 12352)]
[New Thread 0x7fff8946e700 (LWP 12353)]
[New Thread 0x7fff88c6d700 (LWP 12354)]
[New Thread 0x7fff73fff700 (LWP 12355)]
[New Thread 0x7fff737fe700 (LWP 12356)]
[New Thread 0x7fff72ffd700 (LWP 12357)]
[New Thread 0x7fff717e6700 (LWP 12358)]
[New Thread 0x7fff70fe5700 (LWP 12359)]
[New Thread 0x7fff5bfff700 (LWP 12360)]
[New Thread 0x7fff5b7fe700 (LWP 12361)]
[New Thread 0x7fff5affd700 (LWP 12362)]
[Thread 0x7fff5affd700 (LWP 12362) exited]
[New Thread 0x7fff5affd700 (LWP 12363)]
[Thread 0x7fff5affd700 (LWP 12363) exited]
[New Thread 0x7fff5affd700 (LWP 12364)]
[New Thread 0x7fff5a7fc700 (LWP 12365)]
[New Thread 0x7fff59ffb700 (LWP 12366)]
[New Thread 0x7fff597fa700 (LWP 12367)]
[Detaching after fork from child process 12368]
[New Thread 0x7fff727fc700 (LWP 12373)]
[New Thread 0x7fff71ffb700 (LWP 12374)]
[New Thread 0x7fff58a89700 (LWP 12375)]
[New Thread 0x7fff27fff700 (LWP 12376)]
[New Thread 0x7fff277fe700 (LWP 12377)]
[New Thread 0x7fff26ffd700 (LWP 12378)]
[New Thread 0x7fff267fc700 (LWP 12379)]
[New Thread 0x7fff25ffb700 (LWP 12380)]
[New Thread 0x7fff257fa700 (LWP 12381)]
[New Thread 0x7fff24ff9700 (LWP 12382)]
[New Thread 0x7fff07fff700 (LWP 12383)]
[New Thread 0x7ffef700 (LWP 12384)]
[New Thread 0x7fff077fe700 (LWP 12385)]
[New Thread 0x7fff06ffd700 (LWP 12386)]
[New Thread 0x7fff063fc700 (LWP 12387)]
--Type for more, q to quit, c to continue without paging--
Thread 40 "Chrome_InProcRe" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fff58a89700 (LWP 12375)]
0x7fffea1b128f in
blink::CompositedLayerMapping::ComputeBoundsOfOwningLayer(blink::PaintLayer
const*,
blink::IntRect&, blink::IntRect&, blink::PhysicalOffset&, blink::IntPoint&) ()
from
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
(gdb) bt
#0
Bug#970478: ERROR: Renderer process crashed when using qtwebengine backend.
Attachments were missings last time. libaom0-dbgsym libasound2-dbgsym libavcodec58-dbgsym libavformat58-dbgsym libavutil56-dbgsym libblkid1-dbgsym libbluray2-dbgsym libbrotli1-dbgsym libbsd0-dbgsym libbz2-1.0-dbgsym libc6-dbg libcairo-gobject2-dbgsym libcairo2-dbgsym libchromaprint1-dbgsym libcodec2-0.9-dbgsym libcom-err2-dbgsym libdatrie1-dbgsym libdav1d4-dbgsym libdbus-1-3-dbgsym libdouble-conversion3-dbgsym libdrm2-dbgsym libevent-2.1-7-dbgsym libexpat1-dbgsym libffi7-dbgsym libfontconfig1-dbgsym libfreetype6-dbgsym libfribidi0-dbgsym libgcc-s1-dbgsym libgcrypt20-dbgsym libgdk-pixbuf2.0-0-dbgsym libgl1-dbgsym libglib2.0-0-dbgsym libglvnd0-dbgsym libglx0-dbgsym libgme0-dbgsym libgmp10-dbgsym libgnutls30-dbgsym libgomp1-dbgsym libgpg-error0-dbgsym libgraphite2-3-dbgsym libgsm1-dbgsym libharfbuzz0b-dbgsym libhogweed6-dbgsym libicu67-dbgsym libidn2-0-dbgsym libjpeg62-turbo-dbgsym libkeyutils1-dbgsym libkrb5-dbg liblcms2-2-dbgsym liblz4-1-dbgsym liblzma5-dbgsym libmd4c0-dbgsym libmfx1-dbgsym libminizip1-dbgsym libmount1-dbgsym libmp3lame0-dbgsym libmpg123-0-dbgsym libnettle8-dbgsym libnorm1-dbgsym libnspr4-dbgsym libnss3-dbgsym libnuma1-dbgsym libogg-dbg libopenjp2-7-dbgsym libopenmpt0-dbgsym libopus-dbg libp11-kit0-dbgsym libpango-1.0-0-dbgsym libpangocairo-1.0-0-dbgsym libpangoft2-1.0-0-dbgsym libpcre2-16-0-dbgsym libpcre2-8-0-dbgsym libpcre3-dbg libpgm-5.2-0-dbgsym libpixman-1-0-dbgsym libpng16-16-dbgsym libqt5core5a-dbgsym libqt5gui5-dbgsym libqt5network5-dbgsym libqt5positioning5-dbgsym libqt5qml5-dbgsym libqt5qmlmodels5-dbgsym libqt5quick5-dbgsym libqt5test5-dbgsym libqt5webchannel5-dbgsym libqt5webengine5-dbgsym libqt5webenginecore5-dbgsym librabbitmq4-dbgsym libre2-8-dbgsym librsvg2-2-dbgsym libselinux1-dbgsym libshine3-dbgsym libsnappy1v5-dbgsym libsodium23-dbgsym libsoxr0-dbgsym libspeex-dbg libsrt1-gnutls-dbgsym libssh-gcrypt-4-dbgsym libssl1.1-dbgsym libstdc++6-dbgsym libswresample3-dbgsym libsystemd0-dbgsym libtasn1-6-dbgsym libthai0-dbgsym libtheora0-dbgsym libtwolame0-dbgsym libunistring2-dbgsym libuuid1-dbgsym libva-drm2-dbgsym libva-x11-2-dbgsym libva2-dbgsym libvdpau1-dbgsym libvorbis0a-dbgsym libvorbisenc2-dbgsym libvorbisfile3-dbgsym libvpx6-dbgsym libwavpack1-dbgsym libwebp6-dbgsym libwebpdemux2-dbgsym libwebpmux3-dbgsym libx11-6-dbgsym libx264-160-dbgsym libx265-192-dbgsym libxau6-dbg libxcb-render0-dbgsym libxcb-shm0-dbgsym libxcb1-dbgsym libxcomposite1-dbgsym libxdamage1-dbgsym libxdmcp6-dbg libxext6-dbg libxfixes3-dbgsym libxml2-dbgsym libxrender1-dbgsym libxslt1.1-dbgsym libxss1-dbgsym libxvidcore4-dbgsym libzmq5-dbgsym libzstd1-dbgsym libzvbi0-dbgsym ocl-icd-libopencl1-dbgsym zlib1g-dbgsym PID: 5850 (qutebrowser) UID: 1000 (felipe) GID: 1000 (felipe) Signal: 4 (ILL) Timestamp: Mon 2020-09-21 11:41:40 -03 (39s ago) Command Line: /usr/bin/python3 /usr/bin/qutebrowser --qt-flag single-process Executable: /usr/bin/python3.8 Control Group: /user.slice/user-1000.slice/session-1.scope Unit: session-1.scope Slice: user-1000.slice Session: 1 Owner UID: 1000 (felipe) Boot ID: 8a493cc1f411446a9c0bc0e0d42580f6 Machine ID: 70dd67e312f741bc93a178be9523797f Hostname: fx8350 Storage: /var/lib/systemd/coredump/core.qutebrowser.1000.8a493cc1f411446a9c0bc0e0d42580f6.5850.16006993.zst Message: Process 5850 (qutebrowser) of user 1000 dumped core. Stack trace of thread 5894: #0 0x7f4c837b3fe1 raise (libpthread.so.0 + 0x13fe1) #1 0x7f4c837b4140 __restore_rt (libpthread.so.0 + 0x14140) #2 0x7f4c757c928f n/a (libQt5WebEngineCore.so.5 + 0x462928f) #3 0x7f4c757d4054 n/a (libQt5WebEngineCore.so.5 + 0x4634054) #4 0x7f4c757d6561 n/a (libQt5WebEngineCore.so.5 + 0x4636561) #5 0x7f4c757d64ca n/a (libQt5WebEngineCore.so.5 + 0x46364ca) #6 0x7f4c757d64ca n/a (libQt5WebEngineCore.so.5 + 0x46364ca) #7 0x7f4c757d64ca n/a (libQt5WebEngineCore.so.5 + 0x46364ca) #8 0x7f4c757d64ca n/a (libQt5WebEngineCore.so.5 + 0x46364ca) #9 0x7f4c757d66bd n/a (libQt5WebEngineCore.so.5 + 0x46366bd) #10 0x7f4c757d6b3d n/a (libQt5WebEngineCore.so.5 + 0x4636b3d) #11 0x7f4c757d80d0 n/a (libQt5WebEngineCore.so.5 + 0x46380d0) #12 0x7f4c757d8409 n/a (libQt5WebEngineCore.so.5 + 0x4638409) #13 0x7f4c751d9377 n/a (libQt5WebEngineCore.so.5 + 0x4039377) #14 0x7f4c751e39d9 n/a (libQt5WebEngineCore.so.5 + 0x40439d9) #15 0x7f4c751e3e14 n/a (libQt5WebEngineCore.so.5 + 0x4043e14) #16 0x7f4c75771564 n/a (libQt5WebEngineCore.so.5 + 0x45d1564) #17 0x7f4c7512f16c n/a (libQt5WebEngineCore.so.5
Bug#970478: ERROR: Renderer process crashed when using qtwebengine backend.
Hey, Florian! On 9/21/20 7:57 AM, Florian Bruhin wrote: > Hey, > > Upstream maintainer here - not sure what's going on exactly, but let's > try to find out :) That's awesome, thank you. > On Wed, Sep 16, 2020 at 09:12:19PM -0300, zeden wrote: >> Trying to open sites using qtwebengine backend results in: >> "ERROR: Renderer process crashed". > > I assume you're seeing this on any webpage you open? Yes. It happens on any webpage. > If you start qutebrowser in a terminal and with --temp-basedir, does it > happen as well? If so, do you see anything interesting in the output > there? Starting from terminal with: $ qutebrowser --temp-basedir 09:53:21 ERROR: Renderer process crashed When I quit with, the console shows: [4324:4350:0921/095326.040068:ERROR:database.cc(1598)] Cookie sqlite error 1032, errno 0: attempt to write a readonly database, sql: INSERT INTO cookies (creation_utc, host_key, name, value, encrypted_value, path, expires_utc, is_secure, is_httponly, samesite, last_access_utc, has_expires, is_persistent, priority) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?) [4324:4350:0921/095326.0400 And dmesg shows this line for each time i refresh or try to open any website: traps: QtWebEngineProc[4369] trap invalid opcode ip:7f322fa7128f sp:7ffd1d00c600 error:0 in libQt5WebEngineCore.so.5.14.2[7f322bd14000+5a63000] Thank you in advance!
Bug#964810: gimp: Unable to start gimp in debian unstable
On 7/29/20 5:07 AM, Simon McVittie wrote: > Control: reassign -1 libllvm10,libllvm9,libllvm7 > Control: forcemerge 852746 -1 > Control: affects 852746 + gimp > > On Thu, 16 Jul 2020 at 12:26:26 -0300, zeden wrote: >> $ gimp >> : CommandLine Error: Option 'polly' registered more than once! >> LLVM ERROR: inconsistency in registered CommandLine options > > On Wed, 29 Jul 2020 at 00:55:02 -0300, felipe wrote: >> After investigating further, I found the problematic package to be >> mesa-opencl-icd. >> >> After removing the package above, gimp works again. > > This looks like the same issue as #852746. The workaround appears to be > to avoid installing more than one OpenCL implementation at the same time: > > - If you have an AMD GPU, install mesa-opencl-icd > - If you have an NVIDIA GPU and are using the proprietary driver, > install nvidia-opencl-icd or one of the nvidia-*-opencl-icd packages > - If you have an Intel integrated GPU, install beignet-opencl-icd or > intel-opencl-icd I use and AMD polaris card with amdgpu and mesa drivers. Previously I only had mesa-opencl-icd and ocl-icd-libopencl1 which is pulled by mesa-opencl-icd. Trying to remove ocl-icd-libopencl1 prompts me to install nvidia-opencl packages. It seems bug #954849 has a pretty similar bug, but found the problem while using libreoffice's opencl implementation.
Bug#964810: gimp: Unable to start gimp in debian unstable
After investigating further, I found the problematic package to be mesa-opencl-icd. After removing the package above, gimp works again.
Bug#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#963548: Apparently resolved in 83.0.4103.106-2
On Wed, 1 Jul 2020 18:09:10 -0400 Felipe Sologuren wrote: > Hello, >Today I had 81.0.4044.92-1 installed, update ffmpeg: amd64 (7: 4.2.2-1 + > b1, 7: 4.3-2) and the error appeared. >After updating Chrome to 83.0.4103.106-2, the problem disappeared. > Thank you. Hello, Sorry, chromium 83.0.4103.106-2 is still crashing. Much less frequently, but the browser exits completely. Attached an extract from .xsession-errors. I can't complete backtrace right now. Thank you. Received signal 11 SEGV_MAPERR 7f01a8a79cc7 #0 0x55be3e2c0c69 (/usr/lib/chromium/chromium+0x52b3c68) #1 0x55be3e21fef3 (/usr/lib/chromium/chromium+0x5212ef2) #2 0x55be3e2c07f1 (/usr/lib/chromium/chromium+0x52b37f0) #3 0x7f06d48c9110 (/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f) #4 0x7f06cf9b3d3c (/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b) #5 0x7f06cf9b5f33 (/lib/x86_64-linux-gnu/libc-2.30.so+0x87f32) #6 0x7f06cf9b7bf9 __libc_malloc #7 0x55be3e2d89be operator new() #8 0x7f06cfc3ea2c std::__cxx11::basic_string<>::reserve() #9 0x7f06cfc34498 std::__cxx11::basic_stringbuf<>::overflow() #10 0x7f06cfc3d04a std::basic_streambuf<>::xsputn() #11 0x7f06cfc2f714 std::__ostream_insert<>() #12 0x55be3e2c0d39 (/usr/lib/chromium/chromium+0x52b3d38) #13 0x55be3e2c1054 (/usr/lib/chromium/chromium+0x52b4053) #14 0x55be3e232412 (/usr/lib/chromium/chromium+0x5225411) #15 0x55be3e234548 (/usr/lib/chromium/chromium+0x5227547) #16 0x55be3c97a12a (/usr/lib/chromium/chromium+0x396d129) #17 0x55be3c97a17e (/usr/lib/chromium/chromium+0x396d17d) #18 0x55be3bfcf387 (/usr/lib/chromium/chromium+0x2fc2386) #19 0x55be3c9333d9 (/usr/lib/chromium/chromium+0x39263d8) #20 0x55be3c93361e (/usr/lib/chromium/chromium+0x392661d) #21 0x55be3c97d967 (/usr/lib/chromium/chromium+0x3970966) #22 0x55be3c9a94c7 (/usr/lib/chromium/chromium+0x399c4c6) #23 0x55be3c9a977e (/usr/lib/chromium/chromium+0x399c77d) #24 0x55be3c97a13f (/usr/lib/chromium/chromium+0x396d13e) #25 0x55be3c97a17e (/usr/lib/chromium/chromium+0x396d17d) #26 0x55be3bfcf387 (/usr/lib/chromium/chromium+0x2fc2386) #27 0x55be3c2927a3 (/usr/lib/chromium/chromium+0x32857a2) #28 0x55be3c6010bc (/usr/lib/chromium/chromium+0x35f40bb) #29 0x55be3e3f245f (/usr/lib/chromium/chromium+0x53e545e) #30 0x55be3e3f8a24 (/usr/lib/chromium/chromium+0x53eba23) #31 0x55be3e3f6b62 (/usr/lib/chromium/chromium+0x53e9b61) #32 0x55be3e3f582d (/usr/lib/chromium/chromium+0x53e882c) #33 0x55be3e3ee213 (/usr/lib/chromium/chromium+0x53e1212) #34 0x55be3e409abb (/usr/lib/chromium/chromium+0x53fcaba) #35 0x55be3e409de0 (/usr/lib/chromium/chromium+0x53fcddf) #36 0x55be3e409370 (/usr/lib/chromium/chromium+0x53fc36f) #37 0x55be3c27bc46 (/usr/lib/chromium/chromium+0x326ec45) #38 0x55be3c27b76c (/usr/lib/chromium/chromium+0x326e76b) #39 0x55be3c277eed (/usr/lib/chromium/chromium+0x326aeec) #40 0x55be3c26e74b (/usr/lib/chromium/chromium+0x326174a) #41 0x55be3c261044 (/usr/lib/chromium/chromium+0x3254043) #42 0x55be3c260d75 (/usr/lib/chromium/chromium+0x3253d74) #43 0x55be3c27f426 (/usr/lib/chromium/chromium+0x3272425) #44 0x55be3e2de0e0 (/usr/lib/chromium/chromium+0x52d10df) #45 0x7f06d367eb0f (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7.0.0+0x23b0e) #46 0x7f06d367f24f event_base_loop #47 0x55be3e2de38e (/usr/lib/chromium/chromium+0x52d138d) #48 0x55be3e27e5d5 (/usr/lib/chromium/chromium+0x52715d4) #49 0x55be3e256670 (/usr/lib/chromium/chromium+0x524966f) #50 0x55be3c59c3b3 (/usr/lib/chromium/chromium+0x358f3b2) #51 0x55be3e2942a9 (/usr/lib/chromium/chromium+0x52872a8) #52 0x55be3e2d0c9e (/usr/lib/chromium/chromium+0x52c3c9d) #53 0x7f06d48bdf27 start_thread #54 0x7f06cfa2b31f clone r8: 0077 r9: 0050 r10: 0006 r11: 007c r12: 7f06a820 r13: 7f06a830 r14: 7f06a8622420 r15: 0080 di: 0021 si: 0004 bp: 0020 bx: 7f01a8a79cbf dx: 7f06a880 ax: 7f06a8b18700 cx: 7f01a8a79cbf sp: 7f06c525d440 ip: 7f06cf9b3d3c efl: 00010202 cgf: 002b0033 erf: 0004 trp: 000e msk: cr2: 7f01a8a79cc7 [end of stack trace] Calling _exit(1). Core file will not be generated.
Bug#963548: Apparently resolved in 83.0.4103.106-2
Hello, Today I had 81.0.4044.92-1 installed, update ffmpeg: amd64 (7: 4.2.2-1 + b1, 7: 4.3-2) and the error appeared. After updating Chrome to 83.0.4103.106-2, the problem disappeared. Thank you.
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#956849: retroarch does nothing when statrted from console
Package: retroarch Version: 1.7.3+dfsg1-1 Severity: important Dear Maintainer, running retroarch from text console does nothing, retroarch just stop without saying/complaining nothing. Works fine under X -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8), LANGUAGE=es (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages retroarch depends on: ii fonts-dejavu-core 2.37-1 ii libasound21.1.8-1 ii libavcodec58 10:4.1.5-dmo1+deb10u1 ii libavformat58 10:4.1.5-dmo1+deb10u1 ii libavutil56 10:4.1.5-dmo1+deb10u1 ii libc6 2.28-10 ii libdrm2 2.4.97-1 ii libegl1 1.1.0-1 ii libfreetype6 2.9.1-3+deb10u1 ii libgbm1 18.3.6-2+deb10u1 ii libgcc1 1:8.3.0-6 ii libgl11.1.0-1 ii libjack-jackd2-0 [libjack-0.125] 1.9.12~dfsg-2 ii libminiupnpc172.1-1+b1 ii libopenal11:1.19.1-1 ii libpulse0 12.2-4+deb10u1 ii libqt5core5a 5.11.3+dfsg1-1+deb10u3 ii libqt5gui55.11.3+dfsg1-1+deb10u3 ii libqt5widgets55.11.3+dfsg1-1+deb10u3 ii libretro-core-info1.3.6+git20160816-1 ii libsdl2-2.0-0 2.0.9+dfsg1-1 ii libstdc++68.3.0-6 ii libswresample310:4.1.5-dmo1+deb10u1 ii libswscale5 10:4.1.5-dmo1+deb10u1 ii libudev1 241-7~deb10u3 ii libusb-1.0-0 2:1.0.22-2 ii libv4l-0 1.16.3-3 ii libwayland-client01.16.0-1 ii libwayland-cursor01.16.0-1 ii libwayland-egl1 1.16.0-1 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-2 ii libxext6 2:1.3.3-1+b2 ii libxinerama1 2:1.1.4-2 ii libxkbcommon0 0.8.2-1 ii libxv12:1.0.11-1 ii libxxf86vm1 1:1.1.4-1+b2 ii retroarch-assets 1.3.6+git20160731+dfsg1-2 ii zlib1g1:1.2.11.dfsg-1 retroarch recommends no packages. retroarch suggests no packages. -- no debconf information
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#949674: firefox: Firefox 72.0.2-1 crash on launch.
After trying to check what else updated and searching around, it seems this bug is related to sqlite3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949644 After downgrading to libsqlite3-0_3.30.1-1, firefox starts again.
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#895874: git-send-email does require Mail::Address
The git-send-email.perl file does have use Git::LoadCPAN::Mail::Address and since you do NO_PERL_CPAN_FALLBACKS trying to use it throws the following error explaining that the system is broken: > BUG: The 'Mail::Address' module is not here, but NO_PERL_CPAN_FALLBACKS was > set! > > Git needs this Perl module from the CPAN, and will by default ship > with a copy of it. This Git was built with NO_PERL_CPAN_FALLBACKS, > meaning that whoever built it promised to provide this module. > > You're seeing this error because they broke that promise, and we can't > load our fallback version, since we were asked not to install it. > > If you're seeing this error and didn't package Git yourself the > package you're using is broken, or your system is broken. This error > won't appear if Git is built without NO_PERL_CPAN_FALLBACKS (instead > we'll use our fallback version of the module). at > /usr/share/perl5/Git/LoadCPAN.pm line 76. > BEGIN failed--compilation aborted at > /usr/share/perl5/Git/LoadCPAN/Mail/Address.pm line 8. > Compilation failed in require at /usr/lib/git-core/git-send-email line 37. > BEGIN failed--compilation aborted at /usr/lib/git-core/git-send-email line 37. > diff: actual: No such file or directory -- Felipe Contreras
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#922658: linux-image-4.19.0-0.bpo.2-amd64: NETDEV WATCHDOG: enp1s0f1 (r8169): transmit queue 0 timed out
is this bugreport still open? Because I no longer have this laptop, therefore can no longer give a status. Sorry. Please close it. (unless you got a reason to no doing so)
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
