Bug#995224: [Debian-med-packaging] Bug#995224: relion-cuda: FTBFS with cub 1.14

[Andreas Beckmann]

On 20/02/2022 10.21, Sascha Steinbiss wrote:

Currently thrust and cub are out of sync. I got somewhat distracted ...



OK, got it. Just wanted to find out if there's anything I can do from
the relion packaging side. Will take a break from working on this then
until this is sorted out.


thrust and cub are again in sync with tightened dependencies ;-)

Andreas

Bug#1006993: meld: Unable to compare remote folders (from FUSE mountpoints, e.g. GVFS)

[Moritz Schlarb]

Package: meld
Version: 3.20.4-2
Severity: normal
Tags: upstream, patch
Forwarded: https://gitlab.gnome.org/GNOME/meld/-/issues/497

Dear Maintainers,

I want to point you to upstream bug #497
(https://gitlab.gnome.org/GNOME/meld/-/issues/497) which includes more details
on the problem including responses from an upstream developer referencing a
specific commit which fixes this issue and noting that is has been fixed in the
released version 3.21.1
Maybe you can just bump the whole package to that version?

Best regards,
Moritz


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
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 meld depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gir1.2-gtksource-3.0 3.24.11-2+b1
ii  libgtk-3-0   3.24.31-1
ii  libgtksourceview-3.0-1   3.24.11-2+b1
ii  patch2.7.6-7
ii  python3  3.9.8-1
ii  python3-cairo1.20.1-3
ii  python3-gi   3.42.0-3
ii  python3-gi-cairo 3.42.0-3

Versions of packages meld recommends:
ii  yelp  42~beta-2

meld suggests no packages.

-- no debconf information

Bug#1006974: cjk-latex: font faces (bold, ital) for latin fonts missing when using CJKutf8

[Hilmar Preuße]

Am 10.03.2022 um 01:21 teilte Danai SAE-HAN (韓達耐) mit:

Hi all,


That is indeed strange, because as Hilmar pointed out, the upstream code of
CJK has not changed for years.

Which TeX engine are you running?
A minimal working example would be helpful.



Not sure if this is helpful at all: I was able the reproduce the issue 
using pdfLaTeX on a MikTeX as of November last year. After a round of 
updates the issue is gone.


I'll try using Debian unstable.

H.
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006992: linux-image-5.10.0-12-amd64: Loading initial ramdisk... freezes

[Allan Wind]

Package: src:linux
Version: 5.10.103-1
Severity: important

Dear Maintainer,

When I upgraded from buster (10) to bullseye (11) this host would 
freeze when rebooting into a new kernel (including all point 
releases of 5.10.0) and (cold reboot) by issuing /sbin/poweroff 
then pressing the power button.  I am pretty sure it will also
usually, but not always (<50?) freeze on /sbin/reboot into the
same kernel.

When the boot process freezing there is no output after "Loading 
initial ramdisk".  Removing "quiet" and adding "debug" does not
yield any debug output. I have tried dis_ucode_ldr and nomodeset 
which did not make a difference with respect to freezing.

The host is running the latest UEFI BIOS and ECP.  It also happens
to use ECC memory and there are no faults.

There were no issues with this host under buster (10), i.e. I 
suspect a kernel change triggered this change in behavior.

I also have a P50 (previous hardware model) on the same version of 
Debian and it does NOT freeze.

My current work-around is to force power cycle the host by holding 
down the power button, then press the power button again then press
enter and subsequently f1 to enter the bios.  Then save & exit.  
Most of the time (80+%) the system would boot normally.  It 
displays the kernel output with quiet disabled as expected.

I did review #931639 but appears to be a different issue.  Happy 
to provide additional details (using this as my workstation so I 
can't reinstall buster).


/Allan

-- Package-specific info:
** Version:
Linux version 5.10.0-12-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.103-1 (2022-03-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-12-amd64 
root=UUID=fa6ff053-976a-434c-87ae-2422af36f535 ro

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[6.194103] usb 1-6.4.4.1: New USB device strings: Mfr=0, Product=4, 
SerialNumber=5
[6.194104] usb 1-6.4.4.1: Product: Internal Storage
[6.194105] usb 1-6.4.4.1: SerialNumber: G000WM0695230TBN
[6.320664] usb 1-14: new full-speed USB device number 12 using xhci_hcd
[6.470106] usb 1-14: New USB device found, idVendor=8087, idProduct=0a2b, 
bcdDevice= 0.10
[6.470116] usb 1-14: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[6.499359] usbcore: registered new interface driver usbhid
[6.499365] usbhid: USB HID core driver
[6.501194] mc: Linux media interface: v0.10
[6.503464] input: Tablet PTK-440 Mouse as 
/devices/pci:00/:00:14.0/usb1/1-6/1-6.4/1-6.4.2/1-6.4.2:1.0/0003:056A:00B8.0001/input/input21
[6.503567] hid-generic 0003:056A:00B8.0001: input,hiddev0,hidraw0: USB HID 
v1.00 Mouse [Tablet PTK-440] on usb-:00:14.0-6.4.2/input0
[6.503660] hid-generic 0003:0765:5010.0002: hiddev1,hidraw1: USB HID v1.11 
Device [HID 0765:5010] on usb-:00:14.0-13/input0
[6.504168] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[6.512662] videodev: Linux video capture interface: v2.00
[6.541416] Bluetooth: Core ver 2.22
[6.541433] NET: Registered protocol family 31
[6.541434] Bluetooth: HCI device and connection manager initialized
[6.541436] Bluetooth: HCI socket layer initialized
[6.541437] Bluetooth: L2CAP socket layer initialized
[6.541439] Bluetooth: SCO socket layer initialized
[6.552714] usb 1-6.4.4.2: new full-speed USB device number 13 using xhci_hcd
[6.573316] usbcore: registered new interface driver btusb
[6.573663] Bluetooth: hci0: Bootloader revision 0.0 build 26 week 38 2015
[6.574690] Bluetooth: hci0: Device revision is 16
[6.574693] Bluetooth: hci0: Secure boot is enabled
[6.574694] Bluetooth: hci0: OTP lock is enabled
[6.574695] Bluetooth: hci0: API lock is enabled
[6.574695] Bluetooth: hci0: Debug lock is disabled
[6.574696] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[6.575307] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-12-16.sfi
[6.575311] Bluetooth: hci0: Found device firmware: intel/ibt-12-16.sfi
[6.617289] input: Wacom Intuos4 4x6 Pen as 
/devices/pci:00/:00:14.0/usb1/1-6/1-6.4/1-6.4.2/1-6.4.2:1.0/0003:056A:00B8.0001/input/input23
[6.617524] input: Wacom Intuos4 4x6 Pad as 
/devices/pci:00/:00:14.0/usb1/1-6/1-6.4/1-6.4.2/1-6.4.2:1.0/0003:056A:00B8.0001/input/input25
[6.617893] wacom 0003:056A:00B8.0001: hidraw0: USB HID v1.00 Mouse [Tablet 
PTK-440] on usb-:00:14.0-6.4.2/input0
[6.659233] usb 1-6.4.4.2: New USB device found, idVendor=29ea, 
idProduct=0102, bcdDevice= 1.00
[6.659236] usb 1-6.4.4.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[6.659237] usb 1-6.4.4.2: Product: Advantage2 Keyboard
[6.659238] usb 1-6.4.4.2: Manufacturer: Kinesis
[6.659239] usb 1-6.4.4.2: SerialNumber: 314159265359
[6.708723] 

Bug#988851: tuned: packaging improvements

[Schmidt, Adriaan]

Evgeni Golov, 18. Februar 2022 12:49:
> On Fri, Feb 18, 2022 at 12:34:49PM +0100, Evgeni Golov wrote:
> > Hi Adriaan,
> >
> > I was looking at this for the next tuned upload, and have a few
> > questions.
> >
> > On Thu, May 20, 2021 at 01:27:01PM +, Schmidt, Adriaan wrote:
> > > Paths related to grub (required by the bootloader plugin):
> > >
> > > diff --git a/tuned/consts.py b/tuned/consts.py
> > > index 733ad51..f0acf9e 100644
> > > --- a/tuned/consts.py
> > > +++ b/tuned/consts.py
> > > @@ -24,7 +24,7 @@ ERROR_THRESHOLD = 3
> > >
> > >  # bootloader plugin configuration
> > >  BOOT_DIR = "/boot"
> > > -GRUB2_CFG_FILES = ["/etc/grub2.cfg", "/etc/grub2-efi.cfg"]
> > > +GRUB2_CFG_FILES = ["/boot/grub/grub.cfg"]
> >
> > This is the *generated* file, right?
> > So when the user regenerates it (e.g. by installing a new kernel) all
> > changes are wiped, until tuned detects that?
> >
> > Sounds like a source for possible confusion. How do you handle this in
> > your environment?
> >
> > (And you are aware of https://github.com/redhat-performance/tuned/pull/387,
> > it seems)
> 
> I just realized, on EL-systems, those /etc paths are symlinks to the
> generated file in /boot anyways. So at least the expirience is identical
> here.

Sorry, it took me a while to look into this. I did not run any systematic tests,
but looking at the source, there is code to modify both the generated grub.cfg
and /etc/default/grub, so I'm assuming kernel updates and externally triggered
calls to update-grub should be fine.

And I just noticed that I have one more local change:

diff --git a/tuned/plugins/plugin_bootloader.py 
b/tuned/plugins/plugin_bootloader.py
index c3e25a6..7d5c2e6 100644
--- a/tuned/plugins/plugin_bootloader.py
+++ b/tuned/plugins/plugin_bootloader.py
@@ -348,7 +348,7 @@ class BootloaderPlugin(base.Plugin):
def _update_grubenv(self, d):
log.debug("updating grubenv, setting %s" % str(d))
l = ["%s=%s" % (str(option), str(value)) for option, value in 
d.items()]
-   (rc, out) = self._cmd.execute(["grub2-editenv", "-", "set"] + l)
+   (rc, out) = self._cmd.execute(["grub-editenv", "-", "set"] + l)
if rc != 0:
log.warn("cannot update grubenv: '%s'" % out)
return False

I will propose something upstream to detect the executable, but for current
releases we'd need this patch.

> > > Python bindings for perf (required by the scheduler and irqbalance
> plugins):
> > > This is a little more tricky, because it needs to be fixed elsewhere...
> currently these plugins simply fail when trying to "import perf". The
> required module is part of the kernel sources, and is currently not packaged.
> > > Two things are required:
> > >   * The package linux-perf needs to ship the binding itself (perf.so)
> > >   * A wrapper is needed to select the correct version based on the
> running kernel, same as for the "perf" executable, where this wrapper is
> located in package linux-base
> > > For Linux 4.19, we posted a patch (https://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=860957#10), for 5.10 we have something similar which
> we'd be happy to contribute.
> >
> > I recall posting this bug, yeah.
> > Sadly, I don't see much that can be done here from the tuned side, until
> > the kernel packages aren't adjusted :(

Actually, there is some movement:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/425

https://salsa.debian.org/kernel-team/linux/-/commit/91c110c0cfaa5366b880382f86a84a03d8011ffd

This removes the versioning of perf and the need for wrappers, which makes
it easier to package the Python bindings. The bindings themselves are still
not included, but we're working on it...

> > > Systemd unit file (tuned.service):
> > > Currently passes -P to have tuned write its own PID file, and -l to have
> tuned write its own log file.
> > > Wouldn't it be better practice, to
> > >   * remove -P, as systemd will take care of the PID file
> >
> > I'd rather argue this is just default behaviour?
> > https://github.com/redhat-
> performance/tuned/commit/9520364fcae362e7181cd1057591054e3407c756
> > https://github.com/redhat-
> performance/tuned/blob/dc8808cb394e52e0d11c7d7b3a53264421d21d47/tuned.py#L77-
> L79
> >
> > >   * remove -l, and have systemd direct tuned's stdout to the journal
> >
> > Can you propose those changes upstream? They do seem to make sense, but
> > I'd prefer not to diverge from upstream unless really necessary.

You are right. I must have read things wrong and assumed the service file was
part of the Debian packaging. Let's keep it the way it is.

Adriaan

> > Thanks!
> > Evgeni

Bug#1006816: Forwarded upstream

[Julien Puydt]

Hi,

I forwarded the bug to
upstream: https://github.com/agronholm/anyio/issues/417

Here is the commit upstream would like feedback about:
https://github.com/agronholm/anyio/commit/184744ca291d426dd278f697c3637623eb9de0ed

Can you check?

Thanks!

J.Puydt

Bug#1006991: libkwin4-effect-builtins1 blocks apt ugrade on Debian testing

[Aurélien COUDERC]

Le jeudi 10 mars 2022, 06:43:46 CET Hugo Peek a écrit :
> Package: libkwin4-effect-builtins1
> Version: 4:5.23.5-1
> Severity: normal
> X-Debbugs-Cc: hugop...@gmail.com
> 
> Dear Maintainer,

Dear Hugo,

thanks for your bug report.

[…]
> 
> When trying to update through Discover, it says:
> 
> The following packages will be removed by the update:
> - libkwin4-effect-builtins1 (4:5.23.5-1)

This library has been removed from Plasma in 5.24, so you can safely upgrade.


Happy hacking,
--
Aurélien

Bug#1006991: libkwin4-effect-builtins1 blocks apt ugrade on Debian testing

[Hugo Peek]

Package: libkwin4-effect-builtins1
Version: 4:5.23.5-1
Severity: normal
X-Debbugs-Cc: hugop...@gmail.com

Dear Maintainer,

Apt upgrade is holding all KDE updates back:

The following packages have been kept back:
  breeze breeze-cursor-theme kde-cli-tools kde-cli-tools-data 
kde-config-gtk-style kde-config-screenlocker
  kde-plasma-desktop kde-standard kde-style-breeze kdeplasma-addons-data 
khotkeys khotkeys-data kwin-common
  kwin-data kwin-style-breeze kwin-x11 libcolorcorrect5 libkdecorations2-5v5 
libkdecorations2private9
  libkfontinst5 libkfontinstui5 libkscreenlocker5 libkwaylandserver5 
libkwineffects13 libkwinglutils13
  libkwinxrenderutils13 libkworkspace5-5 libnotificationmanager1 
libplasma-geolocation-interface5
  libpowerdevilcore2 libpowerdevilui5 libtaskmanager6abi1 libweather-ion7 
plasma-dataengines-addons
  plasma-desktop plasma-desktop-data plasma-integration plasma-runners-addons 
plasma-wallpapers-addons
  plasma-widgets-addons plasma-workspace plasma-workspace-data powerdevil 
powerdevil-data systemsettings
0 upgraded, 0 newly installed, 0 to remove and 45 not upgraded.

When trying to update through Discover, it says:

The following packages will be removed by the update:
- libkwin4-effect-builtins1 (4:5.23.5-1)

I didn't proceed after that, because I didn't feel like bodging my system today.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libkwin4-effect-builtins1 depends on:
ii  libc6 2.33-7
ii  libepoxy0 1.5.9-2
ii  libkf5configcore5 5.90.0-1
ii  libkf5configgui5  5.90.0-1
ii  libkf5configwidgets5  5.90.1-4
ii  libkf5globalaccel-bin 5.90.0-1
ii  libkf5globalaccel55.90.0-1
ii  libkf5i18n5   5.90.0-1
ii  libkf5notifications5  5.90.0-1
ii  libkf5plasma5 5.90.0-2
ii  libkf5service-bin 5.90.0-1
ii  libkf5service55.90.0-1
ii  libkf5windowsystem5   5.90.0-1
ii  libkwaylandserver5 [libkwaylandserver5-5.23]  5.23.5-1
ii  libkwineffects13  4:5.23.5-1
ii  libkwinglutils13  4:5.23.5-1
ii  libqt5core5a  5.15.2+dfsg-15
ii  libqt5dbus5   5.15.2+dfsg-15
ii  libqt5gui55.15.2+dfsg-15
ii  libqt5qml55.15.2+dfsg-10
ii  libqt5quick5  5.15.2+dfsg-10
ii  libqt5widgets55.15.2+dfsg-15
ii  libstdc++612-20220302-1
ii  libxcb1   1.14-3

libkwin4-effect-builtins1 recommends no packages.

libkwin4-effect-builtins1 suggests no packages.

-- no debconf information

Bug#1006990: postgresql-autodoc: Templates files not found

[Erik de Castro Lopo]

Package: postgresql-autodoc
Version: 1.41+20200921-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Installed the package and ran:

/usr/bin/postgresql_autodoc -d 

Templates files not found in 
/build/postgresql-autodoc-qtvh3E/postgresql-autodoc-1.41+20200921/debian/postgresql-autodoc/usr/share/postgresql-autodoc

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

N/a

   * What was the outcome of this action?

Template files not found.

   * What outcome did you expect instead?

Template files found and a schema diagram to be generated.
 


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (500, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_AU.UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages postgresql-autodoc depends on:
ii  libdbd-pg-perl 3.15.1-1
ii  libhtml-template-perl  2.97-1.1
ii  libterm-readkey-perl   2.38-1+b3

postgresql-autodoc recommends no packages.

Versions of packages postgresql-autodoc suggests:
pn  docbook-book  
ii  graphviz  2.42.2-6

-- no debconf information

Bug#1006648: transition: numerical stack: slepc petsc hypre scotch scalapack

[Drew Parsons]

On 2022-03-05 12:29, Sebastian Ramacher wrote:

Control: tags -1 confirmed

On 2022-03-01 13:34:21 +0100, Drew Parsons wrote:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

We've got a pile-up of numerical libraries waiting in experimental.
I'd like to clear them out into unstable.  This will also let
scalapack rebuild against mpich 4.

The transitions are:

scalapack  2.1 → 2.2
scotch 6.1 → 7.0
hypre  2.22 → 2.23
petsc  3.15 → 3.16
slepc  3.15 → 3.16



scalapack and scotch are uploaded.

I'll want superlu-dist rebuilt before uploading hypre (and mumps before 
petsc).


I'll be uploading a new release of nwchem but am waiting for ga to build 
against scalapack on mipsel.


Drew

Bug#1006621: ITP: boofcv -- Real-time computer vision library

[Peter A]

Based on Dima's comments. Is there any reason we can't just use the Gradle
Wrapper? That way each project can use the version of Gradle it works with
instead of single version for all projects. The only reason I see to not
use Gradle wrapper is because it will download its dependencies and maybe
for some reason that's not allowed.

BoofCV does have a complex build system because it auto generates code. So
you would need to download the jars the auto generate system needs then
build a few classes. Now you're ready to create all the code you need for
this library. At this point, you can in theory javac the entire project as
Dima suggested. Assuming we don't care about mirroring the jar files that
are published on Maven central. This would be equivalent of making one
large .so instead of 15 little .so. If the end goal is some of the tools
included with BoofCV (e.g. calibration and batch scanning of 2d barcodes)
into Debian then that's perfectly fine.

My preference is using gradle wrapper since that's the least amount of
effort for me to do and it's easy to mangle the existing build system.

Peter: if I do the build as described in the instructions, using the
> "gradlew" commands, and I grep the log for "javac", would that give me
> the bulk of the commands that are needed? What else is needed other than
> the "javac" commands?
>

Hmm been a while since I've used javac directly. Probably the easiest way
would be to get a file list using "find" and seeing if it blows up when you
give it several hundred files or so.

- Peter

P.S. I'm going to be a bit erratic when I reply for the next couple of
weeks at least.

-- 
"Now, now my good man, this is no time for making enemies."— Voltaire
(1694-1778), on his deathbed in response to a priest asking that he
renounce Satan.

Bug#998084: python3-numpy adds unnecessary link `/usr/include/python3.9/numpy`

[Gonzalo Tornaria]

On Fri, 29 Oct 2021 22:17:48 -0400 Sandro Tosi  wrote:
> If you feel strongly this symlink needs to be removed, please conduct
> a thorough analysis of the impact that such removal would cause and
> report back on this report, else i'm inclined to just close it out.

As a concrete example take sagemath (https://www.sagemath.org/) when
built from source on debian [0]. See
https://trac.sagemath.org/ticket/33473 for the report in sage issue
tracker.

The way sagemath is built:
 - it uses the system python if available
 - it creates a venv for the system python
 - it builds its own version of python packages, including numpy, in this venv
 - it compiles "sagelib" which is the main component of sagemath using this venv

Because of the symlink that debian places in
/usr/include/python*/numpy, this means that sagelib ends up using
numpy headers from system, but the python module from the venv. This
indeed happens for sage-9.5 (current released version).

It turns out that numpy 1.22 changed the numpy.ndarray structure (size
changed) therefore, using headers from numpy 1.22 together with python
module numpy 1.21 will result in a runtime error:

sage: import sage.rings.polynomial.real_roots
---
ValueErrorTraceback (most recent call last)
...
ValueError: numpy.ndarray size changed, may indicate binary
incompatibility. Expected 96 from C header, got 88 from PyObject

In this example system numpy is 1.22 and sage numpy is 1.21. I don't
use debian anymore [1] but it should be possible to reproduce this
using numpy/experimental which is already 1.22. I found the issue on
void linux which had the same symlink as in debian and upgraded to
numpy 1.22 (see
https://github.com/void-linux/void-packages/issues/36062 for the issue
which is already fixed in void linux).

The same issue also affects scipy.spatial (e.g. when numpy 1.22 is in
the system, numpy 1.21 is built in a venv, and then scipy is built in
the same venv; I think it may also fail if numpy 1.21 is in the system
and numpy 1.22 in the venv but I haven't tested this).

Note that it is possible to workaround the symlink: make sure that the
include arguments to the compiler (-I) for python headers and numpy
headers are in the right order (i.e. numpy headers come first so that
the system numpy headers do not override the venv numpy headers). But
this is brittle, since the order of arguments in CFLAGS is kind of
hard to control.

Other distros (arch, alpine, gentoo, void since today) don't ship any
symlink, and dependent packages seem to work ok. Fedora ships a
symlink as /usr/include/numpy, which would avoid the trouble described
here (because /usr/include is usually only implicit and not added as
-I option) but it makes numpy packages for different versions of
python to conflict.

I think if a python package doesn't compile without the symlink, this
is a bug in the package which should use numpy.get_include() to know
which numpy headers to use. This is the only way to make sure the
package uses the correct headers when using numpy from a venv (because
numpy.get_include() should be called from setup.py in the venv so it
will give the correct answer, meaning the one that matches the numpy
package in the venv).

> i'm not sure supporting a mixed environment of debian packages and pip
> installed modules is the debian maintainer's responsibility: once
> users install software outside of Debian, they usually are on their
> own.

I beg to disagree: the purpose of compilers, interpreters, libraries
and modules is to be able to build and run code and packages that may
well be written by the user, or downloaded from other sources. Even
for software that is shipped by debian it is often useful to be able
to build and install newer, unreleased or development versions, maybe
to develop or test (which sometimes may even be to the distro own
advantage). Of course you do not have to support the version of numpy
shipped by sagemath, but it's nice if you can make sure that the
debian numpy package doesn't get in the way.

Thanks!

Gonzalo

[0] debian ships a binary package for sagemath, but there are still
many important reasons to want to build from source, for example to
develop for sagemath.
[1] I was a debian user 1996-2016

Bug#1006989: nim: incompatible with OpenSSL 3.0

[Steve Langasek]

Source: nim
Version: 1.6.4-1
Severity: serious
Tags: experimental
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Hi Federico,

The nim source package currently has a hard-coded build-dependency (and
runtime dependency) on libssl1.1.  Attempting to switch to libssl3 results
in an unusable binary:

$ ./bin/nimble 
could not import: SSL_get_peer_certificate
$

libssl3 is currently in experimental and expected to be the version of
OpenSSL shipped with the next version of Debian.  Please work with upstream
to ensure this package can be updated for compatibility with OpenSSL 3.

Here is a (not comprehensive or entirely accurate) attempt to check for use
of obsolete symbols by nim:

$ for sym in $(sed -n -e'/proc.*dynlib:/ { s/^\s*proc\s\+//; s/\**(.*//; p }' 
lib/wrappers/openssl.nim); do objdump -T /usr/lib/x86_64-linux-gnu/libssl.so.3  
/usr/lib/x86_64-linux-gnu/libcrypto.so.3 |grep -q $sym\$ || echo "missing 
symbol $sym"; done
missing symbol SSL_library_init
missing symbol SSL_load_error_strings
missing symbol SSLv23_method
missing symbol SSLeay
missing symbol SSL_state
missing symbol SSLv23_client_method
missing symbol SSLv2_method
missing symbol SSLv3_method
missing symbol SSL_CTX_get_ex_new_index
missing symbol bioNew
missing symbol bioFreeAll
missing symbol bioSMem
missing symbol bioCtrlPending
missing symbol ErrClearError
missing symbol ErrFreeStrings
missing symbol ErrRemoveState
missing symbol SSL_get_peer_certificate
$

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1006974: cjk-latex: font faces (bold, ital) for latin fonts missing when using CJKutf8

[韓達耐]

Hi Curtis

That is indeed strange, because as Hilmar pointed out, the upstream code of
CJK has not changed for years.

Which TeX engine are you running?
A minimal working example would be helpful.

Regards

-- 
Danai

On Thu, 10 Mar 2022, 07:27 Hilmar Preuße,  wrote:

> On 3/9/22 19:37, Curtis Dean Smith wrote:
>
> Hi,
>
> > When running a document with CJKutf.sty that rendered properly on
> > Bullseye, the emph, textbf, etc faces now appear as regular roman.
> > If I comment out the begin{CJK}{UTF8}{bsmi}, end{CJK}, and all
> > Chinese in the document, the emph, textbf, etc. faces render
> > properly.
> >
> I'm pretty sure the issue is not in cjk as the upstream code for cjk did
> not change between oldstable and stable. Could you provide a minimal
> example to test the issue?
>
> Hilmar
> --
> Testmail
>
>

Bug#1006906: plocate: cifs file system not being indexed by plocate or mlocate

[Edmund Biow]

Thank you for the suggestion. I noticed that the output of updatedb 
mentioned my server as cifs, which is how it is mounted, but also as 
"type 'autofs'", which I didn't have installed, so I didn't consider it. 
I removed autofs from the PRUNEFS= line, ran updatedb again, and plocate 
worked as expected. Thanks again.


On 3/7/22 23:59, Steinar H. Gunderson wrote:

On Mon, Mar 07, 2022 at 05:12:47PM -0800, Ed Biow wrote:

I always change the /etc/updatedb.conf file to remove cifs from PRUNEFS. The
command works as expected on my Ubuntu systems, mostly 20.04 using the
0.26-3ubuntu3 of mlocate. In the past mlocate worked on Debian.
The locate command is pretty useless to me without indexing my cifs directory.

There is a flag --debug-pruning to updatedb; could you add it and see whether
it gives any useful information?

/* Steinar */

Bug#1006974: cjk-latex: font faces (bold, ital) for latin fonts missing when using CJKutf8

[Hilmar Preuße]

On 3/9/22 19:37, Curtis Dean Smith wrote:

Hi,


When running a document with CJKutf.sty that rendered properly on
Bullseye, the emph, textbf, etc faces now appear as regular roman.
If I comment out the begin{CJK}{UTF8}{bsmi}, end{CJK}, and all
Chinese in the document, the emph, textbf, etc. faces render
properly.


I'm pretty sure the issue is not in cjk as the upstream code for cjk did
not change between oldstable and stable. Could you provide a minimal
example to test the issue?

Hilmar
--
Testmail

Bug#1006988: rust-svgdom: still needed in the archive?

[Daniel Kahn Gillmor]

Package: src:rust-svgdom
Version: 0.18.0-2
Severity: important

rust-svgdom was deprecated by its upstream developer in mid-2019, and
hasn't been touched since.  See https://github.com/RazrFalcon/svgdom

librust-svgdom-dev has no reverse dependencies in debian, and the
package itself has some dependencies on other crates that are in need of
an upgrade (e.g. the rust-svgtypes package).

Andrej, do you think we need to keep this package in debian?  If you
don't think we need it, can you convert this bug report to a removal
request?  (or, feel free to just reply here and i'll do the conversion).

If you do think it needs to stay in the archive, can you explain what is
necessary?

Thanks for thinking about this kind of maintenance,

--dkg


signature.asc
Description: PGP signature

Bug#1006830: elpa-mailscripts: notmuch-slurp-debbugs misses messages

[Sean Whitton]

control: tag -1 + unreproducible

Hello Vagrant,

On Sun 06 Mar 2022 at 07:25AM -08, Vagrant Cascadian wrote:

> On 2022-03-06, Sean Whitton wrote:
>> Could you determine whether downloading the mailbox like this contains
>> the message:
>>
>> bts --bts-server https://bugs.debian.org --mbox --mailreader "true %s" 
>> show 1004939
>
> It didn't appear to visibly do anything (I guess true is a very low
> interactive mailreader), although the .mbox did land in
> .cache/devscripts/bts/ and contains the mentioned Message-Id:
>
>   $ grep ltfe7r.ccn2zwkm4w...@pappacoda.it .cache/devscripts/bts/1004939.mbox
>   Message-Id: 
>   References:  <87czk3pluc.fsf@contorta>
>   In-Reply-To: 
>
> The references/in-repy-to's are from my reply to the message after
> having manually imported the message into my maildir...

Thanks.  As it is included in the downloaded mbox, we can assume that
notmuch-slurp-debbug(1) is skipping over that message somehow, or
notmuch isn't processing it, or something like that.

Unfortunately I can't reproduce here, however -- I get all three
messages for #1004939.  Let's keep this bug open as you've seen this
more than once.  Let me know if you have other cases.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1003002: some more information

[Maximilian Engelhardt]

I did some more tests as I also ran into this problem. Here is what I could 
find out until now:

I start qemu manually in a similar way as done by autopkgtest with the 
following command:

$ qemu-system-arm -machine virt -m 1024 -smp 1 -display none -net 
nic,model=virtio -net user,hostfwd=tcp:127.0.0.1:10022-:22 -object 
rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0,id=rng-device0 -monitor unix:monitor,server=on,wait=off 
-virtfs 
local,id=autopkgtest,path=shared,security_model=none,mount_tag=autopkgtest 
-serial unix:ttyS0,server=on,wait=off -chardev 
socket,path=hvc0,server=on,wait=off,id=hvc0 -device virtio-serial -device 
virtconsole,chardev=hvc0 -chardev socket,path=hvc1,server=on,wait=off,id=hvc1 
-device virtio-serial -device virtconsole,chardev=hvc1 -chardev 
socket,path=hvc2,server=on,wait=off,id=hvc2 -device virtio-serial -device 
virtconsole,chardev=hvc2 -drive 
index=0,file=overlay-tmp/overlay.img,cache=unsafe,if=virtio,discard=unmap,format=qcow2
 -drive 
if=pflash,format=raw,unit=0,read-only,file=/usr/share/AAVMF/AAVMF32_CODE.fd 
-drive if=pflash,format=raw,unit=1,file=overlay-tmp/efivars.fd

I added a third console hvc2 to illustrate my findings better, see below.

Before being able to start this qemu command, I had to do some preparations:

$ qemu-img create -f qcow2 -F qcow2 -b 
/var/local/autopkgtest-unstable-armhf.img overlay-tmp/overlay.img
$ cp /usr/share/AAVMF/AAVMF32_VARS.fd overlay-tmp/efivars.fd

After starting qemu, I can attach to the serial ports with:
$ socat -,echo=0,icanon=0 unix-connect:ttyS0
$ socat -,echo=0,icanon=0 unix-connect:hvc0
$ socat -,echo=0,icanon=0 unix-connect:hvc1
$ socat -,echo=0,icanon=0 unix-connect:hvc2

What I noticed after booting the autopkgtest image is the following:

ttyAMA0 inside the vm is ttyS0 outside
hvc0 inside the vm is hvc1 outside
hcv1 inside the vm is hvc2 outside
hvc0 outside the vm doesn't seem to do anything

So that's the problem, the hvc console numbers are all shifted by one. If you 
leave out hvc2 in the qemu command line (to get the same as done by 
autopkgtest), then hcv1 inside the vm does not exist: "No such device".

But there is more interesting stuff:

When I log into the vm and execute the following commands, the numbering 
changes:

# rmmod virtio_console
# modprobe virtio_console

Now hvc0 inside the vm is also hvc0 outside. And the same for hvc1 and hvc2. 
So everything is now as I would expect it.

I have no idea what's going on here. Is this a bug in the Linux kernel? The 
kernel I did my tests with is 5.16.0-2-armmp-lpae.
I could imagine this is a race somewhere, which might also explain Christian's 
observations with arm64.

I still have an old autopkgtest armhf image from Jun 6 2021 that has linux 
5.10.0-7-armmp-lpae and doesn't show that behaviour. So some change after that 
must have broken the console numbering.

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

Bug#1003565: [Pkg-matrix-maintainers] Bug#1003565: Please modify your dependencies from python3-mistune to python3-mistune0

[Jonas Smedegaard]

Quoting Pierre-Elliott Bécue (2022-03-09 22:10:38)
> 
> Jonas Smedegaard  wrote on 25/02/2022 at 00:00:17+0100:
> 
> > [[PGP Signed Part:No public key for 2C7C3146C1A00121 created at 
> > 2022-02-25T00:00:14+0100 using RSA]]
> > Quoting Pierre-Elliott Bécue (2022-02-24 23:33:04)
> >> Le 24 février 2022 23:11:51 GMT+01:00, Jonas Smedegaard  a 
> >> écrit :
> >> >Quoting Pierre-Elliott Bécue (2022-02-24 22:52:24)
> >> >> 
> >> >> Jonas Smedegaard  wrote on 24/02/2022 at 22:44:03+0100:
> >> >> 
> >> >> > Quoting Pierre-Elliott Bécue (2022-02-24 22:04:28)
> >> >> >> Following up some exchanges, we agreed within the Python Team to 
> >> >> >> reupload mistune 0.8.4 under the mistune0 source package. As it 
> >> >> >> passed NEW, I'm currently doing a sourceful upload and replacing 
> >> >> >> any occurence of mistune in this package by mistune0.
> >> >> >
> >> >> > Please in future post only to not already closed bugreports ;-)
> >> >> 
> >> >> As you'll have work to do, I'm sorry but I stand by my mail sent to 
> >> >> your already closed bugreports. :)
> >> >
> >> >If you mean *different* work than what you have described above 
> >> >(believed already done for bugs #1002163 #1003571 #1003565) then 
> >> >please elaborate what work is - when you reopen the bugreports (no 
> >> >need to elaborate now).
> >
> >> I am not convinced that you did that :
> >> 
> >> > and make a Debian patch to replace any occurrence of a mistune 
> >> > import or usage to mistune0.
> >> 
> >> Of course maybe I misread the changes you made in m2r.
> >
> > Ahh, I totally missed the detail that the package you introduced to 
> > unstable was broken and had to be redesigned, before relying on it.
> 
> It was not unusable, but was still conflicting with python3-mistune, as
> it was installing on the same paths.
> 
> To allow both to coexist, one had to use different paths, and the
> solution designed was to have the old mistune be installed as "mistune0"
> in /u/l/python3/dist-packages.
> 
> Now it's done and in testing, feel free to patch your package
> accordingly! Theoretically it's just a s/mistune/mistune0/g in all .py
> files, setup.py and requirements.txt.

Already did that on February 24th, but thanks anyway.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1003904: lsp-plugins 1.1.31-1 FTBFS on armhf

[Steve Langasek]

Package: lsp-plugins
Version: 1.1.31-1
Followup-For: Bug #1003904
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Hi there,

Attached is a patch that we have applied in Ubuntu to fix this build
failure.  It's not suitable as-is for application in Debian, because Debian
is using the armv7a profile for both armel and armhf targets, and armel as a
Debian architecture doesn't require an FPU - but also, to the best of my
knowledge, armv7a is the wrong ISA baseline for the armel architecture in
Debian generally, so this may not be the appropriate upstream build profile
to use for armel anyway.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru lsp-plugins-1.1.31/debian/patches/series 
lsp-plugins-1.1.31/debian/patches/series
--- lsp-plugins-1.1.31/debian/patches/series2021-12-27 13:29:51.0 
-0800
+++ lsp-plugins-1.1.31/debian/patches/series2022-03-09 12:53:52.0 
-0800
@@ -1 +1,2 @@
 cross.patch
+use-fp-for-arm.patch
diff -Nru lsp-plugins-1.1.31/debian/patches/use-fp-for-arm.patch 
lsp-plugins-1.1.31/debian/patches/use-fp-for-arm.patch
--- lsp-plugins-1.1.31/debian/patches/use-fp-for-arm.patch  1969-12-31 
16:00:00.0 -0800
+++ lsp-plugins-1.1.31/debian/patches/use-fp-for-arm.patch  2022-03-09 
12:57:07.0 -0800
@@ -0,0 +1,24 @@
+Description: use the correct machine target for armhf builds
+ Fixes a build failure because gcc defaults to hard float but the specified
+ override target does not have an FPU.
+ .
+ This patch is not correct on armel, which currently also uses the armv7a
+ target in debian/rules but is explicitly not guaranteed to have an FPU.
+Author: Steve Langasek 
+Last-Update: 2022-03-09
+Bug-Debian: https://bugs.debian.org/1003904
+Forwarded: no
+
+Index: lsp-plugins-1.1.31/scripts/make/configure.mk
+===
+--- lsp-plugins-1.1.31.orig/scripts/make/configure.mk
 lsp-plugins-1.1.31/scripts/make/configure.mk
+@@ -98,7 +98,7 @@
+ endif
+ 
+ ifeq ($(BUILD_PROFILE),armv7a)
+-  CC_ARCH  = -march=armv7-a -marm
++  CC_ARCH  = -march=armv7-a+fp -marm
+ endif
+ 
+ ifeq ($(BUILD_PROFILE),armv7ve)
diff -Nru lsp-plugins-1.1.31/debian/rules lsp-plugins-1.1.31/debian/rules
--- lsp-plugins-1.1.31/debian/rules 2021-11-28 09:51:54.0 -0800
+++ lsp-plugins-1.1.31/debian/rules 2022-03-09 12:53:05.0 -0800
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export PREFIX=/usr
+export VERBOSE=1
 
 include /usr/share/dpkg/architecture.mk
 -include /usr/share/dpkg/buildtools.mk

Bug#1006986: nam: no window

[clohr]

Package: nam
Version: 1.15-5.2
Severity: normal

Dear Maintainer,

nam does not work anymore
No way to get its usual window.

A simple test from ns2:
$ ns
% nam
nam:
child process exited abnormally
%

I do not get the usual nam window.
I just get this error message.

How to get more information about the issue?
How to investigate?

Best regards.
Christophe


(Note: ns2 version 2.35+dfsg-3.1)


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 nam depends on:
ii  libc6   2.33-7
ii  libgcc-s1   12-20220302-1
ii  libotcl11.14+dfsg-4.1
ii  libstdc++6  12-20220302-1
ii  libtcl8.6   8.6.12+dfsg-1
ii  libtclcl1   1.20-9.1
ii  libtk8.68.6.12-1
ii  libx11-62:1.7.2-2+b1

nam recommends no packages.

nam suggests no packages.

-- no debconf information

Bug#1003565: [Pkg-matrix-maintainers] Bug#1003565: Please modify your dependencies from python3-mistune to python3-mistune0

[Pierre-Elliott Bécue]

Jonas Smedegaard  wrote on 25/02/2022 at 00:00:17+0100:

> [[PGP Signed Part:No public key for 2C7C3146C1A00121 created at 
> 2022-02-25T00:00:14+0100 using RSA]]
> Quoting Pierre-Elliott Bécue (2022-02-24 23:33:04)
>> Le 24 février 2022 23:11:51 GMT+01:00, Jonas Smedegaard  a 
>> écrit :
>> >Quoting Pierre-Elliott Bécue (2022-02-24 22:52:24)
>> >> 
>> >> Jonas Smedegaard  wrote on 24/02/2022 at 22:44:03+0100:
>> >> 
>> >> > Quoting Pierre-Elliott Bécue (2022-02-24 22:04:28)
>> >> >> Following up some exchanges, we agreed within the Python Team to 
>> >> >> reupload mistune 0.8.4 under the mistune0 source package. As it 
>> >> >> passed NEW, I'm currently doing a sourceful upload and replacing 
>> >> >> any occurence of mistune in this package by mistune0.
>> >> >
>> >> > Please in future post only to not already closed bugreports ;-)
>> >> 
>> >> As you'll have work to do, I'm sorry but I stand by my mail sent to 
>> >> your already closed bugreports. :)
>> >
>> >If you mean *different* work than what you have described above 
>> >(believed already done for bugs #1002163 #1003571 #1003565) then 
>> >please elaborate what work is - when you reopen the bugreports (no 
>> >need to elaborate now).
>
>> I am not convinced that you did that :
>> 
>> > and make a Debian patch to replace any occurrence of a mistune 
>> > import or usage to mistune0.
>> 
>> Of course maybe I misread the changes you made in m2r.
>
> Ahh, I totally missed the detail that the package you introduced to 
> unstable was broken and had to be redesigned, before relying on it.

It was not unusable, but was still conflicting with python3-mistune, as
it was installing on the same paths.

To allow both to coexist, one had to use different paths, and the
solution designed was to have the old mistune be installed as "mistune0"
in /u/l/python3/dist-packages.

Now it's done and in testing, feel free to patch your package
accordingly! Theoretically it's just a s/mistune/mistune0/g in all .py
files, setup.py and requirements.txt.

Cheers!

-- 
PEB


signature.asc
Description: PGP signature

Bug#1006985: ruby-em-http-request: autopkgtest regression: timeout

[Paul Gevers]

Source: ruby-em-http-request
Version: 1.1.5-3
Severity: serious
User: debian...@lists.debian.org
Usertags: regression timesout

Dear maintainer(s),

Your package has an autopkgtest, great. However, recently it started 
failing in testing (looking at the date, probably when ruby-defaults 
migrated). What's worse, it fails due to an autopkgtest timeout after 
2:47 hours.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://ci.debian.net/packages/r/ruby-em-http-request/

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-em-http-request/19828553/log.gz

autopkgtest [07:09:46]: test gem2deb-test-runner: [---

┌──┐
│ Checking Rubygems dependency resolution on ruby3.0 
   │

└──┘

GEM_PATH= ruby3.0 -e gem\ \"em-http-request\"

┌──┐
│ Run tests for ruby3.0 from debian/ruby-tests.rake 
   │

└──┘

RUBYLIB=. GEM_PATH= ruby3.0 -S rake -f debian/ruby-tests.rake
mv lib ./.gem2deb.lib
/usr/bin/ruby3.0 
-I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib 
/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec 
--pattern ./spec/\*\*/\*_spec.rb --format documentation

wrong number of arguments (given 2, expected 1)
EventMachine::HttpRequest
  with fibers
should be transparent to connection errors

EventMachine::HttpRequest
  should perform successful GET (FAILED - 1)
  should perform successful GET with a URI passed as argument (FAILED - 2)
autopkgtest [09:56:26]: ERROR: timed out on command "su -s /bin/bash 
debci ...


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006984: gnome-commander: depends on deprecated GTK2

[Jeremy Bicha]

Source: gnome-commander
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1

This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
binary packages with a Depends on GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
). It no longer receives any significant
upstream maintenance, and in particular does not get feature development
for new features like UI scaling on high-pixel-density displays (HiDPI)
and native Wayland support. GTK 3 is in maintenance mode and GTK 4 has
been released, so it seems like a good time to be thinking about
minimizing the amount of GTK 2 in the archive.

GTK 2 is used by some important productivity applications like GIMP, and
has also historically been a popular UI toolkit for proprietary software
that we can't change, so perhaps removing GTK 2 from Debian will never be
feasible. However, it has reached the point where a dependency on it is
a bug - not a release-critical bug, and not a bug that can necessarily
be fixed quickly, but a piece of technical debt that maintainers should
be aware of.

A porting guide is provided in the GTK 3 documentation:
https://developer.gnome.org/gtk3/stable/migrating.html

Thank you,
Jeremy Bicha

Bug#1006983: RM: gtk-nodoka-engine -- RoQA; obsolete GTK2 theme engine

[Jeremy Bicha]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: gtk-nodoka-eng...@packages.debian.org

gtk-nodoka-engine is an obsolete GTK2 theme engine with no reverse
dependencies. It's unmaintained in Debian (removed from Testing
because of obsolete debhelper-compat etc.) and upstream.

Without GTK3 support, a GTK2 theme is kinda useless these days.

Thank you,
Jeremy Bicha

Bug#1006982: ruby-clockwork: flaky autopkgtest

[Paul Gevers]

Source: ruby-clockwork
Version: 2.0.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package because it was 
showing up as a regression for the upload of ruby-defaults. I noticed 
that the test regularly fails on all our ci architectures.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-clockwork/19848866/log.gz


Finished in 0.042282s, 1608.2413 runs/s, 3027.2778 assertions/s.

  1) Failure:
Clockwork#test_0005_should pass all arguments to every 
[/tmp/autopkgtest-lxc.1joshj2t/downtmp/build.npU/src/test/clockwork_test.rb:72]:

Expected false to be truthy.

68 runs, 128 assertions, 1 failures, 0 errors, 0 skips


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006912: is it time to have account deletion in policy?

[Marc Haber]

On Wed, Mar 09, 2022 at 11:07:54PM +0500, Andrey Rahmatullin wrote:
> Previous, still open, bug from 2004: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228692

thanks for pointing this out. I have made some notes (both for adduser
and for policy) from that bug.

Adduser development has regaind momentum, so I see it possible that we
get the necessary adduser changes in Debian before bookworm so that we
can, as a second step, amend policy and debhelper.

Please expect me to come up with suggested wording for policy that
referes to some adduser features that do not yet exist, but with my
adduser hat on, I will do my best to have those features implemented
before the suggested wording can be included in Policy.

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1006981: rails: flaky autopkgtest on some ci.d.n architectures

[Paul Gevers]

Source: rails
Version: 2:6.0.3.5+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package on amd64 and 
armhf because it was showing up as a regression for the upload of 
ruby-defaults. I noticed that the test regularly fails on some 
architectures, notably armhf (which always runs on a host with lost of 
cores and RAM) and amd64 (where we have one host with lots of cores and 
RAM).


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/data/autopkgtest/testing/armhf/r/rails/19826102/log.gz

Failure:
ActiveSupport::Cache::RedisCacheStoreTests::RedisCacheStoreCommonBehaviorTest#test_fetch_multi_without_expires_in 
[/tmp/autopkgtest-lxc.0k72y7c9/downtmp/build.89X/src/activesupport/test/cache/behaviors/cache_store_behavior.rb:135]:

--- expected
+++ actual
@@ -1 +1 @@
-{"foo"=>"bar", "fu"=>"fufu", "fud"=>"biz"}
+{"foo"=>"foofoo", "fu"=>"fufu", "fud"=>"biz"}



https://ci.debian.net/data/autopkgtest/testing/amd64/r/rails/19565734/log.gz

Failure:
ActiveSupport::Cache::RedisCacheStoreTests::RedisCacheStoreCommonBehaviorTest#test_large_string_with_compress_false 
[/tmp/autopkgtest-lxc.1wz7jlg5/downtmp/build.gWN/src/activesupport/test/cache/behaviors/cache_store_behavior.rb:226]:

--- expected
+++ actual
@@ -1 +1 @@
-""
+nil


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006980: gemmi: please use packaged doctest.h header

[Gianfranco Costamagna]

Source: gemmi
Version: 0.5.2+ds-1
Severity: important
tags: patch

Hello
the following patch

--- gemmi-0.5.2+ds.orig/tests/cif.cpp
+++ gemmi-0.5.2+ds/tests/cif.cpp
@@ -1,5 +1,5 @@

-#include "doctest.h"
+#include 

 #include 
 #include 
--- gemmi-0.5.2+ds.orig/tests/main.cpp
+++ gemmi-0.5.2+ds/tests/main.cpp
@@ -1,6 +1,6 @@

 #define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
-#include "doctest.h"
+#include 

 #include   // for rand
 #include   // for INT_MIN, INT_MAX


and doing

echo third_party/doctest.h > debian/clean

and adding doctest-dev to build-dependencies helps in using the system-provided 
doctest version.
Note: there is a bug in doctest with newer glibc, leading to a FTBFS

The upstream doctest fix is at
https://github.com/doctest/doctest/commit/8ee91f37ba27397ef5eeedd2e542a433ddc1
but this embedded version is too old.

So, in any case, to avoid a FTBFS bug soon, better probably use the system one.

Gianfranco

Bug#1006979: liggghts: reproducible builds: username and timestamp embedded in libliggghts.so.3.8.0

[Vagrant Cascadian]

Source: liggghts
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: username timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

/usr/lib/x86_64-linux-gnu/libliggghts.so.3.8.0

│ │ │ ├── ./usr/lib/x86_64-linux-gnu/libliggghts.so.3.8.0
...
│ │ │ │ │ -nearestActiveEdgminActiveEdgeDisLIGGGHTS-PUBLIC 3.8.0, compiled 
2022-03-09-06:30:52 by vagrant, git commit e2bd90538abe29938\
baf70275ba72f6db429b758
│ │ │ │ │ +nearestActiveEdgminActiveEdgeDisLIGGGHTS-PUBLIC 3.8.0, compiled 
2023-05-01-09:19:17 by vagrant, git commit e2bd90538abe29938\
baf70275ba72f6db429b758


The attached two patches fix this by respecting the SOURCE_DATE_EPOCH
environment variable for the timestamp, and by removing the build user
from the information embedded in the binary.


Thanks for maintaining liggghts!


live well,
  vagrant
From aa115db3100bd9814b50d1d2109cc0759baa6d9c Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 9 Mar 2022 19:25:35 +
Subject: [PATCH 1/2] src/Make.sh: Use SOURCE_DATE_EPOCH for build timestamp.

https://reproducible-builds.org/docs/source-date-epoch/
---
 src/Make.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/Make.sh b/src/Make.sh
index 96b57be..0fd32fd 100644
--- a/src/Make.sh
+++ b/src/Make.sh
@@ -11,7 +11,8 @@
 
 style () {
   # modified C.K. create version_liggghts.h
-  builddate=`date +%Y-%m-%d-%H:%M:%S`
+  DATE_FMT='+%Y-%m-%d-%H:%M:%S'
+  builddate=`date -u -d "@$SOURCE_DATE_EPOCH" "$DATE_FMT" 2>/dev/null || date -u -r "$SOURCE_DATE_EPOCH" "$DATE_FMT" 2>/dev/null || date -u "$DATE_FMT"`
   wai=`whoami`
   vers=`cat version_liggghts.txt`
   bra=`cat version_liggghts_branch.txt`
-- 
2.35.1

From 05e0cb096e8c5c4581fb81f86e08fcdc52d9aef7 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 9 Mar 2022 20:05:22 +
Subject: [PATCH 2/2] src/Make.sh: Do not embed build user.

---
 src/Make.sh | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/Make.sh b/src/Make.sh
index 0fd32fd..147e123 100644
--- a/src/Make.sh
+++ b/src/Make.sh
@@ -13,20 +13,19 @@ style () {
   # modified C.K. create version_liggghts.h
   DATE_FMT='+%Y-%m-%d-%H:%M:%S'
   builddate=`date -u -d "@$SOURCE_DATE_EPOCH" "$DATE_FMT" 2>/dev/null || date -u -r "$SOURCE_DATE_EPOCH" "$DATE_FMT" 2>/dev/null || date -u "$DATE_FMT"`
-  wai=`whoami`
   vers=`cat version_liggghts.txt`
   bra=`cat version_liggghts_branch.txt`
 
   if [ -d .git ]; then
 githash=`git log -1 --format="%H"`
-echo "#define LIGGGHTS_VERSION \"$bra $vers, compiled $builddate by $wai, git commit $githash\"" > version_liggghts.h
+echo "#define LIGGGHTS_VERSION \"$bra $vers, compiled $builddate, git commit $githash\"" > version_liggghts.h
   elif [ -d ../.git ]; then
 cd ..
 githash=`git log -1 --format="%H"`
 cd src
-echo "#define LIGGGHTS_VERSION \"$bra $vers, compiled $builddate by $wai, git commit $githash\"" > version_liggghts.h
+echo "#define LIGGGHTS_VERSION \"$bra $vers, compiled $builddate, git commit $githash\"" > version_liggghts.h
   else
-echo "#define LIGGGHTS_VERSION \"$bra $vers, compiled $builddate by $wai, git commit unknown\"" > version_liggghts.h
+echo "#define LIGGGHTS_VERSION \"$bra $vers, compiled $builddate, git commit unknown\"" > version_liggghts.h
   fi;
 
   list=`grep -sl $1 $2*.h`
-- 
2.35.1



signature.asc
Description: PGP signature

Bug#1006978: ugrepping /sys/kernel takes too long or grepping /sys/kernel is not thorough

[Peter Mueller]

Package: ugrep
Version: 3.3.3+dfsg-1
Searching for a string in /sys/kernel with grep terminates within 3 seconds 
(and spits out many error messages, which is o.k.).  Searching for the same 
string with ugrep (and avoiding following references) doesn't terminate over 
half an hour and spits out no error messages. Therefore, ugrep has a deficiency 
somewhere, or grep doesn't do its job thoroughly.
# time -p grep -i -r dvistyle /sys/kernel
… (error messages)…
real 2,75 user 0,05 sys 1,06
# date && time -p ugrep -i -r -p dvistyle /sys/kernel
Mi 9. Mär 20:34:45 CET 2022
^Creal 2162,92 user 0,04 sys 0,28
# date Mi 9. Mär 21:10:49 CET 2022 #

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra R.-P.]

For the sake of completeness ...

On Wed 09 Mar 2022 at 08:35:57 +0100  Petra R.-P.  
wrote:

 [...]
> Okay, that's easier:  See attached  dmesg-T41-k5.15.txt .

Adding dmesg-T41-b-k5.15.txt — corresponding file for the other
T41 notebook, which has slightly different hardware.

Best,
Petra
[0.00] Linux version 5.15.0-3-686 (debian-ker...@lists.debian.org) 
(gcc-11 (Debian 11.2.0-14) 11.2.0, GNU ld (GNU Binutils for Debian) 
2.37.90.20220123) #1 SMP Debian 5.15.15-2 (2022-01-30)
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] signal: max sigframe size: 1440
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved
[0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1ff5] usable
[0.00] BIOS-e820: [mem 0x1ff6-0x1ff76fff] ACPI data
[0.00] BIOS-e820: [mem 0x1ff77000-0x1ff78fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x1ff8-0x1fff] reserved
[0.00] BIOS-e820: [mem 0xff80-0x] reserved
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] SMBIOS 2.3 present.
[0.00] DMI: IBM 2374TG6/2374TG6, BIOS 1RETCDWW (3.06f) 06/18/2004
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 1594.697 MHz processor
[0.005065] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.005074] e820: remove [mem 0x000a-0x000f] usable
[0.005087] last_pfn = 0x1ff60 max_arch_pfn = 0x10
[0.005860] x86/PAT: PAT not supported by the CPU.
[0.006732] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC- UC  
[0.015451] initial memory mapped: [mem 0x-0x1cff]
[0.015510] RAMDISK: [mem 0x1d984000-0x1f244fff]
[0.015521] ACPI: Early table checksum verification disabled
[0.015529] ACPI: RSDP 0x000F6E00 24 (v02 IBM   )
[0.015542] ACPI: XSDT 0x1FF6ABE8 4C (v01 IBMTP-1R
3066  LTP )
[0.015556] ACPI: FACP 0x1FF6AD00 F4 (v03 IBMTP-1R
3066 IBM  0001)
[0.015569] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Gpe0Block: 64/32 (20210730/tbfadt-564)
[0.015578] ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid 
Address but zero Length: 0x102C/0x0 (20210730/tbfadt-615)
[0.015590] ACPI: DSDT 0x1FF6AEE7 00BFBA (v01 IBMTP-1R
3066 MSFT 010E)
[0.015601] ACPI: FACS 0x1FF78000 40
[0.015610] ACPI: FACS 0x1FF78000 40
[0.015618] ACPI: SSDT 0x1FF6AEB4 33 (v01 IBMTP-1R
3066 MSFT 010E)
[0.015629] ACPI: ECDT 0x1FF76EA1 52 (v01 IBMTP-1R
3066 IBM  0001)
[0.015640] ACPI: TCPA 0x1FF76EF3 32 (v01 IBMTP-1R
3066 PTL  0001)
[0.015650] ACPI: BOOT 0x1FF76FD8 28 (v01 IBMTP-1R
3066  LTP 0001)
[0.015660] ACPI: Reserving FACP table memory at [mem 0x1ff6ad00-0x1ff6adf3]
[0.015665] ACPI: Reserving DSDT table memory at [mem 0x1ff6aee7-0x1ff76ea0]
[0.015669] ACPI: Reserving FACS table memory at [mem 0x1ff78000-0x1ff7803f]
[0.015674] ACPI: Reserving FACS table memory at [mem 0x1ff78000-0x1ff7803f]
[0.015679] ACPI: Reserving SSDT table memory at [mem 0x1ff6aeb4-0x1ff6aee6]
[0.015683] ACPI: Reserving ECDT table memory at [mem 0x1ff76ea1-0x1ff76ef2]
[0.015688] ACPI: Reserving TCPA table memory at [mem 0x1ff76ef3-0x1ff76f24]
[0.015693] ACPI: Reserving BOOT table memory at [mem 0x1ff76fd8-0x1ff76fff]
[0.015715] 0MB HIGHMEM available.
[0.015718] 511MB LOWMEM available.
[0.015721]   mapped low ram: 0 - 1ff6
[0.015725]   low ram: 0 - 1ff6
[0.015741] Zone ranges:
[0.015743]   DMA  [mem 0x1000-0x00ff]
[0.015750]   Normal   [mem 0x0100-0x1ff5]
[0.015756]   HighMem  empty
[0.015760] Movable zone start for each node
[0.015763] Early memory node ranges
[0.015766]   node   0: [mem 0x1000-0x0009efff]
[0.015771]   node   0: [mem 0x0010-0x1ff5]
[0.015776] Initmem setup node 0 [mem 0x1000-0x1ff5]
[0.015796] On node 0, zone DMA: 1 pages in unavailable ranges
[0.016005] On node 0, zone DMA: 97 pages in unavailable ranges
[0.025301] Using APIC driver default
[0.025444] ACPI: PM-Timer IO Port: 0x1008
[0.025453] Local APIC disabled by BIOS -- you can enable it with "lapic"
[0.025457] APIC: disable apic facility
[0.025460] APIC: switched to apic NOOP
[0.025464] smpboot: Allowing 1 CPUs, 0 

Bug#990279: Status?

[Andrew]

The patch appears to be applied as of kernel security update 5.10.0-12, 
linux_5.10.103-1 source.


On Wed, 9 Feb 2022 14:22:23 -0600 (CST) Timothy Pearson 
 wrote:

>
>
> - Original Message -
> > From: "Salvatore Bonaccorso" 
> > To: "Timothy Pearson" , "990279" 
<990...@bugs.debian.org>
> > Cc: "Christian König" , "Xi Ruoyao" 
, "Alex Deucher"

> > 
> > Sent: Wednesday, February 9, 2022 2:18:34 PM
> > Subject: Re: Bug#990279: Status?
>
> > Hi Timothy,
> >
> > On Wed, Feb 09, 2022 at 01:20:40PM -0600, Timothy Pearson wrote:
> >> - Original Message -
> >> > From: "Christian König" 
> >> > To: "Timothy Pearson" , 
"Salvatore Bonaccorso"

> >> > 
> >> >>
> >> >> If you need me to generate / submit a patch just let me know.
> >> >
> >> > Please do, I don't have time nor a test system to look into 
this.

> >> >
> >> > Regards,
> >> > Christian.
> >>
> >> Submitted here:
> >> 
> >
> > This is not exactly what we meant. The idea is to submit it to
> > upstream for stable 5.10.y so we can pick it up in Debian. I'm 
taking

> > the backport in #47 now.
> >
> > It is now submitted here:
> > 


> >
> > Regards,
> > Salvatore
>
> Understood, apologies for the mixup.  I'll monitor the upstream 
submission and help push it through if needed.

>
> Thanks!
>
>

Bug#1006977: ITP: open-plc-tools -- Toolkit for powerline network adapters with Atheros chipsets

[Mark Hindley]

Package: wnpp
Severity: wishlist
Owner: Mark Hindley 

* Package name: open-plc-tools
  Version : 0.0.6
  Upstream Author : Qualcomm Atheros, Inc.
* URL : https://github.com/qca/open-plc-utils
* License : Clear BSD
  Programming Lang: C
  Description : Toolkit for powerline network adapters with Atheros chipsets

Includes tools for manipulation and modification of pib and nvm files as well as
tools to upload/flash them to the adapter chipset.

Bug#1006976: what about dynamically allocated groups?

[Marc Haber]

Package: debian-policy
Version: 4.6.0.1
Severity: minor

Hi,

9.2.2 distinguishes between

100-999:
   Dynamically allocated system users and groups.

and

1000-5:
   Dynamically allocated user accounts.

This wording is a bit confusing, but this is probably caused by the
ambiguity between users and accounts. I am also astonished that the
1000-5 GIDs are not mentioned in policy, or is a group also a very
special kind of account? Probably yes, at least that's what groupadd's
docs say. So the easiest way to solve this and to be consistent with
passwd/shadow would be:

How about:

100-999:
   Dynamically allocated system user and system group accounts.
   Packages which need a user or group, but can have them and their
   UID/GIDs allocated dynamically and differently on each system, should
   use "adduser --system" or "addgroup --system" to create them as
   needed.  These tools will check for the existence of the user or
   group, and if necessary choose an unused id based on the ranges
   specified in "adduser.conf".

1000-5:
   Dynamically allocated user and group accounts. By default "adduser"
   and "addgroup" will choose UIDs and GIDs for user and group accounts
   in this range, though "adduser.conf" may be used to modify this
   behavior.

Greetings
Marc

Bug#1006975: need better docs to explain system and user accounts

[Marc Haber]

Package: adduser
Version: 3.118
Severity: minor

Adduser needs a bit of explanation about what we see as a system accont
and what we see as a user account. Especially the system account can be
mistaken with an account that is defined on the local system, that is,
defined in /etc/password, making an account mh with uid 12345 a system
account as well (which is not the case in our wording).

Policy 9.2.2 distinguishes between "dynamically allocated system
users and groups" and "dynamcially allocated user accounts". Maybe we
should adopt this wording in our docs or at least refer to policy from
our docs.

Greetings
Marc

Bug#1006380: Blocked by r-cran-jinjar (waiting in new queue)

[Andreas Tille]

Control: block -1 by 1005377

The new upstream version of r-cran-emayili needs r-cran-jinjar
which is waiting in new queue.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#1006150: python3-pip: Error when trying to list packages that need to be updated (local and system-wide)

[Stefano Rivera]

Hi Christian (2022.03.07_11:06:03_-0400)
> Maybe there's a potential race while zipimporting modules, that one
> doesn't see with regular imports? Or I'd assume upstream would have run
> into this bug by now. I marked the fixed version based on the zipimport
> hunch.

Yes, there is. And it has already been fixed in Python 3.10, as part of
https://bugs.python.org/issue42131

Reproducer attached.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272
#!/usr/bin/env python3

import argparse
import sys
import tempfile
import threading
import time
import zipfile


SLOWIMPORT = """
import time

def prepare():
time.sleep(1)
return 'complete'

status = prepare()
"""


class Monitor(threading.Thread):
def run(self):
global success
for i in range(12):
if 'slowimport' in sys.modules:
import slowimport
assert hasattr(slowimport, 'status')
success = True
print('Monitor:', slowimport.status)
return
time.sleep(0.1)


def reproduce():
global success
sys.modules.pop('slowimport', None)
success = False
m = Monitor()
m.start()
import slowimport
print(slowimport.status)
m.join()
return success


def main():
p = argparse.ArgumentParser()
p.add_argument('--zip', action='store_true')
p.add_argument('--py', action='store_true')
args = p.parse_args()
if args.zip:
with tempfile.NamedTemporaryFile(prefix='slowimport', suffix='.zip') as f:
with zipfile.ZipFile(f, 'w') as z:
z.writestr('slowimport.py', SLOWIMPORT)
f.flush()
sys.path.append(f.name)
r = reproduce()
elif args.py:
with tempfile.TemporaryDirectory(prefix='slowimport') as tempdir:
with open(f'{tempdir}/slowimport.py', 'w') as f:
f.write(SLOWIMPORT)
sys.path.append(tempdir)
r = reproduce()
else:
p.error('One of --zip or --py is required.')
if not r:
sys.exit(1)


if __name__ == '__main__':
main()

Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye

[Michael Prokop]

Hi,

* Santiago Garcia Mantinan [Mon Sep 06, 2021 at 11:04:58AM +0200]:
> I'm CCing Josué because this seems to be more on ifupdown's side than on
> bridge-utils.

[...]

> I know we are having quite some trouble with the random bridge mac address,
> but this doesn't seem to be one of those cases.
> 
> For what I see this is a problem with DAD, the bridge is created without any
> port attached to it, so the kernel doesn't allow it to transition from:
> 18: br0inet6 X/64 scope link tentative \   valid_lft forever 
> preferred_lft forever
> to:
> 18: br0inet6 X/64 scope link \   valid_lft forever preferred_lft 
> forever
[...]

> As for this bug... I believe it is on the ifupdown side, so I think we
> should reasign it, unless you see a way to fix this problem on the
> bridge-utils side, but I can't think about any fix on bridge-utils side
> right now.

bridge-utils disappeared from Debian/testing due to this RC bug,
should we downgrade severity and/or reassign the bug to proceed from
here?

regards
-mika-


signature.asc
Description: PGP signature

Bug#1006973: new upstream (6.3.1)

[Daniel Baumann]

Package: otrs2

Hi,

znuny 6.3.1 has been released, it would be nice if you could upgrade, it
contains a bunch of improvements.

Regards,
Daniel

Bug#1006912: is it time to have account deletion in policy?

[Andrey Rahmatullin]

Previous, still open, bug from 2004: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228692

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#998516: bridge-utils: Kernel assigns same MAC-address to the bridge on 2 similar network devices

[Michael Prokop]

Hi,

* Alf [Thu Nov 04, 2021 at 08:24:35PM +0100]:

> Having 2 tiny servers (APU2.C4 and APU.2D4) in my local net each having
> 3 ethernet interfaces assigned to a bridge "br0" (configured in 
> /etc/network/interfaces).
> Upgrading from Bustser to Bullseye worked fine for the first box, the bridge
> received a new MAC assigned by the kernel as described in the listchanges.
> After reconfiguring that in the roter everything was working as before.
> 
> Upgrading the second box in the same network segment lead to almost complete
> blocking of traffic in my local network and the 2nd box was not detected by 
> the router.
> Connecting via serial console and checking network setup revealed:
> 
> The second box got precisely the SAME MAC address as the first box!

> After using bridge_hw to assign the old MAC based on the MAC of one interface 
> solved the problem.
> 
> Conclusion is that hardware addresses should be unique in general, but the
> current way generates same address also if the MAC's of involved interfaces 
> differs - see here:
[...]

Could it be, that the two systems use the same machine ID?
(See e.g. https://github.com/systemd/systemd/issues/21185)

regards
-mika-


signature.asc
Description: PGP signature

Bug#1006972: ITP: node-tad -- Javascript test suite with minimal hassle

[Yadd]

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

* Package name: node-tad
  Version : 3.1.0
  Upstream Author : Mariusz Nowak 
* URL : https://github.com/medikoo/tad
* License : ISC
  Programming Lang: JavaScript
  Description : Javascript test suite with minimal hassle

TAD is a Javascript test suite that allow writing tests with minimal hassle.
It locates test file and provide tested module for test functions.

There are already many JS test suites in Debian, however test files are
not compatible. This test suite is required to enable test, at least,
for: node-es5-ext, node-es6-iterator, node-es6-map, node-es6-set,
node-es6-symbol, node-es6-weak-map and node-event-emitter.

Package will be maintained under JS Team umbrella.

Bug#1006970: Please set the NO_PKG_MANGLE variable (for Ubuntu)

[Gunnar Hjalmarsson]

This is the MR:

https://salsa.debian.org/debian/debianutils/-/merge_requests/23

Bug#1006970: Please set the NO_PKG_MANGLE variable (for Ubuntu)

[Gunnar Hjalmarsson]

Package: debianutils
Version: 5.7-0.1
Severity: wishlist

Dear maintainer,

Currently Ubuntu uses a version of debianutils (5.5-1ubuntu1) with a 
change. The reason is that we wanted to reverse the planned "which" and 
"tempfile" changes for 22.04 LTS. Since those changes were reversed at 
Debian afterwards (at least for now), we would like to soon sync the 
source from Debian again.


To make that easier, I ask you to set the NO_PKG_MANGLE variable at 
build time. While doing so is a no-op in Debian, it's useful in Ubuntu 
due to the language pack procedures.


I'll submit a related merge request.

--
Cheers,
Gunnar Hjalmarsson

Bug#1006615: python3-pybind11: Handle Python 3.10's default sysconfig paths

[stefanor]

Hi Gianfranco (2022.03.09_15:40:56_+)
> Why is then gemmi in Ubuntu installing stuff into /usr/local/lib/python3.10 
> and dh-python not moving it into /usr/lib?

Because dh_python3 hasn't been called yet, at this point in the build.
You need to update the dh_install config file.

> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/sfcalc.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/sprintf.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/mmcif.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/assembly.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/floodfill.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/asudata.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/metadata.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/to_mmdb.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/utf.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/placeh.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/read_coor.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/remarks.hpp
> -- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/solmask.hpp

Hrm, these should probably go to /usr/local unless redirected to /usr.
Sounds like this patch needs some more work.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Sean Whitton]

Dear Dirk,

On Wed 09 Mar 2022 at 12:59pm +01, Dirk Kostrewa wrote:

> Personally, I would still prefer a "rename" entry in the alternative
> system with util-linux's rename as default, since util-linux is
> installed in every Debian system. I know, the syntaxes of util-linux's
> rename and of Perl's rename are incompatible, but a user who wants to
> use Perl's rename would probably know its syntax, would have to actively
> install its package, and would then choose Perl's rename in the
> alternative system.

Right, yes, but unfortunately this is off the table for reasons of
historical compatibility.

> If an entry in the alternative system is not wanted, for me, it would
> also be fine to have access to util-linux's rename in any PATH with any
> recognizable name. I would then create a soft-link, say,
> /usr/local/bin/rename, that points to util-linux's rename.

Hmm, if you are planning to create a symlink, then wouldn't both (A) and
(B) be okay with you?

-- 
Sean Whitton

Bug#993451: osslsigncode distribution does not have production-quality tests (yet)

[Stephen Kitt]

Hi Mike,

Le 09/03/2022 13:41, Michał Trojnara a écrit :
Didn't you notice that these tests are *not* part of the osslsigncode 
release tarball?  Just because some random code can be found is in the 
same GitHub repository doesn't meany it's suitable for production use.


Apologies, I did not notice this. Unfortunately the previous 
version-tracking setup downloaded the tag-based tarballs provided by 
GitHub rather than the separate release tarballs you prepared. I’ve 
fixed that, so going forward the release tarballs will be used (and 
their signature verified).


There is a very good reason why "make check" doesn't work in 
osslsigncode.  It will work when the tests are ready for production 
use.  Hopefully soon.  We're working on this.


Noted, thanks!

Regards,

Stephen

Bug#1006615: python3-pybind11: Handle Python 3.10's default sysconfig paths

[Gianfranco Costamagna]

Hello Stefano

Why is then gemmi in Ubuntu installing stuff into /usr/local/lib/python3.10 and 
dh-python not moving it into /usr/lib?

-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/sfcalc.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/sprintf.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/mmcif.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/assembly.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/floodfill.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/asudata.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/metadata.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/to_mmdb.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/utf.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/placeh.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/read_coor.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/remarks.hpp
-- Installing: /gemmi-0.5.2+ds/debian/tmp/usr/include/gemmi/solmask.hpp
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi.cpython-310-x86_64-linux-gnu.so
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/merge_mtz_mmcif.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/weight.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/rama_gather.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/__pycache__
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/col_order.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/hello.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/maskdiff.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/cif_i_sigi.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/simple_search.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/monomers.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/maskcheck.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/mtrix_iso.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/__main__.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/mtz_i_sigi.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/matthews.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/multiproc.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/sub_ccd.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/ccd_subgraph.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/rama_plot.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/map2mtz.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/long_geom.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/aafreq.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/ccd_gi.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/patterson_slice.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/from_json.py
-- Installing: 
/gemmi-0.5.2+ds/debian/tmp/usr/local/lib/python3.10/dist-packages/gemmi-examples/__init__.py
make[1]: Leaving directory '/gemmi-0.5.2+ds/obj-x86_64-linux-gnu'
   dh_install -O--buildsystem=cmake
dh_install: warning: Cannot find (any matches for) "usr/lib/python3" (tried in 
., debian/tmp)

dh_install: warning: python3-gemmi missing files: usr/lib/python3
dh_install: error: missing files, aborting
make: *** [debian/rules:8: install] Error 255


Similar happens to firewalld, using just standard and plain dh_python3 tool.

Do you mean that a fix for this move from /usr/local/lib into /usr/lib has 
still to be implemented into dh_python?

G.

Bug#907264: faketime: timezone bugs: lax parsing, no way to specify UTC or TZ

[Daniel Kahn Gillmor]

Control: reassign 907264 libc6 2.33-7
Control: retitle 907264 glibc's strptime does not handle %z and %Z as expected
Control: affects 907264 + faketime

On Sat 2018-08-25 21:44:04 +0200, Wolfgang Hommel wrote:
> Apparently, glibc goes for a new tm->tm_gmtoff field and supports %z 
> (but not %Z) fully yet. This might give some headaches regarding 
> cross-platform compatibility, and implementing a completely own parser 
> (i.e., not using strptime()) does not seem viable, either. So yes, this 
> needs to be addressed, but will take some time.

Since the problem appears to be in strptime(), i'm reassigning this bug
to glibc.

   --dkg


signature.asc
Description: PGP signature

Bug#1005065: bookletimposer does not start

[Kjö Hansi Glaz]

Hi,

GMiller:
> Package: bookletimposer
> Version: 0.3
> 
Thanks for trying bookletimposer.

> Traceback (most recent call last):
> File "/usr/bin/bookletimposer", line 165, in 
> main()
> File "/usr/bin/bookletimposer", line 140, in main
> ui = gui.BookletImposerUI(preferences)
> File "/usr/lib/python3/dist-packages/bookletimposer/gui.py", line 68, in 
> __init__
> self.__create_gui()
> File "/usr/lib/python3/dist-packages/bookletimposer/gui.py", line 78, in 
> __create_gui
> builder.add_from_file(os.path.join(config.get_datadir(),
> gi.repository.GLib.Error: g-file-error-quark: Failed to open file 
> “data/bookletimposer.ui”: No such file or directory (4)
> 
I can't reproduce this bug under latest debian. This looks specific to
your setup. Please provide steps for me to reproduce the bug under
debian stable.

Cheers

Bug#1006969: RFS: rumur/2022.03.05-1 [RC] -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "rumur":

* Package name: rumur
   Version : 2022.03.05-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   Section : devel

It builds those binary packages:

  rumur - model checker for the Murphi language

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/rumur/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2022.03.05-1.dsc

Changes since the last upload:

rumur (2022.03.05-1) unstable; urgency=medium
.
   * New upstream release.
.
   * Fix sandbox failures due to statx. Closes: #1004035.

Regards,
Matt

Bug#753461: faketime causes some complex runtime environments (including firefox) to hang

[Daniel Kahn Gillmor]

Control: retitle 753461 faketime causes some complex runtime environments 
(including firefox) to hang
Control: tags 753461 - unreproducible
Control: tags 753461 + upstream
Control: forwarded 753461 https://github.com/wolfcw/libfaketime/issues/373

On Wed 2014-08-06 22:38:28 +0200, Wolfgang Hommel wrote:
> In this case, the observed behavior is quite typical for applications 
> which load system libraries (including time-related functions) 
> themselves at run-time. It basically means that the LD_PRELOAD mechanism 
> is somewhat bypassed by the application, which loads the real (not the 
> faking) library again after the linker has loaded the faking library. 
> Strange things (such as slow reactions with few-seconds-offsets or 
> endless hangs with larger offsets) occur when the application is 
> multi-threaded and one thread sees a faked time while another one uses 
> the real system time, and both try to synchronize.

I've just replicated the reporeted behavior with firefox 96.0.3-1 on
debian testing, using a simple testing profile in safe mode:

   faketime 2022-01-01 firefox -P test -no-remote -safe-mode

this hangs indefinitely, presumably due to some of the concerns that
Wolfgang outlines above.

I don't think this is something that we can fix in debian, but i've
noted it in the upstream bugtracker.

  --dkg


signature.asc
Description: PGP signature

Bug#892149: faketime(1) fails on hurd: sem_open: Operation not supported

[Daniel Kahn Gillmor]

On Mon 2018-03-05 22:00:35 -0500, Aaron M. Ucko wrote:

> The faketime executable fails on hurd-i386 (admittedly not a release
> architecture) with the error
>
>   sem_open: Operation not supported
>
> as seen in [1].

This doesn't seem to be a problem any more on hurd, though i don't think
that faketime itself changed anything significant.  Rather, i suspect
that libc6 changed on hurd in ways that were more compatible with
faketime.

I'm closing this now because i'm unable to replicate the problem, but if
someone can replicate it, please reopen!

--dkg



signature.asc
Description: PGP signature

Bug#1002581: Patch tested

[Kjö Hansi Glaz]

Hi,

I hit this bug and was able to reproduce it with the following steps :

- add to sources.list:

deb cdrom://[Debian GNU/Linux 11.2.0 _Bullseye_ - Official amd64 DVD
Binary-1 20211218-11:13] bullseye Release

- make a change in software-properties-gtk, e.g. enable contrib

- click the "Close" button

- click the "Refresh" button

I applied the proposed path that fixed the issue for me.

Cheers

Bug#1006747: SIGSEGV: Click 'Update All' then 'Next Unread Item'

[Roland Clobus]

Hello Paul,

On 07/03/2022 21:55, Paul Gevers wrote:

On 04-03-2022 10:23, Roland Clobus wrote:

Occasionally I'm experiencing SIGSEGV in liferea.


Thank you for this high quality bug report. I sent it upstream and there 
is already a pull request supposedly fixing the issue.


If you don't mind, I'll just wait until upstream releases a new version.


Now that I know which combination of actions does result in the crash, I 
can avoid that scenario.


Thanks for forwarding the issue upstream.

With kind regards,
Roland Clobus


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006744: open-vm-tools core dump on debian 10

[Chilukuri, Girish - Dell Team]

Hi Bernd,
We tried installing 11.3.5 from buster-backports-sloppy and see the 
same core dump issue. We downloaded the 11.3.5 stable source code tried to 
build the code and install with below steps 
autoreconf -i
./configure
make
sudo make install
sudo ldconfig

Installation was successful and didn't see the core. 

Now we are trying to build the code on other Debian 10 vm, we are seeing lot of 
dependency issues like pam, mspack, glib2, pkg-config, xml2, etc while running 
"./configure". How to resolve these dependencies, Is there are any specific 
steps to perform before running the above commands. 

Is there a way to generate a build/package libs where build is generated 
successfully. 

Thanks,
 Girish


Internal Use - Confidential

-Original Message-
From: Bernd Zeimetz  
Sent: Tuesday, March 8, 2022 7:36 PM
To: Chilukuri, Girish - Dell Team; 1006...@bugs.debian.org
Cc: Singh, Harmeet - Dell Team; Paturu, Santhosh - Dell Team
Subject: Re: Bug#1006744: open-vm-tools core dump on debian 10


[EXTERNAL EMAIL] 

Hi Girish,

could you give 11.3.5 from buster-backports-sloppy a try please?
If that doesn't fix it, 12.0 was released recently, but that will take a bit 
until packages are ready. You could download it from gthub and build/test it, 
though.

Also - please note that bullseye is the current stable release.


Bernd


On 2022-03-08 11:18, Chilukuri, Girish - Dell Team wrote:
> Hi Bernd,
>Debian buster we are using.
> 
> Thanks,
>  Girish
> 
> 
> Internal Use - Confidential
> 
> -Original Message-
> From: Bernd Zeimetz 
> Sent: Tuesday, March 8, 2022 2:13 PM
> To: Chilukuri, Girish - Dell Team; 1006...@bugs.debian.org
> Cc: Singh, Harmeet - Dell Team; Paturu, Santhosh - Dell Team
> Subject: Re: Bug#1006744: open-vm-tools core dump on debian 10
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> did you actually install the debug packages? The backtrace doesn't 
> look like that.
> Please do so.
> 
> https://urldefense.com/v3/__https://wiki.debian.org/HowToGetABacktrace
> __;!!LpKI!0puEtOoAByFgLNggB_VMDeU15wGT9ZJdww_v-PEituwvNiosvGG9pv-_z76w
> Y7MGw9htYJ8$
> [wiki[.]debian[.]org]
> 
> Which release are you using? Bullseye? Or something else? What is 
> "your product"?
> 
> 
> Thanks,
> 
> Bernd
> 
> On 2022-03-08 07:37, Chilukuri, Girish - Dell Team wrote:
>> Hi Bernd,
>> Below is the full backtrace from all threads from the 
>> core file.
>> 
>> gdb /usr/bin/vmtoolsd rp_core.417
>> 
>> GNU gdb (Debian 8.2.1-2+b3) 8.2.1
>> Copyright (C) 2018 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later 
>> > I!0puEtOoAByFgLNggB_VMDeU15wGT9ZJdww_v-PEituwvNiosvGG9pv-_z76wY7MGF37
>> RWWE$
>> [gnu[.]org]>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> Type "show copying" and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> > !!LpKI!0puEtOoAByFgLNggB_VMDeU15wGT9ZJdww_v-PEituwvNiosvGG9pv-_z76wY7
>> MGIaDgDPE$
>> [gnu[.]org]>.
>> Find the GDB manual and other documentation resources online at:
>> 
>> > ation/__;!!LpKI!0puEtOoAByFgLNggB_VMDeU15wGT9ZJdww_v-PEituwvNiosvGG9p
>> v-_z76wY7MGraty7eo$
>> [gnu[.]org]>.
>> 
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /usr/bin/vmtoolsd...(no debugging symbols 
>> found)...done.
>> [New LWP 417]
>> [New LWP 1105]
>> [Thread debugging using libthread_db enabled] Using host libthread_db 
>> library "/usr/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `/usr/bin/vmtoolsd'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
>> 120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or
>> directory.
>> [Current thread is 1 (Thread 0x7f321f095780 (LWP 417))]
>> (gdb) where
>> #0  0x7f321f589206 in __strlen_sse2 () at
>> ../sysdeps/x86_64/multiarch/../strlen.S:120
>> #1  0x7f321f56b475 in __GI___fputs_unlocked
>> (str=0x7f321e2f7ac8 > 0x7f321e2f7ac8>, fp=fp@entry=0x55d222325690)
>> at iofputs_u.c:34
>> #2  0x7f321f5e4868 in __GI___vsyslog_chk (pri=, 
>> flag=1, fmt=0x7f321edc083c "%s.", ap=0x7ffd36e1eda0)
>> at ../misc/syslog.c:205
>> #3  0x7f321f5e4dff in __syslog_chk (pri=, 
>> flag=, fmt=)
>> at ../misc/syslog.c:129
>> #4  0x7f321edbb1db in Audit_EventV () at /lib/libvgauth.so.0
>> #5  0x7f321edbb2a4 in Audit_Event () at /lib/libvgauth.so.0
>> #6  0x7f321edb7f95 in VGAuth_AuditEvent () at /lib/libvgauth.so.0
>> #7  0x7f321edb6d05 in VGAuth_ValidateUsernamePassword () at
>> 

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Axel Beckert]

Hi Damien,

Damien Le Moal wrote:
> > Ok, did another one, this time with "debug loglevel=7" added on the
> > kernel commandline by editing it in GRUB:
> > 
> > https://noone.org/debian/Bug-Reports/1006149/DSCN5259.MOV
> 
> Thanks for this. But unfortunately, it does not tell us much as to what
> is going on...

Ah, what a pity. Thanks for having a look anyways.

> Could you send me dmesg output of a clean boot with 5.15
> kernel ?

Sure. I already posted this to the Debian bug report at
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1006149;filename=5.15.15-2.dmesg.xz;msg=96
shortly before you got into the loop.

> Also, once booted in 5.15, install sg3utils and run these commands:
>
> sudo sg_sat_read_gplog --log=0 --page=0 /dev/sdX
> sudo sg_sat_read_gplog --log=0 --page=0 --dma /dev/sdX

[I find it disturbing how often people just prepend "sudo" in
instructions when they actually mean "as root". Not everyone has sudo
installed — usually for good reasons.]

# sg_sat_read_gplog --log=0 --page=0 /dev/sda
 00 0001   0002     .. .. .. .. .. .. .. ..
 08         .. .. .. .. .. .. .. ..
 10         .. .. .. .. .. .. .. ..
 18         .. .. .. .. .. .. .. ..
 20         .. .. .. .. .. .. .. ..
 28         .. .. .. .. .. .. .. ..
 30         .. .. .. .. .. .. .. ..
 38         .. .. .. .. .. .. .. ..
 40         .. .. .. .. .. .. .. ..
 48         .. .. .. .. .. .. .. ..
 50         .. .. .. .. .. .. .. ..
 58         .. .. .. .. .. .. .. ..
 60         .. .. .. .. .. .. .. ..
 68         .. .. .. .. .. .. .. ..
 70         .. .. .. .. .. .. .. ..
 78         .. .. .. .. .. .. .. ..
 80 0010        .. .. .. .. .. .. .. ..
 88         .. .. .. .. .. .. .. ..
 90         .. .. .. .. .. .. .. ..
 98         .. .. .. .. .. .. .. ..
 a0         .. .. .. .. .. .. .. ..
 a8         .. .. .. .. .. .. .. ..
 b0         .. .. .. .. .. .. .. ..
 b8         .. .. .. .. .. .. .. ..
 c0         .. .. .. .. .. .. .. ..
 c8         .. .. .. .. .. .. .. ..
 d0         .. .. .. .. .. .. .. ..
 d8         .. .. .. .. .. .. .. ..
 e0 0001 0001       .. .. .. .. .. .. .. ..
 e8         .. .. .. .. .. .. .. ..
 f0         .. .. .. .. .. .. .. ..
 f8         .. .. .. .. .. .. .. ..
# sg_sat_read_gplog --log=0 --page=0 --dma /dev/sda
ATA PASS-THROUGH (16), bad field in cdb
sg_sat_read_gplog failed: Illegal request
#

Since the last output might be a hardware-specific issue, here some
more information on /dev/sda:

# fdisk -l /dev/sda
Disk /dev/sda: 149.05 GiB, 160041885696 bytes, 312581808 sectors
Disk model: SAMSUNG HM160HC
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000500cc

Device Boot   Start   End   Sectors   Size Id Type
/dev/sda1  * 63993279993217   485M 83 Linux
/dev/sda3996030   2988089   1992060 972.7M 82 Linux swap / Solaris
/dev/sda4   2988090 312576704 309588615 147.6G  5 Extended
/dev/sda5   2988153  86874232  8388608040G 83 Linux
# smartctl --info /dev/sda
smartctl 7.2 2020-12-30 r5155 [i686-linux-5.15.0-3-686-pae] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: SAMSUNG SpinPoint M5
Device Model: SAMSUNG HM160HC
Serial Number:S12TJD0SA62821
LU WWN Device Id: 5 0f 003162821
Firmware Version: LQ100-10
User Capacity:160’041’885’696 bytes [160 GB]
Sector Size:  512 bytes logical/physical
Device is:In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS, ATA/ATAPI-7 T13/1532D revision 0
Transport Type:   Parallel, Unknown (0x00f)
Local Time is:Wed Mar  9 

Bug#1006967: ITP: pcapy-ng -- Python module for the pcap packet capture library

[Daniel Baumann]

Package: wnpp

  * Package name : pcapy-ng
  * Upstream Author :  Miroslav Stampar
  * License : Apache
  * Homepage : https://github.com/stamparm/pcapy-ng

(the following is copied from the website, not the actual package
description to be used)

Pcapy-NG is a Python extension module that enables software written in
Python to access the routines from the pcap packet capture library. It
is a replacement of Pcapy, which is not maintained any more and stopped
working altogether on Python3.10 (Issue).

>From libpcap's documentation: "Libpcap is a system-independent interface
for user-level packet capture. Libpcap provides a portable framework for
low-level network monitoring. Applications include network statistics
collection, security monitoring, network debugging, etc."

Regards,
Daniel

Bug#1006946: Usb connected printer not working

[eHenry Berg]

Hi,

I made the following today:

apt-get upgrade, 2022-03-09:
# tail -n 100 history.log|less// Search cups
Start-Date: 2022-03-09  13:50:28
Commandline: apt-get upgrade
libcups2:arm64 (2.4.1op1-1, 2.4.1op1-2)
cups-bsd:arm64 (2.4.1op1-1, 2.4.1op1-2)
cups-common:arm64 (2.4.1op1-1, 2.4.1op1-2)
cups-client:arm64 (2.4.1op1-1, 2.4.1op1-2)
cups-ppdc:arm64 (2.4.1op1-1, 2.4.1op1-2)
cups-daemon:arm64 (2.4.1op1-1, 2.4.1op1-2)
cups-ipp-utils:arm64 (2.4.1op1-1, 2.4.1op1-2)
cups-core-drivers:arm64 (2.4.1op1-1, 2.4.1op1-2)
cups:arm64 (2.4.1op1-1, 2.4.1op1-2)
cups-server-common:arm64 (2.4.1op1-1, 2.4.1op1-2)

Now the usb connected printer is working! Many thanks!

This bug can now be closed.

Best Regards,
Evald

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Diederik de Haas]

Hi Petra and Axel,

On Wednesday, 9 March 2022 08:11:37 CET Damien Le Moal wrote:
> Could you try this patch:
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 62eb9921cc94..525ce40b524d 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -3320,6 +3320,7 @@ static int sd_revalidate_disk(struct gendisk *disk)
> sd_read_block_limits(sdkp);
> sd_read_block_characteristics(sdkp);
> sd_zbc_read_zones(sdkp, buffer);
> +   sd_read_cpr(sdkp);
> }
> 
> sd_print_capacity(sdkp, old_capacity);
> @@ -3329,7 +3330,6 @@ static int sd_revalidate_disk(struct gendisk *disk)
> sd_read_app_tag_own(sdkp, buffer);
> sd_read_write_same(sdkp, buffer);
> sd_read_security(sdkp, buffer);
> -   sd_read_cpr(sdkp);
> }
> 
> /*

On Wednesday, 9 March 2022 08:35:57 CET Petra R.-P. wrote:
> I am very sorry, but I am a simple user, not a developer.
> It would need a lot of tuition to make me accomplish that,
> and I'm not sure I'd have enough time at the moment.

If you save the above patch to f.e. 'fix-bug1006149.patch' and then follow
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
 (after having followed 4.2.1 Preparation), then you should 
get a kernel package with that patch applied.
That's relatively easy ... if you're a developer.
While I can understand that it would still be too complicated for Petra, it 
should be doable for Axel (being a DD).
I could try to help further if needed.

HTH (a bit ;-))

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

Bug#726803: qbittorrent fails to respond after sometime and gdb session kinda hangs.

[Christian Marillat]

Hi,

Could you tell me if this bug is still reproducible ?

Christian

Bug#727535: qbittorrent: Invalid WM_TRANSIENT_FOR window 0x3000005 specified for 0x3000003 (qbittorren)

[Christian Marillat]

Hi,

Could you tell me if this bug is still reproducible ?

Christan

Bug#1006965: ITP: python-datetimerange -- library that handles time ranges

[Thomas Goirand]

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

* Package name: python-datetimerange
  Version : 1.2.0
  Upstream Author : Tsuyoshi Hombashi 
* URL : https://github.com/thombashi/DateTimeRange
* License : Expat
  Programming Lang: Python
  Description : library that handles time ranges

 DateTimeRange is a Python library to handle a time range. e.g. check whether a
 time is within the time range, get the intersection of time ranges, truncating
 a time range, iterate through a time range, and so forth.

Note: This is a new (direct) dependency of OpenStack Rating (cloudkitty).

Bug#998897: python3-sip: Thread 1 "python" received signal SIGSEGV, Segmentation fault.

[artem rus]

Hi Dmitry.

Upstream said to remove "sipSetNotInMap(sw);" and made commit to sip6
(hg clone https://www.riverbankcomputing.com/hg/sip)

changeset 2677:072b8949de41 in sip6
Fix a use-after-free bug in all versions of the sip module.
authorPhil Thompson 
dateSat, 15 Jan 2022 13:24:29 +

Do you have plans to update LTS releases ?

вс, 9 янв. 2022 г. в 22:35, Dmitry Shachnev :
>
> Try subscribing to the mailing list before sending your email.
>
> For use-after-free bugs, I find valgrind tool handy, which detects such 
> issues even when the program wouldn't crash.
>
>
> On January 9, 2022 10:18:08 PM GMT+03:00, artem rus  
> wrote:
> > Hi Dmitry.
> >
> > I checked the code in sip5 and sip6 and found the same lines as in
> > sip4, which raise the segmentation fault in sip4. So, there is a high
> > probability all sip versions have the same bug.  This is "using after
> > free" bug, so it's hard to reproduce. Normally the probability of
> > segmentation fault is very low.  I reported the bug to
> > p...@riverbankcomputing.com same time as to bugs.debian.org, but
> > nothing happens :( Maybe my mail was filtered ? So I have no idea what
> > to do next. What do you think?
>
> --
> Dmitry Shachnev

Bug#950123: Longterm fix ?

[Julien Wajsberg]

After thinking about this a bit more, I believe this is abusing te
bash_completion mechanism and the script could probably move elsewhere such
as /etc/profile.d.

Thoughts?

Bug#1006760: r-cran-commonmark: CVE-2022-24724 - integer overflow prior to 0.29.0.gfm.3 and 0.28.3.gfm.21 (cmark extension)

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/r-lib/commonmark/issues/17

Bug#1006964: ITP: python-typepy -- library for variable type checker/validator/converter at a run time

[Thomas Goirand]

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

* Package name: python-typepy
  Version : 1.3.0
  Upstream Author : Tsuyoshi Hombashi 
* URL : https://github.com/thombashi/typepy
* License : Expat
  Programming Lang: Python
  Description : library for variable type checker/validator/converter at a 
run time

 Typepy is a Python library for variable type checker/validator/converter at a
 run time.
 .
 Feature:
  * checking a value type
  * validate a value for a type
  * convert a value from a type to the other type

Note: this is a new indirect dependency for Cloudkitty.

Bug#1006963: ITP: python-mbstrdecoder -- multi-byte character string decoder

[Thomas Goirand]

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

* Package name: python-mbstrdecoder
  Version : 1.1.0
  Upstream Author : Tsuyoshi Hombashi 
* URL : https://github.com/thombashi/mbstrdecoder
* License : Expat
  Programming Lang: Python
  Description : multi-byte character string decoder

 Mbstrdecoder is a Python library for multi-byte character string decoder.

Note: This is a new indirect dependency for Cloudkitty (OpenStack rating).

Bug#993451: osslsigncode distribution does not have production-quality tests (yet)

[Michał Trojnara]

Hi Stephen,

Didn't you notice that these tests are *not* part of the osslsigncode
release tarball?  Just because some random code can be found is in the
same GitHub repository doesn't meany it's suitable for production use.

There is a very good reason why "make check" doesn't work in
osslsigncode.  It will work when the tests are ready for production
use.  Hopefully soon.  We're working on this.

Best regards,
    Mike (the upstream maintainer)

Bug#730107: adduser --system and addgroup --system should ignore remote directory services

[Harald Dunkel]

Instead of dropping this bug report with won'tfix after 8 years it would have
been appropriate to reassign it to the useradd package immediately.

Thanx very much for your help

Harri

Bug#1005699: opendht: Please switch from build-dependency libargon2-0-dev to libargon2-dev

[Gavin Henry]

Hi,

Can I help with this as I'd like to get us on to 2.3.5 when it's out
for my package:

https://mentors.debian.net/package/sentrypeer/

my v2.0.0 will depend on libopendht-dev for the C bindings

Thanks.

Bug#1006961: exabgp.env not loaded with systemd Service

[Adrian]

Package: exabgp
Version: 4.2.8-2
Severity: normal




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

Kernel: Linux 5.10.0-11-amd64 (SMP w/2 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 exabgp depends on:
ii  adduser3.118
ii  debconf1.5.77
ii  dpkg   1.20.9
ii  lsb-base   11.1.0
ii  python3-exabgp 4.2.8-2
ii  python3-pkg-resources  52.0.0-4
ii  ucf3.0043

exabgp recommends no packages.

exabgp suggests no packages.

-- no debconf information

Hi
It seems with systemd the /etc/exabgp/exabgp.env file is not loaded by deafult.

as you can see on a fresh exabgp installation it looks like:
host:~$ ps aux | grep exabg
exabgp172453  0.0  0.5  27696 21660 ?Ss   Mär03   3:02 
/usr/bin/python3 /usr/sbin/exabgp /etc/exabgp/exabgp.conf

#---#
After modifying the systemd file like:
#---#

$ cat /lib/systemd/system/exabgp.service
[Unit]
Description=ExaBGP
Documentation=man:exabgp(1)
Documentation=man:exabgp.conf(5)
Documentation=https://github.com/Exa-Networks/exabgp/wiki
After=network.target
ConditionPathExists=/etc/exabgp/exabgp.conf

[Service]
Environment=exabgp_daemon_daemonize=false
User=exabgp
Group=exabgp
RuntimeDirectory=exabgp
RuntimeDirectoryMode=0750
ExecStartPre=-/usr/bin/mkfifo /run/exabgp/exabgp.in
ExecStartPre=-/usr/bin/mkfifo /run/exabgp/exabgp.out
ExecStart=/usr/sbin/exabgp -e /etc/exabgp/exabgp.env /etc/exabgp/exabgp.conf # 
< manually added env file
ExecReload=/bin/kill -USR1 $MAINPID
Restart=always
CapabilityBoundingSet=CAP_NET_ADMIN
AmbientCapabilities=CAP_NET_ADMIN

[Install]
WantedBy=multi-user.target
#---#


And the env file is loded as expected:
09.03 13:16:28 root|ns-prx1-cbw:~$ ps aux | grep exabgp
exabgp   4120465  1.0  0.5  27444 21436 ?Ss   11:40   1:01 
/usr/bin/python3 /usr/sbin/exabgp -e /etc/exabgp/exabgp.env 
/etc/exabgp/exabgp.conf


#---#

To change the systemd file by hand should not be a solution.
If i'm not wrong with my finding, please add the environment file to the exabgp 
startup command.

Thank you very much for your work!
Best regards
A

Bug#1006962: nvidia-cuda-toolkit: nvcc chokes on g++ 11.2's bits/std_function.h

[Andreas Beckmann]

Package: nvidia-cuda-toolkit
Version: 11.4.3-2
Severity: serious
Control: block 1003037 with -1

nvcc fails to compile bits/std_function.h from g++ 11.2:

$ echo '#include ' | nvcc -ccbin g++-11 -x cu -c -
/usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not 
expanded with ‘...’:
  435 | function(_Functor&& __f)
  | 
^ 
/usr/include/c++/11/bits/std_function.h:435:145: note: ‘_ArgTypes’
/usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not 
expanded with ‘...’:
  530 | operator=(_Functor&& __f)
  | 
 ^ 
/usr/include/c++/11/bits/std_function.h:530:146: note: ‘_ArgTypes’

This is a regression from the header shipped with g++ 11.1
(11.2 includes a fix for an STL defect:
  "2774. std::function construction vs assignment")

The offending code can be reduced to

= nvcc-gcc112-failure.cu =
template < typename >
class function ;
template < typename >
class _Function_handler ;
template < typename _Res , typename ... _ArgTypes >
class function < _Res ( _ArgTypes... ) >
{
template < typename = void >
using _Handler = _Function_handler < _Res ( _ArgTypes... ) > ;
function
() noexcept ( _Handler < > :: template _S_nothrow_init < > ) ;
} ;
=

nvcc -v -x cu -c nvcc-gcc112-failure.cu yields these commands

g++-11 -D__CUDA_ARCH__=520 -E -x c++  -DCUDA_DOUBLE_MATH_FUNCTIONS -D__CUDACC__ 
-D__NVCC__   -D__CUDACC_VER_MAJOR__=11 -D__CUDACC_VER_MINOR__=4 
-D__CUDACC_VER_BUILD__=152 -D__CUDA_API_VER_MAJOR__=11 
-D__CUDA_API_VER_MINOR__=4 -include "cuda_runtime.h" -m64 
"nvcc-gcc112-failure.cu" -o 
"/tmp/tmpxft_7ddc_-7_nvcc-gcc112-failure.cpp1.ii" 
cicc --c++17 --gnu_version=110200 --orig_src_file_name "nvcc-gcc112-failure.cu" 
--allow_managed  -arch compute_52 -m64 --no-version-ident -ftz=0 -prec_div=1 
-prec_sqrt=1 -fmad=1 --include_file_name 
"tmpxft_7ddc_-3_nvcc-gcc112-failure.fatbin.c" -tused 
--gen_module_id_file --module_id_file_name 
"/tmp/tmpxft_7ddc_-4_nvcc-gcc112-failure.module_id" 
--gen_c_file_name 
"/tmp/tmpxft_7ddc_-6_nvcc-gcc112-failure.cudafe1.c" 
--stub_file_name 
"/tmp/tmpxft_7ddc_-6_nvcc-gcc112-failure.cudafe1.stub.c" 
--gen_device_file_name 
"/tmp/tmpxft_7ddc_-6_nvcc-gcc112-failure.cudafe1.gpu"  
"/tmp/tmpxft_7ddc_-7_nvcc-gcc112-failure.cpp1.ii" -o 
"/tmp/tmpxft_7ddc_-6_nvcc-gcc112-failure.ptx"
ptxas -arch=sm_52 -m64 
"/tmp/tmpxft_7ddc_-6_nvcc-gcc112-failure.ptx"  -o 
"/tmp/tmpxft_7ddc_-8_nvcc-gcc112-failure.sm_52.cubin" 
fatbinary -64 --cicc-cmdline="-ftz=0 -prec_div=1 -prec_sqrt=1 -fmad=1 " 
"--image3=kind=elf,sm=52,file=/tmp/tmpxft_7ddc_-8_nvcc-gcc112-failure.sm_52.cubin"
 
"--image3=kind=ptx,sm=52,file=/tmp/tmpxft_7ddc_-6_nvcc-gcc112-failure.ptx"
 
--embedded-fatbin="/tmp/tmpxft_7ddc_-3_nvcc-gcc112-failure.fatbin.c"
 
rm -f /tmp/tmpxft_7ddc_-3_nvcc-gcc112-failure.fatbin
g++-11 -E -x c++ -D__CUDACC__ -D__NVCC__   -D__CUDACC_VER_MAJOR__=11 
-D__CUDACC_VER_MINOR__=4 -D__CUDACC_VER_BUILD__=152 -D__CUDA_API_VER_MAJOR__=11 
-D__CUDA_API_VER_MINOR__=4 -include "cuda_runtime.h" -m64 
"nvcc-gcc112-failure.cu" -o 
"/tmp/tmpxft_7ddc_-5_nvcc-gcc112-failure.cpp4.ii" 
cudafe++ --c++17 --gnu_version=110200 --orig_src_file_name 
"nvcc-gcc112-failure.cu" --allow_managed --m64 --parse_templates 
--gen_c_file_name 
"/tmp/tmpxft_7ddc_-6_nvcc-gcc112-failure.cudafe1.cpp" 
--stub_file_name 
"tmpxft_7ddc_-6_nvcc-gcc112-failure.cudafe1.stub.c" 
--module_id_file_name 
"/tmp/tmpxft_7ddc_-4_nvcc-gcc112-failure.module_id" 
"/tmp/tmpxft_7ddc_-5_nvcc-gcc112-failure.cpp4.ii" 
g++-11 -D__CUDA_ARCH__=520 -c -x c++  -DCUDA_DOUBLE_MATH_FUNCTIONS -m64 
"/tmp/tmpxft_7ddc_-6_nvcc-gcc112-failure.cudafe1.cpp" -o 
"nvcc-gcc112-failure.o" 

the last g++-11 call is the failing one:

nvcc-gcc112-failure.cu:10:28: error: parameter packs not expanded with ‘...’:
   10 | function
  |^
 
nvcc-gcc112-failure.cu:10:28: note: ‘_ArgTypes’

Checking /tmp/tmpxft_7ddc_-6_nvcc-gcc112-failure.cudafe1.cpp
after rerunning the commands manually to preserve the temporary files,
the code has been rewritten by cudafe++ to

=
template< class > class function; 
template< class > class _Function_handler; 
template< class _Res, class ..._ArgTypes> 
class function< _Res (_ArgTypes ...)>  { 
template< class  = void> using _Handler = _Function_handler< _Res (_ArgTypes 
...)> ; 
function() 

Bug#1006960: icu: new upstream release 70.1

[Simon McVittie]

Source: icu
Version: 67.1-7
Severity: wishlist
Control: fixed -1 70.1-2
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

icu has a new upstream version in experimental, which is needed by
src:mozjs91, and indirectly by updated versions of gjs and gnome-shell.

Do you have a timescale in mind for a transition from icu 67 to 70, or
should the GNOME team be looking into using mozjs' vendored copy of icu
until a suitable system copy becomes available in unstable?

Thanks,
smcv

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Dirk Kostrewa]

Dear Sean,

first of all: many thanks to the technical committee for taking care of 
my request! This was my first request, and I am really impressed by the 
way this was discussed and handled!


Personally, I would still prefer a "rename" entry in the alternative 
system with util-linux's rename as default, since util-linux is 
installed in every Debian system. I know, the syntaxes of util-linux's 
rename and of Perl's rename are incompatible, but a user who wants to 
use Perl's rename would probably know its syntax, would have to actively 
install its package, and would then choose Perl's rename in the 
alternative system.


If an entry in the alternative system is not wanted, for me, it would 
also be fine to have access to util-linux's rename in any PATH with any 
recognizable name. I would then create a soft-link, say, 
/usr/local/bin/rename, that points to util-linux's rename.


Best regards,

Dirk.

On 08.03.22 20:58, Sean Whitton wrote:

Dear Chris, Dirk,

On Tue 08 Feb 2022 at 09:23pm +01, Helmut Grohne wrote:


We've discussed a number of possible ways to put it back (various
packages, various paths, with or without update-alternatives, with or
without Conflicts). From what you said, I understand that: [...]

Given these, we think that much of the issue can be resolved
cooperatively. To get there we (as ctte) ask you to explain how you
prefer adding the util-linux rename executable as precisely as you see
it at this stage. [...]

The ctte discussed this bug at our meeting today and determined that
there are two resolutions to this bug supported by at least one member:

(A) src:util-linux should build a binary package that ships util-linux's
 rename as "rename.ul" somewhere on PATH.

(B) src:util-linux should build a binary package that ships util-linux's
 rename, but does not install it as "rename" anywhere on PATH.
 It is not settled, at present, whether util-linux's rename should be
 provided somewhere on PATH with a name other than "rename".

Option (A) is meant to be (B) plus the additional requirement that it be
rename.ul somewhere on PATH.  Neither option says anything about whether
util-linux's rename.ul should be installed in an Essential package.

Chris, we haven't heard back from you in response to our request for
input quoted above.  We would still very much like to hear what you
think of (A) and (B) and whether you prefer some (C).  If we don't hear
back from you by the time of our next committee meeting in a month, we
will consider voting on (A) and (B).

Dirk, we would be grateful if you would comment on these two
resolutions, but we aren't going to block resolving this bug on hearing
from you.

Thanks both.


--

***
Dirk Kostrewa
Gene Center Munich
Department of Biochemistry, AG Hopfner
Ludwig-Maximilians-Universität München
Feodor-Lynen-Str. 25
D-81377 Munich
Germany
Phone:  +49-89-2180-76845
Fax:+49-89-2180-76998
E-mail:kostr...@genzentrum.lmu.de
dirk.kostr...@lmu.de
WWW:www.genzentrum.lmu.de
***

Bug#1006959: bind9-utils: missing dnssec-keymgr

[root]

Package: bind9-utils
Version: 1:9.18.0-2
Severity: normal

Dear Maintainer,

According to the bind9 documentation, a new tool has been introduced, 
dnssec-keymgr (python), which is ment to help with dnssec policy and key 
rotation.
dnssec-keymgr does not seem to be included in any of the bind9 packages.

Can this please be added.

Thanks for your attension.

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

Kernel: Linux 5.11.0-18-generic (SMP w/1 CPU thread)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bind9-utils depends on:
ii  bind9-libs  1:9.18.0-2
ii  libc6   2.33-7

bind9-utils recommends no packages.

bind9-utils suggests no packages.

-- no debconf information

Bug#1006427: New upstream version: 2.2.7

[Alexander Wirt]

Am Sat, Mar 05, 2022 at 08:13:50AM +0100 schrieb Vincent Bernat:
>  ❦  4 March 2022 10:47 +01, Alexander Wirt:
> 
> >> A new upstream version has been published. Would you mind if I take
> >> over the package? I work next to the upstream author and I am often
> >> badgered by the package being not up-to-date. :)
> 
> > I would be glad if you would take over. Unfortunately I am more or
> > less in management nowadays and less in maintaining clusters.
> 
> Thanks! Do you prefer I move the repository under the Debian namespace
> on Salsa or that I keep it under ipvs-team?
Whatever you like more. It is yours, just tell me so that I will be able to 
move the repo. 

Alex

Bug#1006958: RFP: pytype -- Pytype checks and infers types for your Python code

[Enrico Zini]

Package: wnpp
Severity: wishlist

* Package name: pytype
  Version : 2022.3.8
  Upstream Author : Google 
* URL : https://google.github.io/pytype/
* License : Apache, with some code with BSD and MIT
  Programming Lang: Python
  Description : Pytype checks and infers types for your Python code

  Pytype checks and infers types for your Python code - without
  requiring type annotations. Pytype can:
  
   * Lint plain Python code, flagging common mistakes such as misspelled
 attribute names, incorrect function calls, and much more, even
 across file boundaries.
   * Enforce user-provided type annotations. While annotations are
 optional for pytype, it will check and apply them where present.
   * Generate type annotations in standalone files ("pyi files"), which
 can be merged back into the Python source with a provided merge-pyi
 tool.
  
  Pytype is a static analyzer; it does not execute the code it runs on.

It seems like a great help in Python development. It has a different
approach than mypy, and would complement it quite nicely.

Bug#1006957: tortoisehg: update for mercurial 6.1

[Julien Cristau]

Package: tortoisehg
Version: 6.0-1
Severity: normal
X-Debbugs-Cc: jcris...@debian.org

mercurial 6.1 was released recently (and a package is in experimental as of
today), tortoisehg needs a new release to match.

Cheers,
Julien

Bug#1006948: gcc-12: FTBFS on mips64el

[YunQiang Su]

On Tue, 08 Mar 2022 20:53:46 +0100 Paul Gevers  wrote:
> Source: gcc-12
> Version: 12-20220222-1
> Severity: serious
> Tags: ftbfs
> 
> Dear Matthias, GCC maintainers,
> 
> gcc-12 fails to build from source on mips64el in unstable. Normally this 
> isn't an issue, but it builds a Build-Depends of gcc-11 which now can't 
> migrate because it can't be build on mips64el.
> 

We are try our best to find the root cause of this problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104317 


Currently: disable libphobo may be an option.

> Paul
> 
> 

Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1

[Cyril Brulebois]

Sebastian Andrzej Siewior  (2022-03-09):
> On 2022-02-19 17:57:25 [+], Adam D. Barratt wrote:
> > Feel free to upload; we'll wait for the d-i ack before accepting the
> > package into p-u.
> 
> There will be the release of 1.1.1n on Tuesday 15th March 2022 including
> a security fix. Therefore I will:
> - prepare a security release against 1.1.1k-1+deb11u1 which will be
>   released via d-security.
> - respond to this bug with a debdiff against 1.1.1m-0+deb11u1
> - upload 1.1.1n-0+deb11u1.
> 
> Please say if I should delay my upload until a request from the release
> team happens, prepare a debdiff against another release or if there is
> something else.

Just for the avoidance of doubt: I'll be dealing with whatever ends up
in the archive(s) for the d-i side, don't block on me.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#911977: how do we correctly guess the VM name in autopkgtest?

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Andrea Pappacoda (2022-02-19 15:39:12)
>  > I have in my ~/.sbuildrc:
>  >
>  > $autopkgtest_opts = [ '--', 'schroot', '%r-%a-sbuild' ];
>  >
>  > The %r and %a escapes expand to the current distribution and architecture.
> 
> Thanks, this works really well! Would it be possible for sbuild to pass 
> these options by default when the backend is schroot? This way users 
> would be able to simply specify --run-autopkgtest to run tests without root
> privileges.

I don't think that this would be easily possible. Whenever you let something
have a default you must also provide a way to change the default. This becomes
especially hairy because whichever way we implement that lets users change the
default now must also be conditionalized with schroot being the backend or not.

I think this is yet another sign of why sbuild running autopkgtest is a layer
violation. Instead of sbuild running autopkgtest, piuparts and lintian, there
should be a tool above sbuild which runs sbuild, autopkgtest, piuparts and
lintian. Sbuild doing the job is just a convenience option because we don't
have such a tool above sbuild yet but it would be the responsibility of that
tool to find out that it can drive both sbuild and autopkgtest with schroot.

I'm very hesitant about adding yet more duct tape to sbuild plus the necessary
documentation plus the users that will now wonder why sbuild behaviour changed
and they now have to somehow overwrite the default to restore the original
functionality and so on...

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1006872: RFH: apparmor -- user-space parser utility for AppArmor

[intrigeri]

Hi Andrej,

Andrej Shadura (2022-03-07):
> This reminded me I promised to work on dh-apparmor. I should find
> time for that,

Great!

> maybe also for apparmor itself.

Sounds good. Please keep me updated as you think about it :)

Bug#950123: Quick fix

[Julien Wajsberg]

Hi,
I believe the issue is that the scripts in
/usr/share/bash-completion/completions should be different than the ones
that live in /etc/bash_completion.d. The mechanisms are different.
Therefore the current script should still live in /etc/bash_completion.d.

So I quickly fixed this by adding a symbolic link and now this works as
expected.

I believe that with the "new" way, there's no need for a lazy vs not lazy
script, because the new way works by itself in a lazy fashion.

Hope this helps!
-- 
Julien

Bug#1006942: safeeyes: Safeeyes no longer seems to appears in the KDE/Plasma system tray

[Jonas Andradas]

On Tue, Mar 8, 2022 at 5:57 PM Jonas Andradas  wrote:

> Package: safeeyes
> Version: 2.1.3-1
> Severity: minor
> X-Debbugs-Cc: j.andra...@gmail.com
>
> Dear Maintainer,
>
> I noticed that fairly recently (unfortunately, cannot exactly be sure when
> or
> after which package update), safeeyes does not seem appear anymore in
> KDE/Plasma system tray. It is not shown on the system tray, neither in the
> "visible" elements nor in the "box" that has the hidden icons.
>
> Accessing the "Configure System Tray" setting, different entries appear for
> "Application Status" (Bluetooth active device, flameshot, KGpg, etc.),
> "Hardware Control" (audio volume, battery, disks, display
> configuration, etc.), "System Services" (backup status, clipboard, disk
> quota...) and "Miscellaneous" (which in my case shows kate sessions and
> weather
> report). However, safeeyes does not seem to appear there, which makes me
> think
> somehow it is not recognized by KDE/Plasma as something to be shown on the
> system tray.
>
> Before observing this behavior, I had saafeeyes on the system tray, to be
> able
> to postpone or skip the next break, quit safeeyes, etc.
>
> I am raising the bug in safeeyes as I speculate it is not announcing
> itself to
> KDE/Plasma in the way these expect it to be there. However, if the bug
> should
> be in KDE/Plasma, please feel free to move it there (if possible) or ask
> me to
> report it under the appropriate component.
>
> The versions of Plasma workspace/desktop I currently have installed are the
> following ones:
>
> plasma-workspace: 4:5.24.2-2
> plasma-desktop: 4:5.24.2-1
>
> Best Regards,
> Jonas.
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.16.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages safeeyes depends on:
> ii  gir1.2-gtk-3.03.24.31-1
> ii  python3   3.9.8-1
> ii  python3-babel 2.8.0+dfsg.1-7
> ii  python3-croniter  1.0.15-3
> ii  python3-dbus  1.2.18-3+b1
> ii  python3-gi3.42.0-3
> ii  python3-psutil5.9.0-1
> ii  python3-xlib  0.29-1
>
> Versions of packages safeeyes recommends:
> pn  gir1.2-appindicator3-0.1  
> ii  xprintidle0.2.4-2
>
> safeeyes suggests no packages.
>
> -- no debconf information
>

It seems that this bug was also opened upstream on safeeyes' github:
https://github.com/slgobinath/SafeEyes/issues/428 (which seems related to
https://github.com/slgobinath/SafeEyes/issues/268)

Best Regards,
Jonas.