Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

[Salvatore Bonaccorso]

Hi Ard,

On Tue, Nov 23, 2021 at 07:58:32AM +0100, Ard Biesheuvel wrote:
> On Tue, 23 Nov 2021 at 06:12, Salvatore Bonaccorso  wrote:
> >
> > Hi Vincent,
> >
> > On Fri, Nov 19, 2021 at 10:04:57PM +0100, Vincent Blut wrote:
> > > Hi,
> > >
> > > Le 2021-10-26 17:33, Zameer Manji a écrit :
> > > > On Tue, Oct 26, 2021 at 5:05 PM Vincent Blut  
> > > > wrote:
> > > >
> > > > > Control: reassign -1 src:linux
> > > > >
> > > > > Hi,
> > > > >
> > > > > Le 2021-10-26 20:44, Zameer Manji a écrit :
> > > > > > Package: linux-image-arm64
> > > > > > Version: 5.14.9-2
> > > > > > Severity: important
> > > > > >
> > > > > > Dear Maintainer,
> > > > > >
> > > > > > In bullseye, version 5.10.70-1 has the
> > > > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> > > > > > kernel configuration set to 'y'. In bookworm it is unset which 
> > > > > > disable
> > > > > this feature.
> > > > > >
> > > > > > This kernel configuration parameter allows for the EFI stub of the
> > > > > kernel to
> > > > > > parse and use a 'initrd=' parameter to set up an initrd when booting
> > > > > from EFI.
> > > > > > Boot loaders like 'systemd-boot' or 'refind' set this parameter if
> > > > > configured
> > > > > > to pass an initrd. If the kernel configuration parameter is unset, 
> > > > > > the
> > > > > > `initrd=` paramater is ignored, and can result in an unbootable 
> > > > > > system
> > > > > because
> > > > > > the initrd has not setup the root filesystem.
> > > > > >
> > > > > > Without the kernel configuaration set, it is not possible to use
> > > > > 'systemd-boot'
> > > > > > or 'refind' on arm64 as both of these bootloaders assume the kernel 
> > > > > > will
> > > > > > handle the 'initrd=' flag and setup the initrd.
> > > > > >
> > > > > > Please consider enabling 
> > > > > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on
> > > > > > arm64 so using 'systemd-boot' or 'refind' can continue to work. 
> > > > > > Until
> > > > > these
> > > > > > bootloaders have been updated to use an alternative method of 
> > > > > > passing the
> > > > > > initrd to the EFI stub, it is not possible to have a booting system.
> > > > >
> > > > > Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer 
> > > > > enabled
> > > > > by
> > > > > default. Please see [1] for some details.
> > > > >
> > > > > Cheers,
> > > > > Vincent
> > > > >
> > > > > [1]
> > > > > https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a
> > > > >
> > > >
> > > > Hello Vincent,
> > > >
> > > > I see and understand the rationale of upstream to deprecate this
> > > > functionality.
> > > > >From the commit you linked I see another commit [0] which says:
> > > >
> > > > > Loading an initrd passed via the kernel command line is deprecated: it
> > > > > is limited to files that reside in the same volume as the one the 
> > > > > kernel
> > > > > itself was loaded from, and we have more flexible ways to achieve the
> > > > > same. So make it configurable so new architectures can decide not to
> > > > > enable it.
> > > >
> > > > I assume the 'more flexible ways' to do the same is referencing this
> > > > feature [1]
> > > > which is indeed more flexible. The problem is that the 
> > > > firmware/bootloader
> > > > must
> > > > support this new functionality, by populating the right EFI file with 
> > > > the
> > > > right GUID.
> > > >
> > > > As far as I can see on arm64 there are three EFI bootloaders:
> > > > * GRUB2
> > > > * systemd-boot
> > > > * refind
> > > >
> > > > Both systemd-boot and refind do not yet support this new mechanism,
> > > > although I see
> > > > that systemd has some unreleased code [2] to support the new way. I have
> > > > not been
> > > > able to test GRUB2 but my understanding is that this new method is still
> > > > under active
> > > > development [3].
> > > >
> > > > The problem is that upstream has deprecated this functionality by 
> > > > assuming
> > > > the only
> > > > active use was x86, but was completely possible to use it on arm64 (it
> > > > works fine for me
> > > > on bullseye). Since EFI bootloaders have not yet implemented the new 
> > > > way,
> > > > and still
> > > > rely on this deprecated method on all architectures, it results in
> > > > unbootable systems
> > > > on arm64.
> > > >
> > > > I would 100% think this should remain disabled on arm64 if most EFI
> > > > bootloaders
> > > > supported the new way, but unfortunately they do not.
> > > >
> > > > I hope you would consider enabling this kernel configuration for arm64
> > > > until EFI
> > > > bootloaders catch up to the recommended way.
> > > >
> > > >
> > > > [0]
> > > > https://gitlab.com/linux-kernel/stable/-/commit/cf6b83664895a5c7e97710df282e220bd047f0f5
> > > > [1]
> > > > https://gitlab.com/linux-kernel/stable/-/commit/ec93fc371f014a6fb483e3556061ecad4b40735c
> > > > [2]
> > > > 

Bug#1000435: Matplotlib crashes on mips64el in lines.py

[Ole Streicher]

Source: matplotlib
Severity: serious
Version: 3.5.0-1
Control: affects -1 yt
Control: affects -1 astropy

With the new matplotlib version, I now have crashes with a segmentation fault
in at least two of my packages on mips64el, which cause a FTBFS: yt and
astropy. On both packages, the crash happens here:

--8<
  File "/usr/lib/python3/dist-packages/matplotlib/lines.py", line 840 in draw
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 299 in draw
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1163 in draw
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in 
_draw_list_compositing_images
  File "/usr/lib/python3/dist-packages/matplotlib/axes/_base.py", line 3082 in 
draw
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in 
_draw_list_compositing_images
  File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 2803 in draw
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 73 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", 
line 436 in draw
--8<

Build log on Astropy: 
https://buildd.debian.org/status/fetch.php?pkg=astropy=mips64el=5.0-1=1637626067=0

Build log on yt: 
https://buildd.debian.org/status/fetch.php?pkg=yt=mips64el=4.0.1-3=1637588650=0

This happens on both Python 3.9 and 3.10. The I will try to create a stacktrace 
for it.

Bug#1000434: RM: libbiod -- ROM; Does not build with gcc-11, unmaintained upstream, no reverse-depends any more

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pjotr.publi...@thebird.nl, debian-...@lists.debian.org, 
998...@bugs.debian.org


Hi,

es per the discussion with upstream[1] the package libbiod should be
removed from Debian.  It has some Recommends in med-bio-dev but this is
removed in Git and will vanish once the next version of Debian Med
metapackages will be uploaded.

Kind regards

  Andreas.


[1] https://github.com/biod/BioD/issues/55

Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

[Ard Biesheuvel]

On Tue, 23 Nov 2021 at 06:12, Salvatore Bonaccorso  wrote:
>
> Hi Vincent,
>
> On Fri, Nov 19, 2021 at 10:04:57PM +0100, Vincent Blut wrote:
> > Hi,
> >
> > Le 2021-10-26 17:33, Zameer Manji a écrit :
> > > On Tue, Oct 26, 2021 at 5:05 PM Vincent Blut  
> > > wrote:
> > >
> > > > Control: reassign -1 src:linux
> > > >
> > > > Hi,
> > > >
> > > > Le 2021-10-26 20:44, Zameer Manji a écrit :
> > > > > Package: linux-image-arm64
> > > > > Version: 5.14.9-2
> > > > > Severity: important
> > > > >
> > > > > Dear Maintainer,
> > > > >
> > > > > In bullseye, version 5.10.70-1 has the
> > > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> > > > > kernel configuration set to 'y'. In bookworm it is unset which disable
> > > > this feature.
> > > > >
> > > > > This kernel configuration parameter allows for the EFI stub of the
> > > > kernel to
> > > > > parse and use a 'initrd=' parameter to set up an initrd when booting
> > > > from EFI.
> > > > > Boot loaders like 'systemd-boot' or 'refind' set this parameter if
> > > > configured
> > > > > to pass an initrd. If the kernel configuration parameter is unset, the
> > > > > `initrd=` paramater is ignored, and can result in an unbootable system
> > > > because
> > > > > the initrd has not setup the root filesystem.
> > > > >
> > > > > Without the kernel configuaration set, it is not possible to use
> > > > 'systemd-boot'
> > > > > or 'refind' on arm64 as both of these bootloaders assume the kernel 
> > > > > will
> > > > > handle the 'initrd=' flag and setup the initrd.
> > > > >
> > > > > Please consider enabling 
> > > > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on
> > > > > arm64 so using 'systemd-boot' or 'refind' can continue to work. Until
> > > > these
> > > > > bootloaders have been updated to use an alternative method of passing 
> > > > > the
> > > > > initrd to the EFI stub, it is not possible to have a booting system.
> > > >
> > > > Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer 
> > > > enabled
> > > > by
> > > > default. Please see [1] for some details.
> > > >
> > > > Cheers,
> > > > Vincent
> > > >
> > > > [1]
> > > > https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a
> > > >
> > >
> > > Hello Vincent,
> > >
> > > I see and understand the rationale of upstream to deprecate this
> > > functionality.
> > > >From the commit you linked I see another commit [0] which says:
> > >
> > > > Loading an initrd passed via the kernel command line is deprecated: it
> > > > is limited to files that reside in the same volume as the one the kernel
> > > > itself was loaded from, and we have more flexible ways to achieve the
> > > > same. So make it configurable so new architectures can decide not to
> > > > enable it.
> > >
> > > I assume the 'more flexible ways' to do the same is referencing this
> > > feature [1]
> > > which is indeed more flexible. The problem is that the firmware/bootloader
> > > must
> > > support this new functionality, by populating the right EFI file with the
> > > right GUID.
> > >
> > > As far as I can see on arm64 there are three EFI bootloaders:
> > > * GRUB2
> > > * systemd-boot
> > > * refind
> > >
> > > Both systemd-boot and refind do not yet support this new mechanism,
> > > although I see
> > > that systemd has some unreleased code [2] to support the new way. I have
> > > not been
> > > able to test GRUB2 but my understanding is that this new method is still
> > > under active
> > > development [3].
> > >
> > > The problem is that upstream has deprecated this functionality by assuming
> > > the only
> > > active use was x86, but was completely possible to use it on arm64 (it
> > > works fine for me
> > > on bullseye). Since EFI bootloaders have not yet implemented the new way,
> > > and still
> > > rely on this deprecated method on all architectures, it results in
> > > unbootable systems
> > > on arm64.
> > >
> > > I would 100% think this should remain disabled on arm64 if most EFI
> > > bootloaders
> > > supported the new way, but unfortunately they do not.
> > >
> > > I hope you would consider enabling this kernel configuration for arm64
> > > until EFI
> > > bootloaders catch up to the recommended way.
> > >
> > >
> > > [0]
> > > https://gitlab.com/linux-kernel/stable/-/commit/cf6b83664895a5c7e97710df282e220bd047f0f5
> > > [1]
> > > https://gitlab.com/linux-kernel/stable/-/commit/ec93fc371f014a6fb483e3556061ecad4b40735c
> > > [2]
> > > https://github.com/systemd/systemd/commit/a6089431d52adda93eec251a3df0dffa1fe0661a#diff-76eb4030e88f340c9133388f17c65774b0f17a0a8105500978f6ce18ca1deb5a
> > > [3] https://www.mail-archive.com/grub-devel@gnu.org/msg32272.html
> >
> > Salvatore, I tend to agree with Zameer. I think we should explicitly enable
> > EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER until the support for loading initrd
> > from a device path is widespread among bootloaders.
>
> Yeah I guess it makes sense and understand. Before doing the switch
> and re-enabling it 

Bug#999519: xrayutilities: diff for NMU version 1.7.1-2.1

[Dominik Kriegner]

Dear Debian team,

I think the patch can be used like this. I'll also release a new upstream
version with this patch hopefully today.

kind regards
Dominik

On Tue, Nov 23, 2021 at 2:48 AM Stefano Rivera  wrote:

> Control: tags 999519 + patch
> Control: tags 999519 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for xrayutilities (versioned as 1.7.1-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>
> Also filed as:
> https://salsa.debian.org/science-team/python-xrayutilities/-/merge_requests/1
>
> Regards,
>
> SR
>

Bug#1000432: pymatgen: run tests with python3-phonopy

[Andrius Merkys]

Source: pymatgen
Severity: wishlist

Hello,

phonopy has entered Debian. Since pymatgen has integrations with it, it
would be great to have its (autopkg)tests run with python3-phonopy
installed to ensure the successful integration.

I am not sure about adding python3-phonopy to
Depends/Suggests/Recommends, though. This is up to the maintainer to decide.

Andrius

Bug#1000431: Please consider disabling LDC_DYNAMIC_COMPILE

[Christian Ehrhardt]

Package: ldc
Version: 1:1.28.0-1+b1

Hi,
with llvm >=12 you will be forced to disable LDC_DYNAMIC_COMPILE and
thereby libldc-jit.so. The background of this is that the used ORCv1
API was dropped in that newer llvm version.
But in addition the discussion on the related upstream issue to
support ORCv2 [2] revealed that it was only meant to be a personal
experiment, so it might generally (even before llvm >=12) be a good
idea to disable LDC_DYNAMIC_COMPILE.

[1]: 
https://github.com/ldc-developers/ldc/commit/d8bc064cfbc766347d563cb139a72d238312bd38#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20a
[2]: https://github.com/ldc-developers/ldc/issues/3747

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#1000405: Please accept other JRE versions besides the default one

[tony mancill]

On Mon, Nov 22, 2021 at 06:14:16PM +0100, Olivier Cailloux wrote:
> Please rather recommend “java-runtime-headless” if libbatik-java also
> works with java 8, or otherwise, consider some appropriate means to
> recommend any headless jre from 11 onwards.

One other comment (and a note of caution) is that the java-runtime and
java-runtime-headless virtual packages are provided by JRE runtimes
older than Java 8.  For examples, see openjdk-7 [1] and openjdk-6 [2].
I don't know how many of those older JVMs are still around, but strictly
speaking, we should use javaX-runtime[-headless], where X is the greater
of the minimum necessary runtime version and the compilation target
version.

Cheers,
tony

[1] https://snapshot.debian.org/package/openjdk-7/7u261-2.6.22-1~deb8u1/
[2] https://snapshot.debian.org/package/openjdk-6/6b41-1.13.13-1/


signature.asc
Description: PGP signature

Bug#1000430: RM: ttf-aenigma -- ROM; migration complete

[Gürkan Myczko]

Package: ftp.debian.org
Severity: normal

Please remove ttf-aenigma from the archive:
 * migrated to fonts-aenigma

Thanks,
Gurkan

Bug#1000405: Please accept other JRE versions besides the default one

[tony mancill]

On Mon, Nov 22, 2021 at 06:14:16PM +0100, Olivier Cailloux wrote:
> Package: libbatik-java
> Version: 1:0.95.dfsg-5
> 
> The libbatik-java package currently recommends “default-jre”, itself
> depending on “default-jre-headless (= 2:1.11-72) [not hppa]”, itself
> depending on “openjdk-11-jre-headless [not hppa]”. But libbatik-java
> would work equally well with any posterior version, such as openjdk-17-
> jre-headless.
> 
> Please rather recommend “java-runtime-headless” if libbatik-java also
> works with java 8, or otherwise, consider some appropriate means to
> recommend any headless jre from 11 onwards.

Thank you for the bug report.  We might want to add a lintian check for
this condition, since it likely impacts a number of packages that depend
on a Java runtime.

In this specific case, we should create a separate binary package for
the wrappers that depends on a Java runtime, since it is technically
against Java Policy [1] for a library package to depend on a runtime.
That would also address bug #566901 [2].  Any thoughts on whether this
would be confusing to users?

In any event, I will update the Recommends with the next upload.

Regards,
tony

[1] 
https://www.debian.org/doc/packaging-manuals/java-policy/ch02.html#policy-libraries
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566901

Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

[Salvatore Bonaccorso]

Hi Vincent,

On Fri, Nov 19, 2021 at 10:04:57PM +0100, Vincent Blut wrote:
> Hi,
> 
> Le 2021-10-26 17:33, Zameer Manji a écrit :
> > On Tue, Oct 26, 2021 at 5:05 PM Vincent Blut  wrote:
> > 
> > > Control: reassign -1 src:linux
> > >
> > > Hi,
> > >
> > > Le 2021-10-26 20:44, Zameer Manji a écrit :
> > > > Package: linux-image-arm64
> > > > Version: 5.14.9-2
> > > > Severity: important
> > > >
> > > > Dear Maintainer,
> > > >
> > > > In bullseye, version 5.10.70-1 has the
> > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> > > > kernel configuration set to 'y'. In bookworm it is unset which disable
> > > this feature.
> > > >
> > > > This kernel configuration parameter allows for the EFI stub of the
> > > kernel to
> > > > parse and use a 'initrd=' parameter to set up an initrd when booting
> > > from EFI.
> > > > Boot loaders like 'systemd-boot' or 'refind' set this parameter if
> > > configured
> > > > to pass an initrd. If the kernel configuration parameter is unset, the
> > > > `initrd=` paramater is ignored, and can result in an unbootable system
> > > because
> > > > the initrd has not setup the root filesystem.
> > > >
> > > > Without the kernel configuaration set, it is not possible to use
> > > 'systemd-boot'
> > > > or 'refind' on arm64 as both of these bootloaders assume the kernel will
> > > > handle the 'initrd=' flag and setup the initrd.
> > > >
> > > > Please consider enabling CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER 
> > > > on
> > > > arm64 so using 'systemd-boot' or 'refind' can continue to work. Until
> > > these
> > > > bootloaders have been updated to use an alternative method of passing 
> > > > the
> > > > initrd to the EFI stub, it is not possible to have a booting system.
> > >
> > > Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer enabled
> > > by
> > > default. Please see [1] for some details.
> > >
> > > Cheers,
> > > Vincent
> > >
> > > [1]
> > > https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a
> > >
> >
> > Hello Vincent,
> > 
> > I see and understand the rationale of upstream to deprecate this
> > functionality.
> > >From the commit you linked I see another commit [0] which says:
> > 
> > > Loading an initrd passed via the kernel command line is deprecated: it
> > > is limited to files that reside in the same volume as the one the kernel
> > > itself was loaded from, and we have more flexible ways to achieve the
> > > same. So make it configurable so new architectures can decide not to
> > > enable it.
> > 
> > I assume the 'more flexible ways' to do the same is referencing this
> > feature [1]
> > which is indeed more flexible. The problem is that the firmware/bootloader
> > must
> > support this new functionality, by populating the right EFI file with the
> > right GUID.
> > 
> > As far as I can see on arm64 there are three EFI bootloaders:
> > * GRUB2
> > * systemd-boot
> > * refind
> > 
> > Both systemd-boot and refind do not yet support this new mechanism,
> > although I see
> > that systemd has some unreleased code [2] to support the new way. I have
> > not been
> > able to test GRUB2 but my understanding is that this new method is still
> > under active
> > development [3].
> > 
> > The problem is that upstream has deprecated this functionality by assuming
> > the only
> > active use was x86, but was completely possible to use it on arm64 (it
> > works fine for me
> > on bullseye). Since EFI bootloaders have not yet implemented the new way,
> > and still
> > rely on this deprecated method on all architectures, it results in
> > unbootable systems
> > on arm64.
> > 
> > I would 100% think this should remain disabled on arm64 if most EFI
> > bootloaders
> > supported the new way, but unfortunately they do not.
> > 
> > I hope you would consider enabling this kernel configuration for arm64
> > until EFI
> > bootloaders catch up to the recommended way.
> > 
> > 
> > [0]
> > https://gitlab.com/linux-kernel/stable/-/commit/cf6b83664895a5c7e97710df282e220bd047f0f5
> > [1]
> > https://gitlab.com/linux-kernel/stable/-/commit/ec93fc371f014a6fb483e3556061ecad4b40735c
> > [2]
> > https://github.com/systemd/systemd/commit/a6089431d52adda93eec251a3df0dffa1fe0661a#diff-76eb4030e88f340c9133388f17c65774b0f17a0a8105500978f6ce18ca1deb5a
> > [3] https://www.mail-archive.com/grub-devel@gnu.org/msg32272.html
>  
> Salvatore, I tend to agree with Zameer. I think we should explicitly enable 
> EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER until the support for loading initrd
> from a device path is widespread among bootloaders.

Yeah I guess it makes sense and understand. Before doing the switch
and re-enabling it explicitly, let's ask Ard if there are known plans for
!X86 and say so for example arm64 as well to revert the default
upstream. The more we can follow those upstream the better for us :)

Ard, this is about https://bugs.debian.org/997907 on non X86,
specifically for arm64.

Regards,
Salvatore

Bug#1000429: understand $LOCATE_PATH=~/.locatedb and do... something better

[Trent W. Buck]

Package: catfish
Version: 4.16.3-1
Severity: wishlist

catfish has a hard-coded path to mlocate's default database path:

https://codesearch.debian.net/search?q=pkg%3Acatfish+mlocate=1


https://sources.debian.org/src/catfish/4.16.3-1/catfish_lib/catfishconfig.py/#L32

mlocate and plocate support $LOCATE_PATH being a colon-separated list of paths 
to locate databases:


https://manpages.debian.org/bullseye-backports/plocate/plocate.1.en.html#ENVIRONMENT

I use this to run updatedb directly on the NAS, which is MUCH more efficient.
The commands are approximately this:

# on the file server, generate ~twb/.locatedb
sudo -H -u twb nice nocache updatedb --require-visibility=no --output 
.locatedb --database-root ~twb

# on the desktop, where ~twb is NFS and / is Debian Live
export LOCATE_PATH=~twb/.locatedb
locate foo
catfish

I think with Debian 11's catfish, it will ALWAYS pop up this alert:

The search database is more than 7 days old.  Update now?  [Update] [X]

I'm not sure EXACTLY what the correct semantics here should be, but
the current behaviour is definitely annoying me! :-)




-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1000421: dpkg-shlibdeps: Wrong minimum version requirement on libc6

[Guillem Jover]

Hi!

On Mon, 2021-11-22 at 22:49:43 +0100, Joachim Reichel wrote:
> Package: dpkg-dev
> Version: 1.20.9
> Severity: serious
> Control: affects -1 cppcheck

> dpkg-shlibdeps calculates too low minimum version requirements for cppcheck 
> on libc6 (see bug 1000146).
> 
> To reproduce, build cppcheck 2.6-1 in unstable chroot without cleaning up, 
> e.g., "dpkg-buildpackage -rfakeroot -us -uc".
> 
> $ grep Depends debian/cppcheck/DEBIAN/control
> Depends: libc6 (>= 2.29), [...]
> 
> But running the binary with libc6 2.31 fails with
> 
> cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by cppcheck)
> cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by 
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6)
> cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by 
> /lib/x86_64-linux-gnu/libpthread.so.0)
> 
> I believe that is the case because a certain symbol in the .bss section is 
> ignored (this is the only symbol with 2.32 suffix):
> 
> $ objdump -w -T ./debian/cppcheck/usr/bin/cppcheck | grep 
> __libc_single_threaded
> 004670e0 gDO .bss   0001  GLIBC_2.32  
> __libc_single_threaded
> 
> $ nm -D ./debian/cppcheck/usr/bin/cppcheck | grep __libc_single_threaded
> 004670e0 B __libc_single_threaded@@GLIBC_2.32
> 
> $ dpkg-shlibdeps ./debian/cppcheck/usr/bin/cppcheck; cat debian/substvars
> shlibs:Depends=libc6 (>= 2.29), [...]
> 
> After hacking /usr/share/perl5/Dpkg/Shlibs/Objdump.pm:462 to read
> "defined => ($sect ne '*UND*') && ($sect ne '.bss')"
> (maybe not the right solution, just for demonstration):

Thanks for the investigation! But, I'm afraid that would mean
dpkg-gensymbols missing symbols on the generated .symbols file. Also
marking all such symbols from «.bss» would start emitting tons of
warnings for non-imported symbols, more so in cppcheck case as it is
built with -rdynamic (which exports those).

After some further checking, it seems newer binutils have started
qualifying symbols in copy relocation with the version string, which
the code was not matching (but i386 was not affected f.ex. as it does
not use copy relocations for those). The attached patch seems to work
on amd64, but I'll check tomorrow whether the same applies to other
arches and if they use the same symbol format. But at least it should
improve things and not cause regressions as it will try both formats.

Thanks,
Guillem
From a9c4f1806f1927a2da42712658f4cfdd37f73e50 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 23 Nov 2021 02:26:50 +0100
Subject: [PATCH] Dpkg::Shlibs::Objdump: Fix apply_relocations to work with
 versioned symbols
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since at least binutils 2.28 copy relocations for versioned symbols have
the version appended after «@@». We were not taking this into account
which meant these did not match and did not get marked as undefined.

Try both the version qualified symbol and the bare symbol name to cope
with old and new formats.

Closes: #1000421
---
 scripts/Dpkg/Shlibs/Objdump.pm | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/scripts/Dpkg/Shlibs/Objdump.pm b/scripts/Dpkg/Shlibs/Objdump.pm
index 93319d1eb..43d786edd 100644
--- a/scripts/Dpkg/Shlibs/Objdump.pm
+++ b/scripts/Dpkg/Shlibs/Objdump.pm
@@ -488,9 +488,20 @@ sub apply_relocations {
 	# We want to mark as undefined symbols those which are currently
 	# defined but that depend on a copy relocation
 	next if not $sym->{defined};
-	next if not exists $self->{dynrelocs}{$sym->{name}};
-	if ($self->{dynrelocs}{$sym->{name}} =~ /^R_.*_COPY$/) {
+
+my @relocs;
+push @relocs, $sym->{name} . '@@' . $sym->{version} if $sym->{version};
+
+# Symbols that are not versioned, or versioned but linked with old
+# binutils do not have a version appended.
+push @relocs, $sym->{name};
+
+foreach my $reloc (@relocs) {
+next if not exists $self->{dynrelocs}{$reloc};
+next if not $self->{dynrelocs}{$reloc} =~ /^R_.*_COPY$/;
+
 	$sym->{defined} = 0;
+last;
 	}
 }
 }
-- 
2.34.0

Bug#976603: Dropping fcitx4/5 coexistence

[Gunnar Hjalmarsson]

Thanks for elaborating on the topic, Boyuan.

On 2021-11-23 01:40, Boyuan Yang wrote:

Hi,

在 2021-11-23星期二的 00:15 +0100，Gunnar Hjalmarsson写道：

Hi!


  + debian/control: Let fcitx5 conflicts with:
    - fcitx (<< 1:5)
    - fcitx-data (<< 1:5)
    - fcitx-bin (<< 1:5)


That may become a bit problematic with respect to package upgrades for
users who have both fcitx and fcitx5 installed. I suppose that fcitx5
upgrades will be held back if you just do "apt upgrade".

Ubuntu Kylin 21.10 includes both fcitx and fcitx5 by default. The 21.10
-> 22.04 release upgrade is not so far away.

Not sure what to suggest. To start with I wonder if you have considered
situations like the one I mentioned.


This is tough decision with no ideal solution. From fcitx upstream's
perspective, the upstream has no intention to support coexisted fcitx4/fcitx5
from the very beginning, and co-installation provides little (if not zero)
benefit. Besides, fcitx5 will likely eventually replace fcitx4.

From distribution's perspective, Debian included Debian-specific patch to
allow coexistence in the initial fcitx5 packaging. This introduced inherent
bug on icon handling, which I would like to solve recently. Now, I wouldn't
say trading co-installation possibility for bug-free icon handling is always
beneficial, but it shouldn't bother users with reasonable setup.

From packaging perspective, versioned conflicts are indeed a little bit too
aggressive. I was indeed not aware of Ubuntu Kylin's condition of installing
both fcitx and fcitx5 by default. This is a weird decision with no benefit: th
e out-of-box experience won't benefit from co-installation.

Anyway, the correctness of default co-installation decision is out of current
discussion scope. Personally (as packager of fcitx) I do not wish to keep
carrying debian-specific coexistence patch forever, but I would be happy to
work with any team from Ubuntu on securing a solid Ubuntu 22.04 LTS.

The path forward really depends on which fcitx does Ubuntu(-any-flavor) plan
to ship by default: fcitx4 or fcitx5. I would be surprised if they still wish
to install both by default in future, but please let me know if this would be
their decision.

For distribution upgrade: I remember that Ubuntu handles it with do-release-
upgrade. Even for Debian, we do not instruct users to only run "apt upgrade"
across major version upgrades: users always invoke "apt full-upgrade/apt dist-
upgrade", so this shouldn't be a problem. Just make sure that the metapackage
for default Ubuntu desktop depends on correct fcitx (4 or 5, depending on
final decision for 22.04 release).

I may postpone the removal of conexistence patch (with buggy icon handling)
till after Ubuntu 22.04 freeze, but this will happen sonner or later. Please
let me know if there are more information available.


Hopefully there is no need to postpone the removal of the coexistence 
patch. And you are right about do-release-upgrade using "apt 
full-upgrade", which may be sufficient to ensure a smooth upgrade.


Ubuntu in general switched to fcitx5 in 21.10.

https://launchpad.net/bugs/1928360

So when doing a Chinese installation of an Ubuntu flavor (i.e. not 
Ubuntu with GNOME), fcitx5 is installed by default and fcitx4 is not. 
And if you install a Chinese language post install, fcitx5 is pulled as 
a language support component.


Initially Ubuntu Kylin had the intention to do the same. However, Kylin 
makes the Sogou IME easily available to their users and wants to keep 
doing so, and Sogou was not ready for fcitx5 when this was discussed 
during the 21.10 development cycle. So it was decided that Ubuntu Kylin 
also installs fcitx4 in 21.10. The coexistence packaging arrangement 
made that possible, and since im-config launches fcitx4 by default if 
both are present, everyone was happy. :)


I don't know whether Sogou has been adapted to fcitx5 yet. Sending this 
also to Jianfeng Li (Ubuntu Kylin), who may be able to give us a status 
report.


For the record Lubuntu installs fcitx4 for all users irrespective of 
language. I don't really know why they do that — from an im-config POV 
things had been less complicated if they didn't install any IM framework 
by default.


--
Cheers,
Gunnar

Bug#1000204: pyfai: diff for NMU version 0.20.0+dfsg1-4.1

[Stefano Rivera]

Control: tags 1000204 + pending

Dear maintainer,

I've prepared an NMU for pyfai (versioned as 0.20.0+dfsg1-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Also filed as https://salsa.debian.org/science-team/pyfai/-/merge_requests/4

Regards,

SR
diff -Nru pyfai-0.20.0+dfsg1/debian/changelog pyfai-0.20.0+dfsg1/debian/changelog
--- pyfai-0.20.0+dfsg1/debian/changelog	2021-09-19 07:57:57.0 -0400
+++ pyfai-0.20.0+dfsg1/debian/changelog	2021-11-22 21:29:59.0 -0400
@@ -1,3 +1,10 @@
+pyfai (0.20.0+dfsg1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Python 3.10 support, thanks Lukas Märdian. (Closes: #1000204)
+
+ -- Stefano Rivera   Mon, 22 Nov 2021 21:29:59 -0400
+
 pyfai (0.20.0+dfsg1-4) unstable; urgency=medium
 
   * Bug fix: "Removal of the python3-*-dbg packages in sid/bookworm",
diff -Nru pyfai-0.20.0+dfsg1/debian/patches/0009-Fix-collections.MutableSets-compat-with-python3.10.patch pyfai-0.20.0+dfsg1/debian/patches/0009-Fix-collections.MutableSets-compat-with-python3.10.patch
--- pyfai-0.20.0+dfsg1/debian/patches/0009-Fix-collections.MutableSets-compat-with-python3.10.patch	1969-12-31 20:00:00.0 -0400
+++ pyfai-0.20.0+dfsg1/debian/patches/0009-Fix-collections.MutableSets-compat-with-python3.10.patch	2021-11-22 21:29:59.0 -0400
@@ -0,0 +1,45 @@
+From: Lukas Märdian 
+Date: Mon, 22 Nov 2021 21:30:44 -0400
+Subject: Fix collections.MutableSets compat with python3.10
+
+collections.MutableSet was deprecated a long time ago and removed with python3.10.
+https://docs.python.org/3/whatsnew/3.10.html#removed
+https://bugs.python.org/issue37324
+
+Using the old class name leads to test failures such as this one:
+==
+ERROR: test_import_all_modules (pyFAI.test.test_bug_regression.TestBugRegression)
+Try to import every single module in the package
+--
+Traceback (most recent call last):
+  File "/<>/pyfai-0.20.0+dfsg1/.pybuild/cpython3_3.10_pyfai/build/pyFAI/test/test_bug_regression.py", line 286, in test_import_all_modules
+raise err
+  File "/<>/pyfai-0.20.0+dfsg1/.pybuild/cpython3_3.10_pyfai/build/pyFAI/test/test_bug_regression.py", line 271, in test_import_all_modules
+load_source(fqn, path)
+  File "/<>/pyfai-0.20.0+dfsg1/.pybuild/cpython3_3.10_pyfai/build/pyFAI/test/test_bug_regression.py", line 78, in load_source
+spec.loader.exec_module(module)
+  File "", line 883, in exec_module
+  File "", line 241, in _call_with_frames_removed
+  File "/<>/pyfai-0.20.0+dfsg1/.pybuild/cpython3_3.10_pyfai/build/pyFAI/utils/orderedset.py", line 30, in 
+class OrderedSet(collections.MutableSet):
+AttributeError: module 'collections' has no attribute 'MutableSet'
+
+Origin: vendor, Ubuntu
+Forwarded: https://github.com/silx-kit/pyFAI/pull/1588
+---
+ pyFAI/utils/orderedset.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pyFAI/utils/orderedset.py b/pyFAI/utils/orderedset.py
+index de097cf..417490f 100644
+--- a/pyFAI/utils/orderedset.py
 b/pyFAI/utils/orderedset.py
+@@ -27,7 +27,7 @@
+ import collections
+ 
+ 
+-class OrderedSet(collections.MutableSet):
++class OrderedSet(collections.abc.MutableSet):
+ 
+ def __init__(self, iterable=None):
+ self.end = end = []
diff -Nru pyfai-0.20.0+dfsg1/debian/patches/series pyfai-0.20.0+dfsg1/debian/patches/series
--- pyfai-0.20.0+dfsg1/debian/patches/series	2021-09-19 07:57:57.0 -0400
+++ pyfai-0.20.0+dfsg1/debian/patches/series	2021-11-22 21:29:59.0 -0400
@@ -6,3 +6,4 @@
 0006-fix-a-couple-of-test-failing-with-i386.patch
 0007-cleaner-test.patch
 0008-tunning.patch
+0009-Fix-collections.MutableSets-compat-with-python3.10.patch

Bug#999519: xrayutilities: diff for NMU version 1.7.1-2.1

[Stefano Rivera]

Control: tags 999519 + patch
Control: tags 999519 + pending

Dear maintainer,

I've prepared an NMU for xrayutilities (versioned as 1.7.1-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Also filed as: 
https://salsa.debian.org/science-team/python-xrayutilities/-/merge_requests/1

Regards,

SR
diff -Nru xrayutilities-1.7.1/debian/changelog xrayutilities-1.7.1/debian/changelog
--- xrayutilities-1.7.1/debian/changelog	2021-09-19 08:54:46.0 -0400
+++ xrayutilities-1.7.1/debian/changelog	2021-11-22 21:22:36.0 -0400
@@ -1,3 +1,10 @@
+xrayutilities (1.7.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: matplotlib 3.5 support (Closes: #999519)
+
+ -- Stefano Rivera   Mon, 22 Nov 2021 21:22:36 -0400
+
 xrayutilities (1.7.1-2) unstable; urgency=medium
 
   * Corrected Profile nodocs -> nodoc
diff -Nru xrayutilities-1.7.1/debian/patches/0005-Fix-matplotlib-3.5-issue.patch xrayutilities-1.7.1/debian/patches/0005-Fix-matplotlib-3.5-issue.patch
--- xrayutilities-1.7.1/debian/patches/0005-Fix-matplotlib-3.5-issue.patch	1969-12-31 20:00:00.0 -0400
+++ xrayutilities-1.7.1/debian/patches/0005-Fix-matplotlib-3.5-issue.patch	2021-11-22 21:22:36.0 -0400
@@ -0,0 +1,35 @@
+From: Dominik Kriegner 
+Date: Fri, 12 Nov 2021 12:30:16 +0100
+Subject: Fix matplotlib-3.5 issue.
+
+reported by Debian. The best solution seems to be to avoid the
+problematic keyword argument since we anyhow specified the default
+value.
+
+Bug-Debian: https://bugs.debian.org/999519
+---
+ lib/xrayutilities/simpack/fit.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/xrayutilities/simpack/fit.py b/lib/xrayutilities/simpack/fit.py
+index 8e71783..5d49dcf 100644
+--- a/lib/xrayutilities/simpack/fit.py
 b/lib/xrayutilities/simpack/fit.py
+@@ -13,7 +13,7 @@
+ # You should have received a copy of the GNU General Public License
+ # along with this program; if not, see .
+ #
+-# Copyright (C) 2016-2020 Dominik Kriegner 
++# Copyright (C) 2016-2021 Dominik Kriegner 
+ 
+ import warnings
+ 
+@@ -208,7 +208,7 @@ class FitModel(object):
+ else:
+ self.zord = 1
+ if self.logscale:
+-self.ax.set_yscale("log", nonposy='clip')
++self.ax.set_yscale("log")
+ self.fline = None
+ 
+ def showplot(self, xlab=self.lmodel.xlabelstr,
diff -Nru xrayutilities-1.7.1/debian/patches/series xrayutilities-1.7.1/debian/patches/series
--- xrayutilities-1.7.1/debian/patches/series	2021-09-19 08:54:46.0 -0400
+++ xrayutilities-1.7.1/debian/patches/series	2021-11-22 21:22:36.0 -0400
@@ -2,3 +2,4 @@
 0002-Desactivated-pdf-generation-for-the-doc.patch
 0003-Do-not-change-PYTHONPATH-during-the-build.patch
 0004-Used-the-system-Mathjax.patch
+0005-Fix-matplotlib-3.5-issue.patch

Bug#982028: Additional information

[Luis Guzman]

That was a home build, so the build might have used the gnumeric source,
rather than the debian package one.

Seems like no gnumeric "Fallback icon theme" is shipped on the debian
packages, thus the icons issue.

On Mon, 15 Feb 2021 13:37:08 -0600 =?UTF-8?Q?Carlos_Prieto_L=c3=b3pez?=
 wrote:

> By the way: Before reporting here in Debian I tried to report on
> gnome.org. I found an issue already opened a month ago:
>
>
> https://gitlab.gnome.org/GNOME/gnumeric/-/issues/550#note_1026530
>
>
> And the last commentor (@jbrefort) says he uses Debian Sid and that the
> problem is not found there, so he believes it is a Debian bug.
>
>
>

Bug#1000428: gammapy: FTBFS with matplotlib 3.5

[Stefano Rivera]

Source: gammapy
Version: 0.18.2-1
Severity: serious
Justification: FTBFS

Matplotlib 3.5 seems to have caused some test failures:
=== short test summary info 
FAILED gammapy/datasets/tests/test_map.py::test_plot_residual_onoff - ValueEr...
FAILED gammapy/datasets/tests/test_spectrum.py::test_peek - TypeError: Unsupp...
FAILED gammapy/datasets/tests/test_spectrum.py::TestSpectrumOnOff::test_peek
FAILED gammapy/datasets/tests/test_spectrum.py::TestSpectrumOnOff::test_plot_fit
FAILED 
gammapy/irf/tests/test_edisp_map.py::test_edispkernel_from_diagonal_response
FAILED gammapy/irf/tests/test_edisp_map.py::test_edispkernel_from_1D - KeyErr...
FAILED gammapy/makers/background/tests/test_reflected.py::test_bad_on_region
FAILED gammapy/maps/tests/test_region.py::test_width - AssertionError: 
FAILED gammapy/maps/tests/test_regionnd.py::test_region_nd_map_plot - TypeErr...
FAILED gammapy/modeling/models/tests/test_spectral.py::test_model_plot - Type...
= 10 failed, 1157 passed, 479 skipped, 2 xfailed, 3 xpassed in 82.49s (0:01:22) 
=

With both Python 3.9 and 3.10.

See: 
https://buildd.debian.org/status/fetch.php?pkg=gammapy=amd64=0.18.2-1%2Bb1=1637623734=0

SR

Bug#1000427: pyregion: FTBFS with setuptools >= 58

[Stefano Rivera]

Source: pyregion
Version: 2.1.1-1
Severity: serious
Tags: upstream
Justification: FTBFS

pyregion fails to build with setuptools >= 58, which dropped use_2to3
support.:

/usr/lib/python3/dist-packages/setuptools/dist.py:294: DistDeprecationWarning: 
use_2to3 is ignored.
  warnings.warn(f"{attr} is ignored.", DistDeprecationWarning)

See the full log:
https://buildd.debian.org/status/fetch.php?pkg=pyregion=amd64=2.1.1-1%2Bb1=1637589214=0

SR

Bug#1000396: systemd-detect-virt falsely detects "Microsoft" virtualisation

[Liban Parker Hannan]

Hi Micahel,

Thanks for looking into this and filing the report upstream. I'll
subscribe.

Cheers

On Mon, 22 Nov 2021 17:40:05 +0100 Michael Biebl 
wrote:
> Control: forwarded -1 https://github.com/systemd/systemd/issues/21468
> 
> Am 22.11.21 um 16:37 schrieb Michael Biebl:
> > On 22.11.21 14:06, Liban Hannan wrote:
> > 
> >> systemd-detect-virt checks /sys/class/dmi/id/sys_vendor as part of
its
> >> attempt to detect if the system is virtualised. I am using a
Surface
> >> Laptop so sys_vendor returns "Microsoft Corporation" which (as far
as I
> >> can tell) the program assumes indicates the presence of hyper-v
rather
> >> than Microsoft produced hardware. One of the consequences is that
> >> systemd units that won't run in a VM fail, such as thermald.
> > 
> > Would you mind forwarding this issue to upstream by filing an issue
at 
> > https://github.com/systemd/systemd/issues
> 
> I've filed it as https://github.com/systemd/systemd/issues/21468
> 
> Please consider subscribing to this upstream bug report in case
upstream 
> has further questions.
> 
> 
> 

Bug#976603: Droping fcitx4/5 coexistence (Was: Bug#976603: Icon themes in breeze and papirus are not supported)

[Boyuan Yang]

Hi,

在 2021-11-23星期二的 00:15 +0100，Gunnar Hjalmarsson写道：
> Hi!
> 
> >  + debian/control: Let fcitx5 conflicts with:
> >    - fcitx (<< 1:5)
> >    - fcitx-data (<< 1:5)
> >    - fcitx-bin (<< 1:5)
> 
> That may become a bit problematic with respect to package upgrades for 
> users who have both fcitx and fcitx5 installed. I suppose that fcitx5 
> upgrades will be held back if you just do "apt upgrade".
> 
> Ubuntu Kylin 21.10 includes both fcitx and fcitx5 by default. The 21.10 
> -> 22.04 release upgrade is not so far away.
> 
> Not sure what to suggest. To start with I wonder if you have considered 
> situations like the one I mentioned.

This is tough decision with no ideal solution. From fcitx upstream's
perspective, the upstream has no intention to support coexisted fcitx4/fcitx5
from the very beginning, and co-installation provides little (if not zero)
benefit. Besides, fcitx5 will likely eventually replace fcitx4.

>From distribution's perspective, Debian included Debian-specific patch to
allow coexistence in the initial fcitx5 packaging. This introduced inherent
bug on icon handling, which I would like to solve recently. Now, I wouldn't
say trading co-installation possibility for bug-free icon handling is always
beneficial, but it shouldn't bother users with reasonable setup.

>From packaging perspective, versioned conflicts are indeed a little bit too
aggressive. I was indeed not aware of Ubuntu Kylin's condition of installing
both fcitx and fcitx5 by default. This is a weird decision with no benefit: th
e out-of-box experience won't benefit from co-installation.

Anyway, the correctness of default co-installation decision is out of current
discussion scope. Personally (as packager of fcitx) I do not wish to keep
carrying debian-specific coexistence patch forever, but I would be happy to
work with any team from Ubuntu on securing a solid Ubuntu 22.04 LTS.

The path forward really depends on which fcitx does Ubuntu(-any-flavor) plan
to ship by default: fcitx4 or fcitx5. I would be surprised if they still wish
to install both by default in future, but please let me know if this would be
their decision.

For distribution upgrade: I remember that Ubuntu handles it with do-release-
upgrade. Even for Debian, we do not instruct users to only run "apt upgrade"
across major version upgrades: users always invoke "apt full-upgrade/apt dist-
upgrade", so this shouldn't be a problem. Just make sure that the metapackage
for default Ubuntu desktop depends on correct fcitx (4 or 5, depending on
final decision for 22.04 release).

I may postpone the removal of conexistence patch (with buggy icon handling)
till after Ubuntu 22.04 freeze, but this will happen sonner or later. Please
let me know if there are more information available.

Thanks,
Boyuan Yang

Bug#997278: pidgin-sipe: diff for NMU version 1.25.0-2.1

[Adrian Bunk]

Control: tags 997278 + patch
Control: tags 997278 + pending

Dear maintainer,

I've prepared an NMU for pidgin-sipe (versioned as 1.25.0-2.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru pidgin-sipe-1.25.0/debian/changelog pidgin-sipe-1.25.0/debian/changelog
--- pidgin-sipe-1.25.0/debian/changelog	2020-01-23 19:13:12.0 +0200
+++ pidgin-sipe-1.25.0/debian/changelog	2021-11-23 01:46:05.0 +0200
@@ -1,3 +1,11 @@
+pidgin-sipe (1.25.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with --disable-quality-check to fix building with
+recent glib. (Closes: #997278)
+
+ -- Adrian Bunk   Tue, 23 Nov 2021 01:46:05 +0200
+
 pidgin-sipe (1.25.0-2) unstable; urgency=medium
 
   * Add upstream patch 0001-Fix-359-Incorrect-build-due-to-false-negative-config
diff -Nru pidgin-sipe-1.25.0/debian/rules pidgin-sipe-1.25.0/debian/rules
--- pidgin-sipe-1.25.0/debian/rules	2020-01-23 19:13:12.0 +0200
+++ pidgin-sipe-1.25.0/debian/rules	2021-11-23 01:46:05.0 +0200
@@ -2,7 +2,7 @@
 
 include /usr/share/dpkg/pkg-info.mk
 
-DEB_CONFIGURE_EXTRA_FLAGS := --libdir=/usr/lib --enable-purple --disable-telepathy --enable-openssl=no
+DEB_CONFIGURE_EXTRA_FLAGS := --libdir=/usr/lib --enable-purple --disable-telepathy --enable-openssl=no --disable-quality-check
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 

Bug#1000414: textdistance: autopkgtest regression on arm64: AssertionError: assert 3.0 <= 1

[Julian Gilbey]

On Mon, Nov 22, 2021 at 10:14:03PM +0100, Paul Gevers wrote:
> Source: textdistance
> Version: 4.2.2-1
> X-Debbugs-CC: debian...@lists.debian.org
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainer(s),
> 
> With a recent upload of textdistance the autopkgtest of textdistance fails
> in testing when that autopkgtest is run with the binary packages of
> textdistance from unstable on arm64. It passes when run with only packages
> from testing. In tabular form:

Hi Paul,

Thanks for this report.  I've just been fighting with abydos (part of
the same chain of dependencies of spyder), and fixed that.  I'm
working through the list, and textdistance is high on it...

I'm not quite sure what the cause is, but we'll see...

Best wishes,

   Julian

Bug#996653: RFS: dynarmic/5+git20211012.cce7e4e+ds-1 [ITP] -- ARM dynamic recompiler

[Bastian Germann]

On Sun, 14 Nov 2021 14:48:33 +0100 Andrea Pappacoda  wrote:

Control: tags -1 - moreinfo

Untagging moreinfo as it should've been removed with the previous 
message.


Is there a good reason for not including 32 bit in the architecture list?

FTBFS on arm64:

/usr/bin/gmake  -f CMakeFiles/cmTC_aa059.dir/build.make 
CMakeFiles/cmTC_aa059.dir/build
gmake[3]: Entering directory 
'/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_aa059.dir/CheckSymbolExists.c.o
/usr/bin/cc   -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Wdate-time 
-D_FORTIFY_SOURCE=2  -o CMakeFiles/cmTC_aa059.dir/CheckSymbolExists.c.o -c 
/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c

/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c: 
In function ‘main’:
/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:7:19: error: ‘__ARM64__’ undeclared 
(first use in this function)

7 |   return ((int*)(&__ARM64__))[argc];
  |   ^
/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:7:19: note: each undeclared identifier is 
reported only once for each function it appears in

gmake[3]: *** [CMakeFiles/cmTC_aa059.dir/build.make:78: 
CMakeFiles/cmTC_aa059.dir/CheckSymbolExists.c.o] Error 1
gmake[3]: Leaving directory 
'/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp'
gmake[2]: *** [Makefile:127: cmTC_aa059/fast] Error 2

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Boyuan Yang]

Hi,

On Fri, 5 Nov 2021 16:55:33 +0800 Wenbin Lv  wrote:
> Package: src:linux
> Version: 5.15-1~exp1
> Severity: wishlist
> 
> Hi,
> Paragon's NTFS3 driver has been merged to 5.15, and it offers much
> better performance compared to ntfs-3g. Currently it is not enabled in
> Debian's kernel config, nor can I mount NTFS partitions using '-t
> ntfs3'.
> Please enable it if you consider it stable enough. Thank you!

Now that 5.15 has been uploaded to Unstable, this issue will attract wider
attention. Please consider enabling it in future uploads.

Thanks!
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Bug#1000159: dnsproxy listen unnecessary UDP port

[Marcos Talau]

Control: forwarded -1 https://github.com/awaw/dnsproxy/issues/6

The changes [1] fixed the issue about listening to an unnecessary UDP port on
all interfaces. But when dnsproxy receive a query from some client it sends a
UDP datagram, via sendto(), to the configured DNS servers. When dnsproxy calls
sendto() without a previous bind(), the UDP stack of Linux (and certainly
on other kernels), starts to listen to a random UDP port on IN-ADDR_ANY, so,
the port will be opened on all interfaces.

A new patch to fix this was forwarded in [2].

[1] https://github.com/awaw/dnsproxy/issues/1
[2] https://github.com/awaw/dnsproxy/issues/6


signature.asc
Description: PGP signature

Bug#989649: libjs-mathjax: integrate with dh_sphinxdoc

[Julian Gilbey]

OK, update on this...

On Sun, Nov 21, 2021 at 12:24:15PM +, Julian Gilbey wrote:
> On Mon, Oct 04, 2021 at 12:26:35PM +0200, Drew Parsons wrote:
> > Source: mathjax
> > Followup-For: Bug #989649
> > 
> > It's not always so simple as adding the conf.py patch.
> > 
> > For the example of fenics-dolfinx 0.3.0-3 (in experimental), the
> > lintian privacy-breach-generic warning complains about
> > 
> >   https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js
> >   
> > But there is no local tex-mml-chtml.js file to replace it with.
> 
> That shouldn't be a problem; have a look at
> /usr/lib/python3/dist-packages/sphinx/ext/mathjax.py
> This is where the tex-mml-chtml.js file is referred to, but that is
> overridden by the mathjax_path config file variable.

So all you have to do is add:

mathjax_path = 
'file:///usr/share/javascript/mathjax/MathJax.js?config=TeX-AMS-MML_HTMLorMML'

to docs/conf.py

> Unfortunately, though, this completely fails to work with Firefox:
> [...]

The rest of this turns out to be a bug in version 94.0-1 of Debian
Firefox (at least on my machine).  Upgrading to 94.0-2 fixed the
issue, and the Sphinx-generated documentation (with the mathjax_path
patch) now works fine.

Best wishes,

   Julian

Bug#976603: Icon themes in breeze and papirus are not supported

[Gunnar Hjalmarsson]

Hi!


 + debian/control: Let fcitx5 conflicts with:
   - fcitx (<< 1:5)
   - fcitx-data (<< 1:5)
   - fcitx-bin (<< 1:5)


That may become a bit problematic with respect to package upgrades for 
users who have both fcitx and fcitx5 installed. I suppose that fcitx5 
upgrades will be held back if you just do "apt upgrade".


Ubuntu Kylin 21.10 includes both fcitx and fcitx5 by default. The 21.10 
-> 22.04 release upgrade is not so far away.


Not sure what to suggest. To start with I wonder if you have considered 
situations like the one I mentioned.


--
Cheers,
Gunnar

Bug#1000353: [Pkg-utopia-maintainers] Bug#1000353: Downgrade e2fsprogs from Depends to Recommends?

[Michael Biebl]

On 22.11.21 01:02, Trent W. Buck wrote:

Package: libblockdev-fs2
Version: 2.25-2
Severity: wishlist
File: /usr/lib/x86_64-linux-gnu/libbd_fs.so.2.0.0

libblockdev-fs2 Depends e2fsprogs because it calls dumpe2fs 
This was done per https://bugs.debian.org/887270
AFAICT there is a run-time check for this:

 https://codesearch.debian.net/search?q=bd_fs_ext_is_tech_avail

In other words, dumpe2fs isn't found in $PATH, libblockdev-fs2 will
print an obvious error, instead of e.g. segfaulting.

Therefore, can you downgrade e2fsprogs from Depends to Recommends?


Would probably be ok with me, given that libbd_fs also handles other 
file systems (and we don't have any hard deps e.g. for xfsprogs, 
ntfsprogs or dosfstools)


Andreas, wdyt?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#998853: obs-frontend-api.h: fatal error: {obs,util/darray}.h: No such file or directory

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-11-08 17:23:01 -0300, Joao Eriberto Mota Filho wrote:
> Package: libobs-dev
> Version: 26.1.2+dfsg1-2
> Severity: important
> Tags: patch
> Control: affects -1 obs-move-transition
> 
> Dear maintainer,
> 
> In last weekend obs-move-transition[1] arrived to Debian. obs-move-transition
> is the most rated plugin for obs-studio.
> 
>  [1] https://tracker.debian.org/pkg/obs-move-transition
> 
> obs-move-transition depends of the libobs-dev. When packaging this plugin, I
> got the following errors:
> 
>  In file included from /PKGS/obs-move-transition-2.5.1/move-source-filter.c:2:
>  /usr/include/obs/obs-frontend-api.h:3:10: fatal error: obs.h: No such file 
> or directory
>  3 | #include 
>|  ^~~
> 
>  In file included from /PKGS/obs-move-transition-2.5.1/move-transition.c:3:
>  /usr/include/obs/obs-frontend-api.h:4:10: fatal error: util/darray.h: No 
> such file or directory
>  4 | #include 
>|  ^~~
> 
> To allow the plugin to build correctly, I created a 'fixed copy' of the
> /usr/include/obs/obs-frontend-api.h inside of
> obs-move-transition-2.5.1.
> 
> On Debian, the libobs-dev put the headers in /usr/include/obs/ but the current
> /usr/include/obs/obs-frontend-api.h expects to find for these files in
> /usr/include/. However, when building obs-studio, the source code searches for
> the headers also in /usr/include/. Consequently, making a patch for
> obs-frontend-api.h to search for headers in /usr/include/obs/ will generate a
> FTBFS. IMO, the right way is changing the obs-frontend-api.h after the
> obs-studio build process. The attached patch will fix this issue. I also sent
> an MR to Salsa [2] to make to make easier the fix.

In the cmake config installed by libobs-dev, the include dir is
specified as /usr/include/obs. Why is obs-move-transition ignoring this
bit?

Best
Sebastian

> 
> [2] https://salsa.debian.org/multimedia-team/obs-studio/-/merge_requests/5
> 
> After the fix, I will drop the embedded copy of the obs-frontend-api.h in
> obs-move-transition.
> 
> Thanks in advance.
> 
> Regards,
> 
> Eriberto

> --- a/debian/rules
> +++ b/debian/rules
> @@ -28,6 +28,8 @@ override_dh_install:
>   
> debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/obs-plugins/obs-ffmpeg/obs-ffmpeg-mux
>   dh_install
>   rm -rf debian/obs-studio/usr/share/obs/obs-studio/license
> + sed -i 's/#include /#include /' 
> debian/libobs-dev/usr/include/obs/obs-frontend-api.h
> + sed -i 's/#include /#include /' 
> debian/libobs-dev/usr/include/obs/obs-frontend-api.h
>  
>  execute_before_dh_shlibdeps:
>   echo "libobs 0 libobs0 (= ${DEB_VERSION})" > debian/shlibs.local
> 


-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#999980: proftpd-dfsg: depends on obsolete pcre3 library

[Hilmar Preuße]

Control: tags -1 + fixed-upstream

Am 18.11.2021 um 12:49 teilte Matthew Vernon mit:

Hi,


The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/

I've reported the issue in upstream and they created a patch for this. 
The patch is for v1.3.8. Simply applying to the 1.3.7 source does not 
work out, so so we have to wait for next proftp release.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000425: node-cheerio: FTBFS in sid

[Gianfranco Costamagna]

control: tags -1 patch

Hello, I just discovered that the following patch, extracted from a big 
upstream refactor fixed the build/test

Description: Fix build failure with part of upstream patch
Origin: 
https://github.com/cheeriojs/cheerio/commit/b64cb31bb0d40d9d912a4e3a24a5ad22a5cdfced
Bug-Debian: https://bugs.debian.org/1000425
Last-Update: 2021-11-22

--- node-cheerio-1.0.0~rc~10+~cs13.5.2.orig/src/cheerio.ts
+++ node-cheerio-1.0.0~rc~10+~cs13.5.2/src/cheerio.ts
@@ -79,9 +79,9 @@ export class Cheerio implements Array
 : null;

 if (elements) {
-  elements.forEach((elem, idx) => {
-this[idx] = elem;
-  });
+  for (let idx = 0; idx < elements.length; idx++) {
+this[idx] = elements[idx];
+  }
   this.length = elements.length;
   return this;
 }

G.

On Mon, 22 Nov 2021 23:39:21 +0100 Gianfranco Costamagna 
 wrote:
> Source: node-cheerio
> Version: 1.0.0~rc~10+~cs13.5.2-4
> Severity: serious
> 
> Hello, some changes in sid made the package FTBFS
> 
>  debian/rules binary
> dh binary
>dh_update_autotools_config
>dh_autoreconf
>dh_auto_configure --buildsystem=nodejs
>   mkdir node_modules
>   ln -s /usr/share/nodejs/css-what ./node_modules/
>   ln -s /usr/share/nodejs/domelementtype ./node_modules/
>   ln -s /usr/share/nodejs/jest-diff ./node_modules/
>   ln -s /usr/share/nodejs/pretty-format ./node_modules/
>   ln -s /usr/share/nodejs/ts-jest ./node_modules/
>   ln -s /usr/share/nodejs/tslib ./node_modules/
>   mkdir -p ./node_modules/\@types
>   ln -s /usr/share/nodejs/\@types/node ./node_modules/\@types/
>   ln -s /usr/share/nodejs/\@types/parse5 ./node_modules/\@types/
>   cp -rL /usr/share/nodejs/css-select ./node_modules/
>   cp -rL /usr/share/nodejs/domhandler ./node_modules/
>   cp -rL /usr/share/nodejs/dom-serializer ./node_modules/
>   cp -rL /usr/share/nodejs/domutils ./node_modules/
>   cp -rL /usr/share/nodejs/htmlparser2 ./node_modules/
>   mkdir -p ./node_modules/\@types
>   cp -rL /usr/share/nodejs/\@types/jest ./node_modules/\@types
>   ln -s ../cheerio-select node_modules/cheerio-select
>   ln -s ../parse5-htmlparser2-tree-adapter 
> node_modules/parse5-htmlparser2-tree-adapter
>   ln -s ../../types-parse5-htmlparser2-tree-adapter 
> node_modules/\@types/parse5-htmlparser2-tree-adapter
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/node-cheerio-1.0.0~rc~10+~cs13.5.2'
> dh_auto_build --buildsystem=nodejs
> Found debian/nodejs/cheerio-select/build
>   cd ./cheerio-select && sh -ex ../debian/nodejs/cheerio-select/build
> + tsc
> No build command found, searching known files
> No build command found, searching known files
> tsc
> src/cheerio.ts:83:9 - error TS2322: Type 'Node' is not assignable to type 'T'.
>   'T' could be instantiated with an arbitrary type which could be unrelated 
> to 'Node'.
> 
> 83 this[idx] = elem;
>~
> 
> 
> Found 1 error.
> 
> make[1]: *** [debian/rules:12: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/node-cheerio-1.0.0~rc~10+~cs13.5.2'
> 
> 
> Can you please have a look? thanks
> 
> Gianfranco
> 
> 

Bug#1000425: node-cheerio: FTBFS in sid

[Gianfranco Costamagna]

Source: node-cheerio
Version: 1.0.0~rc~10+~cs13.5.2-4
Severity: serious

Hello, some changes in sid made the package FTBFS

 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
   dh_auto_configure --buildsystem=nodejs
mkdir node_modules
ln -s /usr/share/nodejs/css-what ./node_modules/
ln -s /usr/share/nodejs/domelementtype ./node_modules/
ln -s /usr/share/nodejs/jest-diff ./node_modules/
ln -s /usr/share/nodejs/pretty-format ./node_modules/
ln -s /usr/share/nodejs/ts-jest ./node_modules/
ln -s /usr/share/nodejs/tslib ./node_modules/
mkdir -p ./node_modules/\@types
ln -s /usr/share/nodejs/\@types/node ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/parse5 ./node_modules/\@types/
cp -rL /usr/share/nodejs/css-select ./node_modules/
cp -rL /usr/share/nodejs/domhandler ./node_modules/
cp -rL /usr/share/nodejs/dom-serializer ./node_modules/
cp -rL /usr/share/nodejs/domutils ./node_modules/
cp -rL /usr/share/nodejs/htmlparser2 ./node_modules/
mkdir -p ./node_modules/\@types
cp -rL /usr/share/nodejs/\@types/jest ./node_modules/\@types
ln -s ../cheerio-select node_modules/cheerio-select
ln -s ../parse5-htmlparser2-tree-adapter 
node_modules/parse5-htmlparser2-tree-adapter
ln -s ../../types-parse5-htmlparser2-tree-adapter 
node_modules/\@types/parse5-htmlparser2-tree-adapter
   debian/rules override_dh_auto_build
make[1]: Entering directory '/node-cheerio-1.0.0~rc~10+~cs13.5.2'
dh_auto_build --buildsystem=nodejs
Found debian/nodejs/cheerio-select/build
cd ./cheerio-select && sh -ex ../debian/nodejs/cheerio-select/build
+ tsc
No build command found, searching known files
No build command found, searching known files
tsc
src/cheerio.ts:83:9 - error TS2322: Type 'Node' is not assignable to type 'T'.
  'T' could be instantiated with an arbitrary type which could be unrelated to 
'Node'.

83 this[idx] = elem;
   ~


Found 1 error.

make[1]: *** [debian/rules:12: override_dh_auto_build] Error 2
make[1]: Leaving directory '/node-cheerio-1.0.0~rc~10+~cs13.5.2'


Can you please have a look? thanks

Gianfranco

Bug#1000423: python-biom-format: FTBFS with Python 3.10 - Test failures

[Stefano Rivera]

Source: python-biom-format
Version: 2.1.10-2
Severity: serious
Tags: upstream
Justification: FTBFS
Block -1 with 1000422

python-biom-format FTBFS with Python 3.10:
=== short test summary info 
ERROR biom/tests/test_err.py
ERROR biom/tests/test_parse.py
ERROR biom/tests/test_table.py
ERROR biom/tests/test_util.py
ERROR biom/tests/test_cli/test_add_metadata.py
ERROR biom/tests/test_cli/test_show_install_info.py
ERROR biom/tests/test_cli/test_subset_table.py
ERROR biom/tests/test_cli/test_summarize_table.py
ERROR biom/tests/test_cli/test_table_converter.py
ERROR biom/tests/test_cli/test_table_normalizer.py
ERROR biom/tests/test_cli/test_uc_processor.py
ERROR biom/tests/test_cli/test_validate_table.py
!!! Interrupted: 12 errors during collection !!!
== 12 errors in 2.27s ==
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=2: cd 
/<>/.pybuild/cpython3_3.10_biom-format/build; python3.10 -m pytest

See: 
https://buildd.debian.org/status/fetch.php?pkg=python-biom-format=amd64=2.1.10-2%2Bb1=1637570066=0

I adapted an upstream patch, in 
https://salsa.debian.org/med-team/python-biom-format/-/merge_requests/1

But it still doesn't build because we need pandas, first.

SR

Bug#1000422: pandas: FTBFS with Python 3.10 - Test failures

[Stefano Rivera]

Source: pandas
Version: 1.1.5+dfsg-2
Severity: serious
Justification: FTBFS

Pandas fails to build with Python 3.10.
See: 
https://buildd.debian.org/status/fetch.php?pkg=pandas=amd64=1.1.5%2Bdfsg-2%2Bb1=1637461771=0

=== FAILURES ===
 TestDatetime64SeriesComparison.test_comparison_invalid[None-DataFrame] 

left =0  1  2  3  4
0  0  1  2  3  4
right =0  1  2  3  4
0 2001-01-01 2001-01-02 2001-01-03 2001-01-04 2001-01-05
box = 

def assert_invalid_comparison(left, right, box):
"""
Assert that comparison operations with mismatched types behave 
correctly.

Parameters
--
left : np.ndarray, ExtensionArray, Index, or Series
right : object
box : {pd.DataFrame, pd.Series, pd.Index, tm.to_array}
"""
# Not for tznaive-tzaware comparison

# Note: not quite the same as how we do this for tm.box_expected
xbox = box if box is not Index else np.array

result = left == right
expected = xbox(np.zeros(result.shape, dtype=np.bool_))

tm.assert_equal(result, expected)

result = right == left
tm.assert_equal(result, expected)

result = left != right
tm.assert_equal(result, ~expected)

result = right != left
tm.assert_equal(result, ~expected)

msg = "|".join(
[
"Invalid comparison between",
"Cannot compare type",
"not supported between",
"invalid type promotion",
(
# GH#36706 npdev 1.20.0 2020-09-28
r"The DTypes  and "
r" do not have a common 
DType. "
"For example they cannot be stored in a single array unless 
the "
"dtype is `object`."
),
]
)
with pytest.raises(TypeError, match=msg):
>   left < right

pandas/tests/arithmetic/common.py:89:

Looks like upstream has got there, but a quick search didn't find the
relevant patches, yet:
https://github.com/pandas-dev/pandas/commit/e7efd02c71c48c7968b2f8fdb845a0b0bf61a3fa

SR

Bug#1000421: dpkg-shlibdeps: Wrong minimum version requirement on libc6

[Joachim Reichel]

Package: dpkg-dev
Version: 1.20.9
Severity: serious
Control: affects -1 cppcheck

Hi,

dpkg-shlibdeps calculates too low minimum version requirements for cppcheck on 
libc6 (see bug 1000146).

To reproduce, build cppcheck 2.6-1 in unstable chroot without cleaning up, 
e.g., "dpkg-buildpackage -rfakeroot -us -uc".

$ grep Depends debian/cppcheck/DEBIAN/control
Depends: libc6 (>= 2.29), [...]

But running the binary with libc6 2.31 fails with

cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by cppcheck)
cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6)
cppcheck: ./libc.so.6: version `GLIBC_2.32' not found (required by 
/lib/x86_64-linux-gnu/libpthread.so.0)

I believe that is the case because a certain symbol in the .bss section is 
ignored (this is the only symbol with 2.32 suffix):

$ objdump -w -T ./debian/cppcheck/usr/bin/cppcheck | grep __libc_single_threaded
004670e0 gDO .bss   0001  GLIBC_2.32  
__libc_single_threaded

$ nm -D ./debian/cppcheck/usr/bin/cppcheck | grep __libc_single_threaded
004670e0 B __libc_single_threaded@@GLIBC_2.32

$ dpkg-shlibdeps ./debian/cppcheck/usr/bin/cppcheck; cat debian/substvars
shlibs:Depends=libc6 (>= 2.29), [...]

After hacking /usr/share/perl5/Dpkg/Shlibs/Objdump.pm:462 to read
"defined => ($sect ne '*UND*') && ($sect ne '.bss')"
(maybe not the right solution, just for demonstration):

$ dpkg-shlibdeps ./debian/cppcheck/usr/bin/cppcheck; cat debian/substvars
shlibs:Depends=libc6 (>= 2.32), [...]

(Not really sure about the severity. I believe the resulting bugs in packagage 
using dpkg-shlipdeps are "serious".)

Best regards,
  Joachim

-- Package-specific info:
System tainted due to merged-usr-via-aliased-dirs.

-- System Information:
Debian Release: 11.1
  APT prefers stable-debug
  APT policy: (800, 'stable-debug'), (800, 'stable'), (500, 'stable-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg-dev depends on:
ii  binutils  2.35.2-2
ii  bzip2 1.0.8-4
ii  libdpkg-perl  1.20.9
ii  make  4.3-4.1
ii  patch 2.7.6-7
ii  perl  5.32.1-4+deb11u2
ii  tar   1.34+dfsg-1
ii  xz-utils  5.2.5-2

Versions of packages dpkg-dev recommends:
ii  build-essential  12.9
ii  clang-11 [c-compiler]1:11.0.1-2
ii  fakeroot 1.25.3-1.1
ii  gcc [c-compiler] 4:10.2.1-1
ii  gcc-10 [c-compiler]  10.2.1-6
ii  gnupg2.2.27-2
ii  gpgv 2.2.27-2
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2021.07.26

-- no debconf information

Bug#996380: Explanation

[Daniel Leidert]

It seems here is an explanation of the problem:
https://github.com/paolobrasolin/jekyll-antex/issues/16

I cannot find any patches so far.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


signature.asc
Description: This is a digitally signed message part

Bug#1000420: irqtop output is messed up by ruby warning

[Yvan Masson]

Package: irqtop
Version: 2.5.1-2
Severity: normal

Dear Maintainer,

When running irqtop interactively (without `--batch` option), output is 
messed up on each refresh by lines of this type:


/usr/bin/irqtop:xxx: warning: rb_safe_level will be removed in Ruby 3.0

Removing this warning would be great so that we can use irqtop without 
the `--batch` option.


Sorry but I did not take time to try it on testing or unstable.

Regards,
Yvan

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages irqtop depends on:
ii  ruby 1:2.7+2
ii  ruby-curses  1.2.4-1+b4

Versions of packages irqtop recommends:
ii  ethtool  1:5.9-1

irqtop suggests no packages.

-- no debconf information



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000419: pymatgen: FTBFS - Test failure: BSPlotterProjectedTest.test_methods

[Stefano Rivera]

Source: pymatgen
Version: 2022.0.14+dfsg1-1
Severity: serious
Justification: FTBFS

Presumably due to a new matplotlib, but I'm just guessing...

.pybuild/test_python3.9/pymatgen/electronic_structure/tests/test_plotter.py . [ 
55%]
.F

=== FAILURES ===
_ BSPlotterProjectedTest.test_methods __

self = 

def test_methods(self):
self.plotter.get_elt_projected_plots().close()
self.plotter.get_elt_projected_plots_color().close()
self.plotter.get_projected_plots_dots({"Cu": ["d", "s"], "O": 
["p"]}).close()
>   self.plotter.get_projected_plots_dots_patom_pmorb(
{"Cu": ["dxy", "s", "px"], "O": ["px", "py", "pz"]},
{"Cu": [3, 5], "O": [1]},
).close()

.pybuild/test_python3.9/pymatgen/electronic_structure/tests/test_plotter.py:220:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
.pybuild/test_python3.9/pymatgen/electronic_structure/plotter.py:1651: in 
get_projected_plots_dots_patom_pmorb
plt.subplot(row + 1, 2, count)
/usr/lib/python3/dist-packages/matplotlib/pyplot.py:1268: in subplot
key = SubplotSpec._from_subplot_args(fig, args)
/usr/lib/python3/dist-packages/matplotlib/gridspec.py:595: in _from_subplot_args
gs = GridSpec._check_gridspec_exists(figure, rows, cols)
/usr/lib/python3/dist-packages/matplotlib/gridspec.py:223: in 
_check_gridspec_exists
return GridSpec(nrows, ncols, figure=figure)
/usr/lib/python3/dist-packages/matplotlib/gridspec.py:383: in __init__
super().__init__(nrows, ncols,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <[AttributeError("'GridSpec' object has no attribute 
'_row_height_ratios'") raised in repr()] GridSpec object at 0x7f507628bf40>
nrows = 5.5, ncols = 2, height_ratios = None, width_ratios = None

def __init__(self, nrows, ncols, height_ratios=None, width_ratios=None):
"""
Parameters
--
nrows, ncols : int
The number of rows and columns of the grid.
width_ratios : array-like of length *ncols*, optional
Defines the relative widths of the columns. Each column gets a
relative width of ``width_ratios[i] / sum(width_ratios)``.
If not given, all columns will have the same width.
height_ratios : array-like of length *nrows*, optional
Defines the relative heights of the rows. Each column gets a
relative height of ``height_ratios[i] / sum(height_ratios)``.
If not given, all rows will have the same height.
"""
if not isinstance(nrows, Integral) or nrows <= 0:
>   raise ValueError(
f"Number of rows must be a positive integer, not {nrows!r}")
E   ValueError: Number of rows must be a positive integer, not 5.5

/usr/lib/python3/dist-packages/matplotlib/gridspec.py:47: ValueError
- Captured stdout call -
You do not want to sum projection over orbitals.
You do not want to sum projection over atoms.
Number of subfigures: 9
{'start_index': 0, 'end_index': 15, 'name': '\\Gamma-X'}
{'start_index': 16, 'end_index': 31, 'name': 'X-M'}
{'start_index': 32, 'end_index': 47, 'name': 'M-\\Gamma'}
{'start_index': 48, 'end_index': 63, 'name': '\\Gamma-R'}
{'start_index': 64, 'end_index': 79, 'name': 'R-X'}
{'start_index': 80, 'end_index': 95, 'name': 'M-R'}
dictio_d: {'Cu': ['dxy', 's', 'px'], 'O': ['px', 'py', 'pz']}
dictpa_d: {'Cu': ['3', '5'], 'O': ['1']}
=== warnings summary ===


See: 
https://buildd.debian.org/status/fetch.php?pkg=pymatgen=amd64=2022.0.14%2Bdfsg1-1%2Bb1=1637567905=0

SR

Bug#1000418: rust-nitrocli: Please package new version 0.4.1

[Jeremy Stanley]

Source: rust-nitrocli
Version: 0.2.4-1
Severity: wishlist

Dear Maintainer,

Now that the bullseye freeze is behind us, it would be nice to have a
new version of nitrocli. The currently packaged version is several years
old, and lacks support for recent hardware (e.g. my Librem Key fobs).
I've been compiling this myself from source, but would much prefer to be
able to install a binary package, as I'm sure would users who aren't as
comfortable building things like this on their own. Thanks!

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (400, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[David Prévot]

Hi Ondřej,

Le 22/11/2021 à 09:15, David Prévot a écrit :

Le 22/11/2021 à 08:45, Ondřej Surý a écrit :

 > Or we could stop delaying the inevitable[1] and instead of bumping
 > epoch just go ahead with the transition.

You don’t need to bump epoch


Please find attached a short debdiff that fixes the issue at hand 
(restoring php7.4 as default in unstable), without an epoch (the ugly 
2:8.1+85+really7.4+87+nmu1 version being higher than 2:8.1+85, the 
binary packages won’t be rejected, and will disappear as soon as you’ll 
upload a higher version (e.g. 88) without this change when the php8.1 
transition will start, 2:8.1+88 being higher than 
2:8.1+85+really7.4+87+nmu1).


I’ve tested that the new binary packages are now allowed to be installed 
and that related packages can again be built.


I’m happy to upload it if you or the release team agree. I don’t mind if 
the transition gets started right now either (even if we have no proper 
php8.1 as default in experimental to get a grasp of expected issues).


Regards

Daviddiff -Nru php-defaults-87/debian/changelog php-defaults-87+nmu1/debian/changelog
--- php-defaults-87/debian/changelog	2021-11-20 03:20:12.0 -0400
+++ php-defaults-87+nmu1/debian/changelog	2021-11-22 16:34:09.0 -0400
@@ -1,3 +1,11 @@
+php-defaults (87+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Ensure binary packages get a higher version for the revert
+  * Don’t depend on PHP 8.0 packages
+
+ -- David Prévot   Mon, 22 Nov 2021 16:34:09 -0400
+
 php-defaults (87) unstable; urgency=medium
 
   * Revert "Start the transition to PHP 8.0"
diff -Nru php-defaults-87/debian/rules php-defaults-87+nmu1/debian/rules
--- php-defaults-87/debian/rules	2021-11-20 03:20:12.0 -0400
+++ php-defaults-87+nmu1/debian/rules	2021-11-22 16:34:09.0 -0400
@@ -10,7 +10,7 @@
 include /usr/share/dpkg/default.mk
 
 PHP_DEFAULT_VERSION:= 7.4
-PHP_SUPPORTED_VERSIONS := 7.4 8.0
+PHP_SUPPORTED_VERSIONS := 7.4
 PHP_BREAKS_VERSIONS := 5.6 7.0 7.1 7.2 7.3
 
 , := ,
@@ -20,7 +20,7 @@
 PHP_COMMON_DIRS:= $(addprefix /etc/php/,$(addsuffix /mods-available,$(PHP_SUPPORTED_VERSIONS)))
 
 PHP_COMMON_DEB_VERSION := 2:$(DEB_VERSION)
-PHP_DEB_VERSION:= 2:$(PHP_DEFAULT_VERSION)+$(DEB_VERSION)
+PHP_DEB_VERSION:= 2:8.1+85+really$(PHP_DEFAULT_VERSION)+$(DEB_VERSION)
 
 SED=sed
 

Bug#1000417: devscripts: autopkgtest regression: zstd: not found

[Paul Gevers]

Source: devscripts
Version: 2.21.5
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of devscripts the autopkgtest of devscripts fails 
in testing when that autopkgtest is run with the binary packages of 
devscripts from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
devscripts from testing2.21.5
all others from testingfrom testing

I copied some of the output at the bottom of this report. Seems like 
you're missing a (test) dependency.


Currently this regression is blocking the migration to testing [1]. 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

[1] https://qa.debian.org/excuses.php?package=devscripts

https://ci.debian.net/data/autopkgtest/testing/amd64/d/devscripts/16896916/log.gz

testSymlink
testSymlinkWithConvertedSig
testSymlinkWithArmoredSig
testCopy
testRename
testSymlinkExplicit
testCopyExplicit
testRenameExplicit
testSymlinkExplicitSubdir
testRepackGZ2GZ
testForceRepackGZ2XZ
testRepackGZ2XZ
testRepackXZ2GZ
testRepackZST2XZRepackOpt
/bin/sh: 1: zstd: not found
tar: /tmp/shunit.58aiKV/tmp/test_mk-origtargz.zy3M/foo-0.1.tar.zst: 
Cannot write: Broken pipe

tar: Child returned status 127
tar: Error is not recoverable: exiting now
ASSERT:standard output of mk-origtargz --package foo --version 0.1 
--copy foo-0.1.tar.zst --repack\n expected:foo-0.1.tar.zst as foo_0.1.orig.tar.xz.> but was:<>
ASSERT:error output of mk-origtargz --package foo --version 0.1 --copy 
foo-0.1.tar.zst --repack\n expected:<> but was:Unknown compression used in foo-0.1.tar.zst>

ASSERT:result does not exist
ASSERT:filetype for foo_0.1.orig.tar.xz expected: but 
was:`/tmp/shunit.58aiKV/tmp/test_mk-origtargz.zy3M/foo_0.1.orig.tar.xz' (No 
such file or directory)>

testRepackZST2XZNoRepackOpt
/bin/sh: 1: zstd: not found
tar: /tmp/shunit.58aiKV/tmp/test_mk-origtargz.gH3Z/foo-0.1.tar.zst: 
Cannot write: Broken pipe

tar: Child returned status 127
tar: Error is not recoverable: exiting now
ASSERT:standard output of mk-origtargz --package foo --version 0.1 
--copy foo-0.1.tar.zst\n expected:as foo_0.1.orig.tar.xz.> but was:<>
ASSERT:error output of mk-origtargz --package foo --version 0.1 --copy 
foo-0.1.tar.zst\n expected:<> but was:compression used in foo-0.1.tar.zst>

ASSERT:result does not exist
ASSERT:filetype for foo_0.1.orig.tar.xz expected: but 
was:`/tmp/shunit.58aiKV/tmp/test_mk-origtargz.gH3Z/foo_0.1.orig.tar.xz' (No 
such file or directory)>

testRepackZST2ZSTFail
/bin/sh: 1: zstd: not found
tar: /tmp/shunit.58aiKV/tmp/test_mk-origtargz.EdLV/foo-0.1.tar.zst: 
Cannot write: Broken pipe

tar: Child returned status 127
tar: Error is not recoverable: exiting now
testRepackZip2GZ
testRepackJar2GZ
testRepackZip2GZRename
testRepackZip2XZ
testRepackXpi2XZ
testRepackTAR2XZ
testOldFormat
testExclude
testGoVendorIncludeIgnore
testExcludeXZ
testExcludeZip
testSuffix
testSuffixXZ
testSuffixZip
testSuffixNoExclusions
testSameNameSymlink
testSameNameCopy
testSameNameRename
testSameNameExclude
testSameNameExcludeSymlink
testCopyrightFormatWarning
testBrokenTarWarning
testUnmatchedExclusion
testDuplicatePattern

Ran 40 tests.

FAILED (failures=8)
make[1]: *** [Makefile:43: test_mk-origtargz.test_installed] Error 1
make[1]: Leaving directory 
'/tmp/autopkgtest-lxc.7_8glf45/downtmp/build.uPh/src/test'

make: *** [Makefile:47: test-installed] Error 2
autopkgtest [11:12:56]: test shunit2




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000416: ITP: golang-github-tklauser-numcpus -- Go module to get the number of CPUs on a Linux/BSD system

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-tklauser-numcpus
  Version : 0.3.0-1
  Upstream Author : Tobias Klauser
* URL : https://github.com/tklauser/numcpus
* License : Apache-2.0
  Programming Lang: Go
  Description : Go module to get the number of CPUs on a Linux/BSD system

This package is needed for golang-github-shirou-gopsutil v3.
Cheers,

Bug#1000415: ITP: golang-github-tklauser-go-sysconf -- sysconf for Go, without using cgo

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-tklauser-go-sysconf
  Version : 0.3.9-1
  Upstream Author : Tobias Klauser
* URL : https://github.com/tklauser/go-sysconf
* License : BSD-3-clause
  Programming Lang: Go
  Description : sysconf for Go, without using cgo

This package is needed for golang-github-shirou-gopsutil v3.
Cheers,

Bug#1000414: textdistance: autopkgtest regression on arm64: AssertionError: assert 3.0 <= 1

[Paul Gevers]

Source: textdistance
Version: 4.2.2-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of textdistance the autopkgtest of textdistance 
fails in testing when that autopkgtest is run with the binary packages 
of textdistance from unstable on arm64. It passes when run with only 
packages from testing. In tabular form:


   passfail
textdistance   from testing4.2.2-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. 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

[1] https://qa.debian.org/excuses.php?package=textdistance

https://ci.debian.net/data/autopkgtest/testing/arm64/t/textdistance/16584010/log.gz

=== FAILURES 
===
___ test_normalization_range[alg23] 



alg = Editex({'match_cost': 0, 'group_cost': 1, 'mismatch_cost': 2, 
'local': False, 'external': True, 'grouped': frozenset({'U', 'B', 'K', 
'F', 'D', 'M', 'X', 'S', 'Z', 'T', 'C', 'P', 'Q', 'E', 'N', 'J', 'G', 
'V', 'L', 'I', 'R', 'O', 'A', 'Y'})})


@pytest.mark.parametrize('alg', ALGS)

  @hypothesis.given(

left=hypothesis.strategies.text(),
right=hypothesis.strategies.text(),
)

tests/test_common.py:50: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

left = '0', right = 'ῢ'
alg = Editex({'match_cost': 0, 'group_cost': 1, 'mismatch_cost': 2, 
'local': False, 'external': True, 'grouped': frozenset({'U', 'B', 'K', 
'F', 'D', 'M', 'X', 'S', 'Z', 'T', 'C', 'P', 'Q', 'E', 'N', 'J', 'G', 
'V', 'L', 'I', 'R', 'O', 'A', 'Y'})})


@pytest.mark.parametrize('alg', ALGS)
@hypothesis.given(
left=hypothesis.strategies.text(),
right=hypothesis.strategies.text(),
)
def test_normalization_range(left, right, alg):

  assert 0 <= alg.normalized_distance(left, right) <= 1

E   AssertionError: assert 3.0 <= 1
E+  where 3.0 = Editex({'match_cost': 0, 'group_cost': 1, 'mismatch_cost': 2, 'local': 
False... 'B', 'K', 'F', 'D', 'M', 'X', 'S', 'Z', 'T', 'C', 'P', 'Q', 
'E', 'N', 'J', 'G', 'V', 'L', 'I', 'R', 'O', 'A', 'Y'})})>('0', 'ῢ')
E+where Editex({'match_cost': 0, 'group_cost': 1, 'mismatch_cost': 2, 'local': 
False... 'B', 'K', 'F', 'D', 'M', 'X', 'S', 'Z', 'T', 'C', 'P', 'Q', 
'E', 'N', 'J', 'G', 'V', 'L', 'I', 'R', 'O', 'A', 'Y'})})> = 
Editex({'match_cost': 0, 'group_cost': 1, 'mismatch_cost': 2, 'local': 
False, 'external': True, 'grouped': frozenset({'U', 'B', 'K', 'F', 'D', 
'M', 'X', 'S', 'Z', 'T', 'C', 'P', 'Q', 'E', 'N', 'J', 'G', 'V', 'L', 
'I', 'R', 'O', 'A', 'Y'})}).normalized_distance


tests/test_common.py:55: AssertionError
-- Hypothesis 
--

Falsifying example: test_normalization_range(
left='0',
right='ῢ',
alg=Editex({'match_cost': 0, 'group_cost': 1, 'mismatch_cost': 2, 
'local': False, 'external': True, 'grouped': frozenset({'U', 'B', 'K', 
'F', 'D', 'M', 'X', 'S', 'Z', 'T', 'C', 'P', 'Q', 'E', 'N', 'J', 'G', 
'V', 'L', 'I', 'R', 'O', 'A', 'Y'})}),

)
=== warnings summary 
===

tests/test_external.py:16

/tmp/autopkgtest-lxc.iu33ychk/downtmp/autopkgtest_tmp/tests/test_external.py:16: 
PytestUnknownMarkWarning: Unknown pytest.mark.external - is this a typo? 
 You can register custom marks to avoid this warning - for details, see 
https://docs.pytest.org/en/stable/mark.html

@pytest.mark.external

tests/test_external.py:39

/tmp/autopkgtest-lxc.iu33ychk/downtmp/autopkgtest_tmp/tests/test_external.py:39: 
PytestUnknownMarkWarning: Unknown pytest.mark.external - is this a typo? 
 You can register custom marks to avoid this warning - for details, see 
https://docs.pytest.org/en/stable/mark.html

@pytest.mark.external

tests/test_external.py:67

/tmp/autopkgtest-lxc.iu33ychk/downtmp/autopkgtest_tmp/tests/test_external.py:67: 
PytestUnknownMarkWarning: Unknown pytest.mark.external - is this a typo? 
 You can register custom marks to avoid this warning - for details, see 
https://docs.pytest.org/en/stable/mark.html

@pytest.mark.external

-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== short test summary info 

FAILED tests/test_common.py::test_normalization_range[alg23] - 
AssertionError...
== 1 failed, 397 passed, 3 warnings in 54.22s 
==

autopkgtest [23:19:58]: test pytest




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000413: discosnp: autopkgtest regression: Segmentation fault

[Paul Gevers]

Source: discosnp
Version: 1:2.5.4-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of discosnp the autopkgtest of discosnp fails in 
testing when that autopkgtest is run with the binary packages of 
discosnp from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
discosnp   from testing1:2.5.4-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. As the test 
passes in unstable and because of bug #998143 I wonder if the update of 
gatb-core wasn't an ABI breakage and should have seen a SONAME bump and 
a proper transition. As this package and gatb-core are handled in the 
same team, I'll leave you to figure it out. I think you'd want to block 
gatb-core from migrating.


Currently this regression is blocking the migration to testing [1]. 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

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
discosnp/1:2.5.4-1. I.e. due to versioned dependencies or breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=discosnp

https://ci.debian.net/data/autopkgtest/testing/amd64/d/discosnp/16901493/log.gz
https://ci.debian.net/data/autopkgtest/testing/amd64/d/discosnp/16901493/log.gz

tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified


 Running discoSnp++ 2.3.X, in directory /usr with following parameters:
 read_sets=fof.txt
 prefix=discoRes_k_31_c_3
 c=3
 C=2147483647
 k=31
 b=0
 d=1
 D=100
 s=
 P=3
 p=discoRes
 G=
 e=
 starting date=Mon Nov 22 15:13:02 UTC 2021


 
  GRAPH CREATION  ###
 
/usr/bin/dbgh5 -in 
fof.txt_discoRes_k_31_c_3_D_100_P_3_b_0_removemeplease -out 
discoRes_k_31_c_3 -kmer-size 31 -abundance-min 3 -abundance-max 
2147483647 -solidity-kind one -verbose 1 -skip-bcalm -skip-bglue -no-mphf


[DSK: counting kmers ]  0%   elapsed:   0 min 0 
 sec   remaining:   0 min 0  sec   cpu:  -1.0 %   mem: [  25,   25, 
57] MB [DSK: Pass 1/1, Step 1: partitioning ]  0%   elapsed:   0 
min 0  sec   remaining:   0 min 0  sec   cpu:  -1.0 %   mem: [  53, 
53,   57] MB [DSK: Pass 1/1, Step 2: counting kmers   ]  26.4 % 
elapsed:   0 min 1  sec   remaining:   0 min 3  sec   cpu: 102.7 % 
mem: [  86,   86,  847] MB [DSK: Pass 1/1, Step 2: counting kmers   ] 
26.4 %   elapsed:   0 min 1  sec   remaining:   0 min 3  sec   cpu: 
102.7 %   mem: [  86,   86,  847] MB [DSK: Pass 1/1, Step 2: counting 
kmers   ]  26.4 %   elapsed:   0 min 1  sec   remaining:   0 min 3  sec 
  cpu: 102.7 %   mem: [  86,   86,  847] MB [DSK: Pass 1/1, Step 2: 
counting kmers   ]  26.4 %   elapsed:   0 min 1  sec   remaining:   0 
min 3  sec   cpu: 102.7 %   mem: [  86,   86,  847] MB [DSK: Pass 1/1, 
Step 2: counting kmers   ]  26.4 %   elapsed:   0 min 1  sec 
remaining:   0 min 3  sec   cpu: 102.7 %   mem: [  86,   86,  847] MB 
[DSK: Pass 1/1, Step 2: counting kmers   ]  26.4 %   elapsed:   0 min 1 
 sec   remaining:   0 min 3  sec   cpu: 102.7 %   mem: [  86,   86, 
847] MB [DSK: Pass 1/1, Step 2: counting kmers   ]  26.4 %   elapsed: 
0 min 1  sec   remaining:   0 min 3  sec   cpu: 102.7 %   mem: [  86, 
86,  847] MB [DSK: Pass 1/1, Step 2: counting kmers   ]  26.4 % 
elapsed:   0 min 1  sec   remaining:   0 min 3  sec   cpu: 102.7 % 
mem: [  86,   86,  847] MB [DSK: Pass 1/1, Step 2: counting kmers   ] 
26.4 %   elapsed:   0 min 1  sec   remaining:   0 min 3  sec   cpu: 
102.7 %   mem: [  86,   86,  847] MB [DSK: Pass 1/1, Step 2: counting 
kmers   ]  26.4 %   elapsed:   0 min 1  sec   remaining:   0 min 3  sec 
  cpu: 102.7 %   mem: [  86,   86,  847] MB [DSK: Pass 1/1, Step 2: 
counting kmers   ]  26.4 %   elapsed:   0 min 1  sec   remaining:   0 
min 3  sec   cpu: 102.7 %   mem: [  86,   86,  847] MB [DSK: Pass 1/1, 
Step 2: counting kmers   ]  26.4 %   elapsed:   0 min 1  sec 
remaining:   0 min 3  sec   cpu: 102.7 %   mem: [  86,   86,  847] MB 
[DSK: Pass 1/1, Step 2: counting kmers   ]  26.4 %   elapsed:   0 min 1 
 sec   remaining:   0 min 3  sec   cpu: 102.7 %   mem: [  86,   86, 
847] MB [DSK: 

Bug#997718: glewlwyd: FTBFS: Module not found: Error: Can't resolve 'cross-fetch' in '/<>/webapp-src/node_modules/i18next-http-backend/cjs'

[Nicolas Mora]

Hello,

The package node-cross-fetch is in the NEW queue [1].
When it will be accepted in unstable, a quick change in the package 
i18next-http-backend will fix glewlwyd's ftbfs.


/Nicolas

[1] https://ftp-master.debian.org/new/node-cross-fetch_3.1.4%2Bds.1-1.html

Bug#1000412: poetry-core: autopkgtest regression: No such file or directory: 'git'

[Paul Gevers]

Source: poetry-core
Version: 1.0.7-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of poetry-core the autopkgtest of poetry-core fails 
in testing when that autopkgtest is run with the binary packages of 
poetry-core from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
poetry-corefrom testing1.0.7-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. 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

[1] https://qa.debian.org/excuses.php?package=poetry-core

https://ci.debian.net/data/autopkgtest/testing/amd64/p/poetry-core/16881615/log.gz


=== FAILURES 
===
__ test_git_clone_raises_error_on_invalid_repository 
___


def test_git_clone_raises_error_on_invalid_repository():
with pytest.raises(GitError):

  Git().clone("-u./payload", Path("foo"))


tests/vcs/test_vcs.py:273: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/poetry/core/vcs/git.py:228: in __init__

self._config = GitConfig(requires_git_presence=True)
/usr/lib/python3/dist-packages/poetry/core/vcs/git.py:206: in __init__
subprocess.check_output(
/usr/lib/python3.9/subprocess.py:424: in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
/usr/lib/python3.9/subprocess.py:505: in run
with Popen(*popenargs, **kwargs) as process:
/usr/lib/python3.9/subprocess.py:951: in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

self = 
args = ['git', 'config', '-l'], executable = b'git', preexec_fn = None
close_fds = True, pass_fds = (), cwd = None, env = None, startupinfo = None
creationflags = 0, shell = False, p2cread = -1, p2cwrite = -1, c2pread = 11
c2pwrite = 12, errread = -1, errwrite = 12, restore_signals = True, gid 
= None

gids = None, uid = None, umask = -1, start_new_session = False

def _execute_child(self, args, executable, preexec_fn, close_fds,
   pass_fds, cwd, env,
   startupinfo, creationflags, shell,
   p2cread, p2cwrite,
   c2pread, c2pwrite,
   errread, errwrite,
   restore_signals,
   gid, gids, uid, umask,
   start_new_session):
"""Execute program (POSIX version)"""
if isinstance(args, (str, bytes)):
args = [args]
elif isinstance(args, os.PathLike):
if shell:
raise TypeError('path-like args is not allowed when '
'shell is true')
args = [args]
else:
args = list(args)
if shell:
# On Android the default shell is at '/system/bin/sh'.
unix_shell = ('/system/bin/sh' if
  hasattr(sys, 'getandroidapilevel') else '/bin/sh')
args = [unix_shell, "-c"] + args
if executable:
args[0] = executable
if executable is None:
executable = args[0]
sys.audit("subprocess.Popen", executable, args, cwd, env)
if (_USE_POSIX_SPAWN
and os.path.dirname(executable)
and preexec_fn is None
and not close_fds
and not pass_fds
and cwd is None
and (p2cread == -1 or p2cread > 2)
and (c2pwrite == -1 or c2pwrite > 2)
and (errwrite == -1 or errwrite > 2)
and not start_new_session
and gid is None
and gids is None
and uid is None
and umask < 0):
self._posix_spawn(args, executable, env, restore_signals,
  p2cread, p2cwrite,
  c2pread, c2pwrite,
  errread, errwrite)
return
orig_executable = executable
# For transferring possible exec failure from child to parent.
# Data format: "exception name:hex errno:description"
# Pickle is not used; it is complex and involves memory allocation.
errpipe_read, errpipe_write = os.pipe()
# errpipe_write must not be in the standard io 0, 1, or 2 fd range.
low_fds_to_close = []
while errpipe_write < 3:

Bug#1000411: RFP: omegasort -- versatile text file sorting tool

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Go Packaging Team 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: omegasort
  Version : 0.0.5
  Upstream Author : David Rolsky 
* URL : https://github.com/houseabsolute/omegasort
* License : BSD-3-clause
  Programming Lang: Go
  Description : versatile text file sorting tool

 Omegasort is a text file sorting tool
 that aims to be the last sorting tool you'll need.
 .
 It was written to help keep various types of files in a sorted order
 (gitignore files, lists of spelling stopwords, etc.)
 where it could be called as part of commit hooks and CI,
 e.g. using the code quality tool "precious".

I am packaging "precious" which works nicely together with omegasort.

I am not comfortable maintaining Go code, however,
so am filing this as a Request For Packaging.

I have cc'ed the Golang team in the hope they might grab this.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGcH1QACgkQLHwxRsGg
ASHnXg/8DgXzL/F9gffuiq6jv9duoHzR/glIKeTs8FdIyhYqN6HXaXqnBbJEE10A
DP/+ixHO47hit+iRQS4QnajpGBClbhdI0taacjyxX/Yfp/fsJE4MNgxRZttG6Plq
3Q/w7RHFkczwWAcAF5wPC5+LpA8ICsyyhpHTloSR/rnrlB4B6swVSUZtIsl1W/hc
CjG264B91D+MxYSVra3cgESmentCkraswCDDvwrPic2ncnzsBYodmLAKU0FrkHlb
Ds5yu1vpWGKTvi+TYBiGbAp1p/qbqaGKEO8xf2IuQ0nTpizrSZp8mwrbY8jWq9NR
SBB70Cf/bQXShpP2ktwgpJAkaWL41L6CbJo9BBGlZ1cVtkTUrlmJQzj2SepNBLTj
4OlKDrX6gqvmuDzJTY7pA1jxdUaHq6CN2tvDs3qIdkwVslK9H1Azt4JYWGPugS4S
mWCJdbef9S8MzSTijnhHoL+gGGH+aGeVxVdWd6ivx1INLF1tcPEOLWjc06glCMeC
MPukaV/akW/OarJ6sAUyW4cfzaC3CA8bQMbONfezSuX8WCjoukdgUMCl0anmj8+X
8hLXwmgxNdDqb8voE7t1z6sg0lhRKsMu8oPwRAZfCdZmTIBCzVv6GW91rFSuKbZm
NS1g05rT7bXMklob0yZsBnXjUM9+IezAONHqH3HWYtbhMUdvwAA=
=rlrr
-END PGP SIGNATURE-

Bug#998353: src:win32-loader: fails to migrate to testing for too long

[Paul Gevers]

Dear Debian-boot,

On Tue, 2 Nov 2021 20:55:11 +0100 Paul Gevers  wrote:

Can somebody please judge if win32-loader should
migrate in the current state and take appropriate actions if so: contact
ftp to process the package on their side and update bug 982838 (I
wouldn't close it, but reuse it after migration) with the right meta
info such that the bug doesn't block migration? If help is needed,
please reach out to the Release Team.


I didn't see any follow-up on this request. I had a look at the 
changelog, it seems trivial. Is it worth doing the ftp-master dance?


 win32-loader (0.10.5) unstable; urgency=medium
 .
   [ Valentin Vidic ]
   * Update Croatian translation
 .
   [ Didier Raboud ]
   * Run wrap-and-sort -baskt
   * Remove myself from Uploaders

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1

[Otto Kekäläinen]

> > mariadb-10.5 (1:10.5.13-0+deb11u1) bullseye; urgency=medium
> >
> >* New upstream version 10.5.13. Includes security fixes for:
> >  - CVE-2021-35604
> >* Drop MIPS and libatomic patches applied now upstream
> >
> >   -- Otto Kekäläinen   Sat, 20 Nov 2021 12:53:28 -0800
>
> Please also fix #994284 in this PU as it still affects the version in
> bullseye.

Thanks for the reminder, this indeed is a valid fix for a stable
upload. Pushed in git on bullseye branch.
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2313ef33b1a1adb8299faa3827bd4c519362a641

Bug#1000374: transition: opencv

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-11-22 10:26:43 +0100, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I would like to transition OpenCV with a bumped SOVERSION after
> an ABI breakage by upstream [1].
> 
> The Ben file [2] looks good.

Why does the name of the -java package get changed? For the Java ABI
nothing changes in this case. If you compare the produced class files,
the only difference is that libopencv_java454d.so is loaded instead of
libopencv_java454.so.

Cheers

> 
> 
> Cheers
> Timo
> 
> [1] https://github.com/opencv/opencv/issues/20878
> [2] https://release.debian.org/transitions/html/auto-opencv.html
> 
> 
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1000410: Fwd: Install Debian 11 on Allwinner A20 failed

[SaM SaM]

Package: installation-reports

Hello  Debian Team,

I tried to instal Debian 11 on my BananaPI R1 (Lamobo R1) because I needed
a newer kernel version for my application with the BPI.
System Ready SD-Card Images around only have older Kernels.

Package: installation-reports

Boot method: https://wiki.debian.org/InstallingDebianOn/Allwinner
with the Files ...
https://deb.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/firmware.Lamobo_R1.img.gz
& 
https://deb.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/partition.img.gz
>
Date: <22.11.2021>

Machine: 
Processor: Allwinner A20
Memory: 1Gig
Partitions:
~ # df -T
Filesystem   Type   1K-blocks  Used Available Use% Mounted on
tmpfstmpfs 10207212102060   0% /run
devtmpfs devtmpfs  449132 0449132   0% /dev

Output of lspci -knn (or lspci -nn):
Is not working in the Installer Shell

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [E]
Detect media:   [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Under U-boot the Keybord was detected.

When the Linux installer is ready, the Keyboard isn't working any more.

I bought a Serial UART Debug device and now I am able to go through
the Linux Installer via Serial Console. Unfortunately I was only able
to select English for the Language.

But later on the Network Interface seems not to work.

I know the Network Controler of the Lamobo R1 is not an easy one. I am
still a Linux padawan and lightyears away from a Jedi status, but I
hope you can give me some advice to get the System up running.

with kind regards from Germany - Sascha Martens


Here is the Information Screen in Linux Installer with the Network detection

[(1*installer)  2 shell  3 shell  4- log   ][ Jan 01  0:26 ]





   lu [!!] Configure the network tqk
   x   x
   x   Network autoconfiguration failedx
   x Your network is probably not using the DHCP protocol. Alternatively,  x
   x the DHCP server may be slow or some network hardware is not working   x
   x properly. x
   x   x
   x x
   x   x
   mqqqj







 moves;  selects;  activates buttons


*Here is the Information which is transferred over the Serial Debug Console.*

U-Boot SPL 2021.01+dfsg-5 (May 23 2021 - 04:32:45 +)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1


U-Boot 2021.01+dfsg-5 (May 23 2021 - 04:32:45 +) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Lamobo R1
I2C:   ready
DRAM:  1 GiB
MMC:   mmc@1c0f000: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

HDMI connected: EDID: invalid EDID data
In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@1c5
starting USB...
Bus usb@1c14000: USB EHCI 1.00
Bus usb@1c14400: USB OHCI 1.0
Bus usb@1c1c000: USB EHCI 1.00
scanning bus usb@1c14000 for devices... 1 USB Device(s) found
scanning bus usb@1c14400 for devices... 1 USB Device(s) found
scanning bus usb@1c1c000 for devices... 2 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
1575 bytes read in 2 ms (768.6 KiB/s)
## Executing script at 4310
Mainline u-boot / new-style environment detected.
4956672 bytes read in 278 ms (17 MiB/s)
26960 bytes read in 12 ms (2.1 MiB/s)
22629196 bytes read in 1265 ms (17.1 MiB/s)
Booting the Debian installer...

## Flattened Device Tree blob at 4300
   Booting using the fdt blob at 0x4300
EHCI failed to shut down host controller.
   Loading Ramdisk to 48a6b000, end 49fffb4c ... OK
   Loading Device Tree to 48a61000, end 48a6a94f ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 5.10.0-9-armmp
(debian-ker...@lists.debian.org) (gc
c-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils
for Debian) 2.35.2)#1 SMP
Debian 5.10.70-1 (2021-09-30)
[0.00] CPU: ARMv7 

Bug#1000409: ITP: dyssol -- tool for dynamic flowsheet simulation

[Anton Gladky]

Package: wnpp
Severity: wishlist
Owner: Anton Gladky 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: dyssol
  Version : 1.0
  Upstream Author : Dyssol Development Team
* URL : https://github.com/FlowsheetSimulation/Dyssol-open
* License : MIT
  Programming Lang: C++
  Description : tool for dynamic flowsheet simulation


Dyssol, the dynamic simulation of solids processes, is a novel dynamic
flowsheet modelling system designed to simulate the time-dependent behaviour
of complex production processes in solids processing technology. Key features 
including:

1. Dynamic simulation of flowsheets to reflect the time-dependent behaviour of 
processes
   and to take into account the accumulation of mass and energy;
2. Proper calculation of multidimensional distributed parameters of the solid 
phase,
   considering their possible interdependence;
3. Flexibility and extensibility of the system for adding new models of 
apparatuses and solvers.

And distinctive features including:
  * Dynamic simulation of complex process structures;
  * Advanced calculation algorithm for dynamic simulations;
  * Consideration of solid, liquid, gas phases and their mixtures;
  * Proper handling of multidimensional interdependent distributed parameters 
of solids;
  * Providing standardized interfaces and templates for implementation of new 
units;
  * High modularity and extensibility.

The package will be maintained under the roof of Debian Science Team.


Anton
  

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmGb41ARHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wbdxA//aq+1NKUl9sJHwOuSTKTNJhvnckSaQNMa
sGMW4z0oMJFzn15TWN960SeNdBufQzydJHhQ9Ee6wvjOIZGxD0iSFFwkXKYEucwk
+fgx4sZQP85P+nnp3YbnPHpsnHGnNgffVOpkCc2ugJwU3KqVpF+v4S4rjc894orl
I2R7jZycy9ynay3V+400Cb77IJAz2FFvkYXhXvUryZ4BeSdhuSPQ/lWQdBUqaJ+I
h4PVAnCUQTS140wUsbsfiVWELXSId0Z6BRQO+39tPAWg/mj67lRIYyO/FgzbOFaS
H1f5sm1nOKNw3/VF3mDpYjf5n6ha4ARI+6bHvCC8DeST/8bSjRlG/vFfIDmvtAeW
uzJ5Ov8xLiwEYJQ1PwYLMGg0yITJC+YXBJYvTzi4uvpoNQuhKtTtjFoE7TtelC3Q
HBpW99r1vc3pVD5z9w22ETsdFrbhqzITz0u0DoZjgq8ooY1vTEXgZxCfNdqJzsWw
2Rrr9MnCiulngQQYFza/TCudJdEx4TBjB2BUyQnBL9FYwlxXYPKzR16ouwdaiRMe
n6fY4MAREcO8vRmnv3nNLydIa14nt7tP0/CPQWDwQoalAapi1gU8yvP3RBZWXAeA
uyrIVrlS6/Q0p3dVcSJ0DEDDHkQZN3DDQVzW/nHmynI5VXxtwLLRvGbhr9fYODfO
PSRlod/B114=
=Sxnh
-END PGP SIGNATURE-

Bug#1000408: buster-pu: package libmodbus/3.1.4-2+deb10u1

[Thorsten Alteholz]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu


The attached debdiff for libmodbus fixes CVE-2019-14462 and CVE-2019-14463 
in Buster.


These CVEs are marked as no-dsa by the security team.

For both CVEs a unit test was added and the unit-tests of the package 
showed no errors


  Thorsten
diff -Nru libmodbus-3.1.4/debian/changelog libmodbus-3.1.4/debian/changelog
--- libmodbus-3.1.4/debian/changelog2018-12-19 04:14:47.0 +0100
+++ libmodbus-3.1.4/debian/changelog2021-11-20 22:03:02.0 +0100
@@ -1,3 +1,13 @@
+libmodbus (3.1.4-2+deb10u1) buster; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2019-14462 + CVE-2019-14463
+out of bound reads for MODBUS_FC_WRITE_MULTIPLE_REGISTERS and
+MODBUS_FC_WRITE_MULTIPLE_COILS 
+  * add unit test for CVEs above
+
+ -- Thorsten Alteholz   Sat, 20 Nov 2021 22:03:02 +0100
+
 libmodbus (3.1.4-2) unstable; urgency=medium
 
   * Fix float endianness issue on big endian arch (Closes: #916345)
diff -Nru libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-1.patch 
libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-1.patch
--- libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-1.patch 1970-01-01 
01:00:00.0 +0100
+++ libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-1.patch 2021-11-20 
22:03:02.0 +0100
@@ -0,0 +1,37 @@
+commit 5ccdf5ef79d742640355d1132fa9e2abc7fbaefc
+Author: Stéphane Raimbault 
+Date:   Fri Jul 26 16:00:06 2019 +0200
+
+Fix VD-1301 and VD-1302 vulnerabilities
+
+This patch was contributed by Maor Vermucht and Or Peles from
+VDOO Connected Trust.
+
+Index: libmodbus-3.1.4/src/modbus.c
+===
+--- libmodbus-3.1.4.orig/src/modbus.c  2021-11-20 23:48:42.253943045 +0100
 libmodbus-3.1.4/src/modbus.c   2021-11-20 23:48:42.249943044 +0100
+@@ -831,9 +831,10 @@
+ break;
+ case MODBUS_FC_WRITE_MULTIPLE_COILS: {
+ int nb = (req[offset + 3] << 8) + req[offset + 4];
++int nb_bits = req[offset + 5];
+ int mapping_address = address - mb_mapping->start_bits;
+ 
+-if (nb < 1 || MODBUS_MAX_WRITE_BITS < nb) {
++if (nb < 1 || MODBUS_MAX_WRITE_BITS < nb || nb_bits * 8 < nb) {
+ /* May be the indication has been truncated on reading because of
+  * invalid address (eg. nb is 0 but the request contains values to
+  * write) so it's necessary to flush. */
+@@ -862,9 +863,10 @@
+ break;
+ case MODBUS_FC_WRITE_MULTIPLE_REGISTERS: {
+ int nb = (req[offset + 3] << 8) + req[offset + 4];
++int nb_bytes = req[offset + 5];
+ int mapping_address = address - mb_mapping->start_registers;
+ 
+-if (nb < 1 || MODBUS_MAX_WRITE_REGISTERS < nb) {
++if (nb < 1 || MODBUS_MAX_WRITE_REGISTERS < nb || nb_bytes * 8 < nb) {
+ rsp_length = response_exception(
+ ctx, , MODBUS_EXCEPTION_ILLEGAL_DATA_VALUE, rsp, TRUE,
+ "Illegal number of values %d in write_registers (max %d)\n",
diff -Nru libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-2.patch 
libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-2.patch
--- libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-2.patch 1970-01-01 
01:00:00.0 +0100
+++ libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-2.patch 2021-11-20 
22:03:02.0 +0100
@@ -0,0 +1,25 @@
+commit 6f915d4215c06be3c719761423d9b5e8aa3cb820
+Author: Stéphane Raimbault 
+Date:   Wed Jul 31 22:49:53 2019 +0200
+
+Fix my so stupid fix for VD-1301 vulnerability
+
+I can't believe I committed that copy/paste mistake.
+Sorry Maor Vermucht and Or Peles, excepted naming your original
+patch was OK.
+
+Thank you Karl Palsson for your review.
+
+Index: libmodbus-3.1.4/src/modbus.c
+===
+--- libmodbus-3.1.4.orig/src/modbus.c  2021-11-20 23:48:46.985943366 +0100
 libmodbus-3.1.4/src/modbus.c   2021-11-20 23:48:46.985943366 +0100
+@@ -866,7 +866,7 @@
+ int nb_bytes = req[offset + 5];
+ int mapping_address = address - mb_mapping->start_registers;
+ 
+-if (nb < 1 || MODBUS_MAX_WRITE_REGISTERS < nb || nb_bytes * 8 < nb) {
++if (nb < 1 || MODBUS_MAX_WRITE_REGISTERS < nb || nb_bytes != nb * 2) {
+ rsp_length = response_exception(
+ ctx, , MODBUS_EXCEPTION_ILLEGAL_DATA_VALUE, rsp, TRUE,
+ "Illegal number of values %d in write_registers (max %d)\n",
diff -Nru libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-unit-test.patch 
libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-unit-test.patch
--- libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-unit-test.patch 
1970-01-01 01:00:00.0 +0100
+++ libmodbus-3.1.4/debian/patches/CVE-2019-14462-14463-unit-test.patch 
2021-11-20 22:03:02.0 +0100
@@ -0,0 +1,50 @@

Bug#1000406: nginx-common: Nginx starts before DNS is ready

[Thomas Ward]

We had similar discussions on this type of issue downstream in Ubuntu 
[1] and after extensive discussions it was suggested that if someone 
wants to use network-online.target for this they do an override in their 
SystemD.


Given that network-online.target is not well defined, it was determined 
by the Ubuntu Server Team that it made more sense to leave it alone and 
let people 'customize' their configuration that way independently.


Also, keep in mind NGINX Pitfalls such as those that *rely* on DNS - you 
cannot guarantee that DNS is going to be reliable or work at boot time 
or auto startup unless you schedule the startup until long after 
networking would be configured and online.  [2]


While I do not have direct access to control the status quo on things 
for NGINX in Debian, the justification was based on this quote from the 
definition of network targets [3]:


network-online.target is a target that actively waits until the 
network is "up", where the definition of "up" is defined by the 
network management software. ... **It is strongly recommended not to 
pull in this target too liberally: for example network server software 
should generally not pull this in (since server software generally is 
happy to accept local connections even before any routable network 
interface is up), its primary purpose is network client software that 
cannot operate without network.**


(emphasis with asterisks or bold is mine)

Given that freedesktop definitions for SystemD here say "network server 
software should generally not pull this in" and NGINX is no different 
(see pitfalls [2] as I said), I think the 'network.target' vs. 
'network-online.target' argument should remain as "If you want to verify 
it works with DNS then alter your SystemD on a per system level, rather 
than having the entire packaging system for NGINX to be rewritten for 
these cases given the SystemD guidance."



Thomas


[1]: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1666368

[2]: 
https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#using-a-hostname-to-resolve-addresses


[3]: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

On 11/22/21 12:45, Jeremy Ouellet wrote:

Package: nginx-common
Severity: normal

Dear Maintainer,

I was messing with nginx remote proxy and found that it would crash on 
startup.
I looked into the service file and it depended on network.target. I 
changed it

to network-online.target so that it would work.

I beleive that nginx should wait for the network to be online before 
starting
as this makes it so you can use domain names in proxy_pass. I googled 
for this
issue and most people just give workarounds and I feel like the use 
cases for

using just nework.target are minimal.

-- System Information:
Debian Release: 11.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE not

set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nginx-common depends on:
ii debconf [debconf-2.0] 1.5.77
ii lsb-base 11.1.0

nginx-common recommends no packages.

Versions of packages nginx-common suggests:
pn fcgiwrap 

Bug#993294: libidn11-java has no reverse dependency anymore

[Paul Gevers]

Control: tags -1 - moreinfo

Hi,

On 22-11-2021 17:51, Debian Bug Tracking System wrote:

Subject:
Re: dropped libidn11-java has reverse dependency
From:
Simon Josefsson 
Date:
22-11-2021 17:04

To:
998901-d...@bugs.debian.org


Hi.  I believe this is fixed now that libjxmpp-java 1.0.1-3 has been
uploaded to unstable and also migrated to testing, without the
dependency.  Seehttps://tracker.debian.org/pkg/libjxmpp-java

/Simon


elbrus@coccia:~$ dak rm --no-action -R --suite unstable  --binary 
libidn11-java

Will remove the following packages from unstable:

libidn11-java | 1.33-3 | all

Maintainer: Debian Libidn Team 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Everything seems to be solved now. Please remove libidn11-java.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000152: Upgrading libsasl2-modules to 2.1.27+dfsg-2.2 or up broke freeipa-client

[Timo Aaltonen]

On 18.11.2021 19.49, Timo Aaltonen wrote:

Source: cyrus-sasl2
Severity: important

 Hi

As you can see from the CI results

https://ci.debian.net/packages/f/freeipa/unstable/amd64/

since 2021-11-04 and up the tests fail on installing the client with 
this error:


Cannot connect to the server due to generic error: Insufficient access: 
SASL(-4): no mechanism available: No worthy mechs found (Unknown 
authentication method)


I narrowed down the changed packages and the list includes 
libsasl2-modules-gssapi-mit. I verified that upgrading this package (and 
libsasl2-modules) broke my test system with the same error, everything 
else was upgraded earlier to current sid and that state worked fine.


Since the changes to cyrus-sasl2 can't be causing this, maybe there's 
some issue with building it with current gcc? I'll try building it with 
gcc-10 next.


Building with gcc-10 didn't help, still get the same error.



--
t

Bug#998867: debootstrap: --no-merged-usr became a no-op

[Julien Cristau]

On Mon, Nov 15, 2021 at 01:54:36PM +, Dimitri John Ledkov wrote:
> > Also, build chroots must still be created without merged-usr for 
> > sid/bookworm, until something's been done to migrate user systems.
> 
> But Julien, you said that buildds run stable, meaning they are
> unaffected by this debootstrap change in sid/bookworm.
> 
This isn't just about buildds, it's about everything that builds Debian
packages.  (And even if it was just about buildds, we should still do
things in the right order.)

Cheers,
Julien

Bug#1000406: nginx-common: Nginx starts before DNS is ready

[Jeremy Ouellet]

Package: nginx-common
Severity: normal

Dear Maintainer,

I was messing with nginx remote proxy and found that it would crash on 
startup.
I looked into the service file and it depended on network.target. I 
changed it

to network-online.target so that it would work.

I beleive that nginx should wait for the network to be online before 
starting
as this makes it so you can use domain names in proxy_pass. I googled 
for this
issue and most people just give workarounds and I feel like the use 
cases for

using just nework.target are minimal.

-- System Information:
Debian Release: 11.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nginx-common depends on:
ii debconf [debconf-2.0] 1.5.77
ii lsb-base 11.1.0

nginx-common recommends no packages.

Versions of packages nginx-common suggests:
pn fcgiwrap 

Bug#1000333: gem2deb: ignore or find a way to make <= constraint in gemspec work

[Antonio Terceiro]

Control: tag -1 + wontfix

On Sun, Nov 21, 2021 at 11:51:22PM +0530, Pirate Praveen wrote:
> Package: gem2deb
> Version: 1.7
> Severity: wishlist
> 
> should we really honor <= constraint in gemspecs? in ruby-google-fog
> upstream wants fog-core <= 2.1.0 it will never be satisfied in debian
> 
> because 2.1.0-1 >= 2.1.0 and we have 2.1.0-3.1 in archive
> 
> we could either ignore or may be detect the current version in the archive
> (it will require a rebuild if dependency change)

In cases like this, IMO the gemspec needs to be patched to drop such
dependency. Even if we did ignore it and didn't represent that with a
corresponding << constraint in debian/control, the dependency check will
still fail during the build unless the gemspec is patched.


signature.asc
Description: PGP signature

Bug#999626: maxima-emacs: fails to install with xemacs21

[Andreas Beckmann]

Followup-For: Bug #999626
Control: found -1 5.45.1-5

Hi,

the bug is still present, but with a slightly different error message:

  Setting up maxima-emacs (5.45.1-5) ...
  Install emacsen-common for xemacs21
  emacsen-common: Handling install of emacsen flavor xemacs21
  Loading /usr/share/emacsen-common/debian-startup...
  Loading 00debian...
  Compiling /usr/share/xemacs21/site-lisp/debian-startup.el...
  Wrote /usr/share/xemacs21/site-lisp/debian-startup.elc
  Done
  Install maxima-emacs for xemacs21
  install/maxima: Handling install for emacsen flavor xemacs21
  Compiling /usr/share/xemacs21/site-lisp/maxima/bookmode.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/bookmode.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/emaxima.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/emaxima.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/imath.el...
  While compiling toplevel forms in file 
/usr/share/xemacs21/site-lisp/maxima/imath.el:
!! Symbol's value as variable is void ((image-map))
  >>Error occurred processing imath.el: 
  Symbol's value as variable is void: image-map
  
  
  Compiling 
/usr/share/xemacs21/site-lisp/maxima/imaxima-autoconf-variables.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/imaxima-autoconf-variables.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/imaxima.el...
  While compiling toplevel forms in file 
/usr/share/xemacs21/site-lisp/maxima/imaxima.el:
** misplaced interactive spec: (interactive)
** misplaced interactive spec: (interactive "")
** misplaced interactive spec: (interactive "")
** misplaced interactive spec: (interactive "")
** misplaced interactive spec: (interactive "")
** misplaced interactive spec: (interactive "")
  Wrote /usr/share/xemacs21/site-lisp/maxima/imaxima.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/maxima-font-lock.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/maxima-font-lock.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/maxima.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/maxima.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/mylatex.ltx.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/mylatex.ltx.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/setup-imaxima-imath.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/setup-imaxima-imath.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/smart-complete.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/smart-complete.elc
  Compiling /usr/share/xemacs21/site-lisp/maxima/sshell.el...
  Wrote /usr/share/xemacs21/site-lisp/maxima/sshell.elc
  Done
  ERROR: install script from maxima-emacs package failed
  dpkg: error processing package maxima-emacs (--configure):
   installed maxima-emacs package post-installation script subprocess returned 
error exit status 1


Andreas

Bug#1000404: /usr/bin/markdown2: Re: /usr/bin/markdown2: Markdown2 doesn't render tables

[Musbur]

Package: python3-markdown2
Version: 2.3.10-1.1
Followup-For: Bug #1000404
X-Debbugs-Cc: mus...@posteo.org


My bad! Forgot to include -x tables. RTFM!



-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-markdown2 depends on:
ii  python3  3.9.2-3

python3-markdown2 recommends no packages.

python3-markdown2 suggests no packages.

-- no debconf information

Bug#1000405: Please accept other JRE versions besides the default one

[Olivier Cailloux]

Package: libbatik-java
Version: 1:0.95.dfsg-5

The libbatik-java package currently recommends “default-jre”, itself
depending on “default-jre-headless (= 2:1.11-72) [not hppa]”, itself
depending on “openjdk-11-jre-headless [not hppa]”. But libbatik-java
would work equally well with any posterior version, such as openjdk-17-
jre-headless.

Please rather recommend “java-runtime-headless” if libbatik-java also
works with java 8, or otherwise, consider some appropriate means to
recommend any headless jre from 11 onwards.

(This request is similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998881.)

Bug#1000404: /usr/bin/markdown2: Markdown2 doesn't render tables

[Musbur]

Package: python3-markdown2
Version: 2.3.10-1.1
Severity: important
File: /usr/bin/markdown2
X-Debbugs-Cc: mus...@posteo.org

The table syntax is completely ignored. Markdown just puts it into a paragraph.

$ cat t.md
| Header 1 | Header 2 |
|  |  |
| Cell 1   | Cell 2   |

$ markdown2 t.md
| Header 1 | Header 2 |
|  |  |
| Cell 1   | Cell 2   |
$


-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-markdown2 depends on:
ii  python3  3.9.2-3

python3-markdown2 recommends no packages.

python3-markdown2 suggests no packages.

-- no debconf information

Bug#998881: fixed in jing-trang 20181222+dfsg2-6

[Samuel Thibault]

Olivier Cailloux, le lun. 22 nov. 2021 17:32:41 +0100, a ecrit:
> Maybe I am nitpicking here, but it would be more correct, I suppose, to
> just depend on java-runtime rather than on default-jre OR java-runtime.

That would fail on buildds which cannot decide which package it is
supposed to install to provide java-runtime.

Samuel

Bug#1000396: systemd-detect-virt falsely detects "Microsoft" virtualisation

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/21468

Am 22.11.21 um 16:37 schrieb Michael Biebl:

On 22.11.21 14:06, Liban Hannan wrote:


systemd-detect-virt checks /sys/class/dmi/id/sys_vendor as part of its
attempt to detect if the system is virtualised. I am using a Surface
Laptop so sys_vendor returns "Microsoft Corporation" which (as far as I
can tell) the program assumes indicates the presence of hyper-v rather
than Microsoft produced hardware. One of the consequences is that
systemd units that won't run in a VM fail, such as thermald.


Would you mind forwarding this issue to upstream by filing an issue at 
https://github.com/systemd/systemd/issues


I've filed it as https://github.com/systemd/systemd/issues/21468

Please consider subscribing to this upstream bug report in case upstream 
has further questions.






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000402: RM: postgresql-13-mimeo postgresql-13-pg-track-settings postgresql-13-pgaudit postgresql-13-pgq3 postgresql-13-pgq-node postgresql-13-pgtap postgresql-13-repmgr -- ROM; decruft, no longer

[Christoph Berg]

Package: ftp.debian.org
Severity: normal

Hi,

several packages need decrufting since postgresql-14 isn't building
the postgresql-13-* binaries anymore:

mimeo: postgresql-13-mimeo
pg-track-settings: postgresql-13-pg-track-settings
pgaudit: postgresql-13-pgaudit
pgq: postgresql-13-pgq3
pgq-node: postgresql-13-pgq-node
pgtap: postgresql-13-pgtap
repmgr: postgresql-13-repmgr


While I'm reporting this, there's also a pending auto-decruft from
https://ftp-master.debian.org/cruft-report-daily.txt :

* source package postgis version 3.2.0~beta1+dfsg-1~exp1 no longer builds
  binary package(s): postgresql-13-postgis-3-scripts
  on all
  - suggested command:
dak rm -o -m "[auto-cruft] NBS (no longer built by postgis - based on 
source metadata)" -s experimental -a all -p -R -b 
postgresql-13-postgis-3-scripts
  - No dependency problem found

Christoph

Bug#998881: fixed in jing-trang 20181222+dfsg2-6

[Olivier Cailloux]

Thanks for solving this.

Maybe I am nitpicking here, but it would be more correct, I suppose, to
just depend on java-runtime rather than on default-jre OR java-runtime.

Bug#998679: firefox-esr freezes shortly after start

[Daniel Blaschke]

Package: firefox-esr
Followup-For: Bug #998679
X-Debbugs-Cc: blasc...@hep.itp.tuwien.ac.at

Dear Maintainer,

for the past two days I've been testing firefox-esr 91.3.0 downloaded directly
from mozilla.org on debian 11 (bullseye) without any problems: no crashes
whatsoever.
gfx.x11-egl.force-disabled is set to its default "false" and mesa version on my
system is 20.3.5.

I'm running on an intel broadwell gpu (HD Graphics 5500) using the older
xserver-xorg-video-intel driver and gnome-shell on xorg (not wayland).
In fact, wayland crashes randomly after standby on my system (unrelated to
firefox).

Perhaps, the firefox crashes experienced by others is a bug in either newer
mesa 21.2 or the wayland display server of debian testing and firefox is merely
triggering that bug?
Do people affected by this bug experience it on both xorg and wayland or just
wayland?

On Debian stable we're now 3 weeks overdue for a security update of firefox,
which too me seems rather important to address; I cannot reproduce the bug
reported here on bullseye.

Cheers,
Daniel


-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.3-0+deb11u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6.1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-6+deb11u1
ii  libgtk2.0-02.24.33-2
ii  pulseaudio 14.2-2

-- no debconf information

Bug#998913: [biod/BioD] Fails to build with ldc 1.28.0 (Issue #55)

[Andreas Tille]

Hi Pjotr,

Am Mon, Nov 22, 2021 at 08:17:26AM -0800 schrieb Pjotr Prins:
> Thanks @tillea. I wonder if anyone is using BioD. Sambamba imported a subset 
> of BioD, but no longer does that. 

The motivation to package BioD was only to get Sambamba packaged.  I have no 
idea whether there is any user of plain BioD (we simply can not know).  If you 
want to tell me that there is no sense to keep BioD in Debian I wonder whether 
it might be the best idea to simply orphan the project upstream.
Kind regards, Andreas.

Bug#997248: mysql++: FTBFS: ./examples/load_jpeg.cpp:90:50: error: taking address of rvalue [-fpermissive]

[Sascha Steinbiss]

Hi Roberto,

thanks for the quick response!

> I cannot attend to this at the moment, so I give you my blessing to
> proceed with the NMU.

Thanks, will do that and upload soon.

Cheers
Sascha

Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26

[Patrick Alken]

Hi all, sorry for all this trouble. I will try to make a new GSL release 
with the correct numbers.


On 11/22/21 2:18 AM, Sebastian Ramacher wrote:

On 2021-11-21 16:27:03, Dirk Eddelbuettel wrote:

Hi Patrick,

Can you please chime in (as you did in the earlier exchanges when Sebastian
explained to us how to set valus triplet for libtool via configure.ac) ?

On 21 November 2021 at 23:00, Sebastian Ramacher wrote:
| On 2021-11-09 12:54:44 -0600, Dirk Eddelbuettel wrote:
| >
| > On 8 November 2021 at 22:14, Sebastian Ramacher wrote:
| > | Control: tags -1 moreinfo
| > | Control: forwarded -1 
https://release.debian.org/transitions/html/auto-gsl.html
| > |
| > | On 2021-10-31 14:29:40 -0500, Dirk Eddelbuettel wrote:
| > | >
| > | > Package: release.debian.org
| > | > Severity: normal
| > | > User: release.debian@packages.debian.org
| > | > Usertags: transition
| > | >
| > | > GNU GSL 2.7 was release a few months ago, and we now realised (in the
| > | > discussion of #993324 which also included upstream) that the upstream 
libtool
| > | > instruction were in error by _not_ leading to a new sonumber. This was
| > | > corrected in (source package) gsl upload 2.7-3 to experimental, which 
built
| > | > well.
| > |
| > | What's the status of the fix upstream? Was there any progress? Otherwise
| > | we're gonna repeat that with the next upstream release.
| >
| > Those are two distinct issues.  Upstream, I think we all agreed in the 
thread
| > also recorded in the BTS, made an omission in this release where a new 
soname
| > was needed, but wasn't given. This happens.  So now we need a new soname
| > __because the ABI/API changed__.
|
| Yes, the ABI changed and we need a new SONAME. This would ideally be
| done upstream, though. Even better would be a new release with that change.

Yes or no. We could proceed with the patch based on your suggestion. That
would be "lighterweight" as we would not require upstream work right now.
  
| As far as I am aware, the bug report lacks any mail from Patrick which


He did participate earlier. Some of it may have been private mail between him
and myself; I'd have to check.

I reply from Patrick isn't recored in the BTS and I also can't find one
in my inbox.

Cheers


| would currently mean that we'd have a Debian-specific SONAME. If we go
| ahead with that, we will end up in on of the following cases:
|
| 1.  Upstream bumps the SONAME as we discussed it in the bug report.
| Given the changes in [1], the next release of gsl would then have a
| SONAME of libgsl.so.26, but with an incompatible ABI compared to what we
| would have in the archive.

I didn't catch that aspect. Yes us moving to libgsl.so.26 by ourself now
would make it impossible to use that soname later :-/
  
| 2.  Upstream bumps the SONAME to a version higher than 26.


(That would be my stylistic preference. If the next GSL is 2.8, why not take
28? I may be unaware of other style 'customs' here.)
  
| (3. Upstream simply ignores the issue)

|
| If 1. happens, we'd be unable to sync up with upstream's SONAME (there's
| a good reason why we tend to avoid Debian-specific SONAMEs).
|
| Patrick, what are your planes?

We're all ears :)

Dirk
  
| Best

| Sebastian
|
| [1] 
https://git.savannah.gnu.org/cgit/gsl.git/commit/?id=191bf01a38e590dd0df8aa571accbbd331bfee07
|
| >
| > That has happened before, and that is why we had transitions in the past.
|
|
|
| >
| > But not all previous releases had soname changes. I have maintained GSL here
| > for about 20 years and I think this is about the third transition. I would
| > call that defensible.
| >
| > The release team does of course have a broader view, and I am always keen to
| > hear your thoughts.
| >
| > Cheers, Dirk
| >
| > | Cheers
| > |
| > | >
| > | > I would like to ask for a formal transition. As we saw with failing 
tests in
| > | > dependent packages, binNMUs will not work for all package (but possibly
| > | > "most").
| > | >
| > | > Tentative ben file below.
| > | >
| > | > 
-
| > | > title = "gsl 2.7 transition";
| > | > is_affected = .depends ~ /libgsl-dev/;
| > | > is_good = .depends ~ "libgsl26";
| > | > is_bad = .depends ~ "libgsl25";
| > | > 
-
| > | >
| > | > Let me know if I can help otherwise.
| > | >
| > | > Cheers, Dirk
| > | >
| > | >
| > | > --
| > | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| > | >
| > |
| > | --
| > | Sebastian Ramacher
| > | x[DELETED ATTACHMENT signature.asc, application/pgp-signature]
| >
| > --
| > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| >
|
| --
| Sebastian Ramacher
| [DELETED ATTACHMENT signature.asc, application/pgp-signature]

--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#993196: Germany Business List

[Elena Williams]

Hi,

Interested in Industry contacts professional list..

Please let me know which target criteria you would like to 
acquire!..

Target Industry: -__? (Any Industry)
Target Country: - _? (Denmark , USA , UK, Germany and many more..)
Target Job Title: - _? (CEO, President, VP's, Managing Director, 
Director, Manager and many more..)

With complete contact information for pre-show marketing campaign, appointment 
sitting, networking and various other post-show Marketing initiatives.

Data fields: Company names, Contact name, email address, phone number and etc.

If interested let me know so that we can send you count, cost and more info of 
deliver of data GD-PR etc...

Hope we get a positive reply

Have a Great Day!

Best Regards,
Elena Williams

Bug#994614: Fixed upstream

[Nicholas Guriev]

Hello! Thank you for pointing out a commit with the correct fix.

I recall there was a similar bug in LottieShapeData::lerp() and I tried
to apply a patch to avoid the crash. But I apparently didn't take
account of all border cases.

https://sources.debian.org/src/rlottie/0.1+dfsg-2/debian/patches/Zero-corrupt-point.patch/

The crash seems to still be possible when mVertices (as filled from key
"v") are empty or of size 1 and a path is not closed (key "c" has false
value). Ok, I'm reproducing the issue and cherry picking the upstream's
commit soon.


В Ср, 03/11/2021 в 23:35 +0100, Tim Wiederhake пишет:
> The crash happens in librlottie, "lottiemodel.h", line 133, function
> "LottieShapeData::lerp(LottieShapeData const&, LottieShapeData const&,
> float, VPath&)".
> 
> When both "start" and "end" are empty, "size" evaluates to 0 and the
> call to "result.moveTo(start.mPoints[0]..." crashes.
> 
> This is fixed upstream in
> https://github.com/Samsung/rlottie/commit/1cb2021d6883ebe41c17e710fc90a225f038cb51
> 



signature.asc
Description: This is a digitally signed message part

Bug#1000401: golang-github-go-git-go-git: please make the build reproducible

[Chris Lamb]

Source: golang-github-go-git-go-git
Version: 5.4.2-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
golang-github-go-git-go-git could not be built reproducibly.

This is because the testsuite leaves a Git worktree (or similar)
around in a .tmp directory. A patch is attached that cleans this up
after running the tests.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2021-11-22 07:21:35.700858479 -0800
--- b/debian/rules  2021-11-22 07:49:45.545730652 -0800
@@ -2,3 +2,6 @@
 
 %:
dh $@ --builddirectory=_build --buildsystem=golang --with=golang
+
+execute_after_dh_auto_test:
+   find _build -type d -name .tmp -print0 | xargs -0r rm -rf

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[David Prévot]

[ Ondřej, your last mail didn’t make it to the transition bug report, 
neither did the previous one. FWIW, I can only see a blank one from your 
“Apple Mail” MUA. ]


[ Here is a copy of the sources of your email. I reply after this copy 
to try not to add more confusion. ]


Le 22/11/2021 à 10:26, Ondřej Surý a écrit :

On 22. 11. 2021, at 14:15, David Pr=C3=A9vot  =

wrote:

=20
Le 22/11/2021 =C3=A0 08:45, Ond=C5=99ej Sur=C3=BD a =C3=A9crit :
=20
> Or we could stop delaying the inevitable[1] and instead of bumping
> epoch just go ahead with the transition.
=20
You don=E2=80=99t need to bump epoch (especially on source package and =

every binary ones) just to temporarily bump version of one binary =
package.

=20
IIRC, last time such transition was pushed in an uncoordinated way =

like this (7.3 -> 7.4), it took months to handle. Can we please not =
repeat this painful experience for such an expected bigger transition =
(7.4 -> 8.1)?

You asked for more time last December, a year has passed and it=E2=80=99s =
again not good time. What would just having more time grant? We cannot =
have bookworm released with PHP 7.4, so what will change and how much =
more time will be =E2=80=9Cenough=E2=80=9D? We cannot hold back on PHP =
version because Debian contains software that cannot keep up with the =
PHP release model. People would actually appreciate having a recent PHP =
interpreter packaged in Debian instead of software written in PHP. As =
far as I understand most people are using stuff like composer anyway.


The current status is holding some of us to actually work on this =

transition (e.g., I=E2=80=99m not able to properly build and push new =
versions expected to actually work with recent PHP, and have little view =
of the remaining issues that could be spotted via autopkgtests in =
experimental, since little or no bugs were raised on affected packages).

What transition? PHP 7.4 has been released in Debian bullseye, so I =
cannot imaging what transition you are talking about. PHP 7.4 is =
switching to security-only in December with only one extra year. We need =
to switch to PHP 8.1 now and to PHP 8.2 before bookworm release.

So, again - how much time would be enough if a year was not enough?

Ondrej


[ It case that was not clear, I’m not a release team member. ]

Last December, I pointed that the lack of coordination to push PHP 8.0 
into Bullseye just before the freeze was not optimal. IIUC, the people 
in charge at the time (the release team, the security team, and the PHP 
maintainers) decided to stick with PHP 7.4 for Bullseye.


I have no intent to delay the transition to PHP 8: we all know that 
Bookworm won’t ship with PHP 7.


> What transition?

I really mean the php8.1 transition, the one we’re discussing in this 
bug report, apologies if that was unclear.


What is currently bothering me is, since you pushed php-defaults 85 to 
unstable three days ago, packages are currently uninstallable (and thus, 
packages can’t currently be built) [1]. You claim to be willing to 
revert the transition you started without coordination, but the two 
packages you uploaded for that purpose can’t work or reach the archive. 
IIRC, you also pushed the previous transition (the php7.4 one) after 
uploading php-defaults to unstable by mistake. Seeing the same pattern 
again makes it more difficult to assume good faith.


Regards

David

1: That is the issue that triggered my initial mail three days ago, I 
hope you (PHP maintainers and release team) can work out some solution 
quickly.

Bug#1000396: systemd-detect-virt falsely detects "Microsoft" virtualisation

[Michael Biebl]

On 22.11.21 16:37, Michael Biebl wrote:


Control: tags -1 + upstream
Hi Liban

On 22.11.21 14:06, Liban Hannan wrote:


systemd-detect-virt checks /sys/class/dmi/id/sys_vendor as part of its
attempt to detect if the system is virtualised. I am using a Surface
Laptop so sys_vendor returns "Microsoft Corporation" which (as far as I
can tell) the program assumes indicates the presence of hyper-v rather
than Microsoft produced hardware. One of the consequences is that
systemd units that won't run in a VM fail, such as thermald.


Would you mind forwarding this issue to upstream by filing an issue at 
https://github.com/systemd/systemd/issues


Afaics, this issue was introduced by
https://github.com/systemd/systemd/commit/506bbc8569014253ea8614b680ccbc4fc2513a87


OpenPGP_signature
Description: OpenPGP digital signature

Bug#997248: mysql++: FTBFS: ./examples/load_jpeg.cpp:90:50: error: taking address of rvalue [-fpermissive]

[Roberto C . Sánchez]

On Mon, Nov 22, 2021 at 01:16:06PM +0100, Sascha Steinbiss wrote:
> Hi everyone,
> 
> looks like upstream fixed this already [0]. The fix is easily imported
> into packaging, see attached debdiff.
> 
> I would be happy to NMU this within a week or so if there is no action
> by the maintainer to avoid mysql++ to be removed from testing. Please
> let me know if this is not wanted. Also addressing this mail to the
> previous uploader of the package.
> 
> mysql++ is a dependency of my augustus package, which I would prefer not
> to be removed from testing.
> 
Hi Sascha,

I cannot attend to this at the moment, so I give you my blessing to
proceed with the NMU.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

Bug#1000396: systemd-detect-virt falsely detects "Microsoft" virtualisation

[Michael Biebl]

Control: tags -1 + upstream
Hi Liban

On 22.11.21 14:06, Liban Hannan wrote:


systemd-detect-virt checks /sys/class/dmi/id/sys_vendor as part of its
attempt to detect if the system is virtualised. I am using a Surface
Laptop so sys_vendor returns "Microsoft Corporation" which (as far as I
can tell) the program assumes indicates the presence of hyper-v rather
than Microsoft produced hardware. One of the consequences is that
systemd units that won't run in a VM fail, such as thermald.


Would you mind forwarding this issue to upstream by filing an issue at 
https://github.com/systemd/systemd/issues


Thanks in advance.

Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Giulio Paci]

Hi Bastian,

Il sab 23 ott 2021, 11:58 Bastian Germann  ha scritto:

> Am 23.10.21 um 10:43 schrieb Giulio Paci:
> > Since the NMU has already solved the FTBFS, I think I can try to upgrade
> > the tool as well. Unfortunately upstream did not add neither a tag nor a
> > release to github. I have just asked if it is possible to add them
> > (before moving to github upstream used to release tarballs with any new
> > release).
>
> As the last commit is the one changing the version and is from 2018, it
> is reasonable to assume that that commit is the release. There is no
> activity since then and I do not expect upstream to react to your
> request. So please package 2.4.11 regardless of tags.
>

I have discussed with upstream and they agreed to merge some of the
currently open pull requests, as well as tag new versions, so I will
package latest version (currently 2.4.12) as soon as I find time.

>
> I have invited you to https://salsa.debian.org/debian/sctk which also runs
> the Salsa CI pipelines to demonstrate the i386 issue. Please use that repo
> going forward.


I will do. Thank you for setting it up.

Build tests on i386 fail with:

test17: Vietnamese case conversion

Executions complete: Comparing output

   Removing DIFF tests

   Removing SLM tests

!  TESTS HAVE FAILED  !


I checked the issue and found out that the failing tests are test13 and
test13b in sclite.
The failing test case relies on the assumptions that, when a and b have the
same double value:
1) "a < b" is false;
2) "a - b" is 0.0.
For some reason the two above assumptions are sometime disattended on i386,
and thus the "overlap" function in src/sclite/ctm2ctm.c is not always
providing the expected results.
The overlap behavior is unstable and varies according to specific flags
being used to compile the executable (e.g., enabling debug is often enough
to not trigger the failure, but enabling -O3 and -mtune=native generally is
enough to trigger the failure again) or the context surrounding the
operations (e.g., accessing the memory address of the operands).

I guess the main reason for this weird behavior is described in (option
-mfpmath):

https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/x86-Options.html#x86-Options

and in (option -ffloat-store):

https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options
.

Using -ffloat-store option indeed seems to fix the issue.


However I am wondering:
1) is this the proper solution?
2) is it correct that the compiler does not guarantee the above assumptions?

Do you have any suggestion?

Best regards,
Giulio

Bug#1000400: stellarium: mouse pointer not visible in fullscreen on gnome/wayland

[Jérémy Lal]

Package: stellarium
Version: 0.20.4-3
Severity: normal

Also when i try to disable fullscreen (F11) the stellarium window just 
disappears.


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (101, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages stellarium depends on:
ii  libc6 2.32-4
ii  libgcc-s1 11.2.0-12
ii  libqt5core5a  5.15.2+dfsg-13
ii  libqt5gui55.15.2+dfsg-13
ii  libqt5multimedia5 5.15.2-3
ii  libqt5multimediawidgets5  5.15.2-3
ii  libqt5network55.15.2+dfsg-13
ii  libqt5positioning55.15.2+dfsg-3
ii  libqt5printsupport5   5.15.2+dfsg-13
ii  libqt5script5 5.15.2+dfsg-2
ii  libqt5serialport5 5.15.2-2
ii  libqt5widgets55.15.2+dfsg-13
ii  libstdc++611.2.0-12
ii  stellarium-data   0.20.4-3
ii  zlib1g1:1.2.11.dfsg-2

stellarium recommends no packages.

stellarium suggests no packages.

-- no debconf information

Bug#1000398: libstdc++-11-dev: Failed to compile with clang++ C++20 mode due to chenges of std::valarray.

[Kyuma Ohta]

Package: libstdc++-11-dev
Version: 11.2.0-12
Severity: important

Dear Maintainer,

When compiling any C++20 source code using std::valarray with clang++,
failed to compile with below message:
---
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/valarray:foo:var
 error: exception specification in declaration does not match previous 
declaration
---

Because /usr/include/c++/11/valarray includes
/usr/include/c++/11/bits/valarray_array.h .

These decl. begin(valarray<_Tp>& __va) variants,
but recent version (11.2.0-12) changes /usr/include/c++/11/valarray
from older version (11.2.0-10) decl. of begin().

These added [[__nodiscard__]] and noexcept to recent version.

These changes violates specificaton P0012R1 after C++17,
clang++ checks this correctly , but g++ (<= 11) not seems to check this.

See,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0012r1.html

Best regards,
Ohta.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libstdc++-11-dev depends on:
ii  gcc-11-base11.2.0-12
ii  libc6-dev  2.32-4
ii  libgcc-11-dev  11.2.0-12
ii  libstdc++6 11.2.0-12

libstdc++-11-dev recommends no packages.

Versions of packages libstdc++-11-dev suggests:
ii  libstdc++-11-doc  11.2.0-12

-- no debconf information

Bug#1000399: peg-e: french template translation

[bubu]

package: peg-e

severity:wishlist

Tags:patch l10n

dear mainteners,

Please find attached the french  templates translation, proofread
by the
debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

greatings,

    bubu



peg-e_1.3.0-1_fr.po.xz
Description: application/xz

Bug#1000397: ITP: prometheus-frr-exporter -- Prometheus export for the FRR daemon

[Daniel Swarbrick]

Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: prometheus-frr-exporter
  Version : 0.2.20
  Upstream Author : Tynan Young 
* URL : https://github.com/tynany/frr_exporter
* License : MIT
  Programming Lang: Go
  Description : Prometheus exporter for the FRR daemon

Prometheus exporter for FRR version 3.0+ that collects metrics by using
vtysh and exposes them via HTTP, ready for collecting by Prometheus.

My employer currently uses this exporter and since I have already
packaged it inhouse, I wanted to also share it with the Debian
community. I feel that the package would be useful to service providers
and network operators who wish to monitor the health of e.g. BGP peering
with Prometheus.

I will maintain this package with the help of Debian Go packaging /
Prometheus team(s).

Bug#996924: nextcloud-desktop: deletes dirs on the server although they're still here locally

[Hefee]

Control:  tags -1 +upstream

Hey,

It would be helpful, if you can try a newer version from Debian unstable, if 
you see the same behaviour or if is been fixed meanwhile.
Anyways this is an upstream bug. So you should get in contact with nextcloud 
directly:

https://github.com/nextcloud/desktop/issues

If you find a corresponding bug or create a new one please leave a message 
here, so we can update the metadata for this bug.

Regards,

hefee

--
> From time to time, whole directories get erased from the server for no
> reason.  I've seen it happen a few times already, but not early enough
> to be able to catch logs. So far I've been lucky enough to be able to
> restore from backups, but it's not something that I can afford to see
> happen again.
> 
> In my case, the client sent a DELETE request for a directory that
> hadn't been deleted locally. The
> ~/.local/share/Nextcloud/Documents_sync.log file shows it:
> 
> 12:27:42||TEMP|INST_REMOVE|Up|1633813324|61620350e2e1d|0|06377550ocptyqgkbgt
> 0|4||204|0|0
> 
> At the same time, the server log shows the corresponding request:
> 
> [REDACTED] [17/Oct/2021:14:27:42 +0200] "DELETE
> /remote.php/dav/files/DetR/Documents/TEMP HTTP/1.1" 204 609 "-"
> "Mozilla/5.0 (Linux) mirall/3.1.1-2+deb11u1 (Nextcloud)"
> 
> So obviously, on all other clients using that shared Documents
> directory, the TEMP directory is deleted. It's still present locally,
> but there's a discrepancy with the server, and that discrepancy is not
> always resolved in the right direction: sometimes in the past the
> directory was restored from the local version and eventually
> re-uploaded then re-synced to other clients, but other times the local
> version was deleted too, in which case the directory is completely
> lost.
> 
> This is really major, and the fact that it happens "rarely" (although
> a couple of times a year for me) doesn't make it less grave.
> 
> For reference the server runs 21.0.0, but I've seen this bug happen
> with previous versions too, and I don't think the bug is server-side.
> 
> I'm fully willing to help provide more info if instructed how, but
> note that the bug is unpredictable to me.
> 
> It may be relevant that my Documents share is about 500 GB in size,
> with about 300k files.
> 
> Please advise.

signature.asc
Description: This is a digitally signed message part.

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[David Prévot]

Le 22/11/2021 à 08:45, Ondřej Surý a écrit :

> Or we could stop delaying the inevitable[1] and instead of bumping
> epoch just go ahead with the transition.

You don’t need to bump epoch (especially on source package and every 
binary ones) just to temporarily bump version of one binary package.


IIRC, last time such transition was pushed in an uncoordinated way like 
this (7.3 -> 7.4), it took months to handle. Can we please not repeat 
this painful experience for such an expected bigger transition (7.4 -> 8.1)?


The current status is holding some of us to actually work on this 
transition (e.g., I’m not able to properly build and push new versions 
expected to actually work with recent PHP, and have little view of the 
remaining issues that could be spotted via autopkgtests in experimental, 
since little or no bugs were raised on affected packages).


Regards

David


OpenPGP_signature
Description: OpenPGP digital signature

Bug#999804: crash after upgrade to 1.4.3

[Olzvoi Bayasgalan]

Hi,

Should we have blocked this version of isync's transition to testing due 
to this issue? I know it's too late now, but the question seems valid in 
general.


- Olzvoi

Bug#997853: bluetooth.service: Failed to locate executable

[James Howe]

Does 01-disable-sap-plugin.conf override ExecStart by any chance?

You just need to change that to match the new path.

On Tue, 26 Oct 2021 12:40:10 +0800 "Jason L. Quinn" 
 wrote:
> Package: bluetooth
> Version: 5.55-3.1
> Severity: important
> X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com
> 
> Dear Maintainer,
> 
> After a recent full-upgrade from buster to bullseye, bluetooth is not working.
> It appears the system is looking for the bluetooth daemon executable in the
> /usr/lib/bluetooth/ directory
> but no such directory exists. There is a directory called
> /usr/libexec/bluetooth/
> that has a bluetoothd executable. I have tried reinstalling almost all the
> bluetooth-related packages
> hoping it might solve the issue by creating missing symlinks or whatever but 
> it
> did not.
> I also have the bluez package installed and I wasn't certain which package to
> file this bug against.
> 
> The output of "systemctl status bluetooth" gives:
> 
>  bluetooth.service - Bluetooth service
>  Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor
> preset: enabled)
> Drop-In: /etc/systemd/system/bluetooth.service.d
>  └─01-disable-sap-plugin.conf
>  Active: failed (Result: exit-code) since Tue 2021-10-26 12:25:19 +08; 
> 8min
> ago
>Docs: man:bluetoothd(8)
> Process: 4917 ExecStart=/usr/lib/bluetooth/bluetoothd --noplugin=sap
> (code=exited, status=203/EXEC)
>Main PID: 4917 (code=exited, status=203/EXEC)
> CPU: 4ms
> 
> Oct 26 12:25:19 mycomputername systemd[1]: Starting Bluetooth service...
> Oct 26 12:25:19 mycomputername systemd[4917]: bluetooth.service: Failed to
> locate executable /usr/lib/bluetooth/bluetoothd: No such file or directory
> Oct 26 12:25:19 mycomputername systemd[4917]: bluetooth.service: Failed at 
> step
> EXEC spawning /usr/lib/bluetooth/bluetoothd: No such file or directory
> Oct 26 12:25:19 mycomputername systemd[1]: bluetooth.service: Main process
> exited, code=exited, status=203/EXEC
> Oct 26 12:25:19 mycomputername systemd[1]: bluetooth.service: Failed with
> result 'exit-code'.
> Oct 26 12:25:19 mycomputername systemd[1]: Failed to start Bluetooth service.
> 
> 
> -- System Information:
> Debian Release: 11.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

Bug#998867: bumping severity

[Adam Borowski]

Control: severity -1 critical

The current severity, "grave", is a serious understatement.

As all buildd chroots that are created with buggy debootstrap are tainted,
any packages built recently may assume merged usr, and thus needs to be
rebuilt.

Do we have a patch?  If not, let's revert, today or tomorrow at the latest.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A white dwarf seeks a red giant for a binary relationship.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1000395: ITP: ocaml-ptime -- POSIX time for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-ptime
  Version : 0.8.5
  Upstream Author : Daniel C. Bünzli
* URL : http://erratique.ch/software/ptime
* License : ISC
  Programming Lang: OCaml
  Description : POSIX time for OCaml

 Ptime has platform independent POSIX time support in pure OCaml. It
 provides a type to represent a well-defined range of POSIX timestamps
 with picosecond precision, conversion with date-time values,
 conversion with RFC 3339 timestamps and pretty printing to a
 human-readable, locale-independent representation.

This is a new dependency of ocsigenserver.

Bug#1000394: ITP: ocaml-mtime -- monotonic wall-clock time for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-mtime
  Version : 1.3.0
  Upstream Author : Daniel C. Bünzli
* URL : http://erratique.ch/software/mtime
* License : ISC
  Programming Lang: OCaml
  Description : monotonic wall-clock time for OCaml

 Mtime has platform independent support for monotonic wall-clock time
 in pure OCaml. This time increases monotonically and is not subject
 to operating system calendar time adjustments. The library has types
 to represent nanosecond precision timestamps and time spans.

This is a new dependency of ocsigenserver.

Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[David Prévot]

Hi Ondřej,

Le 19/11/2021 à 16:41, Ondřej Surý a écrit :

I disagree, but I uploaded reverted package.


Unfortunately, you also need to bump binary packages version. This 
revert got rejected:


$ ssh coccia.debian.org cat 
/srv/ftp-master.debian.org/queue/reject/php-defaults_87_all-buildd.changes.reason


Version check failed:
Your upload included the binary package libapache2-mod-php, version 
2:7.4+87, for all,

however unstable already has version 2:8.1+85.
Uploads to unstable must have a higher version than present in unstable.

Regards

David


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000393: ITP: ocaml-gmap -- heterogenous maps over a GADT for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-gmap
  Version : 0.3.0
  Upstream Author : Hannes Mehnert
* URL : https://github.com/hannesm/gmap
* License : ISC
  Programming Lang: OCaml
  Description : heterogenous maps over a GADT for OCaml

 Gmap exposes the functor Make which takes a key type (a GADT 'a key)
 and outputs a type-safe Map where each 'a key is associated with a 'a
 value. This removes the need for additional packing. It uses OCaml's
 stdlib Map data structure.

This is a new dependency of ocsigenserver.

Bug#1000392: ITP: ocaml-hmap -- heterogeneous value maps for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-hmap
  Version : 0.8.1
  Upstream Author : Daniel C. Bünzli
* URL : http://erratique.ch/software/hmap
* License : ISC
  Programming Lang: OCaml
  Description : heterogeneous value maps for OCaml

 Hmap provides heterogeneous value maps for OCaml. These maps bind
 keys to values with arbitrary types. Keys witness the type of the
 value they are bound to which allows one to add and lookup bindings
 in a type safe manner.

This is a new dependency of ocsigenserver.

Bug#1000391: ITP: ocaml-eqaf -- constant-time equal function on string for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-eqaf
  Version : 0.8
  Upstream Author : Romain Calascibetta
* URL : https://github.com/mirage/eqaf
* License : MIT
  Programming Lang: OCaml
  Description : constant-time equal function on string for OCaml

 This package provides an equal function on string in constant-time to
 avoid timing-attack with crypto stuff.

This is a new dependency of ocsigenserver.

Bug#1000388: Fix as PR

[Christian Ehrhardt]

Available on salsa at
https://salsa.debian.org/gkarsay/parlatype/-/merge_requests/2

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#1000389: certbot: Renewal failures are not reported to the administrator under systemd

[Michal Sojka]

Package: certbot
Version: 1.12.0-2
Severity: normal

Dear Maintainer,

on systemd-based systems, certificate renewal is run via combination
of systemd timer and service. When the service fails, the systemd
service is marked as failed, but the administrator is not notified
about that. I'd appreciate if the administrator is notified via email
in the same way as with cron.

I'm not sure what is the best way to implement this. The systemd-cron
package provides cron-failure@.service and the services generated by
that package contain "OnFailure=cron-failure@%i.service". Perhaps,
something like this should be implemented even in the certbot package.

-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages certbot depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  python33.9.2-3
ii  python3-certbot1.12.0-2

certbot recommends no packages.

Versions of packages certbot suggests:
ii  python-certbot-doc  1.12.0-2
ii  python3-certbot-apache  1.10.1-1
pn  python3-certbot-nginx   

-- debconf information:
  certbot/remove_live_certs: true

Bug#999525: [help] New error in test cases of bmtk

[Andreas Tille]

Hi,

I think I've found a patch[1] to solve the original issue which just
seems to be a floating point precision issue.  However, meanwhile there
is another less simple issue:

 ERRORS 
_ ERROR collecting 
.pybuild/cpython3_3.10/build/bmtk/tests/builder/test_connection_map.py _
ImportError while importing test module 
'/build/bmtk-0.0.9+ds/.pybuild/cpython3_3.10/build/bmtk/tests/builder/test_connection_map.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3/dist-packages/pandas/__init__.py:30: in 
from pandas._libs import hashtable as _hashtable, lib as _lib, tslib as 
_tslib
/usr/lib/python3/dist-packages/pandas/_libs/__init__.py:13: in 
from pandas._libs.interval import Interval
E   ModuleNotFoundError: No module named 'pandas._libs.interval'

The above exception was the direct cause of the following exception:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
bmtk/tests/builder/test_connection_map.py:4: in 
from bmtk.builder.connection_map import ConnectionMap
bmtk/builder/__init__.py:23: in 
from .networks import DenseNetwork, NetworkBuilder
bmtk/builder/networks/__init__.py:23: in 
from .dm_network import DenseNetwork
bmtk/builder/networks/dm_network.py:32: in 
from bmtk.utils import sonata
bmtk/utils/sonata/__init__.py:24: in 
from .file import File
bmtk/utils/sonata/file.py:23: in 
from . import utils
bmtk/utils/sonata/utils.py:27: in 
import pandas as pd
/usr/lib/python3/dist-packages/pandas/__init__.py:34: in 
raise ImportError(
E   ImportError: C extension: No module named 'pandas._libs.interval' not 
built. If you want to import pandas from the source directory, you may need to 
run 'python setup.py build_ext --
_ ERROR collecting 
.pybuild/cpython3_3.10/build/bmtk/tests/builder/test_connector.py _
ImportError while importing test module 
'/build/bmtk-0.0.9+ds/.pybuild/cpython3_3.10/build/bmtk/tests/builder/test_connector.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3/dist-packages/pandas/__init__.py:30: in 
from pandas._libs import hashtable as _hashtable, lib as _lib, tslib as 
_tslib
/usr/lib/python3/dist-packages/pandas/_libs/__init__.py:13: in 
from pandas._libs.interval import Interval
E   ModuleNotFoundError: No module named 'pandas._libs.interval'

The above exception was the direct cause of the following exception:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
bmtk/tests/builder/test_connector.py:1: in 
from bmtk.builder import connector
bmtk/builder/__init__.py:23: in 
from .networks import DenseNetwork, NetworkBuilder
bmtk/builder/networks/__init__.py:23: in 
from .dm_network import DenseNetwork
bmtk/builder/networks/dm_network.py:32: in 
from bmtk.utils import sonata
bmtk/utils/sonata/__init__.py:2= test session 
starts ==


I updated the upstream version in Git (but the issue is the same for the version
in unstable) and you can see a full build log in Salsa CI[2].

Any idea how to fix this?

Kind regards

  Andreas.


[1] 
https://salsa.debian.org/med-team/bmtk/-/blob/master/debian/patches/precision_in_test.patch
[2] https://salsa.debian.org/med-team/bmtk/-/jobs/2206233#L2178

-- 
http://fam-tille.de

Bug#1000388: FTBFS on s390x due to whitespace damage

[Christian Ehrhardt]

Package: parlatype
Version: 3.0-1

Build is currently broken like here [1]

dpkg-buildpackage: info: host architecture s390x
 debian/rules clean
debian/rules:19: *** missing separator.  Stop.

It is odd that this is only happening on s390x, but it is in fact
whitespace damage.
The rules do not start all lines with tabs, some are mixed space/tabs
and that causes this.

I'll open an MP with the (trivial) fix once I have a bug reference.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=parlatype=s390x=3.0-1=1637515334=0

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd