Bug#1017555: Let's drop win32-loader from amd64/i386 and multiarch CDs
On 17/08/2022 21:08, Didier 'OdyX' Raboud wrote: Following the recent discussion on d-boot [1], it seems we agreed to drop win32-loader from the Debian CDs, as it's not likely to be very useful these days. win32-loader seems also present on debian-installer [2], I'll therefore clone the bug. FYI: win32-loader has also been dropped from live-build images. https://salsa.debian.org/live-team/live-build/-/commit/6908dfd6df69c9e9cd2458d9987b40b06bf1cfd3 With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Bug#1017375: liblexical-accessor-perl: test failure with Sub::HandlesVia 0.034
-=| gregor herrmann, 17.08.2022 17:59:41 +0200 |=- > This should be fixed with libsub-handlesvia-perl 0.035, judging from > the following upstream commit: > … > Also Changes say: > - Sub::HandlesVia::CodeGenerator method_installer is now a rw attribute as >Sub::Accessor::Small was relying on that. > > > I'm going to upload libsub-handlesvia-perl now, then we can depend on > the fixed version to close this bug, I guess? build-time and run-time dependency version bumped, all tests pass, so uploaded. Thank you for the investigation. -- Damyan
Bug#1017591: libkf5service5: missing symbols in library
Package: libkf5service5 Version: 5.97.0-1 Severity: grave Justification: renders package unusable /usr/bin/startplasma-x11: symbol lookup error: /usr/lib/x86_64-linux-gnu/libKF5Service.so.5: undefined symbol: _ZN8KSandbox9isFlatpakEv -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkf5service5 depends on: ii libc6 2.34-4 ii libkf5configcore5 5.97.0-1 ii libkf5coreaddons5 5.97.0-1 ii libkf5dbusaddons5 5.97.0-1 ii libkf5i18n5 5.97.0-1 ii libkf5service-data 5.97.0-1 ii libqt5core5a5.15.4+dfsg-5 ii libqt5dbus5 5.15.4+dfsg-5 ii libqt5xml5 5.15.4+dfsg-5 ii libstdc++6 12.1.0-8 Versions of packages libkf5service5 recommends: ii libkf5service-bin 5.97.0-1 libkf5service5 suggests no packages. -- no debconf information
Bug#1016630: guile-3.0: gdb guile results in SIGSEGV before guile even starts!
Linas Vepstas writes: > Wow! Well, I feel kind of dumb to not actually have tried that; I have been > trained that SIGSEGV is a full stop, and it's pointless to try to > continue. Thank you! Of course, and I might well not have assumed otherwise either -- but yeah, I have the impression that libgc does some "interesting" things. > I can't imagine I will be the first and only one to be surprised by this > change of behavior, but I can't think of a good solution to propose, just > right now. Agreed, I suppose we could consider adding it to a README.Debian, but not sure people (including me) would notice it in the relvant circumstances. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1017590: glibc 2.34 broke getpwnam calls under fakechroot
Source: glibc
Version: 2.34-1
Severity: normal
X-Debbugs-Cc: jo...@debian.org
Control: affects -1 + fakechroot mmdebstrap
Hi,
ultimately this probably needs to be fixed in fakechroot but I need some
help solving this problem from somebody who understands glibc.
Since the upload of glibc 2.34, getpwnam (and friends) under fakechroot
are not wrapped anymore. This means that instead of accessing
/etc/passwd from the chroot, the version from the host will be accessed,
leading to incorrect behaviour.
Since mmdebstrap uses fakechroot, this problem affects mmdebstrap as
well and breaks its autopkgtest.
There was a similar problem in the past. See
https://bugs.debian.org/993946 which in the end was fixed by letting
fakechroot wrap __nss_files_fopen.
I bisected glibc from git between 2.33 and 2.34 and found out, that this
fix broke again in this commit:
https://sourceware.org/git/?p=glibc.git;a=commit;h=6212bb67f4695962748a5981e1b9fea105af74f6
Do you have any idea why this commit is responsible and what fakechroot
could do to fix it? Attached the script I used to setup a minimal chroot
to bisect glibc git (this is for future-me in case I need to do this
ever again in the future).
Thanks!
cheers, josch
#!/bin/sh
set -e
rm -rf /install ./*
/glibc/configure --prefix=/usr && make -j
wget -c
http://snapshot.debian.org/archive/debian/20211216T150239Z/pool/main/f/fakechroot/fakechroot_2.20.1%2Bds-2_all.deb
wget -c
http://snapshot.debian.org/archive/debian/20211216T150239Z/pool/main/f/fakechroot/libfakechroot_2.20.1%2Bds-2_amd64.deb
mkdir -p /install/bin /install/lib /install/lib64 /install/dev /install/usr/lib
ln -s ../lib/ld.so /install/lib64/ld-linux-x86-64.so.2
ln -s ../../lib64 /install/usr/lib/x86_64-linux-gnu
ln -s ../bin /install/usr/bin
cp /bin/dash /install/bin/sh
cp ./elf/ldconfig /install/bin/
cp /usr/bin/seq /usr/bin/env /bin/bash /usr/bin/tr /usr/bin/basename
/usr/bin/getopt /usr/sbin/chroot /bin/echo /install/bin/
cp -a /lib/x86_64-linux-gnu/libtinfo.so.6.2 /install/lib64
ln -s libtinfo.so.6.2 /install/lib64/libtinfo.so.6
cp ./elf/ld.so /install/lib
find -name '*.so' -or -name '*.so.*' | xargs -I'{}' cp '{}' /install/lib64
dpkg-deb --fsys-tarfile fakechroot_2.20.1+ds-2_all.deb | tar -C /install
--keep-directory-symlink -x
dpkg-deb --fsys-tarfile libfakechroot_2.20.1+ds-2_amd64.deb | tar -C /install
--keep-directory-symlink -x
cp /fakechroot/test/src/test-nss_files_fopen /install/bin/
cp -a /install /chroot
mv /chroot /install/chroot
echo "user:x:1337:1337:user:/home/user:/bin/bash" > /install/chroot/etc/passwd
chroot /install fakechroot --lib
/usr/lib/x86_64-linux-gnu/fakechroot/libfakechroot.so /bin/chroot /chroot
/bin/test-nss_files_fopen user
Bug#1017589: CVE-2021-22946: ftp,imap,pop3: do not ignore ssl-reqd
Package: libcurl4
Version: 7.64.0-4+deb10u2
Severity: normal
Tags: patch
CVE-2021-22946 has not been fixed for buster.
https://security-tracker.debian.org/tracker/CVE-2021-22946
So, I ported upstream patch to 7.64.0-4+deb10u2.
https://github.com/curl/curl/commit/364f174724ef115c63d5e5dc1d3342c8a43b1cca
For testing, I applied the attached patch in two ways:
* Apply all hunks of the patch
* Apply hunks except for ftp.c, imap.,c pop3.c
Then, I built the source and ran test984-986 for these case.
```
$ env PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig ./configure
--with-ssl --prefix=`pwd`/install
$ make
$ make test
```
I confirmed that test 984-986 has passed only for former case.
*** ftp-imap-pop3-do-not-ignore-ssl-reqd.patch
Index: curl-7.64.0/lib/ftp.c
===
--- curl-7.64.0.orig/lib/ftp.c
+++ curl-7.64.0/lib/ftp.c
@@ -2622,9 +2622,12 @@ static CURLcode ftp_statemach_act(struct
/* we have now received a full FTP server response */
switch(ftpc->state) {
case FTP_WAIT220:
- if(ftpcode == 230)
-/* 230 User logged in - already! */
-return ftp_state_user_resp(conn, ftpcode, ftpc->state);
+ if(ftpcode == 230) {
+/* 230 User logged in - already! Take as 220 if TLS required. */
+if(data->set.use_ssl <= CURLUSESSL_TRY ||
+ conn->ssl[FIRSTSOCKET].use)
+ return ftp_state_user_resp(conn, ftpcode, ftpc->state);
+ }
else if(ftpcode != 220) {
failf(data, "Got a %03d ftp-server response when 220 was expected",
ftpcode);
Index: curl-7.64.0/lib/imap.c
===
--- curl-7.64.0.orig/lib/imap.c
+++ curl-7.64.0/lib/imap.c
@@ -922,22 +922,18 @@ static CURLcode imap_state_capability_re
line += wordlen;
}
}
- else if(imapcode == IMAP_RESP_OK) {
-if(data->set.use_ssl && !conn->ssl[FIRSTSOCKET].use) {
- /* We don't have a SSL/TLS connection yet, but SSL is requested */
- if(imapc->tls_supported)
-/* Switch to TLS connection now */
-result = imap_perform_starttls(conn);
- else if(data->set.use_ssl == CURLUSESSL_TRY)
-/* Fallback and carry on with authentication */
-result = imap_perform_authentication(conn);
- else {
-failf(data, "STARTTLS not supported.");
-result = CURLE_USE_SSL_FAILED;
- }
+ else if(data->set.use_ssl && !conn->ssl[FIRSTSOCKET].use) {
+/* PREAUTH is not compatible with STARTTLS. */
+if(imapcode == IMAP_RESP_OK && imapc->tls_supported && !imapc->preauth) {
+ /* Switch to TLS connection now */
+ result = imap_perform_starttls(conn);
}
-else
+else if(data->set.use_ssl <= CURLUSESSL_TRY)
result = imap_perform_authentication(conn);
+else {
+ failf(data, "STARTTLS not available.");
+ result = CURLE_USE_SSL_FAILED;
+}
}
else
result = imap_perform_authentication(conn);
Index: curl-7.64.0/lib/pop3.c
===
--- curl-7.64.0.orig/lib/pop3.c
+++ curl-7.64.0/lib/pop3.c
@@ -726,28 +726,23 @@ static CURLcode pop3_state_capa_resp(str
}
}
}
- else if(pop3code == '+') {
-if(data->set.use_ssl && !conn->ssl[FIRSTSOCKET].use) {
- /* We don't have a SSL/TLS connection yet, but SSL is requested */
- if(pop3c->tls_supported)
-/* Switch to TLS connection now */
-result = pop3_perform_starttls(conn);
- else if(data->set.use_ssl == CURLUSESSL_TRY)
-/* Fallback and carry on with authentication */
-result = pop3_perform_authentication(conn);
- else {
-failf(data, "STLS not supported.");
-result = CURLE_USE_SSL_FAILED;
- }
-}
-else
- result = pop3_perform_authentication(conn);
- }
else {
/* Clear text is supported when CAPA isn't recognised */
-pop3c->authtypes |= POP3_TYPE_CLEARTEXT;
+if(pop3code != '+')
+ pop3c->authtypes |= POP3_TYPE_CLEARTEXT;
-result = pop3_perform_authentication(conn);
+if(!data->set.use_ssl || conn->ssl[FIRSTSOCKET].use)
+ result = pop3_perform_authentication(conn);
+else if(pop3code == '+' && pop3c->tls_supported)
+ /* Switch to TLS connection now */
+ result = pop3_perform_starttls(conn);
+else if(data->set.use_ssl <= CURLUSESSL_TRY)
+ /* Fallback and carry on with authentication */
+ result = pop3_perform_authentication(conn);
+else {
+ failf(data, "STLS not supported.");
+ result = CURLE_USE_SSL_FAILED;
+}
}
return result;
Index: curl-7.64.0/tests/data/Makefile.inc
===
--- curl-7.64.0.orig/tests/data/Makefile.inc
+++ curl-7.64.0/tests/data/Makefile.inc
@@ -108,6 +108,8 @@ test927 test928 test929 test930 test931
test936 test937 test938 test939 test940 test941 test942 test943 test944 \
test945 test946
Bug#1017499: Related upstream issue
Upstream issue #7071 [1] seems to be related, with similar artifacts and the issue being first reported in Mobian, which shares the same mesa package as Debian. If this is true, the offending commit would be 53445284a427f79e94607dc4ca2f8bd8ac293356. -- Ben Westover [1] https://gitlab.freedesktop.org/mesa/mesa/-/issues/7071 OpenPGP_signature Description: OpenPGP digital signature
Bug#1017588: RFS: drgn/0.0.20-1 [ITP] -- Programmable debugger
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "drgn": * Package name: drgn Version : 0.0.20-1 Upstream Author : Omar Sandoval * URL : https://github.com/osandov/drgn * License : GPL-3.0+, Expat * Vcs : https://salsa.debian.org/michel/drgn Section : devel The source builds the following binary packages: python-drgn-doc - Programmable debugger - documentation python3-drgn - Programmable debugger (Python 3 library) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/drgn/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/drgn/drgn_0.0.20-1.dsc Changes for the initial release: drgn (0.0.20-1) unstable; urgency=low . * Initial release. (Closes: #1001581) Regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature
Bug#1017584: bullseye launch failures in IPv6-only VPC subnets
Adding some tracing to the dhclient-script, I can see that /etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes is trying to add the routes with calls like: ip -4 route add 169.254.169.254/32 via 169.254.0.1 dev ens5 However, because there's no route to 169.254.0.1, the call fails with "Error: Nexthop has invalid gateway." On systems where the routes are properly configured, there's a link scope route to that address, e.g. on sid: 169.254.0.1 dev ens5 proto dhcp scope link src 169.254.2.187 metric 100 If we create this route on bullseye, then the rest of the IPv4 routes are installed as expected. Something like the following could work, but I'm open to other options: services/admin@i-07e63055bb304147c:~$ cat /etc/dhcp/dhclient-exit-hooks.d/gw case "$reason" in BOUND|RENEW|REBIND|REBOOT) if [ -z "$old_ip_address" ] || [ "$old_ip_address" != "$new_ip_address" ]; then case "$new_ip_address" in 169.254.*) ip -4 ro add 169.254.0.1 dev "$interface" scope link ;; esac fi ;; esac
Bug#1017587: ITP: fheroes2 -- free remake of Heroes of Might and Magic II game engine
Package: wnpp Severity: wishlist Owner: Anatoliy Gunya * Package name: fheroes2 Version : 0.9.18 Upstream Author : fheroes2 team * URL : https://github.com/ihhub/fheroes2 * License : GPL 2.0 Programming Lang: C++ Description : free remake of Heroes of Might and Magic II game engine Debian repository has fheroes2-pkg. This package downloads sources from https://sourceforge.net/projects/fheroes2/ and creates a local package. This project is not fully free software because it contains some source files with non-commercial license. Also this project doesn't updated a long time and looks like dead. There is a fork of this project at https://github.com/ihhub/fheroes2. This one is actively developed, has many improvements (for example, it supports campaigns) and bugfixes. Also it doesn't contain non-free sources. These both projects are game engines, original game's assets are needed to play.
Bug#1017586: RM: libnrepl-clojure [i386 armhf armel ppc64el] -- NBS; No longer built on i386 armhf armel and ppc64el
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: po...@debian.org Please note that a lot of Clojure package build-depend one way or another on nrepl-clojure. I'm not sure if those packages will be auto-decrufted on the architectures where the build-dep can no longer be satisfied? If I need to do anything wrt that, please advise. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1017585: lime FTBFS: Missing build dependency on javahelper
Source: lime Version: 5.0.37+dfsg-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=lime=5.0.37%2Bdfsg-1 ... debian/rules clean dh clean --with javahelper dh: error: unable to load addon javahelper: Can't locate Debian/Debhelper/Sequence/javahelper.pm in @INC (you may need to install the Debian::Debhelper::Sequence::javahelper module) (@INC contains: /etc/perl /usr/local/lib/arm-linux-gnueabi/perl/5.34.0 /usr/local/share/perl/5.34.0 /usr/lib/arm-linux-gnueabi/perl5/5.34 /usr/share/perl5 /usr/lib/arm-linux-gnueabi/perl-base /usr/lib/arm-linux-gnueabi/perl/5.34 /usr/share/perl/5.34 /usr/local/lib/site_perl) at (eval 12) line 1. BEGIN failed--compilation aborted at (eval 12) line 1. make: *** [debian/rules:24: clean] Error 25
Bug#1017584: bullseye launch failures in IPv6-only VPC subnets
Package: cloud.debian.org Severity: important User: cloud.debian@packages.debian.org Usertags: aws image When AWS originally launched IPv6-only VPC subnets, the DHCPv4 server handed out a link-local v4 address and a default route that was a blackhole for most destinations. It did route traffic to the instance metadata endpoint (169.254.169.254), the timesync endpoint (169.254.169.123) and a couple of others. This provided compatibility with existing software, but the blackhole default route lead to some obvious problems for any software that would try to establish a connection using IPv4 before IPv6. AWS has recently started rolling out RFC 3442 routes to the specific endpoints, and stopped distributing a default route. This is the correct thing to do, and works well on sid and bookworm, but it's causing problems on bullseye. The expected behavior when launching in an IPv6 subnet is that an instance has one or more IPv6 addresses and a functioning IPv6 default route. It also should have an IPv4 address in the 169.254/16 range and /32 routes to several endpoints, for example: 2: eth0: mtu 9001 qdisc mq state UP group default qlen 1000 inet 169.254.245.205/32 scope global dynamic eth0 valid_lft 2789sec preferred_lft 2789sec 169.254.0.1 dev eth0 scope link 169.254.169.123 via 169.254.0.1 dev eth0 proto static 169.254.169.249 via 169.254.0.1 dev eth0 proto static 169.254.169.250/31 via 169.254.0.1 dev eth0 proto static 169.254.169.253 via 169.254.0.1 dev eth0 proto static 169.254.169.254 via 169.254.0.1 dev eth0 proto static The actual behavior on the current bullseye AMIs is that IPv6 is configured as expected, but the IPv4 routes are not configured: admin@i-07e63055bb304147c:~$ ip -4 addr show dev ens5 2: ens5: mtu 9001 qdisc mq state UP group default qlen 1000 altname enp0s5 inet 169.254.109.198/32 scope global ens5 valid_lft forever preferred_lft forever admin@i-07e63055bb304147c:~$ ip -4 ro admin@i-07e63055bb304147c:~$ Because cloud-init in bullseye does not know about the IPv6 instance metadata endpoint and is unable to reach the IPv4 endpoint, it is unable to complete the instance provisioning process. Logs indicate the following: Aug 18 00:07:10 debian systemd[1]: Started ifup for ens5. Aug 18 00:07:10 debian dhclient[388]: Internet Systems Consortium DHCP Client 4.4.1 Aug 18 00:07:10 debian sh[388]: Internet Systems Consortium DHCP Client 4.4.1 Aug 18 00:07:10 debian dhclient[388]: Copyright 2004-2018 Internet Systems Consortium. Aug 18 00:07:10 debian sh[388]: Copyright 2004-2018 Internet Systems Consortium. Aug 18 00:07:10 debian dhclient[388]: All rights reserved. Aug 18 00:07:10 debian sh[388]: All rights reserved. Aug 18 00:07:10 debian dhclient[388]: For info, please visit https://www.isc.org/software/dhcp/ Aug 18 00:07:10 debian sh[388]: For info, please visit https://www.isc.org/software/dhcp/ Aug 18 00:07:10 debian dhclient[388]: Aug 18 00:07:10 debian dhclient[388]: Listening on LPF/ens5/06:6c:90:77:5b:a1 Aug 18 00:07:10 debian sh[388]: Listening on LPF/ens5/06:6c:90:77:5b:a1 Aug 18 00:07:10 debian sh[388]: Sending on LPF/ens5/06:6c:90:77:5b:a1 Aug 18 00:07:10 debian sh[388]: Sending on Socket/fallback Aug 18 00:07:10 debian sh[388]: DHCPDISCOVER on ens5 to 255.255.255.255 port 67 interval 4 Aug 18 00:07:10 debian dhclient[388]: Sending on LPF/ens5/06:6c:90:77:5b:a1 Aug 18 00:07:10 debian dhclient[388]: Sending on Socket/fallback Aug 18 00:07:10 debian dhclient[388]: DHCPDISCOVER on ens5 to 255.255.255.255 port 67 interval 4 Aug 18 00:07:10 debian dhclient[388]: DHCPOFFER of 169.254.109.198 from 169.254.0.1 Aug 18 00:07:10 debian sh[388]: DHCPOFFER of 169.254.109.198 from 169.254.0.1 Aug 18 00:07:10 debian sh[388]: DHCPREQUEST for 169.254.109.198 on ens5 to 255.255.255.255 port 67 Aug 18 00:07:10 debian sh[388]: DHCPACK of 169.254.109.198 from 169.254.0.1 Aug 18 00:07:10 debian dhclient[388]: DHCPREQUEST for 169.254.109.198 on ens5 to 255.255.255.255 port 67 Aug 18 00:07:10 debian dhclient[388]: DHCPACK of 169.254.109.198 from 169.254.0.1 Aug 18 00:07:10 debian sh[399]: RTNETLINK answers: File exists Aug 18 00:07:10 debian root[415]: /etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes returned non-zero exit status 2 Aug 18 00:07:10 debian dhclient[388]: bound to 169.254.109.198 -- renewal in 1498 seconds.
Bug#774711: OpenSSH settings hardening
Hi, Some updates on OpenSSH config hardening 1) The ssh-audit tool that Mathew Binkley pointed out has been forked and updated and lives at https://github.com/jtesta/ssh-audit 2) The sshaudit.com site now uses the above version. 3) The sshaudit.com site also now provides a hardening guide https://www.ssh-audit.com/hardening_guides.html that was inspired by the original stribika.github.io page mentioned here. I like Mathew's idea of aiming for a config that scores well, with commented out configs for enabling compatibility for older clients. -- Matt Taggart m...@lackof.org
Bug#1017583: RM: redland-bindings [all] -- NBS; transitional package librdf-ruby no longer built
Package: ftp.debian.org Severity: normal The sole Architecture: all package librdf-ruby is no longer built.
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Control: tag -1 patch Control: forwarded -1 https://salsa.debian.org/lintian/lintian/-/merge_requests/414 On Mon, 2022-06-27 at 15:14:10 +0200, Axel Beckert wrote: > Guillem Jover wrote: > > I'd have to re-dig all this. I might just try to provide a patch, I > > think should probably be a one-liner. > > A patch of course would be nice, but I won't mind if you don't provide > one. I've sent an MR now, which passes the test suite locally, and seems to work on a manually modified package too. Thanks, Guillem
Bug#1017582: cl-containers: Vcs-* do not contain debian packaging
Package: cl-containers Severity: minor X-Debbugs-Cc: Vagrant Cascadian The Vcs-* headers in debian/control: Vcs-Git: git://github.com/gwkkwg/cl-containers Vcs-Browser: https://github.com/gwkkwg/cl-containers These URLs appear to only contain upstream information and not any debian packaging and I do not see any branches specific to debian packaging. From debian-policy: 5.6.26. Version Control System (VCS) fields --- Debian source packages are increasingly developed using VCSs. The purpose of the following fields is to indicate a publicly accessible repository where the Debian source package is developed. "Vcs-Browser" URL of a web interface for browsing the repository. "Vcs-" The field name identifies the VCS. The field’s value uses the version control system’s conventional syntax for describing repository locations and should be sufficient to locate the repository used for packaging. Ideally, it also locates the branch used for development of new versions of the Debian package. live well, vagrant signature.asc Description: PGP signature
Bug#1017581: Please install documentation
Package: libuv1-dev Version: 1.44.2-1 Severity: minor Hi. I'm currently trying to selecte an event library, and found libuv1. I noticed that there were docs on the upstream website, but not, AFAICT, in any Debian binary package. However, the source package does seem to contain quite a lot in docs/src/. It would be ncie to install this documentation somewhere suitable. As manpages would be ideal, assuming the .rst files are suitable for that, but HTML in /usr/share/doc/ would do nicely as well. Thanks, Ian. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
On Thu, Aug 18, 2022 at 12:13 AM Thorsten Glaser wrote: > > Arnd Bergmann dixit: > > >The way the FPU type gets selected in gcc changed with recent versions, > >this was intentional and won't be reverted but it did break packages that > >used the old method. > > Hmph. > > >In most cases, it's sufficient to pass > >-march=armv7-a+fp instead of -march=armv7-a to pick the right > >instruction set. > > There’s no “instead of”, though. > > So basically, I now need to add -march=… to CFLAGS in the package > when compiling for either of armel and armhf. What I see with gcc-12-arm-linux-gnueabihf 12.1.0-8cross1 is that it defaults to the correct architecture level (armv7-a+fp) and passes that to the assembler, so it /should/ not be necessary do this explictily. The problem with other packages was that they did pass "-march=armv7-a" for armhf, but that is interpreted as not having an FPU now, where on older compilers the -mhard-float flag would override the -march= flag and enable support for an FPU regardless. > Which value do I use for armel, which for armhf (the one you gave > is for armhf, I think)? That should be -march=armv5te Arnd
Bug#1017580: plasma-desktop: dpkg error when upgrading plasma-desktop and plasma-workspace-data from Debian Bullseye to Bookworm
Package: plasma-desktop Version: 4:5.25.4-1 Severity: normal Dear Maintainer, trying to dist-upgrade fresh Debian Bullseye with KDE to Debian Bookworm fails with a: ``` Unpacking plasma-workspace-data (4:5.25.4-2) over (4:5.20.5-6) ... dpkg: error processing archive /tmp/apt-dpkg-install-tgSUlx/82-plasma-workspace-data_4%3a5.25.4-2_all.deb (--unpack): trying to overwrite '/usr/share/qlogging-categories5/kcmusers.categories', which is also in package plasma-desktop 4:5.20.5-4 ``` Please redirect me if this is the wrong place for reporting this issue. Greetings Julian Groß -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-17-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 plasma-desktop depends on: iu accountsservice 22.08.8-1 iu breeze 4:5.25.4-1 iu kactivitymanagerd5.25.4-1 iu kde-cli-tools4:5.25.4-1 iu kded55.96.0-1 iu kio 5.96.0-3 iu kpackagetool55.96.0-1 iu layer-shell-qt 5.25.4-1 ii libaccounts-qt5-11.16-2 ii libc62.34-3 ii libgcc-s110.2.1-6 iu libglib2.0-0 2.72.3-1+b1 iu libibus-1.0-51.5.26-4 iu libkaccounts24:21.12.3-1 iu libkf5activities55.96.0-2 iu libkf5activitiesstats1 5.96.0-1 iu libkf5authcore5 5.96.0-1 iu libkf5baloo5 5.96.0-1 iu libkf5bookmarks5 5.96.0-1 iu libkf5codecs55.96.0-1 iu libkf5completion55.96.0-1 iu libkf5configcore55.96.0-1 iu libkf5configgui5 5.96.0-1 iu libkf5configwidgets5 5.96.0-1 iu libkf5coreaddons55.96.0-1 iu libkf5crash5 5.96.0-1 iu libkf5dbusaddons55.96.0-1 iu libkf5declarative5 5.96.0-3 iu libkf5globalaccel-bin5.96.0-1 iu libkf5globalaccel5 5.96.0-1 iu libkf5guiaddons5 5.96.0-1 iu libkf5i18n5 5.96.0-1 iu libkf5iconthemes55.96.0-1 iu libkf5itemviews5 5.96.0-1 iu libkf5jobwidgets55.96.0-1 iu libkf5kcmutils5 5.96.0-1 iu libkf5kdelibs4support5 5.96.0-1 iu libkf5kiocore5 5.96.0-3 iu libkf5kiofilewidgets55.96.0-3 iu libkf5kiogui55.96.0-3 iu libkf5kiowidgets55.96.0-3 iu libkf5newstuffcore5 5.96.0-1 iu libkf5newstuffwidgets5 5.96.0-1 iu libkf5notifications5 5.96.0-1 iu libkf5notifyconfig5 5.96.0-1 iu libkf5package5 5.96.0-1 iu libkf5plasma55.96.0-1 iu libkf5plasmaquick5 5.96.0-1 iu libkf5quickaddons5 5.96.0-3 iu libkf5runner55.96.0-1 iu libkf5service-bin5.96.0-1 iu libkf5service5 5.96.0-1 iu libkf5solid5 5.96.0-1 iu libkf5sonnetcore55.96.0-1 iu libkf5sonnetui5 5.96.0-1 iu libkf5widgetsaddons5 5.96.0-1 iu libkf5windowsystem5 5.96.0-1 iu libkf5xmlgui55.96.0-1 iu libkuserfeedbackcore11.2.0-2 ii libkworkspace5-5 4:5.20.5-6 iu libnotificationmanager1 4:5.25.4-2 ii libpackagekitqt5-1 1.0.2-1 ii libphonon4qt5-4 4:4.11.1-4 ii libprocesscore9 4:5.20.5-1 iu libqt5concurrent55.15.4+dfsg-5 ii libqt5core5a 5.15.2+dfsg-9 iu libqt5dbus5 5.15.4+dfsg-5 iu libqt5gui5 5.15.4+dfsg-5 iu libqt5network5 5.15.4+dfsg-5 iu libqt5qml5 5.15.4+dfsg-4 iu libqt5quick5 5.15.4+dfsg-4 iu libqt5quickwidgets5 5.15.4+dfsg-4 iu libqt5sql5
Bug#1017579: Freeciv < 2.6.7, freeciv-3.0 < 3.0.3, Modpack Installer buffer overflow
Source: freeciv Version: 2.6.6-1 Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team Quoting from the announcement posted to oss-security (no CVE is available): -- Just released freeciv-2.6.7 & freeciv-3.0.3 fix buffer overflow in Modpack Installer utility's handling of the modpack URL. Specially crafted URLs, without any '/' -characters would result in an underflowing length (unsigned)(-1) string copy, i.e., all of the NULL-terminated string given as "URL" would get written beyond the buffer reserved for it. Freeciv source tarballs are available from https://www.freeciv.org/download.html for current 3.0, and from https://www.freeciv.org/wiki/Old_downloads for 2.6. In case you can't make full version update at the moment, bug tracker ticket has also a patch for this single issue attached: https://osdn.net/projects/freeciv/ticket/45299 --
Bug#1017578: gtk+3.0: build test failures with glib 2.73
Source: gtk+3.0 Version: 3.24.34-1 Severity: important As detected by autopkgtests, gtk+3.0 will fail its build tests with glib 2.73 (currently in experimental). We need to adapt https://gitlab.gnome.org/GNOME/gtk/-/commit/78c153ae14 for the older code base. TEST: icontheme... (pid=3486770) /icontheme/basics: OK /icontheme/lookup-order: (/<>/debian/build/deb/testsuite/gtk/.libs/icontheme:3486770): GLib-ERROR **: 22:37:08.353: g_log_set_writer_func() called multiple times FAIL GTester: last random seed: R02S6d667302897b32fd5f67396760fbaa55 (pid=3486785) /icontheme/generic-fallback: OK /icontheme/force-symbolic: OK /icontheme/force-regular:OK /icontheme/rtl: OK /icontheme/symbolic-single-size: OK /icontheme/svg-size: OK /icontheme/size: OK /icontheme/builtin: OK /icontheme/list: OK /icontheme/async:OK /icontheme/inherit: OK /icontheme/nonsquare-symbolic: OK FAIL: icontheme Thank you, Jeremy Bicha
Bug#1017577: sqlcipher: new upstream version available
Source: sqlcipher Version: 3.4.1-2 Severity: normal X-Debbugs-Cc: d...@fifthhorseman.net sqlcipher upstream offers version 4.5.2. debian is pretty far out of date. I ran into this when packaging and experimenting with the rust bindings for sqlite3 (package: rust-rusqlite), which include bindings for sqlcipher, but don't currently work because of the antiquity of the sqlcipher version in debian. debian/watch for sqlcipher is also broken. i'm not sure i understand what it was trying to do, but the following patch simplifies things and should make it notice the new upstream versions as well. thanks for maintaining sqlcipher in debian! --dkg diff --git a/debian/watch b/debian/watch index 8c11c50..979e3c8 100644 --- a/debian/watch +++ b/debian/watch @@ -1,4 +1,2 @@ -version=3 -https://github.com/sqlcipher/sqlcipher/tags \ -.*/archive/(?:upstream/)?(?:v||version-|release-|X|R|r|Version_)(\d\S*)\.tar\.gz -# Bart Martens Wed, 22 May 2013 04:56:45 + +version=4 +https://github.com/sqlcipher/sqlcipher/tags .*/v@ANY_VERSION@@ARCHIVE_EXT@ -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#975475: package takes much more space
Hi, On Wed, 09 Dec 2020 06:15:57 +0900 =?UTF-8?Q?Marc_Dequ=C3=A8nes_=28duck=29?= wrote: Control: tags -1 +help Quack, I tried building with LTO but it does not work with problems similar to this: https://sourceware.org/bugzilla/show_bug.cgi?id=12762 I tried the workarounds to no avail. I do not wish to sacrifice the hardening flags just to save some space, knowing that's still a small amount compared to the size of most games. Help welcome. \_o< -- Marc Dequènes Hi, I've found that the dll.so files contains debug info, which is the cause of the large file size. For example, /usr/lib/dxvk/wine64-development/d3d11.dll.so contains these sections: /usr/lib/dxvk/wine64-development/d3d11.dll.so: file format pei-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0021e098 000359051000 000359051000 1000 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 6410 00035927 00035927 0022 2**4 CONTENTS, ALLOC, LOAD, DATA 2 .rdata00067c00 000359277000 000359277000 00227000 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .pdata00017b80 0003592df000 0003592df000 0028f000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .xdata00028bdc 0003592f7000 0003592f7000 002a7000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .bss 2c90 00035932 00035932 2**4 ALLOC 6 .edata00c2 000359323000 000359323000 002d 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .idata1a8c 000359324000 000359324000 002d1000 2**2 CONTENTS, ALLOC, LOAD, DATA 8 .CRT 0060 000359326000 000359326000 002d3000 2**2 CONTENTS, ALLOC, LOAD, DATA 9 .tls 0010 000359327000 000359327000 002d4000 2**2 CONTENTS, ALLOC, LOAD, DATA 10 .rsrc 0340 000359328000 000359328000 002d5000 2**2 CONTENTS, ALLOC, LOAD, DATA 11 .reloc3798 000359329000 000359329000 002d6000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 12 .debug_aranges 7880 00035932d000 00035932d000 002da000 2**0 CONTENTS, READONLY, DEBUGGING 13 .debug_info 07261214 000359335000 000359335000 002e2000 2**0 CONTENTS, READONLY, DEBUGGING 14 .debug_abbrev 000b2dfc 000360597000 000360597000 07544000 2**0 CONTENTS, READONLY, DEBUGGING 15 .debug_line 002524c8 00036064a000 00036064a000 075f7000 2**0 CONTENTS, READONLY, DEBUGGING 16 .debug_frame 000719e0 00036089d000 00036089d000 0784a000 2**0 CONTENTS, READONLY, DEBUGGING 17 .debug_str001521fc 00036090f000 00036090f000 078bc000 2**0 CONTENTS, READONLY, DEBUGGING 18 .debug_loc0097bbcd 000360a62000 000360a62000 07a0f000 2**0 CONTENTS, READONLY, DEBUGGING 19 .debug_ranges 0027bbf0 0003613de000 0003613de000 0838b000 2**0 CONTENTS, READONLY, DEBUGGING From x86_64-w64-mingw32-objdump -h /usr/lib/dxvk/wine64-development/d3d11.dll.so) The debug sections are the cause of the large file size, with debug_info using more than 119 MB. Maybe the debug size wasn't that large without LTO, but given that d3d11 is probably C++ and large, I guess this is expected to have such a large debug info size. Even if these are dll files, maybe a solution would be to split the debug info into a -dbgsym package, the same way this is done on normal Linux packages. I've tried to replicate what dh_strip does (when autogenerating -dbgsym packages), but with mingw's binutils. Moving debug info in a second file works, but there is no build id. The script in attachment will generate a .debug file from a PE executable or DLL and will strip and add a gnu_debuglink to the original file. Usage to test it: $ x86_64-w64-mingw32-gcc -g test.c -o test.exe $ ./strip_debug.sh test.exe $ winedbg --gdb --no-start --port 2345 test.exe & $ gdb test.exe (gdb) target remote localhost:2345 Maybe you can use the commands in the script to generate a separate package manually with debug info (dh_strip won't work with PE files so won't generate -dbgsym packages automatically). When using this script on d3d11.dll.so, I get this resulting file sizes: original d3d11.dll.so: 137M d3d11.dll.so: 2,9M d3d11.dll.so.debug: 134M -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| strip_debug.sh Description: application/shellscript
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Arnd Bergmann dixit: >The way the FPU type gets selected in gcc changed with recent versions, >this was intentional and won't be reverted but it did break packages that >used the old method. Hmph. >In most cases, it's sufficient to pass >-march=armv7-a+fp instead of -march=armv7-a to pick the right >instruction set. There’s no “instead of”, though. So basically, I now need to add -march=… to CFLAGS in the package when compiling for either of armel and armhf. Which value do I use for armel, which for armhf (the one you gave is for armhf, I think)? bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1017576: nautilus-admin: Incompatible with Nautilus 43
Source: nautilus-admin Severity: important Version: 1.1.9-3.1 Tags: patch sid bookworm Control: block 1016988 by -1 Nautilus 43 includes major API changes for Nautilus extensions. Code changes are needed to support this. Here is a merge request with the required changes https://salsa.debian.org/debian/nautilus-admin/-/merge_requests/1 Nautilus 43 and nautilus-python 4 are available in Debian Experimental. Thank you, Jesus Soto
Bug#1017537: Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Arnd Bergmann dixit: >I tried cross-building it myself now and found the same issue with >an older arm-linux-gnueabihf-gcc-11, which invokes the assembler as > >/usr/lib/gcc-cross/arm-linux-gnueabihf/11/../../../../arm-linux-gnueabihf/bin/as >-v -march=armv7-a -mfloat-abi=hard -meabi=5 -o bin-arm/__longjmp.o >longjmp.s > >where the old one would pass an extra -mfpu=vfpv3-d16. Is my expectation that, for any given platform (armel, armhf, arm64), that a default invocation of the system compiler adds the correct flags not good? >However, with arm-linux-gnueabihf-gcc-12, it appears to work fine again. Sounds like a bug in gcc-11 instead then? (Why has this then not hit more packages?) >I also see that the Makefile attempts to detect the host architecture, but >fails to recognize armv8 hardware as arm. What hardware and toolchain >environment was the failing build on? debian/rules inspects DEB_HOST_ARCH and passes MYARCH to the upstream Makefile so this ought to DTRT…ish — arm64 is passed as aarch64, and all other *arm* are passed as arm (though we don’t carry armeb or the pre-EABI arm any more so that’s probably also fine). Note that #1017537 (on armel) and #1017538 (on armhf) probably are, if not the same thing, at least related. bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Bug#1017575: RFP: jless -- command-line JSON viewer
Package: wnpp Severity: wishlist * Package name: jless Version : 0.8.0 Upstream Author : Paul Julius Martinez * URL : https://jless.io/ * License : MIT Programming Lang: Rust Description : command-line JSON viewer jless is a command-line JSON viewer. Use it as a replacement for whatever combination of less, jq, cat and your editor you currently use for viewing JSON files. Features: - Clean syntax highlighted display of JSON data, omitting quotes around object keys, closing object and array delimiters, and trailing commas. - Expand and collapse objects and arrays so you can see both the high- and low-level structure of the data. - A wealth of vim-inspired movement commands for efficiently moving around and viewing data. - Full regex-based search for finding exactly the data you're looking for.
Bug#1017572: git-buildpackage: pq export shouldn't run when on wrong branch
Source: git-buildpackage Version: 0.9.28 Severity: important Test Case Run this command from your master branch: gbp pq export What Happens --- $ gbp pq export gbp:info: Generating patches from git (master..patch-queue/master) gbp:error: patch-queue/master not a valid tree-ish $ git status On branch master Your branch is up to date with 'origin/master'. Changes not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) deleted:debian/patches/fix.patch deleted:debian/patches/series What I Expect -- That's a bit destructive of a command if someone is not paying attention. Occasionally, this will result in Debian patches being silently dropped (!), which I why I'm using a slightly elevated severity for this bug. gbp pq export should error when it's not on a patch-queue branch and not make changes. Or when it's instructed to ignore the branch as proposed in https://bugs.debian.org/915629 Thank you, Jeremy Bicha
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
On Wed, Aug 17, 2022 at 8:00 PM Thorsten Glaser wrote: > > Arnd Bergmann dixit: > > >-march=armv7-a+fp instead of -march=armv7-a to pick the right > > “instead of” > > We pass nothing there, and we need a solution (or two distinct > ones) for armel and armhf. I tried cross-building it myself now and found the same issue with an older arm-linux-gnueabihf-gcc-11, which invokes the assembler as /usr/lib/gcc-cross/arm-linux-gnueabihf/11/../../../../arm-linux-gnueabihf/bin/as -v -march=armv7-a -mfloat-abi=hard -meabi=5 -o bin-arm/__longjmp.o longjmp.s where the old one would pass an extra -mfpu=vfpv3-d16. However, with arm-linux-gnueabihf-gcc-12, it appears to work fine again. I also see that the Makefile attempts to detect the host architecture, but fails to recognize armv8 hardware as arm. What hardware and toolchain environment was the failing build on? Arnd
Bug#1017571: haskell-persistent: FTBFS on 32 bit archs
Source: haskell-persistent
Version: 2.13.3.5-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=haskell-persistent=i386=2.13.3.5-1=1659381639=0
Failures:
test/Database/Persist/THSpec.hs:240:26:
1) Database.Persist.THSpec.HasIdDef should have correct underlying sql type
expected: SqlInt64
but got: SqlInt32
To rerun use: --match "/Database/Persist/THSpec/HasIdDef/should have correct
underlying sql type/"
Randomized with seed 158227830
Finished in 0.1950 seconds
231 examples, 1 failure, 3 pending
Test suite test: FAIL
Test suite logged to: dist-ghc/test/persistent-2.13.3.5-test.log
0 of 1 test suites (0 of 1 test cases) passed.
-e: error: debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct
returned exit code 1
at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 852.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup test
--builddir=dist-ghc --show-details"...) called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 596
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup test
--builddir=dist-ghc --show-details"...) called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 470
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "test",
"--builddir=dist-ghc", "--show-details=direct") called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 678
Debian::Debhelper::Buildsystem::Haskell::Recipes::check_recipe() called
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:165: check-ghc-stamp] Error 25
Cheers
--
Sebastian Ramacher
Bug#1017570: ITP: qt-color-widgets -- Qt widgets to manage color inputs
Package: wnpp Owner: Dima Kogan Severity: wishlist * Package name: qt-color-widgets Version : 2.2.0 Upstream Author : Mattia Basaglia d...@dragon.best * URL or Web page : https://gitlab.com/mattbas/Qt-Color-Widgets * License : LGPL-3+ Description : Qt widgets to manage color inputs
Bug#1017569: urlview: Mangles non-ASCII URLs for display
Package: urlview Version: 0.9-21+b1 Severity: normal Tags: patch Dear Maintainer, I ~often receive URLs that end in a fancy quote (or close enough); this can be reproduced with echo https://example.com/a” | urlview which displays UrlView 0.9: (1 matches) Press Q or Ctrl-C to Quit! ->1 https://example.com/a�~@~] I've narrowed it down to being linked to narrow-character ncurses(??) and am attaching a patch (based on current Salsa) and have opened https://salsa.debian.org/debian/urlview/-/merge_requests/3 Best, наб -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/24 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages urlview depends on: ii libc6 2.31-13+deb11u3 ii libncurses6 6.2+20201114-2 ii libtinfo6 6.2+20201114-2 ii sensible-utils 0.0.14 Versions of packages urlview recommends: ii lynx [www-browser] 2.9.0dev.6-3~deb11u1 ii w3m [www-browser] 0.5.3+git20210102-6 Versions of packages urlview suggests: pn mutt pn ncftp | lftp ii wget 1.21-1+deb11u1 -- no debconf information From 957868f8722c76907840c214d83fca3c86971c9a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= Date: Wed, 17 Aug 2022 22:26:27 +0200 Subject: [PATCH 1/2] d/control: depend on libcurses-dev directly X-Mutt-PGP: OS libncurses5-dev is a "transitional package for libncurses-dev" --- debian/changelog | 3 ++- debian/control | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index 0292d4f..9d83027 100644 --- a/debian/changelog +++ b/debian/changelog @@ -3,8 +3,9 @@ urlview (0.9-23) UNRELEASED; urgency=medium * d/url_handler: don't require bash for no reason, shellcheck-clean * d/README.Debian: align with reality w.r.t. url_handler.sh Closes: #1017562 + * d/control: depend on libcurses-dev directly - -- наб Wed, 17 Aug 2022 21:42:22 +0200 + -- наб Wed, 17 Aug 2022 22:28:38 +0200 urlview (0.9-22) unstable; urgency=medium diff --git a/debian/control b/debian/control index 527952d..e7384b5 100644 --- a/debian/control +++ b/debian/control @@ -5,7 +5,7 @@ Maintainer: Emanuele Rocca Standards-Version: 4.2.0 Vcs-Browser: https://salsa.debian.org/debian/urlview Vcs-Git: https://salsa.debian.org/debian/urlview.git -Build-Depends: libncurses5-dev, debhelper (>= 13) +Build-Depends: libncurses-dev, debhelper (>= 13) Package: urlview Architecture: any -- 2.30.2 From 6a2f08ab28343e8c5b7c7ab4a64f09beb913fd91 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= Date: Wed, 17 Aug 2022 22:33:38 +0200 Subject: [PATCH 2/2] Link against libncursesw, setlocale(LC_ALL, "") MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mutt-PGP: OS On https://example.com/a” (i.e. a fancy quote), urlview with narrow-character curses makes an absolute hash of it, by writing it as: https://example.com/a�~@~] When linked against the wide-character ncurses, it displays it exactly as expected, in the original form. --- configure.in | 2 +- debian/changelog | 3 ++- urlview.c| 3 +++ 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/configure.in b/configure.in index 45e4e89..7bbd68e 100644 --- a/configure.in +++ b/configure.in @@ -24,7 +24,7 @@ AC_ARG_WITH(slang, [ --with-slang[=DIR] use S-Lang instead of curses], LIBS="$LIBS -lslang -lm" fi], - [AC_CHECK_LIB(ncurses, initscr, [LIBS="$LIBS -lncurses"], [LIBS="$LIBS -lcurses"]) + [AC_CHECK_LIB(ncursesw, initscr, [LIBS="$LIBS -lncursesw"], [LIBS="$LIBS -lcurses"]) AC_CHECK_FUNCS(curs_set) AC_CHECK_HEADERS(ncurses.h) AC_CHECK_HEADER(ncurses/curses.h, [CPPFLAGS="$CPPFLAGS -I/usr/include/ncurses"])]) diff --git a/debian/changelog b/debian/changelog index 9d83027..ffe47ea 100644 --- a/debian/changelog +++ b/debian/changelog @@ -4,8 +4,9 @@ urlview (0.9-23) UNRELEASED; urgency=medium * d/README.Debian: align with reality w.r.t. url_handler.sh Closes: #1017562 * d/control: depend on libcurses-dev directly + * Link against libncursesw, fixing display of non-ASCII URLs - -- наб Wed, 17 Aug 2022 22:28:38 +0200 + -- наб Wed, 17 Aug 2022 22:39:23 +0200 urlview (0.9-22) unstable; urgency=medium diff --git a/urlview.c b/urlview.c index 9281bbb..7b28408 100644 --- a/urlview.c +++ b/urlview.c @@ -32,6 +32,7 @@ #endif /* USE_SLANG */ #include +#include #include #include #include @@ -144,6 +145,8 @@ void search_backward (char *search, int urlcount,
Bug#1009982: pius ITA
On Thu, Aug 18, 2022 at 4:39 AM Louis-Philippe Véronneau wrote: > > Hi, > > Do you still plan on adopting this package? I'm a pius user and I'd be > glad to maintain this package under the Debian Python Team. > Yes. Since the package is currently in good shape, I didn't take any action yet. I'm fine if you take it over too. -- Shengjing Zhu
Bug#1017112: libdatetime-timezone-perl 2.23-1+2022b flagged for acceptance
package release.debian.org tags 1017112 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: libdatetime-timezone-perl Version: 2.23-1+2022b Explanation: update included data
Bug#1009982: pius ITA
Hi, Do you still plan on adopting this package? I'm a pius user and I'd be glad to maintain this package under the Debian Python Team. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1017506: [Debian-on-mobile-maintainers] Bug#1017506: phosh: Swipping UP froze the UI and require phosh restart
Guido Günther writes: > control: -1 forwarded > https://gitlab.gnome.org/World/Phosh/phosh/-/issues/818 > thanks Thanks, as a workaround I did a: gsettings set org.gnome.desktop.interface enable-animations true And it works perfectly fine. Thanks. -- Daniel Dehennin Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF Fingerprint: 3E69 014E 5C23 50E8 9ED6 2AAD CC1E 9E5B 7A6F E2DF signature.asc Description: PGP signature
Bug#1016687: Clarification Needed
On Tue, 16 Aug 2022 14:06:56 +0200 Victor Jaquez wrote: > > In that case intel-media-va-driver and i965-va-driver wouldn't be > distributed either. > > If I understand correctly, they are distributed because they don't > contain the codec logic, only the data structures. The logic is > defined somewhere else (gpu firmware or other blobs). > > vmjl > Yes, after more research, I agree with this, and for more background, see: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15258 If Debian doesn't ship the firmware, there is no issue. Please enable the codec support as Debian/mesa has been doing this by default up until the option was created.
Bug#1006788: bagel: autopkgtest failure with new mpich.
Control: severity -1 serious Control: retitle -1 autopkgtest fails on hosts with lots of RAM/cores Hi, On Sun, 3 Apr 2022 19:42:42 +0200 Michael Banck wrote: Hrm, it seems that test case passed now on the latest upload: https://ci.debian.net/data/autopkgtest/unstable/amd64/b/bagel/20573831/log.gz |Get:14 http://deb.debian.org/debian unstable/main amd64 libmpich12 amd64 4.0.1-1 [4,924 kB] [...] |running test case 'he3_svp_asd-dmrg'... PASSED. So I'm a bit at a loss about what's going on here, perhaps that test case really is just flakey. Yes, this test looks flaky (I came here because it was blocking glibc). The good news is however, it seems related to the host that runs the test. I.e. the test fails on our beefy amd64 host (ci-worker13) with 64 cores and 256GB RAM, but seems to pass on the others. The error on s390x is the same by the way (that has 10 cores and 32GB RAM). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1017567: ITP: elpa-marginalia -- Marginalia in the Emacs minibuffer
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-marginalia Version : 0.13 Upstream Author : Daniel Mendler, Omar Antolín Camarena * URL or Web page : https://github.com/minad/marginalia * License : GPL-3+ Programming Lang: Emacs Lisp Description : Marginalia in the Emacs minibuffer This is a package providing useful annotations in the minibuffer based on the completion category. Aymeric Agon-Rambosson
Bug#1017566: ITP: elpa-marginalia -- Marginalia in the Emacs minibuffer
Package: wnpp Owner: Aymeric Agon-Rambosson Severity: wishlist * Package name: elpa-marginalia Version : 0.13 Upstream Author : Daniel Mendler, Omar Antolín Camarena * URL or Web page : https://github.com/minad/marginalia * License : GPL-3+ Programming Lang: Emacs Lisp Description : Marginalia in the Emacs minibuffer This is a package that provides useful annotations in the Emacs minibuffer. Aymeric Agon-Rambosson
Bug#1017565: crysal: FTBFS everywhere
Source: crystal
Version: 1.3.2+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=crystal=amd64=1.3.2%2Bdfsg-1=1660695991=0
Failures:
1) Crystal::Loader .parse parses file paths
Failure/Error: expect_raises(Crystal::Loader::LoadError,
/#{Dir.current}\/foobar\.o.+(No such file or directory|image not found)/) do
Expected Crystal::Loader::LoadError with message matching
/\/build\/crystal-oKAM1A\/crystal-1.3.2+dfsg\/foobar\.o.+(No such file or
directory|image not found)/, got #>/foobar.o: cannot open shared object file: No such file or
directory> with backtrace:
# src/compiler/crystal/loader/unix.cr:59:25 in 'parse:search_paths'
# src/spec/expectations.cr:422:12 in '->'
# src/primitives.cr:266:3 in 'internal_run'
# src/spec/example.cr:33:16 in 'run'
# src/spec/context.cr:18:23 in 'internal_run'
# src/spec/context.cr:337:14 in 'run'
# src/spec/context.cr:18:23 in 'internal_run'
# src/spec/context.cr:337:14 in 'run'
# src/spec/context.cr:18:23 in '->'
# src/array.cr:1273:5 in 'main'
# /lib/x86_64-linux-gnu/libc.so.6 in '??'
# /lib/x86_64-linux-gnu/libc.so.6 in '__libc_start_main'
# .build/compiler_spec in '_start'
# ???
# spec/compiler/loader/unix_spec.cr:31
Finished in 14:37 minutes
10296 examples, 1 failures, 0 errors, 15 pending
Failed examples:
crystal spec spec/compiler/loader/unix_spec.cr:30 # Crystal::Loader .parse
parses file paths
make[2]: *** [Makefile:108: compiler_spec] Error 1
Cheers
--
Sebastian Ramacher
Bug#1017564: consul: FTBFS on armel
Source: consul Version: 1.8.7+dfsg1-5 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=consul=armel=1.8.7%2Bdfsg1-5%2Bb2=1660745521=0 === RUN TestGenerateCert generate_test.go:101: DM-skipped --- SKIP: TestGenerateCert (0.00s) === CONT TestGeneratePrivateKey === CONT TestGenerateCA --- PASS: TestGeneratePrivateKey (0.01s) --- PASS: TestGenerateCA (0.02s) PASS ok github.com/hashicorp/consul/tlsutil 1.715s ? github.com/hashicorp/consul/types [no test files] ? github.com/hashicorp/consul/version [no test files] FAIL dh_auto_test: error: cd _build && go test -vet=off -v -p 2 -short -failfast -timeout 8m github.com/hashicorp/consul github.com/hashicorp/consul/acl github.com/hashicorp/consul/command github.com/hashicorp/consul/command/acl github.com/hashicorp/consul/command/acl/authmethod github.com/hashicorp/consul/command/acl/authmethod/create github.com/hashicorp/consul/command/acl/authmethod/delete github.com/hashicorp/consul/command/acl/authmethod/list github.com/hashicorp/consul/command/acl/authmethod/read github.com/hashicorp/consul/command/acl/authmethod/update github.com/hashicorp/consul/command/acl/bindingrule github.com/hashicorp/consul/command/acl/bindingrule/create github.com/hashicorp/consul/command/acl/bindingrule/delete github.com/hashicorp/consul/command/acl/bindingrule/list github.com/hashicorp/consul/command/acl/bindingrule/read github.com/hashicorp/consul/command/acl/bindingrule/update github.com/hashicorp/consul/command/acl/bootstrap github.com/hashicorp/consul/command/acl/policy github.com/hashicorp/consul/command/acl/policy/create github.com/hashicorp/consul/command/acl/policy/delete github.com/hashicorp/consul/command/acl/policy/list github.com/hashicorp/consul/command/acl/policy/read github.com/hashicorp/consul/command/acl/policy/update github.com/hashicorp/consul/command/acl/role github.com/hashicorp/consul/command/acl/role/create github.com/hashicorp/consul/command/acl/role/delete github.com/hashicorp/consul/command/acl/role/list github.com/hashicorp/consul/command/acl/role/read github.com/hashicorp/consul/command/acl/role/update github.com/hashicorp/consul/command/acl/rules github.com/hashicorp/consul/command/acl/token github.com/hashicorp/consul/command/acl/token/clone github.com/hashicorp/consul/command/acl/token/create github.com/hashicorp/consul/command/acl/token/delete github.com/hashicorp/consul/command/acl/token/list github.com/hashicorp/consul/command/acl/token/read github.com/hashicorp/consul/command/acl/token/update github.com/hashicorp/consul/command/catalog github.com/hashicorp/consul/command/catalog/list/dc github.com/hashicorp/consul/command/catalog/list/nodes github.com/hashicorp/consul/command/catalog/list/services github.com/hashicorp/consul/command/config github.com/hashicorp/consul/command/config/delete github.com/hashicorp/consul/command/config/list github.com/hashicorp/consul/command/config/read github.com/hashicorp/consul/command/config/write github.com/hashicorp/consul/command/connect github.com/hashicorp/consul/command/connect/ca github.com/hashicorp/consul/command/connect/ca/get github.com/hashicorp/consul/command/connect/ca/set github.com/hashicorp/consul/command/connect/expose github.com/hashicorp/consul/command/connect/proxy github.com/hashicorp/consul/command/event github.com/hashicorp/consul/command/forceleave github.com/hashicorp/consul/command/helpers github.com/hashicorp/consul/command/info github.com/hashicorp/consul/command/intention github.com/hashicorp/consul/command/intention/check github.com/hashicorp/consul/command/intention/create github.com/hashicorp/consul/command/intention/delete github.com/hashicorp/consul/command/intention/finder github.com/hashicorp/consul/command/intention/get github.com/hashicorp/consul/command/intention/match github.com/hashicorp/consul/command/join github.com/hashicorp/consul/command/keygen github.com/hashicorp/consul/command/keyring github.com/hashicorp/consul/command/kv github.com/hashicorp/consul/command/kv/del github.com/hashicorp/consul/command/kv/exp github.com/hashicorp/consul/command/kv/get github.com/hashicorp/consul/command/kv/imp github.com/hashicorp/consul/command/kv/impexp github.com/hashicorp/consul/command/kv/put github.com/hashicorp/consul/command/leave github.com/hashicorp/consul/command/lock github.com/hashicorp/consul/command/login github.com/hashicorp/consul/command/logout github.com/hashicorp/consul/command/maint github.com/hashicorp/consul/command/members github.com/hashicorp/consul/command/operator github.com/hashicorp/consul/command/operator/autopilot github.com/hashicorp/consul/command/operator/autopilot/get github.com/hashicorp/consul/command/operator/autopilot/set github.com/hashicorp/consul/command/operator/raft
Bug#1017563: RM: theseus [arm64 armel armhf mips64el mipsel ppc64el s390x alpha hppa hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k powerpc ppc64 riscv64 sh4 sparc64 x32] -- ROM; has a dependency av
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, theseus depends on muscle, which is only available on Intel architectures at the moment, see bug #1006161 which led to the removal of muscle on non-Intel arches. Could you please proceed to the removal of theseus from all architectures except amd64 and i386? Thanks a lot for your help, Best regards, - -- Pierre -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEM8soQxPpC9J9y0UjYAMWptwndHYFAmL9R24PHHBndEBkZWJp YW4ub3JnAAoJEGADFqbcJ3R2y7wQAIcWOrPaRQl0H5hS00TxWCfJCQCYXCWKUspB UYfw7cYxMCpVeALbV0gPWnPZ6AxmNVOk6KSd6izGW6wVeFFcBG387mw6h7eMp6al rCWeC8Q/Zc2DHYyTLDM0hkA0DJPoE1tQxIRz9aZN7np8AAW+hOfLtUIMvJinfWwd Q4+3OPyFR7ny2SBVPxNtCsq2+44DgPecUrCJsrY7yS/vnHH56HSiFhPOEfzsoGGz uc+2nBeqC/M9qOsNuQmQG1kM7/+s7rSNHfocmjcWKY+Lyac6Yp4gJ4O0FIHtrNir 2T0hp8Lx71kKOxvJb7DNv2ILusWLK0k6mfSEc0og7BB3UGsUaxux8gkGO3yCCw4L Ya6OM/Yfa2qNTV+p+tg6C01e3lZefKjK8K4R/vtkjAs1pyFjb5spwgY2bgSHT8Hd a7ZFg6apqM6ximjz46DipXR+dn88Zi/+V6AH7IXv35xFMyPd015SFjmEFX1BMlL8 Dt/8riOXPjLb7WFf75EAe88vzADh28yuIqwDfX4Lpbl9OXPxk33QIoiUESi2faCb y66q/1+TOeQqoFS1L1FKC1Q+REW02emGIQ7VDyx16jltQbE8eJdotzBOm60iMbt+ FkqbheCNMawe9n8ltdCM9mPz6CT0puU6D3h/suaYgAvBr5n69t9au6DwfzIHzCwL OXKra+s3 =gHD7 -END PGP SIGNATURE-
Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles
Am 16.08.22 um 20:35 schrieb Simon McVittie:
On Tue, 16 Aug 2022 at 18:46:33 +0200, Adam Borowski wrote:
On Tue, Aug 16, 2022 at 03:13:35PM +0100, Luca Boccassi wrote:
On Tue, 16 Aug 2022 13:13:53 +0200 Johannes Schauer Marin Rodrigues
The package passwd=1:4.11.1+dfsg1-2 in the archive does not have the
dependency on "systemd | systemd-tmpfiles" and was compiled with
debhelper 13.6.
This currently installs systemd on a systems that don't need it
This looks entirely correct to me. You can install the -standalone
variant if you prefer a slightly smaller footprint, which is provided
exactly for those non-default use cases.
No, the "passwd" package does not need systemd (nor its -standalone subset
as evidenced by currently working fine).
Some Technical Committee members had a brief informal discussion of this
bug report, in an attempt to avoid it getting escalated to us later when
everyone is already (more) upset. This message is from me personally,
without a TC hat, and does not reflect a consensus.
I've had discussions similar to this one as a dbus maintainer, since
dbus-daemon is another package with a tmpfiles.d fragment that is
affected by this change. I don't think this is as simple as either of
the two obvious opposing viewpoints:
- this dependency is always OK, take no action
- this dependency is always wrong, revert the feature completely
Many packages install tmpfiles.d fragments, with varying levels of
dependency on the directives from those files being processed: for some
packages it's a requirement, while for other packages it's a nice-to-have.
I do not have an informed opinion on which category shadow is in. For dbus,
it's certainly a nice-to-have.
Historically, debhelper generated maintainer script snippets that
would process tmpfiles.d if and only if booted into systemd, meaning
that any package wanting to be able to require/assume the presence
of a transient file/directory on non-systemd systems (whether that
means a chroot/container with no init at all, or a non-systemd init
like sysvinit) had to be prepared to create the file/directory using a
redundant non-tmpfiles.d mechanism; and similarly, any package wanting
to be able to rely on cruft files getting cleaned up (which seems to
be shadow's use-case for this) had to be prepared to remove those files
with a redundant non-tmpfiles.d mechanism.
The change that has triggered this report is that since debhelper 13.8,
debhelper generates maintainer script snippets that process tmpfiles.d
unconditionally, with a dependency on systemd | systemd-tmpfiles in order
to be able to do that.
If it wasn't for its dependency implications, I would be saying that
we should be making *more* use of tmpfiles.d and similar declarative
mechanisms over time: a declarative syntax for the transient files that
we want to create and/or clean up seems like a win. tmpfiles.d fragments
also seem like a useful way to associate transient files with the package
that "owns" them, analogous to %ghost files in RPM. So I would like to
avoid issues like this one making maintainers reluctant to use tmpfiles
in situations where they're non-critical.
I think it would make sense for dh_installtmpfiles to have two modes:
- Assume tmpfiles.d snippets are required for the package's functionality
- Generate a dependency on a tmpfiles.d implementation
- Run it unconditionally
- Assume tmpfiles.d snippets are nice-to-have
- Generate a Suggests or Recommends on a tmpfiles.d implementation,
or no dependency relationship at all
- Only run it if one is installed
Something analogous to dpkg-shlibdeps default behaviour vs.
dpkg-shlibdeps -dRecommends (or Suggests) might make sense, although
that would be ineffective unless affected packages add ${misc:Recommends}
or ${misc:Suggests} (as appropriate) to the relevant control field.
I do not currently have a strong opinion on which of those should be
the default if a maintainer takes no particular action, but I think both
the strong dependency and the weak (or no) dependency should be possible.
For low-level packages like shadow and dbus, I think it would make
sense to configure those packages for the "tmpfiles.d snippets are
nice-to-have" mode if that is compatible with those packages' needs,
even if it is not the default.
It might also be useful to have a third mode that is equivalent to what
happened before 13.8: assume that tmpfiles.d snippets are desirable on
systemd-booted systems, but either unnecessary or actively harmful on
non-systemd-booted systems. I think this mode probably should not be the
default, but it could be used by maintainers who are aware that their
package's tmpfiles.d content makes systemd-specific assumptions.
smcv
Looking at the package in question
$ cat debian/passwd.tmpfiles
# If a password operation is in progress and we lose power, stale lockfiles
# can be left behind. Clear them on boot.
r! /etc/gshadow.lock
r! /etc/shadow.lock
r! /etc/passwd.lock
r!
Bug#1017537: dietlibc: FTBFS on armel: illegal instruction
Sebastian Ramacher dixit: >This is already an issue with 0.34~cvs20160606-12. It’s an incompatible toolchain change that broke this package. I’m trying to find out why, but the ARM porters are not helpful. bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (406 (433) bugs: 0 RC, 275 (295) I, 131 (138) M, 0 F) + 208 ‣ src:dash (91 (106) bugs: 0 RC, 51 (55) I, 40 (51) M, 0 F) + 63 ubu ‣ src:mksh (1 bug: 0 RC, 0 I, 1 M, 0 F) dash has two RC bugs they just closed because they don’t care about quality…
Bug#975016: #975016 - OpenJDK 17 support state for Bullseye
Hi Holger, On Wed, Aug 17, 2022 at 10:47:25AM +, Holger Levsen wrote: > hi, > > as both openjdk-11 and openjdk-17 have received security updates and > as I understand this very bug report, we can close this bug as nothing > regarding the security-status of openjdk-(11|17) in bullseye needs to > be documented right now, as they are both supported. Sort of. Just for exanding the context, there is a note about it in https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#limited-security-support . Moritz might give a better overview though than me. Regards, Salvatore
Bug#1017559: aqsis TBFS with openexr 3.1.5
Source: aqsis Version: 1.8.2+git20210815-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=aqsis=1.8.2%2Bgit20210815-1%2Bb2 ... CMake Error at libs/shadervm/CMakeLists.txt:5 (message): Aqsis shadervm requires boost regex and OpenEXR to build -- Configuring incomplete, errors occurred! ... //Location of the Half OpenEXR library AQSIS_HALF_LIBRARY:FILEPATH=AQSIS_HALF_LIBRARY-NOTFOUND //Location of the Iex OpenEXR library AQSIS_IEX_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libIex.so //Location of the IlmImf OpenEXR library AQSIS_ILMIMF_LIBRARY:FILEPATH=AQSIS_ILMIMF_LIBRARY-NOTFOUND //Location of the IlmThread OpenEXR library AQSIS_ILMTHREAD_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libIlmThread.so //Location of the Imath OpenEXR library AQSIS_IMATH_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libImath.so //Name of the main aqsis configuration file AQSIS_MAIN_CONFIG_NAME:STRING=aqsisrc //Location of the NSIS executable AQSIS_NSIS_EXECUTABLE:FILEPATH=AQSIS_NSIS_EXECUTABLE-NOTFOUND //Location of the OpenEXR headers AQSIS_OPENEXR_INCLUDE_DIR:PATH=/usr/include //Semi-colon separated list of paths to search for openexr libraries AQSIS_OPENEXR_LIBRARIES_DIR:PATH= ...
Bug#1017509: matrix-synapse: Service won't started after upgrade
Control: tag -1 moreinfo Hi, On Wed, 17 Aug 2022, at 11:18, joffrey575 wrote: > I have upgrade matrix-synapse in 1.63.0-1~bpo11+1 version from the old n-1. > > After this, the service won't started. > > I give it to you journalctl logs as follow. > > After discuss in synapse channel on website https://app.element.io, > they said it's a problem can came from python3-matrix-common. > ii python3-matrix-common 1.2.1-1~bpo11+1 This is not supposed to happen, you have the latest version installed. Could you please double-check and try and find out more? Thanks! -- Cheers, Andrej
Bug#1017558: libboost-filesystem-dev: boost::filesystem::copy_file() throws "Invalid cross-device link"
Package: libboost-filesystem-dev Version: 1.74.0.3 Severity: normal X-Debbugs-Cc: offri...@gmail.com Dear Maintainer, Version 1.74 of boost filesystem contains a bug that causes copy_file() to misbehave. The issue has been filed upstream (https://github.com/boostorg/filesystem/issues/254), and it's supposed to be fixed in later version of Boost. The means that upgrading should fix it. Regards, André -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libboost-filesystem-dev depends on: ii libboost-filesystem1.74-dev 1.74.0-16.1 libboost-filesystem-dev recommends no packages. libboost-filesystem-dev suggests no packages. -- no debconf information
Bug#1017557: libmilter1.0.1: Missing symlinks to libmilter.so.1.0.1
Package: libmilter1.0.1 Version: 8.15.2-22 Severity: important Dear Maintainer, * What led up to the situation? Trying to use a pre-compiled binary for `ctmilter`, an application that dynalinks with `libmilter`. * What exactly did you do (or not do) that was effective (or ineffective)? The application wouldn't start because it failed to find `libmilter.so.1`. Checking with $ ldd ./ctmilter.bin linux-vdso.so.1 (0x7ffd14911000) libmilter.so.1.0 => not found libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f07c7812000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f07c76ce000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f07c76b4000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f07c7692000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f07c74cd000) /lib64/ld-linux-x86-64.so.2 (0x7f07c79e7000) led me to look at the contents of package `libmilter1.0.1` $ dpkg -L libmilter1.0.1 /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libmilter.so.1.0.1 /usr/share /usr/share/bug /usr/share/bug/libmilter1.0.1 /usr/share/bug/libmilter1.0.1/control /usr/share/bug/libmilter1.0.1/script /usr/share/doc /usr/share/doc/libmilter1.0.1 /usr/share/doc/libmilter1.0.1/README.gz /usr/share/doc/libmilter1.0.1/changelog.Debian.gz /usr/share/doc/libmilter1.0.1/changelog.gz /usr/share/doc/libmilter1.0.1/copyright and then tried # cd /usr/lib/x86_64-linux-gnu # ln -s libmilter.so.1.0.1 libmilter.so.1.0 $ ldd ./ctmilter.bin linux-vdso.so.1 (0x7ffc71dd8000) libmilter.so.1.0 => /lib/x86_64-linux-gnu/libmilter.so.1.0 (0x7fc3c7e99000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fc3c7ccc000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fc3c7b88000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fc3c7b6e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fc3c7b4c000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc3c7987000) /lib64/ld-linux-x86-64.so.2 (0x7fc3c7eb4000) After that, `ctmilter` worked fine. * What outcome did you expect instead? After reading Debian Policy, specifically https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime I believe the package is missing symlinks libmilter.so.1 -> libmilter.so.1.0.1 libmilter.so.1.0 -> libmilter.so.1.0.1 -- Package-specific info: Output of /usr/share/bug/libmilter1.0.1/script: ls -alR /etc/mail: /etc/mail: total 348 drwxr-sr-x 7 smmta smmsp 4096 Sep 4 2021 . drwxr-xr-x 187 root root 12288 Aug 17 12:02 .. -rwxr-xr-- 1 root smmsp 10016 Sep 4 2021 Makefile -rw--- 1 root root 4265 Sep 4 2021 access -rw-r- 1 smmta smmsp 12288 Sep 4 2021 access.db -rw-r--r-- 1 root root281 Aug 25 2019 address.resolve lrwxrwxrwx 1 root smmsp10 Sep 14 2019 aliases -> ../aliases -rw-r- 1 smmta smmsp 12288 Sep 4 2021 aliases.db -rw-r--r-- 1 root root 3223 Sep 4 2021 databases -rw-r--r-- 1 root root 5659 Aug 25 2019 helpfile -rw-r--r-- 1 root smmsp32 Sep 14 2019 local-host-names drwxr-sr-x 2 smmta smmsp 4096 Sep 14 2019 m4 drwxr-xr-x 2 root root 4096 Sep 4 2021 peers drwxr-xr-x 2 root smmsp 4096 Aug 25 2019 sasl -rw-r--r-- 1 root smmsp 65170 Sep 4 2021 sendmail.cf -rw-r--r-- 1 root root 65313 Sep 4 2021 sendmail.cf.old -rw-r--r-- 1 root root 12235 Sep 4 2021 sendmail.conf -rw-r--r-- 1 root smmsp 4235 Sep 4 2021 sendmail.mc -rw-r--r-- 1 root root148 Aug 25 2019 service.switch -rw-r--r-- 1 root root179 Aug 25 2019 service.switch-nodns drwxr-sr-x 2 smmta smmsp 4096 Sep 4 2021 smrsh -rw-r--r-- 1 root smmsp 44527 Sep 4 2021 submit.cf -rw-r--r-- 1 root root 44662 Sep 4 2021 submit.cf.old -rw-r--r-- 1 root smmsp 2383 Sep 4 2021 submit.mc drwxr-xr-x 2 smmta smmsp 4096 Sep 14 2019 tls -rw-r--r-- 1 root smmsp 0 Sep 14 2019 trusted-users /etc/mail/m4: total 8 drwxr-sr-x 2 smmta smmsp 4096 Sep 14 2019 . drwxr-sr-x 7 smmta smmsp 4096 Sep 4 2021 .. -rw-r- 1 root smmsp0 Sep 14 2019 dialup.m4 -rw-r- 1 root smmsp0 Sep 14 2019 provider.m4 /etc/mail/peers: total 12 drwxr-xr-x 2 root root 4096 Sep 4 2021 . drwxr-sr-x 7 smmta smmsp 4096 Sep 4 2021 .. -rw-r--r-- 1 root root 328 Aug 25 2019 provider /etc/mail/sasl: total 8 drwxr-xr-x 2 root smmsp 4096 Aug 25 2019 . drwxr-sr-x 7 smmta smmsp 4096 Sep 4 2021 .. /etc/mail/smrsh: total 8 drwxr-sr-x 2 smmta smmsp 4096 Sep 4 2021 . drwxr-sr-x 7 smmta smmsp 4096 Sep 4 2021 .. lrwxrwxrwx 1 root smmsp 32 Sep 4 2021 mail.local -> /usr/libexec/sendmail/mail.local lrwxrwxrwx 1 root smmsp 17 Sep 14 2019 procmail -> /usr/bin/procmail /etc/mail/tls: total 48 drwxr-xr-x 2 smmta smmsp 4096 Sep 14 2019 . drwxr-sr-x 7
Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE
Am 17.08.22 um 19:18 schrieb Nelson G: Package: systemd Version: 247.3-7 Severity: normal Dear Maintainer, After installing debian 11 with luks2 encryption I noticed the restarting and powering off processes took a few seconds more than the average compared to my other debian systems without encrypted partitions, I noticed that in the last moment, my screen would print the following: Detaching DM devices Not all DM devices detached, 1 left. Detaching DM devices Not all DM devices detached, 1 left. Cannot finalize remaining DM devices, continuing. Failed to finalize DM devices, ignoring. then I found this on my journalctl ago 17 13:48:49 vm systemd-cryptsetup[764]: Device vda5_crypt is still in use. ago 17 13:48:49 vm systemd-cryptsetup[764]: Failed to deactivate: Device or resource busy ago 17 13:48:49 vm systemd[1]: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE ago 17 13:48:49 vm systemd[1]: systemd-cryptsetup@vda5_crypt.service: Failed with result 'exit-code'. Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.140 Can you try dracut as your initramfs generator? It supports http://systemd.io/INITRD_INTERFACE/ Specifically this part should be relevant to you: " If the executable /run/initramfs/shutdown exists systemd will use it to jump back into the initrd on shutdown. /run/initramfs/ should be a usable initrd environment to which systemd will pivot back and the shutdown executable in it should be able to detach all complex storage that for example was needed to mount the root file system. " OpenPGP_signature Description: OpenPGP digital signature
Bug#1008684: Aw: Re: Bug#1008684: openvswitch-switch update leaves interfaces down
> Use auto...On Aug 17, 2022 18:02, topro wrote: Ok, now I sacrificed one of my affected hosts by migrating away any guests and putting it in a place where I got access to physical keeyboard and screen, so I have a playground for testing. I tried any combination of auto and/or allow-ovsbr1 I could imagine. The outcome is always the same. I tested further and noticed that I do not need to do an actual update to break my network config but a simple "service openvswitch-switch restart" already is enough. To be more precise, when I do a "service openvswitch-switch stop", it won't touch my networking config. Only after subsequent "service openvswitch-switch start" all my configured interfaces are down. I do need auto on the bridge and [auto|allow ovsbr1] to have a working network after boot. But whatever I do, after openvswitch restart my interfaces are down. I also tried packages from stable-backports, no change. Yet, this config did work fine on older versions of openvswitch. Interrestingly enough there seems to be a related bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989720#41 featuring an interresting statement: "Yeah. FYI, I'm about to release 2.17.x in Debian. I'll make sure it closes this bug." Is there any chance I would need to wait for 2.17 to get that issue resolved? I'm sorry I cannot try with 2.17 packages from experimental as that has way too many dependencies to testing/sid packages. Now that I have a testground, is there anything you would like me to test in order to track down this issue? Best regards, topro
Bug#1017556: src:redis: fails to migrate to testing for too long: autopkgtest regressions
Source: redis Version: 5:6.0.16-4 Severity: serious Control: close -1 5:7.0.4-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:redis has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package is a key package and so is python-fakeredis. Hence, the autopkgtest regression won't be fixed by autoremoval. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=redis OpenPGP_signature Description: OpenPGP digital signature
Bug#1017547: openexr-viewers FTBFS with openexr 3.1.5
Hi Pino ! Since openexr-viewers does not build anymore against openexr 3.x and it is dead upstream, do you want me to fill in a RM for you ? Thanks
Bug#1017555: Let's drop win32-loader from amd64/i386 and multiarch CDs
Package: debian-cd Version: 3.1.35 Severity: normal Tags: d-i X-Debbugs-Cc: win32-loa...@packages.debian.org Following the recent discussion on d-boot [1], it seems we agreed to drop win32-loader from the Debian CDs, as it's not likely to be very useful these days. win32-loader seems also present on debian-installer [2], I'll therefore clone the bug. As for the win32-loader package, its network version [3] is still probably useful, and doesn't take much space on mirrors; let's keep it. Best, OdyX [1] https://lists.debian.org/debian-boot/2022/07/msg00083.html [2] https://d-i.debian.org/daily-images/amd64/20220817-00:19/build_cdrom_gtk.log -- System Information: Debian Release: bookworm/sid APT prefers buildd-unstable APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debian-cd depends on: ii apt2.5.2 ii bc 1.07.1-3+b1 ii bzip2 1.0.8-5 ii cpp4:12.1.0-3 ii curl 7.84.0-2 ii dctrl-tools [grep-dctrl] 2.24-3+b1 ii dpkg-dev 1.21.9 ii genisoimage9:1.1.11-3.4 pn libcompress-zlib-perl pn libdigest-md5-perl ii libdpkg-perl 1.21.9 pn libfile-slurp-perl ii libyaml-libyaml-perl 0.83+ds-1+b1 ii lynx 2.9.0dev.10-1 ii make 4.3-4.1 ii perl [libdigest-sha-perl] 5.34.0-5 ii tofrodos 1.7.13+ds-5 ii wget 1.21.3-1+b2 ii xorriso1.5.4-2 Versions of packages debian-cd recommends: ii dosfstools 4.2-1 pn hfsutils ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii mtools 4.0.33-1+really4.0.32-1 ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3 debian-cd suggests no packages.
Bug#1017537: dietlibc: FTBFS on armel: illegal instruction
Control: found -1 0.34~cvs20160606-12 Control: tags -1 sid bookworm On 2022-08-17 18:54:38 +0200, Sebastian Ramacher wrote: > Source: dietlibc > Version: 0.34~cvs20160606-14 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: sramac...@debian.org > > https://buildd.debian.org/status/fetch.php?pkg=dietlibc=armel=0.34%7Ecvs20160606-14=1658293281=0 > > > RUN ERROR for debian/unittests/tc523086.c in variant pthreads (rc = 132), > test output is: > > Illegal instruction > This is already an issue with 0.34~cvs20160606-12. Cheers > > > RUN ERROR for debian/unittests/t-ascii1.c in variant pthreads (rc = 132), > test output is: > > Illegal instruction > > > > RUN ERROR for debian/unittests/signal.c in variant pthreads (rc = 132), test > output is: > > Illegal instruction > > > > RUN ERROR for debian/unittests/gettimeofday.c in variant pthreads (rc = 132), > test output is: > > Illegal instruction > > > > RUN ERROR for debian/unittests/socketfns.c in variant pthreads (rc = 132), > test output is: > > Illegal instruction > > > > RUN ERROR for test/bsearch.c in variant pthreads (rc = 132), test output is: > > Illegal instruction > > > > RUN ERROR for test/fadvise.c in variant pthreads (rc = 132), test output is: > > Illegal instruction > > > > RUN ERROR for test/mmap_test.c in variant pthreads (rc = 132), test output is: > > Illegal instruction > > > > RUN ERROR for test/stdarg.c in variant pthreads (rc = 132), test output is: > > Illegal instruction > > > > RUN ERROR for test/ungetc.c in variant pthreads (rc = 132), test output is: > > Illegal instruction > > > > RUN ERROR for test/utime.c in variant pthreads (rc = 132), test output is: > > Illegal instruction > > > > RUN ERROR for test/waitpid.c in variant pthreads (rc = 132), test output is: > > Illegal instruction > > > > RUN ERROR for test/dirent/opendir-tst1.c in variant pthreads (rc = 132), test > output is: > > Illegal instruction > > > > RUN ERROR for test/stdlib/tst-calloc.c in variant pthreads (rc = 132), test > output is: > > Illegal instruction > > > make[1]: *** [debian/rules:105: override_dh_auto_test-arch] Error 1 > make[1]: Leaving directory '/<>' > > > Cheers > -- > Sebastian Ramacher -- Sebastian Ramacher
Bug#1004734: closed by Brian Potkin (Re: Bug#1004734: "usblp0: removed" when printing via USB on Canon LBP-810)
Indeed, fixing this issue is not worth the effort, if possible at all. Thanks for the explanations about USB, and for the time studying this issue. Regards, Yvan OpenPGP_signature Description: OpenPGP digital signature
Bug#1017554: juce-7.0.1~ds0/debian/extra/juce_audio_processors/format_types/juce_VSTInterface.h needs updating for 7.0.1
Package: juce-modules-source-data Version: 7.0.1~ds0-1 Severity: serious Tags: ftbfs Control: affects -1 src:iem-plugin-suite https://buildd.debian.org/status/fetch.php?pkg=iem-plugin-suite=amd64=1.13.0-2%2Bb2=1660758021=0 ... /usr/share/juce/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp: In member function ‘void JuceVSTWrapper::updateCallbackContextInfo()’: /usr/share/juce/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp:670:100: error: ‘const struct Vst2::VstTimeInfo’ has no member named ‘nanoSeconds’ 670 | info.setHostTimeNs ((ti->flags & Vst2::kVstNanosValid) != 0 ? makeOptional ((uint64_t) ti->nanoSeconds) : nullopt); | ^~~ ...
Bug#1017154: fuse: FTBFS: ulockmgr_server.c:127:12: error: conflicting types for ‘closefrom’; have ‘int(int)’
Control: tags -1 + confirmed patch upstream Control: forwarded -1 https://patchwork.ozlabs.org/project/buildroot/patch/20210912194057.2556882-1-fontaine.fabr...@gmail.com/#2753385 Control: user helm...@debian.org Control: usertags -1 + rebootstrap On Sun, Aug 14, 2022 at 09:12:12AM +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. The patch to fix this is in the link above. Helmut
Bug#1017553: libnvtt2 silently loses OpenEXR support when built with openexr 3.1.5
Package: libnvtt2 Version: 2.0.8-1+dfsg-8.2 Severity: important https://buildd.debian.org/status/fetch.php?pkg=nvidia-texture-tools=amd64=2.0.8-1%2Bdfsg-8.2%2Bb2=1660741804=0 ... -- Looking for OpenEXR - not found ...
Bug#980974: apparmor blocks cups backend outgoing network connections
Hello, denials for capabilty net_admin are often a sign that a service uses systemd libraries on startup, and these systemd libraries do funny[tm] things. In these cases the net_admin capability is not really needed. See https://bugzilla.opensuse.org/show_bug.cgi?id=1196850#c3 for the technical details. (Yes, I'm aware that this bugreport is for Samba, not cups - but I'm somewhat sure that cups uses the same systemd libraries on startup.) I have to admit that I'm only a cups user, but I'd be surprised if it really needs capability net_admin. To find out if it's really needed or just "systemd noise", can you please explicitely deny net_admin and test if printing still works? To do this, add deny capability net_admin, to /etc/apparmor.d/local/usr.sbin.cupsd This will a) deny it and b) silence the logging. Then reload the profile with systemctl reload apparmor I'd also recommend to aa-enforce cupsd (in theory deny rules get enforced even in complain mode, but better safe than sorry) If printing doesn't work with the deny rule added, please try if it works if you allow the capability: capability net_admin, (and remove the deny rule). Note, since this bug includes two different AppArmor denials: capability sys_nice, for cups-browsed is unrelated to what I wrote above. Please don't change your cups-browsed profile (= keep it in complain mode) while testing the deny rule in the cupsd profile. Regards, Christian Boltz -- > check up on dusted up coolers / vents etc. That is the first thing that I did, but I can't imagine that the amount of dust is automatically changing with the kernel ? [> David Haller and Raymond Wooninck in opensuse-factory]
Bug#1017552: alertmanager-irc-relay: FTBFS on armel
Source: alertmanager-irc-relay Version: 0.4.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=alertmanager-irc-relay=armel=0.4.2-1%2Bb3=1660740127=0 2022/08/17 12:41:55.543763 reconciler.go:77: INFO Setting JOIN state on channel #foo 2022/08/17 12:41:55.543873 reconciler.go:116: INFO Channel #foo monitor: join succeeded 2022/08/17 12:41:55.543971 reconciler.go:129: INFO Channel #foo monitor: context canceled while monitoring 2022/08/17 12:41:55.544069 irc_server_for_test.go:168: INFO =Server= Stopped accepting new connections --- PASS: TestKickRejoin (0.00s) FAIL FAILgithub.com/google/alertmanager-irc-relay0.128s ? github.com/google/alertmanager-irc-relay/logging[no test files] FAIL dh_auto_test: error: cd obj-arm-linux-gnueabi && go test -vet=off -v -p 4 github.com/google/alertmanager-irc-relay github.com/google/alertmanager-irc-relay/logging returned exit code 1 make: *** [debian/rules:7: build-arch] Error 25 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 Cheers -- Sebastian Ramacher
Bug#1017551: ITP: qcodeeditor -- A Qt widget for editing/viewing code
Package: wnpp Owner: Dima Kogan Severity: wishlist * Package name: qcodeeditor Version : 1.0+1gitdc644d Upstream Author : Megaxela * URL or Web page : https://github.com/Megaxela/QCodeEditor * License : MIT Description : A Qt widget for editing/viewing code.
Bug#981669: gettext: incorrect build dependencies for nojava architectures
El 17/8/22 a las 20:27, Jessica Clarke escribió: Sorry for the oversight in my patch. You could list it twice, once with the arch restriction and once with the profile restriction? Good idea! Yes, I believe that should work, as far as not-installed allows for duplicate entries. I'll try that and will let you know how it goes. Thanks a lot!
Bug#1017550: libvigraimpex silently loses OpenEXR support when built with openexr 3.1.5
Package: libvigraimpex11 Version: 1.11.1+dfsg-9 Severity: important https://buildd.debian.org/status/fetch.php?pkg=libvigraimpex=amd64=1.11.1%2Bdfsg-9%2Bb1=1660741137=0 ... -- Searching for OpenEXR --in default locations -- Could NOT find OpenEXR (missing: OPENEXR_HALF_LIBRARY OPENEXR_ILMIMF_LIBRARY) ...
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
On 2022-08-17 17:28:08 +, Thorsten Glaser wrote:
> tags 1017538 + help
> forwarded 1017538 https://lists.debian.org/debian-arm/2022/07/msg00041.html
> thanks
>
> Hi Sebastian,
>
> instead of filing a bug with the information we already have…
>
> >arm/__longjmp.S: Assembler messages:
> >arm/__longjmp.S:9: Error: selected processor does not support `vldm
> >ip!,{d0-d15}' in ARM mode
>
> … you could maybe have considered answering the question I posed
> on the Debian ARM mailing list about *why* it fails because nothing
> related to ARM was changed in the package or code.
Don't shoot the messanger.
Cheers
>
> So something in the toolchain(?) must have changed since the last
> successful build (what?) which we need to locally revert.
>
> Thanks in advance for any help,
> //mirabilos
> --
> Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
> schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
> Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
> hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
--
Sebastian Ramacher
Bug#981669: gettext: incorrect build dependencies for nojava architectures
On 17 Aug 2022, at 19:10, Santiago Vila wrote: > > Hi. I'm trying to make gettext buildable on hppa (and every other non-java > arch), but there is a subtle problem with debhelper, maybe you can help. > > After accepting the modifications proposed in Bug#982085 (with minor > changes), this is what I have in debian/gettext.install > > [!hppa !hurd-i386 !kfreebsd-any] usr/share/gettext/gettext.jar > usr/share/java > [!hppa !hurd-i386 !kfreebsd-any] usr/share/gettext/javaversion.class > > which AFAIK means "only if the arch supports Java, and only if nojava has not > been selected". > > So far, so good. > > Then I have this in debian/not-installed > > [hppa hurd-i386 kfreebsd-any] usr/share/gettext/gettext.jar > [hppa hurd-i386 kfreebsd-any] usr/share/gettext/javaversion.class > > which apparently means "only if the architecture does not support Java AND > only if nojava is selected" > > This is really a problem, because we would really want that to be OR, > not AND, so that we have the logical negation of the *.install script. > > As a result, gettext on hppa finally is "buildable" (in the sense that > build-dependencies may finally be met), but it fails to build from source. > > https://buildd.debian.org/status/fetch.php?pkg=gettext=hppa=0.21-8=1660663945=0 > > Is there a way to tell dh-exec that we want those conditions in > "not-installed" to be combined with OR? > > (I'm Cc:ing also Jessica Clarke, who initially provided the patch for this). > > I believe there is not, so what I will surely do in the meantime is to > call dh_missing with --list-missing. > > However, before doing so, I wonder if it would be possible for you to try the > current gettext in unstable with nojava profile, just to be sure that it will > work when I upload the version using --list-missing. > > (I also would like to hear from hurd-i386 porters before making more uploads, > as the failure there is not the same). Sorry for the oversight in my patch. You could list it twice, once with the arch restriction and once with the profile restriction? Jess
Bug#1017549: profanity: Command autoaway is not working
Package: profanity Version: 0.12.1-1~bpo11+1 Severity: normal Tags: upstream X-Debbugs-Cc: stefan.kr...@posteo.de Dear Maintainer, the autoaway command is not working correctly. Example: /autoaway check on /autoaway message xa "Ich bin mal weg" The user will get an error message: Invalid usage, see '/help autoaway' for details. This issue has been fixed in upstream commit: 4ea98c71ee0095115db905569fac18a8a82731c1 Fix /autoaway command logic -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-17-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 profanity depends on: ii libc6 2.31-13+deb11u3 ii libcurl3-gnutls7.74.0-1.3+deb11u2 ii libgcrypt201.8.7-6 ii libglib2.0-0 2.66.8-1 ii libgpgme11 1.14.0-1+b2 ii libgtk-3-0 3.24.24-4+deb11u2 ii libncursesw6 6.2+20201114-2 ii libnotify4 0.7.9-3 ii libotr54.1.1-4 ii libpython3.9 3.9.2-1 ii libreadline8 8.1-1 ii libsignal-protocol-c2.3.2 2.3.3-1 ii libsqlite3-0 3.34.1-3 ii libstrophe00.12.2-1~bpo11+1 ii libtinfo6 6.2+20201114-2 profanity recommends no packages. profanity suggests no packages. -- no debconf information
Bug#1017284: fenics-dolfinx: FTBFS: CheckSymbolExists.c:8:19: error: ‘PETSC_USE_COMPLEX’ undeclared (first use in this function); did you mean ‘PETSC_HAVE_COMPLEX’?
Source: fenics-dolfinx Followup-For: Bug #1017284 The cmake error logs can be too effusive, they tend to obscure the error. In this case the real problem seems to be that it never found scotch, even though it found it. A mystery indeed. Schrödinger's SCOTCH.
Bug#981669: gettext: incorrect build dependencies for nojava architectures
Hi. I'm trying to make gettext buildable on hppa (and every other non-java arch), but there is a subtle problem with debhelper, maybe you can help. After accepting the modifications proposed in Bug#982085 (with minor changes), this is what I have in debian/gettext.install [!hppa !hurd-i386 !kfreebsd-any] usr/share/gettext/gettext.jar usr/share/java [!hppa !hurd-i386 !kfreebsd-any] usr/share/gettext/javaversion.class which AFAIK means "only if the arch supports Java, and only if nojava has not been selected". So far, so good. Then I have this in debian/not-installed [hppa hurd-i386 kfreebsd-any] usr/share/gettext/gettext.jar [hppa hurd-i386 kfreebsd-any] usr/share/gettext/javaversion.class which apparently means "only if the architecture does not support Java AND only if nojava is selected" This is really a problem, because we would really want that to be OR, not AND, so that we have the logical negation of the *.install script. As a result, gettext on hppa finally is "buildable" (in the sense that build-dependencies may finally be met), but it fails to build from source. https://buildd.debian.org/status/fetch.php?pkg=gettext=hppa=0.21-8=1660663945=0 Is there a way to tell dh-exec that we want those conditions in "not-installed" to be combined with OR? (I'm Cc:ing also Jessica Clarke, who initially provided the patch for this). I believe there is not, so what I will surely do in the meantime is to call dh_missing with --list-missing. However, before doing so, I wonder if it would be possible for you to try the current gettext in unstable with nojava profile, just to be sure that it will work when I upload the version using --list-missing. (I also would like to hear from hurd-i386 porters before making more uploads, as the failure there is not the same). Thanks.
Bug#1017540: Clarification
The .iso is for the latest debian bullseye, taken from https://cdimage.debian.org/debian-cd/current/i386/iso-dvd/
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Arnd Bergmann dixit: >-march=armv7-a+fp instead of -march=armv7-a to pick the right “instead of” We pass nothing there, and we need a solution (or two distinct ones) for armel and armhf. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Bug#1017548: minetest: CVE-2022-35978
Source: minetest Version: 5.5.0+dfsg+~1.9.0mt4+dfsg-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for minetest, filling it as grave, but downgrade if you strongly disagree. CVE-2022-35978[0]: | Minetest is a free open-source voxel game engine with easy modding and | game creation. In **single player**, a mod can set a global setting | that controls the Lua script loaded to display the main menu. The | script is then loaded as soon as the game session is exited. The Lua | environment the menu runs in is not sandboxed and can directly | interfere with the user's system. There are currently no known | workarounds. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-35978 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35978 [1] https://github.com/minetest/minetest/security/advisories/GHSA-663q-pcjw-27cc [2] https://github.com/minetest/minetest/commit/da71e86633d0b27cd02d7aac9fdac625d141ca13 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1017547: openexr-viewers FTBFS with openexr 3.1.5
Source: openexr-viewers Version: 2.3.0-1 Severity: serious Tags: ftbfs bookworm sid https://buildd.debian.org/status/fetch.php?pkg=openexr-viewers=amd64=2.3.0-1%2Bb2=1660741866=0 ... main.cpp:66:10: fatal error: ImathLimits.h: No such file or directory 66 | #include | ^~~ compilation terminated. make[2]: *** [Makefile:494: main.o] Error 1
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
On Wed, Aug 17, 2022 at 7:28 PM Thorsten Glaser wrote:
>
> tags 1017538 + help
> forwarded 1017538 https://lists.debian.org/debian-arm/2022/07/msg00041.html
> thanks
>
> Hi Sebastian,
>
> instead of filing a bug with the information we already have…
>
> >arm/__longjmp.S: Assembler messages:
> >arm/__longjmp.S:9: Error: selected processor does not support `vldm
> >ip!,{d0-d15}' in ARM mode
>
> … you could maybe have considered answering the question I posed
> on the Debian ARM mailing list about *why* it fails because nothing
> related to ARM was changed in the package or code.
>
> So something in the toolchain(?) must have changed since the last
> successful build (what?) which we need to locally revert.
The way the FPU type gets selected in gcc changed with recent versions,
this was intentional and won't be reverted but it did break packages that
used the old method. In most cases, it's sufficient to pass
-march=armv7-a+fp instead of -march=armv7-a to pick the right
instruction set.
Arnd
Bug#1017546: golang-github-vbatts-tar-split: FTBFS on mips64el
Source: golang-github-vbatts-tar-split
Version: 0.11.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=golang-github-vbatts-tar-split=mips64el=0.11.1-2%2Bb7=1660746830=0
=== RUN TestLargeJunkPadding
[TestLargeJunkPadding] junk chunk #0/#320
[TestLargeJunkPadding] junk chunk #32/#320
[TestLargeJunkPadding] junk chunk #64/#320
[TestLargeJunkPadding] junk chunk #96/#320
[TestLargeJunkPadding] junk chunk #128/#320
[TestLargeJunkPadding] junk chunk #160/#320
panic: test timed out after 10m0s
goroutine 28 [running]:
testing.(*M).startAlarm.func1()
/usr/lib/go-1.19/src/testing/testing.go:2036 +0x108
created by time.goFunc
/usr/lib/go-1.19/src/time/sleep.go:176 +0x5c
goroutine 1 [chan receive, 9 minutes]:
testing.(*T).Run(0xc82b60, {0x1201c59a6, 0x14}, 0x1201ceb00)
/usr/lib/go-1.19/src/testing/testing.go:1494 +0x4b8
testing.runTests.func1(0xc82b60)
/usr/lib/go-1.19/src/testing/testing.go:1846 +0xa0
testing.tRunner(0xc82b60, 0xcb1cf8)
/usr/lib/go-1.19/src/testing/testing.go:1446 +0x140
testing.runTests(0xcb6030, {0x1202c5300, 0x3, 0x3}, {0xc0b75cf0c3e8d1b6,
0x8bb2fe5587, 0x1202e4760})
/usr/lib/go-1.19/src/testing/testing.go:1844 +0x524
testing.(*M).Run(0xcc4140)
/usr/lib/go-1.19/src/testing/testing.go:1726 +0x734
main.main()
_testmain.go:53 +0x250
goroutine 41 [select]:
io.(*pipe).read(0xc0002958c0, {0xc000218000, 0x2000, 0x2000})
/usr/lib/go-1.19/src/io/pipe.go:57 +0xc0
io.(*PipeReader).Read(0xc0002a4048, {0xc000218000, 0x2000, 0x2000})
/usr/lib/go-1.19/src/io/pipe.go:136 +0x5c
io.discard.ReadFrom({}, {0x1201fb5b8, 0xc0002a4048})
/usr/lib/go-1.19/src/io/io.go:611 +0xb4
io.copyBuffer({0x1201fb7f8, 0x120311d40}, {0x1201fb5b8, 0xc0002a4048}, {0x0,
0x0, 0x0})
/usr/lib/go-1.19/src/io/io.go:413 +0x18c
io.Copy(...)
/usr/lib/go-1.19/src/io/io.go:386
github.com/vbatts/tar-split/tar/asm.TestLargeJunkPadding(0xc036c0)
/<>/obj-mips64el-linux-gnuabi64/src/github.com/vbatts/tar-split/tar/asm/disassemble_test.go:65
+0x468
testing.tRunner(0xc036c0, 0x1201ceb00)
/usr/lib/go-1.19/src/testing/testing.go:1446 +0x140
created by testing.(*T).Run
/usr/lib/go-1.19/src/testing/testing.go:1493 +0x498
goroutine 42 [select]:
io.(*pipe).write(0xc000295860, {0xc000394000, 0x8000, 0x8000})
/usr/lib/go-1.19/src/io/pipe.go:86 +0x1f0
io.(*PipeWriter).Write(0xc0002a4040, {0xc000394000, 0x8000, 0x8000})
/usr/lib/go-1.19/src/io/pipe.go:165 +0x5c
io.copyBuffer({0x1201fb5d8, 0xc0002a4040}, {0x1201fb598, 0xcb6048}, {0x0,
0x0, 0x0})
/usr/lib/go-1.19/src/io/io.go:429 +0x2a8
io.Copy(...)
/usr/lib/go-1.19/src/io/io.go:386
io.CopyN({0x1201fb5d8, 0xc0002a4040}, {0x1201fb658, 0xca2050}, 0x400)
/usr/lib/go-1.19/src/io/io.go:362 +0xc8
github.com/vbatts/tar-split/tar/asm.TestLargeJunkPadding.func1()
/<>/obj-mips64el-linux-gnuabi64/src/github.com/vbatts/tar-split/tar/asm/disassemble_test.go:46
+0x39c
created by github.com/vbatts/tar-split/tar/asm.TestLargeJunkPadding
/<>/obj-mips64el-linux-gnuabi64/src/github.com/vbatts/tar-split/tar/asm/disassemble_test.go:21
+0x248
goroutine 43 [runnable]:
bytes.(*Buffer).Write(0xc0002ba000, {0xc0002f0db8, 0x400, 0x400})
/usr/lib/go-1.19/src/bytes/buffer.go:166 +0x1c
encoding/base64.(*encoder).Write(0xc0002f0d80, {0xc00088, 0x8000, 0x10})
/usr/lib/go-1.19/src/encoding/base64/base64.go:224 +0x1dc
encoding/json.encodeByteSlice(0xc0002ba000, {0x1201981a0, 0xc001223dd8, 0x97},
{0x0, 0x1})
/usr/lib/go-1.19/src/encoding/json/encode.go:857 +0x414
encoding/json.structEncoder.encode({{{0xc00013c000, 0x6, 0x8}, 0xc9e840}},
0xc0002ba000, {0x1201b5780, 0xc001223da0, 0x99}, {0x0, 0x1})
/usr/lib/go-1.19/src/encoding/json/encode.go:760 +0x1f8
encoding/json.(*encodeState).reflectValue(0xc0002ba000, {0x1201b5780,
0xc001223da0, 0x99}, {0x0, 0x1})
/usr/lib/go-1.19/src/encoding/json/encode.go:359 +0x90
encoding/json.(*encodeState).marshal(0xc0002ba000, {0x1201b5780, 0xc001223da0},
{0x0, 0x1})
/usr/lib/go-1.19/src/encoding/json/encode.go:331 +0x188
encoding/json.(*Encoder).Encode(0xca6320, {0x1201b5780, 0xc001223da0})
/usr/lib/go-1.19/src/encoding/json/stream.go:206 +0x80
github.com/vbatts/tar-split/tar/storage.(*jsonPacker).AddEntry(0xc0005283c0,
{0x2, {0x0, 0x0}, {0x0, 0x0, 0x0}, 0x0, {0xc00088, 0x8000, ...}, ...})
/<>/obj-mips64el-linux-gnuabi64/src/github.com/vbatts/tar-split/tar/storage/packer.go:97
+0x214
github.com/vbatts/tar-split/tar/asm.NewInputTarStream.func1()
/<>/obj-mips64el-linux-gnuabi64/src/github.com/vbatts/tar-split/tar/asm/disassemble.go:138
+0x780
created by github.com/vbatts/tar-split/tar/asm.NewInputTarStream
Bug#1017545: golang-github-golang-jwt-jwt: FTBFS on mipsel
Source: golang-github-golang-jwt-jwt Version: 4.2.0-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=golang-github-golang-jwt-jwt=mipsel=4.2.0-1%2Bb2=1660751536=0 === RUN Example_getTokenViaHTTP 2022/08/17 15:52:04 Authenticate: user[test] pass[known] --- PASS: Example_getTokenViaHTTP (0.65s) === RUN Example_useTokenViaHTTP --- PASS: Example_useTokenViaHTTP (0.64s) FAIL FAILgithub.com/golang-jwt/jwt 32.502s ? github.com/golang-jwt/jwt/cmd/jwt [no test files] === RUN TestExtractor --- PASS: TestExtractor (0.00s) === RUN TestParseRequest --- PASS: TestParseRequest (2.62s) === RUN ExampleHeaderExtractor --- PASS: ExampleHeaderExtractor (0.00s) === RUN ExampleArgumentExtractor --- PASS: ExampleArgumentExtractor (0.00s) PASS ok github.com/golang-jwt/jwt/request 2.656s ? github.com/golang-jwt/jwt/test [no test files] FAIL dh_auto_test: error: cd _build && go test -vet=off -v -p 4 github.com/golang-jwt/jwt github.com/golang-jwt/jwt/cmd/jwt github.com/golang-jwt/jwt/request github.com/golang-jwt/jwt/test returned exit code 1 make: *** [debian/rules:6: binary-arch] Error 25 Cheers -- Sebastian Ramacher
Bug#1017544: golang-github-anacrolix-missinggo: FTBFS: test failures
Source: golang-github-anacrolix-missinggo
Version: 2.1.0-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=golang-github-anacrolix-missinggo=arm64=2.1.0-6%2Bb8=1660737580=0
--- PASS: TestGetSubtestName (0.00s)
--- PASS: TestGetSubtestName/hello (0.00s)
--- PASS: TestGetSubtestName/world (0.00s)
=== RUN TestTimerDrain
timer_test.go:22:
Error Trace:timer_test.go:22
Error: received too soon
Test: TestTimerDrain
panic: test timed out after 10m0s
goroutine 50 [running]:
testing.(*M).startAlarm.func1()
/usr/lib/go-1.19/src/testing/testing.go:2036 +0x88
created by time.goFunc
/usr/lib/go-1.19/src/time/sleep.go:176 +0x38
goroutine 1 [chan receive]:
testing.(*T).Run(0x485380, {0x2066e7?, 0x45de77c1c641?}, 0x22ebe8)
/usr/lib/go-1.19/src/testing/testing.go:1494 +0x33c
testing.runTests.func1(0x0?)
/usr/lib/go-1.19/src/testing/testing.go:1846 +0x70
testing.tRunner(0x485380, 0x4000109cb8)
/usr/lib/go-1.19/src/testing/testing.go:1446 +0x10c
testing.runTests(0x4bd220?, {0x3a6420, 0x18, 0x18}, {0xdd00?,
0xdd574404eb4f9589?, 0x3ac500?})
/usr/lib/go-1.19/src/testing/testing.go:1844 +0x3e8
testing.(*M).Run(0x4bd220)
/usr/lib/go-1.19/src/testing/testing.go:1726 +0x500
main.main()
_testmain.go:99 +0x1e8
goroutine 49 [chan receive]:
github.com/anacrolix/missinggo.TestTimerDrain(0x400012e340?)
/<>/obj-aarch64-linux-gnu/src/github.com/anacrolix/missinggo/timer_test.go:26
+0xd8
testing.tRunner(0x400012eb60, 0x22ebe8)
/usr/lib/go-1.19/src/testing/testing.go:1446 +0x10c
created by testing.(*T).Run
/usr/lib/go-1.19/src/testing/testing.go:1493 +0x328
FAILgithub.com/anacrolix/missinggo 600.139s
Cheers
--
Sebastian Ramacher
Bug#999731: cryptsetup-suspend: fails to wake up screen after suspend
On Wed, 17 Aug 2022 at 19:01:38 +0200, Jonas Smedegaard wrote: > - it seems related to Wayland It does work with GNOME and Wayland though. -- Guilhem. signature.asc Description: PGP signature
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
tags 1017538 + help
forwarded 1017538 https://lists.debian.org/debian-arm/2022/07/msg00041.html
thanks
Hi Sebastian,
instead of filing a bug with the information we already have…
>arm/__longjmp.S: Assembler messages:
>arm/__longjmp.S:9: Error: selected processor does not support `vldm
>ip!,{d0-d15}' in ARM mode
… you could maybe have considered answering the question I posed
on the Debian ARM mailing list about *why* it fails because nothing
related to ARM was changed in the package or code.
So something in the toolchain(?) must have changed since the last
successful build (what?) which we need to locally revert.
Thanks in advance for any help,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1017543: xfce4-sensors-plugin: Plugin often forgets configuration (not fixed in stable)
Package: xfce4-sensors-plugin Version: 1.3.0-3 Severity: wishlist Dear Maintainer, bug reported here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851407 is not fixed for stable. It would be great if this fix could land to debian 11. have a nice day. -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-sensors-plugin depends on: ii libc62.31-13+deb11u3 ii libcairo21.16.0-5 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libnotify4 0.7.9-3 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libsensors5 1:3.6.0-7 ii libx11-6 2:1.7.2-1 ii libxfce4panel-2.0-4 4.16.2-1 ii libxfce4ui-2-0 4.16.0-1 ii libxfce4util74.16.0-1 ii libxnvctrl0 470.103.01-1~deb11u1 Versions of packages xfce4-sensors-plugin recommends: pn hddtemp ii lm-sensors 1:3.6.0-7 Versions of packages xfce4-sensors-plugin suggests: pn xsensors
Bug#1017540: cdimage.debian.org: i386 DVD 1 iso fails to install - md5 file integrity
Hi Dominik! On Wed, Aug 17, 2022 at 01:09:45PM -0400, dominik wrote: >Package: cdimage.debian.org >Severity: normal >Tags: ftbfs a11y >X-Debbugs-Cc: domin...@organworks.com > >Dear Maintainer, > >Attempting an install of .i386 DVD 1 through USB stick, the Install process >stops shortly after >searching for installation files, bringing up a read error. Running the md5 >integrity check will eventually >find an error with some file on the system, though the specific file varies on >installation attempts. Thus it is not >possible to install the .iso. This is despite correct sha256sum checks. A >netinst iso is available and works fine, >as a temporary workaround. This suggests that *maybe* your USB stick is faulty - this can be all-too-common problem. How are you writing the image to it please? Could you also please double-check that the image is written correctly by doing a checksum readback from the USB stick afterwards? -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Bug#1008684: openvswitch-switch update leaves interfaces down
Use auto...On Aug 17, 2022 18:02, topro wrote: > > > >> # eth0 onboard hw ethernet device > >> allow-ovsbr1 eth0 > >> [...] > > > >You should not be using "allow-ovsbr1", as much as I understand > > glad to give it a try. just omit that line on both eth0 and ovsvlan99 made > openvswitch not come up on boot any more. > > should I omit just on one of those two, or replace with auto? is there any > authoritative documentation where I can learn how do configure it right? > > and then, this config was working up until post-"~git" versions of 2.15 > showed up. > > Best regards, > topro >
Bug#1017540: cdimage.debian.org: i386 DVD 1 iso fails to install - md5 file integrity
Package: cdimage.debian.org Severity: normal Tags: ftbfs a11y X-Debbugs-Cc: domin...@organworks.com Dear Maintainer, Attempting an install of .i386 DVD 1 through USB stick, the Install process stops shortly after searching for installation files, bringing up a read error. Running the md5 integrity check will eventually find an error with some file on the system, though the specific file varies on installation attempts. Thus it is not possible to install the .iso. This is despite correct sha256sum checks. A netinst iso is available and works fine, as a temporary workaround.
Bug#999731: cryptsetup-suspend: fails to wake up screen after suspend
Quoting Guilhem Moulin (2022-08-17 13:50:36) > Control: tag -1 moreinfo > > Hi Jonas! > > On Tue, 16 Nov 2021 at 17:22:54 +0100, Jonas Smedegaard wrote: > > Quoting Jonas Smedegaard (2021-11-15 18:06:57) > >> cryptsetup-suspend looks promising, but unfortunately failed for me so > >> far on my ARM-based laptop - TERES-I - running an up-to-date bookwork > >> sytem with with the Wayland-based window-manager Sway: Without > >> cryptsetup-suspend, waking up leads to screen being backlit-black > >> where I can either hit ESC and get visual feedback from sway-lock, or > >> CTRL+ALT+F2 and get a text console; with cryptsetup-suspend installed, > >> waking up also leads to screen being backlit-black but not responding > >> to keyboard entry - system is however enough restored that I can power > >> it down and then examine the journal. > > > > Still unresponsive after wakeup without swaylock. > > > > That laptop has an odd builtin keyboard that requires a 2 second delay > > in u-boot or it fails to initialize. But that should not be an issue > > here: I can enter LUKS password succesfully - only afterwards the screen > > switches to a deadlocked state. > > Do I understand correctly that: > > 1/ the system suspends properly (presumably after suspending the LUKS > devices); > 2/ waking the system ups yields a cryptsetup prompt and the disk(s) can > be unlocked properly; but > 3/ you don't get your window manager as you left it? > > ? Possibly. Not sure if it is "window manager as I left it" or not, I can only say that I get a black screen that does not respond to key presses - it seems related to Wayland, since I can login via SSH and gracefully shutdown or reboot the system. > Does `sudo openvt -ws -c8 -- sh -c 'echo hello; sleep 3'` switch to VT8, > print there, and switch back to the window manager some seconds later? I will try that and report my findings on that (but if the command cannot meaningfully be executed from an SSH login then I can already say it won't work). > If not, then the issue is the hardcoded VT-switching logic and we'll > need to find another workaround. If yes, then perhaps adding `set -x` > at the top of /lib/cryptsetup/scripts/suspend/cryptsetup-suspend-wrapper > might shed some light on the execution flow? You'll find the trace at > `journalctl -u systemd-suspend.service`. I'll try that as well... - Jonas -- Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1017539: haskell-foundation: FTBFS on armel
Source: haskell-foundation
Version: 0.0.28-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=haskell-foundation=armel=0.0.28-1=1660672213=0
BlockN
Multiple n
[32;1m ✓ [0mn = CountOf 0 (4 tests)
[32;1m ✓ [0mn = CountOf 1 (4 tests)
[32;1m ✓ [0mn = CountOf 2 (4 tests)
[32;1m ✓ [0mn = CountOf 3 (4 tests)
[32;1m ✓ [0mn = CountOf 4 (4 tests)
[32;1m ✓ [0mn = CountOf 5 (4 tests)
[32;1m ✓ [0mn = CountOf 6 (4 tests)
[32;1m ✓ [0mn = CountOf 7 (4 tests)
[32;1m ✓ [0mn = CountOf 8 (4 tests)
[32;1m ✓ [0mn = CountOf 33 (4 tests)
[32;1m ✓ [0mn = CountOf 42 (4 tests)
Format
CSV
[32;1m ✓ [0mfield unit tests (9 tests)
[32;1m ✓ [0mrow unit tests (6 tests)
[32;1m ✓ [0mrow unit tests (6 tests)
[32;1m ✓ [0mrecord . toRow == id (400 tests)
[31;1mFailed 9 out of 6121[0m
Test suite check-foundation: FAIL
Test suite logged to: dist-ghc/test/foundation-0.0.28-check-foundation.log
0 of 1 test suites (0 of 1 test cases) passed.
-e: error: debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct
returned exit code 1
at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 852.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup test
--builddir=dist-ghc --show-details"...) called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 596
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup test
--builddir=dist-ghc --show-details"...) called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 470
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "test",
"--builddir=dist-ghc", "--show-details=direct") called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 686
Debian::Debhelper::Buildsystem::Haskell::Recipes::check_recipe() called
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:165: check-ghc-stamp] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
Cheers
--
Sebastian Ramacher
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Source: dietlibc
Version: 0.34~cvs20160606-14
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=dietlibc=armhf=0.34%7Ecvs20160606-14=1658252860=0
arm/__longjmp.S: Assembler messages:
arm/__longjmp.S:9: Error: selected processor does not support `vldm
ip!,{d0-d15}' in ARM mode
make[2]: *** [Makefile:206: bin-arm/__longjmp.o] Error 1
make[2]: *** Waiting for unfinished jobs
: -x -R .comment -R .note bin-arm/realpath.o
: -x -R .comment -R .note bin-arm/fnmatch.o
: -x -R .comment -R .note bin-arm/glob.o
: -x -R .comment -R .note bin-arm/sha256crypt.o
: -x -R .comment -R .note bin-arm/rx.o
: -x -R .comment -R .note bin-arm/sha512crypt.o
make[2]: Leaving directory '/<>'
dh_auto_build: error: make -j8 "INSTALL=install --strip-program=true"
prefix=/usr/lib/arm-linux-gnueabihf/diet MYARCH=arm
VERSION=0.34\~cvs20160606-14 DEBUG=1 "CFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 -g
-O2 -ffile-prefix-map=/<>=.
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wall -fno-pie -specs=/usr/share/dpkg/no-pie-link.specs
-Wl,-z,relro -Wl,-z,now -no-pie -pipe -nostdinc -D_REENTRANT -Os
-fomit-frame-pointer -fstrict-aliasing -W -Wall -Wextra -Wchar-subscripts
-Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused
-Wredundant-decls -Wshadow" returned exit code 2
make[1]: *** [debian/rules:94: override_dh_auto_build-arch] Error 25
Cheers
--
Sebastian Ramacher
Bug#1017537: dietlibc: FTBFS on armel: illegal instruction
Source: dietlibc Version: 0.34~cvs20160606-14 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=dietlibc=armel=0.34%7Ecvs20160606-14=1658293281=0 RUN ERROR for debian/unittests/tc523086.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for debian/unittests/t-ascii1.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for debian/unittests/signal.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for debian/unittests/gettimeofday.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for debian/unittests/socketfns.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for test/bsearch.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for test/fadvise.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for test/mmap_test.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for test/stdarg.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for test/ungetc.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for test/utime.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for test/waitpid.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for test/dirent/opendir-tst1.c in variant pthreads (rc = 132), test output is: Illegal instruction RUN ERROR for test/stdlib/tst-calloc.c in variant pthreads (rc = 132), test output is: Illegal instruction make[1]: *** [debian/rules:105: override_dh_auto_test-arch] Error 1 make[1]: Leaving directory '/<>' Cheers -- Sebastian Ramacher
Bug#1017500: ITP: plotjuggler -- Fast, intuitive and extensible time series visualization tool
Davide Faconti writes: > If you tell me more, maybe I can help to remove these dependencies > (from 3rdparty I guess). Since I am embracing conan for dependencies, > it should not be a big deal. Hi. I think removing dependencies from the repo is a good thing to do, but it would save me only a small bit of time. The biggest effort in packaging is generally dependencies and copyrights. I'm going to need to go through the dependency list, and make sure all the dependencies are in Debian. Anything that's not tiny and not alrady in Debian will need to be packaged. For PlogJuggler I see these unpackaged dependencies: - QCodeEditor - Qt-Advanced-Docking - color_widgets - mcap - sol For the copyrights, I'd need to make sure that everything in the repo has a clear copyright. You don't actually have a statement anywhere. Somewhere (like in the README) you should say "Copyright YEAR PlotJuggler contributors" or something. Then this copyright statement and the LICENSE (that you already have) will apply to everything in your repo, unless there are explicit notes to the contrary. You're also shipping some stuff that clearly doesn't adhere to that copyright statement or to your license: you have a bunch of memes in plotjuggler_app/resources/memes. You have no idea who made these and under what terms. I will strip those out. If you do that before I get to it, I wouldn't need to. I'm not going to get to this for a bit, since all the dependencies need to be taken care of first, but it'd be great if the copyrights were cleared up by the time I get to it. Thanks!
Bug#1017536: eiciel: Incompatible with Nautilus 43
Source: eiciel Severity: serious Version: 0.9.13.1-1 Tags: sid bookworm eiciel is incompatible with Nautilus 43. It would need to be converted to GTK4 to continue to work. Thank you, Jesus Soto
Bug#1017499: mesa: Updates to 22.2 RCs cause artifacts on nouveau and blank screen on VirtIO
On 8/16/22 11:57 PM, Ben Westover wrote: > I also updated my Debian virtual machine in UTM on macOS, which uses > VirtIO graphics, and LightDM is just completely black there except for > a cursor. The default graphics option of UTM is virtio-ramfb-gl, which is GPU accelerated. I just tested virtio-ramfb, and it doesn't have this issue, though it's not ideal as I can't resize the window and it's not GPU accelerated. I tested all of the *-gl accelerated graphics options, and they all have this issue. I also tested a normal virt-manager VM on Linux, and it doesn't have this issue. -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1007764: gcc-defaults: please support DPKG_ROOT
(my last mail to d...@debian.org bounced with "retry timeout exceeded" so I'm trying again with the ubuntu.com address as well) Hi, On Wed, 16 Mar 2022 13:30:26 +0100 Johannes Schauer Marin Rodrigues wrote: > when creating chroots for new architectures that are in the process of being > bootstrapped without yet having emulation support from qemu, it is not > possible to run maintainer scripts inside the foreign architecture chroot > because foreign architecture ELF binaries cannot be executed. The solution to > that problem is to run maintainer scripts from outside the chroot and use the > DPKG_ROOT environment variable to instruct the maintainer script on which > chroot to operate. By default, for normal installations, that environment > variable is set, but empty. > > Apart from init-system-helpers and pam, all packages in the > Essential:yes set have support for DPKG_ROOT already. To start building > packages we also need to install build-essential. > > Please consider applying the patch from this merge request: > > https://salsa.debian.org/toolchain-team/gcc-defaults/-/merge_requests/4 > > We tested it in our CI environment and it produces a bit-by-bit > identical chroot with DPKG_ROOT compared to a normal installation. > > https://salsa.debian.org/helmutg/dpkg-root-demo/ > > Since the DPKG_ROOT variable is empty on normal installations, the patch > should have no effect in the normal case. I wanted to send a friendly ping about this bug. I see that since I filed this bug, you uploaded three new versions of gcc-defaults. Please consider applying the changes of above merge request against gcc-defaults on salsa. Here is the diff in plain text for your convenience: --- a/debian/g++.postinst.in +++ b/debian/g++.postinst.in @@ -2,9 +2,9 @@ # remove the doc dir, if it's still a directory and replace with a symlink pkg=`basename $0 .postinst` -if [ ! -L /usr/share/doc/$pkg ]; then -rm -rf /usr/share/doc/$pkg -ln -s cpp /usr/share/doc/$pkg +if [ ! -L "$DPKG_ROOT/usr/share/doc/$pkg" ]; then +rm -rf "$DPKG_ROOT/usr/share/doc/$pkg" +ln -s cpp "$DPKG_ROOT/usr/share/doc/$pkg" fi # fix for report #138038: remove old diversions signature.asc Description: signature
Bug#1017533: dh-cargo: Order of cargo:X-Cargo-Built-Using subtitution varies depending on the locale env vars that are set
Package: dh-cargo Version: 24 Severity: normal X-Debbugs-Cc: r...@graphiant.com The order of the cargo:X-Cargo-Built-Using substitution generated by dh-cargo- built-using for binary Rust packages can vary if LC_ALL is set when building. This means that the contents of the binary package can vary depending on the environment, which is highlighted as a problem by tools like reprotest. For example: $ LANG=fr_CH.UTF-8 LANGUAGE=fr_CH.UTF-8:fr LC_ALL=fr_CH.UTF-8 dpkg- buildpackage -uc -us &> /dev/null && cat debian/built-using-repro.substvars cargo:Built-Using= cargo:X-Cargo-Built-Using=rust-lazycell (= 1.3.0-3), rust-lazy-static (= 1.4.0-1) shlibs:Depends=libc6 (>= 2.18), libgcc-s1 (>= 4.2) misc:Depends= misc:Pre-Depends= $ LANG=en_GB.UTF-8 LANGUAGE='en_GB:en' dpkg-buildpackage -uc -us &> /dev/null && cat debian/built-using-repro.substvars cargo:Built-Using= cargo:X-Cargo-Built-Using=rust-lazy-static (= 1.4.0-1), rust-lazycell (= 1.3.0-3) shlibs:Depends=libc6 (>= 2.18), libgcc-s1 (>= 4.2) misc:Depends= misc:Pre-Depends= -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable- debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-16-amd64 (SMP w/5 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-cargo depends on: ii cargo 0.47.0-3+b1 ii debhelper 13.3.4 ii perl 5.32.1-4+deb11u2 ii python33.9.2-3 dh-cargo recommends no packages. dh-cargo suggests no packages.
Bug#1017532: packagekit: please do the equivalent of "apt autoremove" after upgrades
Package: packagekit Version: 1.2.5-3 Severity: wishlist Dear Maintainer, I help a few friends whore are not into software run Debian on their machines. They do updates through gnome-software and PackageKit, and this works well. However, after a few stable updates, there are several kernels installed, and /boot will often fill up. At this point GNOME will show them warnings about /boot having little available space, and I have to intervene running `apt autoremove` for them to make the warnings go away. It would be nice if the PackageKit APT backend would perform the equivalent of `apt autoremove` on each upgrade. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages packagekit depends on: ii init-system-helpers 1.64 ii libappstream4 0.15.4-1 ii libapt-pkg6.0 2.5.2 ii libc6 2.34-3 ii libgcc-s1 12.1.0-8 ii libglib2.0-02.72.3-1+b1 ii libglib2.0-bin 2.72.3-1+b1 ii libgstreamer1.0-0 1.20.3-1 ii libpackagekit-glib2-18 1.2.5-3 ii libpolkit-gobject-1-0 0.105-33 ii libsqlite3-03.39.2-1 ii libstdc++6 12.1.0-8 ii libsystemd0 251.3-1 ii policykit-1 0.105-33 Versions of packages packagekit recommends: ii packagekit-tools 1.2.5-3 ii systemd 251.3-1 Versions of packages packagekit suggests: ii appstream 0.15.4-1 -- no debconf information signature.asc Description: PGP signature
Bug#1008684: openvswitch-switch update leaves interfaces down
>> # eth0 onboard hw ethernet device >> allow-ovsbr1 eth0 >> [...] > >You should not be using "allow-ovsbr1", as much as I understand glad to give it a try. just omit that line on both eth0 and ovsvlan99 made openvswitch not come up on boot any more. should I omit just on one of those two, or replace with auto? is there any authoritative documentation where I can learn how do configure it right? and then, this config was working up until post-"~git" versions of 2.15 showed up. Best regards, topro
Bug#1017375: liblexical-accessor-perl: test failure with Sub::HandlesVia 0.034
On Mon, 15 Aug 2022 05:26:39 +, Damyan Ivanov wrote:
> t/30shv.t fails with:
>
> Usage: Sub::HandlesVia::CodeGenerator::method_installer(self) at
> .../lib/Sub/HandlesVia/Toolkit/SubAccessorSmall.pm line 58.
>
> In version 0.034, Sub::HandlesVia::CodeGenerator's method_installer field
> is read-only and the above line tries to modify it:
>
> $gen->method_installer( sub {
> my ( $method_name, $coderef ) = @_;
> my $real_destination = $handles_map->{$method_name};
> $realattr->install_coderef( $real_destination, $coderef );
> } );
This should be fixed with libsub-handlesvia-perl 0.035, judging from
the following upstream commit:
commit 8c5799169c61a4c7aec65df51997a42bbecb8bd5
Author: Toby Inkster
Date: Fri Aug 12 15:40:49 2022 +0100
Make the CodeGenerator's method_installer an rw attribute
diff --git a/lib/Sub/HandlesVia/CodeGenerator.pm
b/lib/Sub/HandlesVia/CodeGenerator.pm
index c9d353b..586ca9b 100644
--- a/lib/Sub/HandlesVia/CodeGenerator.pm
+++ b/lib/Sub/HandlesVia/CodeGenerator.pm
@@ -156,7 +156,7 @@ has generator_for_type_assertion => (
);
has method_installer => (
- is => ro,
+ is => rw,
isa => 'CodeRef',
);
Also Changes say:
- Sub::HandlesVia::CodeGenerator method_installer is now a rw attribute as
Sub::Accessor::Small was relying on that.
I'm going to upload libsub-handlesvia-perl now, then we can depend on
the fixed version to close this bug, I guess?
Cheers,
gregor
--
.''`. 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
`-
signature.asc
Description: Digital Signature
Bug#1000796: marked as pending in base-passwd
Hi, On 17-08-2022 13:16, Colin Watson wrote: On Sun, Aug 14, 2022 at 11:27:47PM +0200, Paul Gevers wrote: On Thu, 03 Mar 2022 00:42:14 + Colin Watson wrote: Bug #1000796 in base-passwd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/base-passwd/-/commit/06ed6f49253ff244dc9cbcadc840fdf611f11462 Can we have this uploaded to unstable please? Pending RC bugs for 5 months are a bit awkward. Uploaded now - sorry for the delay. Thank you. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1017511: pacman-package-manager: fails to build reproducibly and embeds detected path in scripts
Hello Luca, On 8/17/22 5:56 AM, Luca Boccassi wrote: > It looks like the path to sh is detected at build time and embedded in > a bunch of scripts, which is bad as it breaks reproducibility, and also > breaks when building on usr-merged systems, which is expressely against > the Tech Committee resolution on this matter: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pacman-package-manager.html > > 1 #!/bin/bash > 1 #!/usr/bin/bash > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 Ah, thank you for this! Discovering the root of pacman's failure to build reproducibly was on my to-do list, but I have been very busy for the past week. Now that I know what to look for, this shouldn't be too hard to fix. Thanks, -- Ben Westover OpenPGP_signature Description: OpenPGP digital signature
Bug#1017499: mesa: Updates to 22.2 RCs cause artifacts on nouveau and blank screen on VirtIO
On Tue, Aug 16, 2022 at 11:57:49PM -0400, Ben Westover wrote: > After updating to mesa 22.2.0~rc1-1 on my 2008 Dell Precision laptop > with a Quadro FX 1700M GPU, I began experiencing artifacts [1] as soon > as lightdm started, and they still remained after launching Xfce [2]. > I also updated my Debian virtual machine in UTM on macOS, which uses > VirtIO graphics, and LightDM is just completely black there except for > a cursor. > > After updating to 22.2.0~rc2-1, the nouveau laptop's artifacts were > limited to only foreground objects, such as the login box of lightdm > [3] or the menu and panel of Xfce [4]. The virtual machine stayed the > same. I can report the same or very similar behaviour for my setup. My machine is also an old Dell machine (Vostro 430 from early 2010), with graphics card nVidia GT218 [GeForce 310] using the nouveau driver. Best wishes, Julian
