Bug#999376: marked as done (python-gmpy2 ftbfs with Python 3.10)
On 11/19/21 1:45 PM, Debian Bug Tracking System wrote: Your message dated Fri, 19 Nov 2021 21:40:53 + with message-id and subject line Bug#999376: fixed in python-gmpy2 2.1.0~b5-1 has caused the Debian Bug report #999376, regarding python-gmpy2 ftbfs with Python 3.10 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.) Sorry, I was in an arm sling after shoulder surgery and unable to easily type on my home computer, so I hadn't gotten a chance to update this yet. I was about to do so and see you beat me to it. Thank you!
Bug#988462: A little more info please?
On 2021-11-09 19:26, Chris Carr wrote: > - please could you explain why it is not suitable for inclusion in > bullseye? What is it that I am not seeing or experiencing in my daily > use of it? Problem is, that Trac (up to version 1.4) used to be a Python 2 program. Python 2 is not supported anymore (or only in a very limited way), so many dependencies for Trac are removed from Debian. It was impossible to keep Trac with Python 2 in Debian. Now Trac (>= 1.5) is based on Python 3, but the new code is not yet considered stable by upstream. I hoped, that there were a Trac release 1.6 just in time for Debian 11, e.g. around 2021-01, but Trac development happens a little bit slower even than Debians. > Also, please could you recommend an alternative ticket management > package that is included in bullseye. Preferably one that will import > my trac db so I don't have to re-enter 11 years of history. If Trac works fine for you (it does for me!), just stay with Debian 10, e.g. in a systemd-nspawn or docker container. That's what we do in my company: We run a server with Debian 11 and a systemd-nspawn container of Debian 10 with Trac and PostgreSQL on it. As soon as Trac 1.6 is released, I'll try to get it into Debian, as well as some of the plugins, and hopefully it will be part of Debian 12. Cheers
Bug#617856: New version of apt-show-versions fixes 617856
My version was just accepted. Am 26.10.21 um 03:51 schrieb Paul Wise: > On Mon, 2021-10-25 at 13:00 +0200, Christoph Martin wrote: > >> I will try to upload a new release. I could not do so in the last >> weeks, because my signature-key had expired and the new one did not yet >> make it into the keyring. > > You could upload to mentors.debian.net and file an RFS request: > > https://mentors.debian.net/sponsors/rfs-howto/ > OpenPGP_signature Description: OpenPGP digital signature
Bug#617856: New version of apt-show-versions fixes 617856
Hi Paul, I will try to upload a new release. I could not do so in the last weeks, because my signature-key had expired and the new one did not yet make it into the keyring. Greeting Christoph Am 20.10.21 um 07:09 schrieb Paul Wise: > On Fri, 8 Oct 2021 11:31:39 +0200 Christoph Martin wrote: > >> tags 617856 + pending >> thanks >> >> Upload of new version is pending. > > Could you upload the package? > OpenPGP_signature Description: OpenPGP digital signature
Bug#997201: fio: FTBFS: crc/../os/os-linux.h:17:10: fatal error: linux/raw.h: No such file or directory
Hello Lucas, hello everyone. Am Samstag, dem 23.10.2021 um 21:11 +0200 schrieb Lucas Nussbaum: > Source: fio > Version: 3.25-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs […] > During a rebuild of all packages in sid, your package failed to build > on amd64. I currently do not have much time at hand to attend to this. Feel free to NMU. Thanks, Martin Steigerwald • Proact Deutschland GmbH Trainer Telefon: +49 911 30999 0 • www.proact.de Südwestpark 43 • 90449 Nürnberg • Germany Amtsgericht Nürnberg • HRB 18320 Geschäftsführer: René Schülein • Jonas Hasselberg • Linda Höljö #ThePowerOfData | #ThePowerOfTogether This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Please read more in Proacts’ privacy notice,
Bug#994951: rar: NMU 5.5.0-1.1
Had a quick look, and looks good to me. Re: comment about unrar - there is unrar and unrar-nonfree packages using the alternatives mechanism already, so this could be provided as an alternative, but I doubt it’s worthwhile > On 13 Oct 2021, at 18:36, Bastian Germann wrote: > > I am going to upload a new revision (debdiff enclosed). > The maintainer is on LowThresholdNmu. diff -Nru rar-5.5.0/debian/changelog rar-5.5.0/debian/changelog --- rar-5.5.0/debian/changelog 2017-08-29 12:10:31.0 +0200 +++ rar-5.5.0/debian/changelog 2021-10-13 18:51:43.0 +0200 @@ -1,3 +1,15 @@ +rar (2:5.5.0-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * DEP-5 copyright file with licenses fixed (Closes: #994951) + * Package unrar again for distribution permission compliance (Closes: #994956) + * Exclude txt files from compression so they are untouched + * Update Debian's manpage (Closes: #995001) + * Remove autobuild tag (Closes: #862028) + * d/watch: Make the package a MUT (download both origtars) + + -- Bastian Germann Wed, 13 Oct 2021 18:51:43 +0200 + rar (2:5.5.0-1) unstable; urgency=medium * New upstream release diff -Nru rar-5.5.0/debian/control rar-5.5.0/debian/control --- rar-5.5.0/debian/control2017-05-04 04:52:05.0 +0200 +++ rar-5.5.0/debian/control2021-10-13 18:41:25.0 +0200 @@ -4,8 +4,7 @@ Maintainer: Martin Meredith Build-Depends: debhelper (>= 9) Standards-Version: 3.9.8 -Homepage: http://www.rarlabs.com/ -XS-Autobuild: yes +Homepage: https://www.rarlabs.com/ Package: rar Architecture: i386 amd64 diff -Nru rar-5.5.0/debian/copyright rar-5.5.0/debian/copyright --- rar-5.5.0/debian/copyright 2017-05-04 04:52:05.0 +0200 +++ rar-5.5.0/debian/copyright 2021-10-13 18:51:43.0 +0200 @@ -1,150 +1,202 @@ -This package was debianized by Petr Cech on -Sat, 16 May 1998 11:35:01 +0200. -Changes to Debian Package made by Martin Meredith - -This package is Auto-Buildable - -It was downloaded from http://www.rarlab.com/rar/ - +Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ +Comment: This package was debianized by Petr Cech on + Sat, 16 May 1998 11:35:01 +0200. + Changes to Debian Package made by Martin Meredith +Upstream-Name: rar +Upstream-Contact: https://www.win-rar.com/contact.html +Source: http://www.rarlab.com/download.htm + +Files: * +Copyright: Copyright (c) 1993-2017 Alexander Roshal +Comment: This software is shareware. +License: RAR-EULA + +Files: + *default.sfx + *rar Copyright: -Copyright (c) 1993-2006 Alexander Roshal - -This software is shareware. - - The RAR Archiver - EULA (End User License Agreement) for use and distribution - - - The RAR archiver is distributed as try before you buy. This means: - - 1. All copyrights to RAR are exclusively owned by the author - - Alexander Roshal. - - 2. Anyone may use this software during a test period of 40 days. - Following this test period of 40 days or less, if you wish to - continue to use RAR, you must purchase a license. - - 3. There are 2 basic types of licenses issued for RAR, these are: - - a. A single computer usage license. The user purchases one license - to use RAR archiver on one computer. - - Home users may use their single computer usage license on - all computers which are in property of the license owner. - - Business users require one license per computer RAR is - installed on. - - b. A multiple usage license. The user purchases a number of usage - licenses for use, by the purchaser or the purchaser's employees - on the same number of computers. - - In a network (server/client) environment you must purchase - a license copy for each separate client (workstation) - on which RAR is installed, used, or accessed. A separate - license copy for each client (workstation) is needed regardless - of whether the clients (workstations) will use RAR simultaneously - or at different times. If for example you wish to have - 9 different clients (workstations) in your network with access - to RAR, you must purchase 9 license copies. - - A user who purchased a RAR license, is granted a non-exclusive - right to use RAR on as many computers as defined by the licensing - terms above according to the number of licenses purchased, - for any legal purpose. The licensed RAR software may not be rented - or leased, but may be permanently transferred, in it's entirety, - if the person receiving it agrees to the terms of this license. - If the software is an update, the transfer must include the update - and all previous versions. - - 4. Licensing for RAR on mobile devices (U3 stick, USB stick, - external harddrive): - - In addition to the terms stated above following licensing terms - apply t
Bug#995410: breezy: FTBFS:
Hey debian bugs, On Sat, 2 Oct 2021 at 21:11, Jelmer Vernooij wrote: > > I've seen one earlier reference to this error - I think it had to do > with a regression introduced by a new version of Python. > > Cc'ing Martin, who has more background on the plugin code. Presuming this is Python 3.9 in some form? There were importlib changes there that perhaps break the machinery we use to test the plugins code - which includes creating new module objects, sticking them in sys.path and also writing little bits of python to disk and expecting import to pick them up. Nothing from the traceback seems wrong or unreasonable. Alternatively it may just be the tempdir stuff falling over under the debian test isolation in some form. No obvious fix without looking deeper I'm afraid! Martin
Bug#995672: cockpit-machines: 253-1 fails to build via apt-src
Control: severity -1 normal
Control: tag -1 unreproducible moreinfo
Hello Friedemann,
Friedemann Schorer [2021-10-03 23:40 +0200]:
> Severity: serious
That feels inflated to me. The package builds fine in official buildds [1], in
upstream CI (which uses pbuilder) and locally in a debian-sid container, and it
is really quite harmless -- the build is more or less "install a bunch of
files". Also, the error message below doesn't even get to the point where it
even attempts to build c-machines, it seems to fail early in apt-src's
name-to-location mapping? So that's certainly not a regression compared to the
testing version.
[1] https://buildd.debian.org/status/package.php?p=cockpit-machines
> Got the latest source packages for cockpit-machines 253-1, unpacked them
> locally via 'dpkg-source -x', made the source known to apt-src ('apt-src
> import cockpit-machines --location cockpit-machines-253') and tried to
> build it.
> Here's the output:
>
> ~/build: apt-src list
>
> i cockpit-machin 253-1 /home/frschorer/build/cockpit-machines-253
>
> ~/build: apt-src build cockpit-machines
>
> E: Not installed
>
> When I import the sourcetree of cockpit 254-1 from unstable sources,
> too, and then try to build cockpit-machines apt-src builds the other cockpit
> packages instead.
I never used apt-src, so I'm trying to reproduce this:
sudo apt install -y apt-src
cd /tmp
apt-get source cockpit-machines
apt-src import cockpit-machines --location cockpit-machines-253/
apt-src build cockpit-machines
the latter works:
> dpkg-buildpackage: info: source package cockpit-machines
> dpkg-buildpackage: info: source version 253-1
> [...]
> dpkg-deb: building package 'cockpit-machines' in
> '../cockpit-machines_253-1_all.deb'.
> dpkg-buildpackage: info: binary-only upload (no source included)
> I: Successfully built in /tmp/cockpit-machines-253
Do these exact commands work for you? What did you do differently? How does your
~/.apt-src/status file look like? If you move it away, or try this as a
different user, what result do you get?
Thanks,
Martin
Bug#993162: libc6: i386 (Geode LX): latest push to Bookwork produces multiple sig ILL
la 28. elok. 2021 klo 13.43 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > la 28. elok. 2021 klo 13.40 Aurelien Jarno (aurel...@aurel32.net) kirjoitti: > > > > On 2021-08-28 13:36, Martin-Éric Racine wrote: > > > la 28. elok. 2021 klo 12.58 Aurelien Jarno (aurel...@aurel32.net) > > > kirjoitti: > > > > > $ sudo coredumpctl debug 1011 > > > > >PID: 1011 (apt-get) > > > > >UID: 0 (root) > > > > >GID: 0 (root) > > > > > Signal: 4 (ILL) > > > > > Timestamp: Sat 2021-08-28 11:00:34 EEST (3min 22s ago) > > > > > Command Line: apt-get --quiet --quiet update > > > > > Executable: /usr/bin/apt-get > > > > > Control Group: /user.slice/user-1000.slice/session-4.scope > > > > > Unit: session-4.scope > > > > > Slice: user-1000.slice > > > > >Session: 4 > > > > > Owner UID: 1000 (perkelix) > > > > >Boot ID: 77dfa6eb16584c02b84de4e2b8feb781 > > > > > Machine ID: 1063a9d1fb9df6e371ea9f94491345ed > > > > > Hostname: geode > > > > >Storage: > > > > > /var/lib/systemd/coredump/core.apt-get.0.77dfa6eb16584c02b84de4e2b8feb781.1011.163013763400.zst > > > > >Message: Process 1011 (apt-get) of user 0 dumped core. > > > > > > > > > > Stack trace of thread 1011: > > > > > #0 0xb7ad2ed0 __cpu_indicator_init > > > > > (libgcc_s.so.1 + 0x2ed0) > > > > > #1 0xb7faf02c call_init (ld-linux.so.2 + > > > > > 0x1102c) > > > > > #2 0xb7faf132 call_init (ld-linux.so.2 + > > > > > 0x11132) > > > > > #3 0xb7f9f0fa _dl_start_user (ld-linux.so.2 > > > > > + 0x10fa) > > > > > > > > The SIGILL happens in __cpu_indicator_init which is provided by > > > > libgcc-s1. Bookworm got a new upstream version of this package compared > > > > to bullseye, so if you also upgraded it, it's more likely to be the > > > > issue. In that case, have you tried to downgrade it? > > > > > > Just did. Here's the result: > > > > > > $ sudo coredumpctl debug 2083 > > >PID: 2083 (apt-get) > > >UID: 0 (root) > > >GID: 0 (root) > > > Signal: 4 (ILL) > > > Timestamp: Sat 2021-08-28 13:33:05 EEST (1min 36s ago) > > > Command Line: apt-get update > > > Executable: /usr/bin/apt-get > > > Control Group: /user.slice/user-1000.slice/session-2.scope > > > Unit: session-2.scope > > > Slice: user-1000.slice > > >Session: 2 > > > Owner UID: 1000 (perkelix) > > >Boot ID: a200afe0e5134b8a812b05c898c8b859 > > > Machine ID: 1063a9d1fb9df6e371ea9f94491345ed > > > Hostname: geode > > >Storage: > > > /var/lib/systemd/coredump/core.apt-get.0.a200afe0e5134b8a812b05c898c8b859.2083.163014678500.zst > > >Message: Process 2083 (apt-get) of user 0 dumped core. > > > > > > Stack trace of thread 2083: > > > #0 0xb7ae9170 frame_dummy (libstdc++.so.6 + > > > 0x87170) > > > > It seems that all libraries from gcc-11 are now compiled with Intel CET > > enabled, following an upstream commit [1]. I guess you will also have to > > downgrade libstdc++6. > > > > [1] > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8d286dd118a5bd16f7ae0fb9dfcdcfd020bea803 > > Sure enough, downgrading libstdc++6 too fixed it. Preventing other binaries from crashing with sig ILL required downgrading libgomp1 and other packages build from GCC11 as well. Martin-Éric
Bug#993162: libc6: i386 (Geode LX): latest push to Bookwork produces multiple sig ILL
la 28. elok. 2021 klo 13.40 Aurelien Jarno (aurel...@aurel32.net) kirjoitti: > > On 2021-08-28 13:36, Martin-Éric Racine wrote: > > la 28. elok. 2021 klo 12.58 Aurelien Jarno (aurel...@aurel32.net) kirjoitti: > > > > $ sudo coredumpctl debug 1011 > > > >PID: 1011 (apt-get) > > > >UID: 0 (root) > > > >GID: 0 (root) > > > > Signal: 4 (ILL) > > > > Timestamp: Sat 2021-08-28 11:00:34 EEST (3min 22s ago) > > > > Command Line: apt-get --quiet --quiet update > > > > Executable: /usr/bin/apt-get > > > > Control Group: /user.slice/user-1000.slice/session-4.scope > > > > Unit: session-4.scope > > > > Slice: user-1000.slice > > > >Session: 4 > > > > Owner UID: 1000 (perkelix) > > > >Boot ID: 77dfa6eb16584c02b84de4e2b8feb781 > > > > Machine ID: 1063a9d1fb9df6e371ea9f94491345ed > > > > Hostname: geode > > > >Storage: > > > > /var/lib/systemd/coredump/core.apt-get.0.77dfa6eb16584c02b84de4e2b8feb781.1011.163013763400.zst > > > >Message: Process 1011 (apt-get) of user 0 dumped core. > > > > > > > > Stack trace of thread 1011: > > > > #0 0xb7ad2ed0 __cpu_indicator_init > > > > (libgcc_s.so.1 + 0x2ed0) > > > > #1 0xb7faf02c call_init (ld-linux.so.2 + > > > > 0x1102c) > > > > #2 0xb7faf132 call_init (ld-linux.so.2 + > > > > 0x11132) > > > > #3 0xb7f9f0fa _dl_start_user (ld-linux.so.2 + > > > > 0x10fa) > > > > > > The SIGILL happens in __cpu_indicator_init which is provided by > > > libgcc-s1. Bookworm got a new upstream version of this package compared > > > to bullseye, so if you also upgraded it, it's more likely to be the > > > issue. In that case, have you tried to downgrade it? > > > > Just did. Here's the result: > > > > $ sudo coredumpctl debug 2083 > >PID: 2083 (apt-get) > >UID: 0 (root) > >GID: 0 (root) > > Signal: 4 (ILL) > > Timestamp: Sat 2021-08-28 13:33:05 EEST (1min 36s ago) > > Command Line: apt-get update > > Executable: /usr/bin/apt-get > > Control Group: /user.slice/user-1000.slice/session-2.scope > > Unit: session-2.scope > > Slice: user-1000.slice > >Session: 2 > > Owner UID: 1000 (perkelix) > >Boot ID: a200afe0e5134b8a812b05c898c8b859 > > Machine ID: 1063a9d1fb9df6e371ea9f94491345ed > > Hostname: geode > >Storage: > > /var/lib/systemd/coredump/core.apt-get.0.a200afe0e5134b8a812b05c898c8b859.2083.163014678500.zst > >Message: Process 2083 (apt-get) of user 0 dumped core. > > > > Stack trace of thread 2083: > > #0 0xb7ae9170 frame_dummy (libstdc++.so.6 + > > 0x87170) > > It seems that all libraries from gcc-11 are now compiled with Intel CET > enabled, following an upstream commit [1]. I guess you will also have to > downgrade libstdc++6. > > [1] > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8d286dd118a5bd16f7ae0fb9dfcdcfd020bea803 Sure enough, downgrading libstdc++6 too fixed it. Martin-Éric
Bug#993162: libc6: i386 (Geode LX): latest push to Bookwork produces multiple sig ILL
la 28. elok. 2021 klo 12.58 Aurelien Jarno (aurel...@aurel32.net) kirjoitti: > > $ sudo coredumpctl debug 1011 > >PID: 1011 (apt-get) > >UID: 0 (root) > >GID: 0 (root) > > Signal: 4 (ILL) > > Timestamp: Sat 2021-08-28 11:00:34 EEST (3min 22s ago) > > Command Line: apt-get --quiet --quiet update > > Executable: /usr/bin/apt-get > > Control Group: /user.slice/user-1000.slice/session-4.scope > > Unit: session-4.scope > > Slice: user-1000.slice > >Session: 4 > > Owner UID: 1000 (perkelix) > >Boot ID: 77dfa6eb16584c02b84de4e2b8feb781 > > Machine ID: 1063a9d1fb9df6e371ea9f94491345ed > > Hostname: geode > >Storage: > > /var/lib/systemd/coredump/core.apt-get.0.77dfa6eb16584c02b84de4e2b8feb781.1011.163013763400.zst > >Message: Process 1011 (apt-get) of user 0 dumped core. > > > > Stack trace of thread 1011: > > #0 0xb7ad2ed0 __cpu_indicator_init (libgcc_s.so.1 > > + 0x2ed0) > > #1 0xb7faf02c call_init (ld-linux.so.2 + 0x1102c) > > #2 0xb7faf132 call_init (ld-linux.so.2 + 0x11132) > > #3 0xb7f9f0fa _dl_start_user (ld-linux.so.2 + > > 0x10fa) > > The SIGILL happens in __cpu_indicator_init which is provided by > libgcc-s1. Bookworm got a new upstream version of this package compared > to bullseye, so if you also upgraded it, it's more likely to be the > issue. In that case, have you tried to downgrade it? Just did. Here's the result: $ sudo coredumpctl debug 2083 PID: 2083 (apt-get) UID: 0 (root) GID: 0 (root) Signal: 4 (ILL) Timestamp: Sat 2021-08-28 13:33:05 EEST (1min 36s ago) Command Line: apt-get update Executable: /usr/bin/apt-get Control Group: /user.slice/user-1000.slice/session-2.scope Unit: session-2.scope Slice: user-1000.slice Session: 2 Owner UID: 1000 (perkelix) Boot ID: a200afe0e5134b8a812b05c898c8b859 Machine ID: 1063a9d1fb9df6e371ea9f94491345ed Hostname: geode Storage: /var/lib/systemd/coredump/core.apt-get.0.a200afe0e5134b8a812b05c898c8b859.2083.163014678500.zst Message: Process 2083 (apt-get) of user 0 dumped core. Stack trace of thread 2083: #0 0xb7ae9170 frame_dummy (libstdc++.so.6 + 0x87170) gdb terminated by signal ILL. Martin-Éric
Bug#993162: libc6: i386 (Geode LX): latest push to Bookwork produces multiple sig ILL
Package: libc6 Version: 2.31-17 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Since 2.31-17 trickled into Bookworm, a number of executables (including APT and GDB) die with sig ILL. An example: $ sudo coredumpctl debug 1011 PID: 1011 (apt-get) UID: 0 (root) GID: 0 (root) Signal: 4 (ILL) Timestamp: Sat 2021-08-28 11:00:34 EEST (3min 22s ago) Command Line: apt-get --quiet --quiet update Executable: /usr/bin/apt-get Control Group: /user.slice/user-1000.slice/session-4.scope Unit: session-4.scope Slice: user-1000.slice Session: 4 Owner UID: 1000 (perkelix) Boot ID: 77dfa6eb16584c02b84de4e2b8feb781 Machine ID: 1063a9d1fb9df6e371ea9f94491345ed Hostname: geode Storage: /var/lib/systemd/coredump/core.apt-get.0.77dfa6eb16584c02b84de4e2b8feb781.1011.163013763400.zst Message: Process 1011 (apt-get) of user 0 dumped core. Stack trace of thread 1011: #0 0xb7ad2ed0 __cpu_indicator_init (libgcc_s.so.1 + 0x2ed0) #1 0xb7faf02c call_init (ld-linux.so.2 + 0x1102c) #2 0xb7faf132 call_init (ld-linux.so.2 + 0x11132) #3 0xb7f9f0fa _dl_start_user (ld-linux.so.2 + 0x10fa) Stack trace for other executables show the same cause as above. $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping: 2 cpu MHz : 497.996 cache size : 128 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall bugs: sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass bogomips: 995.99 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: Feel free to reassign as appropriate. Cheers! Martin-Éric -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmEp8TIACgkQrh+Cd8S0 17YLcQ/9GU6jypIgCKXTN48qzbAbDZYiGnKmsRJ7vXmmKZOLH75SWsmT++NJi+lf SPe0JCKRhBuRVBx+0kIRZ89KaTn/L4fWXMb1UF9wLQQEkvQfj0Vbnwi5lgQuLTTw x99Zouh9s9OtRQ+SZhQnuTts2SeiYLN9xkmCVPlK4LUSYuNfXJ60dOmmCXvgzpoQ 7BAZ43XciA5jU2+SmK506oFCVjNQWstgncRKMVj2++apdXiSZXZ1cP2RLfIpurLU OH6Ke3iifeOgcNuhPbLfva5rrdwFIEo0mEKzNzgpzIsOzBjow2EAmLehr24iAcoy BkxGuTdGeUtF/rOQFEwhtPi2BwAqrgqSe0BFvy8D4rfY2wM0fprAV6/1xtMRAGCX HBo+VQPbBjcfW91sKXIBMAolJcirV1HoiKGZCjjQpPzZUSe7oTnFmVFvsSiCkfAb gNL4MTKnN6s5F4rGDmOcIxQ2B5h/AK/au8yB6gjPpyDWjQJ3812PpHlOoFUjrQzu Mhdr+er8oWZc8Thq9IN+tv76CeV9FLWPwNs8Fs5yVi11Tj5SCJJrNEe3IqnUBKj6 ioxg3WLAY3V+dYrFCTycZuaE+3wO9uNDmJZWFOOKeBptgiMqxgGOuoDO/IFSBLst kslWCmTguCn7EoHFGEK4Tlv8cSNZbZaIcsdDWNNgibFPqG12I8I= =uPzL -END PGP SIGNATURE-
Bug#991588: systemd: Buster to Bullseye: boot stalls at network loading on normal boot
ke 28. heinäk. 2021 klo 20.21 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > ke 28. heinäk. 2021 klo 19.18 Dennis Filder (d.fil...@web.de) kirjoitti: > > * You have tpm2-abrmd installed, and its systemd unit is the only one > > defining a Requires=systemd-udev-settle.service. 2.1.0-1 under > > Buster didn't do that yet, so this could be the breaking change. As > > its manpage states systemd-udev-settle.service as a unit is > > conceptually problematic because udev events are never really > > settled; the unit is also deprecated, so tpm2-abrmd should correct > > its systemd/udev definitions. > > It was probably pulled in as a Recommends. At least I don't recall > ever installing it. It appears that this bug is caused by tpm2-abrmd's systemd unit. Tagging the maintainer. Martin-Éric
Bug#991588: systemd: Buster to Bullseye: boot stalls at network loading on normal boot
ke 28. heinäk. 2021 klo 20.21 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > ke 28. heinäk. 2021 klo 19.18 Dennis Filder (d.fil...@web.de) kirjoitti: > > * You have tpm2-abrmd installed, and its systemd unit is the only one > > defining a Requires=systemd-udev-settle.service. 2.1.0-1 under > > Buster didn't do that yet, so this could be the breaking change. As > > its manpage states systemd-udev-settle.service as a unit is > > conceptually problematic because udev events are never really > > settled; the unit is also deprecated, so tpm2-abrmd should correct > > its systemd/udev definitions. > > It was probably pulled in as a Recommends. At least I don't recall > ever installing it. > > > * Another potential issue is this line: > > > > post-up systemctl restart micro-httpd.socket > > > > The call to systemctl might be blocking. > > Could be. That post-up is there because micro-https is launched by > systemd before all network interfaces are up, which fails because the > 172.16.1.2 to which I've configured it to bind does not exist that > early during bootup. micro-httpd would need to launch only after all > interfaces are up. I filed a bug against micro-https for that specific > issue. > > > I wonder if that micro-httpd.socket definition amounts to a circular > > dependency resulting in a deadlock. > > Could be. However, please note that bootup only stalls when launched > using the normal mode. If I boot via recovery mode and resume from the > rescue shell prrompt, it doesn't stall. > > > I recommend uncommenting the post-up line from /etc/network/interfaces > > just to see if this solves the problem. Alternatively try disabling > > tpm2-abrmd.service temporarily. > > I purged tpm2-abrmd and regular bootup no longer stalls. > > Thanks for the above. You zeroed-in on the most probable cause of the > problem. :) > > Martin-Éric $ LC_ALL=C apt-cache depends tpm2-abrmd tpm2-abrmd PreDepends: init-system-helpers Depends: libc6 Depends: libglib2.0-0 Depends: libtss2-mu0 Depends: libtss2-rc0 Depends: libtss2-sys1 Depends: libtss2-tctildr0 $ LC_ALL=C apt-cache rdepends tpm2-abrmd tpm2-abrmd Reverse Depends: tpm2-abrmd-dbgsym $ LC_ALL=C apt-cache rdepends tpm2-abrmd-dbgsym tpm2-abrmd-dbgsym Reverse Depends: Given the above, I'm begining to wonder whether 1) reassigining to src:tpm2-abrmd or even 2) removing src:tpm2-abrmd from the archive would make more sense? Martin-Éric
Bug#991588: systemd: Buster to Bullseye: boot stalls at network loading on normal boot
ke 28. heinäk. 2021 klo 19.18 Dennis Filder (d.fil...@web.de) kirjoitti: > * You have tpm2-abrmd installed, and its systemd unit is the only one > defining a Requires=systemd-udev-settle.service. 2.1.0-1 under > Buster didn't do that yet, so this could be the breaking change. As > its manpage states systemd-udev-settle.service as a unit is > conceptually problematic because udev events are never really > settled; the unit is also deprecated, so tpm2-abrmd should correct > its systemd/udev definitions. It was probably pulled in as a Recommends. At least I don't recall ever installing it. > * Another potential issue is this line: > > post-up systemctl restart micro-httpd.socket > > The call to systemctl might be blocking. Could be. That post-up is there because micro-https is launched by systemd before all network interfaces are up, which fails because the 172.16.1.2 to which I've configured it to bind does not exist that early during bootup. micro-httpd would need to launch only after all interfaces are up. I filed a bug against micro-https for that specific issue. > I wonder if that micro-httpd.socket definition amounts to a circular > dependency resulting in a deadlock. Could be. However, please note that bootup only stalls when launched using the normal mode. If I boot via recovery mode and resume from the rescue shell prrompt, it doesn't stall. > I recommend uncommenting the post-up line from /etc/network/interfaces > just to see if this solves the problem. Alternatively try disabling > tpm2-abrmd.service temporarily. I purged tpm2-abrmd and regular bootup no longer stalls. Thanks for the above. You zeroed-in on the most probable cause of the problem. :) Martin-Éric
Bug#991588: systemd: Buster to Bullseye: boot stalls at network loading on normal boot
ke 28. heinäk. 2021 klo 10.43 Michael Biebl (bi...@debian.org) kirjoitti: > > control: reassign -1 ifupdown > > Am 28.07.21 um 06:13 schrieb Martin-Éric Racine: > > Package: systemd > > Version: 247.3-6 > > Severity: serious > > > > Since upgrading to Bullseye, the boot process stalls at network loading [1] > > when booting in regular mode. When booting in recovery mode and resuming > > boot at the rescue shell prompt, the boot process completes as normal. > > > > Since /etc/network/interfaces [2] remains the same and worked fine under > > Buster, I suspect that this is a systemd issue. Feel free to reassign as > > appropriate. > > > > Since this prevents normal rebooting, I consider this a serious issue. > > > > [1] Alternates between these two lines: > > A start job is running for Helper to synchronize boot up for ifupdown > > A start job is running for Wait for udev to complete device initialization > > Since ifupdown installs a udev rule for allow-hotplug interfaces and > ifupdown-pre.service is shipped by ifupdown, I'm going to reassign this > to the ifupdown package. > Its maintainer is more likely to help you debug any ifupdown related issues. Fair enough. Adding ifupdown reportbug output: --- up and down scripts installed: /etc/network/if-down.d: total 4 lrwxrwxrwx 1 root root 29 Feb 24 13:34 bridge -> /lib/bridge-utils/ifupdown.sh -rwxr-xr-x 1 root root 1677 Mar 30 2019 clamav-freshclam-ifupdown lrwxrwxrwx 1 root root 32 Feb 25 23:19 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-post-down.d: total 4 lrwxrwxrwx 1 root root 29 Feb 24 13:34 bridge -> /lib/bridge-utils/ifupdown.sh lrwxrwxrwx 1 root root 25 Feb 25 23:19 hostapd -> ../../hostapd/ifupdown.sh -rwxr-xr-x 1 root root 1409 Mar 24 2016 wireless-tools lrwxrwxrwx 1 root root 32 Feb 25 23:19 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-pre-up.d: total 12 lrwxrwxrwx 1 root root 29 Feb 24 13:34 bridge -> /lib/bridge-utils/ifupdown.sh -rwxr-xr-x 1 root root 344 Jun 30 2016 ethtool lrwxrwxrwx 1 root root 25 Feb 25 23:19 hostapd -> ../../hostapd/ifupdown.sh -rwxr-xr-x 1 root root 4191 Sep 15 2018 wireless-tools lrwxrwxrwx 1 root root 32 Feb 25 23:19 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-up.d: total 16 -rwxr-xr-x 1 root root 1677 Mar 30 2019 clamav-freshclam-ifupdown -rwxr-xr-x 1 root root 1685 Jun 30 2016 ethtool -rwxr-xr-x 1 root root 4938 Jan 4 2021 mountnfs lrwxrwxrwx 1 root root 32 Feb 25 23:19 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 5.10.0-4 ii libc6 2.31-13 ii lsb-base 11.1.0 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2.3 Versions of packages ifupdown suggests: ii ppp 2.4.9-1+1 pn rdnssd -- no debconf information > > > [2] /etc/network/interfaces: > > allow-hotplug /en* /wl* > > auto br0 > > > > iface br0 inet static > > bridge_hw (MAC) > > bridge_ports regex (enp3|enp6|wl).* > > address 172.16.1.2 > > post-up systemctl restart micro-httpd.socket > > iface br0 inet6 manual > > bridge_hw (MAC) > > bridge_ports regex (enp3|enp6|wl).* > > # IPv6 from /etc/dhcp/dhclient-exit-hooks.d/prefix_delegation > > privext 2 > > > > iface enp3s0 inet manual > > > > iface enp4s0 inet dhcp > > iface enp4s0 inet6 auto > > post-up /etc/boot.d/iptables_IPv4-MASQ_IPv6-bridge_no-LTSP-outside > > request_prefix 1 > > privext 2 > > dhcp 1 > > > > #BGN,2x2:2 > > iface wlxMAC1 inet manual > > hostapd /etc/hostapd/hostapd-1-wlxMAC1.conf > > > > #ABGN,2x2:2 > > iface wlxMAC2 inet manual > > hostapd /etc/hostapd/hostapd-1-wlxMAC2.conf > > > > -- Package-specific info: > > > > -- System Information: > > Debian Release: 11.0 > >APT prefers testing-security > >APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, > > 'testing'), (500, 'stable') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) > > Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi:en > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages systemd depends on: > > ii adduser 3.118 > > ii libacl1 2.2.53-10 > > ii libapparmor1 2.13.6-10
Bug#991416: bridge-utils: broken IPv4 connection after upgrading to Debian Bullseye, setting old MAC with bridge_hw fixes the issue
Package: bridge-utils Followup-For: Bug #991416 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've had similar problems in the past. IIRC this is caused by occasional changes in how the kernel does interface discovery. In my particular case, the bridge took on the nasty habit of adopting the MAC address of a removable interface. Removing the device made the bridge collapse. The fix indeed was to specificy the MAC address I want it to use using bridge_hw. Martin-Éric -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmD6g2AACgkQrh+Cd8S0 17a0qxAAuAAYpas+x9BIvJdgd6I6Mxh+iVFzlCwuUwE351eDfzDcSDAFepUQ/r8m +HGL0bn6pJDgfOF1xWHLWKB85YGjENu0M1AaI3ABxu/wA3KTHmhPP5932KbqM6Lz yfEpvBonsD6La7R1zBqp/n/n+/NHmkJt8JFVd4ltQ3na3gIShKdc71CiuHoe0ZRU v07JobiDnxJyz/RwdJUKKKiqLn1y6HeexEz42sT0u6nd16h/vqjF1THKhlfg9n6x 5iUK7djWMzijsz81wduHUIku+0ac8yrjGgCqjBkyFVeZV0AZypWD/jDXV1bPNnm7 MfUXauUgjdHa9aW7RIwHL3xuDUUWGIoaoH8AnVlgBu7I4yH9yf3Se6L4+uzaLsMh EJ4ABZaYKZLh598XNR8owCrJaYErUSJoAX91KwmmCZrHaNI6mAB+UDW5sjtvjHox acfskUi/WjE5EjKJMX7ZONuloctzVVqY5s1QtT2j7laBDVyTWBnPFV0iG0vopyqS Qkp2io7eKwjEp9BLd/e6pkCeW5zWm87CMDQClTOgQZ6PPkbMhiyLAwNrjWJddN+h yjAagiM5om4akJ3VwTmBVsNDFjz8FQPKAlBvgaVGyCH+Ql5IWfaK68gjc+exCcpt /3H+TTTLloQ0m2BYTrMhD2TVfU5yDTOHFCjndmlNxzRmEPfSo9o= =h3CF -END PGP SIGNATURE-
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
Thanks for the additional info, and for the patch in the first place. I'll upload it asap. Thx, Mt. signature.asc Description: PGP signature
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
Hello, I'm sorry to ask, but I fear I need additional information, please. It seems to me that this patch merely circumvent the change in ImageMagik to allow the handling of eps file during the construction of the package. Am I right, or is it only disabling the dangerous parts of the converter while retrieving the parts we need? Sorry to ask, I'm very bad with ImageMagik. Even if it's re-enabling the conversion of eps files for the package building, I guess that this is a good emergency solution to not delay the release too much, provided that we trust the eps files that come with ns-3. Thanks for the proposal. But I would prefer not to live with such a complex and even somewhat dangerous patch in my package, so I'm curious about other solutions that would allow to convert eps to png without ImageMagik. Maybe using gimp and Script-Fu? Thanks for that patch anyway, Mt Le Fri, Jul 16, 2021 at 06:21:21PM +0200, Dennis Filder a écrit : > Control: tag -1 patch > > With this patch the build finished for me. > > Regards, > Dennis Filder > Description: Override overly strict ImageMagick security policy (#987504) > This patch derives a more permissive ImageMagick security policy from > the system default. > Author: Dennis Filder > Last-Update: 2021-07-16 > Bug-Debian: https://bugs.debian.org/991061 > --- a/ns-3.31/doc/models/Makefile > +++ b/ns-3.31/doc/models/Makefile > @@ -496,6 +496,8 @@ > > RESCALE = ../../utils/rescale-pdf.sh > > +POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: > ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml" > + > %.eps : %.dia > @echo dia $(notdir $<) > @$(DIA) -t eps $< -e $@ >/dev/null > @@ -506,7 +508,9 @@ > > %.png : %.eps > @echo convert $(notdir $<) > - @$(CONVERT) $< $@ >/dev/null > + test -d ../../../debian/tmp/ImageMagick || mkdir -p > ../../../debian/tmp/ImageMagick > + test -f ../../../debian/tmp/ImageMagick/policy.xml || sed -e '/ domain="coder" rights="none" pattern="PS" .>/s@"none"@"read|write"@' > "$(POLFILE)" > ../../../debian/tmp/ImageMagick/policy.xml > + XDG_CONFIG_HOME="$(shell pwd)/../../../debian/tmp" $(CONVERT) $< $@ > >/dev/null > > %.pdf : %.eps > @echo epstopdf $(notdir $<) > @@ -556,6 +560,7 @@ > clean: > -rm -rf $(BUILDDIR)/* > -rm -rf $(SOURCETEMP) > + -rm -Rf ../../../debian/tmp/ImageMagick > > frag: pickle > @if test ! -d $(BUILDDIR)/frag; then mkdir $(BUILDDIR)/frag; fi -- The web was not envisioned as a form of television when it was invented. But, like it or not, it is rapidly resembling TV: linear, passive, programmed and inward-looking. -- Hossein Derakhshan https://medium.com/matter/the-web-we-have-to-save-2eb1fe15a426 signature.asc Description: PGP signature
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
Hello, thanks for the report. I've read through the bugs both in debian and ubuntu, and I found the location of the issue in the package (ns3 is quite a large package). ns-3.31/doc/models/Makefile reads (many lines omitted): ``` CONVERT = convert # specify figures from which .png and .pdf figures need to be # generated (all dia and eps figures) IMAGES_EPS = \ $(FIGURES)/lena-dual-stripe.eps \ %.png : %.eps @echo convert $(notdir $<) @$(CONVERT) $< $@ >/dev/null ``` Now, the question is about what is the best move from here. I cannot do as in the bug I've seen by Ubuntu where the eps doc was disabled, as we use(d) convert to move the other way around, eps -> png. Is there another way to convert eps to png that I could use (according to google, ImageMagik is THE way to go here), or shall I ship a broken documentation? Any advice would be welcome here. Thanks, Mt. - Le 13 Juil 21, à 15:59, Adrian Bunk b...@debian.org a écrit : > Source: ns3 > Version: 3.29+dfsg-3 > Severity: serious > Tags: ftbfs > > https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/ns3.html > > ... > convert lena-dual-stripe.eps > convert-im6.q16: attempt to perform an operation not allowed by the security > policy `PS' @ error/constitute.c/IsCoderAuthorized/408. > convert-im6.q16: no images defined `source-temp/figures/lena-dual-stripe.png' > @ > error/convert.c/ConvertImageCommand/3258. > make[2]: *** [Makefile:475: source-temp/figures/lena-dual-stripe.png] Error 1 > > > See #987504 for background.
Bug#986012: fatrace: autopkgtest regression: ^rm(.*): D /tmp/autopkgtest-lxc.yky1gevw/downtmp/build.jzI/src$ not found in log
Control: tag -1 pending Paul Gevers [2021-03-27 21:43 +0100]: > https://ci.debian.net/data/autopkgtest/testing/amd64/f/fatrace/11288159/log.gz > > autopkgtest [23:08:44]: test fatrace-currentmount: [--- > ^rm(.*): D /tmp/autopkgtest-lxc.yky1gevw/downtmp/build.jzI/src$ not > found in log I finally found some time to reproduce this with [1]. I tested fatrace manually, and I don't find any way any more to get open_by_handle_at() or fanotify to work in an LXC container with the default security profile any more. As I don't have any influence over the container setting in production debci, I'm afraid my only way out is to apply "isolation-machine" to fatrace-currentmount as well. At least all the tests are runnning both in upstream and Ubuntu CI. Thanks, Martin [1] https://ci.debian.net/doc/file.MAINTAINERS.html
Bug#988462: trac: not ready for Debian 11
Package: trac Version: 1.5.2+dfsg-2 Severity: serious IMHO, the current version of Trac is not suitable for including it in a stable release. I'll try to provide backports of future version 1.6.x for Debian 11.
Bug#926253: postfixadmin: /usr/share/postfixadmin/lib/../templates_c does not exist on new installation
Thanks for the report. If you can provide a patch I can try to include it in a bugfix release. Christoph Am 02.04.19 um 19:26 schrieb Michael Krieger: > Package: postfixadmin > Version: 3.2.1-2 > Severity: important > > On a new installation of postfixadmin in Buster, > /usr/share/postfixadmin/lib/../templates_c > (the compiled template folder) is not created. As such, the following error > appears and > nothing works: > AH01071: Got error 'PHP message: ERROR: directory > /usr/share/postfixadmin/lib/../templates_c > doesn't exist or isn't writeable for the webserver' > > > A simple: > mkdir -p /usr/share/postfixadmin/lib/../templates_c > chown www-data /usr/share/postfixadmin/lib/../templates_c -R > chmod 700 /usr/share/postfixadmin/lib/../templates_c > results in postfixadmin working correctly by creating the folder and > appropriately sets > permissions for the folder for use by web servers. >
Bug#987264: git-el: fails to install with xemacs21
On Sat, 24 Apr 2021 02:59:40 +0300 Adrian Bunk wrote: > On Tue, Apr 20, 2021 at 05:10:16PM +0200, Andreas Beckmann wrote: > > Package: git-el > > Version: 1:2.30.2-1 > > Severity: serious > > User: debian...@lists.debian.org > > Usertags: piuparts > > > > Hi, > > > > during a test with piuparts I noticed your package failed to install if > > xemacs21 is already installed. > > Most relevant is that emacs-common is *not* installed > and neither any other package that ships /usr/share/emacs/site-lisp/ IIRC emacs-common is only for FSF Emacs packages. The quickest workaround would be to add a debian/git-el.dirs file containing usr/share/emacs/site-lisp. I wonder if emacsen-common package should provide that dir for all emacs flavours. -- Agustin
Bug#858498: Please reject simgrid_3.27+dfsg-1
Hello FTP masters, I'm sorry for the extra burden, but I uploaded the new upstream release to unstable by error instead of experimental. This upload needs to be canceled so that I can fix the version in testing. #858498 is RC and was reopened an hour ago. Sorry again for the extra burden, Mt. signature.asc Description: PGP signature
Bug#985754: Bug #985754: dino-im
Thanks Sebastian for finding the bug, thanks Michel for finding the upstream fix! Will upload now!
Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x
On Tue, Mar 9, 2021 at 2:23 PM Dirk Eddelbuettel wrote: > > > On 9 March 2021 at 14:26, Graham Inggs wrote: > | Control: tags -1 - fixed-upstream + upstream > | Control: notforwarded -1 > | > | > | >From TMB upstream [1]: > | > | > Digging a bit deeper I found that after calling > | > > | > M_cholmod_factorize_p(A, mm, (int*)NULL, 0 /*fsize*/, f, ) > | > > | > the cholmod_common struct contains bogus, e.g. c.status=14903956 and > c.dtype=15216988. > | > | > | [1] https://github.com/kaskr/adcomp/issues/340#issuecomment-790606775 > > Appreciate the hard-core digging Graham! > > And said call is made by glmmTMB in error, or is the call done by Matrix as > part of exposing CHOLMOD? Indeed, that's the question ... If glmmTMB calls Matrix-exported C functions and something goes wrong does not necessarily point the finger to Matrix, even though it did not happen for previous versions of Matrix. In this case, it could be that glmmTMB relied on an undocumented Matrix behavior which I had decided to change... though I must say, I would still be surprised.. I'd rather expect something more complicated where at least two factors are leading to the problem you see.. Martin -- Martin Maechler, Seminar fuer Statistik, ETH Zurich
Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0
Hi Sam, that looks mostly good. Now I had some time to test your changes, and I have some things, that may need another check. I have added pam_tally to common-auth and the upgrade did not stop when installing the new libpam-modules. I believe the regex is missing these files, since it does not contain a "-" in the permitted characters. Currently it chatches these files: # ls -1d /etc/pam.d/* | grep -e '^/etc/pam.d/[0-9a-zA-Z/]*$' /etc/pam.d/chfn /etc/pam.d/chpasswd /etc/pam.d/chsh /etc/pam.d/login /etc/pam.d/newusers /etc/pam.d/other /etc/pam.d/passwd /etc/pam.d/runuser /etc/pam.d/su With a modified search it will also find the common-* files: # ls -1d /etc/pam.d/* | grep -e '^/etc/pam.d/[0-9a-zA-Z/-]*$' /etc/pam.d/chfn /etc/pam.d/chpasswd /etc/pam.d/chsh /etc/pam.d/common-account /etc/pam.d/common-auth /etc/pam.d/common-password /etc/pam.d/common-session /etc/pam.d/common-session-noninteractive /etc/pam.d/login /etc/pam.d/newusers /etc/pam.d/other /etc/pam.d/passwd /etc/pam.d/runuser /etc/pam.d/runuser-l /etc/pam.d/su /etc/pam.d/su-l While testing I also noticed, that pam-auth-update gives some errors on my system. These come from line 710-714 of the script. Upon further checking I found, that the script does not handle commented lines. We use "# ..." comments at the start of our pam-configs. Is that an intented use-case or should we add an exception to pam-auth-update to filter comment lines? And some final nitpick: It seems I mistyped a capital T (line 21) into the text templates and this got copied over.
Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x
On Tue, Feb 23, 2021 at 3:17 PM Graham Inggs wrote: > > Hi Dirk > > On Tue, 23 Feb 2021 at 15:34, Dirk Eddelbuettel wrote: > > If it were me I would turn off the autopkgtest in r-cran-glmmtmb (maybe just > > on s390x) and move on. > > That would just be hiding the problem. > > If it is the kind of bug I described previously, it shows up more > often on big-endian systems, but it is still present on little-endian > systems, and will show up in the right (wrong) conditions. > You may be right on spot, Graham, or not.. Currently I don't have time to investigate ... also I *have* been a bit puzzled by therankMatrix(*, "qr") -- Matrix-only -- discrepancy that Dirk found. I agree it *would* be good to dig further, but that needs a chunk of dedicated time (and "free head") which I don't have for now. Apropos 'rabbit hole' : Isn't the origin -- long before the Matrix movie -- in Lewis Carrol's "Alice in Wonderland" (1865 !!): https://en.wikipedia.org/wiki/White_Rabbit ?? Best, Martin -- Martin Maechler, Seminar fuer Statistik, ETH Zurich
Bug#885195: [Pkg-electronics-devel] Bug#885195: guile-2.0 removed
Joerg Jaspert schrieb am 13. February 2021: > i just removed guile-2.0 from unstable. > While your package already won't be part of the next release, it will > now also be unusable in unstable. > > Please either upload a fixed version A fixed version sits at debian mentors looking for a sponsor. https://mentors.debian.net/package/geda-gaf/ First upload to debian mentors was last week (Tuesday 9th). I reploaded to amend changes that make lintian complain less and respond to remarks by reviewers. All the best, ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgpjmZsDa0IFc.pgp Description: OpenPGP digital signature
Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)
Dear Dirk,
I'm in vacations right now ...
1) I think I might simply disable the check *on* that platform .. or
platforms with similar characteristics.
Can you send me the outputs of so I can take some of the entries to
determine I'm on the platform?
sessionInfo()
str(.Machine, digits=10)
capabilities()
.Platform
2) Can you send me the result of rankMatrix(Z, method="qr")
i.e. `rnkZ.` from the above example ?
Best, Martin
On Mon, Feb 15, 2021 at 5:12 PM Dirk Eddelbuettel wrote:
>
>
> Martin,
>
> I have this long-running bug report against Matrix, triggered by glmmTMB on
> s390x. Graham has been chasing this patiently and we are now at the level of
> checking on a shell account on the appropriate hardware.
>
> We validated that everything does in fact "still break" with CRAN-current
> packages of everything (and R 4.0.3, I guess by tomorrow we'd have 4.0.4).
>
> glmmTMB does indeed fail in an example -- but so does Matrix 1.3-2 when I run
>
> _R_CHECK_FORCE_SUGGESTS_=false R CMD check \
> --no-manual --no-vignettes Matrix_1.3-2.tar.gz
>
> and I see
>
> [...]
> Running 'factorizing.R'
> ERROR
> Running the tests in 'tests/factorizing.R' failed.
> Last 13 lines of output:
> + inherits(qrZ, "sparseQR")
> + inherits(Rz, "sparseMatrix")
> + isTriangular(Rz)
> + isDiagonal(Rz) # even though formally a "dtCMatrix"
> + qr2rankMatrix(qrZ, do.warn=FALSE) == 6
> + })
> > options(oo)
> >
> > ## problematic rank deficient rankMatrix() case -- only seen in large
> cases ??
> > Z. <- readRDS(system.file("external", "Z_NA_rnk.rds", package="Matrix"))
> > tools::assertWarning(rnkZ. <- rankMatrix(Z., method = "qr")) # gave errors
> Error in assertCondition(expr, classes, .exprString = d.expr) :
> Failed to get warning in evaluating rnkZ. <- rankMatrix(Z., method ...
> Calls: -> assertCondition
> Execution halted
> * checking for unstated dependencies in vignettes ... OK
>
> Can you advise if I should dive into a particular routine or comparison to
> see what is up here?
>
> Best, Dirk
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
--
Martin Maechler,
Seminar fuer Statistik, ETH Zurich
Bug#930005: regina-rexx: rexxutil error
Package: regina-rexx
Version: 3.6-2.2
Severity: wishlist
El lun, 15 feb 2021 a las 13:40, Alen Zekulic () escribió:
>
> On Mon, Feb 15, 2021 at 13:16:58 +0100, Agustin Martin wrote:
>
> > I think I have something close to be ready for migration to debhelper.
>
> Me too. :)
>
> > ¿What do you prefer, a commit to salsa or a patch in the BTS?
>
> For now I prefer a patch in the BTS.
FIne, Alen,
I am filing a new bug report about this with wishlist severity, and
attaching a git patch with my changes. This is only about migration to
old-style debhelper from 3.5-2.2. It includes the migration itself and
making most of the package multiarch ready. As a bonus this fixes the
timestamp issues in #854294.
There is a pending thing about multiarch, the handling of
regina-config is not yet multiarch friendly. An $arch version should
be installed in an arch dependent dir and /usr/bin/regina-config be
made a wrapper to it, considering the architecture for which the
package is built (this is important e.g. when building for amd64/i386
from the other arch). Once I have something ready I will submit an
additional patch to this bug report, to be appplied after debhelper
migration changes.
Regards,
--
Agustin
From 389c9685789a9799477c09285c378b784f87bd51 Mon Sep 17 00:00:00 2001
From: Agustin Martin
Date: Mon, 15 Feb 2021 20:29:39 +0100
Subject: [PATCH] Migrate to old-style debhelper from regina-rexx 3.6-2.2
* Migration to old-style debhelper. This also includes:
- Make package multiarch.
- Fix the timestamp issues in #854294.
* Remove autotools-dev Build-Dep, it is pulled by debhelper.
Signed-off-by: Agustin Martin
---
debian/control| 20 +-
debian/libregina3-dev.install | 5 +
debian/libregina3-dev.manpages| 1 +
debian/libregina3.install | 2 +
debian/md5_sums | 19 --
debian/patches/_Makefile.in_libdir.diff | 32 +++
.../patches/_Makefile.in_set-DESTDIR.diff | 17 ++
debian/patches/_Makefile.in_sharedir.diff | 25 +++
debian/patches/az-patch-01| 18 --
debian/patches/series | 4 +
debian/postinst | 8 -
debian/postrm | 8 -
debian/postrm-dev | 8 -
debian/regina-rexx.examples | 2 +
debian/regina-rexx.install| 5 +
debian/regina-rexx.links | 1 +
debian/regina-rexx.manpages | 3 +
debian/rules | 190 +++---
18 files changed, 186 insertions(+), 182 deletions(-)
create mode 100644 debian/libregina3-dev.install
create mode 100644 debian/libregina3-dev.manpages
create mode 100644 debian/libregina3.install
delete mode 100644 debian/md5_sums
create mode 100644 debian/patches/_Makefile.in_libdir.diff
create mode 100644 debian/patches/_Makefile.in_set-DESTDIR.diff
create mode 100644 debian/patches/_Makefile.in_sharedir.diff
delete mode 100644 debian/postinst
delete mode 100644 debian/postrm
delete mode 100644 debian/postrm-dev
create mode 100644 debian/regina-rexx.examples
create mode 100644 debian/regina-rexx.install
create mode 100644 debian/regina-rexx.links
create mode 100644 debian/regina-rexx.manpages
diff --git a/debian/control b/debian/control
index 0413a05..bc66464 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,8 @@ Source: regina-rexx
Section: libs
Priority: optional
Maintainer: Alen Zekulic
-Build-Depends: libncurses5-dev, autotools-dev
+Build-Depends: libncurses5-dev,
+ debhelper-compat (=12)
Standards-Version: 4.4.1
Homepage: http://regina-rexx.sourceforge.net/
Vcs-Git: https://salsa.debian.org/debian/regina-rexx.git
@@ -10,7 +11,8 @@ Vcs-Browser: https://salsa.debian.org/debian/regina-rexx
Package: libregina3
Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends},
+ ${misc:Depends}
Conflicts: regina3
Replaces: regina3
Description: Regina REXX interpreter, run-time library
@@ -25,9 +27,14 @@ Description: Regina REXX interpreter, run-time library
Package: libregina3-dev
Section: libdevel
Architecture: any
-Depends: ${regver:Depends}, libc6-dev, cpp
-Conflicts: regina2-dev, regina3-dev
-Replaces: regina2-dev, regina3-dev
+Depends: ${misc:Depends},
+ libregina3 (= ${binary:Version}),
+ libc6-dev,
+ cpp
+Conflicts: regina2-dev,
+ regina3-dev
+Replaces: regina2-dev,
+ regina3-dev
Description: Regina REXX interpreter, development files
Regina is an ANSI compliant REXX interpreter for multiple platforms.
.
@@ -41,7 +48,8 @@ Description: Regina REXX interpreter, development files
Package: regina-rexx
Section: interpreters
Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends},
+ ${misc:Depends}
Description: Regina REXX interpreter
Regina i
Bug#982613: NetworkManager triggers assert in python-dbusmock test suite
Control: reassign -1 network-manager 1.29.90-1 Control: tag -1 upstream fixed-upstream Control: forwarded -1 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/662 This eventually *did* turn out to be a bug in NetworkManager itself, and only became visible now because of the beta version number. I validated that the fix https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/e1e9abdf041b4cc backports cleanly on top of 1.29.90 and fixes the assertion and the python-dbusmock tests. Thus moving this bug back to NM. I don't think this beta version should move into testing, as it's prone to cause assertion crashes in real-life situations as well. But of course Michael has the last word on this. Thanks Thomas and Michael for your help here! Martin
Bug#930005: regina-rexx: rexxutil error
El lun, 15 feb 2021 a las 0:05, Agustin Martin () escribió: > > El vie, 12 feb 2021 a las 23:05, Alen Zekulic () > escribió: > > > > I agree, please go ahead! > > Uploaded. Hi, Seems this upload has been late for two days, so regina-rexx will not hit bullseye because of soft freeze (see https://release.debian.org/bullseye/freeze_policy.html#soft), "Packages that are not in testing will not be allowed to migrate to testing. This applies to new packages as well as to packages that were removed from testing (either manually or by auto-removals). Packages that are not in bullseye at the start of the soft freeze will not be in the release." > > I planed to migrate my debian/rules to debhelper too. > > When I was playing with this there were still some issues. Once I find > time to continue and consider things in good shape, I will let you > know. Another thing I think may be interesting is to split the a-z > patch into smaller chunks for better handling. I think I have something close to be ready for migration to debhelper. ¿What do you prefer, a commit to salsa or a patch in the BTS? Regards, -- Agustin
Bug#930005: regina-rexx: rexxutil error
El vie, 12 feb 2021 a las 23:05, Alen Zekulic () escribió: > > On Fri, Feb 12, 2021 at 13:25:23 +0100, Agustin Martin wrote: > > > Alen, I plan to upload a NMU with this changes and may be some minor > > issues. Even if I have not written rexx for years I think it would be > > a pity to have this package with this open bug. > > I agree, please go ahead! Uploaded. > > Also, one issue with this package is that Debian build system is > > ancient, even pre-debhelper. This makes everything a nightmare. I > > have been playing with a migration to traditional (no dh sequencer) > > debhelper. This should fix another bug report about build > > reproduciibility. I am aware that this is a rather invasive change, > > but I think is required to make contributors life easier, let me know > > your POV. > > I planed to migrate my debian/rules to debhelper too. When I was playing with this there were still some issues. Once I find time to continue and consider things in good shape, I will let you know. Another thing I think may be interesting is to split the a-z patch into smaller chunks for better handling. > > Other thing I noticed is that this package has no repo under > > salsa. I can prepare a git repo with regina history and put it under > > salsa/debian group. Alen, please tell me if you object to this, I > > consider it important and will proceed unless you object explicitly. > > Any help is greatly appreciated, I have no objection, quite the > contrary! When I was creating the repo I noticed that there was already a repo created under debian salsa group by Boyuan Yang, with commits for a NMU that was never uploaded, so I used it. Reverted one thing, no need to B-D on debhelper just to pull autotools-dev, debhelper is currently unused. > > By the way, upstream is active and there are new versions available, > > although I will focus on current upstream version in Debian. > > Mark and I are in contact. We plan to roll out the latest releases of > Regina REXX (3.9.4) and The Hessling Editor (3.3) as soon as possible. Nice to know, Regards, -- Agustin
Bug#982613: NetworkManager triggers assert in python-dbusmock test suite
Martin Pitt [2021-02-14 11:41 +0100]: > So this is some weird NM build system issue that breaks something for any tag > (i.e. minor/micro version in configure.ac) >= 1.28.0. Note that the 1.28-rc* > tags > have version 1.27.x. I checked out tag 1.30-rc1 (aka version 1.29.0), and changed configure.ac+meson.build from 1.29.90 → 1.30.0, and voilà, it works. So it's not something specific to 28, but specific to doing a final release. Setting the version to 1.30.90 also works, and it's enough to change configure.ac, leaving meson.build alone. (Debian's package still uses automake, not meson). And here we have the explanation at last: configure.ac sets `more_asserts_default` for odd (development) minor versions, i.e. non-release versions are built with --with-more-asserts=100. So now I need to figure out what the (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS) assertion is really about, and mock this harder. So reassigning to dbusmock was justified, this is not a regression in NM, and thus the autopkgtest regression should be ignored/overridden. Martin [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/master/configure.ac#L1066
Bug#982613: NetworkManager triggers assert in python-dbusmock test suite
Hello all, CC'ing Thomas, maybe he has some idea about this. Thomas, please see [0] for the python-dbusmock failure that triggered this bug report. Adrian Bunk [2021-02-12 16:22 +0200]: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz > test_one_wifi_with_accesspoints (__main__.TestNetworkManager) ... ** > libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: assertion > failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS) > Bail out! libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: > assertion failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS) > ERROR I enabled tests on Debian unstable upstream now [1] to reproduce the failure [2]. I first ran a bisect between tags 1.28.0 (which works) and 1.30-rc1 (which is release 1.29.90, and fails). Curiously that came out as "release: bump version to 1.29.0 (development) is the first bad commit". It turns out that the 1.29.0-dev branch got based off 1.28-rc1, not 1.28.0, and `git shortlog 1.28-rc1..1.28.0` has a good deal of changes. I confirmed that 1.28-rc1 itself also has that failure (otherwise I'd really be 勞), and so does 1.28-rc2. Then I ran a bisect between 1.28-rc2 and 1.28.0, and again it resulted in the first bad version being "release: bump version to 1.28.0" [3] (which is again trivial). I used a test script [4] which builds everything from a clean git tree, and I uninstalled network-manager from the container that I'm running this in, so there are no stale files between builds. The NM dbusmock [5] does not have any version check or other version sensitive code. So this is some weird NM build system issue that breaks something for any tag (i.e. minor/micro version in configure.ac) >= 1.28.0. Note that the 1.28-rc* tags have version 1.27.x. I grepped the NM source for '1_28' and '\b1\b.*\b28\b', but that did not spot anything obvious. I also checked for '\b1\b.*\b27\b' (just in case there is some condition on <= 1.27), but that does not hit anything relevant. So at the moment I'm totally stumped about this. Thomas, are you aware of any version sensitive magic in NM's build? Thanks! Martin [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982613#5 [1] https://github.com/martinpitt/python-dbusmock/commit/8350ab65eb [2] https://github.com/martinpitt/python-dbusmock/actions/runs/565487941 [3] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/6f32c5c10736 [4] #!/bin/sh set -eux cd /tmp/NetworkManager git clean -ffdx ./autogen.sh --with-crypto=gnutls --with-iptables=/usr/sbin/iptables make -j4 clients/cli/nmcli cd /source PATH=/tmp/NetworkManager/clients/cli:$PATH PYTHONPATH=. python3 tests/test_networkmanager.py TestNetworkManager.test_one_wifi_with_accesspoints [5] https://github.com/martinpitt/python-dbusmock/blob/master/dbusmock/templates/networkmanager.py
Bug#982613: Debian Python Team
Control: reassign -1 0.22.0-1 Control: affects -1 network-manager Adrian Bunk [2021-02-12 16:22 +0200]: > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/10412779/log.gz > test_one_wifi_with_accesspoints (__main__.TestNetworkManager) ... ** > libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: assertion > failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS) > Bail out! libnm:ERROR:libnm/nm-client.c:2863:_dbus_handle_obj_changed_dbus: > assertion failed: (dbobj->obj_state >= NML_DBUS_OBJ_STATE_ON_DBUS) > ERROR This is almost surely not a bug in NM itself, but that the current dbusmock does not properly emulate the new NM 1.29.90. Reassigning, I'll take a look. Martin
Bug#930005: regina-rexx: rexxutil error
On Sun, 16 Jun 2019 23:26:45 +0200 Andreas Beckmann wrote:
> Followup-For: Bug #930005
> Control: tag -1 patch
>
> The attached patch fixes the linking issue and thus the missing tgetent
> symbol. Thereafter the command
> regina /usr/share/doc/regina-rexx/examples/regutil.rexx
> works on i386, but segfaults on amd64.
Hi all,
I have been looking into this package. Seems the amd64 segfault
disappears when we make sure termcap.h is loaded from the right
regutils file. I am attaching two additional patches for
debian/patches, one sets HAVE_TGETENT and the other makes sure
termcap.h is loaded if so.
Alen, I plan to upload a NMU with this changes and may be some minor
issues. Even if I have not written rexx for years I think it would be
a pity to have this package with this open bug.
Also, one issue with this package is that Debian build system is
ancient, even pre-debhelper. This makes everything a nightmare. I have
been playing with a migration to traditional (no dh sequencer)
debhelper. This should fix another bug report about build
reproduciibility. I am aware that this is a rather invasive change,
but I think is required to make contributors life easier, let me know
your POV.
Other thing I noticed is that this package has no repo under salsa. I
can prepare a git repo with regina history and put it under
salsa/debian group. Alen, please tell me if you object to this, I
consider it important and will proceed unless you object explicitly.
By the way, upstream is active and there are new versions available,
although I will focus on current upstream version in Debian.
Regards,
--
Agustin
Index: regina-rexx/regutil/regscreenux.c
===
--- regina-rexx.orig/regutil/regscreenux.c 2021-02-12 00:18:07.362794088 +0100
+++ regina-rexx/regutil/regscreenux.c 2021-02-12 00:22:30.733931644 +0100
@@ -34,6 +34,10 @@
# include
#endif
+#ifdef HAVE_TGETENT
+# include
+#endif
+
#if 0
#ifdef USE_TERMCAP_DB
# ifdef HAVE_TERM_H
Index: regina-rexx/configure.in
===
--- regina-rexx.orig/configure.in 2021-02-11 23:35:03.688015418 +0100
+++ regina-rexx/configure.in 2021-02-11 23:35:03.684015371 +0100
@@ -248,6 +248,9 @@
if test "$REGUTIL_TERM_LIB" = "none required" -o "$REGUTIL_TERM_LIB" = "no"; then
REGUTIL_TERM_LIB=""
fi
+if test "x$REGUTIL_TERM_LIB" != "x"; then
+AC_DEFINE([HAVE_TGETENT],[1],[Define if tgetent exist])
+fi
LIBS="$save_LIBS"
AC_SUBST(REGUTIL_TERM_LIB)
Index: regina-rexx/configure
===
--- regina-rexx.orig/configure 2021-02-11 23:35:02.932006415 +0100
+++ regina-rexx/configure 2021-02-11 23:35:36.260403347 +0100
@@ -5259,8 +5259,14 @@
if test "$REGUTIL_TERM_LIB" = "none required" -o "$REGUTIL_TERM_LIB" = "no"; then
REGUTIL_TERM_LIB=""
fi
+if test "x$REGUTIL_TERM_LIB" != "x"; then
+
+$as_echo "#define HAVE_TGETENT 1" >>confdefs.h
+
+fi
LIBS="$save_LIBS"
+
save_LIBS="$LIBS"
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing crypt" >&5
$as_echo_n "checking for library containing crypt... " >&6; }
Bug#980792: Cannot decrypt encrypted root at boot with cryptsetup-initramfs 2:2.3.4-2~bpo10+1 (buster-backports)
Package: cryptsetup-initramfs
Version: 2:2.3.4-1~bpo10+1
Severity: grave
Justification: renders package unusable
apt upgrade installed cryptsetup-initramfs 2:2.3.4-2~bpo10+1 over
2:2.3.4-1~bpo10+1 despite the fact that initramfs-tools stayed at 0.133+deb10u1
(no newer version available in buster or buster-backports).
apt-cache cryptsetup-initramfs
(for version 2:2.3.4-2~bpo10+1) says it depends on "initramfs-tools (>= 0.137)
| linux-initramfs-tool", while the changelog says it "now requires initramfs-
tools 0.137 or later and no longer copies libgcc_s.so.1 to the initrd since
recent initramfs-tools take care of it".
After the upgrade, booting with a newly created initrd doesn't allow to unlock
the encrypted root any more ("wrong password or unknown parameter").
Fortunately, the cryptsetup-initramfs' install script re-creates only the
current kernel's initrd, so that booting from an older kernel allowed me to get
into the system and to revert cryptsetup and cryptsetup-initramfs to
2:2.3.4-1~bpo10+1 which solved the problem.
-- Package-specific info:
-- System Information:
Debian Release: 10.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.8-surface (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_CRAP,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_BE.UTF-8, LC_CTYPE=de_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_BE:de (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cryptsetup-initramfs depends on:
ii busybox 1:1.30.1-4
ii cryptsetup 2:2.3.4-1~bpo10+1
ii debconf [debconf-2.0] 1.5.71
ii initramfs-tools [linux-initramfs-tool] 0.133+deb10u1
Versions of packages cryptsetup-initramfs recommends:
ii console-setup 1.193~deb10u1
ii kbd2.0.4-4
cryptsetup-initramfs suggests no packages.
-- debconf information:
cryptsetup-initramfs/prerm_active_mappings: true
Bug#980291: [Pkg-javascript-devel] Bug#980291: Bug#980291: Bug#980291: Bug#980294: libjs-jquery-flot: breaking API change
On 2021-01-19 14:15, Pirate Praveen wrote: > It is not about breaking as such, but breaking without coordination and > planning that is the problem. We have a release team and transition process > for a reason. I don't think uploading breaking changes without giving > adequate notice and warning is OK. Well, I did the upload that caused the breakage, but I (shortly) before freeze. I coordinated with the regular uploader explicitely before uploading, but it would have been much better to talk to the team, which I will do next time! Anyway, Antonio and Xavier hopefully fixed the API breakage. Thanks to both!
Bug#980291: Bug#980294: libjs-jquery-flot: breaking API change
On 2021-01-18 14:28, Antonio Terceiro wrote: > In special, I need to stop including the standalone plugin files, > because it's already included in the main file. This wasn't the case in > the previous version, and I get that this is how upstream designed it to > be. Pretty "hacky" idea: How about leaving the main file as intended by upstream, i.e. with all plugins included, and replace the the plugin files with dummies? Or am I misunderstanding the issue?
Bug#979575: ispell 3.4.01 breaks affix files of igerman98 and hkgerman
reassign 979694 ispell 3.4.01-1 reassign 979746 ispell 3.4.01-1 forcemerge 979575 979694 979746 affects 979575 ispanish thanks El dom, 10 ene 2021 a las 23:02, Agustin Martin () escribió: > > El dom, 10 ene 2021 a las 22:39, Robert Luberda () > escribió: > > > > reassign 979549 ispell 3.4.01-1 > > reassign 979565 ispell 3.4.01-1 > > forcemerge 979575 979549 979565 > > affects 979575 ingerman iogerman ifrench iesperanto iswiss > > tags 979575 pending fixed-upstream > > thanks > > > > > > Roland Rosenfeld pisze: > > > > > > In the meantime upstream maintainer released a version 3.4.02 on > > > > Yes, I've noticed it this morning, and it looks like upgrading to that > > version fixes the issue. > > This may also be causing #979694. Confirmed, ispell 3.4.02 fixes this problem. Reassigning and forcemerging #979575 and #979746 with this bug report, so everything is marked as fixed. Regards, -- Agustin
Bug#979575: ispell 3.4.01 breaks affix files of igerman98 and hkgerman
El dom, 10 ene 2021 a las 22:39, Robert Luberda () escribió: > > reassign 979549 ispell 3.4.01-1 > reassign 979565 ispell 3.4.01-1 > forcemerge 979575 979549 979565 > affects 979575 ingerman iogerman ifrench iesperanto iswiss > tags 979575 pending fixed-upstream > thanks > > > Roland Rosenfeld pisze: > > > > In the meantime upstream maintainer released a version 3.4.02 on > > Yes, I've noticed it this morning, and it looks like upgrading to that > version fixes the issue. This may also be causing #979694. Regards,
Bug#979329: fastboot: Undeclared dependency on android-libunwind
Package: fastboot Version: 1:10.0.0+r36-3 Severity: grave Justification: renders package unusable $ fastboot fastboot: error while loading shared libraries: lib7z.so: cannot open shared object file: No such file or directory This file is provided only by package android-libunwind, but fastboot doesn't declare a dependency on that.
Bug#974608: gthumb uses internal libexiv2 functions to get the user comment
Package: gthumb Version: 3:3.8.3-0.1 Followup-For: Bug #974608 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Fixed upstream 1 hour ago: https://gitlab.gnome.org/GNOME/gthumb/-/commit/3bdb4f94ba37b410ac07c25b5c83e587b55482fd See also: https://gitlab.gnome.org/GNOME/gthumb/-/issues/137 https://gitlab.gnome.org/GNOME/gthumb/-/issues/30 I haven't checked whether this can be backported to the 3.8.3 branch. Upgrading the Debian package to 3.11.1 might make more sense. - -- System Information: Debian Release: 10.7 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores) Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi_FI.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gthumb depends on: ii gsettings-desktop-schemas 3.28.1-1 ii gthumb-data 3:3.8.3-0.1 ii libbrasero-media3-1 3.12.2-5 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libclutter-1.0-01.26.2+dfsg-10 ii libclutter-gtk-1.0-01.8.4-4 ii libexiv2-14 0.25-4+deb10u1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgl1-mesa-dri 18.3.6-2+deb10u1 ii libglib2.0-02.58.3-2+deb10u2 ii libgstreamer-plugins-base1.0-0 1.14.4-2 ii libgstreamer1.0-0 1.14.4-1 ii libgtk-3-0 3.24.5-1 ii libjpeg62-turbo 1:1.5.2-2+deb10u1 ii libjson-glib-1.0-0 1.4.4-2 ii liblcms2-2 2.9-3 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpng16-16 1.6.36-6 ii libraw190.19.2-2 ii librsvg2-2 2.44.10-2.1 ii libsecret-1-0 0.18.7-1 ii libsoup2.4-12.64.2-2 ii libstdc++6 8.3.0-6 ii libtiff54.1.0+git191117-2~deb10u1 ii libwebkit2gtk-4.0-372.30.4-1~deb10u1 ii libwebp60.6.1-2 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gthumb recommends: ii libgphoto2-6 2.5.22-3 ii libgphoto2-port12 2.5.22-3 gthumb suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAl/txdoACgkQrh+Cd8S0 17Z/Fg/+LtN/1HlY196Ud3lZKaZCbb4py9hYszATImYcOtY8/kzxWhMJXYPLEkEj WiiN2TxzWgXNTJWc8GLIUDC/bFI3ePculd5nn9c1kiVxP4+2lLXANxnwGUJS0mLb ssbNSO5asysFWYtV17b30qU6Nfc6FPmnbSbhpz24OfrKytRw/w+trtJCkv/6g18c PcVD8N050uXaJX7+cwyzZ1kjXyEcAzL7uCuNPlu8O9kZcTm7+7cMD4nufBLtNW4a cOC0/UigG/0L+hD//8sBq8FXdLrUvqStp1mffeGLy0k7yDFf9LMVO4kQmwLI6edQ s7SFagRj23pUn7Ibvp3EQUgFfDe7IPujsFVsNLCpir/IVRQBoTUbhHPopKsGaJkJ KddKqxT0DZ40yJVveDAN7EaIKSkSzoWJJ4F40vjYvMnW6XO+ZRIaOsbWgGaOVPdh HBxga3g/8X0xzlhkenStqnxliyTjvHzAa0H7e0Ka610/9Kc/6GmMc1QpEDmYuCbM jmmki3I3JWG5P6t+bo+8kMRhTr2wwohrL51kIctP6UqcN2YZphHLvjH+O736Q4IP WqFNJxb4ntiPbVi6ETLlRo/vjbNynIE70TEp6QVWPn4j9kpsR/jKlX9ElnILQfqd jBrTNMl15PDTahJZ01kmNAT5ZCygs9SKaOK0U02p50yjz6MO+qE= =fi0x -END PGP SIGNATURE-
Bug#978310: umockdev: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1
Control: tag -1 fixed-upstream pending Control: forwarded -1 https://github.com/martinpitt/umockdev/issues/115 Hello Lucas, Lucas Nussbaum [2020-12-26 22:57 +0100]: > > Bail out! ERROR:../tests/test-umockdev.c:1135:t_testbed_usb_lsusb: > > assertion failed (exit_status == 0): (256 == 0) I noticed that a few days as well, and someone else also noticed in https://github.com/martinpitt/umockdev/issues/115 The fix is already upstream, I'll do a new release ASAP. Thanks for your report and your continous rebuild efforts! These are much appreciated. Martin
Bug#959905: Any update?
Hi Alexandre, Any update on this bug? It's stopping the migration to testing and it would be nice to have this tool in the next stable release of Debian. Thanks! -- Martin Michlmayr https://www.cyrius.com/
Bug#921257:
Hi, Is it possible to update the version of khal that is being built here? One of the failures in the latest build log was fixed in 0.10.2 and I'm not sure about the other, and there's currently no version in testing. Thanks!
Bug#975020: version mismatch between package and manifest.json
Package: webext-dav4tbsync Version: 1.21-1 Severity: grave Justification: makes the package in question unusable by most or all users Dear Mechthilde, many thanks for maintaining the tbsync packages! Very much appreciated, especially the support of Debian 10 (buster). The zip file dav4tbs...@jobisoft.de.xpi contains a manifest.json with the following lines: "strict_min_version": "68.0", "strict_max_version": "69.*" ... "version": "1.8", I assume, that this is wrong. Upstream git 1.21 shows instead: "strict_min_version": "78.0", "strict_max_version": "78.*" ... "version": "1.21", In consequence, the plugin shows as "disabled" in Thunderbird and with version 1.8 instead of 1.21. I hope, I got all facts correct. Cheers!
Bug#961152: apt-show-versions: diff for NMU version 0.22.11+nmu1
Thanks for you work. I have just release 0.23 which includes your patch. Am 08.11.20 um 18:26 schrieb Dominic Hargreaves: > Control: tags 961152 + patch > Control: tags 961152 + pending > > Dear maintainer, > > I've prepared an NMU for apt-show-versions (versioned as 0.22.11+nmu1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. > > Regards. >
Bug#973403: softether-common: hamcore.se2 broken
Package: softether-common Version: 5.01.9674+git20200806+8181039+dfsg-2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: debian-b...@fhloston.org Dear Maintainer, neither softether-vpnserver nor softether-vpnbridge actually starts. Following error is reported: Oct 27 21:20:25 iceborg vpnbridge[1677]: -- Alert: SoftEther VPN Kernel -- Oct 27 21:20:25 iceborg vpnbridge[1677]: Fatal Error: The file "hamcore.se2" is missing or broken. Oct 27 21:20:25 iceborg vpnbridge[1677]: Please check hamcore.se2. Oct 27 21:20:25 iceborg vpnbridge[1677]: #015 It seems the hamcore.se2 file provided by softether-common is too small/contains only the authors. -rw-r--r-- 1 root root 1832 Oct 19 14:14 /usr/share/softether-common/hamcore.se2 Thank you for providing softether as a debian package! Martin -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386
Bug#973010: pcp is uninstallable on many architectures due to new bpftrace dependency
Package: pcp
Version: 5.2.1-1
Severity: serious
Tags: patch
The recent 5.2.1-1 upload made a dependency change to pcp:
Package: pcp
-Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, libpcp-pmda-perl,
python3-pcp, python3, libpcp-web1
+Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, libpcp-pmda-perl,
python3-pcp, python3, bpftrace (>= 0.9.2), libpcp-web1
But the "bpftrace" package only exists on a few architectures [1]. This is what
makes the package uninstallable and prevents testing migration [2].
Please fix
that at least by restricting the architectures, like so:
Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, libpcp-pmda-perl,
python3-pcp, python3, bpftrace (>= 0.9.2) [amd64 arm64 ppc64 ppc64el],
libpcp-web1
Preferably you would also drop it to Recommends:, as hopefully bpftrace isn't
an absolute requirement for running PCP? I.e.
Depends: ${shlibs:Depends}, ${misc:Depends}, gawk, procps, libpcp-pmda-perl,
python3-pcp, python3, libpcp-web1
Recommends: bpftrace (>= 0.9.2)
Thanks!
Martin
[1] https://packages.debian.org/sid/bpftrace
[2] https://tracker.debian.org/pkg/pcp
signature.asc
Description: PGP signature
Bug#969804: Bug#969804: bart: autopkgtest should be marked superficial
Am Montag, den 21.09.2020, 17:57 +0200 schrieb Andreas Tille: > On Mon, Sep 21, 2020 at 05:30:20PM +0200, Andreas Tille wrote: > > > > May be I misunderstood you - but if you do not run the test at all > > (as done in some architectures) how will you know whether the test > > might fail? May be I miss your point here and thus I implemented > > my suggestion and we'll see what happends on the buildd logs soon. Thank you! No, I meant running the tests but ignoring the results, so exactly what you implemented! > For instance > > > https://buildd.debian.org/status/fetch.php?pkg=bart=i386=0.6.00-3=1600702554 > =0 > > has > > ... > ./test_linop_matrix > ./test_linop_matrix: 4/ 4 passed. > ./test_linop > [31mERROR: ./test_linop: 2/ 3 passed. > [0mmake[3]: *** [Makefile:685: utests-all] Error 1 > make[3]: Leaving directory '/<>' > make[2]: *** [Makefile:273: utest] Error 2 > > > --> I guess access to i386 should be simple. You can either use > qemu or may be the issue can be even reproduced in an i386 > pbuilder chroot Yes, I think this is a problem I looked at before. Essentially the floating point computation has a bigger error for some reason. But I did not have to time to get on the bottom of it. What would be really useful is to get bug reports for failing tests which are not critical. > > The s390x build > > > https://buildd.debian.org/status/fetch.php?pkg=bart=s390x=0.6.00-3=1600702311 > aw=0 > > has the know issue. > > So at least the logs do not hide the issues that might be worth > investigating or not. Yes, this is useful. I will try to change the tests so that a failing test outputs more information. Best, Martin
Bug#969804: Bug#969804: bart: autopkgtest should be marked superficial
Hi Andreas, Am Montag, den 21.09.2020, 09:45 +0200 schrieb Andreas Tille: > Hi Martin, > > On Sat, Sep 19, 2020 at 05:50:34PM +, Uecker, Martin wrote: > > > I'm not sure whether this is a good idea in general. If > > > we can be sure that for s390x there is an issue with the > > > tool chain I could imagine something like: > > > > > > if build on s390x > > > run_test || true # FIXME: explanation why we ignore test > > > else > > > run_test > > > > > > I do not think that ignoring the tests on all architectures > > > is a good idea. > > > > Without any way to investigate it is difficult > > to be sure. > > > > But we run very comprehensive tests upstream. > > I'm pretty sure about this and I appreciate the effort you are doing so. > > > So it is > > actually very likely that all problems we can catch in > > Debian (and not already earlier) are problems > > with the tool chain on some architecture. > > To the best of my knowledge the fact that a test runs on amd64 but fails > on some other architecture is not only caused by issues in the tool > chain. For instance recently I learned that for instance if char is > used as "very short int" it matters whether it is declared as char, > signed char or unsigned char. I know, this is also why I originally thought it would be a good idea. > To spot this kind of issues it makes > perfectly sense to run the test suite on all architectures - except > for those where we expicitly know that a broken tool chain is breaking > the build. If there were an easy way to log into a s390x machine and debug the problem, the outcome would likely be a useful bug report against GCC which would be useful to the community and the s390x port. But as things are, it only causes unnecessary work for us to not get the package removed while we learned nothing about the underlying issue. > Thus my suggestion to exclude only the affected s390x from the test. > If my suggestion is not worded clearly enough feel free to ping me and > I implement my suggestion in d/rules to show what I mean. Well, the idea would be to do exactly this but pro-actively for all architectures except amd64. We would still get the information when tests fail (which is useful) but avoid wasting effort on fixing it each time. Best, Martin > Kind regards and thanks for working on bart > > Andreas. > >
Bug#969804: Bug#969804: bart: autopkgtest should be marked superficial
Am Samstag, den 19.09.2020, 17:09 +0200 schrieb Andreas Tille: > Hi Martin, > > On Sat, Sep 19, 2020 at 01:15:47PM +, Uecker, Martin wrote: > > > The severity on this bug can be downgraded, however the FTBFS on s390x > > > remains a release critical bug, since s390x is a release architecture. > > > > > > Either the FTBFS gets fixed, or removal of the s390x binaries can be > > > requested. > > > > I wonder whether we should simply turn off all tests on > > non-x86-64 architectures. > > > > These usually turn up issues with the toolchain which > > then cause additional work for me although the bug is > > elsewhere. > > I'm not sure whether this is a good idea in general. If > we can be sure that for s390x there is an issue with the > tool chain I could imagine something like: > > if build on s390x > run_test || true # FIXME: explanation why we ignore test > else > run_test > > I do not think that ignoring the tests on all architectures > is a good idea. Without any way to investigate it is difficult to be sure. But we run very comprehensive tests upstream. So it is actually very likely that all problems we can catch in Debian (and not already earlier) are problems with the tool chain on some architecture. Best, Martin
Bug#969804: [Debian-med-packaging] Bug#969804: bart: autopkgtest should be marked superficial
Hi Graham, Am Samstag, den 19.09.2020, 14:04 +0200 schrieb Graham Inggs: > On Sat, 19 Sep 2020 at 13:51, Uecker, Martin > wrote: > > Could severity be downgraded? > > The severity on this bug can be downgraded, however the FTBFS on s390x > remains a release critical bug, since s390x is a release architecture. > > Either the FTBFS gets fixed, or removal of the s390x binaries can be > requested. I wonder whether we should simply turn off all tests on non-x86-64 architectures. These usually turn up issues with the toolchain which then cause additional work for me although the bug is elsewhere. Best, Martin
Bug#969804: bart: autopkgtest should be marked superficial
Could severity be downgraded? (The build on s390x seems to use a newer compiler. The failure may be a compiler bug, but similar to the RISC-V bug I can't investigate as I never got access to porter boxes.) On Thu, 17 Sep 2020 15:05:16 +0200 Andreas Tille wrote: > Control: tags -1 normal > > On Thu, Sep 17, 2020 at 01:40:29PM +0200, Paul Gevers wrote: > > The thread starts here: > > https://lists.debian.org/debian-devel/2020/09/msg00071.html > > > > mostly follow-ups from here on: > > https://lists.debian.org/debian-devel/2020/09/msg00219.html > > Thanks for the pointers and as I'd love to repeat for all your > work on this > Andreas. > > -- > http://fam-tille.de > >
Bug#969171: akonadi-server expects akonadi-backend-mysql allthough any sql backend should work
severity 969171 normal thanks Dear Eric. Akonadi will use whatever database is set in the configuration file, by default on first startup MySQL if the MySQL backend has been installed at first startup. So if you use it with an existing home directory that has MySQL specified as database backend it needs the MySQL database backend of Akonadi to operate with the existing configuration. See the file: '~/.config/akonadi/akonadiserverrc'. This can happen as easily as starting once with the MySQL backend installed, as Plasma starts Akonadi automatically in its default configuration. Then you have an empty MariaDB based Akonadi. If you then switch to PostgreSQL this error occurs. Please ask on debian-kde and/or upstream kdepim-users mailing list for support. The Debian bug tracker is not for user support questions. Also review previous threads on this topic there. Note that on switching the database Akonadi will start anew and some information only stored in the database will be lost. I think it is not a bug of the package. But it is definitely not severity grave as Akonadi is perfectly usable here in exact the same version (usable to the extent Akonadi works reliable, but that is an upstream issue). So downgrading severity to normal. I have seen repeatedly seen that you set too high bug severity. If the package does not work for me does not mean that its automatically grave severity. Especially when it is, as I assume, a configuration error. So please refrain from setting grave when it isn't. It just causes additional work for the already overloaded Debian Qt/KDE team. If you are unsure please ask first in debian-kde mailing list. That is part of what it is there for. Best, -- Martin
Bug#936146: archivemail - Python 3 porting
Hi! I used this frequently enough to be hesitant to let apt dist-upgrade remove it on my system currently. But I understand it may not make sense to port it as its hard and upstream is not active anymore. Is there an alternative in Debian repository? Best, -- Martin
Bug#965001: strange version 2.1.0 beta4 fails tests with mpfr4 4.1.0
On Thu, Jul 30, 2020, 6:48 AM Case Van Horsen wrote: > I will update the test suite today. (The offending test will be > removed from test_gmpy2_format.txt and moved to test_mpfr40_format.txt > and test_mpfr41_format.txt with the appropriate version chosen.) > > Will this release move to MPC 1.2.0? > > Case > Thanks Case! Matthias, Vincent, would one of you be willing to do a non-maintainer upload once Case releases the new version? I would like to but won't have computer access until October. > On Thu, Jul 30, 2020 at 6:36 AM Martin Kelly > wrote: > > > > On Thu, Jul 30, 2020, 5:34 AM Matthias Klose wrote: > >> > >> On 7/30/20 3:42 AM, Martin Kelly wrote: > >> > Apparently this bug is going to cause autoremoval from testing soon. > Is the > >> > severity really high enough for that? > >> > >> yes, because it blocks migration of mpfr4, used by our GCC packages. > I'm > >> certainly biased, however I'd like to see the new mpfr4 in use now, > even if it > >> means removing a bindings package from testing. > > > > > > Case Van Horsen (upstream maintainer), is there anything we can do here > to fix the tests? I can look at this in October, but the package will be > removed from testing at that point. I'm not sure when the package freeze > will be, but I certainly don't want to miss the next release. > > > > > > >
Bug#965001: strange version 2.1.0 beta4 fails tests with mpfr4 4.1.0
On Thu, Jul 30, 2020, 5:34 AM Matthias Klose wrote: > On 7/30/20 3:42 AM, Martin Kelly wrote: > > Apparently this bug is going to cause autoremoval from testing soon. Is > the > > severity really high enough for that? > > yes, because it blocks migration of mpfr4, used by our GCC packages. I'm > certainly biased, however I'd like to see the new mpfr4 in use now, even > if it > means removing a bindings package from testing. > Case Van Horsen (upstream maintainer), is there anything we can do here to fix the tests? I can look at this in October, but the package will be removed from testing at that point. I'm not sure when the package freeze will be, but I certainly don't want to miss the next release.
Bug#965001: strange version 2.1.0 beta4 fails tests with mpfr4 4.1.0
On Wed, Jul 15, 2020, 4:27 PM Martin Kelly wrote:
> On Tue, Jul 14, 2020, 3:15 AM Vincent Lefevre wrote:
>
>> On 2020-07-14 09:48:18 +0200, Matthias Klose wrote:
>> > There is no 2.1.0 beta4, just a beta1, so I don't know what was
>> packaged in
>> > February 2020. However the tests now fail with mpfr 4.1.0, seems to be
>> > consistent across all architectures:
>> >
>> > **
>> > File "test/test_gmpy2_format.txt", line 157, in test_gmpy2_format.txt
>> > Failed example:
>> > c.__format__('e')
>> > Differences (ndiff with -expected +actual):
>> > - '3.3331e-01+5e+00j'
>> > + '3.3331e-01+5.e+00j'
>> > ? +
>>
>> FYI, the old MPFR behavior was regarded as a bug:
>>
>>
>> https://gforge.inria.fr/tracker/index.php?func=detail=21816_id=136=619
>>
>> There were 2 reasonable interpretations of the description in the
>> MPFR manual that did not leave the output partly unspecified, and
>> for each of them, some outputs were incorrect. The one that has
>> been chosen is the one that is closer to ISO C's %e and it does
>> not change the numerical output value (the only difference is
>> trailing zeros).
>>
>> --
>> Vincent Lefèvre - Web: <https://www.vinc17.net/>
>> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
>> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>>
>
> Hi all,
>
> Thanks for the bug report. Unfortunately I'm on a long hiking vacation
> with no computer access until October and won't be able to look at this
> until then. I welcome a non-maintainer upload if this needs a fix sooner.
>
> I'm also CCing the upstream maintainer, who may have an opinion on that to
> do here.
>
The beta4 version is this one:
https://github.com/aleaxit/gmpy/releases/tag/gmpy2-2.1.0b4
It looks like it may be a tag but not a release? In any case, I assume
that's what I packaged (I can't check as I don't have computer access right
now, just phone).
Apparently this bug is going to cause autoremoval from testing soon. Is the
severity really high enough for that?
Again, I'd like to take a closer look at this but am away from a computer
until October on an extended trip
>
Bug#966501: 2.0.3 REST API regression: Failed to parse parameters for /v1.12/libpod/events: unexpected end of JSON input
Package: podman Version: 2.0.3+dfsg1-1 Severity: serious Tags: upsteam fixed-upstream Version 2.0.3 breaks the REST API really hard, which breaks cockpit-podman and any other API user. This is tracked here: https://github.com/containers/podman/issues/7078 This has been fixed upstream and will be in 2.0.4. I'd like to block this version from testing to avoid the regression. If you disagree and would rather get this in ASAP (given how young the package is still), I'm fine with that as well, and disable the cockpit-podman test on debian-testing for a while. Thanks, Martin
Bug#962276: (no subject)
Possibly related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961206 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961741
Bug#965001: strange version 2.1.0 beta4 fails tests with mpfr4 4.1.0
On Tue, Jul 14, 2020, 3:15 AM Vincent Lefevre wrote:
> On 2020-07-14 09:48:18 +0200, Matthias Klose wrote:
> > There is no 2.1.0 beta4, just a beta1, so I don't know what was packaged
> in
> > February 2020. However the tests now fail with mpfr 4.1.0, seems to be
> > consistent across all architectures:
> >
> > **
> > File "test/test_gmpy2_format.txt", line 157, in test_gmpy2_format.txt
> > Failed example:
> > c.__format__('e')
> > Differences (ndiff with -expected +actual):
> > - '3.3331e-01+5e+00j'
> > + '3.3331e-01+5.e+00j'
> > ? +
>
> FYI, the old MPFR behavior was regarded as a bug:
>
>
> https://gforge.inria.fr/tracker/index.php?func=detail=21816_id=136=619
>
> There were 2 reasonable interpretations of the description in the
> MPFR manual that did not leave the output partly unspecified, and
> for each of them, some outputs were incorrect. The one that has
> been chosen is the one that is closer to ISO C's %e and it does
> not change the numerical output value (the only difference is
> trailing zeros).
>
> --
> Vincent Lefèvre - Web:
Bug#964678: dictionaries-common: FTBFS: Can't locate TheWML/Backends/Slice/Main.pm in @INC
control: reassign -1 slice control: found -1 2.28.0~ds1-1 control: retitle -1 wml/slice must depend on wml package El jue., 9 jul. 2020 a las 13:36, Lucas Nussbaum () escribió: > > Source: dictionaries-common > Version: 1.28.1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200709 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This seems due to new slice package built from wml missing a dependency on wml. Reassigning > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > slice -oUNDEF+I+IW+IA-A-H-W-AH:scripts/maintainer/config-ispell > > scripts/maintainer/config.in > > Can't locate TheWML/Backends/Slice/Main.pm in @INC (you may need to install > > the TheWML::Backends::Slice::Main module) (@INC contains: /usr/share/wml > > /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 > > /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 > > /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base > > /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 > > /usr/local/lib/site_perl) at /usr/bin/slice line 10. > > BEGIN failed--compilation aborted at /usr/bin/slice line 10. > > make[1]: *** [Makefile:147: scripts/maintainer/config-ispell] Error 2 > > The full build log is available from: > > http://qa-logs.debian.net/2020/07/09/dictionaries-common_1.28.1_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures.
Bug#964334: segfault repeatedly
Package: chromium Version: 83.0.4103.116-2 Followup-For: Bug #964334 Dear Maintainer, seeing the same issue in chromium 83.0.4103.116-2, keeps crashing after a few minutes of use. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964362 is a dup of this one, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963548 *may* be, but that one also mentions tab crashes (as opposed to browser crashes) In 83.0.4103.116-1~deb10u2 I get both tab crashes (consistently when opening google chat) and browser crashes. In 83.0.4103.116-2 I only get browser crashes... [30759:30759:0707/165049.768521:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process. [30720:30840:0707/165050.050567:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [30720:30840:0707/165050.054057:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [30720:30840:0707/165050.054430:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files libpng warning: iCCP: known incorrect sRGB profile Received signal 11 SEGV_MAPERR 7f01bc2be677 #0 0x563a76110c69 (/usr/lib/chromium/chromium+0x52b3c68) #1 0x563a7606fef3 (/usr/lib/chromium/chromium+0x5212ef2) #2 0x563a761107f1 (/usr/lib/chromium/chromium+0x52b37f0) #3 0x7f62e4052110 (/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f) #4 0x7f62df13dd3c (/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b) #5 0x7f62df13ff33 (/lib/x86_64-linux-gnu/libc-2.30.so+0x87f32) #6 0x7f62df141bf9 __libc_malloc #7 0x563a761289be operator new() #8 0x7f62df3c8a2c std::__cxx11::basic_string<>::reserve() #9 0x7f62df3be498 std::__cxx11::basic_stringbuf<>::overflow() #10 0x7f62df3c704a std::basic_streambuf<>::xsputn() #11 0x7f62df3b9714 std::__ostream_insert<>() #12 0x563a76110d39 (/usr/lib/chromium/chromium+0x52b3d38) #13 0x563a76111054 (/usr/lib/chromium/chromium+0x52b4053) #14 0x563a76082412 (/usr/lib/chromium/chromium+0x5225411) #15 0x563a76084548 (/usr/lib/chromium/chromium+0x5227547) #16 0x563a747ca12a (/usr/lib/chromium/chromium+0x396d129) #17 0x563a747ca17e (/usr/lib/chromium/chromium+0x396d17d) #18 0x563a73e1f387 (/usr/lib/chromium/chromium+0x2fc2386) #19 0x563a747833d9 (/usr/lib/chromium/chromium+0x39263d8) #20 0x563a7478361e (/usr/lib/chromium/chromium+0x392661d) #21 0x563a747cd967 (/usr/lib/chromium/chromium+0x3970966) #22 0x563a747f94c7 (/usr/lib/chromium/chromium+0x399c4c6) #23 0x563a747f977e (/usr/lib/chromium/chromium+0x399c77d) #24 0x563a747ca13f (/usr/lib/chromium/chromium+0x396d13e) #25 0x563a747ca17e (/usr/lib/chromium/chromium+0x396d17d) #26 0x563a73e1f387 (/usr/lib/chromium/chromium+0x2fc2386) #27 0x563a740e27a3 (/usr/lib/chromium/chromium+0x32857a2) #28 0x563a744510bc (/usr/lib/chromium/chromium+0x35f40bb) #29 0x563a7624245f (/usr/lib/chromium/chromium+0x53e545e) #30 0x563a76248a24 (/usr/lib/chromium/chromium+0x53eba23) #31 0x563a76246b62 (/usr/lib/chromium/chromium+0x53e9b61) #32 0x563a7624582d (/usr/lib/chromium/chromium+0x53e882c) #33 0x563a7623e213 (/usr/lib/chromium/chromium+0x53e1212) #34 0x563a76259abb (/usr/lib/chromium/chromium+0x53fcaba) #35 0x563a76259de0 (/usr/lib/chromium/chromium+0x53fcddf) #36 0x563a76259370 (/usr/lib/chromium/chromium+0x53fc36f) #37 0x563a740cbc46 (/usr/lib/chromium/chromium+0x326ec45) #38 0x563a740cb76c (/usr/lib/chromium/chromium+0x326e76b) #39 0x563a740c7eed (/usr/lib/chromium/chromium+0x326aeec) #40 0x563a740be74b (/usr/lib/chromium/chromium+0x326174a) #41 0x563a740b1044 (/usr/lib/chromium/chromium+0x3254043) #42 0x563a740b0d75 (/usr/lib/chromium/chromium+0x3253d74) #43 0x563a740cf426 (/usr/lib/chromium/chromium+0x3272425) #44 0x563a7612e0e0 (/usr/lib/chromium/chromium+0x52d10df) #45 0x7f62e2e07b0f (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7.0.0+0x23b0e) #46 0x7f62e2e0824f event_base_loop #47 0x563a7612e38e (/usr/lib/chromium/chromium+0x52d138d) #48 0x563a760ce5d5 (/usr/lib/chromium/chromium+0x52715d4) #49 0x563a760a6670 (/usr/lib/chromium/chromium+0x524966f) #50 0x563a743ec3b3 (/usr/lib/chromium/chromium+0x358f3b2) #51 0x563a760e42a9 (/usr/lib/chromium/chromium+0x52872a8) #52 0x563a76120c9e (/usr/lib/chromium/chromium+0x52c3c9d) #53 0x7f62e4046f27 start_thread #54 0x7f62df1b531f clone r8: 0077 r9: 0050 r10: 0004 r11: 007c r12: 7f62bc20 r13: 7f62bc30 r14: 7f62bc206850 r15: 0040 di: 0261 si: 0004 bp: 0260 bx: 7f01bc2be66f dx:
Bug#964120: not compatible with current Gajim, no more upstream support
Package: gajim-rostertweaks Version: 1.1.0-1 Severity: grave This package just needs to be removed.
Bug#962703: mailplate: Should we remove this package from Debian?
Thank you for your efforts! Removal of mailplate is definitely the best option. -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#962368: frogatto-data: Source-only upload not automatically built for non-free packages
Hello, thanks for pointing me to this, I didn't know. And even now, I'm not sure of whether frogatto-data is auto-buildable. The reason why it's non-free is because the licence file states: "The Frogatto game and all content is available for download free of charge from http://www.frogatto.com. The game may be redistributed for non-commercial purposes so long as the entire package is kept in-tact and unmodified. This license must also be included and kept in-tact. It is forbidden to distribute the game, or any portion thereof for any commercial or revenue-generating purpose." Under this light, should I mark the package as auto-buildable? I tend to think so but would appreciate your guidance. In the meanwhile, I'll do a source+binary upload of the package. Thanks again, Mt. - Le 7 Juin 20, à 0:05, Boyuan Yang by...@debian.org a écrit : > Source: frogatto-data > Severity: serious > Version: 1.3.1+dfsg-2 > X-Debbugs-CC: mquin...@debian.org > > Dear Debian frogatto-data maintainers, > > Thanks for updating package frogatto-data in Debian. However, you just > made a source-only upload against a non-free package, which would cause > problems. > > By default, Debian's buildd will not build non-free packages due to > licensing concerns. If your package has no licensing concerns, please > follow instructions as written in the Developers Reference [1] to mark > the package as auto-buildable. If not, please make a binary-only upload > (or a source+binary upload) to actually make sure that the deb package > exists in the archive. > > -- > Regards, > Boyuan Yang > > [1] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable
Bug#961907: ca-certificates: Remove expired mozilla/AddTrust_External_Root.crt
This is accurate to my understanding of the situation. On Mon, Jun 1, 2020 at 11:33 AM Kurt Roeckx wrote: > Just to clarify, as I understand it, openssl 1.0.2 (so libssl1.0.2 > in oldstable) still has the problem, which means things like > libcurl in oldstable have that problem. And removing the > certificate from the trust store fixes it. > > > Kurt > >
Bug#961907: ca-certificates: Remove expired mozilla/AddTrust_External_Root.crt
On Mon, Jun 1, 2020 at 1:29 AM Axel Beckert wrote:
> > You will need to workaround this. As such this motivates critical me
> think.
>
> I think "grave" is severe enough, as it "only" breaks HTTPS including
> apt with HTTPS-based mirrors (as the one mentioned above) and hence
> only "unrelated software/packages", not the whole system (like the
> kernel or the bootloader would do if the system won't boot anymore
> after an upgrade).
>
ok.
I read the description about unrelated software a bit differently indeed.
("makes unrelated software on the system (or the whole system) break, or
causes serious data loss, or introduces a security hole on systems where
you install the package.")
> > just doing a straight up curl will hang until timeout. With the expired
> > cert disabled this is bypassaed (without curl -k).
>
> Nope. curl exits immediately for me, at least in unstable (7.68.0-1):
>
Indeed. Sorry, me being inaccurate. I was testing this on old stable.
As you noted later on as well =)
Ack, stretch is affected, too, at least with lynx and — funnily again
> — curl (7.52.1-5+deb9u10).
>
Thanks for digging further into this issue.
Bug#960892: another fix
Control: -1 fixed-upstream Thanks On Fri, May 22, 2020 at 02:35:34AM +0200, Axel Beckert wrote: > Hi Martin. > > Martin Quinson wrote: > > I gave another try to this fix, and the current git version of po4a > > manages to build aptitude even with the recent patch removed. > > > > Could you please give it a try, just to ensure that I didn't mess up > > my verification? > > Can confirm. Thanks for caring! Thanks for this test. I'm happy that this bug is gone now. I will release a new upstream version on Sunday. I'm just giving a few days to the translators to update their work since the fix introduced some strings, and since you have a temporarily fix in aptitude. Have a good one, Mt. -- Walking on water and developing software from a specification are easy if both are frozen. signature.asc Description: PGP signature
Bug#960892: another fix
Hello, I gave another try to this fix, and the current git version of po4a manages to build aptitude even with the recent patch removed. Could you please give it a try, just to ensure that I didn't mess up my verification? Thanks in advance, Mt. -- Reject: The reference on the SimGrid toolkit is outdated. -- Bastard Reviewer From Hell signature.asc Description: PGP signature
Bug#960892: po4a: --srcdir ignored by [po_directory]
Hello, your patch was included in an upstream release. The debian package should be updated shortly. Thanks for your patience, Mt. -- You have a problem and decide to use floats. Now you have 2.0001 problems. signature.asc Description: PGP signature
Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"
Control: retitle -1 FTBFS on IPv6-only hosts
Control: found -1 188-1
Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/14098
Control: tag -1 patch upstream
Hello Aurelien,
Aurelien Jarno [2020-05-16 19:27 +0200]:
> This is an IPv6 host only,
Ah! This explains the issue indeed. I'm able to reproduce this now.
To unbreak unstable users ASAP, I uploaded a binary-all build for now.
Aurelien Jarno [2020-05-17 17:04 +0200]:
> As g_network_address_parse() supports escaping addresses with [] even
> for IPv4 addresses, I guess the following *untested* patch should fix
> the issue.
>
> --- a/src/common/test-webserver.c
> +++ b/src/common/test-webserver.c
> @@ -93,7 +93,7 @@
>/* HACK: this should be "localhost", but this fails on COPR;
> https://github.com/cockpit-project/cockpit/issues/12423 */
>tc->localport = g_strdup_printf ("127.0.0.1:%d", port);
>if (str)
> -tc->hostport = g_strdup_printf ("%s:%d", str, port);
> +tc->hostport = g_strdup_printf ("[%s]:%d", str, port);
>if (inet)
> g_object_unref (inet);
>g_free (str);
Spot on, thank you! I tested this and sent an upstream PR to fix this.
Martin
Bug#960752: FTBFS on arch-all, test-suite failure - conova buildd has broken "localhost"
Michael Biebl [2020-05-16 12:39 +0200]: > Source: cockpit > Version: 219-1 > Severity: serious > > Hi Martin, > > looks like the latest release reliably triggers a FTBFS on arch-all: > > https://buildd.debian.org/status/logs.php?pkg=cockpit=219-1=all > > The relevant part from the build log > ** > cockpit-protocol:ERROR:src/common/test-webserver.c:374:perform_request: > assertion failed (error == NULL): Error resolving > ?2a02:16a8:dc41:100::238:46259?: Name or service not known > (g-resolver-error-quark, 0) > SKIP: test-webserver Bail out! > cockpit-protocol:ERROR:src/common/test-webserver.c:374:perform_request: > assertion failed (error == NULL): Error resolving > ?2a02:16a8:dc41:100::238:46259?: Name or service not known > (g-resolver-error-quark, 0) > Aborted > ERROR: test-webserver process failed: 134 Right, this seems to be an annoying mis-configuration of the new "conova" buildd. The test hasn't changed in a long time, and works fine on every other buildd, architecture, or distribution (Ubuntu, Fedora, RHEL, Arch, etc.) https://buildd.debian.org/status/logs.php?pkg=cockpit=all Buildd admins, is there something weird about conova, like it resolves "localhost" to that IPv6 address, or more likely, "localhost" cannot be resolved in NSS locally and it's trying to resolve it with that DNS server? As a stopgap I'll probably do a locally built all binary upload, but I can't do it right now. Thanks, Martin
Bug#960201: python-gmpy2: autopkgtest regression: RuntimeWarning: coroutine '' was never awaited
On 5/10/20 8:20 AM, Paul Gevers wrote: Source: python-gmpy2 Version: 2.1.0~b4-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Because your autopkgtest was part of the tests for glibc, I spotted that the autopkgtest of python-gmpy2 regressed recently. On 2020-05-01 at 19:13 we had the last successful run on arm64 in testing, the first failure was also on 2020-05-01, even earlier: at 02:08 in unstable on amd64. I copied some of the output at the bottom of this report. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-gmpy2/5338978/log.gz Thanks for the bug report. Given that no new python-gmpy2 package was uploaded on May 1, I'm guessing one of the dependencies of this package has broken, or changed in a way that broke this package. Is there a way to get a list of packages that were uploaded after the last successful test and before the first failure? +Case Van Horsten, the upstream maintainer. Case, could you take a look at the failures here? They seem to have occurred without gmpy2 changing, so some dependency is failing.
Bug#937791: Blocked on reverse dependencies
On 4/13/20 2:25 PM, Moritz Mühlenhoff wrote: On Sat, Feb 08, 2020 at 11:13:20AM -0800, Martin Kelly wrote: On Sat, 8 Feb 2020 10:55:23 -0800 Martin Kelly wrote: On 2/2/20 8:39 PM, Sandro Tosi wrote: should we remove this package then? or do you want to generate a python3-gmpy? I didn't realize, but it looks like this package actually does support Python 3. I had assumed we would let this package die when Python 2 dies, since the package is dead upstream since 2013. However, looking at the popcon stats, the original python GMPY is still much more popular than than python GMPY2 (3543 vs 443). So I think it's worth keeping this package. I'm working on converting it over now and should be able to get it done in the next few weeks. Is it possible to remove the AUTORM tag until this is done, or should we let it get deleted and upload a new python3-gmpy package after that? Looking further, it seems that with current versions of Python 3 (I tested with 3.7.3), the old GMPY 1.17 is no longer passing. When I run test3/gmpy_test.py, I'm getting: $ python3 test3/gmpy_test.py ... 8 items had failures: 1 of 4 in gmpy_test_cvr 4 of 126 in gmpy_test_cvr.__test__.user_errors 1 of 1 in gmpy_test_dec 2 of 2 in gmpy_test_mpf 2 of 60 in gmpy_test_mpf.__test__.binio 2 of 2 in gmpy_test_mpq 2 of 4 in gmpy_test_mpz 7 of 25 in gmpy_test_rnd.__test__.rand 1504 tests in 42 items. 1483 passed and 21 failed. ***Test Failed*** 21 failures. In contrast, the tests for GMPY 2 all succeed, so I think the author clearly intended for tests to fully pass. Since this hasn't been maintained for 7 or so years, I'm not too surprised. Given this, I think we should let this package be removed and consider resurrecting it in the future if people ask for it and someone will step up to maintain it. Sandro, is there anything more to do if I want to let this package be removed, or do I just wait for the auto-removal? Martin, what are you referring here to with "removed"? Removal from testing or unstable? The former happened automatically in the mean time, the latter needs a bug using "reportbug ftp.debian.org" Cheers, Moritz Thanks for clarifying; I filed a bug to remove this package from unstable, as it's dead upstream and all reverse dependencies are removed from unstable at this point: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958138
Bug#956550: src:umockdev: fails to migrate to testing for too long
Hello Paul, Paul Gevers [2020-04-12 20:35 +0200]: > As recently announced [1], the Release Team now considers packages that > are out-of-sync between testing and unstable for more than 60 days as > having a Release Critical bug in testing. Your package src:umockdev in > its current version in unstable has been trying to migrate for 60 days > [2]. Hence, I am filing this bug. Whoops, thanks for the reminder! Indeed I fixed the RC bug (https://bugs.debian.org/951114) two months ago already, but typoed the "Closes #" so that the bug stayed open. I closed it now. Martin
Bug#952426: digikam: digkam experimental not correctly instalable
On Mon, Feb 24, 2020 at 01:07:40PM +0100, Eric Valette wrote: > On 24/02/2020 12:57, Agustin Martin wrote: > > > Hi, > > > > According to https://packages.debian.org/source/experimental/hdf5 there is a > > new "libhdf5-hl-100" package in experimental. Looking into it, seems that > > libhdf5_serial_hl.so.100 has been moved there, so installing that new > > package > > should help in experimental. I still wonder what is pulling it during build. > > > Except that if you llok at the beginning of the bug report it cannot be > installed in conjunction with digikam. That why I opened this new bug. Sorry, I missed that, I may be wrong, but after a quick glance, that problem in experimental seems likely related to the hdf5 transition to the new schema, not to digikam itself. IMHO libhdf5-103 should not have been dropped in experimental. It should have instead become a transitional package depending on packages with its previous contents, those having properly versioned breaks. That would make the system work and allow dependencies to be upgraded later (although this last should not be done in experimental). This addresses your 2) and 3) points in your reply to Steve, > As other have pointed out, it works but remains > ... > 2) If I do and experimental update it start failing again, > 3) as soon as libhdf-103 hits unstable, the problem will reappear, There is still the problem of the undeclared digikam dependency on the hdf5 stuff. Regards, -- Agustin
Bug#952360: [xml/sgml-pkgs] Bug#952360: linuxdoc-tools: FTBFS: fmt_latex2e::postASP: LaTeX first run problem. Aborting ...
Control: affects 952460 -1
Control: tags -1 +pending
On Sun, Feb 23, 2020 at 02:47:12PM +0100, Lucas Nussbaum wrote:
> Source: linuxdoc-tools
> Version: 0.9.73-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > make[2]: Entering directory '/<>/doc'
> > - Building txt docs
> > /tmp/ldt.p976T7wYPZ/linuxdoc --backend=txt --filter --blanks=1 guide.sgml
> > Processing file guide.sgml
> > troff: :2261: warning [p 1, 226.0i]: can't break line
> > - Building pdf docs
> > /tmp/ldt.p976T7wYPZ/linuxdoc --backend=latex \
> > --output=pdf \
> > --pass="\usepackage{times}" guide.sgml
> > Processing file guide.sgml
> > fmt_latex2e::postASP: LaTeX first run problem. Aborting ...
> > make[2]: *** [Makefile:9: guide.pdf] Error 1
Hi, Lucas,
Thanks for pointing out this problem.
This is caused by a rearrangement in contents of texlive packages. This
results in missing "letltxmacro.sty", which triggers the error. Missing
style now lives in "texlive-latex-extra", but is required by "hyperref.sty",
a style in "texlive-latex-base" which should not, IMHO, require styles
outside "texlive-latex-base".
I have filed #952460 against texlive-latex-base to make this known to
texlive maintainers. Depending on their reply this will be fixed either in
texlive with a new relocation or in linuxdoc-tools (by means of an additional
Build-Depends on texlive-latex-extra, now has only texlive-latex-recommended).
In the meantime I am marking this bug as pending.
Regards,
--
Agustin
Bug#952426: digikam: digkam experimental not correctly instalable
On Mon, Feb 24, 2020 at 11:38:40AM +0100, Eric Valette wrote: > On 24/02/2020 10:50, Simon Frei wrote: > > > The error message you quote refers to so-version 100, while the required > > one is 103. That suggests you aren't running the digikam binary from the > > package, but something else (maybe you self-compiled at some point?). > > Check the output of which digikam. > > Did you just test your packages before uploading? > > ldd /usr/bin/digikam | grep libhd > libhdf5_serial.so.103 => > /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.103 (0x7fd2c60f2000) > libhdf5_serial_hl.so.100 => not found Hi, I think this should have triggered an error at build time. So digikam probably built and installed well at that time. > This bug has already been reported by me and fixed for 6.4 To be honest, it just disappeared for 6.4, bit I could not find an action leading to that. According to "ldd -v /usr/bin/digikam" output digikam 5.9.0 had a dependency on libhdf5_serial_hl.so.100, but 6.4.0 does not. I may have missed it, but I do not see any change on debian/control leading to this change. Not to mention that it seems present again in experimental 7.0. My guess is that digikam is being affected by some obscure dependency changes in the build chain about the libhdf5 stuff and what is pulling it. digikam seems to use this hdf5 stuff if present and not use it otherwise. I wonder what is the benefit of using it, 6.4.0 works without it. Regards, PS: Like Simon, I am just tring to help triaging bug reports and make maintenance easier for real maintainers. -- Agustin
Bug#952426: digikam: digkam experimental not correctly instalable
On Mon, Feb 24, 2020 at 12:09:58PM +0100, Simon Frei wrote: > On 24/02/2020 11:38, Eric Valette wrote: > > On 24/02/2020 10:50, Simon Frei wrote: > > > >> one is 103. That suggests you aren't running the digikam binary from the > >> package, but something else (maybe you self-compiled at some point?). > >> Check the output of which digikam. > > > > > > Did you just test your packages before uploading? > > > > ldd /usr/bin/digikam | grep libhd > > libhdf5_serial.so.103 => > > /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.103 (0x7fd2c60f2000) > > libhdf5_serial_hl.so.100 => not found > > > Firstly: I don't upload digikam to debian. I am just a user interested > in having it packaged and very occasional contributor upstream. By > helping to triage and clarify bugs I hope to remove some workload from > Steve (uploader), which hopefully makes it more likely to keep getting > packages from him (thanks a lot for that!). > > And my bad, apparently libhdf5-103 still ships the .100 lib: > > libhdf5-103: /usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.100 > > At least it does in testing. I now upgraded libhdf5-103 to experimental > and I do get the same error you do. Maybe at the time the experimental > build was done the old version of hdf5 was still in experimental. Anyway > the fix for you is to downgrade libhdf5-103 to unstable and for the > package probably as simple as a rebuild (which in my opinion isn't > really necessary unless there's another change, e.g. beta3). Hi, According to https://packages.debian.org/source/experimental/hdf5 there is a new "libhdf5-hl-100" package in experimental. Looking into it, seems that libhdf5_serial_hl.so.100 has been moved there, so installing that new package should help in experimental. I still wonder what is pulling it during build. Regards, -- Agustin
Bug#951115: New version uploaded
severity 951115 normal thanks Hello, so I uploaded a version of this package without mipsel, and it built nicely on all architectures where its dependencies are to be found (all official architectures plus some others). Thus downgrading this bug. Thanks, Mt. signature.asc Description: PGP signature
Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table
Hi Alberto, Am 13.02.20 um 10:11 schrieb Alberto Molina Coballes: > I don't understand the rule "-F PREROUTING" after a "-A ..." one. It > seems that the segfault happens in this specific case (it's a bug of > course, but not a bug with grave severity). I choose the grave severity because the bug makes a reload of ufw fail and then the firewall is off ! Christoph signature.asc Description: OpenPGP digital signature
Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table
Hil Alberto, Am 13.02.20 um 10:11 schrieb Alberto Molina Coballes: > > Is this ruleset a real one obtained from ufw? I ask because the next one > doesn't result in segfault: > > *nat > -F PREROUTING > -F POSTROUTING > -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194 > COMMIT > > I don't understand the rule "-F PREROUTING" after a "-A ..." one. It > seems that the segfault happens in this specific case (it's a bug of > course, but not a bug with grave severity). Actually I stripped it down to these lines, because this is the minimum set of rules which makes it crash. In my UFW before.rules files I have several PREROUTING and POSTROUTING rules with a -F before the -A rules block in the nat table. Christoph signature.asc Description: OpenPGP digital signature
Bug#951114: umockdev fails autopkg test with stderr output
Control: tag -1 fixed-upstream pending Hello Matthias, Matthias Klose [2020-02-11 11:45 +0100]: > autopkgtest [17:12:07]: test upstream: ---] > autopkgtest [17:12:07]: test upstream: - - - - - - - - - - results - - - - - > - > - - - - > upstream FAIL stderr: > autopkgtest [17:12:08]: test upstream: - - - - - - - - - - stderr - - - - - > - - > - - - > > ** (tests/.libs/test-umockdev:14610): WARNING **: 17:11:56.893: > umockdev.vala:1205: failed to create /tmp/umockdev.3JZ6F0/dev/link -> > /tmp/umockdev.3JZ6F0/dev/other symlink for device /devices/other: File exists > autopkgtest [17:12:08]: summary > upstream FAIL stderr: Oops! Fixed upstream: https://github.com/martinpitt/umockdev/commit/af719667e1d27352 Thanks, Martin
Bug#951115: ns3: FTBFS on mipsel (OOM of the linker)
Source: src:ns3 Version: 3.30+dfsg-3.1 Severity: serious Tag: ftbfs Tag: help Hello, I'm the maintainer of this package. I'm opening this bug to discuss the issue with whom may be interested, and keep track of the discussion. The package is currently trying to enter testing to fix 2 (easy) RC bugs, but fails to do so because builds fail on mipsel with the following message: -- as: out of memory allocating 17107680 bytes after a total of 567459840 bytes /tmp/cc23jwIU.s: Assembler messages: /tmp/cc23jwIU.s: Fatal error: can't close /<>/ns-3.30/build- shared/src/lte/bindings/ns3module.cc.7.o: memory exhausted -- I tried to reduce the memory consumption with the following chunks in debian/rules: -- ifeq ($(DEB_HOST_GNU_CPU),mipsel) # Drop the debug symbols all together on mipsel to avoid OOM causing FTBFS export DEB_CFLAGS_MAINT_STRIP=-g export DEB_CXXFLAGS_MAINT_STRIP=-g endif LDFLAGS+=-Wl,--as-needed # Define CFLAGS and friends to harden the build -- must come any addition to these variables DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk ifeq ($(DEB_HOST_GNU_CPU),mipsel) # Further reduce the memory consumption on mipsel LDFLAGS += -Wl,--reduce-memory-overheads -Wl,--no-keep-memory endif --- The version that failed on the buildd servers does not have these changes, but I tested it on the porterbox. I manually inspected the command-line parameters passed to the parser, and it seem to be all right. Compiling without -g and linking with the reduce-memory-overheads (unless I'm wrong). But this is not sufficient: I get exactly the same error message. In addition, I don't think that this is a real bug of as. ns-3 is a very large library, and upstream is not paying a lot of effort on reducing its size or optimizing the linking phase. I don't have any idea of how to fix it myself. I guess that I should ask for the removal of the mipsel version of this package, but I'm not entirely sure. I'd love to have ns-3 building on every platform, even if I'm certain that nobody will ever try to use it on this platform. This is a rather inefficient simulator used in science. Users will more probably deploy it to a fast compute server. But still, if possible, being compilable on mipsel too would be healthy for the software, if I could. Any help or advice is really really welcomed. Everything is in the salsa repository. Thanks, Mt -- Vae Soli. signature.asc Description: PGP signature
Bug#889148: am-utils: incorrect installation installs scripts instead of executables
The problem is that the file m4/macros/libtool.m4 in the am-utils source is out of date relative to the libtool used in the build. The debian/rules script tries to fix this but the fix is overridden by a later stage of the build. The attached patch fixes it for me on Raspbian 10. __Martin On Fri, 02 Feb 2018 16:26:53 +0100 Giacomo Mulas wrote: > Package: am-utils > Version: 6.2+rc20110530-3.2+b1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > I just updated the am-utils package and it became unusable with the > update. Any command in the am-utils package would fail with a message > like: > > herschel:~# amq > /usr/sbin/amq: error: '/usr/sbin/.libs/amq' does not exist > This script is just a wrapper for amq. > See the libtool documentation for more information. --- am-utils-6.2+rc20110530/debian/rules +++ am-utils-6.2+rc20110530/debian/rules @@ -62,7 +62,7 @@ # autotools-dev recommends updating config.sub # and config.guess. The following has that # effect as well as updating libtool - cp -f /usr/share/aclocal/libtool.m4 ./acinclude.m4 + cp -f /usr/share/aclocal/libtool.m4 ./m4/macros/libtool.m4 aclocal libtoolize -f -c
Bug#937791: Blocked on reverse dependencies
On Sat, 8 Feb 2020 10:55:23 -0800 Martin Kelly wrote: On 2/2/20 8:39 PM, Sandro Tosi wrote: > should we remove this package then? or do you want to generate a python3-gmpy? > I didn't realize, but it looks like this package actually does support Python 3. I had assumed we would let this package die when Python 2 dies, since the package is dead upstream since 2013. However, looking at the popcon stats, the original python GMPY is still much more popular than than python GMPY2 (3543 vs 443). So I think it's worth keeping this package. I'm working on converting it over now and should be able to get it done in the next few weeks. Is it possible to remove the AUTORM tag until this is done, or should we let it get deleted and upload a new python3-gmpy package after that? Looking further, it seems that with current versions of Python 3 (I tested with 3.7.3), the old GMPY 1.17 is no longer passing. When I run test3/gmpy_test.py, I'm getting: $ python3 test3/gmpy_test.py ... 8 items had failures: 1 of 4 in gmpy_test_cvr 4 of 126 in gmpy_test_cvr.__test__.user_errors 1 of 1 in gmpy_test_dec 2 of 2 in gmpy_test_mpf 2 of 60 in gmpy_test_mpf.__test__.binio 2 of 2 in gmpy_test_mpq 2 of 4 in gmpy_test_mpz 7 of 25 in gmpy_test_rnd.__test__.rand 1504 tests in 42 items. 1483 passed and 21 failed. ***Test Failed*** 21 failures. In contrast, the tests for GMPY 2 all succeed, so I think the author clearly intended for tests to fully pass. Since this hasn't been maintained for 7 or so years, I'm not too surprised. Given this, I think we should let this package be removed and consider resurrecting it in the future if people ask for it and someone will step up to maintain it. Sandro, is there anything more to do if I want to let this package be removed, or do I just wait for the auto-removal?
Bug#937791: Blocked on reverse dependencies
On 2/2/20 8:39 PM, Sandro Tosi wrote: $ apt-cache rdepends python-gmpy python-gmpy Reverse Depends: obfsproxy python-tlslite-ng python-sympy python-gmpy-doc Dependencies on obfsproxy and python-sympy documented with affects and blocks. python-tlslite-ng has been removed already, there are no more reverse dependencies on python-gmpy, what should we do next? i see the source package doesnt produce any python3 package, and the last changelog entry contains: * Override python-foo-but-no-python3-foo Lintian warning, since this package is end-of-life after Python 2 support ends. should we remove this package then? or do you want to generate a python3-gmpy? I didn't realize, but it looks like this package actually does support Python 3. I had assumed we would let this package die when Python 2 dies, since the package is dead upstream since 2013. However, looking at the popcon stats, the original python GMPY is still much more popular than than python GMPY2 (3543 vs 443). So I think it's worth keeping this package. I'm working on converting it over now and should be able to get it done in the next few weeks. Is it possible to remove the AUTORM tag until this is done, or should we let it get deleted and upload a new python3-gmpy package after that? and we can rename python-gmpy-doc to python3-gmpy-doc once the blocking bugs are resolved. please dont, -doc package must preserve the python- prefix. Cheers, Sandro
Bug#922574: digiKam FTBFS with OpenCV 4
On Fri, Jan 17, 2020 at 04:35:04PM +0100, Agustin Martin wrote: > On Tue, Dec 10, 2019 at 01:55:50PM -0500, John Scott wrote: > > Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=401306 > > > > This appears to have been fixed upstream. There are a couple patches there. > > Hi all, > > I have been playing with this problem and with changes in upstream bug > report and I was finally able to make digikam 5.9.0 build in sid. Hi, Steve, Thanks a lot for uploading digikam 6.4.0. Since this #922574 bug report was not closed with it, I guess you want to give this upload an extended time before testing migration. Minimally tested but it is apparently fixing #918478 too. Some other bug reports were filed for older digikam versions and may no longer apply. Do you mind if I mail submitters to double check that before closing those bug reports? Thanks for your work in digikam. Regards, -- Agustin
Bug#950535: iptables-restore segfaults on nat table
Package: iptables Version: 1.8.2-4 Severity: grave Dear Maintainer, after updateing from stretch to buster ufw failed to work. we have nat-table entries for PREROUTING and POSTROUTING . iptables-restore segfaults on these rules. The following rules lead to the error: *nat -F PREROUTING -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194 -F PREROUTING -F POSTROUTING COMMIT The version from backports: 1.8.3-2~bpo10+1 does not have this problem. Please bring this fix to the stable release. The ufw firewall ist disabled after this error. So I consider this a security problem Christoph -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (700, 'stable-updates'), (700, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:\ en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iptables depends on: ii libc62.28-10 ii libip4tc01.8.2-4 ii libip6tc01.8.2-4 ii libiptc0 1.8.2-4 ii libmnl0 1.0.4-2 ii libnetfilter-conntrack3 1.0.7-1 ii libnfnetlink01.0.1-3+b1 ii libnftnl11 1.1.2-2 ii libxtables12 1.8.2-4 Versions of packages iptables recommends: ii nftables 0.9.0-2 Versions of packages iptables suggests: ii kmod 26-1 signature.asc Description: OpenPGP digital signature
Bug#948719: fio, (build-)dependencies unsatisfiable on mipsel.
Hi Peter! Thank you for your report. Am Sonntag, den 12.01.2020, 15:23 + schrieb peter green: > Package: fio > Version: 14.2.5-3 > Severity: serious > > The binary packages built from the ceph source package were recently > removed from mipsel, because the new version of ceph runs out of > address space during the build. Your package build-depends on librbd- > dev and depends on librbd1 which are built from the ceph source > package. So fio is now uninstallable and unbuildable on mipsel. > > The librbd-dev build-dependency is arch-qualified as linux-any, which > suggests building with rbd support is optional. If possible please > build your package without rbd support on mipsel (if this is not > possible then you will probablly need to request removal of the fio > packages on mipsel). I am pretty sure that building with rbd support is optional. However even after looking at Debian Policy in detail¹ I still do not know whether: Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.16.1~), libaio-dev [linux-any], zlib1g-dev, librdmacm-dev [linux-any], libibverbs-dev [linux-any], librbd-dev [linux-any !mipsel], libgtk2.0-dev, libcairo2- dev, libnuma-dev [linux-any], flex, bison, libglusterfs-dev instead of Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.16.1~), libaio-dev [linux-any], zlib1g-dev, librdmacm-dev [linux-any], libibverbs-dev [linux-any], librbd-dev [linux-any !], libgtk2.0-dev, libcairo2-dev, libnuma-dev [linux-any], flex, bison, libglusterfs-dev would work. What I do not know whether I can first include some architecture wildcard and then exclude some other architecture. The policy appears to lack any clear guidance on that. There is also no example in there which indicates that this is possible. Just using [!mipsel] would break the build on other architectures like FreeBSD and Hurd again. [1] https://www.debian.org/doc/debian-policy/ch-relationships.html Thanks, Mit freundlichen Grüßen / With kind regards Martin Steigerwald • Proact Deutschland GmbH Trainer Telefon: +49 911 30999 0 • Fax: +49 911 30999 99 Südwestpark 43 • 90449 Nürnberg • Germany martin.steigerw...@proact.de • www.proact.de Amtsgericht Nürnberg • HRB 18320 Geschäftsführer: Oliver Kügow • Richard Müller • Jonas Hasselberg • Jonas Persson – Delivering Business Agility –
Bug#922574: digiKam FTBFS with OpenCV 4
On Tue, Dec 10, 2019 at 01:55:50PM -0500, John Scott wrote:
> Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=401306
>
> This appears to have been fixed upstream. There are a couple patches there.
Hi all,
I have been playing with this problem and with changes in upstream bug
report and I was finally able to make digikam 5.9.0 build in sid.
I have prepared a personal build with those changes (it is minimally
tested, so is initially intended for my personal use), and I am attaching a
debdiff with the changes as well as individual patches under debian/patches
for clarity.
That personal build is apparently working for my preliminary tests and
is intended to fix both
#922574 digikam: FTBFS against opencv 4
#918478 digikam: ImageEditor window is blank when opened a second time
as well as a problem with libkf5calendar.
Steve, feel free to use these changes at your convenience. If needed I can
prepare a NMU, but I would appreciate some additional testing first.
Summary of the patches under debian/patches follow:
* 0010_libopencv.h_update-for-opencv4-remove-obsolete-stuff.diff:
Update libopencv.h.cmake.in for opencv4 and remove obsolete stuff.
Based on upstream changes in https://bugs.kde.org/show_bug.cgi?id=401306.
* 0011_facesengine_fix-openCV4-compilation.diff:
Update for opencv4 (and some opencv3).
Original patch by Gilles Caulier modified to deal with buster opencv
(seems that it also needs to use cv::IMREAD_GRAYSCALE). Version should
be fine tuned, but seems to work with both buster and sid.
* 0020_calsettings.cpp_Fix-for-recent-libkf5calendarcore.diff:
Fix calsettings.cpp for libkf5calendarcore-dev_4%3a19.08.3
KCalCore namespace has been renamed to KCalendarCore. Just set a
namespace alias to work around this.
This will not work for buster libkf5calendarcore-dev_4%3a18.08.3.
Comment that alias if a backport is needed.
* 0030_fix-blank-imageeditor.patch:
Fix ImageEditor window is blank when opened a second time (#918478)
Changes borrowed from http://bugs.debian.org/918478
Please find attached above patches and the debdiff for my personal build.
Hope this helps
--
Agustin
From: Aguatin Martin
Date: 20200117
Subject: Update libopencv.h.cmake.in for opencv4 and remove obsolete stuff
Based on changes by Gilles Caulier for recent digikam.
--- a/core/app/utils/libopencv.h.cmake.in
+++ b/core/app/utils/libopencv.h.cmake.in
@@ -49,35 +49,26 @@
#define OPENCV_VERSION OPENCV_MAKE_VERSION(CV_MAJOR_VERSION,CV_MINOR_VERSION,CV_SUBMINOR_VERSION)
#define OPENCV_TEST_VERSION(major,minor,patch) ( OPENCV_VERSION < OPENCV_MAKE_VERSION(major,minor,patch) )
-#if OPENCV_TEST_VERSION(2,5,0)
-# include
-# include
-# include
-# include
-#else
-# include
-# include
-# include
-# include
-#endif
+// Core module headers
-#if OPENCV_TEST_VERSION(3,0,0)
-# include
-# include
-# include
-#else
-# include
# include
# include
# include
+#include
+#include
+
+// Object detection module headers
+
+#include
+
+// Image codecs module headers
+
# include
-# include
-#endif
-// for old-style code
-#if OPENCV_VERSION <= OPENCV_MAKE_VERSION(2,4,99)
-# include
-#endif
+// Image processing module headers
+
+#include
+#include
// Restore warnings
#if !defined(__APPLE__) && defined(__GNUC__)
>From 7a5af66d8fc7ab8e78f05016eaf3e94de66951b3 Mon Sep 17 00:00:00 2001
From: Gilles Caulier
Date: Fri, 15 Mar 2019 17:16:06 +0100
Subject: fix broken compilation with OpenCV4 in Test::FaceEngine CCBUGS:
401306
Modified by Agustin martin to lower version in OPENCV test to (2,99,0)
Was (3,99,0), but buster opencv version is lower and already needs
this change.
---
core/tests/facesengine/preprocess.cpp | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/core/tests/facesengine/preprocess.cpp
+++ b/core/tests/facesengine/preprocess.cpp
@@ -63,7 +63,13 @@ QList toImages(const QStringLis
foreach (const QString& path, paths)
{
QByteArray s = path.toLocal8Bit();
-images << cv::imread(std::string(s.data()), CV_LOAD_IMAGE_GRAYSCALE);
+images << cv::imread(std::string(s.data()),
+#if OPENCV_TEST_VERSION(2,99,0)
+CV_LOAD_IMAGE_GRAYSCALE
+#else
+cv::IMREAD_GRAYSCALE
+#endif
+);
}
return images;
--- a/core/libs/facesengine/detection/opencvfacedetector.cpp
+++ b/core/libs/facesengine/detection/opencvfacedetector.cpp
@@ -366,7 +366,7 @@ void OpenCVFaceDetector::updateParameter
* unless in we want very high sensitivity at low speed
*/
if (d->sensitivityVsSpecificity > 0.1 || d->speedVsAccuracy < 0.9)
-d->primaryParams.flags = CV_HAAR_DO_CANNY_PRUNING;
+d->primaryParams.flags = cv::CASCADE_DO_CANNY_PRUNING;
else
d->primaryParams.flags = 0;
From: Agustin Martin
Date: 20200117
Subject: Fix c
Bug#937969: python-omemo-backend-signal: Python2 removal in sid/bullseye
Quoting Scott Kitterman : It's only needed as a Recommends for sat-xmpp-core, whch is about to be removed from Testing. Note, that upstream of sat-* already ported everything to Python 3. I started packaging the new stuff, but got stuck at some point. It's probably time to give it another try.
Bug#947712: autopkgtest regressions in python-dbusmock with newer network-manager 1.22.2-1
Hello Michael and Thomas, Michael Biebl [2020-01-08 19:42 +0100]: > > The latest update of network-manager causes an autopkgtest regression in > > python-dbusmock. > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-dbusmock/3793816/log.gz > > > > == > > FAIL: test_eth_and_wifi (__main__.TestNetworkManager) > > -- > > Traceback (most recent call last): > > File "test_networkmanager.py", line 138, in test_eth_and_wifi > > self.assertRegex(out, r'eth0.*\sdisconnected') > > AssertionError: Regex didn't match: 'eth0.*\\sdisconnected' not found in > > 'DEVICE TYPE STATECONNECTION \neth0ethernet unknown -- > >\nwlan0 wifi unknown -- \n' Note that this may look similar to the recent StateReason issue fixed in https://github.com/martinpitt/python-dbusmock/commit/bd51d9108e08 but it's different. python-dbusmock upstream runs tests against Fedora rawhide as well, and I just restarted a run against latest rawhide: https://travis-ci.org/martinpitt/python-dbusmock/jobs/628460969 this succeeds against NetworkManager-1:1.22.2-1.fc32.x86_64, i. e. the same NM upstream version that up uploaded into Debian. As per https://ci.debian.net/packages/p/python-dbusmock/unstable/amd64/ the first failure happened in https://ci.debian.net/data/packages/unstable/amd64/p/python-dbusmock/3694572.log against NM 1.22.0, while the last successful run was against 1.20.8. I'll investigate this more closely tomorrow. Right now my sid schroot is rather broken due to some weirdness with gnupg disappearing from the archive. Thanks, Martin
Bug#947916: [pcp] Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing
Hello Nathan, Nathan Scott [2020-01-07 11:18 +1100]: > Thanks for looking into this issue while we were all off, Martin and Sunil! > > To summarise where I understand things are at now: Martin's uploaded > a pcp package for rebuild which drops the python2 build steps. I think > this is fine and solves the immediate, pressing issue. My pleasure -- the NMU did probably not clean up some bits in the control.master etc. bits, but it should be good enough to get into testing and fix the RC bug/avoid being kicked out of testing indeed. > Ken and Andreas, this would mean we set Debian8 (and the equivalent > Ubuntu release) as the minimum required for Makepkgs builds. Would > that be a problem for anyone? It turns out that was the first Debian that > used systemd as the init system, so there's a possibility of several other > useful packaging cleanups if we take this path. Note that Debian 8 went EOL some time ago. There are some efforts to provide security update maintenance for it, but that doesn't mean that you still have to support it upstream -- these security updates would only do selected patch backports, not new upstream releases. Debian 9 should still be supported for roughly another half year. (See https://www.debian.org/releases/) Thanks, Martin
