Bug#1079532: haproxy FTCBFS: multiple reasons
Hello Helmut, I am running into this issue when trying to crossbuild with cowbuilder: The following packages have unmet dependencies: builddeps:/build/haproxy_3.0.5-2.dsc:arm64 : Depends: python3-sphinx:amd64 Depends: python3:arm64 but it is not going to be installed Depends: python3-mako:arm64 but it is not installable I am only adding --git-pbuilder-options="--host-arch arm64" to "gbp buildpackage". Isn't there something to do also for Build-Depends-Indep? I wonder why python3-sphinx is not build-depends-indep. I'll investigate that. On 2024-08-24 11:28, Helmut Grohne wrote: Source: haproxy Version: 2.9.9-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability ftcbfs haproxy cannot be cross built from source for multiple reasons. The immediate issue is the python3-sphinx dependency. That package is affected by the multiarch interpreter problem and hence must not be annotated Multi-Arch: foreign. As a result, the dependency is technically unsatisfiable. Whilst it can be used in architecture-dependent ways, that's not the common case and we are commonly annotating it :native. That's also applicable here as it is used for manual page generation. If the manual page were not included in an Arch:any package the preferred solution were to move it to Build-Depends-Indep. Then debian/rules does not pass any cross tools to make. While normally, I'd recommend using dh_auto_build, the install target also uses CC and dh_auto_install does not pass cross tools. So here, I recommend passing them explicitly instead. Last but not least, the upstream build system hard codes the build architecture pkg-config in a few spots. It is recommended for Makefile build systems to always refer to it via the PKG_CONFIG variable to allow passing a different one for cross building. All of these issues are fixed in the attached patch and it makes haproxy cross buildable. Please consider applying it and forwarding the upstream parts. Helmut
Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding
I have temporarily pushed Helge's patch until this is solved upstream. On 2024-09-11 17:01, Bo YU wrote: Hi, Sorry for jumping into this topic. Is there anything I can do to push for updates to this package? Becasue the package blocked debci team to create riscv64/testing chroot on our riscv64 workers due to this FTBFS on mips64el lead to fail to migrate. On Mon, Aug 12, 2024 at 10:33:28AM +0200, Aurelien Jarno wrote: Hi, ... But for upstream, it just hides the real bug. On those architectures, the NaN encoding is indeed different, but the resulted encoded data should be the identical, as defined in the RFC. Therefore I believe the real fix is to convert NaNs (and probably also infinities) during the encoding process. My initial thoughts is to report this to upstream and then we can disable/skip NaNs related test on Debian side. But I am not sure if this is appropriate so let me make sure first here. BR, Bo
Bug#1072970: RM: graphite-api -- ROM; FTBFS, dead
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: graphite-...@packages.debian.org Control: affects -1 + src:graphite-api User: ftp.debian@packages.debian.org Usertags: remove -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 No commit on upstream since 7 years. -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmZn804SHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5tBAQAJ4zysFWk9zrvYLird5s9+Bug7yo5tQU Y5LS8Kbd0jNS4W+ggEDESLFDhz7JL+krrEga1hqQklopo7pw1ZWytSWH0Hk6RDhW xCQ+Teo1DqoLXqA2XpMxrkws1C98pRbq9yWENz9+rWQwFU2MhEXgz0DUONWl5KQZ jfcJ/pgK//KxAN4rAla6cnAlFPo7qNCjDLLhky+ynL4IbxKM3YuiQJ0pBO4sgJu7 DOaxTFAqiUBMjjX3ntP4qbuCiL2RiHe89GQ30OhEa8DclcyAmgX7LJoBELb+T1a3 fW4m/fDTPyR+A9Y6V0iT/OJlhrrCfC9RWwlRkt6fV4Id23xUsapeUYEMDhG0K3zf pGwAHTdtG+rCEHDbUYEL16GSM0u1HiW5p4jFwqbrrJ3o5JQzAsRu+XjCM5zLkSzp VxCZQy19RldEt0YfRELTo7JfVmtKqpnwRH+8m3dRNJri5fBEOKVsO3D00CwIunYt g8pPE5Vfj6OIsAp1Z7hroydJOCxlXTzw3WU/DLqR8X2QleLGfDUH6eCiKQzCgX4l qMLpQStgJpVh0mnvGzIrNJnqfuWwdt4CWNkxQ3zjB1op/klP2ddys/UHvf9D+Jlm 3tdbqSS9VLHik9aMp5cOOnctDC1xXz2nokgSCcKYzqVpf51arHLxUxD4QJam+KWx zNe+aXvlaLBR =WFyf -END PGP SIGNATURE-
Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding
Hello Helge, Couldn't the patch be pushed upstream? And maybe there should be an else branch with the encoding of the other NaN? On 2024-04-27 17:35, Helge Deller wrote: Source: libcbor Version: 0.10.2-1.2 Tags: ftbfs X-Debbugs-Cc: del...@debian.org libcbor fails to build from source on the hppa and mips architectures. Reason is, that a testcases which checks the binary representation of NaN fails on those architectures, because they use a different binary encoding of the bytes. See the "encoding" section at https://en.wikipedia.org/wiki/NaN for details. Failure except: 20: [ RUN ] test_float 20: [ ERROR ] --- difference at offset 2 0xffbf 0xffc0 20: difference at offset 3 0x 0x00 20: difference at offset 4 0x 0x00 20: 3 bytes of 0x1739c and 0xfa001b57 differ 20: [ LINE ] --- ./test/float_ctrl_encoders_test.c:150: error: Failure! 20: [ FAILED ] test_float 20: [ RUN ] test_double 20: [ ERROR ] --- difference at offset 2 0xfff7 0xfff8 20: difference at offset 3 0x 0x00 20: difference at offset 4 0x 0x00 20: difference at offset 5 0x 0x00 20: difference at offset 6 0x 0x00 20: difference at offset 7 0x 0x00 20: difference at offset 8 0x 0x00 20: 7 bytes of 0x1739c and 0xfa001b63 differ 20: [ LINE ] --- ./test/float_ctrl_encoders_test.c:177: error: Failure! The attached patch avoids this test on hppa and thus building libcbor succeeds. I did not test the patch on mips yet. Helge
Bug#1065690: lldpd: Does not pick correct IP or hostname
The IP address is a global information of the system (so, the same IP address is advertised for all interfaces). The hostname is the result of "getent host $(uname -n)". On 2024-03-09 00:12, Witold Baryluk wrote: Package: lldpd Version: 1.0.18-1 Severity: normal X-Debbugs-Cc: witold.bary...@gmail.com It sends correct IPv6, but IPv4 and hostname are wrong. user@debian:~$ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp7s0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 10:00:00:0d:b0:00 brd ff:ff:ff:ff:ff:ff 3: enp8s0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 10:00:00:00:b0:00 brd ff:ff:ff:ff:ff:ff 8: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:00:00:00:00:90 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever 23: enp10s0f0np0: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 64:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff 24: enp10s0f1np1: mtu 9000 qdisc fq_pie state UP group default qlen 1000 link/ether 64:00:00:00:00:02 brd ff:ff:ff:ff:ff:ff inet 10.0.0.18/24 brd 10.0.0.255 scope global dynamic noprefixroute enp10s0f1np1 valid_lft 85650sec preferred_lft 85650sec inet6 fe80::0002/64 scope link noprefixroute valid_lft forever preferred_lft forever What I see on the switch (MikroTik RouterOS 7.15beta6, on hw model CRS504-4XQ-IN) connected to directly to enp10s0f1np1: Interface qsfp28-4-1# correct IP Address 172.17.0.1# incorrect IPv6 Addressfe80::0002# correct MAC Address 64:00:00:00:00:02 # correct Identitylocalhost # incorrect Platform Version Board Name Interface Name enp10s0f1np1 # incorrect Regards, Witold
Bug#1065370: RM: pyiosxr -- ROM; dead upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pyio...@packages.debian.org Control: affects -1 + src:pyiosxr User: ftp.debian@packages.debian.org Usertags: remove -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmXkhSwSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5ZQkP/AgLRJdg/Q+HCzTHWB0itqjTBXUUKOMl lU/09LdZp5HUN2bVmhk5UuEXsGtmdN6F5a8V/yt0R17ItqmtwiVMNQwlaKyXrd9M H4AWHo5d00BEi7F4Msc9+Qwphm/tZrbejPPL/fNA/MaW+/Z8BcqgRTYEYBRD7lig ecEl9QyLVqURFK9xB2S6qg+Q8XUhL72vJLT7buI6HTa5bFYqqnHCqDLtGZn8N6jD wmr4Bhh4W3eIJoGU372F8jTnQ8uSrKB/WvH2fTnv5ou8bZxira+P4TDHsAzGGpdU T4DLw7mkhWtOlTunwIgpUb6OyQuSmbF6mTvwDt13e/lKeGymhxEFE7PuTXZt3FSx wqeMmS4uZlFSPoqQEn3yz/RDzvt2SLP9n1yX7CUXmr9j0dY0Es9Ve6QLkTjyV4CJ /8pJXFYWEWggzFh6EnPlQqvTQQ8VucdmBJKdqsb9DjMOTzZoFs6o0n/xJMq+90Ej zvZTz8ruK2w1NWUPdcSNGA9sUnauV2J+NpWSO714bZNvyoek4G0sO3txuBeL2jao MkxGh8RxVrE+w/RDEJvcQdn5Fm8z7N2n9s8lFWS4tG8BeK1fu5tzN/n0WfA06MAn 0EKYg2AbQSmIcgqXatQaqeaZfBRv0sfunPduKDnNzbfeWdx2uXVC4s0C1o+jdryG PJoNZdc4KjNm =10TI -END PGP SIGNATURE-
Bug#929830: lldpd: Memory usage of lldpd implies memory leak
This is only for FDP/EDP (rare protocols). But a similar problem was fixed in earlier releases. So, maybe. On 2024-01-15 10:56, Gürkan Myczko wrote: Maybe the memory leak(s) are fixed with 1.0.18? https://github.com/lldpd/lldpd/releases
Bug#1058794: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
On 2024-01-04 00:30, Alexandre Detiste wrote: @Vincent: this one package "gtextfsm" is yours do you green light an upload ? Yes.
Bug#1040988: fixed in picom 10.2-2
On Tue, 26 Dec 2023 16:19:12 + Debian FTP Masters wrote: * Fix infinite loop with GNOME (Closes: #1040988) Upstream also added: https://github.com/yshui/picom/commit/7366553be2b825495c5b1e09be09d0fabde4b9b4 Otherwise, picom won't start at the beginning of a session (no windows yet).
Bug#1053736: amdgpu firmware are not looked up in all possible paths
Source: linux Version: 6.5.6-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, When amdgpu firmware are in /lib/firmware/updates, they are not detected by the "amdgpu-firmware-required" patch, preventing the module to load while the correct firmwares are present. https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/bugfix/all/radeon-amdgpu-firmware-is-required-for-drm-and-kms-on-r600-onward.patch Also, maybe the situation in 2013 is not the same in 2023 and we should just drop the patch? - -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmUkcSYSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5b1EQAJvTSc0ZV3duNoF/rjNbkfWJOcbu63Fu tmSYaWHzuCAgoXUZIFt+6BZTRbVMGFMFeNHhuR/qd8cq6Rh/qdH5AiICR5aV3Xts c/TYVbrJNsj0fpsO7+sbaDMzvnJ7Ccu6qWbDfo/YLkNzU7AAHJS8M8pkepAwY830 najSkl3NeQPADp268V42HfpF+O8okTxuHXUpbzYlYODSw+kj7MCCJUvSPb5NtQOg EyF32bOQZ86TtM99atbMdywGKwGN5q8qbiuJmQJuKsF0I7CaYDYewfOkpnAaps4n 3SFhiEBDu1Xhvif89umt6K/AU9Qp6Fz2wXycEmDgUArIuDc9Y2hddNneKXe93tE4 kN0OeyyEWebmwwWJlGBIios7EYugA6p7n9yNkS3fL5YaRkPm3GAWEruU9bLrLVVZ xXfq7PqzBxSl1lzkZwi6fN85LZ2HOwcHDKP9yFiQG+bXse0/4VRhXePgTlXY+DXV Pi/apu1kGMlOOOhs4uniH+3EHGwvHNOofPoCd2WG0aQ/c+VHlqD/0Bc5/bg7inX9 oicyKKhLZvvURp1wgQrEpqUuPopecDgNkyY16iyi2cpMrIFM6HchRUIyBnto1Nay IyBL5XgxEnfj8ZcIKiQf8Yx9CfXUluJghWCqpKG5LQpkEWB/pCLZrnctM5ywDXF5 Tzoiu8OLqeXH =6yHp -END PGP SIGNATURE-
Bug#1052613: Keepalived occasionally fails SSL_CHECK
Hello Pavel, I'll be more comfortable if you submitted this patch upstream first. On 2023-09-25 12:48, Pavel Matěja wrote: Package: keepalived Version: 1:2.2.7-1 I'm upgrading our servers from Bullseye to Bookworm. Some of them act as load balancers using keepalived. Right now I have one Bullseye and one Bookworm with the same configuration checking the same services. Several of our services are running on HTTPS therefore I'm using SSL_CHECK. I can see that the Bookworm one occasionally fails SSL_CHECK for several seconds on one service while the Bullseye does not report any problem at all. It's quite rare - not even once per hour with 2s loop delay. I was looking for possible reason and I've found https://github.com/openssl/openssl/issues/20365 https://github.com/pjsip/pjproject/issues/3632 https://stackoverflow.com/questions/18179128/how-to-manage-the-error-queue-in-openssl-ssl-get-error-and-err-get-error They are all basically saying that you can have multiple SSL errors left in error queue and you are supposed to run|ERR_get_error() before calling |SSL_* functions. I've tried to patch keepalived sources (see attachment) and the problem seems to disappear. I have no idea why is Bullseye package unaffected. It might be related to different OpenSSL version. What do you think about this? -- Pavel Matěja
Bug#1037185: bpftrace: Fix FTBFS on armhf
On 2023-06-07 12:07, Danilo Egea Gondolfo wrote: * What led up to the situation? The build is failing on armhf because cmake is not detecting the architecture correctly as we cross compile on arm64. Also, after fixing the cmake part, the build will fail in src/triggers.h due to the attribute used when it build on arm 32-bit. It might be a bug on gcc but I'm not sure (clang++ doesn't throw the same error). Shouldn't all this be fixed upstream?
Bug#1031912: Package cirrus/ directory
Source: firmware-nonfree Version: 20230210-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! The Cirrus Logic CS35L41 is a DSP with firmwares shipped upstream in the cirrus/ directory. It would be nice to build a package for that (firmware-cirrus?). Thanks! - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmP5ySASHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5hDYP/0+bw+0ar+FW4QdtfObxjhSr6IAS10DR avdy4linMxK8rdmn3PV44F4sC5A1TnfCILthLtLgM8urraJj9CD0kNR+WHL2hxI7 qrmSXYoBIFlMtP6rR4ICupzM1HAU2Gb4XCTVJz5CFt/w0JBGXXkKfeQA8b0HRWDy LiSbS9qWY+kJpmvSbzIJzChz5N64TJziRNPhDsy8vHAzMXBkcc5G4oyU2jdoAyuk VfXgHFyJ2kZYiv1/dvvzGy3bXYK9pv+Q/oYq86Ty9LPwudI5xBVMiEAwOKq126HX 1ZtGvEDXV1JgRKap1+9Rhyvkf1j5F4ANGfnr/GmOL94uhdpDOh0Hrdasgw6/klBt HiwBXzFQkZjXE5RhKeAjXMiCSkpbvPY5o8aJZTfqMjhV17qUN2yw7lGfVfl4rDOG 2xdK+c+/UHfgprAcPCXUCCZ1GROYXXh36KJlX2v5UNGKm37rXKvxmcbBsWj5SPIc UCy1zOUdKvKig01WrGkS5tAVK8jKWMOPGidD+DMVN0LcbdemPkG3LTYbXZDg4qSy leKJ+wOlrHhX03thPl3q3KzU0Ufpr8FGPQwcM2Ku3g0u+fKYwoPjNXPrl5znGEnf IYHUBNS/muIfPS3e6vFqMma8VWpj9PaqZGR60iEOygMavDwDDMG92oScD3bPq6wu sbPxjVIqIU4S =iiuL -END PGP SIGNATURE-
Bug#1029992: xtl: new upstream version 0.7.5 available
On 2023-01-30 00:31, Drew Parsons wrote: Source: xtl Version: 0.7.2-2.1 Severity: normal xtl 0.7.5 has just been released. The latest version of xtensor needs it (uses xtl/xcompare.hpp), and we need the latest version of xtensor in order to support the latest version of xsimd. The latest release of xsimd fixes some issues which makes pythran more stable and more effective. scipy uses pythran to accelerate computations. tl;dr: Would it be possible to upload the new version of xtl to experimental so we can test it alongside xsimd 10.0.0 ? Hello Drew, Done.
Bug#1030173: Document breaking changes in NEWS.Debian
On 2023-01-31 23:09, Lee Garrett wrote: I've written a NEWS file for you: Thanks, it will be part of the next upload.
Bug#1030173: Document breaking changes in NEWS.Debian
On 2023-01-31 21:44, Lee Garrett wrote: with release 2.6 haproxy has dropped the "ssl-engine" keyword by default. Would be nice to document that in NEWS.Debian so it gets shown by tools such as apt-listchanges during upgrade from bullseye to bookworm. In my case haproxy failed to start with my bullseye config since it still had the "ssl-engine" keyword in it. I understand this would be useful, but it opens me to get bugs like "NEWS.Debian says something about ssl-engine, but not about some other change". I would need to make a summary of upstream's CHANGELOG file. This seems a tedious task.
Bug#1027382: Please, minimize your build chroots
On 2023-01-28 13:59, Adrian Bunk wrote: I am not saying that trying to force maintainers to spend time on such issues by making them release critical is better, but you are also creating extra work and frustration for the people who are doing QA work in Debian. It also pushes some maintainers to give up on packages. I gave up on maintaining any Go package after the whole "everything should compile with only one CPU because policy says so" fiasco. The most rare resource we have is volunteer time. Creating artificial problems is not helping.
Bug#1027382: Please, minimize your build chroots
On 2023-01-28 00:20, Santiago Vila wrote: Release Policy exists as a canonical list of what should be RC and > what not, and it's intended to avoid stupid discussions like this one. Extending build-essential is easier than asking many people to do pointless work to satisfy a set of non-existing users. It is not like we had several reports of people complaining they can't build a package because they are in an environment without tzdata. It is not OK to create problems to force many volunteers to do extra work.
Bug#958895: libevhtp-dev: libtool arguments failure
On 2023-01-27 08:48, Alexandre Rossi wrote: Now that the blocking bug is fixed, I thing the patch should be uploaded to unstable. Do you want me to prepare a build for you to upload? Yes, please do. An updated package is available on mentors. https://mentors.debian.net/package/libevhtp/ Thanks, it's uploaded!
Bug#1021502: lintian: incorrectly complains about debian-news-entry-has-unknown-version
On Tue, 11 Oct 2022 20:11:07 +0200 Axel Beckert wrote: > > Please investigate and fix this bug in lintian. I see no possibility how to do that in Lintian except for switching the check from a binary to a source package check. Not sure if this is that easily doable. Additionally it will become more complex as it would have each per-binary-package debian/.NEWS files separately. (It would also invalidate any lintian override about it.) But I actually would prefer to not have to do that at all as IMHO that tag is validly emitted and this is IMHO a newly introduced bug in debhelper. Cloning an according (wishlist) bug report against debhelper As it won't be fixed in debhelper either, maybe downgrade this warning?
Bug#958895: libevhtp-dev: libtool arguments failure
On 2023-01-12 08:46, Alexandre Rossi wrote: Now that the blocking bug is fixed, I thing the patch should be uploaded to unstable. Do you want me to prepare a build for you to upload? Yes, please do.
Bug#1023697: Keep out of testing
On Thu, 10 Nov 2022 22:45:57 +0100 Bastian Germann wrote: As a new maintainer has stepped up, this cannot be the reason anymore to dump the package. Actually, with the next version of swupdate (one of those handful) I wanted to switch from OpenSSL to SWUpdate. As there are no real plan to provide QUIC support in OpenSSL 3 and the performance regressions of OpenSSL 3 are quite important, I may also switch HAProxy to WolfSSL.
Bug#689962: linux: Compile with CONFIG_VIRTIO_CONSOLE=y
❦ 24 avril 2021 16:15 +02, Salvatore Bonaccorso: Is this still something we should consider, or can the bug be closed? I suppose that's since almost nobody chimes in in all these years, there is no need. Now that 989153 and 989181 have been merged into this one and the bug is reopened, then the next question becomes: how to proceed. The current setting in debian/config/config (ie: globally) is this: CONFIG_VIRTIO_CONSOLE=m I can make a MR to change that to =y, but I'm not familiar with VIRTIO_CONSOLE and thus can't assess whether it's useful on all architectures. https://salsa.debian.org/kernel-team/linux/-/commit/e83e9da65cce7c870acc6b601738dd5d71bdc842 is where the above setting was made ... on 2008-09-04. The helptext in drivers/char/Kconfig says: "Virtio console for use with hypervisors." Unfortunately, I don't know either for other architectures. It is useful at least for AMD64 (to make it work on VM with no ISA bus). For ARM64, I don't know if the platform has a better mechanism for serial consoles.
Bug#1023537: bpftrace/libbpf: SIGSEGV at btf_find_by_name_kind()
On Sun, 06 Nov 2022 10:01:09 + Breno Leitao wrote: bpftrace is segfault on everycommand when running on 6.0 kernel: It works for me. Can you try again with bpftrace 0.16.0-1+b1?
Bug#1023974: Dependency missing
On 2022-11-13 12:30, Philipp Marek wrote: # bpftrace bpftrace: error while loading shared libraries: libclang-15.so.13: cannot open shared object file: No such file or directory I am not able to reproduce on my system. I don't have libclang1-15 at all and it works. bpftrace is not linked to libclang 15 but to libclang 14. Are you sure bpftrace is the one from the Debian package, not side-compiled version?
Bug#1023485: Shipped blkid is incompatible with the one in util-linux, break cryptsetup
Package: busybox-static Version: 1:1.35.0-3 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! blkid was added as an applet in busybox. This makes it available in initramfs in place of the one from util-linux. This prevents cryptsetup to works as the syntax used is not recognized by busybox. 10:58 ❱ blkid -l -t UUID=255e21df-9261-47b5-ac37-b4ae4c435a37 -o device /dev/nvme0n1p3 10:59 ❱ busybox blkid -l -t UUID=255e21df-9261-47b5-ac37-b4ae4c435a37 -o device 10:59 ❱ sudo busybox blkid -l -t UUID=255e21df-9261-47b5-ac37-b4ae4c435a37 -o device cryptsetup-initramfs could parse the output of busybox blkid, but this seems more fragile. It seems easiest to not ship blkid in busybox (hence the bug against busybox). - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmNmNPMSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5xT0QAKDHldn2kpQ+q5++vOpu05hYLsz9VkWp ud2ZH+gNXc85qDHvTN+kKu+h1nMbK8Qk/x6o/orRzvRBAwmJ6XE06tBBulOahoKi q8dxYorvXQJV3bI7ua1JYsYKTybguE/omN27IguopQdzE1Bac5fkfcKwni5QHEdi oOda3FNVAdQiZ7mh77nBaD9NtqG4lzMb4rbxwQ5ZGG2BOypVQ7CHnoyPt813PjSI eh76R5cW9/KgyqbWo4mGVGtZ8DqmVY+BLuVKH0+g+zreieRlbTLhJakwYCUJ4SNS 6ye9M58xtgviBbDUBl4ae7LV9ARSa9RpG6wkLgVw36CrD/QAwAoSsjJwcPRg2xGH P7O8nyT+tyP3xFmNGAHfJpLO/CPh8B3rNJABSO6F8hGzoh2Ej8zFfmEZ3CfchnmR SatUtS5yBlvU3wvkdK0VMDpXOdqqJjDkexjm28vriBvyAUi07OBsbqtEILGgJXb6 bOXv6hGWg5F/qA+OgjWdu6YJUbBrZVH7gvePbr5lmwwGItDc0UIrAZxZ5/1FIi5G G9+NTS+kpFFT0uvD8F6HaqZrPGTSDJM5DSoHxZLkYSYJjZzbrC2Fk9w3AaE7/6u/ 05EVetREI89NvCt7GJbvS0jCWIlk3JVMAfbDvoNm6vqqTGJPEMjW81ABkJk6QKpF 3UcOjdL4nGqS =KLT1 -END PGP SIGNATURE-
Bug#1021157: missing firmwares for Qualcomm NFA725A
On 2022-10-29 20:05, Diederik de Haas wrote: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/?qt=grep&q=WCN6855 does show various results which come very close ...SILICONZ_LITE-3.6510.7 vs the referenced ...SILICONZ_LITE-3.6510.16. And one commit is for symlinks to hw2.1 qca/rampatch_usb_00130201.bin is also present in the upstream repo, but searching for nvm_usb_00130201_gf.bin did not yield any results. So this looks like upstream does have most of the needed files, albeit a slightly older version? I don't know if anything should be done based on this, but figured I'd share my findings. I suppose the search engine only works for stuff mentioned directly in commit messages. The file present in the repository: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qca/nvm_usb_00130201_gf.bin.
Bug#1022848: linux: 6.0.5 fixes critical btrfs bug
On 2022-10-29 09:23, Salvatore Bonaccorso wrote: So question is,.. would it make sense to request that linux-image-amd64 depends on the signed | unsigned version? No unfortunately we cannot do that. The reason is similar to what lead to https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71 or caused bugs like #916927. In meanwhile furthermore linux-image-amd64 is anyway not anymore from a separate metapackage but built from linux-signed-amd64. The signed packages need always longer as this needs action of signing them trough a seprate manual process of ftp-masters. What about linux-image-amd64-unsigned?
Bug#1021157: missing firmwares for Qualcomm NFA725A
On 2022-10-29 07:15, Vincent Bernat wrote: 07:14 ❱ dpkg -L firmware-atheros | grep -E '(WCM6855|nvm_usb_00130201)' I made a typo in WCN, but the files are not here either.
Bug#1021157: missing firmwares for Qualcomm NFA725A
On 2022-10-29 00:50, Diederik de Haas wrote: The card works just fine with a 5.19 kernel after installing these files in /usr/lib/firmware/ath11k/WCN6855/hw2.0/: https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/1.1/WLAN.H SP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16/amss.bin https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/1.1/WLAN. HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16/m3.bin https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/board-2.b in https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/regdb.bin And then creating a symlink from /usr/lib/firmware/ath11k/WCN6855/hw2.1/ to hw2.0/ . (I do not understand the structure of the directories in WCN6855/hw2.0/1.1/, so I choose the newest files.) Some other firmwares from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git /tree/qca are needed for Bluetooth support and are missing as well: qca/rampatch_usb_00130201.bin qca/nvm_usb_00130201_gf.bin I found all the mentioned file names in the buildd log for 20220913-1, so I guess the issue is fixed. Can you verify that and update/close the bug accordingly? They are not present. 07:14 ❱ dpkg -L firmware-atheros | grep -E '(WCM6855|nvm_usb_00130201)'
Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot
On Fri, 10 Sep 2021 10:35:31 +0200 Julian Andres Klode wrote: Control: reassign -1 shim Control: affects -1 fwupd On Fri, Sep 10, 2021 at 09:27:11AM +0200, Norbert Schulz wrote: > Package: fwupd > Version: 1.2.14-1~deb10u1 > Followup-For: Bug #968997 > > Dear Maintainer, > > this bug still exist for a long time. I removed all packages relating fwupd and install it from scratch but > no install of the firmware on reboot. Sure, that's expected, shim 15.4 is not able to load fwupd without additional patches, which have not been applied yet, so it's not going to get better by reinstalling fwupd. shim-unsigned has been updated to 15.6 which has the right patches in. But for some reason, shim-signed is still at 15.4.
Bug#1010039: autorandr: python deprecation warnings
On Fri, 22 Apr 2022 16:52:35 -0700 Don Armstrong wrote: > % autorandr > /usr/bin/autorandr:42: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives > from distutils.version import LooseVersion as Version Thanks for the report! Looks like upstream has fixed this, so I just need to upgrade to the newest version. Hey Don! Any plan for that? Thanks!
Bug#1017676: bpftrace: Please upgrade to llvm-toolchain-14
On 2022-08-18 23:43, Sylvestre Ledru wrote: Source: bpftrace Severity: important Dear Maintainer, As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -14. We are trying NOT to ship Bookworm with llvm-toolchain-13. llvm-defaults is now pointing to -14. I was about to upload. Can I still proceeed or should I not?
Bug#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks
On 2022-08-13 09:59, Carsten Schoenert wrote: The NetBox UI is using some comprehensive JS files which are shipped as minimized files. Currently I'm unable to drop the shipped minimized code and rebuild all the needed files from scratch. If possible I'd like to get some help on this, currently netbox will need to go into non-free due the non rebuild-able minimized files. OTOH netbox can't go into main as it requires at least one package from non-free, it requires drf-yasg-nonfree for some Swagger functionality. It also looks like drf-yasg-nonfree is non-free just because of the minimized JS files. This is often a problem and while not everybody agrees with this, you can workaround this issue by shipping the non-minified sources in debian/missing-sources. You may or may not use them in the build process. Maybe it does not hurt to try to run a minifier (like uglifyjs) on them if you feel like it. As long as upstream is using the files as is, the FTP masters are likely to accept a package with the sources in debian/missing.
Bug#1015210: OUI lookups incorrect
On 2022-07-17 21:54, Jonathon Reinhart wrote: Are you suggesting that python3-netaddr would need its own directory somewhere under /var for the updated index files? (Because /usr shouldn't change, and /var/lib/ieee-data isn't controlled by python3-netaddr) That's right.
Bug#1015210: OUI lookups incorrect
On 2022-07-17 20:40, Jonathon Reinhart wrote:
OUI lookups are returning incorrect / corrupt results. Take for
example OUI F4-6D-04.
The data in ieee-data is correct:
F4-6D-04 (hex)ASUSTek COMPUTER INC.
F46D04 (base 16)ASUSTek COMPUTER INC.
15,Li-Te Rd.,Peitou,
Taipei112
TW
But using the OUI object I get completely incorrect / corrupt results:
>>> oui = OUI('F4-6D-04')
>>> oui
OUI('F4-6D-04')
>>> oui.registration()
{'address': [')\t\tCisco Systems, Inc',
'80 West Tasman Drive',
'San Jose CA 94568',
'US'],
'idx': 16018692,
'offset': 821392,
'org': 'eero inc.',
'oui': 'F4-6D-04',
'size': 141}
I suspect that the reason is because this debian package replaces
netaddr/eui/oui.txt with a symlink to /var/lib/ieee-data/oui.txt but
**does not** update the corresponding oui.idx. Thus, the indices are
stale.
This Debian package likely needs to re-generate the indices before shipping.
It's already the case. However, the file can change unexpectedly (for
example, when the user is running update-ieee-data). It seems that
update-ieee-data will execute hooks in /var/lib/ieee-data/update.d. We
could install such a hook. But, we would also need to add a symlink for
the indexes to a directory controlled by the netaddr package.
If you want to try to do that, you are welcome to submit a patch.
In the meantime, you can run python3
/usr/lib/python3/dist-packages/netaddr/eui/ieee.py as root to fix the
issue. This is not really "clean" (as you erase package-owned data), but
it would work.
Bug#1013581: Please rebuild to pick up the new libXi.6 dependency.
Version: 3.19-9 On 6/24/22 13:39, Peter Pentchev wrote: If this is the case, could you just request a binNMU? Hm, that's actually an interesting idea... I'll look into it, and, in that case, sorry for bothering you! :) So yeah, I will look into it and probably close this bug accordingly. I have uploaded a new version.
Bug#1013581: Please rebuild to pick up the new libXi.6 dependency.
On 6/24/22 13:05, Peter Pentchev wrote: Source: xnee Version: 3.19-8 Severity: serious X-Debbugs-Cc: r...@debian.org Hi, First of all, thanks for taking care of cnee/xnee in Debian! At some point recently, the XIQueryVersion() function from the X11 API moved to a separate library, libXi.so.6, found in the libxi6 Debian package. Since cnee 3.19-8 (in both unstable and testing) has not been linked against libXi.so.6 at build time, it does not try to load it, resulting in errors such as: [roam@straylight ~]$ cnee --replay -f /dev/null; echo "exit code $?" cnee: symbol lookup error: /lib/libxnee.so.0: undefined symbol: XIQueryVersion exit code 127 ...which breaks any program that tries to invoke cnee, leading to e.g. the wmanager tests breaking in #1013579. I think that a simple rebuild should be enough - I tested it on my local system and the cnee binary is now linked against libXi.so.6, too. If this is the case, could you just request a binNMU? Thanks.
Bug#1011391: [Pkg-openssl-devel] Bug#1011391: openssl: please support quictls patchset
❦ 8 June 2022 07:44 +02, Sebastian Andrzej Siewior: >> Willy Tarreau already asked the team for QuicTLS packaging without an >> answer: >> >> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html > > there was an answer: > > https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2022-January/007702.html Oh, sorry for saying otherwise. It seems pipermail does not provide links when a thread span over two months. As for the last paragraph, OpenSSL team said API compatibility with the patchset is a non-goal and it was also said they would like to not use the same approach by unifying the various way to handle TLS flavors. So it seems likely QuicTLS will die at some point. However, QUIC support will appear during a major version of OpenSSL, so previous version supporting the QuicTLS patchset will continue to receive security support and I suppose that it gives time for the few users to migrate to the proper OpenSSL API. I can relay your questions directly to QuicTLS on GitHub unless you want to do it yourself. -- Use library functions. - The Elements of Programming Style (Kernighan & Plauger)
Bug#1011391: openssl: please support quictls patchset
❦ 22 May 2022 16:50 +02, Sakirnth Nagarasa: > This patchset of OpenSSL is necessary to build the crypto helper > libraries for ngtcp2 with OpenSSL as well. HAProxy is also a user of such a fork. It should be noted the fork is backed by Akamai and Microsoft and is able to release updated versions the same day as OpenSSL and they managed to make the library coinstallable with the regular OpenSSL one. So, we could also provide a libssl3-quick library. Willy Tarreau already asked the team for QuicTLS packaging without an answer: https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html My opinion is that we cannot rely on OpenSSL to provide a solution in the near term (no work is currently done). As the number of downstream projects increase, users will try to find a solution. It would be better to have a solution backed at least partially by their distribution. It would be nice to have some kind of feedback to know how things are on the Debian side for this OpenSSL fork. -- Make sure comments and code agree. - The Elements of Programming Style (Kernighan & Plauger)
Bug#1010849: DWARF support disabled during build / no symbolic stack traces or argument types
❦ 11 May 2022 16:00 +02, Harald Welte: > It seems the Debian bpftrace is built without libdw support. This means no > stack > traces can be provided with uprobes, and one cannot dereference structs or > other > type information from the DWARF information. > > # bpftrace -lv > 'uprobe:/usr/local/lib/libosmocore.so.18.0.0:osmo_timer_schedule' > WARNING: Cannot parse DWARF: libdw not available No particular reason. I have added it to as a build-dep and it works just fine. Well, it took me two tries! -- There is a great discovery still to be made in Literature: that of paying literary men by the quantity they do NOT write.
Bug#1008323: bpftrace: fix FTBFS
❦ 11 April 2022 21:14 +02, Hector Oron: > According to https://github.com/iovisor/bpftrace/issues/2068 > > I applied the following patch to make the package build: Thanks! I will use the more minimal patch found here instead: https://github.com/iovisor/bpftrace/pull/2174 -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan & Plauger)
Bug#960420: Needs versioned dependency on slop
❦ 12 May 2020 14:25 +02, Yuri D'Elia: > I didn't realize maim depended on slop through a dso (I assumed it > simply called the binary). > > slop was updated to 7.5, which broke maim as a result: > > maim: error while loading shared libraries: libslopy.so.7.4: cannot > open shared object file: No such file or directory Again with the latest upload. 10:16 ❱ maim maim: error while loading shared libraries: libslopy.so.7.5: cannot open shared object file: No such file or directory -- Your manuscript is both good and original, but the part that is good is not original and the part that is original is not good. -- Samuel Johnson
Bug#995028: ncal: incorrect week numbers listed when using -w option
❦ 24 September 2021 16:33 -07, Andy Bussman: > ncal lists incorrect week numbers when using the -w option. > > Week numbers do not conform in the ISO-8601 standard, even though the > man page states that the "-w" option is ISO-8601 compliant. FI, the bug is also present upstream. -- Make sure all variables are initialised before use. - The Elements of Programming Style (Kernighan & Plauger)
Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address
❦ 25 March 2022 11:48 +01, Arturo Borrero Gonzalez: >> After looking twice, I notice the VIP is in the same subnet as the peer. >> If you don't have any other address on the subnet, I don't see how this >> could work. If you have, maybe it would be better to use a /32 for the >> VIP. > > Would you mind to elaborate? > > The setup is as follows: > > * peer 1, local IP 208.80.153.188/29 > * peer 2, local IP 208.80.153.189/29 > * VIP 208.80.153.190/29 > > I honestly don't know how this relates to the execution error itself. > Do you think the address assignment fails because some misconfigured > netmask? Usually, on Linux, VIP are using /32 to avoid issues with source address selection. Notably, when contacting a peer, the VIP could be selected when using a /29, while this is not possible when using a /32. -- Its name is Public Opinion. It is held in reverence. It settles everything. Some think it is the voice of God. -- Mark Twain
Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address
severity -1 important fixed -1 1:2.2.7-1~bpo11+1 thanks ❦ 24 March 2022 17:24 +01, Arturo Borrero Gonzalez: > This exact same setup was previously working, and actually, the next version > works just fine. > Not sure if this has anything to do with the kernel version warning at the > beginning. > > In summary: > > | keepalived version | Debian | Works? | > | |--|| > | 1:2.0.10-1 | buster | yes| > | 1:2.1.5-0.2+deb11u1 | bullseye | no | > | 1:2.2.7-1~bpo11+1 | bullseye-bpo | yes| > > I'm opeining this bug report mostly so others can find it. > Raelly appreciated the bpo package is ready to use. Glad that the backport solves this issue. Unfortunately, I don't think it's worth reporting the issue upstream as they don't like us lagging so many versions late. I have used it myself with unicast_src, so it is not broken for everyone. After looking twice, I notice the VIP is in the same subnet as the peer. If you don't have any other address on the subnet, I don't see how this could work. If you have, maybe it would be better to use a /32 for the VIP. -- If one cannot enjoy reading a book over and over again, there is no use in reading it at all. -- Oscar Wilde
Bug#1007800: golang-golang-x-tools: FTBFS with Go 1.18
❦ 16 March 2022 18:39 -05, William 'jawn-smith' Wilson: > golang-golang-x-tools currently FTBFS with Go 1.18 > > In Ubuntu, the attached patch was applied to achieve the following: > > > * Fix FTBFS with Go 1.18 Hello, gopls has issues with Go 1.18. Better upgrade to the latest upstream version. Thanks. -- There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy. -- Wm. Shakespeare, "Hamlet"
Bug#1006427: New upstream version: 2.2.7
❦ 9 March 2022 12:37 +01, Alexander Wirt: >> >> A new upstream version has been published. Would you mind if I take >> >> over the package? I work next to the upstream author and I am often >> >> badgered by the package being not up-to-date. :) >> >> > I would be glad if you would take over. Unfortunately I am more or >> > less in management nowadays and less in maintaining clusters. >> >> Thanks! Do you prefer I move the repository under the Debian namespace >> on Salsa or that I keep it under ipvs-team? > Whatever you like more. It is yours, just tell me so that I will be > able to move the repo. If you don't mind, can you move it to the Debian namespace? Thanks! -- Write clearly - don't sacrifice clarity for "efficiency". - The Elements of Programming Style (Kernighan & Plauger)
Bug#1006961: exabgp.env not loaded with systemd Service
❦ 9 March 2022 13:18 +01, Adrian: > ExecStart=/usr/sbin/exabgp -e /etc/exabgp/exabgp.env /etc/exabgp/exabgp.conf > # < manually added env file /etc/exabgp/exabgp.env is the default value when no -e option is provided. -- A horse! A horse! My kingdom for a horse! -- Wm. Shakespeare, "Richard III"
Bug#1006427: New upstream version: 2.2.7
❦ 4 March 2022 10:47 +01, Alexander Wirt: >> A new upstream version has been published. Would you mind if I take >> over the package? I work next to the upstream author and I am often >> badgered by the package being not up-to-date. :) > I would be glad if you would take over. Unfortunately I am more or > less in management nowadays and less in maintaining clusters. Thanks! Do you prefer I move the repository under the Debian namespace on Salsa or that I keep it under ipvs-team? -- Parenthesise to avoid ambiguity. - The Elements of Programming Style (Kernighan & Plauger)
Bug#1006427: New upstream version: 2.2.7
Source: keepalived Version: 1:2.2.4-0.2 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! A new upstream version has been published. Would you mind if I take over the package? I work next to the upstream author and I am often badgered by the package being not up-to-date. :) Thanks. - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-rc2+ (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmIYr6oSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5+58P/RP4CWS+i+eUmfyN4FfUDJdptPPOCscO AFs5bkvXmYaSRjMZPd+UUHQS3mFfMvzJav6MoASvzt4FQguTpQAaFPJotQk6KrGt jJ5LW9CJaozt1NopB4kLWe6n+GYq4Hgogqa6pXno1omEj78VvQAow/2wfM0oo5n2 24kXMiW0USHSu0vOtytrAUo3A/Fvqj79DnYhUGCpBV3zvfvgcnCynD8Q3eZomqv5 copImS212Ds19WCNm4l8DM4Pqkjt/B9FUQrWat2vHotwGwi7s0rfejSML3nhl4eW OYGYjwO5htBedfHFfqfhanHMHOZ7D5R5CVibtWqnRS7hiNHGDByhrJ7c8caBgv9g GaU9QZMvoTpD34k/GNFBKvvnYi0KtnH6c7ZQRzIPaCgY1rsHoF6PMcE9sXTqxWP8 kev6S0XVqhZxM2OT0/msiP/iTVXbx7+gGWwERJHKf4kpcderZyN774zOx7rya1gK h2XbjkWUfw3o4Q8i9eNAJyPvXnyZlV01oXS09fRsfy1LTd3a55oG6cPGSBlw+uzp n2W4zDMESWyRHcsnQgggUXhTyMvvGazxM9m/7HWOc4V7J3kO24ZShE7AZp19z3Tb 7Fa5h8VWaOFB1gQTvGZj1mwf5DlL8zcvbXs+T7OoyvFcOAzZx5qGL6n0z95nrzLW 3MXHCKa5CRxW =QL8q -END PGP SIGNATURE-
Bug#1006007:
❦ 19 February 2022 10:02 -03, Andreas Hasenack: > Salsa PR at https://salsa.debian.org/haproxy-team/haproxy/-/merge_requests/7 > with the upstream patch that ubuntu has been carrying. I have asked upstream about guidance on this. It seems that despite compiling, there are regressions during integration tests. -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan & Plauger)
Bug#1003108: Dependency on python3-cachecontrol has an odd alternative
Package: python3-poetry Version: 1.1.12+dfsg-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! python3-cachecontrol (>= 0.12.6) | python3 (>> 3.6) So, python3-cachecontrol don't get installed. Dunno who is generating this dependency. Checked cachecontrol repository, but nothing odd here. And in dh-python, nothing odd here either. - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-poetry depends on: ii python3 3.9.8-1 ii python3-cachy 0.3.0-4 ii python3-cleo0.8.1-2 ii python3-clikit 0.6.2-3 ii python3-html5lib1.1-3 ii python3-importlib-metadata 4.6.4-1 ii python3-lockfile1:0.12.2-2.2 ii python3-packaging 21.3-1 ii python3-pexpect 4.8.0-2 ii python3-pkginfo 1.8.2-1 ii python3-poetry-core 1.0.7-2 ii python3-requests2.25.1+dfsg-2 ii python3-requests-toolbelt 0.9.1-1 ii python3-shellingham 1.3.2-1.1 ii python3-tomlkit 0.8.0-1 ii python3-virtualenv 20.12.1+ds-1 python3-poetry recommends no packages. python3-poetry suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmHUC/MSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5wxAP/ifdRGmBN7Uxwr5yB0GT9zBXNl2jOk7l 8IUyaG7jkbIHggLaxTo7hG65uOfLn7v0EF8iEHv+iV68lbPeN7anbjVdZgoRno/K 81XfA+KPlkNgMbT2AcLKizxCbYGHSqqBNTFe3sIaDwoEKdwxcB5EEejbc67s2KJf 32lOUXgmHvS+oA+jZ2YOSBuf0qK1G6ET/8tBDWUg02gnlsE4KQnQUNvA1pKrl5LX +3P1cYKGrQXuxnayMGWZJ4xlbS4QdWLspQmiIbFENxyT594mDF2pnl96EMKNkde3 hnhFu4I2Hz3Q0IUteFPiAOv4ADREwzgSVUXJ0LsTUIkwJjN5t46h1tAKcdxhsYSl O0CBxIAFvTK/BWPeLth11zOqzR2XYeUOVu3hidmg7pzBEVpvNk1VP9pxdXBve315 dEEsEz6EW10QrMBkC3GbR4vLVb+Z2z79O1NXL7/+Shxq6843LMy8wlgSLd4KW26m vZP32DACnnORWAmACU6xOM4lmZPP7c0PUN4yZcIcB42HWHRUuRb8KFfguvvwLYzD n72kbABEgQijWCGyL81XF2r7I35FZjebX3B5xJAL9Nu/x0CDZgzaJOoKrmebmXdy qmVYm1/mZ8UlXdvUTl3nLCTw9RFr98sM07R4zh1r8qQFJEhhihk+saNLoasOxxOJ WhvF48J+K10+ =+gUh -END PGP SIGNATURE-
Bug#965696: libwhisker2-perl: diff for NMU version 2.5-1.2
Thanks! If you want to take over this package, be my guest! On January 1, 2022 6:35:04 PM GMT+01:00, gregor herrmann wrote: >Control: tags 965696 + patch >Control: tags 965696 + pending >Control: tags 999044 + patch >Control: tags 999044 + pending > > >Dear maintainer, > >I've prepared an NMU for libwhisker2-perl (versioned as 2.5-1.2) and >uploaded it to DELAYED/5. Please feel free to tell me if I >should delay it longer. > >Regards. > > >-- > .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org > : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 > `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe > `- -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#998242: cron-failure@.service delivery fails due to DynamicUser with exim
Control: forwarded -1 https://github.com/systemd-cron/systemd-cron/issues/75 ❦ 21 December 2021 21:14 +01, Vincent Bernat: > I have the same issue with Postfix. This is a problem known upstream. DynamicUser= implies NoNewPrivileges=. https://github.com/systemd-cron/systemd-cron/issues/75 -- To be or not to be. -- Shakespeare To do is to be. -- Nietzsche To be is to do. -- Sartre Do be do be do. -- Sinatra
Bug#995212: ungoogled-chromium? [
❦ 14 December 2021 09:13 GMT, Jeff Blake: > Unless there are licensing or technical objections, I would suggest building > with upstream > bundled clang to avoid all sorts of incompatibilities and obviate the need > for extra patching > (stable's clang is often too old and upstream currently uses clang-14 vs > unstable's 13). > As an added bonus, this is a prerequisite to, and allows building with PGO > enabled. Refer to > my rules file to see how download of upstream clang/llvm binaries can > be automated [6]. Unfortunately, packages are not allowed to fetch external stuff during build. You'll need to vendor clang, either directly in the source tarball or as an additional tarball. I just cite this part, but I agree with everything else you said. > Finally, it's good to see some of the maintainability issues being > discussed, as when debian chromium development was restarted a year or > so ago, I became frustrated when my questions on the issue went > unanswered. So many patches seemed to be superfluous, yet nobody > seemed to have the motivation, authority or courage to delete them. The situation didn't change that much. When a maintainer is inactive, it is always a bit difficult to know how to move forward. The issue has now gotten a bit more light, but it is still unclear on how to proceed. I don't think we had a similar case in the past (pretty popular package, totally unable to push security fixes). It is a pity the package got an exception to go in Bullseye while it was pretty clear we would get into this situation. -- As flies to wanton boys are we to the gods; they kill us for their sport. -- Shakespeare, "King Lear"
Bug#998242: cron-failure@.service delivery fails due to DynamicUser with exim
❦ 1 November 2021 14:27 +01, Yuri D'Elia: > cron-failure@ is using DynamicUser=yes, however this causes a silent > delivery failure when using exim4: > > systemd[1]: Starting cron-failure@cron-monthly.service... > mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed > to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D: > Permission denied > mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed > to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D: > Permission denied > mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed > to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D: > Permission denied > systemd[1]: cron-failure@cron-monthly.service: Deactivated successfully. > systemd[1]: Finished cron-failure@cron-monthly.service. I have the same issue with Postfix. Dec 21 21:02:53 neo mail_on_failure[938987]: postdrop: warning: mail_queue_enter: create file maildrop/155101.938987: Permission denied Dec 21 21:02:53 neo postfix/postdrop[938987]: warning: mail_queue_enter: create file maildrop/155101.938987: Permission denied Dec 21 21:03:03 neo mail_on_failure[938987]: postdrop: warning: mail_queue_enter: create file maildrop/155516.938987: Permission denied Dec 21 21:03:03 neo postfix/postdrop[938987]: warning: mail_queue_enter: create file maildrop/155516.938987: Permission denied However, I don't know how it should work. Permissions for maildrop is: 21:03 ❱ ls -ltrd /var/spool/postfix/maildrop drwx-wx--T 2 postfix postdrop 4096 Dec 21 20:05 /var/spool/postfix/maildrop With `T`, I am unable to create a file either: 21:05 ❱ touch /var/spool/postfix/maildrop/titi touch: cannot touch '/var/spool/postfix/maildrop/titi': Permission denied I suppose only postdrop can write here: 21:08 ❱ ls -ltrhA =postdrop -r-xr-sr-x 1 root postdrop 19K Nov 13 22:05 /usr/sbin/postdrop However, for some reason, the process is not part of the postdrop group: 21:09 ❱ ls -ltrhAd /proc/938987 dr-xr-xr-x 9 cron-failure systemd-journal 0 Dec 13 07:19 /proc/938987 21:11 ❱ systemctl cat cron-failure@cron-root-root-0.service # /lib/systemd/system/cron-failure@.service [Unit] Description=systemd-cron OnFailure for %i Documentation=man:systemd.cron(7) RefuseManualStart=true RefuseManualStop=true ConditionFileIsExecutable=/usr/sbin/sendmail [Service] Type=oneshot ExecStart=/lib/systemd-cron/mail_on_failure %i DynamicUser=yes Group=systemd-journal 21:13 ❱ cat /proc/938987/status | grep Cap CapInh: CapPrm: CapEff: CapBnd: 01ff CapAmb: 21:13 ❱ capsh --decode=01ff | grep setgid 0x01ff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore So, process should be able to change group. -- This night methinks is but the daylight sick. -- William Shakespeare, "The Merchant of Venice"
Bug#996165: firmware-sof-signed: sound/mic also does not work on Dell Precision 5760
❦ 17 December 2021 17:55 +01, Dirk Kostrewa: > I have also tried before the 5.14 kernel from the Bullseye backports > repository (with firmware-sof-signed 1.7.1), which also didn't work. I > would be grateful for any other suggestion! No idea. You should try to ask upstream: https://github.com/thesofproject/sof -- Make input easy to prepare and output self-explanatory. - The Elements of Programming Style (Kernighan & Plauger)
Bug#996165: firmware-sof-signed: sound/mic also does not work on Dell Precision 5760
❦ 17 December 2021 10:19 +01, Dirk Kostrewa: > 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device > [8086:43c8] (rev 11) > Subsystem: Dell Device [1028:0a5e] > Flags: bus master, fast devsel, latency 64, IRQ 16, IOMMU group 17 > Memory at 618d1d8000 (64-bit, non-prefetchable) [size=16K] > Memory at 618d00 (64-bit, non-prefetchable) [size=1M] > Capabilities: [50] Power Management version 3 > Capabilities: [80] Vendor Specific Information: Len=14 > Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+ > Kernel driver in use: sof-audio-pci > Kernel modules: snd_hda_intel, snd_sof_pci > > Could you please check this? > > I would be happy to provide any information that you need to address > this issue! You can try with a more recent version to see if it fixes your issue: https://packages.debian.org/sid/all/firmware-sof-signed/download -- After all, all he did was string together a lot of old, well-known quotations. -- H. L. Mencken, on Shakespeare
Bug#1001507: RFS: dwm/6.2-1 [ITA] -- dynamic window manager
❦ 11 December 2021 10:43 GMT, Matteo Bini: >* New maintainer Is there some agreement with the original maintainer? >* New upstream release. You can close #978687 and #945281. -- Debian package sponsoring guidelines: https://vincent.bernat.ch/en/debian-package-sponsoring
Bug#1001474: bullseye-pu: package bpftrace/0.11.3-5
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
[ Reason ]
Array indexing is broken, making bpftrace unable to complete its task on some
scripts.
[ Impact ]
Some scripts cannot work.
[ Tests ]
Tested with this script:
#!/usr/bin/env bpftrace
#include
#include
kprobe:tcp_connect
{
$sk = ((struct sock *) arg0);
if ($sk->__sk_common.skc_family == AF_INET6) {
$d0 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[0];
$d1 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[1];
$d2 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[2];
$d3 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[3];
printf("%X %X %X %X\n", $d0, $d1, $d2, $d3);
}
}
[ Risks ]
Code is trivial. Patch is from upstream.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Upstream patch to fix the issue.
[ Other info ]
-BEGIN PGP SIGNATURE-
iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmGzmqISHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5N/QP/ibBMh/2uaCW0gsYOeb7brdwNEBuclMW
r7NQhJx10Q/f5tonj1NizPu94oeEOh4W6GpmZ4tMmQSi7k2Hr9Ny3r+mqwSjGTEZ
R5xK8gHV1WSoVCXCXa9xu3XdXaeZhG545g9cnAIxkCRp6ZOcI6MqDZ6A+xEExTz2
y5bF9ezhPDRjbhMFiuhhZ9lwIBSuINwm0osgEsrwxpRz96TnLQG2rPS52UUTYCiO
6Tpd4aJdCLTgw969H2//tb1PuODq0//KFndDWhtZcN88ahvH1QYk9Tlf7HrtQ5qy
LrkAQe5puu5q5+S54OdvGhcEINclgsdZ52tqF///nHm1Q+IghimlSjsNZAQh9CaI
wh3PhTKtFUj5zHWQKFwgLV/41p6Cg8SYTlQp9trT1tS8J9eELJQDzoHEBFl6iJer
HtOFSazwIkHlFqFsrmZ+mIZ0mpmlKRBQmLwP4dURV+4skFbIT4tx1g4TrZeK0Erg
dEOZQ8BP3pTjSXT1GqHpnif6NiiLGre0FTmqEVT3XrgFPoR5jrECxn7PzAKAxuCP
Ulx3pTpsock1jS/LSAbPoyUTOo2skm39tC9zOuixLQuLy81NVMIUr2SQQctLiLAk
/avo0leQDqZihJY2Di7idvm9El/VbHq80SYi2ddMsD8WeFvIU77xwrP1azlnjkhg
hdP5YokOmKBt
=pJ4O
-END PGP SIGNATURE-
>From b06bd9dfd60e58f6c5164fd283cb19801513fb09 Mon Sep 17 00:00:00 2001
From: Vincent Bernat
Date: Fri, 10 Dec 2021 19:16:23 +0100
Subject: [PATCH] d/patches: add patch to fix array indexing
---
debian/changelog | 6 ++
debian/patches/1457.patch | 27 +++
debian/patches/series | 1 +
3 files changed, 34 insertions(+)
create mode 100644 debian/patches/1457.patch
diff --git a/debian/changelog b/debian/changelog
index e22c1cc4b4a8..e138bfe58331 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+bpftrace (0.11.3-5+deb11u1) bullseye; urgency=medium
+
+ * d/patches: add patch to fix array indexing (Closes: #1001449).
+
+ -- Vincent Bernat Fri, 10 Dec 2021 19:16:15 +0100
+
bpftrace (0.11.3-5) unstable; urgency=medium
* d/control: do not build-depends on libbfd-dev (Closes: #980438)
diff --git a/debian/patches/1457.patch b/debian/patches/1457.patch
new file mode 100644
index ..d572df0e39fa
--- /dev/null
+++ b/debian/patches/1457.patch
@@ -0,0 +1,27 @@
+From 21e9a7292240e1aa7a2809dedb37347104085dc1 Mon Sep 17 00:00:00 2001
+From: Daniel Xu
+Date: Thu, 6 Aug 2020 08:51:44 -0700
+Subject: [PATCH] Fix array indexing regression
+
+We regressed on array indexing because the CreateArray() helper forgot
+to set pointee_size. This caused all array indexes to silently index to
+index 0.
+---
+ CHANGELOG.md | 2 ++
+ src/ast/semantic_analyser.cpp | 3 ++-
+ src/types.cpp | 1 +
+ tests/runtime/regression | 5 +
+ 4 files changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/src/types.cpp b/src/types.cpp
+index bc0be7d912..14fff5f64a 100644
+--- a/src/types.cpp
b/src/types.cpp
+@@ -280,6 +280,7 @@ SizedType CreateArray(size_t num_elements, const SizedType
&element_type)
+ auto ty = SizedType(Type::array, num_elements);
+ ty.num_elements_ = num_elements;
+ ty.element_type_ = new SizedType(element_type);
++ ty.pointee_size = element_type.size;
+ return ty;
+ }
+
diff --git a/debian/patches/series b/debian/patches/series
index d01dae2643d1..d6e04b4626c3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
0001-Ensure-symbols-are-exported-for-bpftrace-executable.patch
+1457.patch
--
2.34.1
Bug#1001449: array indexing broken
❦ 10 December 2021 10:40 +01, Julian Taylor: > This has been fixed upstream with this patch: > https://github.com/iovisor/bpftrace/pull/1457 I'll try to push the update for the next point release (Dec 18). -- The last thing one knows in constructing a work is what to put first. -- Blaise Pascal
Bug#999673: bullseye-pu: package lldpd/1.0.11-1
❦ 29 November 2021 17:32 GMT, Adam D. Barratt: >> > What you've uploaded to bullseye is *not* what you proposed in this >> > request, however. >> > >> > The debdiff attached to this bug report amounts to "4 files >> > changed, >> > 130 insertions(+)", the uploaded package is "39 files changed, 561 >> > insertions(+), 221 deletions(-)" and includes a new upstream >> > release. >> >> Ugh. Very sorry about that! >> >> Here is the appropriate diff. How can I sort out my bad upload? >> Bumping the version number? I hold uploading anything else until you >> approve. > > Ah, I see the confusion - you used the wrong base upload when > generating the first diff. As that resulted in an upload of 1.0.12- > 1+deb11u1 and the fixed package will be 1.0.11-1+deb11u1, they can co- > exist in the processing queue - free to upload the new diff and we will > deal with rejecting the larger diff. Thanks! Done. -- "... all the modern inconveniences ..." -- Mark Twain
Bug#977738: rofi: New upstream release 1.6.1
❦ 9 September 2021 09:04 +02, Vincent Bernat:
>> https://github.com/davatorium/rofi/releases/tag/1.6.1
>>
>> Version 1.6.0 is very interesting because it adds a new [1]script mode
>> that allows more powerful selectors.
>>
>> I tried to build the package using the current [2]debian directory for
>> the package in Sid and it seems to work with no changes.
>>
>> 1. https://github.com/davatorium/rofi/blob/next/doc/rofi-script.5.markdown
>> 2. https://deb.debian.org/debian/pool/main/r/rofi/rofi_1.5.4-1.debian.tar.xz
>
> I am also interested by updating Rofi in Debian. Jason, do you plan to
> continue working on Rofi? I can sponsor the uploads if needed.
I have uploaded 1.7.1 in DELAYED/10 queue. Attached is the diff.
diff -Nru rofi-1.5.4/debian/changelog rofi-1.7.1/debian/changelog
--- rofi-1.5.4/debian/changelog 2021-09-14 20:17:12.0 +0200
+++ rofi-1.7.1/debian/changelog 2021-11-28 14:15:52.0 +0100
@@ -1,3 +1,15 @@
+rofi (1.7.1-0.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * New upstream release. Closes: #977738.
+ * d/patches: remove patch to fix autoconf 2.70 compatibility.
+ * d/control: add libxcb-cursor-dev as a build-depedency.
+ * d/control: remove libxcb-xrm (not needed anymore).
+ * d/control: replace librsvg2-dev with gdk-pixbuf.
+ * d/docs: remove (no more README.md).
+
+ -- Vincent Bernat Sun, 28 Nov 2021 14:15:52 +0100
+
rofi (1.5.4-1.1) unstable; urgency=high
* Non-maintainer upload.
diff -Nru rofi-1.5.4/debian/control rofi-1.7.1/debian/control
--- rofi-1.5.4/debian/control 2021-09-14 19:55:52.0 +0200
+++ rofi-1.7.1/debian/control 2021-11-28 14:15:52.0 +0100
@@ -7,18 +7,18 @@
bison,
flex,
libpango1.0-dev,
+ libgdk-pixbuf-2.0-dev,
libstartup-notification0-dev,
libxkbcommon-dev (>= 0.5.0),
libxkbcommon-x11-dev (>= 0.5.0),
libxcb1-dev,
- libxcb-xkb-dev,
- libxcb-xinerama0-dev,
+ libxcb-cursor-dev,
libxcb-ewmh-dev,
libxcb-icccm4-dev,
libxcb-randr0-dev,
libxcb-util0-dev,
- librsvg2-dev,
- libxcb-xrm-dev
+ libxcb-xinerama0-dev,
+ libxcb-xkb-dev
Standards-Version: 4.4.0
Homepage: https://github.com/DaveDavenport/rofi/
Vcs-Git: https://salsa.debian.org/jpleau-guest/rofi
diff -Nru rofi-1.5.4/debian/patches/0001-fix-autoconf-2.70-compat.patch rofi-1.7.1/debian/patches/0001-fix-autoconf-2.70-compat.patch
--- rofi-1.5.4/debian/patches/0001-fix-autoconf-2.70-compat.patch 2021-09-14 20:17:02.0 +0200
+++ rofi-1.7.1/debian/patches/0001-fix-autoconf-2.70-compat.patch 1970-01-01 01:00:00.0 +0100
@@ -1,24 +0,0 @@
-From: Boyuan Yang
-Date: Tue, 14 Sep 2021 14:12:35 -0400
-Subject: fix autoconf 2.70 compat
-
-* Use no argument AC_PROG_LEX
-
-Bug-Debian: https://bugs.debian.org/978898
- configure.ac | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/configure.ac b/configure.ac
-index 533b99d..d4b7c59 100644
a/configure.ac
-+++ b/configure.ac
-@@ -7,7 +7,7 @@ AH_BOTTOM([#include "gitconfig.h"])
- dnl -
- dnl Lex & Bison language parser.
- dnl -
--AC_PROG_LEX([flex])
-+AC_PROG_LEX
- AC_PROG_YACC
-
- AS_IF([test "x${YACC}" != "xbison -y" ], [AC_MSG_ERROR( "Failed to find bison")])
diff -Nru rofi-1.5.4/debian/patches/series rofi-1.7.1/debian/patches/series
--- rofi-1.5.4/debian/patches/series 2021-09-14 20:13:04.0 +0200
+++ rofi-1.7.1/debian/patches/series 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-0001-fix-autoconf-2.70-compat.patch
diff -Nru rofi-1.5.4/debian/rofi.docs rofi-1.7.1/debian/rofi.docs
--- rofi-1.5.4/debian/rofi.docs 2021-09-14 19:55:52.0 +0200
+++ rofi-1.7.1/debian/rofi.docs 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-README.md
--
In the first place, God made idiots; this was for practice; then he made
school boards.
-- Mark Twain
Bug#999673: bullseye-pu: package lldpd/1.0.11-1
❦ 27 November 2021 17:43 GMT, Adam D. Barratt:
>> > Package: release.debian.org
>> > Severity: normal
>> > Tags: bullseye
>> > User: release.debian@packages.debian.org
>> > Usertags: pu
>> [...]
>>
>> I did the upload to bullseye as I think the change is not
>> controversial.
>
> What you've uploaded to bullseye is *not* what you proposed in this
> request, however.
>
> The debdiff attached to this bug report amounts to "4 files changed,
> 130 insertions(+)", the uploaded package is "39 files changed, 561
> insertions(+), 221 deletions(-)" and includes a new upstream release.
Ugh. Very sorry about that!
Here is the appropriate diff. How can I sort out my bad upload? Bumping
the version number? I hold uploading anything else until you approve.
>From a5a413c1f44bb0a063fc9ca4cf56ae7137f53f3d Mon Sep 17 00:00:00 2001
From: Vincent Bernat
Date: Sun, 14 Nov 2021 15:42:12 +0100
Subject: [PATCH] Tentative security update for Bullseye
---
debian/changelog | 8 ++
...et-VLAN-tag-if-client-did-not-set-it.patch | 27 ++
...-overflow-when-reading-SONMP-packets.patch | 93 +++
debian/patches/series | 2 +
4 files changed, 130 insertions(+)
create mode 100644 debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
create mode 100644 debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch
diff --git a/debian/changelog b/debian/changelog
index 4fc8b730cc52..6da569249198 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lldpd (1.0.11-1+deb11u1) bullseye; urgency=high
+
+ * d/patches: sonmp: fix heap overflow when reading SONMP packets.
+CVE-2021-43612
+ * d/patches: client: do not set VLAN tag if client did not set it
+
+ -- Vincent Bernat Sat, 27 Nov 2021 23:30:43 +0100
+
lldpd (1.0.11-1) unstable; urgency=medium
* New upstream release.
diff --git a/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
new file mode 100644
index ..1f65986ae27e
--- /dev/null
+++ b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
@@ -0,0 +1,27 @@
+From 261afbe371ab316a4bf710338f6d9183a01e083f Mon Sep 17 00:00:00 2001
+From: Vincent Bernat
+Date: Wed, 29 Sep 2021 12:02:15 +0200
+Subject: [PATCH] client: do not set VLAN tag if client did not set it
+
+This fixes a bug where frames could be tagged with VLAN 0 after client
+configuration.
+---
+ src/daemon/client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/daemon/client.c b/src/daemon/client.c
+index b4a08aae80a8..0d0f3ea37a19 100644
+--- a/src/daemon/client.c
b/src/daemon/client.c
+@@ -390,7 +390,7 @@ _client_handle_set_port(struct lldpd *cfg,
+ port->p_disable_rx = port->p_disable_tx = 1;
+ break;
+ }
+- if (set->vlan_tx_enabled >= -1) {
++ if (set->vlan_tx_enabled > -1) {
+ port->p_vlan_tx_enabled = set->vlan_tx_enabled;
+ port->p_vlan_tx_tag = set->vlan_tx_tag;
+ }
+--
+2.33.1
+
diff --git a/debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch b/debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch
new file mode 100644
index ..c06689987c34
--- /dev/null
+++ b/debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch
@@ -0,0 +1,93 @@
+From 73d42680fce8598324364dbb31b9bc3b8320adf7 Mon Sep 17 00:00:00 2001
+From: Vincent Bernat
+Date: Sun, 19 Sep 2021 21:18:47 +0200
+Subject: [PATCH] sonmp: fix heap overflow when reading SONMP packets
+
+By sending short SONMP packets, an attacker can make the decoder crash
+by reading too much data on the heap. SONMP packets are fixed in size,
+just ensure we get the enough bytes to contain a SONMP packet.
+
+CVE-2021-43612
+---
+ NEWS | 2 ++
+ src/daemon/protocols/sonmp.c | 2 +-
+ src/daemon/protocols/sonmp.h | 2 +-
+ tests/check_sonmp.c | 10 +-
+ 4 files changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/src/daemon/protocols/sonmp.c b/src/daemon/protocols/sonmp.c
+index 41dcf6aa412d..f8f12469e28a 100644
+--- a/src/daemon/protocols/sonmp.c
b/src/daemon/protocols/sonmp.c
+@@ -311,7 +311,7 @@ sonmp_decode(struct lldpd *cfg, char *frame, int s,
+
+ length = s;
+ pos = (u_int8_t*)frame;
+- if (length < SONMP_SIZE) {
++ if (length < SONMP_SIZE + 2*ETHER_ADDR_LEN + sizeof(u_int16_t)) {
+ log_warnx("sonmp", "too short SONMP frame received on %s", hardware->h_ifname);
+ goto malformed;
+ }
+diff --git a/src/daemon/protocols/sonmp.h b/src/daemon/protocols/sonmp.h
+index 0e60106dae63..ff7a720f0b5d 100644
+--- a/src/daemon/protocols/sonmp.h
b/src/daemon/protocols/sonmp.h
+@@ -24,7 +24,7 @@
+
Bug#1000707: bullseye-pu: package keepalived/1:2.1.5-0.2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [ Reason ] Keepalived ships a DBus policy allowing anyone to access and write any properties. We want to restrict this policy to only impact the properties owned by Keepalived. [ Impact ] Any user can read any DBus property and write any writable property. [ Tests ] Tested manually with: dbus-send --print-reply --system --dest=org.freedesktop.nm_dispatcher \ / org.freedesktop.DBus.Properties.Set \ string:com.example.Nope string:Nope variant:string:foo Thanks to Simon McVittie for its help on this. [ Risks ] Very low. I think most people don't enable DBus support, so we are unlikely to break anything. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] Restrict allowed properties to org.keepalived.Vrrp1 destination. [ Other info ] - - Real impact seems small as most properties are already readable and are not writable. - - Security team is OK to use a point release to fix this. 9b4813899b1b -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmGiR6sSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5S/gP/ipz9T9W02SEl2QOVw3falS9pQx4JUaV NYbwqbd+nocTjRTjk093QbtpfsGIxldwOBNy5cdZhEBQr+v4P+sj6zzBnP5s75mG foWBRviSQhD3XvwS9kZ5+4yhULdhv9iiSJE22nDmIRCOQ/zYvxeoaMxbjSoEetvE 4CzSNtVXP3uPmC+/FmdmdyoYxtbZTgnSkBv5bNNHtpMt9bl3jjRlLTx9vp1gbkzg nJUulyvv63wIm6pAiKbjrvW0gwutKlvlfNchlREgS4k8kAvuT/nUsZnsoMYw6m/B B8aR8z2HRTUYI/PmIqOG+UXvnL5M69SR5EB3bTGJfhgPhjDVG/M5yIdbBBBYHRdH 4/F42o5krlMPHSc96LRhaX8E1H5xcIGh3rwRq7EvP9i5C5O6Ox9cSRj+9kindvkR hBbjtdqXu4idmf9+unSk/NN+I2T+lOLKWeqhF00Wu8TtD9+JIEJbLnqcBoXc9QC7 d6qG3fuqKPyqrplliYgMEWb/GzQXvFnwx+JleBwFZ0nXXl5lGOLzOAVliYDowkZv a0w3qmdC0o46QfLzilGBPbFRLuoGCJ1ptQO9p/cK3esYEkxwicxgkhsAoSFqaWLT tvSt2KC9nC6FmuBpLrhUwK63zZOanHFwuTkVqsP+vQu+uHnDpnxaT4kvo78ckdhX e3DXALjBZLhd =uiHe -END PGP SIGNATURE- >From 9b4813899b1bd0ba9b719f458d794534e9989d22 Mon Sep 17 00:00:00 2001 From: Vincent Bernat Date: Sat, 27 Nov 2021 15:53:33 +0100 Subject: [PATCH] Fix shipped too broad DBus policy. CVE-2021-44225 --- debian/changelog | 6 ++ debian/patches/2063.patch | 38 ++ debian/patches/series | 1 + 3 files changed, 45 insertions(+) create mode 100644 debian/patches/2063.patch diff --git a/debian/changelog b/debian/changelog index 51ee7b25efc1..2491770e8103 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +keepalived (1:2.1.5-0.2+deb11u1) bullseye; urgency=medium + + * Fix shipped too broad DBus policy. CVE-2021-44225. + + -- Vincent Bernat Sat, 27 Nov 2021 15:51:39 +0100 + keepalived (1:2.1.5-0.2) unstable; urgency=medium * Non-maintainer upload. diff --git a/debian/patches/2063.patch b/debian/patches/2063.patch new file mode 100644 index ..ea9d40ec2115 --- /dev/null +++ b/debian/patches/2063.patch @@ -0,0 +1,38 @@ +From 7977fec0be89ae6fe87405b3f8da2f0b5e415e3d Mon Sep 17 00:00:00 2001 +From: Vincent Bernat +Date: Tue, 23 Nov 2021 06:50:59 +0100 +Subject: [PATCH] dbus: fix policy to not be overly broad + +The DBus policy did not restrict the message destination, allowing any +user to inspect and manipulate any property. + +Signed-off-by: Vincent Bernat +--- + keepalived/dbus/org.keepalived.Vrrp1.conf | 13 - + 1 file changed, 8 insertions(+), 5 deletions(-) + +diff --git a/keepalived/dbus/org.keepalived.Vrrp1.conf b/keepalived/dbus/org.keepalived.Vrrp1.conf +index 2b78a575c..b5ced6085 100644 +--- a/keepalived/dbus/org.keepalived.Vrrp1.conf b/keepalived/dbus/org.keepalived.Vrrp1.conf +@@ -3,12 +3,15 @@ + "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> + + +- +- ++ ++ + + +- +- +- ++ ++ ++ + + diff --git a/debian/patches/series b/debian/patches/series index e69de29bb2d1..c6683cd1715d 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -0,0 +1 @@ +2063.patch -- 2.34.0
Bug#999673: bullseye-pu: package lldpd/1.0.11-1
❦ 14 November 2021 19:21 +01, Vincent Bernat: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu [...] I did the upload to bullseye as I think the change is not controversial. -- The lunatic, the lover, and the poet, Are of imagination all compact... -- Wm. Shakespeare, "A Midsummer Night's Dream"
Bug#995817: ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger
❦ 15 November 2021 07:51 +01, Salvatore Bonaccorso: >> I have tried to just not strip the binary, but this produces a quite >> huge binary. I didn't get time to investigate much yet. > > Asked a bit around, and got the following hint from Niels Thykier: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595810#10 > > so that might work, first exclude with -X in dh_strip and then call > strip manually, keeping BEGIN_trigger and END_trigger. > > Niels, thanks for the pointer! Thanks! It works. I have uploaded the new version to unstable. -- Make the coupling between modules visible. - The Elements of Programming Style (Kernighan & Plauger)
Bug#999673: bullseye-pu: package lldpd/1.0.11-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
[ Reason ]
- - Low-severity security issue when receiving SONMP packets.
CVE-2021-43612
- - Annoying bug where LLDP packets are encapsulated in VLAN 0 when some
configuration directives are used. Many implementations reject such
a packet (regression introduced in 1.0.6)
[ Impact ]
- - Someone could crash lldpd from another neighbor if the user enables
SONMP (quite unlikely).
- - People cannot use some configuration directives.
[ Tests ]
- - Both codes are covered by tests in upstream. The SONMP tests are run
during build as well. The VLAN 0 test is not run during build.
[ Risks ]
- - For SONMP, low risk as it is seldomly used and correctly formed
packets are part of the tests run during build.
- - For VLAN 0, the change is trivial, tested upstream and reported OK by two
users.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
- - SONMP: there was a confusion about the size of a packet. The same
variable was used for the payload size and for checking the size
with Ethernet headers.
- - VLAN 0: when changing some settings, a struct containing the changed
settings is transmitted. -1 was used to say "no change" but it was
interpreted as a change.
[ Other info ]
- - Security team is OK to fix the security issue in a point release.
- - I don't think this is worth fixing the SONMP issue in Buster, but I
can do that too. The VLAN issue is not present.
-BEGIN PGP SIGNATURE-
iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmGRU44SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5++gP/jK+rA7DgjxgweFrlUezPB39QSg6wcmu
9YrUO8wyjSzZ0A51Gfh/afyJAKRKehy3tD/nWvrQumn5ZkYXMhVbock5zJbgnTmo
1ndd2CtIOlpdSceqmnxX83Qt5qj7yHLWCzyAYg+ujgO1Su/IrE6GwwWr3+OBJQdN
lwLrbDzIe+Xv+4sYLLhWjO1ApVHpJmLJYYywBWug6YkTa9hx1wixPGm76G1Z4tvc
312L+9uwJqdp85Nb8w29VgBx8nDOWZS54FaimnggmGk895beQdI4wUCGfrJ/Tqkt
K4emDeOUv5pUudDYNU98a0byf7Ahif+QVZLS0w9p32uHd7qtr1ZwkmhcO2I0W0jA
EWIC7PW3qyQqa8SrD068Sx9jEhCt69uJaQyDUV38DbCmNFjip4oK607XeLuh/WwC
R6TI3iMro3T03QSzyYyFvWLJpL0n/xHtoMb0UXWY+KE38uOQQ1Fdv3JkvxxI6q6Z
8FhpTYr1ONE9uj577aMj3bX9BkxdVKKjy48bLEkHhTd1KS/FOLpWMmnlRVNBAr8t
KDn09xcsxU+anIGunFwrATqH8sBFOqO0gvr+ylgyswQiW3L8WWM2uyG1+UoO/AeW
lwMHk+6WUuejhB/7PzA0Wcv5zfgkwahZRf2zN6ohON6IaVR6Pbn0+lSYU5rlramB
dsd1jEbkXZ36
=W7Cl
-END PGP SIGNATURE-
>From d70b8be04c6d8638e6f2cd612a07e73992fa0798 Mon Sep 17 00:00:00 2001
From: Vincent Bernat
Date: Sun, 14 Nov 2021 15:42:12 +0100
Subject: [PATCH] Tentative security update for Bullseye
---
debian/changelog | 8 ++
...et-VLAN-tag-if-client-did-not-set-it.patch | 27 ++
...-overflow-when-reading-SONMP-packets.patch | 93 +++
debian/patches/series | 2 +
4 files changed, 130 insertions(+)
create mode 100644
debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
create mode 100644
debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch
diff --git a/debian/changelog b/debian/changelog
index bb87d8129f9e..68ae7b91d22d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lldpd (1.0.12-1+deb11u1) bullseye; urgency=high
+
+ * d/patches: sonmp: fix heap overflow when reading SONMP packets.
+CVE-2021-43612
+ * d/patches: client: do not set VLAN tag if client did not set it
+
+ -- Vincent Bernat Sun, 14 Nov 2021 15:41:59 +0100
+
lldpd (1.0.12-1) unstable; urgency=medium
* New upstream release.
diff --git
a/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
new file mode 100644
index ..1f65986ae27e
--- /dev/null
+++
b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
@@ -0,0 +1,27 @@
+From 261afbe371ab316a4bf710338f6d9183a01e083f Mon Sep 17 00:00:00 2001
+From: Vincent Bernat
+Date: Wed, 29 Sep 2021 12:02:15 +0200
+Subject: [PATCH] client: do not set VLAN tag if client did not set it
+
+This fixes a bug where frames could be tagged with VLAN 0 after client
+configuration.
+---
+ src/daemon/client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/daemon/client.c b/src/daemon/client.c
+index b4a08aae80a8..0d0f3ea37a19 100644
+--- a/src/daemon/client.c
b/src/daemon/client.c
+@@ -390,7 +390,7 @@ _client_handle_set_port(struct lldpd *cfg,
+ port->p_disable_rx = port->p_disable_tx = 1;
+ break;
+ }
+- if (set->vlan_tx_enabled >= -1) {
++ if (set->vlan_tx_enabled > -1) {
+ port->p_vlan_tx_enabled = set->vlan_tx_enabled;
Bug#995817: ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger
❦ 13 November 2021 15:06 +01, Salvatore Bonaccorso: >> > In fact, it does not happen if you have debug symbols. My patch does not >> > work anymore either and the previous upload did not fix this bug. Some >> > distributions work around that by asking "strip" to keep BEGIN_trigger. >> > It seems we cannot do that easily with dh_strip. >> >> Confirmed! >> >> No idea on the solution though. > > Any idea on how to bring that back? I have tried to just not strip the binary, but this produces a quite huge binary. I didn't get time to investigate much yet. -- Why is it that we rejoice at a birth and grieve at a funeral? It is because we are not the person involved. -- Mark Twain, "Pudd'nhead Wilson's Calendar"
Bug#964934: cookiecutter: Upgrade to version 1.7.x
❦ 12 November 2021 12:52 -04, Wesley Schwengle: >>> In December 2019 version 1.7.0 was released and in April 2020 1.7.1 and >>> 1.7.2 were released. It adds a very useful feature: >>> >>>https://cookiecutter.readthedocs.io/en/1.7.2/advanced/directories.html >>> >>> I would like to make use of this. Could you bump the version the debian >>> unstable branch? >> I am missing a recent enough version of python3-recommonmark due to >> bug >> #955180. > > It seems that bug has been resolved. Could you perhaps see if the > version bump is now possible? I have uploaded 1.7.3. -- Modularise. Use subroutines. - The Elements of Programming Style (Kernighan & Plauger)
Bug#997218: keepalived: FTBFS: if.h:44:5: error: redeclaration of enumerator ‘IFF_UP’
❦ 23 October 2021 21:13 +02, Lucas Nussbaum: > During a rebuild of all packages in sid, your package failed to build > on amd64. This bug has been fixed in later versions. I have uploaded 2.2.4-0.1 to DELAYED/10. Here is the diff compared to what is actually in master on Salsa. diff --git a/debian/changelog b/debian/changelog index a11fb75cca2d..f9c585865a56 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,9 +1,17 @@ -keepalived (1:2.2.1-1) UNRELEASED; urgency=medium +keepalived (1:2.2.4-0.1) unstable; urgency=medium + [ Alexander Wirt ] * [61cbc18] New upstream version 2.2.1 * [ecf662d] Keepalived has now support for systemd notify - -- Alexander Wirt Mon, 25 Jan 2021 09:04:08 +0100 + [ Vincent Bernat ] + * Non-maintainer upload. + * New upstream version 2.2.4. Closes: #980563. +- Fix FTFBS. Closes: #997218. + * d/rules: enable systemd as an init to get systemd features. + * d/rules: remove use of custom-specified include directory for kernel. + + -- Vincent Bernat Sun, 07 Nov 2021 17:57:44 +0100 keepalived (1:2.1.5-0.2) unstable; urgency=medium diff --git a/debian/include/linux/linux/ip_vs.h b/debian/include/linux/linux/ip_vs.h deleted file mode 100644 index 4102ddcb4e14.. --- a/debian/include/linux/linux/ip_vs.h +++ /dev/null @@ -1,474 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -/* - * IP Virtual Server - * data structure and functionality definitions - */ - -#ifndef _IP_VS_H -#define _IP_VS_H - -#include /* For __beXX types in userland */ - -#define IP_VS_VERSION_CODE 0x010201 -#define NVERSION(version) \ - (version >> 16) & 0xFF, \ - (version >> 8) & 0xFF, \ - version & 0xFF - -/* - * Virtual Service Flags - */ -#define IP_VS_SVC_F_PERSISTENT 0x0001 /* persistent port */ -#define IP_VS_SVC_F_HASHED 0x0002 /* hashed entry */ -#define IP_VS_SVC_F_ONEPACKET 0x0004 /* one-packet scheduling */ -#define IP_VS_SVC_F_SCHED1 0x0008 /* scheduler flag 1 */ -#define IP_VS_SVC_F_SCHED2 0x0010 /* scheduler flag 2 */ -#define IP_VS_SVC_F_SCHED3 0x0020 /* scheduler flag 3 */ - -#define IP_VS_SVC_F_SCHED_SH_FALLBACK IP_VS_SVC_F_SCHED1 /* SH fallback */ -#define IP_VS_SVC_F_SCHED_SH_PORT IP_VS_SVC_F_SCHED2 /* SH use port */ - -/* - * Destination Server Flags - */ -#define IP_VS_DEST_F_AVAILABLE 0x0001 /* server is available */ -#define IP_VS_DEST_F_OVERLOAD 0x0002 /* server is overloaded */ - -/* - * IPVS sync daemon states - */ -#define IP_VS_STATE_NONE 0x /* daemon is stopped */ -#define IP_VS_STATE_MASTER 0x0001 /* started as master */ -#define IP_VS_STATE_BACKUP 0x0002 /* started as backup */ - -/* - * IPVS socket options - */ -#define IP_VS_BASE_CTL (64+1024+64) /* base */ - -#define IP_VS_SO_SET_NONE IP_VS_BASE_CTL /* just peek */ -#define IP_VS_SO_SET_INSERT (IP_VS_BASE_CTL+1) -#define IP_VS_SO_SET_ADD (IP_VS_BASE_CTL+2) -#define IP_VS_SO_SET_EDIT (IP_VS_BASE_CTL+3) -#define IP_VS_SO_SET_DEL (IP_VS_BASE_CTL+4) -#define IP_VS_SO_SET_FLUSH (IP_VS_BASE_CTL+5) -#define IP_VS_SO_SET_LIST (IP_VS_BASE_CTL+6) -#define IP_VS_SO_SET_ADDDEST (IP_VS_BASE_CTL+7) -#define IP_VS_SO_SET_DELDEST (IP_VS_BASE_CTL+8) -#define IP_VS_SO_SET_EDITDEST (IP_VS_BASE_CTL+9) -#define IP_VS_SO_SET_TIMEOUT (IP_VS_BASE_CTL+10) -#define IP_VS_SO_SET_STARTDAEMON (IP_VS_BASE_CTL+11) -#define IP_VS_SO_SET_STOPDAEMON (IP_VS_BASE_CTL+12) -#define IP_VS_SO_SET_RESTORE(IP_VS_BASE_CTL+13) -#define IP_VS_SO_SET_SAVE (IP_VS_BASE_CTL+14) -#define IP_VS_SO_SET_ZERO (IP_VS_BASE_CTL+15) -#define IP_VS_SO_SET_MAX IP_VS_SO_SET_ZERO - -#define IP_VS_SO_GET_VERSION IP_VS_BASE_CTL -#define IP_VS_SO_GET_INFO (IP_VS_BASE_CTL+1) -#define IP_VS_SO_GET_SERVICES (IP_VS_BASE_CTL+2) -#define IP_VS_SO_GET_SERVICE (IP_VS_BASE_CTL+3) -#define IP_VS_SO_GET_DESTS (IP_VS_BASE_CTL+4) -#define IP_VS_SO_GET_DEST (IP_VS_BASE_CTL+5) /* not used now */ -#define IP_VS_SO_GET_TIMEOUT (IP_VS_BASE_CTL+6) -#define IP_VS_SO_GET_DAEMON (IP_VS_BASE_CTL+7) -#define IP_VS_SO_GET_MAX IP_VS_SO_GET_DAEMON - - -/* - * IPVS Connection Flags - * Only flags 0..15 are sent to backup server - */ -#define IP_VS_CONN_F_FWD_MASK 0x0007 /* mask for the fwd methods */ -#define IP_VS_CONN_F_MASQ 0x /* masquerading/NAT */ -#define IP_VS_CONN_F_LOCALNODE 0x0001 /* local node */ -#define IP_VS_CONN_F_TUNNEL 0x0002 /* tunneling */ -#define IP_VS_CONN_F_DROUTE 0x0003 /* direct routing */ -#define IP_VS_CONN_F_BYPASS 0x0004 /* cache bypass */ -#define IP_VS_CONN_F_SYNC 0x0020 /* entry created by sync */ -#define IP_VS_CONN_F_HASHED 0x0040 /* hashed entry */ -#define IP_VS_CONN_F_NOOUTPUT 0x0080 /* no output packets */ -#define IP_VS_CONN_F_INACTIVE 0x0100 /* not established */ -#define IP_VS_CONN_F_OUT_SEQ 0x0200 /* must do output seq adjust */ -#define IP_VS_CONN_F_IN_SEQ 0x0400 /* must do input seq adjust */ -#define IP_VS_CONN_F_SEQ_MASK 0x0600 /* in/out sequence mask */ -#define IP_VS_CONN_F_NO_CPORT 0x0
Bug#998108: Tracking this bug down
❦ 4 November 2021 23:39 +01, Eugen Dedu: > Maybe I am wrong, but, for me, the simplest method to track this bug > down is to check the changes between the two versions, 93.0 and > 93.0-1+b1. Firefox code has not changed, only one or some libraries > it depends on. I thought that the only change is in libvpx version, > but, surprisingly, a previous comment mentions that rebuilding firefox > with old vpx (libvpx6) still exhibits the bug. I think that libc6 is > out of question, because the last package is 19 Sep, too old wrt this > bug; the same for gcc-11, the last package being on 21 Oct. Doesn't > this (checking the changes) sound like a good approach to find the > cause of the problem? There are a lot of changes between the two builds: - automake (= 1:1.16.5-1), + automake (= 1:1.16.4-2), - bash (= 5.1-3+b2), + bash (= 5.1-3+b1), - bsdextrautils (= 2.37.2-4), - bsdutils (= 1:2.37.2-4), + bsdextrautils (= 2.37.2-3), + bsdutils (= 1:2.37.2-3), - cargo (= 0.57.0-3), + cargo (= 0.47.0-3+b1), - cpp (= 4:11.2.0-2), - cpp-11 (= 11.2.0-10), - dash (= 0.5.11+git20210120+802ebd4-2), - dbus (= 1.12.20-3), - dbus-bin (= 1.12.20-3), - dbus-daemon (= 1.12.20-3), - dbus-session-bus-common (= 1.12.20-3), - dbus-system-bus-common (= 1.12.20-3), - dbus-user-session (= 1.12.20-3), + cpp (= 4:10.2.1-1), + cpp-10 (= 10.3.0-11), + dash (= 0.5.11+git20210120+802ebd4-1), + dbus (= 1.12.20-2), + dbus-user-session (= 1.12.20-2), - debconf (= 1.5.78), + debconf (= 1.5.77), - dh-strip-nondeterminism (= 1.12.0-2), + dh-strip-nondeterminism (= 1.12.0-1), - g++ (= 4:11.2.0-2), - g++-11 (= 11.2.0-10), - gcc (= 4:11.2.0-2), + g++ (= 4:10.2.1-1), + g++-10 (= 10.3.0-11), + gcc (= 4:10.2.1-1), + gcc-10 (= 10.3.0-11), - gcc-11 (= 11.2.0-10), - gcc-11-base (= 11.2.0-10), + gcc-11-base (= 11.2.0-8), - lib32gcc-s1 (= 11.2.0-10), - lib32stdc++6 (= 11.2.0-10), + lib32gcc-s1 (= 11.2.0-8), + lib32stdc++6 (= 11.2.0-8), - libapparmor1 (= 3.0.3-5), + libapparmor1 (= 3.0.3-2), - libasan6 (= 11.2.0-10), + libasan6 (= 11.2.0-8), - libatomic1 (= 11.2.0-10), + libatomic1 (= 11.2.0-8), - libaudit-common (= 1:3.0.6-1), - libaudit1 (= 1:3.0.6-1), + libaudit-common (= 1:3.0.5-1), + libaudit1 (= 1:3.0.5-1), - libblkid-dev (= 2.37.2-4), - libblkid1 (= 2.37.2-4), + libblkid-dev (= 2.37.2-3), + libblkid1 (= 2.37.2-3), - libc-ares2 (= 1.18.1-1), + libc-ares2 (= 1.17.2-1), - libcc1-0 (= 11.2.0-10), + libcc1-0 (= 11.2.0-8), - libcryptsetup12 (= 2:2.4.1-1), + libcryptsetup12 (= 2:2.4.0-1), - libdatrie-dev (= 0.2.13-2), - libdatrie1 (= 0.2.13-2), + libdatrie-dev (= 0.2.13-1), + libdatrie1 (= 0.2.13-1), - libdbus-1-3 (= 1.12.20-3), - libdbus-1-dev (= 1.12.20-3), + libdbus-1-3 (= 1.12.20-2), + libdbus-1-dev (= 1.12.20-2), - libdeflate-dev (= 1.8-1), - libdeflate0 (= 1.8-1), + libdeflate-dev (= 1.7-2), + libdeflate0 (= 1.7-2), - libegl-mesa0 (= 21.2.4-1), + libegl-mesa0 (= 21.2.3-1), - libegl1-mesa-dev (= 21.2.4-1), + libegl1-mesa-dev (= 21.2.3-1), - libepoxy-dev (= 1.5.9-2), - libepoxy0 (= 1.5.9-2), + libepoxy-dev (= 1.5.9-1), + libepoxy0 (= 1.5.9-1), - libexpat1 (= 2.4.1-3), - libexpat1-dev (= 2.4.1-3), - libffi-dev (= 3.4.2-3), - libffi8 (= 3.4.2-3), - libfile-stripnondeterminism-perl (= 1.12.0-2), + libexpat1 (= 2.4.1-2+b1), + libexpat1-dev (= 2.4.1-2+b1), + libffi-dev (= 3.4.2-2), + libffi7 (= 3.3-6), + libffi8 (= 3.4.2-2), + libfile-stripnondeterminism-perl (= 1.12.0-1), - libfreetype-dev (= 2.11.0+dfsg-1), - libfreetype6 (= 2.11.0+dfsg-1), - libfreetype6-dev (= 2.11.0+dfsg-1), + libfreetype-dev (= 2.10.4+dfsg-1), + libfreetype6 (= 2.10.4+dfsg-1), + libfreetype6-dev (= 2.10.4+dfsg-1), - libgbm1 (= 21.2.4-1), + libgbm1 (= 21.2.3-1), - libgcc-11-dev (= 11.2.0-10), - libgcc-s1 (= 11.2.0-10), + libgcc-s1 (= 11.2.0-8), - libgdbm-compat4 (= 1.22-1), - libgdbm6 (= 1.22-1), + libgdbm-compat4 (= 1.21-1), + libgdbm6 (= 1.21-1), - libgl1-mesa-dri (= 21.2.4-1), - libglapi-mesa (= 21.2.4-1), + libgl1-mesa-dri (= 21.2.3-1), + libglapi-mesa (= 21.2.3-1), - libglib2.0-0 (= 2.70.0-3), - libglib2.0-bin (= 2.70.0-3), - libglib2.0-data (= 2.70.0-3), - libglib2.0-dev (= 2.70.0-3), - libglib2.0-dev-bin (= 2.70.0-3), + libglib2.0-0 (= 2.70.0-1+b1), + libglib2.0-bin (= 2.70.0-1+b1), + libglib2.0-data (= 2.70.0-1), + libglib2.0-dev (= 2.70.0-1+b1), + libglib2.0-dev-bin (= 2.70.0-1+b1), - libglx-mesa0 (= 21.2.4-1), + libglx-mesa0 (= 21.2.3-1), - libgomp1 (= 11.2.0-10), + libgomp1 (= 11.2.0-8), - libisl23 (= 0.24-2), - libitm1 (= 11.2.0-10), + libisl23 (= 0.23-1), + libitm1 (= 11.2.0-8), - libllvm12 (= 1:12.0.1-15), - libllvm13 (= 1:13.0.0-8), - liblsan0 (= 11.2.0-10), + libllvm12 (= 1:12.0.1-9), + libllvm13 (= 1:13.0.0-2), + liblsan0 (= 11.2.0-8), - libmount-dev (= 2.37.2-4), - libmount1 (= 2.37.2-4), - libmpc3 (= 1.2.1-1), + libmount-dev (= 2.37.2-3), + libmount1 (= 2.37.2-3), + libmpc3 (= 1.2.0-1), - libnode72 (= 12.22.7~dfsg-2), + libnode72 (= 12.22.5~dfsg-5), - libobjc4 (= 11.2.0-10), + libobjc4 (= 11.2.0-8), - libp11-kit0 (= 0.24.0-5), + libp11-kit0 (= 0.24.0-3), - libpam-sys
Bug#990821: aptly fails to run if both gnupg2 and gnupg1 are installed
❦ 8 July 2021 16:51 +02, Christoph Berg: > As soon as gpg1 (package gnupg1) and gpgv (from gnupg 2) are > installed, aptly fails to run. I think aptly should "Conflicts: > gnupg1", but maybe there is a better fix. This also happens when gpgv1 is installed. -- Don't sacrifice clarity for small gains in "efficiency". - The Elements of Programming Style (Kernighan & Plauger)
Bug#995823: bullseye-pu: package kodi/2:19.2+dfsg1-1~deb11u1 (pre-upload unblock bug)
❦ 7 October 2021 16:24 GMT, Vasyl Gello: > FYI, kodi 2:19.1+dfsg2-2_19.2+dfsg1-1 is in unstable :) I have been running a version rebuilt for Bullseye since a few days (notably due to issues with HD audio which are fixed in this release) and it works fine for me. -- For a light heart lives long. -- Shakespeare, "Love's Labour's Lost"
Bug#995817: ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger
❦ 6 October 2021 15:03 +02, Salvatore Bonaccorso:
> After updating bpftrace to 0.13.0-1 in unstable, I noticed invocation
> using a BEGIN block do not work anymore, the BEGIN_trigger symbol
> cannot be resolved, basically reproducible with the minimal:
>
> # bpftrace -e 'BEGIN { }'
> Attaching 1 probe...
> ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger
>
> Samewise for the END_trigger.
>
> Not further checked on the issue.
>
> p.s.: please downgrade if you think important is not appropriate.
In fact, it does not happen if you have debug symbols. My patch does not
work anymore either and the previous upload did not fix this bug. Some
distributions work around that by asking "strip" to keep BEGIN_trigger.
It seems we cannot do that easily with dh_strip.
--
Don't diddle code to make it faster - find a better algorithm.
- The Elements of Programming Style (Kernighan & Plauger)
Bug#930557: i3-gaps RFS/ITP
❦ 3 October 2021 09:16 +02, Michael Stapelberg: > I will stress one more time that what we need here is not a one-time > sponsorship offer, but a multi-year commitment for maintaining the > i3-gaps package in Debian. Let's hear from antisocrates. I can offer a multi-year commitment for sponsorship and take over maintainance if needed. I can also maintain it myself. I suppose you would favor i3-gaps to conflict with i3-wm instead of trying to be co-installable (with or without alternatives as the difference is limited to a few binaries and I think this does not include i3-msg). -- Must I hold a candle to my shames? -- William Shakespeare, "The Merchant of Venice"
Bug#930557: i3-gaps RFS/ITP
❦ 3 October 2021 08:48 +02, Michael Stapelberg: > I still think it’d be better to spend time on merging gaps rather than > packaging gaps, > but it seems like nobody has the skill set and/or motivation. This is a very different skillset from packaging. > Is there someone who would continuously maintain i3-gaps in Debian? > I wouldn’t want that package to diverge from upstream i3 in terms of which > version is available in Debian. Alternatively, src:i3-wm could build both i3-wm and i3-gaps. It adds extra work on existing maintainers but maybe you and Jakob would be OK with that? I can propose a patch for that if it helps. -- Use recursive procedures for recursively-defined data structures. - The Elements of Programming Style (Kernighan & Plauger)
Bug#930557: i3-gaps RFS/ITP
❦ 17 June 2019 18:30 +02, Michael Stapelberg: > Ingo will outline what needs to be done to get i3-gaps into a mergable > state, so that we can eventually bring these features to all i3 users. > > For the time being, our recommendation is to NOT add i3-gaps to Debian or > any other Linux distribution. Instead, if you have time and motivation, > please consider helping improve i3-gaps with the goal of a merge. It seems there is not much progress on this front. The issue on GitHub does not show activity either. As other popular desktop distributions (Fedora, openSuSE, Arch and Manjaro) are providing a i3-gaps package, maybe an i3-gaps package in Debian could be reconsidered? I would gladly sponsor it if there is no strong opposition from i3 maintainers. -- Write and test a big program in small pieces. - The Elements of Programming Style (Kernighan & Plauger)
Bug#994865: Delayed start due to Pipewire not running
❦ 23 September 2021 17:09 +02, Vincent Bernat: > Let me reboot at the end of the day with just xdg-desktop-portal in > verbose mode, it may be enough to find the cause. If not, I will apply > your other tricks. OK, a bit late, but on verbose, I get: Sep 30 07:57:56 chocobo xdg-desktop-portal[1730]: XDP: providing portal org.freedesktop.portal.FileChooser Sep 30 07:57:56 chocobo xdg-desktop-portal[1730]: XDP: Falling back to gtk.portal for org.freedesktop.impl.portal.AppChooser Sep 30 07:58:21 chocobo xdg-desktop-portal[1730]: XDP: Failed to create FileManager proxy: Error calling StartServiceByName for org.freedesktop.FileManager1: Timeout was reached Sep 30 07:58:21 chocobo xdg-desktop-portal[1730]: XDP: providing portal org.freedesktop.portal.OpenURI Sep 30 07:58:21 chocobo xdg-desktop-portal[1730]: XDP: Falling back to gtk.portal for org.freedesktop.impl.portal.Print I have Thunar installed and I think there may be just a dependency loop: Sep 30 07:58:21 chocobo dbus-daemon[1433]: [session uid=1000 pid=1433] Successfully activated service 'org.freedesktop.portal.Desktop' Sep 30 07:58:22 chocobo dbus-daemon[1433]: [session uid=1000 pid=1433] Successfully activated service 'org.freedesktop.FileManager1' 08:07 ❱ journalctl -b0 --user-unit=thunar.service -- Journal begins at Sun 2021-08-01 16:26:21 CEST, ends at Thu 2021-09-30 08:05:07 CEST. -- Sep 30 07:57:56 chocobo systemd[1402]: Starting Thunar file manager... Sep 30 07:58:22 chocobo systemd[1402]: Started Thunar file manager. So, the bug may be more in Thunar. This looks like: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929490 https://www.reddit.com/r/swaywm/comments/ptwd6p/thunar_and_xdgdesktopportal_block_each_other/ Personally, I don't care much about org.freedesktop.FileManager1 and I would prefer this dbus service to not be provided at all. I'll try to mask thunar.service to avoid this. -- I do desire we may be better strangers. -- William Shakespeare, "As You Like It"
Bug#994865: Delayed start due to Pipewire not running
❦ 23 September 2021 15:37 +01, Simon McVittie: > I see from your initial bug report that you are using systemd as pid 1, > systemd --user, and dbus-user-session (i.e. dbus-daemon --session is > running as a systemd --user unit). Is that correct? Yes. > What desktop environment are you using? Or if you have made your own > desktop environment from individual components, what are the major > components like window manager and session manager (if any)? lightdm with autologin to Xsession which chains to systemd --user which spawns i3 and various other stuff. > It might be helpful to run the affected GTK app with G_MESSAGES_DEBUG=all > in the environment. This doesn't work for gnome-terminal because > gnome-terminal is weird, but gnome-terminal -vv is close enough. I am using my own terminal and since it is a "GTK application" (it has a daemon mode), I think it may be like gnome-terminal, but the very first terminal is "normal". > Most components that talk to xdg-desktop-portal only do so when they find > that they're running as a Flatpak app, or maybe some other sandboxed app > framework like Snap. Just to rule some things out: are you launching > Flatpak and/or Snap apps? Or if not, do you have environment variable > GTK_USE_PORTAL set? No Flatpak on boot. I am using some later. Let me reboot at the end of the day with just xdg-desktop-portal in verbose mode, it may be enough to find the cause. If not, I will apply your other tricks. -- If you tell the truth you don't have to remember anything. -- Mark Twain
Bug#994865: Delayed start due to Pipewire not running
❦ 23 September 2021 10:08 +01, Simon McVittie: >> Since upgrading to 1.10.1-1, xdg-desktop-portal service takes a lot of >> time to start on a desktop not using Pipewire. > > Looking at the diff, I don't understand why this particular upgrade > would trigger this: the only Pipewire-related change was to add a 10 > second timeout on some operations, instead of waiting indefinitely. > > Are you sure this is triggered by upgrading xdg-desktop-portal, and not > by upgrading some related package - perhaps x-d-p-gtk or pipewire? I don't have Pipewire installed (but it was installed at some point). I see that on a previous boot, the same error was here but did not introduce a delay. > The 25 second delay you reported is the default timeout for D-Bus method > calls, so I suspect what you are seeing here is a D-Bus method call that > never gets a reply and times out. > > I'm less confident than you are that the missing Pipewire service is the > root cause here. I think the log you reported is equally consistent with > some unrelated D-Bus method call starting, timing out 25 seconds later, > and then x-d-p proceeding through its remaining startup tasks, one of > which is to try to talk to Pipewire to decide whether it can provide > video-related portals (screen-sharing and remote-desktop). > > It might be helpful to run > > /usr/libexec/xdg-desktop-portal --verbose --replace > > or even > > G_MESSAGES_DEBUG=all /usr/libexec/xdg-desktop-portal --verbose --replace > > and report what the output is, and where in the output the 25 second delay > happened. Unfortunately, it seems the problem only happens on boot. I have added --verbose for the next boot and I'll keep you posted. > Doing the same for xdg-desktop-portal-gtk (or whatever other backend you > are using, if not -gtk) could also provide useful information; or watching > the output of `dbus-monitor --session` might also be helpful, although > there will be a lot of noise from unrelated D-Bus operations in that. xdg-desktop-portal-gtk started without delay and its log does not have any error. >> In turn, this seems to delay many other things that rely on this >> service. For example, VTE terminals are delayed. > > I would have expected xdg-desktop-portal to start up at most once per > GUI login session, so I would have expected you to only see a delay > once. Yes, the delay happens only once. > If you're seeing a delay in opening VTE terminals, one possible reason > is that when /etc/profile.d/flatpak.sh runs > `GIO_USE_VFS=local flatpak --installations`, it might be doing IPC to some > service that takes a long time. > > If you run > > G_MESSAGES_DEBUG=all flatpak --installations -vv > > is that also delayed, and are there any clues in its output? The terminal window does is not displayed. The delay is related to the fact that VTE terminals (like Gnome Terminal) are "GTK apps" and they synchronize with DBus to find an existing instance if any. For some reason, this requires a desktop portal. So, I'll reboot before the end of the week and I'll tell you what's in the logs. -- Test programs at their boundary values. - The Elements of Programming Style (Kernighan & Plauger)
Bug#994890: New upstream version (5.7.4)
Package: maim Version: 5.6.3-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! Could you please upload a new version? 5.6.3 is getting a bit old and I am running into an annoying bug that may be fixed in a more recent version. Thanks! - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-1-amd64 (SMP w/12 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages maim depends on: ii libc62.32-4 ii libgcc-s111.2.0-7 ii libjpeg62-turbo 1:2.0.6-4 ii libpng16-16 1.6.37-3 ii libstdc++6 11.2.0-7 ii libx11-6 2:1.7.2-2+b1 ii libxcomposite1 1:0.4.5-1 ii libxext6 2:1.3.4-1 ii libxfixes3 1:5.0.3-2 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii slop 7.5-1+b1 maim recommends no packages. maim suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmFLYPgSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5gvgP/R2B3vthPg67Ch5dUEcF6i7CNEZhfHSu Nmxb8LyaAPHM682dTvBbb0lK6Dh2PjUIBZLnKs1rc8kD1RgnVlf5BYpyvO0E/hin PlmG/XK3vRzAkXNagO6KDHm9n+B1p9gTmfCzyXbzJP7lgthZgwP5pd+qdtg3nS4n NWIY+kqUGFV6eAbWO2CIrUrA/VYCufP2spNR7aUgVFNRciklYxtxJD6/0zNVXu1n fpC+1JBQnER7rg8gCZTChEuIMeNa1BYPTvS9WBVPEcXMKyOEoQzCDN1OcuqoaaLX g4XxlCU+KwKd3AA2JRKivb0Qb+S55uqqeCoiVkxm8N4TU4KqvdUQe2fSKHwVQrtI gb4GDZK+jEYXOEzf7FqHfhvfV5Gt3Kpw3KmJcQXqh6Kszq2j4zsox7jvV+dJ28Kv Qc+jPMZE5ltkqEhSCM8HM/mH5v1bNAB8haKAPQJ2j9DKst2eZq2EfNKctRgjMxIX pwjrnumOrArBnSGaccNX4mmhboxiNnSqD3JgvLLFlsYWCYzqh18YfXDc6sAZL8zN dV3aQMNsXCcdmgsVi3m/vbYnATIR2OQ224rJan8n7QAPEdiaNOrssn5Ei5u9e+C/ yEgBIOGODObiJFPuAwzADoo64q9nEXZsI4kwpl3ce70Ytr4HyY8d+sQ+5xyk5GRU 33xCAxiNWhgA =16HM -END PGP SIGNATURE-
Bug#980300: libcbor: Please upgrade to new version 0.8.0
❦ 21 September 2021 14:54 -04, Nicolas Mora: > Friendly ping request for this bug. > If you need help, I'll be happy to help you with this upgrade. Done. It is waiting in NEW. -- Identify bad input; recover if possible. - The Elements of Programming Style (Kernighan & Plauger)
Bug#994865: Delayed start due to Pipewire not running
Package: xdg-desktop-portal Version: 1.10.1-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! Since upgrading to 1.10.1-1, xdg-desktop-portal service takes a lot of time to start on a desktop not using Pipewire. 09:52 ❱ journalctl -b0 --user-unit=xdg-desktop-portal - -- Journal begins at Sat 2021-07-31 17:43:34 CEST, ends at Wed 2021-09-22 09:50:26 CEST. -- Sep 22 09:39:02 neo systemd[1655]: Starting Portal service... Sep 22 09:39:27 neo xdg-desktop-portal[2274]: context 0x56081dd4ed40: can't load config client.conf: No such file or directory Sep 22 09:39:27 neo xdg-desktop-portal[2274]: context 0x56081dd4ed40: can't load config client.conf: No such file or directory Sep 22 09:39:27 neo xdg-desktop-por[2274]: Failed connect to PipeWire: Couldn't create PipeWire context Sep 22 09:39:27 neo systemd[1655]: Started Portal service. In turn, this seems to delay many other things that rely on this service. For example, VTE terminals are delayed. - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-1-amd64 (SMP w/12 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xdg-desktop-portal depends on: ii bubblewrap0.5.0-1 ii dbus-user-session [default-dbus-session-bus] 1.12.20-2 ii dbus-x11 [dbus-session-bus] 1.12.20-2 ii fuse3 [fuse] 3.10.5-1 ii libc6 2.32-4 ii libfuse2 2.9.9-5 ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2 ii libglib2.0-0 2.70.0-1 ii libjson-glib-1.0-01.6.6-1 ii libpipewire-0.3-0 0.3.36-1 xdg-desktop-portal recommends no packages. xdg-desktop-portal suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmFK4UMSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5PdQP/2ucWQj0hy8lUcziq0ipJAXrA4gAgw/4 0ItN/TXnFvjFEphm8GNf+phCX1GMMpZ8hDsd0GSrh075heabLeslT5SgTTzf66Hj uTXCrtGyCWRfy4Gejs24FqfUbRthWJKUfLfhoWzwdmltxrVCupaMUVnUmGHVnc/+ bb17WtIGBRgXuVn7i3o9HbmyeN/g52j9hwq8r01gdpr20jtlSgntj8JrHVZa0FIy d9Le4GCDEtJixvoS3Rd34anLOvUituma9ykrGYR+H3HGSKCTZYBMGlG5USUMxvyz p+GaBP+/RRUyW4ylCtack9VdJxlMFqbM5qJX/KZOTQGOEp82NqCHirUtoVvHV1NO H7q9KZ6a5zZQ7ow+orfZ68pHnlZW0is1JLr2ZQM5S/lONsUFlmXlfnTvk/WzjtRf wO7WE85eg1tHtgpgxzytZTl/9LAV7yeY0UL6hA6iNRwGjAm8nD6BwvUaBcOelhMU zR+8pzDoFPRmfVxHQeJEfOTWI7q6RMdXOonUF3t+v1h0MqRN+MWkdjqcBIdPDN6g mWwaOr4gr7Y+c5pBrvO0DzoegpiHEkC8LDF1cVSeXTJDbOoSGdR3fPCvdZEoPBTD /BTOZ2foZgZfHiziGoACis/C9iPB7vWRaKmtumzi2UZvqQ6R1IffbZca2Ljgnd7H RwoM33yporRa =g1Mf -END PGP SIGNATURE-
Bug#992149: firmware-sof: Internal microphone (DMIC) not working on Lenovo Thinkpad 13S
❦ 21 September 2021 18:03 +03, Andrei POPESCU: >> The work-around is presented here: >> https://github.com/thesofproject/linux/issues/2460#issuecomment-779212719 >> >> In a nutshell, a binary blob is offered there to replace the file >> sof-hda-generic-2ch.tplg in firmware-sof-signed. >From my understand, this would break all laptops where the mic is on PDM0. It seems the infrastructure to detect PDM0 or PDM1 is not here yet. -- Make sure every module hides something. - The Elements of Programming Style (Kernighan & Plauger)
Bug#977738: rofi: New upstream release 1.6.1
❦ 19 December 2020 20:18 GMT, Ayose: > A new version was published: > > https://github.com/davatorium/rofi/releases/tag/1.6.1 > > Version 1.6.0 is very interesting because it adds a new [1]script mode > that allows more powerful selectors. > > I tried to build the package using the current [2]debian directory for > the package in Sid and it seems to work with no changes. > > 1. https://github.com/davatorium/rofi/blob/next/doc/rofi-script.5.markdown > 2. https://deb.debian.org/debian/pool/main/r/rofi/rofi_1.5.4-1.debian.tar.xz I am also interested by updating Rofi in Debian. Jason, do you plan to continue working on Rofi? I can sponsor the uploads if needed. -- Use recursive procedures for recursively-defined data structures. - The Elements of Programming Style (Kernighan & Plauger)
Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)
Package: systemd Version: 247.9-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! After upgrading to libc6 2.32-1, some services are unable to restart. In my case, systemd-resolved, systemd-timesyncd and colord. Using "systemctl daemon-reexec" fixes the issue. Unsure if there is really something to be fixed but as I didn't find anything about that, a bug report may help others. I suppose the problem is related to NSS. Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time Synchronization... Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service: Failed to determine user credentials: No such process Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service: Failed at step USER spawning /lib/systemd/systemd-timesyncd: No such process - -- Package-specific info: - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.13.0-trunk-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.3.1-1 ii libapparmor1 3.0.3-2 ii libaudit11:3.0.5-1 ii libblkid12.37.2-2 ii libc62.32-1 ii libcap2 1:2.44-1 ii libcrypt11:4.4.25-2 ii libcryptsetup12 2:2.4.0-1 ii libgcrypt20 1.9.4-2 ii libgnutls30 3.7.2-2 ii libgpg-error01.42-3 ii libip4tc21.8.7-1 ii libkmod2 29-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2 ii libmount12.37.2-2 ii libpam0g 1.4.0-10 ii libseccomp2 2.5.1-1 ii libselinux1 3.1-3 ii libsystemd0 247.9-1 ii libzstd1 1.4.8+dfsg-2.1 ii mount2.37.2-2 ii systemd-timesyncd [time-daemon] 247.9-1 ii util-linux 2.37.2-2 Versions of packages systemd recommends: ii dbus 1.12.20-2 Versions of packages systemd suggests: ii policykit-10.105-31 ii systemd-container 247.9-1 Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.140 ii libnss-systemd 247.9-1 ii libpam-systemd 247.9-1 ii udev 247.9-1 - -- Configuration Files: /etc/systemd/logind.conf changed: [Login] HandlePowerKey=ignore /etc/systemd/resolved.conf changed: [Resolve] DNSSEC=allow-downgrade - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmE2jA8SHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5HXcQAKG5+toLrAqmXBjrFCHUauoUJ1MKEXYp gMk11uNJd61yY0gW7eQHNJ1bl1aeXQ5FBOw830xMVFn9qXcCAghrDcB8yT8Vlsw9 XQQakme/+qUNU6xg4RW9IRbrqH32AhV1hp4rkrchjVYpoLng26JOV7zKSs7PrhL/ THtVzuxRnqgyQ0j742yDmw5X6y/jqBIyOgdVWm176kYIaIvkob8i8YzF8eSjQCgq 0PEDVwtbkDUu8M79lA2QPTya+3y9xD/vp01/hbyMA7+lOfQKC5ylX5rklsMhsWez mLwRBj3UYGGYm6jRWwYRbciSCpYLxsz0RVz6+T8FStyGqh3vNBAWFQHYn47QtypU 2t4JGgJV+Z6yDeY2eh/ltk2kk+yhsMJtDzEoY7unsG4fWa8MoxgdKeIwbQ3Hujir uyQMD170q5/AkPWsmKeJm2OdBF9nRs8dGU+VGi80XZzld0Ociu0tcUQu9F9LbrNj 5HdvUlkY6rkW0OsTpDBjKqVyB/DMHT9ciS5o9a/C6ZwRMspyItxKrxtN+9M2VIN3 5BHv/2vuZfh5OqDCtlVVwEhj2YZUVlEmtIJ+UfA7VfupXHwNiCvI8QOWkKcOvkMJ 1FurFmmJ3WED/2qLfr25GhZgyUGDb/3NluuHHnwRIkpCBYyV4qOSnAd/z4SUa+wv p2k968FNOmUz =jj8P -END PGP SIGNATURE-
Bug#993658: qemu-user-static does not work through binfmt since 6.0
❦ 4 September 2021 15:49 +03, Michael Tokarev: >> Kernel: Linux 5.13.0-trunk-amd64 (SMP w/12 CPU threads) > > Can you please check if it works with not-so-fresh kernel > (eg the one from bullseye)? > > I wont able to do this until late evening today. > > I'm guessing this is the upstream way to detect if we were > called from binfmt subsystem (they done it within kernel) > interferes with my way of doing the same without touching > the kernel. Kernel side is a recent addition. It works fine with 5.10.0-8-amd64 from bullseye. Thanks! -- The Public is merely a multiplied "me." -- Mark Twain
Bug#993658: qemu-user-static does not work through binfmt since 6.0
Package: qemu-user-static Version: 1:6.1+dfsg-4 Severity: critical -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! Since 6.0, qemu-user-static does not seem to work properly through binfmt. I am a bit lost on how to diagnose that: 13:23 ❱ cat /proc/sys/fs/binfmt_misc/qemu-aarch64 enabled interpreter /usr/libexec/qemu-binfmt/aarch64-binfmt-P flags: POCF offset 0 magic 7f454c46020101000200b700 mask ff00feff 13:23 ❱ ./bin/busybox ls BusyBox v1.30.1 (Debian 1:1.30.1-7) multi-call binary. BusyBox is copyrighted by many authors between 1998-2015. Licensed under GPLv2. See source distribution for detailed copyright notices. [...] 13:25 ❱ file bin/busybox bin/busybox: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=6a67fd6d086c703062f3be2d751adf619aa67bc6, for GNU/Linux 3.7.0, stripped When invoked through binfmt, the binaries seem to go from "I display something wrong" to "I will wipe your entire home". That's what happened to me when using cowbuilder. The chroot was not able to be setup correctly and during the clean phase, cowbuilder did not detect the bind mount and/or was not able to undo them, rm -rfing everything that was mounted. Downgrading qemu-user-static to 1:5.2+dfsg-11 fixes the issue. 13:30 ❱ cat /proc/sys/fs/binfmt_misc/qemu-aarch64 enabled interpreter /usr/libexec/qemu-binfmt/aarch64-binfmt-P flags: POCF offset 0 magic 7f454c46020101000200b700 mask ff00feff 13:31 ❱ ./bin/busybox ls bin usr - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.13.0-trunk-amd64 (SMP w/12 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.2.1-1 Versions of packages qemu-user-static suggests: ii sudo 1.9.5p2-3 - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmEzWXASHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5QgoQAKCvyj4ZvK38O+U4JczjZgEyFr1F3L91 04eRxVhienFsserUx+8qE50kQvAjFXt7iqjugF65o+UpsgC0YCG7f8Ri5KAynHWx X5ChFgyZtjU3W9ZOs/zGBa9g2Dw8v3FcXO4AvjZnlmXHzLM7Xh7OhcmUjnQe5U1s JPXw8tojzJA6gaqjCZRmkBuVZMfLteUSeb/yxbopdUCqlv89bFF5VyHS/Agoxj8Q iRyo8qcyAhur/oqMe0tTCoLP9IWtisF1mO0TZoFe82qzSL/WTayn9nvJ7mhCS/s/ 2PyuVa9z1z4NprnZj4f6L3DFszbIB/rlkZng1/GNd9VwAbFqlgGltHZbww1mAOhP 2+ssNF7TDWuFeNQbUwk/YJyzySM/t9fL+O21onahLOR/Hc+Z+tD0f91AdOhBOxM0 D14cqYjKiyQ3Td+N46ZyEkJXW1ThNE2PLU+tnkyXFJGOCfgVLZdPyIeyV77We/MF 9yV9Jy3XrvwuSuqaZZSmlqTp5HzY86AgfEesYTB7diyBTeFwKPE8qnNKOIBXLakG yqH19GtqReRK4zImsQ+/0UU9qxuvrpwGgaAsClZtAxyeBLLdffsXi2kb4EAJ9B2C HFHwSOF+zC91xm8x1wbezCJf9newuQRxvciAIPcXKmKwut9oLqI/zSDRk5LoZLwy VjloaV/64hIA =15C8 -END PGP SIGNATURE-
Bug#993429: Please indent example in package description
❦ 1 September 2021 08:23 +02, Christoph Biedl: > please check https://packages.debian.org/sid/jo - there is a small and > nice usage example in the package description, but unfortunately the > formatting is rather poor. > > According to policy, just adding another space at the beginning of the > respective lines should be sufficient to resolve that. OK, it will be there on next upload! -- Truth is the most valuable thing we have -- so let us economize it. -- Mark Twain
Bug#865793: hsetroot FTCBFS: uses the build architecture pkg-config
❦ 24 June 2017 22:31 +02, Helmut Grohne: > hsetroot fails to cross build from source, because the patch added in > #735758 uses the build architecture pkg-config. It should be using the > PKG_PROG_PKG_CONFIG macro and access pkg-config through $PKG_CONFIG > instead. After doing so, hsetroot cross builds successfully. Please > consider applying the attached patch. I have just uploaded a new version. Unfortunately, the build system is now a very simple makefile. It accepts PKG_CONFIG as an environment variable to change the location of pkg-config. Would this work when crosscompiling? Thanks. -- No violence, gentlemen -- no violence, I beg of you! Consider the furniture! -- Sherlock Holmes
Bug#982249: New upstream version 0.33.0 - Please package
Package: mpv Followup-For: Bug #982249 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! Here is a patch to update to 0.33.1. If you prefer to pull directly from Salsa, the branches are available on my fork: https://salsa.debian.org/bernat/mpv - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.13.0-trunk-amd64 (SMP w/12 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mpv depends on: ii libarchive13 3.4.3-2+b1 ii libasound21.2.5.1-1 ii libass9 1:0.15.1-2 ii libavcodec58 7:4.4-5 ii libavdevice58 7:4.4-5 ii libavfilter7 7:4.4-5 ii libavformat58 7:4.4-5 ii libavutil56 7:4.4-5 ii libbluray21:1.3.0-3 ii libc6 2.31-17 ii libcaca0 0.99.beta19-2.2 ii libcdio-cdda2 10.2+2.0.0-1+b2 ii libcdio-paranoia2 10.2+2.0.0-1+b2 ii libcdio19 2.1.0-2 ii libdrm2 2.4.107-2 ii libdvdnav46.1.1-1 ii libegl1 1.3.2-1 ii libgbm1 21.2.1-1 ii libjack-jackd2-0 [libjack-0.125] 1.9.17~dfsg-1 ii libjpeg62-turbo 1:2.0.6-4 ii liblcms2-22.12~rc1-2 ii liblua5.2-0 5.2.4-1.1+b3 ii libpulse0 15.0+dfsg1-2 ii librubberband21.9.0-1 ii libsdl2-2.0-0 2.0.14+dfsg2-3 ii libswresample37:4.4-5 ii libswscale5 7:4.4-5 ii libuchardet0 0.0.7-1 ii libva-drm22.12.0-2 ii libva-wayland22.12.0-2 ii libva-x11-2 2.12.0-2 ii libva22.12.0-2 ii libvdpau1 1.4-3 ii libwayland-client01.19.0-2 ii libwayland-cursor01.19.0-2 ii libwayland-egl1 1.19.0-2 ii libx11-6 2:1.7.2-1 ii libxext6 2:1.3.3-1.1 ii libxinerama1 2:1.1.4-2 ii libxkbcommon0 1.0.3-2 ii libxrandr22:1.5.1-1 ii libxss1 1:1.2.3-1 ii libxv12:1.0.11-1 ii zlib1g1:1.2.11.dfsg-2 Versions of packages mpv recommends: ii xdg-utils 1.1.3-4.1 ii youtube-dl 2021.06.06-1 mpv suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmEl9TUSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5KEMQAJtafIg14KBpg95jlrsgsIQxym5SHT9+ 6n8hqgFFuzwZLRjfEli4I8Xhjjn64KQ0pby2kGsXYsZcO1BEwfjiwb+TQzxTKmA2 4lUWiyVwBUhaog61/GAVEkrnuOjk1y13+jFTF4zl4TeU0ZgtGZ6jlBNOqVPFCdSf JI9PtwBAkkmBKU5uHihfKvLeAhtKKzOMY/6jPIXP5+LNWUV3s65Bzit98shynE2w zIxEQNvNHG3DSwhzwwb/VKgvNXCWHO21CFaPPK7bEbLbGj5TevL9Cw1hCRPP5gIF kWPGuUAXEZfbT1sJbGt47kx1aB5acPYPOOhPtJvVGgFEwk0YD+p7gjsdEqVgvRw+ YwBqOnIMFIIDJ/bQ/cKvHOLFOLa+QK/YAyaIw7FA3bG7KN8XcEJGUT+i1I2FnuK1 B1RHBTvP3QhZq4Zo087+v6Bb/Ft7i+72bS/ZwEvZZqs+vpkBwedAqhwG90VySJdL NwVLieqqGwYOKiTFrtO3xi+8cd6D9EySftfsJVXd1RbdRP062Ks9M6XRJVlNMjpV peLgN/bAT4E3IvpPPYIlxhkL2ucsotXyV7OgUAFiw+VaMkkToH5BUOuyEd8ZRH6i pPj9YghGtOHYESTApcdtHWrvwuQMEzjpA8nsOR5HT99CHfJjROEgxfl4llqSf9d5 mRmCmSBCOEO8 =ay07 -END PGP SIGNATURE- diff --git a/debian/changelog b/debian/changelog index b896541ff7f3..0abbbc810204 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,15 @@ +mpv (0.33.1-1) unstable; urgency=medium + + * New upstream release. Closes: #982249. + * d/patches: remove fix for CVE-2021-30145, applied upstream. + * d/patches: remove ffmpeg ABI fix, applied upstream. + * d/patches: remove Lua security fix, applied upstream. + * d/rules: don't build with SMB client support (removed upstream). + * d/rules: don't build with sndio support (removed upstream). + * d/symbols: update. + + -- Vincent Bernat Wed, 25 Aug 2021 09:20:59 +0200 + mpv (0.32.0-3) unstable; urgency=medium * debian/patches: Apply upstream fix for CVE-2021-30145 (Closes: #986839) diff --git a/debian/control b/debian/control index a36186f0fcb2..7724677d81c1 100644 --- a/debian/control +++ b/debian/control @@ -31,8 +31,6 @@ Build-Depends: libpulse-dev, librubberband-dev, libsdl2-dev, - libsmbclient-dev, - libsndio-dev (>= 1.0.1), libswscale-dev (>= 7:4.0
Bug#846383: grub2: add TPM support
fixed 846383 2.04-18 thanks ❦ 21 August 2021 20:42 +02, Vincent Bernat: >> grub2 (2.04-18) unstable; urgency=medium >> >> [ Steve McIntyre ] >> * Enable the shim_lock and tpm modules for i386-efi too. Ensure that >> tpm is included in our EFI images. >> [...] >> >> -- Colin Watson Sun, 25 Apr 2021 16:20:17 +0100 >> >> Do we think that's enough to close this bug? > > Does this mean it's inside "core.efi"? I think this is not the case: > there is a "tpm.mod" file and "strings core.efi | grep tpm" does not > return any result. But maybe it's easy for a user to build a core.efi > with the module added? Some users may like core.efi to be signed, but > that's not my case. OK, that's not the file which is used to boot with EFI. This is /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi which contains the TPM module. So, yes, this can be closed. -- Must I hold a candle to my shames? -- William Shakespeare, "The Merchant of Venice"
Bug#846383: grub2: add TPM support
❦ 21 August 2021 17:45 +01, Colin Watson: >> > We think that TPM support is a good addition to Debian because it can >> > increase >> > its adoption in environments where a more secure approach to the booting is >> > needed, by being able to securely measure if any component has been >> > tampered. >> >> It seems that Grub in Debian has now TPM support as there is a tpm.mod >> shipped with Grub. Manual here: >> https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html >> >> The documentation suggests the module should be builtin. If not, it is a >> bit unknown what can happen. Maybe the tpm.mod itself can be tampered? >> >> Would it be possible to have the module builtin for GRUB UEFI (where >> the size does not matter)? > > It already is, in bullseye: > > grub2 (2.04-18) unstable; urgency=medium > > [ Steve McIntyre ] > * Enable the shim_lock and tpm modules for i386-efi too. Ensure that > tpm is included in our EFI images. > [...] > > -- Colin Watson Sun, 25 Apr 2021 16:20:17 +0100 > > Do we think that's enough to close this bug? Does this mean it's inside "core.efi"? I think this is not the case: there is a "tpm.mod" file and "strings core.efi | grep tpm" does not return any result. But maybe it's easy for a user to build a core.efi with the module added? Some users may like core.efi to be signed, but that's not my case. -- Consider well the proportions of things. It is better to be a young June-bug than an old bird of paradise. -- Mark Twain, "Pudd'nhead Wilson's Calendar"
Bug#846383: grub2: add TPM support
❦ 30 November 2016 20:11 GMT, Urquiza, Fabio: > We think that TPM support is a good addition to Debian because it can increase > its adoption in environments where a more secure approach to the booting is > needed, by being able to securely measure if any component has been > tampered. It seems that Grub in Debian has now TPM support as there is a tpm.mod shipped with Grub. Manual here: https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html The documentation suggests the module should be builtin. If not, it is a bit unknown what can happen. Maybe the tpm.mod itself can be tampered? Would it be possible to have the module builtin for GRUB UEFI (where the size does not matter)? -- The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain
Bug#991813: libsmi: New upstream version 0.5.0 available.
❦ 3 August 2021 08:33 +02, Tobias Frost: >> > So -- my 2 cent -- I would even package trunk of the git repo, it would >> > be much better than the more-than-adecade(!) old version in Debian. >> >> If you have some time, feel free to take over the package. I have too >> much on my plate currently. >> >> > Regarding ABI: I've diffed the 0.4.8 smi.h with the 0.5.0 one: >> > all those changes should not be ABI changing. >> >> Thanks for checking. If you don't want to take over the package, I'll >> try to find some time to update to 0.5.0. > > Lets form a team or maybe ask the net-snmp people if they would be ok > in expanding the scope towards are more snmp team? Whatever you see fit. I don't think the SNMP team has much bandwidth either, so I wouldn't go through the trouble. -- Truth is the most valuable thing we have -- so let us economize it. -- Mark Twain
Bug#991813: libsmi: New upstream version 0.5.0 available.
❦ 3 August 2021 07:42 +02, Tobias Frost: > So -- my 2 cent -- I would even package trunk of the git repo, it would > be much better than the more-than-adecade(!) old version in Debian. If you have some time, feel free to take over the package. I have too much on my plate currently. > Regarding ABI: I've diffed the 0.4.8 smi.h with the 0.5.0 one: > all those changes should not be ABI changing. Thanks for checking. If you don't want to take over the package, I'll try to find some time to update to 0.5.0. -- Instrument your programs. Measure before making "efficiency" changes. - The Elements of Programming Style (Kernighan & Plauger)
Bug#990079: tagging 935548, tagging 986803, tagging 989479, tagging 990079, tagging 990528, tagging 990525 ...
❦ 17 July 2021 23:30 +02, Sebastian Ramacher: > # can be fixed via DSAs > tags 935548 + bullseye-ignore > tags 986803 + bullseye-ignore > tags 989479 + bullseye-ignore > tags 990079 + bullseye-ignore > tags 990528 + bullseye-ignore > tags 990525 + bullseye-ignore > tags 990691 + bullseye-ignore > tags 990835 + bullseye-ignore > tags 991046 + bullseye-ignore > tags 991040 + bullseye-ignore > thanks Maybe we should reconsider shipping a browser who has been often late in shipping security fixes? -- Watch out for off-by-one errors. - The Elements of Programming Style (Kernighan & Plauger)
Bug#991813: libsmi: New upstream version 0.5.0 available.
❦ 2 August 2021 14:02 +02, Tobias Frost: > Upsteam has released 0.5.0 already in 2014. > Would be cool to have this version as well in Debian. I don't remember why I didn't package but I remember there was some "good" reason. I think there is an ABI incompatibility but it is not reflected in the ABI number (VERSION, REVISION and AGE stays the same). I may have contacted upstream on the mailing list about this, but all I can find is me asking about what's new in this 0.5.0 because no changelog, no announce, not listed on the official website and got no answer. So, maybe, there is no issue at all. -- Extreme fear can neither fight nor fly. -- William Shakespeare, "The Rape of Lucrece"
