Processed: tagging 972806
Processing commands for cont...@bugs.debian.org: > tags 972806 + upstream Bug #972806 [src:mbedtls] mbedtls security advisories: local side channel attacks Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 972806: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972806 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972592: marked as done (mdtraj should be Architecture: any-amd64 arm64)
Your message dated Sat, 24 Oct 2020 06:03:31 + with message-id and subject line Bug#972592: fixed in mdtraj 1.9.4+git20201015.068f29a-2 has caused the Debian Bug report #972592, regarding mdtraj should be Architecture: any-amd64 arm64 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 972592: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: mdtraj Version: 1.9.4-4 Severity: serious Tags: ftbfs mdtraj needs SSE, which is not in the baseline of the i386 port and not available at all on !x86. Upstream master additionally contains a NEON port, which is part of the arm64 baseline (but not the armhf baseline). mdtraj should should therefore be Architecture: any-amd64 arm64 Upstream is talking about porting to simde [1], but no recent progress is visible on that. [1] https://github.com/mdtraj/mdtraj/pull/1562#issuecomment-644056348 --- End Message --- --- Begin Message --- Source: mdtraj Source-Version: 1.9.4+git20201015.068f29a-2 Done: Drew Parsons We believe that the bug you reported is fixed in the latest version of mdtraj, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 972...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Drew Parsons (supplier of updated mdtraj package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 24 Oct 2020 12:34:12 +0800 Source: mdtraj Architecture: source Version: 1.9.4+git20201015.068f29a-2 Distribution: unstable Urgency: medium Maintainer: Debichem Team Changed-By: Drew Parsons Closes: 972592 Changes: mdtraj (1.9.4+git20201015.068f29a-2) unstable; urgency=medium . * add debian patches - 32bit_skip_image_molecule.patch skips test_image_molecules in test_trajectory.py on 32-bit systems to avoid segfault in image_molecule (see upstream Issue #1591) - test_order_relax_tol.patch relaxes absolute tolerance in test_order.py::test_directors_angle_from_traj to help i386 pass tests. * restrict python3-mdtraj Architecture: any-amd64 arm64 i386. mdtraj needs SSE2 or NEON. Closes: #972592. Checksums-Sha1: c1016a539f7d38f106865664b39df2ff5e0686b2 2756 mdtraj_1.9.4+git20201015.068f29a-2.dsc 8ea65b1010c1fc58fc78e2602e97176cd6490418 297496 mdtraj_1.9.4+git20201015.068f29a-2.debian.tar.xz Checksums-Sha256: 47f2feb72d9c9f6c19874944a1ff4ea4503c61cb8cb950f07eb9d6afbf2c136c 2756 mdtraj_1.9.4+git20201015.068f29a-2.dsc d881cfe5b5cbca06260451e3fefcf26d41ede4298b5c29f5002e0630c2f4fe2b 297496 mdtraj_1.9.4+git20201015.068f29a-2.debian.tar.xz Files: e3338b8fa41a0eab2e54cd306de51789 2756 python optional mdtraj_1.9.4+git20201015.068f29a-2.dsc a4b1c8ee6de6b9938519d6298e378232 297496 python optional mdtraj_1.9.4+git20201015.068f29a-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEI8mpPlhYGekSbQo2Vz7x5L1aAfoFAl+TvQIACgkQVz7x5L1a AfpaDRAAqVLN49it6WHhU+lLbBJTbXcVLBetJRWH7eN3i1eVzTx/dsbi1k8IcQKC woLTz7W+mLrMmFb7223Ep831AfpJdcqYNpY3tqmB6gCdN5Q9jvWz7ukQQDAIIacK Gjq3ikhQZAfeXVT+PTrxnuLmIPABD5/runpkdwaV++dgHt7vIXRXjjF/TZ2h/WtE MckcQvaWIFDwHV/1FGgpJvc8DXd8HR+wWOk1bgGUmZ1On5WNUPT3uaa0y/kCF3tL GLN1/m01mAK1zqjO03lJe5J6qEQg/ri41/W3z0Z2H1MrIWhLvJ6GETAQPT+w6Buh 1omnMnT2Ilx4R+Nnc7xVHn5oYR/+r3LOK+K2qWRnI17Bzrz9/D3YQOwYxXxbuP2u tzEkotHwyYvz/yNFEbd/ShoNBkiOXMA+cDDTYV0RFTRlYd5KYLcAfB6WPgv+Fu0R W8a/Vc0N7j2ZdsatbbaLueC3leGv2rpfPyCUZRIV3juQDGNbHgXcOgn+i9SU5xQZ yT7F7UbDdDV4F7HSQ/YgWlvIRBGGcsYZLl6s2DhbkEVDq867DRbilzdUHv+i5puj 4w0y41pOKsT2k0eZElzzd+CZU6JWW9qVZ4tJ5xQwT5fv3RM/v7sYwMxBwIHdRYN9 X1w2voq6Pd7kr6ygo8EvnTt2mvooFq2UGzw9LYycwR4tT+710hg= =UfRg -END PGP SIGNATURE End Message ---
Bug#972430: nvidia-legacy-340xx-driver: Fails to build with kernel 5.9
Package: nvidia-legacy-340xx-driver Version: 340.108-7 Followup-For: Bug #972430 Thank you for using the patch I discovered. Just a heads up. 5.9 has reached testing today and version -8 of nvidia legacy has not reached unstable yet (at least in the mirror I use). So, I have put linux-image-amd64 and linux-headers-amd64 on hold and I advise the rest of the users to do the same until version -8 reaches testing as well. On my end, I will test the new version once it becomes available in unstable and report back. -- Package-specific info: uname -a: Linux mitsos 5.8.0-3-amd64 #1 SMP Debian 5.8.14-1 (2020-10-10) x86_64 GNU/Linux /proc/version: Linux version 5.8.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-13) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.8.14-1 (2020-10-10) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 10.2.0 (Debian 10.2.0-13) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.151215] Console: colour VGA+ 80x25 [0.590644] pci :01:00.0: vgaarb: setting as boot VGA device [0.590644] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.590644] pci :01:00.0: vgaarb: bridge control possible [0.590644] vgaarb: loaded [0.773569] Linux agpgart interface v0.103 [3.276292] nvidia: loading out-of-tree module taints kernel. [3.276303] nvidia: module license 'NVIDIA' taints kernel. [3.315335] nvidia: module verification failed: signature and/or required key missing - tainting kernel [3.362151] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [3.367572] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0 [3.367583] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 [3.826825] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [3.921462] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input10 [3.921541] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11 [3.921609] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12 [3.921672] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input13 [8.933135] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs Device node permissions: crw-rw+ 1 root video 226, 0 Oct 24 06:55 /dev/dri/card0 crw-rw-rw- 1 root root 195, 0 Oct 24 06:55 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Oct 24 06:55 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Oct 24 06:55 pci-:01:00.0-card -> ../card0 video:*:44:jim OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jun 8 11:36 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 44 Jun 8 11:36 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 43 Jun 8 11:36 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jun 8 11:36 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 25 Jun 8 11:36 /etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jun 8 11:36 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jun 8 11:36 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 39 Jun 8 11:36 /etc/alternatives/glx--nvidia-drm-outputclass.conf -> /etc/nvidia/nvidia-drm-outputclass.conf lrwxrwxrwx 1 root root 28 Jun 8 11:36 /etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf lrwxrwxrwx 1 root root 32 Jun 8 11:36 /etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf lrwxrwxrwx 1 root root 29 Jun 8 11:36 /etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 28 Jan 5 2020 /etc/alternatives/nvidia -> /usr/lib/nvidia/legacy-340xx lrwxrwxrwx 1 root root 57 Jan 5 2020 /etc/alternatives/nvidia--libEGL.so.1-x86_64-linux-gnu
Bug#972806: mbedtls security advisories: local side channel attacks
Earlier this year, an issue was filed for security advisories in April: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963159
Bug#972808: cura-engine FTBFS: error: ‘find_if’ is not a member of ‘std’
Source: cura-engine
Version: 1:4.7.1-1
Severity: serious
Tags: ftbfs
A native build of cura-engine on unstable amd64 ends with:
| [ 86%] Building CXX object
CMakeFiles/SparseGridTest.dir/tests/utils/SparseGridTest.cpp.o
| /usr/bin/c++ -DARCUS -DBUILD_TESTS -DBUILD_TESTS=1
-I/usr/include/polyclipping -I/<>/obj-x86_64-linux-gnu -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -Wall
-static-libstdc++ -fopenmp -std=gnu++11 -o
CMakeFiles/SparseGridTest.dir/tests/utils/SparseGridTest.cpp.o -c
/<>/tests/utils/SparseGridTest.cpp
| In file included from /usr/include/gtest/gtest.h:387,
| from /<>/tests/utils/SparseGridTest.cpp:4:
| /<>/tests/utils/SparseGridTest.cpp: In member function ‘virtual
void cura::GetNearbyTest_GetNearby_Test::TestBody()’:
| /<>/tests/utils/SparseGridTest.cpp:48:38: error: ‘find_if’ is
not a member of ‘std’; did you mean ‘find’?
|48 | EXPECT_NE(result.end(), std::find_if(result.begin(),
result.end(), [&point](const typename SparsePointGridInclusive::Elem
&elem) { return elem.val == point; }))
| | ^~~
| /<>/tests/utils/SparseGridTest.cpp:54:38: error: ‘find_if’ is
not a member of ‘std’; did you mean ‘find’?
|54 | EXPECT_EQ(result.end(), std::find_if(result.begin(),
result.end(), [&point](const typename SparsePointGridInclusive::Elem
&elem) { return elem.val == point; }))
| | ^~~
| /<>/tests/utils/SparseGridTest.cpp: In member function ‘virtual
void cura::GetNearbyTest_getNearbyLine2_Test::TestBody()’:
| /<>/tests/utils/SparseGridTest.cpp:99:38: error: ‘find_if’ is
not a member of ‘std’; did you mean ‘find’?
|99 | EXPECT_NE(result.end(), std::find_if(result.begin(),
result.end(), [&point](const typename SparsePointGridInclusive::Elem
&elem) { return elem.val == point; }))
| | ^~~
| /<>/tests/utils/SparseGridTest.cpp:105:38: error: ‘find_if’ is
not a member of ‘std’; did you mean ‘find’?
| 105 | EXPECT_EQ(result.end(), std::find_if(result.begin(),
result.end(), [&point](const typename SparsePointGridInclusive::Elem
&elem) { return elem.val == point; }))
| | ^~~
| /<>/tests/utils/SparseGridTest.cpp: In member function ‘virtual
void cura::GetNearbyTest_getNearbyLine_Test::TestBody()’:
| /<>/tests/utils/SparseGridTest.cpp:144:38: error: ‘find_if’ is
not a member of ‘std’; did you mean ‘find’?
| 144 | EXPECT_NE(result.end(), std::find_if(result.begin(),
result.end(), [&point](const typename SparsePointGridInclusive::Elem
&elem) { return elem.val == point; }))
| | ^~~
| /<>/tests/utils/SparseGridTest.cpp:150:38: error: ‘find_if’ is
not a member of ‘std’; did you mean ‘find’?
| 150 | EXPECT_EQ(result.end(), std::find_if(result.begin(),
result.end(), [&point](const typename SparsePointGridInclusive::Elem
&elem) { return elem.val == point; }))
| | ^~~
| make[3]: *** [CMakeFiles/SparseGridTest.dir/build.make:98:
CMakeFiles/SparseGridTest.dir/tests/utils/SparseGridTest.cpp.o] Error 1
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[2]: *** [CMakeFiles/Makefile2:1295: CMakeFiles/SparseGridTest.dir/all]
Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[1]: *** [Makefile:185: all] Error 2
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j1 "INSTALL=install
--strip-program=true" returned exit code 2
| make: *** [debian/rules:10: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
This must be a very recent issue as neither crossqa (10 days ago) nor
reproducible builds (6 days ago) have run into this issue. It's reliably
reproducible anyhow. I'm unsure what might cause it. Neither gcc-10 nor
cura-engine were uploaded in that time. It would be a good idea to add
the missing #include any how.
Helmut
Bug#972806: mbedtls security advisories: local side channel attacks
Source: mbedtls Version: 2.16.0-1 Severity: serious Tags: security Justification: security Dear Maintainer, Mbed TLS 2.16.8 released 1 Sep 2020 addresses 3 security advisories ==> Please update mbedtls in all active Debian releases. Thank you. https://github.com/ARMmbed/mbedtls/releases https://tls.mbed.org/tech-updates/security-advisories Local side channel attack on classical CBC decryption in (D)TLS https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2020-09-1 CVE-2020-16150 Severity: High Local side channel attack on RSA and static Diffie-Hellman https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2020-09-2 Severity: High Protocol weakness in DHE-PSK key exchange https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2020-09-3 Severity: Low -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#972789: qemu: FTBFS on arm{el,hf}: /<>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible
23.10.2020 19:50, Sebastian Ramacher wrote:
Source: qemu
Version: 1:5.1+dfsg-4
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)
binNMUs of qemu for the libbrlapi transition failed to build on armel
and armhf:
| /<>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is
not compatible
|44 | };
| | ^
Hmm. So this looks like a gcc ICE bug. Here's the code in question:
struct target_sigframe
{
abi_ulong pretcode;
int sig;
int code;
abi_ulong psc;
char retcode[8];
abi_ulong extramask[TARGET_NSIG_WORDS-1];
struct target_sigcontext sc;
};
...
| /<>/linux-user/m68k/signal.c:44:1: internal compiler error:
‘verify_type’ failed
I'm not sure what I have to do with this, besides reassigning it to gcc.
BTW, symbol TYPE_CANONICAL is not used/referenced by qemu sources.
/mjt
Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?
On Sat, 2020-10-24 at 03:06 +, kpcyrd wrote: > Yes, running the build.py script would cause reproducible builds issues > because it's used to take snapshots of Mozilla's trusted root CA > certificates. Hmm, I assume that is because it would build from the current snapshot each time it is run? > This is a very non-trivial downstream patch though, the project I'm > trying to package runs in a sandbox and loading certificates from disk > at runtime is not possible without redesigning some things. One option to solve this would be to have src:rust-webpki-roots provide webpki-roots-build containing build.py and then have ca-certificates build-dep on webpki-roots, run build.py and build a binary package containing the generated rust code. That seems a bit ick though. Is there any chance of webpki/rustls upstream switching from embedding to runtime loading of certs like other TLS stacks do? > webpki-roots is an optional dependency of reqwest, see > librust-reqwest+webpki-roots-dev[1]. It looks like this package needs rebuilding, because the binary package librust-webpki-roots-dev doesn't provide the virtual package named librust-webpki-roots-0.16+default-dev any more, which is probably why dak didn't know that something in Debian uses src:rust-webpki-roots. > It's related to webpki[2]/rustls[3], the later only got accepted > into debian very recently. These appear to be the websites for these two: https://briansmith.org/rustdoc/webpki/ https://github.com/ctz/rustls -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?
On Sat, Oct 24, 2020 at 09:42:40AM +0800, Paul Wise wrote: > Source: rust-webpki-roots > Severity: serious > Tags: security > X-Debbugs-Cc: Debian Security Team , kpcyrd > > Usertags: embed > > rust-webpki-roots is essentially a duplicate of ca-certificates. > > https://tracker.debian.org/pkg/ca-certificates > https://wiki.debian.org/EmbeddedCopies > > AFAICT, rebuilding the package from source doesn't run the upstream > supplied build.py script, so rebuilding from source won't update the > certs available in the package. Yes, running the build.py script would cause reproducible builds issues because it's used to take snapshots of Mozilla's trusted root CA certificates. > Having to rebuild rust-webpki-roots and everything that depends on it > after every update of ca-certificates would be very annoying though. > > Probably rust-webpki-roots should be removed from Debian and replaced > with something that loads the certs from ca-certificates at runtime. This is a very non-trivial downstream patch though, the project I'm trying to package runs in a sandbox and loading certificates from disk at runtime is not possible without redesigning some things. > As far as I can tell, nothing in Debian uses rust-webpki-roots, but on > IRC, kpcyrd mentioned that they have projects that use webpki-roots, > CCing them in order to get more info about that usage. webpki-roots is an optional dependency of reqwest, see librust-reqwest+webpki-roots-dev[1]. It's related to webpki[2]/rustls[3], the later only got accepted into debian very recently. [1]: https://packages.debian.org/unstable/librust-reqwest+webpki-roots-dev [2]: https://tracker.debian.org/pkg/rust-webpki [3]: https://tracker.debian.org/pkg/rust-rustls
Bug#972802: rust-webpki-roots: duplicates ca-certificates, remove from Debian?
Source: rust-webpki-roots Severity: serious Tags: security X-Debbugs-Cc: Debian Security Team , kpcyrd Usertags: embed rust-webpki-roots is essentially a duplicate of ca-certificates. https://tracker.debian.org/pkg/ca-certificates https://wiki.debian.org/EmbeddedCopies AFAICT, rebuilding the package from source doesn't run the upstream supplied build.py script, so rebuilding from source won't update the certs available in the package. Having to rebuild rust-webpki-roots and everything that depends on it after every update of ca-certificates would be very annoying though. Probably rust-webpki-roots should be removed from Debian and replaced with something that loads the certs from ca-certificates at runtime. As far as I can tell, nothing in Debian uses rust-webpki-roots, but on IRC, kpcyrd mentioned that they have projects that use webpki-roots, CCing them in order to get more info about that usage. $ ssh mirror.ftp-master.debian.org dak rm -s unstable -Rn rust-webpki-roots Will remove the following packages from unstable: librust-webpki-roots-dev | 0.20.0-1+b1 | amd64, arm64, armel, armhf, i386 rust-webpki-roots | 0.20.0-1 | source webpki-roots | 0.20.0-1+b1 | amd64, arm64, armel, armhf, i386 Maintainer: Debian Rust Maintainers --- Reason --- -- Checking reverse dependencies... No dependency problem found. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#972430: marked as done (nvidia-legacy-340xx-driver: Fails to build with kernel 5.9)
Your message dated Fri, 23 Oct 2020 22:19:04 + with message-id and subject line Bug#972430: fixed in nvidia-graphics-drivers-legacy-340xx 340.108-8 has caused the Debian Bug report #972430, regarding nvidia-legacy-340xx-driver: Fails to build with kernel 5.9 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 972430: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972430 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: nvidia-legacy-340xx-driver Version: 340.108-7 Severity: grave Justification: renders package unusable Dear Maintainer, As usual, new kernel in unstable and nvidia 340x fails to build once more. Here is the log https://paste.debian.net/1167671/ There is no suitable patch at the moment of writing, but I will keep looking. -- Package-specific info: uname -a: Linux mitsos 5.8.0-3-amd64 #1 SMP Debian 5.8.14-1 (2020-10-10) x86_64 GNU/Linux /proc/version: Linux version 5.8.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-13) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.8.14-1 (2020-10-10) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 GCC version: gcc version 10.2.0 (Debian 10.2.0-13) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.151421] Console: colour VGA+ 80x25 [0.589708] pci :01:00.0: vgaarb: setting as boot VGA device [0.589708] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.589708] pci :01:00.0: vgaarb: bridge control possible [0.589708] vgaarb: loaded [0.773896] Linux agpgart interface v0.103 [3.244182] nvidia: loading out-of-tree module taints kernel. [3.244193] nvidia: module license 'NVIDIA' taints kernel. [3.279605] nvidia: module verification failed: signature and/or required key missing - tainting kernel [3.302651] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [3.319778] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0 [3.319790] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.108 Wed Dec 11 11:06:58 PST 2019 [3.668036] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [3.778913] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input9 [3.779662] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11 [3.780215] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12 [3.781671] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input13 [9.190464] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs Device node permissions: crw-rw+ 1 root video 226, 0 Oct 18 14:46 /dev/dri/card0 crw-rw-rw- 1 root root 195, 0 Oct 18 14:46 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 Oct 18 14:46 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Oct 18 14:46 pci-:01:00.0-card -> ../card0 video:*:44:jim OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Jun 8 11:36 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 44 Jun 8 11:36 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1 lrwxrwxrwx 1 root root 43 Jun 8 11:36 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 43 Jun 8 11:36 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 25 Jun 8 11:36 /etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Jun 8 11:36 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Jun 8 11:36 /etc/alternatives/glx--nvidia-bug-report.sh -> /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 39 Jun
Bug#971721: marked as done (mime-support: missing dependency on perl)
Your message dated Fri, 23 Oct 2020 22:00:13 + with message-id and subject line Bug#971721: fixed in mailcap 3.65 has caused the Debian Bug report #971721, regarding mime-support: missing dependency on perl to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 971721: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971721 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: mime-support Version: 3.64 Severity: serious On Mon, Oct 05, 2020 at 09:09:01AM +0200, Adam Borowski wrote: > On Mon, Oct 05, 2020 at 01:52:19PM +1000, Jai Flack wrote: > > Forgive me if this is an ignorant question but isn't mailcap missing > > dependencies? If I build, then install all three and then ask apt about > > mailcap's dependencies it gives: > > [...] > > > But the script it installs clearly depends on Perl: > > > > #! /usr/bin/perl > > > Is this an exception because Perl is part of the base system and assumed > > to always be installed? > > perl-base is essential. Indeed. However, the script in question (/usr/bin/run-mailcap) uses modules not shipped in perl-base. use Encode qw(decode); use I18N::Langinfo qw(langinfo CODESET); So yes, the mime-support package in sid is missing a dependency on perl. This seems to have regressed in 3.55 with the fix for #682900. Filing a bug about this, thanks for noticing. -- Niko Tyni nt...@debian.org --- End Message --- --- Begin Message --- Source: mailcap Source-Version: 3.65 Done: Charles Plessy We believe that the bug you reported is fixed in the latest version of mailcap, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 971...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Charles Plessy (supplier of updated mailcap package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 08 Oct 2020 05:29:01 +0900 Source: mailcap Binary: mailcap Architecture: source all Version: 3.65 Distribution: experimental Urgency: medium Maintainer: Mime-Support Packagers Changed-By: Charles Plessy Description: mailcap- Debian's mailcap system, and support programs Closes: 964850 971721 Changes: mailcap (3.65) experimental; urgency=medium . * Split the mailcap system into a separate optional package, to allow for alternatives. Closes: #964850. * Depends on Perl. Closes: #971721. Checksums-Sha1: 80de73585494703f0a5d1680e6dd5391879c5547 1547 mailcap_3.65.dsc 37a397eb9e186e8b687f50e1afeffe07582d082d 26224 mailcap_3.65.tar.xz 73a5484d3dc0c3561c8d8073d26bf05daa26a1e8 31268 mailcap_3.65_all.deb fba8a714faad5ab7fe936ab38ce9df59d25af25f 4634 mailcap_3.65_amd64.buildinfo Checksums-Sha256: 91b693ceb1dd408eaebf2b470ba992a6c1050d08091a73ac9ffc535b8edf7427 1547 mailcap_3.65.dsc 07cb7c5ee1b62c24faa06ae22abba4e25add6e12cc871fb5b61bb4e13bf8e315 26224 mailcap_3.65.tar.xz c89278018c0a34b98e4c21ad9b81597d617ef990a3a203d2a2b666cb46de64e0 31268 mailcap_3.65_all.deb f107868aa950780235a8123d8a567560a31fac577ac6baae7da73dd6fbf2c431 4634 mailcap_3.65_amd64.buildinfo Files: 9068d5efbc97d5c52d263f001c0a44c9 1547 utils optional mailcap_3.65.dsc d62a77cf7d75c11d80948f8d26d22460 26224 utils optional mailcap_3.65.tar.xz dc3531c8cf02f5a8cf649430d59d3368 31268 utils optional mailcap_3.65_all.deb bc898c93633dd31250aad7169c6d6e80 4634 utils optional mailcap_3.65_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEc0cUmcxg7Z7ugFlGxb1sjyKV1QIFAl9+RZcACgkQxb1sjyKV 1QJO/w/+JRjVk2Rh9u8cXjhchi1I/zDx3ycJCV/W3n7RQ6za259dsMtGUp2u+7gL PmFoajZqu1t7b0/BDdQ/3bxfR4TNnZeMPW+KL+4VwD+moQeU/JUG/C4IkBylAgFw U79aWtwLOZejlMY++QNFSjQyhKw++5GRwRjnjo1EXsGTBKRJWwW6qRvdt8FY13qL ESsb5/sT4UnjKqwR/GAPYyuLOoaX0hifSX5+orINfk3vjkG0ff1ZdAdqgd2YoEDX e+COpNN3zhkuO467hTT09XAWsQJ4JXpU/iIIKdITtpiD+BmXAf97T8mq8o8o67Pg R62oi2sJFPKEvVXWrzjtN8lPTZJmhwKg2WCoBEKoro0ml3pU9A3Gnn/IlXQo7NGN 5bFWkvhj3FnX5BANXD9hij8bN0zVTV+astCoxKaAnOxYjMFYBHppWXjT74R//rUC wwgFntVpO8kLN3rZhuMz8nCeA1tBYfE/GDWitIoXWssUjhxQBKVMc2BhBpp+Lfxt FMBSuqnPpaY1+GUAM5SBWCmOy7+h/eFvbm0KVAeTlKsxVo85cOleUhoBXSDByldM 1T+FGIgpDdntSBAg5XbqqBse80fvCphElFGVR0toEY4xlnq+2f4/mIaFcwwwAPoY f9QuxFHprujzSBgj2C3zHnFIp91qSpZy5xp1hyFxAnhvodiMjdo= =OTYc
Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option
On Thu, 22 Oct 2020 at 21:47, Simon McVittie wrote: > > On Thu, 22 Oct 2020 at 19:14:54 +0100, David Miguel Susano Pinto wrote: >> gnome-boxes does not start. Trying from command line, issues this error: >> >> $ gnome-boxes >> gnome-boxes: symbol lookup error: >> /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1: undefined symbol: >> libusb_set_option >> >> Similar issue when starting qemu: >> >> $ qemu-system-x86_64 >> qemu-system-x86_64: symbol lookup error: qemu-system-x86_64: undefined >> symbol: libusb_set_option > > It starts fine on a Debian 10 system for me. According to > /var/lib/dpkg/info/libusb-1.0-0:amd64.symbols, that symbol has been provided > by libusb-1.0-0 since version 2:1.0.22, which you have. > > Do you have an older version of libusb-1.0.so.0 somewhere in the library > search path, perhaps in /usr/local/lib? I checked and other than "/lib/x86_64-linux-gnu/libusb-1.0.so.0" (provided by libusb-1.0-0) I also have "/lib/libusb-1.0.so.0" (which seems to be what is loaded: $ ldd /usr/bin/gnome-boxes | grep usb libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0x7f49d1393000) libusbredirhost.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1 (0x7f49c88fb000) libusbredirparser.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirparser.so.1 (0x7f49c88f00 Removing "/lib/libusb-1.0.so*" (and run ldconfig to update the linker cache), makes it load the right libusb: $ ldd /usr/bin/gnome-boxes | grep usb libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x7fc22ff71000) libusbredirhost.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirhost.so.1 (0x7fc2274b3000) libusbredirparser.so.1 => /usr/lib/x86_64-linux-gnu/libusbredirparser.so.1 (0x7fc2274a8000) And gnome-boxes now works properly. The thing is, I have no idea where this /lib/libusb came from. I'm pretty sure I didn't install anything other than debs from the official debian repos. dpkg-query also does not know which package installed it: $ dpkg-query -S /lib/libusb-1.0.so.0.1.0 dpkg-query: no path found matching pattern /lib/libusb-1.0.so.0.1.0 I have one other Debian machine which has the same file. Any clues where that file came from and what it may be used for? Thank you David
Bug#972579: [Pkg-rust-maintainers] Comments regarding rust-kmon_1.3.0-1_amd64.changes
On Sun, Oct 18, 2020 at 08:27:30PM +, Joerg Jaspert wrote: > Hi Maintainer, > > c002350518c0bbe87a18994ec6869411 10347 FIXME-(source.section) optional > rust-kmon_1.3.0-1_amd64.buildinfo > f6f32a721903d3c2fa78fc2e6b095695 2391 FIXME-(source.section) optional > rust-kmon_1.3.0-1.dsc > > Uh yeah, one should fixup all FIXMEs before uploading. :) > Point taken. And thanks for the reminder 22:35 < Ganneff> W: zoxide: unknown-section FIXME-(source.section) 22:36 < Ganneff> not the first time i see that in a package. does debcargo sometimes fail there (and maintainer obviously not checking lintian)? 22:52 < dkg> Ganneff: debcargo should be noticing that and warning, but of course it can't fix it itself. maybe Sylvestre overlooked the FIXME somehow? 22:52 < dkg> i can try to take a look at it 22:53 < Ganneff> just the second time i saw that. 22:53 < stappers> Acknowledge on that 22:53 < Ganneff> i sure can (and did) overwrite it for the archive, thats no problem, but package should be fixed. Regards Geert Stappers Adding this to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972579 -- Silence is hard to parse
Bug#971214: marked as done (elpy: FTBFS: tests failed)
Your message dated Fri, 23 Oct 2020 14:48:27 -0400 with message-id <87lffw6ao4@digitalmercury.dynalias.net> and subject line Re: Bug#971214: elpy: FTBFS: tests failed has caused the Debian Bug report #971214, regarding elpy: FTBFS: tests failed to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 971214: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971214 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: elpy Version: 1.34.0-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200926 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > dh_auto_build > I: pybuild base:217: /usr/bin/python3 setup.py build > running build > running build_py > creating /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/jedibackend.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/refactor.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/__init__.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/__main__.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/pydocutils.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/blackutil.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/yapfutil.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/compat.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/auto_pep8.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/rpc.py -> /<>/.pybuild/cpython3_3.8_elpy/build/elpy > copying elpy/server.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy > creating /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/test_server.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/test_rpc.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/support.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/test_yapf.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/__init__.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/test_pydocutils.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/test_auto_pep8.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/test_refactor.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/test_jedibackend.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/compat.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/test_black.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > copying elpy/tests/test_support.py -> > /<>/.pybuild/cpython3_3.8_elpy/build/elpy/tests > running egg_info > creating elpy.egg-info > writing elpy.egg-info/PKG-INFO > writing dependency_links to elpy.egg-info/dependency_links.txt > writing requirements to elpy.egg-info/requires.txt > writing top-level names to elpy.egg-info/top_level.txt > writing manifest file 'elpy.egg-info/SOURCES.txt' > reading manifest file 'elpy.egg-info/SOURCES.txt' > reading manifest template 'MANIFEST.in' > writing manifest file 'elpy.egg-info/SOURCES.txt' > PYTHONPATH=. python3 -m sphinx -N -bman docs/ build/man > Running Sphinx v3.2.1 > making output directory... done > building [mo]: targets for 0 po files that are out of date > building [man]: all manpages > updating environment: [new config] 9 added, 0 changed, 0 removed > reading sources... [ 11%] FAQ > reading sources... [ 22%] concepts > reading sources... [ 33%] customization_tips > reading sources... [ 44%] editing > reading sources... [ 55%] extending > reading sources... [ 66%] ide > reading sources... [ 77%] index > reading sources... [ 88%] introduction > reading sources... [100%] quickstart > > /<>/docs/quickstart.rst:14: WARNING: duplicate description of > command elpy-shell-send-region-or-buffer, other instance in > /<>/docs/ide.rst > /<>/docs/quickstart.rst:20: WARNING: duplicate description of > command elpy-shell-send-statement-and-step, other instance in > /<>/docs/ide.rst > /<>/docs/quickstart.rst:26: WARNING: duplicate description of > command elpy-shell-switch-to-shell, other instance in > /<>/docs/ide.rst > /<>/docs/quickstart.rst:31: WARNING: duplicate description of > command elpy-doc, other instance in /<>/docs/ide.rst > looking for now-outdated files... none found > pickling environment... done > checking consistency... done > writing... elpy.1
Bug#972746: [debian-mysql] Bug#972746: mariadb-10.3: CVE-2020-15180
Hi Otto, On Fri, Oct 23, 2020 at 09:03:16AM +0300, Otto Kekäläinen wrote: > Hello! > > Thanks! > > Bullseye is meant to ship with 10.5 and 10.3 should be removed once > 10.5 has been in Debian testing for a while (currently still in Debian > unstable due to debci false positive). Thanks, this sounds sensible! Regards, Salvatore
Bug#972793: hg-git: autopkgtest needs update for new version of dulwich: lots of deprecation *warnings*
Source: hg-git Version: 0.9.0-1 Severity: serious X-Debbugs-CC: debian...@lists.debian.org, dulw...@packages.debian.org Tags: sid bullseye User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:dulwich Dear maintainer(s), With a recent upload of dulwich the autopkgtest of hg-git fails in testing when that autopkgtest is run with the binary packages of dulwich from unstable. It passes when run with only packages from testing. In tabular form: passfail dulwichfrom testing0.20.6-1.1 hg-git from testing0.9.0-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of dulwich to testing [1]. Of course, dulwich shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in dulwich was intended and your package needs to update to the new situation. Also, failing on deprecation warnings should really be avoided in autopkgtesting (that's more something for upstreams test framework), please disable deprecation warnings if possible. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=dulwich https://ci.debian.net/data/autopkgtest/testing/amd64/h/hg-git/7682446/log.gz --- /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/tests/test-renames.t +++ /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/tests/test-renames.t.err @@ -371,6 +371,16 @@ adding objects added 2 commits with 2 trees and 3 blobs updating reference refs/heads/master + /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/hggit/git_handler.py:411: DeprecationWarning: Use SendPackResult.refs instead. +if remote_name and new_refs: + /usr/lib/python3/dist-packages/mercurial/pycompat.py:362: DeprecationWarning: Use SendPackResult.refs instead. +iteritems = lambda x: x.items() + /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/hggit/git_handler.py:431: DeprecationWarning: Use SendPackResult.refs instead. +if old_refs == new_refs: + /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/hggit/git_handler.py:434: DeprecationWarning: Use SendPackResult.refs instead. +elif len(new_refs) > len(old_refs): + /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/hggit/git_handler.py:436: DeprecationWarning: Use SendPackResult.refs instead. +elif len(old_refs) > len(new_refs): $ cd ../gitrepo $ git log master --pretty=oneline ERROR: test-renames.t output changed !. --- /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/tests/test-file-removal.t +++ /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/tests/test-file-removal.t.err @@ -168,6 +168,12 @@ searching for changes adding objects added 9 commits with 8 trees and 5 blobs + /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/hggit/git_handler.py:431: DeprecationWarning: Use SendPackResult.refs instead. +if old_refs == new_refs: + /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/hggit/git_handler.py:434: DeprecationWarning: Use SendPackResult.refs instead. +elif len(new_refs) > len(old_refs): + /tmp/autopkgtest-lxc.1m_ql5en/downtmp/build.IYS/src/hggit/git_handler.py:435: DeprecationWarning: Use SendPackResult.refs instead. +ret = 1 + (len(new_refs) - len(old_refs)) $ cd .. $ git --git-dir=gitrepo2 log --pretty=medium ERROR: test-file-removal.t output changed !. signature.asc Description: OpenPGP digital signature
Processed: hg-git: autopkgtest needs update for new version of dulwich: lots of deprecation *warnings*
Processing control commands: > affects -1 src:dulwich Bug #972793 [src:hg-git] hg-git: autopkgtest needs update for new version of dulwich: lots of deprecation *warnings* Added indication that 972793 affects src:dulwich -- 972793: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972793 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#957436: libfm-qt: ftbfs with GCC-10
On Sat, Oct 17, 2020 at 08:20:10PM +0300, Dmitry Shachnev wrote: > As this failure is blocking the Qt 5.15 transition, I have uploaded the > attached debdiff as NMU to DELAYED/5. It built fine on most architectures, but unfortunately it FTBFS on armel, so I have to do one more upload to let the new version migrate to testing. I have now uploaded the attached debdiff to DELAYED/1. I also created a merge request which has changes from both my NMUs: https://salsa.debian.org/lxqt-team/libfm-qt/-/merge_requests/1 -- Dmitry Shachnev diff -Nru libfm-qt-0.14.1/debian/changelog libfm-qt-0.14.1/debian/changelog --- libfm-qt-0.14.1/debian/changelog 2020-10-17 20:11:39.0 +0300 +++ libfm-qt-0.14.1/debian/changelog 2020-10-23 20:28:57.0 +0300 @@ -1,3 +1,10 @@ +libfm-qt (0.14.1-12.2) unstable; urgency=medium + + * Non-maintainer upload. + * Update symbols files from buildds’ logs to fix FTBFS on armel. + + -- Dmitry Shachnev Fri, 23 Oct 2020 20:28:57 +0300 + libfm-qt (0.14.1-12.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru libfm-qt-0.14.1/debian/libfm-qt6.symbols libfm-qt-0.14.1/debian/libfm-qt6.symbols --- libfm-qt-0.14.1/debian/libfm-qt6.symbols 2020-10-17 20:11:39.0 +0300 +++ libfm-qt-0.14.1/debian/libfm-qt6.symbols 2020-10-23 20:28:57.0 +0300 @@ -578,10 +578,10 @@ (c++)"Fm::FolderConfig::getDouble(char const*, double*)@Base" 0.14.0~ (c++)"Fm::FolderConfig::getInteger(char const*, int*)@Base" 0.14.0~ (c++)"Fm::FolderConfig::getString(char const*)@Base" 0.14.0~ - (optional|c++|arch= !amd64 !arm64 !mips64el !ppc64el !s390x !alpha !ppc64 !riscv64 !sparc64 )"Fm::FolderConfig::getStringList(char const*, unsigned int*)@Base" 0.14.0~ - (optional|c++|arch= !armel !armhf !i386 !mips !mipsel !hppa !hurd-i386 !m68k !powerpc !sh4 !x32 )"Fm::FolderConfig::getStringList(char const*, unsigned long*)@Base" 0.14.0~ - (optional|c++|arch= !amd64 !arm64 !mips64el !ppc64el !s390x !alpha !ppc64 !riscv64 !sparc64 )"Fm::FolderConfig::getUint64(char const*, unsigned long long*)@Base" 0.14.0~ - (optional|c++|arch= !armel !armhf !i386 !mips !mipsel !hppa !hurd-i386 !m68k !powerpc !sh4 !x32 )"Fm::FolderConfig::getUint64(char const*, unsigned long*)@Base" 0.14.0~ + (optional|c++|arch-bits=32)"Fm::FolderConfig::getStringList(char const*, unsigned int*)@Base" 0.14.0~ + (optional|c++|arch-bits=64)"Fm::FolderConfig::getStringList(char const*, unsigned long*)@Base" 0.14.0~ + (optional|c++|arch-bits=32)"Fm::FolderConfig::getUint64(char const*, unsigned long long*)@Base" 0.14.0~ + (optional|c++|arch-bits=64)"Fm::FolderConfig::getUint64(char const*, unsigned long*)@Base" 0.14.0~ (c++)"Fm::FolderConfig::globalConfigFile_@Base" 0.14.0~ (c++)"Fm::FolderConfig::init(char const*)@Base" 0.14.0~ (c++)"Fm::FolderConfig::isEmpty()@Base" 0.14.0~ @@ -594,10 +594,10 @@ (c++)"Fm::FolderConfig::setDouble(char const*, double)@Base" 0.14.0~ (c++)"Fm::FolderConfig::setInteger(char const*, int)@Base" 0.14.0~ (c++)"Fm::FolderConfig::setString(char const*, char const*)@Base" 0.14.0~ - (optional|c++|arch= !amd64 !arm64 !mips64el !ppc64el !s390x !alpha !ppc64 !riscv64 !sparc64 )"Fm::FolderConfig::setStringList(char const*, char const* const*, unsigned int)@Base" 0.14.0~ - (optional|c++|arch= !armel !armhf !i386 !mips !mipsel !hppa !hurd-i386 !m68k !powerpc !sh4 !x32 )"Fm::FolderConfig::setStringList(char const*, char const* const*, unsigned long)@Base" 0.14.0~ - (optional|c++|arch= !amd64 !arm64 !mips64el !ppc64el !s390x !alpha !ppc64 !riscv64 !sparc64 )"Fm::FolderConfig::setUint64(char const*, unsigned long long)@Base" 0.14.0~ - (optional|c++|arch= !armel !armhf !i386 !mips !mipsel !hppa !hurd-i386 !m68k !powerpc !sh4 !x32 )"Fm::FolderConfig::setUint64(char const*, unsigned long)@Base" 0.14.0~ + (optional|c++|arch-bits=32)"Fm::FolderConfig::setStringList(char const*, char const* const*, unsigned int)@Base" 0.14.0~ + (optional|c++|arch-bits=64)"Fm::FolderConfig::setStringList(char const*, char const* const*, unsigned long)@Base" 0.14.0~ + (optional|c++|arch-bits=32)"Fm::FolderConfig::setUint64(char const*, unsigned long long)@Base" 0.14.0~ + (optional|c++|arch-bits=64)"Fm::FolderConfig::setUint64(char const*, unsigned long)@Base" 0.14.0~ (c++)"Fm::FolderConfig::~FolderConfig()@Base" 0.14.0~ (c++)"Fm::FolderItemDelegate::FolderItemDelegate(QAbstractItemView*, QObject*)@Base" 0.10.0 (c++)"Fm::FolderItemDelegate::createEditor(QWidget*, QStyleOptionViewItem const&, QModelIndex const&) const@Base" 0.12.0 @@ -1146,70 +1146,25 @@ (c++)"std::_Fwd_list_base, std::allocator > >::_M_erase_after(std::_Fwd_list_node_base*, std::_Fwd_list_node_base*)@Base" 0.14.1 (c++|arch= !armel !armhf !i386 !mips !mipsel !hppa !hurd-i386 !kfreebsd-i386 !m68k !powerpc !powerpcspe !sh4 !x32 )"std::_Hashtable, std::allocator > const, std::pair, std::allocator > const, std::shared_ptr >, std::allocator, std::allocator > const, std::shared_ptr > >, std::__detail::_Select1st, std::equal_to, std::allocator > const>, std:
Bug#972789: qemu: FTBFS on arm{el,hf}: /<>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible
Source: qemu Version: 1:5.1+dfsg-4 Severity: serious Tags: ftbfs sid bullseye Justification: fails to build from source (but built successfully in the past) binNMUs of qemu for the libbrlapi transition failed to build on armel and armhf: | cc -iquote /<>/b/qemu/linux-user/m68k -iquote linux-user/m68k -iquote /<>/tcg/arm -isystem /<>/linux-headers -isystem /<>/b/qemu/linux-headers -iquote . -iquote /<> -iquote /<>/accel/tcg -iquote /<>/include -iquote /<>/disas/libvixl -I/usr/include/pixman-1 -pthread -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -fPIE -DPIE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -I/usr/include/p11-kit-1 -DSTRUCT_IOVEC_DEFINED -I/usr/include/libpng16 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/capstone -isystem ../linux-headers -iquote .. -iquote /<>/target/m68k -DNEED_CPU_H -iquote /<>/include -I/<>/linux-user/m68k -I/<>/linux-user/host/arm -I/<>/linux-user -Ilinux-user/m68k -MMD -MP -MT linux-user/m68k/signal.o -MF linux-user/m68k/signal.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -c -o linux-user/m68k/signal.o /<>/linux-user/m68k/signal.c | /<>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible |44 | }; | | ^ | | unit-size | align:32 warn_if_not_align:0 symtab:-1229976864 alias-set -1 canonical-type 0xb6f94420 precision:32 min max | pointer_to_this > | SI size unit-size | align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb5b48ba0 | domain unit-size | align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb6f94060 precision:32 min max > | SI size unit-size | align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb676d6c0 precision:32 min max >> | /<>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_MODE’ of ‘TYPE_CANONICAL’ is not compatible | | unit-size | align:32 warn_if_not_align:0 symtab:-1229976864 alias-set -1 canonical-type 0xb6f94420 precision:32 min max | pointer_to_this > | SI size unit-size | align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb5b48ba0 | domain unit-size | align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb6f94060 precision:32 min max > | SI size unit-size | align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb676d6c0 precision:32 min max >> | | unit-size | user align:16 warn_if_not_align:0 symtab:-1241131856 alias-set -1 canonical-type 0xb6f94420 precision:32 min max | pointer_to_this > | no-force-blk BLK size unit-size | user align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb5b48ba0 | domain unit-size | align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb6f94060 precision:32 min max > | SI size unit-size | align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb676d6c0 precision:32 min max >> | /<>/linux-user/m68k/signal.c:44:1: internal compiler error: ‘verify_type’ failed See https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=armhf&ver=1%3A5.1%2Bdfsg-4%2Bb1&stamp=1603242447&raw=0 for example Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Processed: Re: Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers
Processing control commands: > forwarded -1 https://bugs.launchpad.net/hplip/+bug/1901209 Bug #972339 [printer-driver-hpcups] armhf: hpcups crashes with free() invalid pointer for some printers Set Bug forwarded-to-address to 'https://bugs.launchpad.net/hplip/+bug/1901209'. -- 972339: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972339 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers
Control: forwarded -1 https://bugs.launchpad.net/hplip/+bug/1901209 Le vendredi, 23 octobre 2020, 09.42:59 h CEST Didier 'OdyX' Raboud a écrit : > As this is testable at build-time, I'll add a test for this and upload this > to experimental. I'll report this to upstream today. Damn. It seems the bug doesn't trigger in buildd environments. I have also tried building hplip on the abel.debian.org porterbox, and the build-time test doesn't fail there. So it seems that there's a reproductible bug when run: - in qemu - in ci.debian.net's - in a sid chroot in abel.debian.org … but not: - in a buildd build; - in a manual build in abel.debian.org. I'm wondering what makes the build process immune to that error. The attached script will fail in a sid chroot on armhf, and I have reported this to the upstream bugtracker at https://bugs.launchpad.net/hplip/+bug/1901209 -- OdyX test_972339.sh Description: application/shellscript signature.asc Description: This is a digitally signed message part.
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 03:27:23PM +0200, Guillem Jover wrote: > If we want to support the interim versions that have never been in a > stable release, then I think the only way is to bump the minmum > version in liburing shlibs and symbols files to 0.7, then rebuild the > couple of packages built with 0.6 against 0.7, and then add Breaks in > liburing against the old dependent package versions using the previous > liburing releases. Well, seemingly there are people who run old sid, and then only “apt update ; apt install plocate” -- which will pull in newer plocate but not liburing1 :-) But all that _must_ be supported as per Policy is upgrades from stable to stable, I believe? Not entirely sure how strict it is. It helps that liburing1 has never been in stable (only stable-bpo). > Otherwise I'll just package the new upstream release and request a > rebuild of reverse dependencies, and we could just ignore 0.7 as if > it never existed. :) Yes, a soname bump would certainly do the trick for unstable. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#972758: ABI breakage without soname bump
Control: forwarded -1 https://github.com/axboe/liburing/issues/228 Hi! On Fri, 2020-10-23 at 12:20:30 +0200, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 11:33:41AM +0200, Julien Cristau wrote: > > https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd > > seems to have bumped SONAME upstream. > > That would fix it, yes, but it seems to have missed the kflags change > (the commit says all added padding is at the end). > > The kflags change was made a month or so before 0.7 release: > > > https://github.com/axboe/liburing/commit/0f0517331307605e576b3492c93dc4988e06fdc0 Ouch, right, missed that one. :/ Thanks for the report and analysis. On Fri, 2020-10-23 at 12:47:00 +0200, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 12:41:36PM +0200, Julien Cristau wrote: > > All that's needed is a 0.8 release I guess. Reported and requested this upstream. > Yes, that would fix it. Optionally, one would require something like > a Breaks: liburing (<< 0.7-2) added on all packages compiled against > liburing, plus versioned Breaks on liburing1 on all packages in the > archive ever built against pre-0.7. :-/ If we want to support the interim versions that have never been in a stable release, then I think the only way is to bump the minmum version in liburing shlibs and symbols files to 0.7, then rebuild the couple of packages built with 0.6 against 0.7, and then add Breaks in liburing against the old dependent package versions using the previous liburing releases. Otherwise I'll just package the new upstream release and request a rebuild of reverse dependencies, and we could just ignore 0.7 as if it never existed. :) Thanks, Guillem
Processed: Re: Bug#972758: ABI breakage without soname bump
Processing control commands: > forwarded -1 https://github.com/axboe/liburing/issues/228 Bug #972758 [liburing1] ABI breakage without soname bump Set Bug forwarded-to-address to 'https://github.com/axboe/liburing/issues/228'. -- 972758: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972758 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972664: marked as done (kdepim-runtime trying to overwrite kcm_ldap.so from libkf5libkdepim-plugins)
Your message dated Fri, 23 Oct 2020 13:03:41 + with message-id and subject line Bug#972664: fixed in kdepim-runtime 4:20.08.2-3 has caused the Debian Bug report #972664, regarding kdepim-runtime trying to overwrite kcm_ldap.so from libkf5libkdepim-plugins to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 972664: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972664 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: kdepim-runtime Version: 4:20.08.2-2 Severity: important Dear Maintainer, On upgrading from 4:20.04.1-2: Unpacking kdepim-runtime (4:20.08.2-2) over (4:20.04.1-2) ... dpkg: error processing archive /tmp/apt-dpkg-install-pKyivo/07-kdepim-runtime_4%3a20.08.2-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/qt5/plugins/kcm_ldap.so', which is also in package libkf5libkdepim-plugins:amd64 4:20.04.1-2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Some Conflicts/Breaks/Replaces seem to be missing. Greetings, Haegar -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kdepim-runtime depends on: iu akonadi-server 4:20.08.2-2 iu kio 5.74.0-2 ii kio-ldap 20.04.1-2 ii libc62.31-4 ii libgcc-s110.2.0-15 ii libkf5akonadiagentbase5 [libkf5akonadiagentbase5-20.04] 4:20.04.1-4 pn libkf5akonadicalendar5-20.04 iu libkf5akonadicalendar5abi1 4:20.08.2-2 ii libkf5akonadicontact5 [libkf5akonadicontact5-20.04] 4:20.04.1-2 ii libkf5akonadicore5abi2 [libkf5akonadicore5-20.04]4:20.04.1-4 iu libkf5akonadimime5 4:20.08.2-2 pn libkf5akonadimime5-20.04 ii libkf5akonadinotes5 [libkf5akonadinotes5-20.04] 4:20.04.1-1 ii libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.04] 4:20.04.1-4 pn libkf5alarmcalendar5-20.04 iu libkf5alarmcalendar5abi1 4:20.08.2-2 iu libkf5calendarcore5abi2 5:5.74.0-2 iu libkf5codecs55.74.0-2 iu libkf5completion55.74.0-2 iu libkf5configcore55.74.0-2 iu libkf5configgui5 5.74.0-2 iu libkf5configwidgets5 5.74.0-2 iu libkf5contacts5 5:5.74.0-2 iu libkf5coreaddons55.74.0-2 ii libkf5dav5 [libkf5dav5-20.04]20.04.1-1 iu libkf5i18n5 5.74.0-2 ii libkf5identitymanagement5 [libkf5identitymanagement5-20.04] 20.04.1-2 ii libkf5imap5 [libkf5imap5-20.04] 20.04.1-2 iu libkf5jobwidgets55.74.0-2 iu libkf5kiocore5 5.74.0-2 iu libkf5kiowidgets55.74.0-2 ii libkf5mailtransport5 [libkf5mailtransport5-20.04]20.04.1-2 iu libkf5mailtransportakonadi5 20.08.2-2 pn libkf5mailtransportakonadi5-20.04 ii libkf5mbox5 [libkf5mbox5-20.04] 20.04.1-2 ii libkf5mime5abi1 [libkf5mime5-20.04] 20.04.1-1 iu libkf5notifications5 5.74.0-2 ii libkf5notifyconfig5 5.70.0-1 iu libkf5service-bin5.74.0-2 iu libkf5service5 5.74.0-2 iu libkf5textwidgets5 5.74.0-2 iu libk
Bug#972420: adios not supporting python3.9
So,
The current head of tree currently fails correctly when it tries to
build against all pythons and fails.
Unfortunately cython3 doesn't appeat to generate code (in some cases)
that works with python 3.9 :
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG
-g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat
-Werror=format-security -g -fwrapv -O2 -g -O2
-fdebug-prefix-map=/srv/build/adios/adios-1.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -D_NOMPI
-I/usr/lib/python3/dist-packages/numpy/core/include -I../../src/public
-I/usr/include -I/usr/include -I/usr/include/hdf5/serial
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include
-I/usr/include -I/usr/include -I/sr/include -I/usr/include -I/sr/include
-I/usr/include -I/usr/include/python3.8 -c adios.cpp -o
build/temp.linux-x86_64-3.8/adios.o -Wno-uninitialized -Wno-unused-function
In file included from
/usr/lib/python3/dist-packages/numpy/core/include/numpy/ndarraytypes.h:1822,
from
/usr/lib/python3/dist-packages/numpy/core/include/numpy/ndarrayobject.h:12,
from
/usr/lib/python3/dist-packages/numpy/core/include/numpy/arrayobject.h:4,
from adios.cpp:540:
/usr/lib/python3/dist-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2:
warning: #warning "Using deprecated NumPy API, disable it with "
"#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
17 | #warning "Using deprecated NumPy API, disable it with " \
| ^~~
adios.cpp:49053:3: error: cannot convert ‘PySequenceMethods*’ to
‘PyNumberMethods*’ in initialization
49053 | &__pyx_tp_as_sequence_softdict, /*tp_as_sequence*/
| ^~
| |
| PySequenceMethods*
adios.cpp:49398:3: error: cannot convert ‘PyObject* (*)(PyObject*)’ {aka
‘_object* (*)(_object*)’} to ‘PyAsyncMethods*’ in initialization
49398 | __pyx_pw_5adios_4file_19__repr__, /*tp_repr*/
| ^~~~
| |
| PyObject* (*)(PyObject*) {aka _object* (*)(_object*)}
regards
Alastair
--
Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
Processed: tagging 972762
Processing commands for cont...@bugs.debian.org: > tags 972762 + upstream pending Bug #972762 [src:bornagain] bornagain doesn't correctly detects python3.9 Added tag(s) upstream and pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 972762: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972762 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972596: marked as done (kmail: archivemailwidgettest hangs on armhf/mipsel)
Your message dated Fri, 23 Oct 2020 12:33:52 + with message-id and subject line Bug#972596: fixed in kmail 4:20.08.2-3 has caused the Debian Bug report #972596, regarding kmail: archivemailwidgettest hangs on armhf/mipsel to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 972596: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972596 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: kmail Version: 4:20.08.2-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) kmail failed to build on armhf: | make[2]: Entering directory '/<>/obj-arm-linux-gnueabihf' | Running tests... | /usr/bin/ctest --force-new-ctest-process -j1 | Test project /<>/obj-arm-linux-gnueabihf | Start 1: displaymessageformatactionmenutest | 1/27 Test #1: displaymessageformatactionmenutest Passed1.48 sec | Start 2: cryptostateindicatorwidgettest | 2/27 Test #2: cryptostateindicatorwidgettest Passed1.22 sec | Start 3: kactionmenutransporttest | 3/27 Test #3: kactionmenutransporttest .. Passed1.11 sec | Start 4: akonadi-sqlite-tagselectdialogtest | 4/27 Test #4: akonadi-sqlite-tagselectdialogtest ***Failed0.08 sec | org.kde.pim.akonaditest: Started akonadi daemon with pid: 0 | org.kde.pim.akonaditest: Failed to start Akonadi server! | | Start 5: akonadi-sqlite-kmcommandstest | 5/27 Test #5: akonadi-sqlite-kmcommandstest .***Failed0.07 sec | org.kde.pim.akonaditest: Started akonadi daemon with pid: 0 | org.kde.pim.akonaditest: Failed to start Akonadi server! See https://buildd.debian.org/status/fetch.php?pkg=kmail&arch=armhf&ver=4%3A20.08.2-2&stamp=1603221672&raw=0 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Source: kmail Source-Version: 4:20.08.2-3 Done: Pino Toscano We believe that the bug you reported is fixed in the latest version of kmail, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 972...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Pino Toscano (supplier of updated kmail package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 23 Oct 2020 14:21:38 +0200 Source: kmail Architecture: source Version: 4:20.08.2-3 Distribution: unstable Urgency: medium Maintainer: Debian/Kubuntu Qt/KDE Maintainers Changed-By: Pino Toscano Closes: 972596 Changes: kmail (4:20.08.2-3) unstable; urgency=medium . * Team upload. * Disable the unit tests, as they may take too long, and they do not fully pass anyway: (Closes: #972596) - pass -DBUILD_TESTING=OFF to cmake to disable their build - leave an empty dh_auto_test override - drop the xauth, and xvfb build dependencies Checksums-Sha1: c0ff5bbd5b1cdd4431c6f6ccb592286a489c0491 4371 kmail_20.08.2-3.dsc 3f0eb9f6567b3825786ee167e1dcd9e87f4b7444 15592 kmail_20.08.2-3.debian.tar.xz 015e398c6dfca1f071288eb84718e093b6a3d89a 22209 kmail_20.08.2-3_source.buildinfo Checksums-Sha256: e6ea72408c9af9b7d2a33c7992ee5933b1deeb497101cdcec55725a2df1c5d71 4371 kmail_20.08.2-3.dsc 91d3152334e9e660be523cb0e853abc438fb92a4a0decfb379a8eaa4a92ce503 15592 kmail_20.08.2-3.debian.tar.xz 91efc6cdc81c434c47c71bcf4404e70e4eb97ca5659594f931fd81c0ecaab1a2 22209 kmail_20.08.2-3_source.buildinfo Files: c342f4d4d9f3487abaa57b341d949491 4371 kde optional kmail_20.08.2-3.dsc d55f99c6880a76be8b31108aaa427a85 15592 kde optional kmail_20.08.2-3.debian.tar.xz 212673973bd09ea6f8f1cbf9b8344c7c 22209 kde optional kmail_20.08.2-3_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEXyqfuC+mweEHcAcHLRkciEOxP00FAl+SyvcACgkQLRkciEOx P00waQ//e7Q3+Z3egszIR1+aEWHZbW4DDNZ0QEtdJHkd/sidk9a32K2+TuYpEQUZ 1ZRHWXL1i1P9+gvVXR6Y56dj9USGp7qL/6/dPLVDRDsvBZCz30w7DWC8z8OKlBuX nnWY2fpTiWqIpkNvCrvld3mTbmehSbTj1LaWpqyPgACkrye/0st2zf2iZmA/NB6s lk5g+Qv1Yykm3u9PRvYAQ6dx+Vau+I8FG9kY0JyJ9xpK9INzdvafP+4B8YJeF+6I T7rKs40kO5MoNp9KD8HhWoGMeqDckubhqArZZMz2cStCMCiQhzjZ1JiItiIwPnz/ 9ZRSfQ
Processed: severity of 972664 is serious, tagging 972664
Processing commands for cont...@bugs.debian.org: > severity 972664 serious Bug #972664 [kdepim-runtime] kdepim-runtime trying to overwrite kcm_ldap.so from libkf5libkdepim-plugins Severity set to 'serious' from 'important' > tags 972664 + pending Bug #972664 [kdepim-runtime] kdepim-runtime trying to overwrite kcm_ldap.so from libkf5libkdepim-plugins Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 972664: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972664 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972224: marked as done (zanshin: FTBFS against KDEPIM 20.08)
Your message dated Fri, 23 Oct 2020 12:04:48 + with message-id and subject line Bug#972224: fixed in zanshin 0.5.71-2 has caused the Debian Bug report #972224, regarding zanshin: FTBFS against KDEPIM 20.08 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 972224: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972224 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: zanshin Version: 0.5.71-1 Severity: normal Tags: ftbfs Hey, I built zanshin against new KDEPIM 20.08 and it fails with: /<>/obj-x86_64-linux-gnu/src/zanshin/kontact/kontact_zanshinplugin_autogen/EWIEGA46WW/../../../../../../src/zanshin/kontact/kontact_plugin.h:39:13: error: ‘ReadOnlyPart’ in namespace ‘KParts’ does not name a type 39 | KParts::ReadOnlyPart *createPart() override; | ^~~~ There is already a patch in the upstream repository: https://invent.kde.org/pim/zanshin/-/commit/4850c08998b33b37af99c3312d19 To build against kdepim 20.08 you can use the http://qt-kde-team.debian.net/ repo. I'll upload kdepim the next days to experimental. hefee --- End Message --- --- Begin Message --- Source: zanshin Source-Version: 0.5.71-2 Done: Pino Toscano We believe that the bug you reported is fixed in the latest version of zanshin, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 972...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Pino Toscano (supplier of updated zanshin package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 23 Oct 2020 13:52:07 +0200 Source: zanshin Architecture: source Version: 0.5.71-2 Distribution: unstable Urgency: medium Maintainer: Debian KDE Extras Team Changed-By: Pino Toscano Closes: 972224 Changes: zanshin (0.5.71-2) unstable; urgency=medium . * Team upload. . [ Norbert Preining ] * Fix compilation with KDE Apps 20.08 (Closes: #972224) . [ Pino Toscano ] * Bump the debhelper compatibility to 13: - switch the debhelper build dependency to debhelper-compat 13 * Remove the explicit as-needed linking, as it is done by binutils now. * Bump Standards-Version to 4.5.0, no changes required. * Remove obsolete field Name from debian/upstream/metadata (already present in machine-readable debian/copyright). * Fix references to the upstream Git repository. Checksums-Sha1: 519d0dc0fcf746b2bc33fe405a33f5990cda64ca 2389 zanshin_0.5.71-2.dsc 7d3942d7b768d8014fd805e710f00775e19d1567 9340 zanshin_0.5.71-2.debian.tar.xz 54f16e28dcb99d9647bdca51a67b63d4750738da 20535 zanshin_0.5.71-2_source.buildinfo Checksums-Sha256: 89ca2315f03687900ae371f50cb15c5c6908f234417707a97594d8bdc824cd06 2389 zanshin_0.5.71-2.dsc 38f4eea0566440f0d6802fb5c94aa2ded99bf1676a3a88323c74c435ec275037 9340 zanshin_0.5.71-2.debian.tar.xz 694c28b6c6714c73dab9db395ad7f285ddc6ce3694c1eaa71b9795a90a5d1e4c 20535 zanshin_0.5.71-2_source.buildinfo Files: 723ff4769a25163f88e426bddd76a2bf 2389 kde optional zanshin_0.5.71-2.dsc d4848204601c4f7952c9a1fd60ede700 9340 kde optional zanshin_0.5.71-2.debian.tar.xz 8156118127232ab302283c34c5fb0fea 20535 kde optional zanshin_0.5.71-2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEXyqfuC+mweEHcAcHLRkciEOxP00FAl+SxAUACgkQLRkciEOx P002xg//YUL5Lpb+CcrVrlz0+JcpVbPTM6zzbVQaZp99TkXABu9SpdFf2m+5hmQu 4AbDaeFDhusrvpJid5YRFDrbQcSw1AB/47VmendxlxKV1Ymz39DHsg3hSR7NKrUI J108Cu0tl+Go1DBouas4NCt3ukoXMihOkS5Fqwy7nKWluL26sd5mpm7DAzey0vwy DZI0zP2HZG/sALlaFcpZjT/uAGFV+R2xLfpv6iKEHug1/wPiJhsS1E9GlfmhN/Vl Tu/EYqVc9LBLyB5XcLdcbcZNhrjFWx7g9P8RyUpffMw1tQrT59oDUN9qmNS5IR6w 64nqeD7S3VUuz662/bSqYeKn85wkmuH/Wdn7EbtYjwUiVU+XcYRx18c7aHtbPz0n 83P1aTtkPDdCYCRh3fqZQolHlVAeEBaIFMLY5PwgcA/GibL8shke/KC3pz04SmTc PaA/Ic61aGgJMayACZokdS47oxhOS/dgK6CuOOJ2DdUcugUW4vmPfH/sV2n8E5vE WBwtXwtjyEf2olpBhat0xmc0srEnUf5EGNoteblcM1H07XuVv1nh294MwnLQetWn 912GCfQJP2qLN0DMB5T6b7OWT8XItQecTmCa4xt+EXTs6ueGaB9CT5i0/jyqWoFu 5asNq3dE6ubwSk/hIbdmINVNSihRApJd19oXhBWSYyvUlQYQ+T8= =Zry3 -END PGP SIGNATURE End Message ---
Bug#972226: marked as done (kjots: FTBFS with KDEPIM 20.08)
Your message dated Fri, 23 Oct 2020 11:48:33 + with message-id and subject line Bug#972226: fixed in kjots 4:5.0.2-3 has caused the Debian Bug report #972226, regarding kjots: FTBFS with KDEPIM 20.08 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 972226: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972226 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: kjots Version: 4:5.0.2-2 Severity: normal Tags: ftbfs Hey, kjots failed to build against KDEPIM 20.08: /<>/obj-x86_64-linux-gnu/src/kontact_plugin/kontact_kjotsplugin_autogen/EWIEGA46WW/../../../../../src/kontact_plugin/kjots_plugin.h:66:13: error: ‘ReadOnlyPart’ in namespace ‘KParts’ does not name a type 66 | KParts::ReadOnlyPart *createPart() Q_DECL_OVERRIDE; | ^~~~ there is alaready an patch upstream to fix this: https://invent.kde.org/pim/kjots/-/commit/bcf49fb95bee12bbc4bef0578285ad296deafcae You can build against new KDEPIM 20.08 with the repo: http://qt-kde-team.debian.net/ hefee --- End Message --- --- Begin Message --- Source: kjots Source-Version: 4:5.0.2-3 Done: Pino Toscano We believe that the bug you reported is fixed in the latest version of kjots, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 972...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Pino Toscano (supplier of updated kjots package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 23 Oct 2020 13:36:05 +0200 Source: kjots Architecture: source Version: 4:5.0.2-3 Distribution: unstable Urgency: medium Maintainer: Debian/Kubuntu Qt/KDE Maintainers Changed-By: Pino Toscano Closes: 972226 Changes: kjots (4:5.0.2-3) unstable; urgency=medium . * Team upload. . [ Norbert Preining ] * Fix compilation with KDE Apps 20.08 (Closes: #972226) . [ Pino Toscano ] * Bump the debhelper compatibility to 13: - switch the debhelper-compat build dependency to 13 * Remove the explicit as-needed linking, as it is done by binutils now. * Add Rules-Requires-Root: no. * Bump Standards-Version to 4.5.0, no changes required. * Set fields Upstream-Name, Upstream-Contact in debian/copyright. * Remove obsolete fields Contact, Name from debian/upstream/metadata (already present in machine-readable debian/copyright). Checksums-Sha1: 6c410ae0f0c62cae7148326215957c886a57b77f 2469 kjots_5.0.2-3.dsc f123d6d26d67c7aaedd7c98aef5978bad8c96a9e 5632 kjots_5.0.2-3.debian.tar.xz ab19932e9482db06ec982dbed16ab08c55a51439 20961 kjots_5.0.2-3_source.buildinfo Checksums-Sha256: 603106cb1644cb9ccf78e47fa0af6684bc23bc0e4da5642c40d1f24b98461280 2469 kjots_5.0.2-3.dsc 4542d9c85127f958c51a77edc9b4c7dc9856ef26da3c5b2412ba601e481c3dc2 5632 kjots_5.0.2-3.debian.tar.xz a2d64980f35499dc8e1deb82aebd1aa4fb62275d9a834536a56c9451c377fd29 20961 kjots_5.0.2-3_source.buildinfo Files: 9a2ab4cff9e8096117acfa63afe9 2469 kde optional kjots_5.0.2-3.dsc db3e551695abcce73a3b6c4f387550e8 5632 kde optional kjots_5.0.2-3.debian.tar.xz bf4b717b2d2336f6531760822ca06fee 20961 kde optional kjots_5.0.2-3_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEXyqfuC+mweEHcAcHLRkciEOxP00FAl+SwEoACgkQLRkciEOx P01pCw//VQPNyDFvD7+ebmJTsMlVXb+Zlxi2iLRAAag4tgrM7bwtETF6kVI9ewBc LyrRk3XUdG+3wW63jAlj1becxlyp2VYIxveMu5f44bSEw6L5QMM5J50xJo+7Fqij 3e+UBq/+gGZDIaqM/xUqXkmPc7pg1KMCRDW6BzTiXxPwAWw6dFfFqEEdga8LF525 tZ3gmnaV1hLBNDxi6ivA+cEudoI22mhOHg6/myY30VZcyjeI/O2rbCYi3yXfa845 O2iaQAuHJBXcakUZbh/CPPuIgZThBKXRovZwAO7edV6RtYEQ0XPyGM82raKKp6Jl 1pa88O9kC/Yq9x/2k3ddOkxWnKZeyQpaEyHEDjIhzLYFvHPsXk+7IWaKASbmcvaJ Yj0zCjHZqs7junWoUDWTLqysefuSZH992BGBYSUz5BRT61Eg8ccDRHmNuYbde2r4 JwTfX00LLjuLYlYpZ5SgsIHunkMkvP81pi2qBZMrpaXkQBGkWkDPdkJerQwqq4aX Gt168fpVv0WNPgcAzYG2ZoQzYmuHnGAD7WYPPeITGbM0nQU62n9OxdB7nVuvQRdp WMr2SpGhrXXmwalrj5KHqzmOuU84FVcWFSHXDpd/slEpF0R13p7ALPaoRnboeJOc lV/caZr/HTj5Ac4Wv7q4PhFPZOuvjFmrwmLKiuzBcasnCMUw9Ls= =zz+R -END PGP SIGNATURE End Message ---
Bug#972589: marked as done (kitinerary FTBFS on mipsel/mips64el/riscv64: test failures)
Your message dated Fri, 23 Oct 2020 11:33:35 +
with message-id
and subject line Bug#972589: fixed in kitinerary 20.08.2-4
has caused the Debian Bug report #972589,
regarding kitinerary FTBFS on mipsel/mips64el/riscv64: test failures
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
972589: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972589
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: kitinerary
Version: 20.08.2-2
Severity: serious
Tags: ftbfs
It is surprising that even the failing tests that look
like a timezone issue are reproducibly architecture specific.
kitinerary builds for riscv64 on Ubuntu, but they are
just ignoring test results.
https://buildd.debian.org/status/package.php?p=kitinerary
...
6/29 Test #6: knowledgedbtest ..***Failed0.45 sec
* Start testing of KnowledgeDbTest *
Config: Using QtTest library 5.14.2, Qt 5.14.2
(mips64-little_endian-lp64-n64-hardfloat shared (dynamic) release build; by GCC
10.2.0)
PASS : KnowledgeDbTest::initTestCase()
PASS : KnowledgeDbTest::testUnalignedNumber()
QDEBUG : KnowledgeDbTest::testAlphaId() "ABC"
PASS : KnowledgeDbTest::testAlphaId()
FAIL! : KnowledgeDbTest::testIBNRLookup() Compared values are not the same
Loc: [/<>/autotests/knowledgedbtest.cpp(93)]
FAIL! : KnowledgeDbTest::testUICLookup() Compared values are not the same
Loc: [/<>/autotests/knowledgedbtest.cpp(120)]
FAIL! : KnowledgeDbTest::testSncfStationIdLookup() Compared values are not the
same
Loc: [/<>/autotests/knowledgedbtest.cpp(136)]
PASS : KnowledgeDbTest::testCountryDb()
PASS : KnowledgeDbTest::testPowerPlugCompat(empty)
PASS : KnowledgeDbTest::testPowerPlugCompat(DE-DE)
PASS : KnowledgeDbTest::testPowerPlugCompat(DE-CH)
PASS : KnowledgeDbTest::testPowerPlugCompat(CH-DE)
PASS : KnowledgeDbTest::testPowerPlugCompat(DE-FR)
PASS : KnowledgeDbTest::testPowerPlugCompat(DE-GB)
PASS : KnowledgeDbTest::testPowerPlugCompat(DE-IT)
PASS : KnowledgeDbTest::testPowerPlugCompat(IT-DE)
PASS : KnowledgeDbTest::testPowerPlugCompat(DE-IL)
PASS : KnowledgeDbTest::testPowerPlugCompat(DE-AO)
PASS : KnowledgeDbTest::testPowerPlugCompat(AO-DE)
PASS : KnowledgeDbTest::testPowerPlugCompat(DE-DK)
PASS : KnowledgeDbTest::testPowerPlugCompat(DK-DE)
PASS : KnowledgeDbTest::testPowerPlugCompat(DE-ZA)
PASS : KnowledgeDbTest::testPowerPlugCompat(ZA-CH)
PASS : KnowledgeDbTest::testPowerPlugCompat(ZA-DE)
PASS : KnowledgeDbTest::testPowerPlugCompat(ZA-IT)
PASS : KnowledgeDbTest::testTimezoneForCountry()
PASS : KnowledgeDbTest::testCountryForTimezone()
PASS : KnowledgeDbTest::testTimezoneForLocation()
PASS : KnowledgeDbTest::testCountryFromCoordinate()
PASS : KnowledgeDbTest::testUICCountryCodeLookup()
PASS : KnowledgeDbTest::testIso3Lookup()
FAIL! : KnowledgeDbTest::testIndianRailwaysStationCodeLookup() Compared values
are not the same
Loc: [/<>/autotests/knowledgedbtest.cpp(339)]
FAIL! : KnowledgeDbTest::testFinishStationCodeLookup() Compared values are not
the same
Loc: [/<>/autotests/knowledgedbtest.cpp(359)]
PASS : KnowledgeDbTest::cleanupTestCase()
Totals: 28 passed, 5 failed, 0 skipped, 0 blacklisted, 19ms
* Finished testing of KnowledgeDbTest *
...
26/29 Test #26: calendarhandlertest ..***Failed0.54 sec
* Start testing of CalendarHandlerTest *
Config: Using QtTest library 5.14.2, Qt 5.14.2
(mips64-little_endian-lp64-n64-hardfloat shared (dynamic) release build; by GCC
10.2.0)
PASS : CalendarHandlerTest::initTestCase()
PASS : CalendarHandlerTest::testCreateEvent(canceled.json)
PASS : CalendarHandlerTest::testCreateEvent(event.json)
PASS : CalendarHandlerTest::testCreateEvent(eventreservation.json)
QWARN : CalendarHandlerTest::testCreateEvent(flight.json) org.kde.kitinerary:
IATA BCBP code too short for unique mandatory section, or invalid mandatory
section format
PASS : CalendarHandlerTest::testCreateEvent(flight.json)
QDEBUG : CalendarHandlerTest::testCreateEvent(hotel.json) Actual:
BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:2.0
X-KDE-ICAL-IMPLEMENTATION-VERSION:1.0
BEGIN:VEVENT
DTSTAMP:20171227T111649Z
X-KDE-KITINERARY-RESERVATION:[{"@context":"http://schema.org"\,"@type":
"LodgingReservation"\,"checkinTime":"2017-09-19T15:00:00+03:
00"\,"checkoutTime":"2017-09-20T12:00:00+03:00"\,"potentialAction":
[{"@type":"CancelAction"\,"target":"https:
//secure.booking.com/mybooking.en-gb.html?auth_key=magic&source=conf_metad
ata&pbsource=email_cancel"}\,{"@type":
Bug#970606: [Openjdk] Bug#970606: Bug#970606: src:openjdk-*: autopkgtest times out on Debian/Ubuntu infrastructure
On 10/7/20 10:33 PM, Paul Gevers wrote: > Hi Matthias, > > On 21-09-2020 17:52, Paul Gevers wrote: >>> Apparently >>> the very same tests don't time out on the buildds. >> >> I don't know what timeouts apply to buildds, but indeed I think they are >> much higher to cope with *building* some extremely big packages. > > Do you know how much time these tests would take? If so, I wonder if we > should make it possible for individual packages to have a longer > timeout. It would be work on the debci/ci.d.n side of things, but not > impossible of course. For an upper bound, use the build time: The very same tests are run during the build. And I think this is done for many packages. The other question is, if it's sensible to run the upstream test suite as an autopkg test, if it's already run during the build. Ideally it should only run the autopkg tests which test on integration issues with run time dependencies, but this would require analyzing some 1 tests and For now I just disabled the jdk tests as an autopkg test. So please clear the test results, to run it again, and let it migrate. Matthias
Processed: tagging 972589
Processing commands for cont...@bugs.debian.org: > tags 972589 + pending Bug #972589 [src:kitinerary] kitinerary FTBFS on mipsel/mips64el/riscv64: test failures Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 972589: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972589 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972730: marked as done (python-mpd: autopkgtest fails when two python3 versions are supported)
Your message dated Fri, 23 Oct 2020 10:50:06 +
with message-id
and subject line Bug#972730: fixed in python-mpd 1.1.0-3
has caused the Debian Bug report #972730,
regarding python-mpd: autopkgtest fails when two python3 versions are supported
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
972730: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972730
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: python-mpd
Severity: normal
Dear Maintainer,
Hi,
I got confused and thought this package was maintained by the Python
team and uploaded an autopkgtest fix. Sorry! At least the change is
hopefully non-controversial.
I've made a merge request on salsa:
https://salsa.debian.org/mpd-team/python-mpd/-/merge_requests/1
but filing the bug here to to make sure the maintainers see the change.
Cheers,
mwh
-- System Information:
Debian Release: bullseye/sid
APT prefers focal-updates
APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'),
(400, 'focal-proposed'), (100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
Source: python-mpd
Source-Version: 1.1.0-3
Done: Simon McVittie
We believe that the bug you reported is fixed in the latest version of
python-mpd, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 972...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Simon McVittie (supplier of updated python-mpd package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 23 Oct 2020 10:32:04 +0100
Source: python-mpd
Architecture: source
Version: 1.1.0-3
Distribution: unstable
Urgency: medium
Maintainer: mpd maintainers
Changed-By: Simon McVittie
Closes: 972730
Changes:
python-mpd (1.1.0-3) unstable; urgency=medium
.
[ Michael Hudson-Doyle ]
* d/test/{control,python3}: Fix test when more than one version of
Python 3 is supported (Closes: #972730)
- Don't quote output of pyversions -s
- Add python3-all to Depends:
.
[ Simon McVittie ]
* Mark python-mpd-doc as Multi-Arch: foreign
* Remove build-dependency on dh-exec, no longer needed
* Build-Depend on dh-sequence-* to reduce repetition
Checksums-Sha1:
165cb5c7c72e235e3dfb232de6e92961886c14cb 2435 python-mpd_1.1.0-3.dsc
ac026d2cf79c5f315f8e4b4acd50335f92f45a3a 6660 python-mpd_1.1.0-3.debian.tar.xz
43eca6c249eea7a0988077c1c983d07d80500f0d 7706
python-mpd_1.1.0-3_source.buildinfo
Checksums-Sha256:
edf6bee55698790c8af34dc3e7b9161e181fac934e3031aca2029c6ec3edc89e 2435
python-mpd_1.1.0-3.dsc
695396de5a5ba1709048fe59136b0bc22dae7c5c17b4c0d2ee9f762596cf4fd1 6660
python-mpd_1.1.0-3.debian.tar.xz
5ca5cb76b5d20f460743218cf257ac69a73086b7e86de1eb946c2ad3630fdfba 7706
python-mpd_1.1.0-3_source.buildinfo
Files:
ccb9281eb740c35dceeb0e523bd673f8 2435 python optional python-mpd_1.1.0-3.dsc
81e7a2d3491eb7f591de25ba0731ea45 6660 python optional
python-mpd_1.1.0-3.debian.tar.xz
68b0e702261d93f73c30484ad10736ef 7706 python optional
python-mpd_1.1.0-3_source.buildinfo
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEENuxaZEik9e95vv6Y4FrhR4+BTE8FAl+SsLUACgkQ4FrhR4+B
TE81MQ//WAfuzJAeRp4J8VhmWj3Z22r0SsTKKQre3alTkHHcapBoZ59ztnzNjfLH
vLOWodI6SdxA7z7oENXpp5ACq9JhWDLS9vFKt1j4GrxGP5vI7sTR2LzNbdoMJyiZ
3xtgjh38LXCS2sj2eTql7EEOUX1yrDpK0aBwUBgvUQTISUDsbr9Ww87KwbT7fSKS
cffsunGoVqEJW5GA6e38B0+KdFDyofvOxojH6ttYaHF6tR6oK3M8eAvIpuydm01w
lSuwLMY0EPb9JixlwPCgjbrlZa00REF0DWqCC3ofwXK0inHSYs2xWqfO80zyU1mb
Q7VCAEowbjmIVFcRerAxjYhRFnaaUzPVfEIQ0AOWLINKN0W875Rc8Wl8iX9tC6Y4
zBf8tdsTKgvRgouMkbHOv83EvhIfx+bPybmDVe496r6CMJRQGEZ2YTxCi+Fe82QK
5U2Xtn6Bd8oxFu2pgFDo7Ucb+rzb2f4RBvqvd6N2mJqikbs1j4nRnpK5A6SLAt37
7NaXDyYCoPbMncLPOaXKmCOSYjX4ChSPc17PCBeSlokRj/9DwBVWo2OpDNjZE7A6
P4azTsTUy8kywK4Be9HtXVZ1C5vqgGoFk6z3MFrzcB8GrHCFRSmWavabqnOkzlpQ
pupCa6+KH5B
Bug#972317: FTBFS on ppc64el
The actual error seems to be: #0 0x7fff8e95743c llvm::sys::PrintStackTrace(llvm::raw_ostream&) /<>/llvm/lib/Support/Unix/Signals.inc:533:13 #1 0x7fff8e9577a0 PrintStackTraceSignalHandler(void*) /<>/llvm/lib/Support/Unix/Signals.inc:593:3 #2 0x7fff8e954df8 llvm::sys::RunSignalHandlers() /<>/llvm/lib/Support/Signals.cpp:67:5 #3 0x7fff8e957b2c SignalHandler(int) /<>/llvm/lib/Support/Unix/Signals.inc:375:3 #4 0x7fff94d304d8 (linux-vdso64.so.1+0x4d8) #5 0x7fff8e93f220 getLHSKind /<>/llvm/include/llvm/ADT/Twine.h:239:42 #6 0x7fff8e93f220 isNull /<>/llvm/include/llvm/ADT/Twine.h:189:14 #7 0x7fff8e93f220 concat /<>/llvm/include/llvm/ADT/Twine.h:490:9 #8 0x7fff8e93f220 llvm::operator+(llvm::Twine const&, llvm::Twine const&) /<>/llvm/include/llvm/ADT/Twine.h:518:16 #9 0x7fff8ee621e0 llvm::TargetLoweringBase::computeRegisterProperties(llvm::TargetRegisterInfo const*) /<>/llvm/lib/CodeGen/TargetLoweringBase.cpp:1260:42 #10 0x7fff909186cc llvm::PPCTargetLowering::PPCTargetLowering(llvm::PPCTargetMachine const&, llvm::PPCSubtarget const&) /<>/llvm/lib/Target/PowerPC/PPCISelLowering.cpp:1204:3 #11 0x7fff90984ae0 llvm::PPCSubtarget::PPCSubtarget(llvm::Triple const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, llvm::PPCTargetMachine const&) /<>/llvm/lib/Target/PowerPC/PPCSubtarget.cpp:60:25 #12 0x7fff90986448 make_unique &, std::__cxx11::basic_string, const llvm::PPCTargetMachine &> /<>/llvm/include/llvm/ADT/STLExtras.h:1406:33 #13 0x7fff90986448 llvm::PPCTargetMachine::getSubtargetImpl(llvm::Function const&) const /<>/llvm/lib/Target/PowerPC/PPCTargetMachine.cpp:331:9 #14 0x7fff90986654 PPCTTIImpl /<>/llvm/lib/Target/PowerPC/PPCTargetTransformInfo.h:40:59 #15 0x7fff90986654 llvm::PPCTargetMachine::getTargetTransformInfo(llvm::Function const&) /<>/llvm/lib/Target/PowerPC/PPCTargetMachine.cpp:520:30 #16 0x7fff8ff1ce3c operator() /<>/llvm/lib/Target/TargetMachine.cpp:283:48 #17 0x7fff8ff1ce3c __invoke_impl>/llvm/lib/Target/TargetMachine.cpp:283:7) &, const llvm::Function &> /usr/lib/gcc/powerpc64le-linux-gnu/10/../../../../include/c++/10/bits/invoke.h:60:14 #18 0x7fff8ff1ce3c __invoke_r>/llvm/lib/Target/TargetMachine.cpp:283:7) &, const llvm::Function &> /usr/lib/gcc/powerpc64le-linux-gnu/10/../../../../include/c++/10/bits/invoke.h:141:14 #19 0x7fff8ff1ce3c std::_Function_handler::_M_invoke(std::_Any_data const&, llvm::Function const&) /usr/lib/gcc/powerpc64le-linux-gnu/10/../../../../include/c++/10/bits/std_function.h:291:9 #20 0x7fff8fa3b0bc operator() /usr/lib/gcc/powerpc64le-linux-gnu/10/../../../../include/c++/10/bits/std_function.h:622:14 #21 0x7fff8fa3b0bc run /<>/llvm/lib/Analysis/TargetTransformInfo.cpp:1340:10 #22 0x7fff8fa3b0bc llvm::TargetTransformInfoWrapperPass::getTTI(llvm::Function const&) /<>/llvm/lib/Analysis/TargetTransformInfo.cpp:1371:14 #23 0x7fff8f652254 (anonymous namespace)::CFGSimplifyPass::runOnFunction(llvm::Function&) /<>/llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp:268:63 #24 0x7fff8eaa6874 llvm::FPPassManager::runOnFunction(llvm::Function&) /<>/llvm/lib/IR/LegacyPassManager.cpp:1648:27 #25 0x7fff8eaa5cbc llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) /<>/llvm/lib/IR/LegacyPassManager.cpp:1585:44 #26 0x7fff8eaa5bdc llvm::legacy::FunctionPassManager::run(llvm::Function&) /<>/llvm/lib/IR/LegacyPassManager.cpp:1510:15 #27 0x7fff9399c658 EmitAssembly /<>/clang/lib/CodeGen/BackendUtil.cpp:887:27 #28 0x7fff9399c658 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptrstd::default_delete >) /<>/clang/lib/CodeGen/BackendUtil.cpp:1498:15 #29 0x7fff93c1dfd0 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) /<>/clang/lib/CodeGen/CodeGenAction.cpp:303:7 #30 0x7fff92d17ad0 clang::ParseAST(clang::Sema&, bool, bool) /<>/clang/lib/Parse/ParseAST.cpp:171:13 #31 0x7fff94312d28 clang::ASTFrontendAction::ExecuteAction() /<>/clang/lib/Frontend/FrontendAction.cpp:1041:3 #32 0x7fff93c1cb84 clang::CodeGenAction::ExecuteAction() /<>/clang/lib/CodeGen/CodeGenAction.cpp:1059:28 #33 0x7fff94312520 clang::FrontendAction::Execute() /<>/clang/lib/Frontend/FrontendAction.cpp:934:8 #34 0x7fff942ca6d8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /<>/clang/lib/Frontend/CompilerInstance.cpp:944:33 #35 0x7fff9438fd80 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /<>/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:291:25 #36 0x100a1cdc cc1_main(llvm::ArrayRef, char const*, void*) /<>/clang/tools/driver/cc1_main.cpp:249:15 #37 0x1009f6e0 ExecuteCC1Tool /<>/clang/tools/driver/driver.cpp:309:12 #38 0x0
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 12:41:36PM +0200, Julien Cristau wrote: > All that's needed is a 0.8 release I guess. Yes, that would fix it. Optionally, one would require something like a Breaks: liburing (<< 0.7-2) added on all packages compiled against liburing, plus versioned Breaks on liburing1 on all packages in the archive ever built against pre-0.7. :-/ /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#972780: mytop has wrong shebang
Package: mariadb-client-10.3 Version: 1:10.3.25-0+deb10u1 Severity: grave Hello, on start mytop a get: [quote] > mytop /usr/bin/env: „perl -w“: Datei oder Verzeichnis nicht gefunden /usr/bin/env: use -[v]S to pass options in shebang lines [/quote] CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores) 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=de_DE:en_US:de_LU:de_CH:de_BE:de_AT (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-client-10.3 depends on: ii debianutils 4.8.6.1 ii libc6 2.28-10 ii libconfig-inifiles-perl 3.01-1 ii libgnutls30 3.6.7-4+deb10u5 ii libstdc++68.3.0-6 ii mariadb-client-core-10.3 1:10.3.25-0+deb10u1 ii perl 5.28.1-6+deb10u1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages mariadb-client-10.3 recommends: ii libdbd-mysql-perl 4.050-2 ii libdbi-perl 1.642-1+deb10u1 ii libterm-readkey-perl 2.38-1 mariadb-client-10.3 suggests no packages. -- Configuration Files: /etc/mysql/mariadb.conf.d/50-client.cnf changed: [client] loose-default-character-set = utf8 [client-mariadb] /etc/mysql/mariadb.conf.d/50-mysql-clients.cnf changed: [mysql] default-character-set = utf8 [mysql_upgrade] [mysqladmin] [mysqlbinlog] [mysqlcheck] [mysqldump] [mysqlimport] [mysqlshow] [mysqlslap] -- no debconf information
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 12:20:30PM +0200, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 11:33:41AM +0200, Julien Cristau wrote: > > https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd > > seems to have bumped SONAME upstream. > > That would fix it, yes, but it seems to have missed the kflags change > (the commit says all added padding is at the end). > > The kflags change was made a month or so before 0.7 release: > > > https://github.com/axboe/liburing/commit/0f0517331307605e576b3492c93dc4988e06fdc0 > Yeah, I'm not saying the commit message is accurate, just that that change will end up fixing this bug. :) All that's needed is a 0.8 release I guess. Cheers, Julien
Bug#972774: ros-ros ftbfs
Control: reassign -1 googletest Control: forcemerge 972618 -1 Control: reassign 972775 googletest Control: forcemerge 972618 972775 Control: affects -1 src:ros-ros src:ros-rospack Hi Doko, * Matthias Klose [2020-10-23 12:07]: ros-ros ftbfs with python3.9 (python3-defaults from experimental), not yet convinced if that's related to python3.9, looks more like a googletest issue. [..] CMake Error at /usr/src/googletest/googletest/CMakeLists.txt:129 (set_target_properties): set_target_properties called with incorrect number of arguments. CMake Error at /usr/src/googletest/googletest/CMakeLists.txt:132 (set_target_properties): set_target_properties called with incorrect number of arguments. Yes, this looks exactly like #972618, merging accordingly (dito #972775). Cheers Jochen signature.asc Description: PGP signature
Processed: Re: Bug#972774: ros-ros ftbfs
Processing control commands: > reassign -1 googletest Bug #972774 [src:ros-ros] ros-ros ftbfs Bug reassigned from package 'src:ros-ros' to 'googletest'. No longer marked as found in versions ros-ros/1.15.7-1. Ignoring request to alter fixed versions of bug #972774 to the same values previously set > forcemerge 972618 -1 Bug #972618 [googletest] googletest: Breaks apt build Bug #972774 [googletest] ros-ros ftbfs Added indication that 972774 affects apt Marked as found in versions googletest/1.10.0.20201018-1. Bug #972618 [googletest] googletest: Breaks apt build Added tag(s) bullseye, sid, and ftbfs. Merged 972618 972774 > reassign 972775 googletest Bug #972775 [src:ros-rospack] ros-rospack ftbfs Bug reassigned from package 'src:ros-rospack' to 'googletest'. No longer marked as found in versions ros-rospack/2.6.2-1. Ignoring request to alter fixed versions of bug #972775 to the same values previously set > forcemerge 972618 972775 Bug #972618 [googletest] googletest: Breaks apt build Bug #972774 [googletest] ros-ros ftbfs Bug #972775 [googletest] ros-rospack ftbfs Added indication that 972775 affects apt Marked as found in versions googletest/1.10.0.20201018-1. Bug #972774 [googletest] ros-ros ftbfs Merged 972618 972774 972775 > affects -1 src:ros-ros src:ros-rospack Bug #972774 [googletest] ros-ros ftbfs Bug #972618 [googletest] googletest: Breaks apt build Bug #972775 [googletest] ros-rospack ftbfs Added indication that 972774 affects src:ros-ros and src:ros-rospack Added indication that 972618 affects src:ros-ros and src:ros-rospack Added indication that 972775 affects src:ros-ros and src:ros-rospack -- 972618: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972618 972774: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972774 972775: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972775 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 11:33:41AM +0200, Julien Cristau wrote: > https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd > seems to have bumped SONAME upstream. That would fix it, yes, but it seems to have missed the kflags change (the commit says all added padding is at the end). The kflags change was made a month or so before 0.7 release: https://github.com/axboe/liburing/commit/0f0517331307605e576b3492c93dc4988e06fdc0 /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#972778: zbar ftbfs with python3.9
Package: src:zbar
Version: 0.23.1-1
Severity: serious
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.9
this looks like cython3 is not run during the build (python3-defaults from
experimental).
https://people.debian.org/~ginggs/python3.9-default/zbar_0.23.1-1build1_amd64-2020-10-23T04:27:31Z.build
[...]
python/enum.c: In function ‘enumitem_print’:
python/enum.c:84:31: error: ‘PyTypeObject’ {aka ‘struct _typeobject’}
has no member named ‘tp_print’
84 | return(self->name->ob_type->tp_print(self->name, fp, flags));
| ^~
python/enum.c: At top level:
python/enum.c:118:6: error: ‘PyTypeObject’ {aka ‘struct _typeobject’}
has no member named ‘tp_print’
118 | .tp_print = (printfunc)enumitem_print,
| ^~~~
python/enum.c:118:23: warning: initialization of ‘PyObject * (*)(PyObject *,
PyObject *)’ {aka ‘struct _object * (*)(struct _object *, struct _object
*)’} from ‘long int’ makes pointer from integer without a cast
[-Wint-conversion]
118 | .tp_print = (printfunc)enumitem_print,
| ^
python/enum.c:118:23: note: (near initialization for
‘zbarEnumItem_Type.tp_getattro’)
python/enum.c: In function ‘enumitem_print’:
python/enum.c:85:1: warning: control reaches end of non-void function
[-Wreturn-type]
85 | }
| ^
make[3]: *** [Makefile:1476: python/zbar_la-enum.lo] Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:1897: all-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:977: all] Error 2
make[1]: Leaving directory '/<>'
dh_auto_build: error: make -j16 returned exit code 2
Bug#972779: zeroc-ice ftbfs with python3.9
Package: src:zeroc-ice Version: 3.7.4-1 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 zeroc-ice ftbfs with python3.9 (python3-defaults from experimental): https://people.debian.org/~ginggs/python3.9-default/zeroc-ice_3.7.4-1build1_amd64-2020-10-23T04:32:29Z.build modules/IcePy/Init.cpp: In function ‘PyObject* PyInit_IcePy()’: modules/IcePy/Init.cpp:147:24: error: ‘void PyEval_InitThreads()’ is deprecated [-Werror=deprecated-declarations] 147 | PyEval_InitThreads(); |^ In file included from /usr/include/python3.9/Python.h:145, from modules/IcePy/Config.h:23, from modules/IcePy/BatchRequestInterceptor.h:8, from modules/IcePy/Init.cpp:5: /usr/include/python3.9/ceval.h:130:37: note: declared here 130 | Py_DEPRECATED(3.9) PyAPI_FUNC(void) PyEval_InitThreads(void); | ^~
Bug#972776: talloc ftbfs with python3.9
Package: src:talloc Version: 2.3.1-1 Severity: serious Tags: sid bullseye ftbfs talloc ftbfs with python3.9 (python3-defaults from experimental). Looks like hard-coding a specific python version. https://people.debian.org/~ginggs/python3.9-default/talloc_2.3.1-1build1_amd64-2020-10-22T15:04:42Z.build debian/rules override_dh_install make[1]: Entering directory '/<>' DEB_PY3_INCDIR=/usr/include/python3.9 \ dh_install dh_install: warning: Cannot find (any matches for) "usr/lib/*/libpytalloc-util.cpython-38-*.so.*" (tried in ., debian/tmp) dh_install: warning: python3-talloc missing files: usr/lib/*/libpytalloc-util.cpython-38-*.so.* dh_install: error: missing files, aborting
Processed: Re: Bug#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault
Processing control commands: > tags -1 confirmed Bug #970878 [src:ghostscript] ghostscript breaks doc-rfc autopkgtest: segmentation fault Added tag(s) confirmed. -- 970878: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970878 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972774: ros-ros ftbfs
Package: src:ros-ros Version: 1.15.7-1 Severity: serious Tags: sid bullseye ftbfs ros-ros ftbfs with python3.9 (python3-defaults from experimental), not yet convinced if that's related to python3.9, looks more like a googletest issue. https://people.debian.org/~ginggs/python3.9-default/ros-ros_1.15.7-1build1_amd64-2020-10-22T14:06:27Z.build [...] CMake Warning at CMakeLists.txt:43 (project): VERSION keyword not followed by a value or was followed by a value that expanded to nothing. -- The CXX compiler identification is GNU 10.2.0 -- The C compiler identification is GNU 10.2.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done CMake Warning at /usr/src/googletest/googletest/CMakeLists.txt:54 (project): VERSION keyword not followed by a value or was followed by a value that expanded to nothing. -- Found PythonInterp: /usr/bin/python3.9 (found version "3.9") -- Looking for pthread.h -- Looking for pthread.h - found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE CMake Error at /usr/src/googletest/googletest/CMakeLists.txt:129 (set_target_properties): set_target_properties called with incorrect number of arguments. CMake Error at /usr/src/googletest/googletest/CMakeLists.txt:132 (set_target_properties): set_target_properties called with incorrect number of arguments. CMake Error at CMakeLists.txt:103 (set_target_properties): set_target_properties called with incorrect number of arguments. CMake Error at CMakeLists.txt:106 (set_target_properties): set_target_properties called with incorrect number of arguments. -- Configuring incomplete, errors occurred! See also "/<>/obj-x86_64-linux-gnu/core/mk/gmock/CMakeFiles/CMakeOutput.log". See also "/<>/obj-x86_64-linux-gnu/core/mk/gmock/CMakeFiles/CMakeError.log".
Bug#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault
Control: tags -1 confirmed Quoting Iustin Pop (2020-10-23 00:02:11) > On 2020-10-10 13:34:16, Bernhard Übelacker wrote: > > Dear Maintainer, > > tried to have a look at this one, found the segfault [1], > > and can point to the place where the pointer gets overwritten [2]. > > Unfortunately Valgrind or ASAN gave me not more details. > > Thanks for this information. To me, this is clearly a bug in > ghostscript, which is just incidentally triggered by a PDF shipped by > doc-rfc. It could be just as well a PDF downloaded from the internet > :/ > > As such, I think it is correct that this is a serious bug on > ghostscript, but not in doc-rfc, so I will mark it not found in that > package. > > Of course, I'm biased since I'm the maintainer of doc-rfc, but I think > it's a fair assesment. For the record it is not a PDF file but a (quite large and allegedly) PostScript file that causes Ghostscript to segfault. I do agree that Ghostscript shouldn't segfault. I am unaware if the Postscript file is flawed, but that would be a different bug. - 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#972775: ros-rospack ftbfs
Package: src:ros-rospack Version: 2.6.2-1 Severity: serious Tags: sid bullseye ftbfs ros-rospack ftbfs with python3.9 (python3-defaults from experimental), not yet convinced if that's related to python3.9, looks more like a googletest issue. https://people.debian.org/~ginggs/python3.9-default/ros-rospack_2.6.2-2build1_amd64-2020-10-22T14:07:50Z.build [...] CMake Warning at CMakeLists.txt:43 (project): VERSION keyword not followed by a value or was followed by a value that expanded to nothing. -- The CXX compiler identification is GNU 10.2.0 -- The C compiler identification is GNU 10.2.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done CMake Warning at /usr/src/googletest/googletest/CMakeLists.txt:54 (project): VERSION keyword not followed by a value or was followed by a value that expanded to nothing. -- Found PythonInterp: /usr/bin/python3.9 (found version "3.9") -- Looking for pthread.h -- Looking for pthread.h - found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE CMake Error at /usr/src/googletest/googletest/CMakeLists.txt:129 (set_target_properties): set_target_properties called with incorrect number of arguments. CMake Error at /usr/src/googletest/googletest/CMakeLists.txt:132 (set_target_properties): set_target_properties called with incorrect number of arguments. CMake Error at CMakeLists.txt:103 (set_target_properties): set_target_properties called with incorrect number of arguments. CMake Error at CMakeLists.txt:106 (set_target_properties): set_target_properties called with incorrect number of arguments. -- Configuring incomplete, errors occurred! See also "/<>/obj-x86_64-linux-gnu/core/mk/gmock/CMakeFiles/CMakeOutput.log". See also "/<>/obj-x86_64-linux-gnu/core/mk/gmock/CMakeFiles/CMakeError.log".
Bug#972773: python-ciso8601 ftbfs with python3.9
Package: src:python-ciso8601 Version: 2.1.3-2 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 https://people.debian.org/~ginggs/python3.9-default/python-ciso8601_2.1.3-2build1_amd64-2020-10-22T13:38:30Z.build packaging error, you are mixing b-d's python3-all and python3-dev, which cannot work. to support all python3 version, b-d on python3-all-dev, if supporting a single version, b-d on python-dev. Nothing else.
Bug#972772: pybdsf ftbfs with python3.9
Package: src:pybdsf Version: 1.9.2-2 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 pybdsf ftbfs with python3.9 (python3-defaults from experimenal): https://people.debian.org/~ginggs/python3.9-default/pybdsf_1.9.2-2build1_amd64-2020-10-22T13:21:38Z.build [...] compile options: '-Ibuild/src.linux-x86_64-3.8/build/src.linux-x86_64-3.8/bdsf -I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.8 -c' x86_64-linux-gnu-gcc: build/src.linux-x86_64-3.8/build/src.linux-x86_64-3.8/bdsf/fortranobject.c x86_64-linux-gnu-gcc: build/src.linux-x86_64-3.8/bdsf/_pytesselatemodule.c In file included from build/src.linux-x86_64-3.8/build/src.linux-x86_64-3.8/bdsf/fortranobject.c:2: build/src.linux-x86_64-3.8/build/src.linux-x86_64-3.8/bdsf/fortranobject.h:7:10: fatal error: Python.h: No such file or directory 7 | #include "Python.h" | ^~ compilation terminated. build/src.linux-x86_64-3.8/bdsf/_pytesselatemodule.c:14:10: fatal error: Python.h: No such file or directory 14 | #include "Python.h" | ^~ compilation terminated. error: Command "x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Ibuild/src.linux-x86_64-3.8/build/src.linux-x86_64-3.8/bdsf -I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/python3.8 -c build/src.linux-x86_64-3.8/build/src.linux-x86_64-3.8/bdsf/fortranobject.c -o build/temp.linux-x86_64-3.8/build/src.linux-x86_64-3.8/build/src.linux-x86_64-3.8/bdsf/fortranobject.o -MMD -MF build/temp.linux-x86_64-3.8/build/src.linux-x86_64-3.8/build/src.linux-x86_64-3.8/bdsf/fortranobject.o.d" failed with exit status 1
Bug#972771: openstructure ftbfs with python3.9
Package: src:openstructure Version: 2.1.0-1 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 openstructure ftbfs with python3.9 (python3-defaults from experimental), looks like it still looks for 3.8 https://people.debian.org/~ginggs/python3.9-default/openstructure_2.1.0-1build1_amd64-2020-10-23T01:33:06Z.build [...] This warning is for project developers. Use -Wno-dev to suppress it. -- Found SQLITE3: /usr/lib/x86_64-linux-gnu/libsqlite3.so -- Found FFTW: /usr/lib/x86_64-linux-gnu/libfftw3f.so -- Found TIFF: /usr/lib/x86_64-linux-gnu/libtiff.so (found version "4.1.0") -- Searching for python module PyQt5 for /usr/bin/python3.8 -- Found python module PyQt5 -- Searching for python module PyQt5.sip for /usr/bin/python3.8 -- Found python module PyQt5.sip
Bug#972769: libsigrokdecode ftbfs with python3.9
Package: src:libsigrokdecode Version: 0.5.3-1 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 libsigrokdecode ftbfs with python3.9 (python3-defaults from experimental): https://people.debian.org/~ginggs/python3.9-default/libsigrokdecode_0.5.3-1build1_amd64-2020-10-21T11:58:04Z.build [...] libtool: link: gcc -std=c99 -fvisibility=hidden -Wall -Wextra -Wmissing-prototypes -Wshadow -Wformat=2 -Wno-format-nonliteral -Wfloat-equal -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/python3.9 -I/usr/include/x86_64-linux-gnu/python3.9 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro -Wl,--as-needed -o tests/.libs/main tests/main-main.o tests/main-core.o tests/main-decoder.o tests/main-inst.o tests/main-session.o -pthread ./.libs/libsigrokdecode.so -lcheck_pic -lrt -lm -lsubunit -lglib-2.0 -pthread /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyList_Insert' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyModule_AddObject' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PySys_GetObject' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyDict_SetItemString' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyType_GenericNew' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyImport_Import' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyList_GetItem' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyBytes_AsStringAndSize' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyObject_CallMethod' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyGILState_Release' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyBytes_Size' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyBool_FromLong' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyUnicode_FromString' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyObject_CallFunctionObjArgs' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyExc_TypeError' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `Py_InitializeEx' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyExc_Exception' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyObject_Str' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyDict_Next' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyLong_AsLong' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyModule_AddIntConstant' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyErr_Format' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyFloat_FromDouble' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyArg_ParseTuple' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyErr_Occurred' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PySet_Pop' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyObject_IsSubclass' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyArg_ParseTupleAndKeywords' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyFloat_Type' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyExc_IndexError' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyEval_InitThreads' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `_Py_FalseStruct' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyEval_RestoreThread' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyBytes_AsString' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyType_FromSpec' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `_Py_TrueStruct' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyEval_SaveThread' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyDict_Size' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PySequence_GetItem' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyDict_GetItem' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PySequence_Size' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyList_Size' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyType_IsSubtype' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `Py_DecRef' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyGILState_Ensure' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyErr_NormalizeException' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyObject_CallObject' /usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyType_GetFlags' /usr/bin/ld: ./.libs/libsigrokde
Bug#972768: kissplice ftpfs with python3.9
Package: src:kissplice Version: 2.5.3-2 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 Not sure if that's python 3.9 specific (python3-defaults from experimental was used). this ends up with a link error: https://people.debian.org/~ginggs/python3.9-default/kissplice_2.5.3-2build1_amd64-2020-10-21T09:34:38Z.build usr/bin/ld: CMakeFiles/ks_kissreadsSplice.dir/tree.c.o:./obj-x86_64-linux-gnu/thirdparty/kissreads/src/./thirdparty/kissreads/include/commons.h:56: multiple definition of `quality'; CMakeFiles/ks_kissreadsSplice.dir/commons.c.o:./obj-x86_64-linux-gnu/thirdparty/kissreads/src/./thirdparty/kissreads/include/commons.h:56: first defined here /usr/bin/ld: CMakeFiles/ks_kissreadsSplice.dir/tree.c.o:./obj-x86_64-linux-gnu/thirdparty/kissreads/src/./thirdparty/kissreads/include/commons.h:55: multiple definition of `silent'; CMakeFiles/ks_kissreadsSplice.dir/commons.c.o:./obj-x86_64-linux-gnu/thirdparty/kissreads/src/./thirdparty/kissreads/include/commons.h:55: first defined here /usr/bin/ld: CMakeFiles/ks_kissreadsSplice.dir/tree.c.o:./obj-x86_64-linux-gnu/thirdparty/kissreads/src/./thirdparty/kissreads/include/commons.h:54: multiple definition of `standard_fasta'; CMakeFiles/ks_kissreadsSplice.dir/commons.c.o:./obj-x86_64-linux-gnu/thirdparty/kissreads/src/./thirdparty/kissreads/include/commons.h:54: first defined here /usr/bin/ld: CMakeFiles/ks_kissreadsSplice.dir/tree.c.o:./obj-x86_64-linux-gnu/thirdparty/kissreads/src/./thirdparty/kissreads/include/commons.h:53: multiple definition of `nuc'; CMakeFiles/ks_kissreadsSplice.dir/commons.c.o:./obj-x86_64-linux-gnu/thirdparty/kissreads/src/./thirdparty/kissreads/include/commons.h:53: first defined here /usr/bin/ldcd /<>/obj-x86_64-linux-gnu/modules && /usr/bin/c++ -I/<>/modules -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-unused-result -Wno-parentheses -Wno-error=format-security -std=c++11 -o CMakeFiles/ks_clean_duplicates.dir/LabelledCEdge.cpp.o -c /<>/modules/LabelledCEdge.cpp : CMakeFiles/ks_kissreadsSplice.dir/tree.c.o:./obj-x86_64-linux-gnu/thirdparty/kissreads/src/./thirdparty/kissreads/include/commons.h:52: multiple definition of `comp'; CMakeFiles/ks_kissreadsSplice.dir/commons.c.o:./obj-x86_64-linux-gnu/thirdparty/kissreads/src/./thirdparty/kissreads/include/commons.h:52: first defined here collect2: error: ld returned 1 exit status make[3]: *** [thirdparty/kissreads/src/CMakeFiles/ks_kissreadsSplice.dir/build.make:257: lib/kissplice/ks_kissreadsSplice] Error 1 make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
Bug#972767: frr ftbfs with python3.9
Package: src:frr Version: 7.4-1 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 frr ftbfs with python3.9 (python3-defaults from experimental) https://people.debian.org/~ginggs/python3.9-default/frr_7.4-1build1_amd64-2020-10-21T08:19:46Z.build [...] checking python interpreter python3... /usr/bin/python3 (python3) checking whether /usr/bin/python3.9-config is available... yes checking whether /usr/bin/python3.9-config provides a working build environment... no checking whether pkg-config python-3.9 is available... yes checking whether pkg-config python-3.9 provides a working build environment... no checking whether /usr/bin/python3.9-config is available... yes checking whether /usr/bin/python3.9-config provides a working build environment... no checking whether pkg-config python-3.9 is available... yes checking whether pkg-config python-3.9 provides a working build environment... no configure: error: PYTHON (/usr/bin/python3) explicitly specified but development environment not working tail -v -n \+0 config.log
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 10:47:57AM +0200, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 09:55:36AM +0200, Steinar H. Gunderson wrote: > > If this were somehow only about newer functionality or critical fixes, it > > could > > be fixed by bumping the versioned dependency, but rhis goes both ways; if > > you > > build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1, > > you get a similar crash. So it would seem there's hidden ABI breakage here > > that > > needs a soname bump. > > It seems there's a new “unsigned *kflags;” added in the middle of > struct io_uring_cq that would explain this. > https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd seems to have bumped SONAME upstream. Cheers, Julien
Processed: found 972730 in 1.1.0-2, tagging 972730
Processing commands for cont...@bugs.debian.org: > found 972730 1.1.0-2 Bug #972730 [src:python-mpd] python-mpd: autopkgtest fails when two python3 versions are supported Marked as found in versions python-mpd/1.1.0-2. > tags 972730 + bullseye sid Bug #972730 [src:python-mpd] python-mpd: autopkgtest fails when two python3 versions are supported Added tag(s) sid and bullseye. > thanks Stopping processing here. Please contact me if you need assistance. -- 972730: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972730 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972765: fontforge ftbfs with python3.9
Package: src:fontforge Version: 1:20190801~dfsg-5 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 fontforge ftbfs with python3.9 (python3-defaults from experimental). There seem to be two issues, 3.8 is used instead of 3.9, and d-shlibs isn't aware of 3.9. https://people.debian.org/~ginggs/python3.9-default/fontforge_20190801~dfsg-5build1_amd64-2020-10-22T22:02:36Z.build [...] dh_install --package=fontforge-nox --sourcedir=debian/tmp/nox dh_install --no-package=fontforge-nox --sourcedir=debian/tmp/x d-shlibmove --commit \ --devunversioned \ --exclude-la \ --extralib debian/tmp/x/usr/lib/libgunicode.so \ --extralib debian/tmp/x/usr/lib/libgutils.so \ --movedev "debian/tmp/x/usr/include/*" usr/include/ \ --movedev "debian/tmp/x/usr/lib/pkgconfig/*.pc" usr/lib/x86_64-linux-gnu/pkgconfig \ --override s/libfontforge3-dev/libfontforge-dev/ \ --override s/libpython3.8-1.0-dev/libpython3.8-dev/ \ debian/tmp/x/usr/lib/libfontforge.so Library package automatic movement utility --> libfontforge-dev package from same source package. --> libfreetype6-dev package exists. --> libgif-dev package exists. --> libglib2.0-dev package exists. --> libjpeg-dev package exists. --> libpng-dev package exists. devlibs error: There is no package matching [libpython3.9-1.0-dev] and noone provides it, please report bug to d-shlibs maintainer --> libreadline-dev package exists. --> libspiro-dev package exists. --> libtiff5-dev package exists. --> libuninameslist-dev package exists. --> libxml2-dev package exists. --> zlib1g-dev package exists. make[1]: *** [debian/rules:53: override_dh_install] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:72: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Bug#972764: cantor ftbfs with python3.9
Package: src:cantor Version: 20.04.3-1 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 cantor ftbfs with python3.9 (python3-defaults from experimental): https://people.debian.org/~ginggs/python3.9-default/cantor_20.04.3-1build1_amd64-2020-10-22T21:44:32Z.build [...] make[1]: Leaving directory '/<>' dh_install dh_install: warning: Cannot find (any matches for) "etc/xdg/cantor_python.knsrc" (tried in ., debian/tmp) dh_install: warning: cantor-backend-python3 missing files: etc/xdg/cantor_python.knsrc dh_install: warning: Cannot find (any matches for) "usr/bin/cantor_pythonserver" (tried in ., debian/tmp) dh_install: warning: cantor-backend-python3 missing files: usr/bin/cantor_pythonserver dh_install: warning: Cannot find (any matches for) "usr/lib/*/cantor_pythonbackend.so" (tried in ., debian/tmp) dh_install: warning: cantor-backend-python3 missing files: usr/lib/*/cantor_pythonbackend.so dh_install: warning: Cannot find (any matches for) "usr/lib/*/qt5/plugins/cantor/backends/cantor_pythonbackend.so" (tried in ., debian/tmp) dh_install: warning: cantor-backend-python3 missing files: usr/lib/*/qt5/plugins/cantor/backends/cantor_pythonbackend.so dh_install: warning: Cannot find (any matches for) "usr/share/config.kcfg/pythonbackend.kcfg" (tried in ., debian/tmp) dh_install: warning: cantor-backend-python3 missing files: usr/share/config.kcfg/pythonbackend.kcfg dh_install: error: missing files, aborting make: *** [debian/rules:9: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Bug#972763: bup ftbfs with python3.9
Package: src:bup Version: 0.31-1 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 https://people.debian.org/~ginggs/python3.9-default/bup_0.31-1build1_amd64-2020-10-21T07:33:31Z.build bup ftbfs with python3.9 (python3-defaults from experimental): [...] creating build/temp.linux-x86_64-3.9 x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -D_FILE_OFFSET_BITS=64 -Wall -O2 -Wno-unknown-pragmas -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.9 -c _helpers.c -o build/temp.linux-x86_64-3.9/_helpers.o -D_FILE_OFFSET_BITS=64 -Wall -O2 -Wno-unknown-pragmas -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security _helpers.c:359:13: error: conflicting types for ‘Py_GetArgcArgv’ 359 | extern void Py_GetArgcArgv(int *argc, char ***argv); | ^~ In file included from /usr/include/python3.9/cpython/pystate.h:9, from /usr/include/python3.9/pystate.h:143, from /usr/include/python3.9/genobject.h:11, from /usr/include/python3.9/Python.h:123, from _helpers.c:8: /usr/include/python3.9/cpython/initconfig.h:456:18: note: previous declaration of ‘Py_GetArgcArgv’ was here 456 | PyAPI_FUNC(void) Py_GetArgcArgv(int *argc, wchar_t ***argv); | ^~ error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1 make[2]: *** [Makefile:152: lib/bup/_helpers.so] Error 1
Bug#972762: bornagain doesn't correctly detects python3.9
Package: src:bornagain Version: 1.16.0-1 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.9 bornagain ftbfs with python3-defaults from experimental, ending up with a mix of 3.8 and 3.9. https://people.debian.org/~ginggs/python3.9-default/bornagain_1.16.0-1build1_amd64-2020-10-21T07:22:49Z.build [...] -- Found Doxygen: /usr/bin/doxygen (found version "1.8.20") found components: doxygen missing components: dot -- Requested Python versions 3.8;3.7;3.6;3.5;3.4;3.3 -- Found PythonInterp: /usr/bin/python3.8 (found version "3.8.6") -- Found Python interpreter version 3.8.6 at /usr/bin/python3.8 -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.9.so (found version "3.9.0+") -- Found Python libraries version 3.9.0+ at /usr/lib/x86_64-linux-gnu/libpython3.9.so; includes at /usr/include/python3.9 -- BORNAGAIN_USE_PYTHON3: ON. -- --> Validating Python installation corresponding to the interpreter /usr/bin/python3.8 -- > ALT_PYTHON_PREFIX:/usr -- > ALT_PYTHON_INCLUDE_DIRS:/usr/include/python3.8 -- > ALT_PYTHON_SITE_PACKAGES:/usr/lib/python3/dist-packages -- > ALT_PYTHON_MODULE_EXTENSION:.cpython-38-x86_64-linux-gnu.so -- > ALT_PYTHON_IS_DEBUG:0 -- > ALT_PYTHON_SIZEOF_VOID_P:8 -- > ALT_PYTHON_LIBRARY_SUFFIX:3.8 -- > Python interpreter reports include directory (see ALT_PYTHON_INCLUDE_DIRS) which differs from what we have learned before (see PYTHON_INCLUDE_DIRS). -- > Setting PYTHON_INCLUDE_DIRS=/usr/include/python3.8 -- ---> PYTHON_VERSION_STRING 3.8.6 differs from PYTHONLIBS_VERSION_STRING 3.9.0+ -- ---> There is inconcistency between versions of interpreter and library. -- --> Python seems to be OK. [...]
Processed: Re: Bug#972730: python-mpd: autopkgtest fails when two python3 versions are supported
Processing control commands: > severity -1 serious Bug #972730 [src:python-mpd] python-mpd: merge changes from accidental NMU Severity set to 'serious' from 'normal' > retitle -1 python-mpd: autopkgtest fails when two python3 versions are > supported Bug #972730 [src:python-mpd] python-mpd: merge changes from accidental NMU Changed Bug title to 'python-mpd: autopkgtest fails when two python3 versions are supported' from 'python-mpd: merge changes from accidental NMU'. > tags -1 + patch pending Bug #972730 [src:python-mpd] python-mpd: autopkgtest fails when two python3 versions are supported Added tag(s) pending and patch. -- 972730: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972730 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 09:55:36AM +0200, Steinar H. Gunderson wrote: > If this were somehow only about newer functionality or critical fixes, it > could > be fixed by bumping the versioned dependency, but rhis goes both ways; if you > build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1, > you get a similar crash. So it would seem there's hidden ABI breakage here > that > needs a soname bump. It seems there's a new “unsigned *kflags;” added in the middle of struct io_uring_cq that would explain this. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#972758: ABI breakage without soname bump
Package: liburing1 Version: 0.7-1 Severity: grave Tags: upstream Hi, I've had a number of reports from people who are having problems with plocate, that can be traced to differing versions of liburing1. Specifically, plocate is built in sid against liburing1 0.7-1 (which gets a versioned dependency only on liburing1 >= 0.4), but if people instead have liburing1 0.6-3 on their systems, they crash: kos:~> plocate plocate md5sums /home/sesse/nmu/plocate-1.0.2/debian/.debhelper/plocate/dbgsym-root/DEBIAN/md5sums /home/sesse/nmu/plocate-1.0.2/debian/plocate/DEBIAN/md5sums /var/lib/dpkg/info/plocate-dbgsym.md5sums /var/lib/dpkg/info/plocate.md5sums kos:~> sudo dpkg -i liburing1_0.6-3_amd64.deb [...] kos:~> plocate plocate md5sums zsh: segmentation fault plocate plocate md5sums If this were somehow only about newer functionality or critical fixes, it could be fixed by bumping the versioned dependency, but rhis goes both ways; if you build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1, you get a similar crash. So it would seem there's hidden ABI breakage here that needs a soname bump. /* Steinar */
Bug#972749: xen-tools: bullseye: /updates -> -security
Hi Paul, Paul Wise wrote: > On Fri, 2020-10-23 at 08:05 +0200, Axel Beckert wrote: > > Ack. Just have to think how I make that separation properly. Either by > > listing all supported previous release names (or maybe just those not > > yet archived) and defaulting to the new scheme to be comaptible with > > all future releases. > > That sounds OK to me. Dropping the unsupported releases seems > appropriate, That's not what I meant! I meant that I probably not have to list releases no more supported by Debian as the "eol" flag in etc/distributions.conf already implies that I don't have to care about security updates anymore. > unless xen-tools also supports using archive.debian.org for those > releases, Of course it does! Back to Sarge and Dapper you can install any Debian and Ubuntu release in a Xen DomU. That's really helpful if you want to do software archaeology on living subjects and not just in a chroot, like checking if some kernel coped with some other thing or so. > > I'd rather avoid this seemingly debian-specific dependency (c.f. > > https://salsa.debian.org/debian/distro-info/-/blob/master/debian/copyright > > and the native package version number) as xen-tools should also be > > usable on other distributions. > > distro-info is in a few distros, similar ones to xen-tools: Thanks for checking. I though wonder why it has a native package version number in Debian then. Will think about it, but it's not likely that I'll do that soon. xen-tools is more or less in maintenance mode as I only use it seldomly myself anymore after changing jobs. (I used it a lot on my previous job which is one of the reasons why I adopted it about 10 years ago.) > > I disagree since distro-info is debian-only and that's a clear no-go. > > Also these numbers won't change in the future once they're released, > > so hardcoding won't do any harm. > > The issue with hardcoding is the maintenance cost of having to remember > to add the new versions for every release. I have to do that anyway, so I currently see no point in adding that dependency, unless I a) revamp the whole tool, e.g. automating the list of distro symlinks in Makefile (or rewriting the whole toolset so that it fetches the information live while running on the Xen host system), but both still needs to know which distribution release are the same in terms of set of scripts: https://github.com/xen-tools/xen-tools/blob/master/Makefile#L178-L231 And b) all the information currently in etc/distributions.conf would have to be in distro-info — including which distributions are testable and which distributions are equivalent with regards to the set of scripts. (See above.) I doubt that this will actually work out. I may then have to maintain it in less places, but I'll still have to maintain this data set _and_ check that my dependency has that data, too. > > > It might even be a good idea to include the security > > > suite information in distro-info itself and look it up there. > > FTR I filed #972750 about this idea. Thanks, subscribed to it. > > I'd rather add it to xen-tools' etc/distribution.conf which basically > > tracks the needed setting changes per release: > > https://github.com/xen-tools/xen-tools/blob/master/etc/distributions.conf > > I think it is better to have these sort of things in one central place > rather copies in every script that needs the information. While I generally agree, I'm not sure if you are aware that there's some quite xen-tools specific facts in there like e.g. which distributions are supported at all and which distributions shouldn't be run in the test suite. I'd rather have all those information in one place than split over my repo and some other tools. That information about which GPG keyring to use is probably not in distro-info either. Anyway, looking at /usr/share/distro-info/*.csv there's indeed some quite useful data in there, like the EoL dates. I think I might have some use for that in another project of mine. But then again, ubuntu.csv misses the ESM dates and debian.csv misses the LTS/ELTS dates despite the latter is an open bug report since 2015 (https://bugs.debian.org/782685 — Hey, this bug report was even filed by myself! *sigh*) and marked as pending for more than a year despite there were two uploads of each, distro-info and distro-info-data since then. So I think I can say that I'm not too happy with the amount of information being in there and also have some doubt that more columns are actually added anytime soon. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers
Control: found -1 3.20.5+dfsg0-3 Control: tags -1 +bullseye +upstream Le vendredi, 16 octobre 2020, 14.23:59 h CEST Didier 'OdyX' Raboud a écrit : > According to the 3.20.9-3 armhf auutopkgtest run for migration testing; > https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.gz > > hpcups sometimes crashes with free(): invalid pointer. For instance, it > seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd' > printer will let hpcups crash. > > I'd welcome assistance here as I'm no C gdb fluent person. So. This bug can be reproduced by the following suite of commands on armhf: $ export PPD=./prnt/hp-officejet_pro_1150c.ppd.gz $ /usr/lib/cups/filter/pdftopdf 1 debian '' 1 '' print_step_1.pdf $ /usr/lib/cups/filter/gstoraster 1 debian '' 1 '' print_step_2.raster $ /usr/lib/cups/filter/hpcups 1 debian '' 1 '' print_step_3.hpcups As I have confirmed that this is also _already_ a bug in the current bullseye version, I'll mark this RC bug as affecting the corresponding versions, and I'll upload a version without the autopkgtest to unstable, to let this version migrate. As this is testable at build-time, I'll add a test for this and upload this to experimental. I'll report this to upstream today. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Processed: Re: Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers
Processing control commands: > found -1 3.20.5+dfsg0-3 Bug #972339 [printer-driver-hpcups] armhf: hpcups crashes with free() invalid pointer for some printers Marked as found in versions hplip/3.20.5+dfsg0-3. > tags -1 +bullseye +upstream Bug #972339 [printer-driver-hpcups] armhf: hpcups crashes with free() invalid pointer for some printers Added tag(s) bullseye. Bug #972339 [printer-driver-hpcups] armhf: hpcups crashes with free() invalid pointer for some printers Ignoring request to alter tags of bug #972339 to the same tags previously set -- 972339: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972339 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#972749: xen-tools: bullseye: /updates -> -security
On Fri, 2020-10-23 at 08:05 +0200, Axel Beckert wrote: > Ack. Just have to think how I make that separation properly. Either by > listing all supported previous release names (or maybe just those not > yet archived) and defaulting to the new scheme to be comaptible with > all future releases. That sounds OK to me. Dropping the unsupported releases seems appropriate, unless xen-tools also supports using archive.debian.org for those releases, in that case you should keep all old releases. > I'd rather avoid this seemingly debian-specific dependency (c.f. > https://salsa.debian.org/debian/distro-info/-/blob/master/debian/copyright > and the native package version number) as xen-tools should also be > usable on other distributions. distro-info is in a few distros, similar ones to xen-tools: https://repology.org/project/distro-info/versions https://repology.org/project/xen-tools/versions > I disagree since distro-info is debian-only and that's a clear no-go. > Also these numbers won't change in the future once they're released, > so hardcoding won't do any harm. The issue with hardcoding is the maintenance cost of having to remember to add the new versions for every release. > > It might even be a good idea to include the security > > suite information in distro-info itself and look it up there. FTR I filed #972750 about this idea. > I'd rather add it to xen-tools' etc/distribution.conf which basically > tracks the needed setting changes per release: > https://github.com/xen-tools/xen-tools/blob/master/etc/distributions.conf I think it is better to have these sort of things in one central place rather copies in every script that needs the information. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
