Bug#1064438: gnome-settings-daemon: gsd-xsettings crash with older gsettings-desktop-schemas

[Marc Glisse]

Package: gnome-settings-daemon
Version: 46~beta-1
Severity: important

Dear Maintainer,

since the update of gnome-settings-daemon to version 46 in testing,
gsd-xsettings crashes while reporting

(gsd-xsettings:5037): GLib-GIO-ERROR **: 08:45:13.336: Settings schema 
'org.gnome.desktop.a11y.interface' does not contain a key named 
'show-status-shapes'

The backtrace doesn't say much more

(gdb) bt
#0  g_log_structured_array (log_level=, fields=0x7fffdc20, 
n_fields=4) at ../../../glib/gmessages.c:556
#1  0x7732f9e2 in g_log_default_handler
(log_domain=log_domain@entry=0x77568ecb "GLib-GIO", 
log_level=log_level@entry=6, message=message@entry=0x7fffe4004c80 "Settings 
schema 'org.gnome.desktop.a11y.interface' does not contain a key named 
'show-status-shapes'", unused_data=unused_data@entry=0x0)
at ../../../glib/gmessages.c:3284
#2  0x7732fc50 in g_logv (log_domain=0x77568ecb "GLib-GIO", 
log_level=G_LOG_LEVEL_ERROR, format=, 
args=args@entry=0x7fffdd70) at ../../../glib/gmessages.c:1392
#3  0x7732ff03 in g_log (log_domain=log_domain@entry=0x77568ecb 
"GLib-GIO", log_level=log_level@entry=G_LOG_LEVEL_ERROR, 
format=format@entry=0x77580ed8 "Settings schema '%s' does not contain a key 
named '%s'") at ../../../glib/gmessages.c:1461
#4  0x7750d5b1 in g_settings_schema_get_value (key=, 
schema=) at ../../../gio/gsettingsschema.c:1015
#5  g_settings_schema_get_value (schema=0x55611220, key=0x55561ac5 
"show-status-shapes") at ../../../gio/gsettingsschema.c:1001
#6  0x7750dc37 in g_settings_schema_key_init 
(key=key@entry=0x7fffdee0, schema=0x55611220, 
name=name@entry=0x55561ac5 "show-status-shapes") at 
../../../gio/gsettingsschema.c:1295
#7  0x77511d07 in g_settings_get_value (settings=0x556108d0 
[GSettings], key=0x55561ac5 "show-status-shapes") at 
../../../gio/gsettings.c:1224
#8  0xe379 in gsd_xsettings_manager_start (manager=0x555ebbe0 
[GsdXSettingsManager], error=error@entry=0x7fffe090) at 
../plugins/xsettings/gsd-xsettings-manager.c:1519
#9  0xb0f0 in main (argc=, argv=) at 
../plugins/common/daemon-skeleton-gtk.h:277

The mention of "schema" led me to notice that gsettings-desktop-schemas has a 
newer version in unstable, and indeed upgrading that package (and the gir and 
dev packages that come with it) from 45.0-2 to 46~beta-3 seems to have fixed 
the issue.

My suggestion would be to tighten the dependency, which currently only says (>= 
42~). Maybe in the very short term you could also ask if the migration of 
gsettings-desktop-schemas to testing can be sped up?

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'testing'), (500, 'stable'), (50, 'unstable-debug'), 
(50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common  46~beta-1
ii  gsettings-desktop-schemas 46~beta-3
ii  libasound21.2.10-3
ii  libc6 2.37-15
ii  libcairo2 1.18.0-1+b1
ii  libcanberra-gtk3-00.30-11
ii  libcanberra0  0.30-11
ii  libcolord21.4.7-1
ii  libcups2  2.4.7-1+b1
ii  libfontconfig12.14.2-6+b1
ii  libgck-1-03.41.1-4
ii  libgcr-base-3-1   3.41.1-4
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-3+b1
ii  libgeoclue-2-02.7.1-2
ii  libgeocode-glib-2-0   3.26.3-6+b1
ii  libglib2.0-0  2.78.4-1
ii  libgnome-desktop-3-20 44.0-2+b1
ii  libgtk-3-03.24.41-1
ii  libgudev-1.0-0238-3
ii  libgweather-4-0   4.4.0-1
ii  libmm-glib0   1.22.0-3
ii  libnm01.44.2-7
ii  libnotify40.8.3-1
ii  libp11-kit0   0.25.3-4
ii  libpam-systemd [logind]   255.3-2
ii  libpango-1.0-01.51.0+ds-4
ii  libpangocairo-1.0-0   1.51.0+ds-4
ii  libpolkit-gobject-1-0 124-1
ii  libpulse-mainloop-glib0   16.1+dfsg1-3
ii  libpulse0 16.1+dfsg1-3
ii  libspa-0.2-bluetooth  1.0.3-1
ii  libsystemd0   255.3-2
ii  libupower-glib3   1.90.2-8
ii  libwacom9 2.9.0-2
ii  libwayland-client01.22.0-2.1+b1
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxi6

Bug#525813: apt-file: Doesn't work very well when multiple package versions are available

[Niels Thykier]

Christoph Anton Mitterer:

Hey.

I took the liberty to forcemerge these two bugs (578727 and 525813) as
they seem to be about the same thing.

My suggestion would be that per default, the apt-file should print the
package name with =version.
Perhaps with the exception if only one version is available (or maybe
there should be an option, that causes the =version to be omitted, if
and only if, only on version is available).

When specifying the package name I think it should also allow =version
to be appended and follow the behaviour of e.g. apt-get cache, that is:
- if no version is given, match all available versions
- if one is given, match only that.


Cheers,
Chris.



Hi

One challenge we have here is that a package can have multiple versions 
in a given suite at the same time; notably in unstable. There is no 
metadata that tells apt-file which file is in which version of the 
package. So in this case, even adding a version could produce the wrong 
result. I have no plan to support versioning for selecting the suite 
because of the above problem, because it will not fix the root issue - 
only gloss over it in some cases.


For people that want better support here, please request the archive 
maintainers to provide an index with versioning so that apt-file can do 
proper filtering.


Best regards,
Niels

Bug#1064440: filename on command line gets rejected

[Zefram]

Package: guile-3.0
Version: 3.0.5-4
Severity: normal

The guile-3.0(1) command-line interface is documented to take the filename
of a script to execute.  Here's how well it understands filenames:

$ echo '(display "perplexity") (newline)' > $'foo\xf4\x90\x80\x80bar.scm'
$ LC_ALL=de_DE.iso88591 guile-3.0 --no-auto-compile 
$'foo\xf4\x90\x80\x80bar.scm' 2>&1 | cat -v
perplexity
$ LC_ALL=de_DE.utf8 guile-3.0 --no-auto-compile $'foo\xf4\x90\x80\x80bar.scm' 
2>&1 | cat -v
;;; Stat of /home/zefram/tmp/g0/fooM-tM-^PM-^@M-^@bar.scm failed:
;;; Throw to key `decoding-error' with args `("scm_to_utf8_stringn" "invalid 
codepoint in string" 84 "/home/zefram/tmp/g0/foo\U11bar.scm")'.
Backtrace:
   0 (primitive-load "/home/zefram/tmp/g0/foo\U11bar.scm")

ERROR: In procedure primitive-load:
Throw to key `decoding-error' with args `("scm_to_utf8_stringn" "invalid 
codepoint in string" 84 "/home/zefram/tmp/g0/foo\U11bar.scm")'.
$

In this example I've created a script files, I've told guile-3.0(1)
twice to run it, and on one of the two attempts it's signalled an error.
(The --no-auto-compile option doesn't affect the substantive result, I'm
just using it to avoid the noise that the caching system would otherwise
make.)  In the invocation that failed, one can see via strace(1) that
guile-3.0(1) doesn't use the filename for any file operations at all;
the error occurs at an earlier stage.  The error thus doesn't depend
on the file existing: if there is no file of that name then the same
error occurs.

This bug depends on the locale implied by the environment, and more
specifically on the character encoding nominated by the LC_CTYPE component
of the locale.  Nominating a locale that's not installed behaves the same
as nominating the C locale.  Part of my example above depends on having
the de_DE.utf8 and de_DE.iso88591 locales installed.  If you don't have
the specific locales that I used then you can get the same results as
me by substituting an installed locale that nominates the same encoding.

This bug occurs when the locale nominates the UTF-8 encoding and the
supplied filename includes what looks like UTF-8 encoding of a codepoint
outside the Unicode range.  The filename as a whole doesn't need to have
the syntax of UTF-8 encoding of text.  (A different bug, Bug#1064437,
occurs if this error is not hit and the filename does not have the syntax
of locale-nominated encoding of text.)

Preferably, guile-3.0(1) should use the script file specified on the
command line, regardless of locale.  It shouldn't be attempting to treat
the filename as encoded text.  Alternatively, if it cannot be made to
handle arbitrary filenames, then this limitation must be documented.

-zefram

Bug#1064439: fai-client - References deprecated qemu-debootstrap

[Bastian Blank]

Package: fai-client
Version: 6.0.5
Severity: normal
X-Debbugs-Cc: wa...@debian.org

qemu-debootstrap is deprecated since several Debian releases and should
not longer be used.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'proposed-updates'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 fai-client depends on:
ii  debconf-utils1.5.86
ii  file 1:5.45-2+b1
ii  iproute2 6.7.0-2
ii  libfile-lchown-perl  0.02-3+b2
ii  perl 5.38.2-3
ii  procps   2:4.0.4-4
ii  zstd 1.5.5+dfsg2-2

Versions of packages fai-client recommends:
ii  fdisk   2.39.3-6
ii  util-linux  2.39.3-6

Versions of packages fai-client suggests:
pn  libgraph-perl  
pn  logtail

-- no debconf information

Bug#433568: VLAN support within D-I

[Lucas Bonnet]

Hello dear Debian maintainers,

I can confirm that the 2020 patch from Carsten Schoenert still applies
to d-i/netcfg releases 1.187 and 1.188, and result in a debian installer
that knows about VLANs and can be fully automated with a preseed config
like the following:

d-i netcfg/enableboolean true
d-i netcfg/use_vlan  boolean true
d-i netcfg/vlan_id   string  1001
d-i netcfg/choose_interface  select  ens3f0np0


We would be interested in helping push the patch upstream so that other
users can enjoy this without having to build and make their own initrd,
how can we help?


Regards,
-- 
Lucas Bonnet
Bearstech - http://bearstech.com

Bug#1064441: fai-client - Copies qemu-mumble-static to chroot

[Bastian Blank]

Package: fai-client
Version: 6.0.5
Severity: serious
X-Debbugs-Cc: wa...@debian.org

The check-cross-arch tool copies a qemu-mumble-static binaries into the
new system, but never cleans it up.  So this leaks unmanaged binaries
into the new system.

Also using qemu-user-static without the F flag is not supported on
Debian anymore, so please ditch all this setup code and rely on the
default package setup.

Bastian


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'proposed-updates'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 fai-client depends on:
ii  debconf-utils1.5.86
ii  file 1:5.45-2+b1
ii  iproute2 6.7.0-2
ii  libfile-lchown-perl  0.02-3+b2
ii  perl 5.38.2-3
ii  procps   2:4.0.4-4
ii  zstd 1.5.5+dfsg2-2

Versions of packages fai-client recommends:
ii  fdisk   2.39.3-6
ii  util-linux  2.39.3-6

Versions of packages fai-client suggests:
pn  libgraph-perl  
pn  logtail

-- no debconf information

Bug#1052619: ITP: pydantic-core -- Rust implementation of pydantic core functionality

[Andreas Tille]

Hi Timo,

thanks for the quick update.

Am Thu, Feb 22, 2024 at 09:08:19AM +0100 schrieb Timo Röhling:
> * Andreas Tille  [2024-02-22 08:49]:
> > any progress with pydantic-core?  I've checked Salsa for the string
> > "pydantic" but did not found pydantic-core there.  It would be really
> > great to have pydantic 2.x (I stumbled upon python-semantic-release
> > which also needs it to easily fix #1056503 by upgrading to latest
> > upstream which seems to work with Python3.12)
> The pydantic-core packaging itself is pretty much done, but I still need the
> Rust crate "speedate" as dependency. For the latest upstream version of
> pydantic-core, "jitter" is needed as well.

Sounds promising. ;-)
 
> > I need to admit I have no experience in Rust packaging so I can't
> > really help here but pushing some start to Salsa could be the first
> > step.
> The Rust team has a very unusual workflow, which is not difficult to follow
> but somewhat more involved than "file ITP, upload package", which caused me
> to procrastinate. :/

:-)

Well, I hope this workflow does not prevent you from pushing to Salsa.
I personally have the habit to add some TODO items to d/changelog where
other developers hopefully look first.

Thanks a lot for working on this
   Andreas.

-- 
http://fam-tille.de

Bug#1064443: confused by changing absolute pathname

[Zefram]

Package: guile-3.0
Version: 3.0.5-4
Severity: normal

The guile-3.0(1) command-line interface is documented to take the filename
of a script to execute.  Here's how well it resolves filenames:

$ mkdir a
$ cd a
$ echo '(display "ok") (newline)' > ok.scm
$ perl -e 'chdir ".."; while(1) { rename("a", "b"); rename("b", "a"); }' &
[1] 389562
$ guile-3.0 --no-auto-compile ok.scm  
ok
$ guile-3.0 --no-auto-compile ok.scm
Backtrace:
   0 (primitive-load "/home/zefram/tmp/g0/b/ok.scm")

ERROR: In procedure primitive-load:
In procedure open-file: No such file or directory: 
"/home/zefram/tmp/g0/b/ok.scm"
$ guile-3.0 --no-auto-compile ok.scm
Backtrace:
   0 (primitive-load "/home/zefram/tmp/g0/a/ok.scm")

ERROR: In procedure primitive-load:
In procedure open-file: No such file or directory: 
"/home/zefram/tmp/g0/a/ok.scm"
$ guile-3.0 --no-auto-compile ok.scm
;;; Stat of /home/zefram/tmp/g0/b/ok.scm failed:
;;; In procedure stat: No such file or directory: "/home/zefram/tmp/g0/b/ok.scm"
ok
$ guile-3.0 --no-auto-compile ok.scm
ok

Each time that I invoked guile-3.0(1), the filename "ok.scm" given on
the command line unambiguously referred to an extant script file in the
current directory.  Some invocations successfully ran it, but others
got confused.  The confused invocations either entirely fail to run the
script, or produce some extra stderr noise and then run the script.

guile-3.0(1) is getting confused because the absolute pathname of the
current directory is changing.  It works out an absolute pathname for
the specified script, and then tries to use that at a time when it may
be stale.  The manifestation of the bug varies from run to run because
it is subject to this race condition.

I use the --no-auto-compile option in my example in order to avoid the
extra noise of guile's caching system.  If caching is allowed to occur
then similar results ensue, but there's extra stderr noise that doesn't
indicate a real problem, and the situation is semantically a bit more
complicated because of the caching.

guile-3.0(1) shouldn't need to use an absolute pathname for the script
file.  The name given on the command line should be used; relative
pathnames should work.

-zefram

Bug#1064437: filename on command line gets mangled

[Zefram]

Package: guile-3.0
Version: 3.0.5-4
Severity: normal

The guile-3.0(1) command-line interface is documented to take the filename
of a script to execute.  Here's how well it understands filenames:

$ echo '(display "sadness") (newline)' > 'L?on.scm'
$ echo '(display "joy") (newline)' > $'L\xe9on.scm'
$ LC_ALL=C guile-3.0 --no-auto-compile $'L\xe9on.scm'
sadness
$ LC_ALL=de_DE.utf8 guile-3.0 --no-auto-compile $'L\xe9on.scm'
sadness
$ LC_ALL=de_DE.iso88591 guile-3.0 --no-auto-compile $'L\xe9on.scm'
joy

In this example I've created two different script files, with different
but related names, I've told guile-3.0(1) three times to run one
of them, and it's run the wrong one on two of the three attempts.
(The --no-auto-compile option doesn't affect the substantive result,
I'm just using it to avoid the noise that the caching system would
otherwise make.)  In the invocations that ran the wrong file, one can see
via strace(1) that guile-3.0(1) doesn't use the correct filename for any
file operations at all; it completely substitutes the erroneous filename.
The use of the wrong filename doesn't depend on the file of that wrong
name existing: if there is no file of that name then guile-3.0(1) will
fail to find any script to execute, and will generate an error message
that shows the erroneous filename.

How guile-3.0(1) mangles the script filename on each invocation depends
on the locale implied by the environment, and more specifically on the
character encoding nominated by the LC_CTYPE component of the locale.
Nominating a locale that's not installed behaves the same as nominating
the C locale.  Part of my example above depends on having the de_DE.utf8
and de_DE.iso88591 locales installed.  If you don't have the specific
locales that I used then you can get the same results as me by
substituting an installed locale that nominates the same encoding.

This bug occurs in most cases where the supplied filename doesn't have
the syntax of locale-nominated encoding of text.  (A different bug occurs
in some other cases of the supplied filename not having such syntax,
report to come.)  The nature of the manglement is that each octet that
doesn't look like valid encoded text gets replaced with "?".

It appears that the supplied filename is being decoded, according
to the locale-nominated encoding, with decoding errors muffled and
"?" silently substituted in, and then the lossily-decoded filename is
re-encoded according to the locale-nominated encoding, and the result
of that process is the filename that gets actually used.  As far as I
can see the manglement comes only from character decoding: there isn't
also any Unicode normalisation.

This could cause a security problem in some circumstances that are only
slightly strange.  Suppose a privileged program is using guile-3.0(1)
to run scripts that partly derive from untrusted user input.  Suppose the
program has created an innocuous script to run, has permitted an untrusted
user to determine part of the filename for that script, and has ensured
that the supplied filename is innocuous from a Unix point of view but
isn't preventing the use of filenames with high-half octets.  Suppose
further that an untrusted user can cause the same program to create
another file, of content that the program doesn't intend to execute,
under the mangled name, which is almost as innocuous from a Unix point
of view.  Then it could execute code determined by a malicious user,
due entirely to guile-3.0(1) misinterpreting a filename.  I'm not aware
of any specific program that can be exploited in this way, and I haven't
based the declared severity of this bug report on this security issue.

Preferably, guile-3.0(1) should use the script file of the name that
was supplied on the command line.  It must pass to the file syscalls
the same octet string that was supplied as a command line argument,
without assuming anything about its syntax.

If it cannot be made to handle arbitrary filenames correctly, then
guile-3.0(1) must at least detect that it can't handle the specified
filename.  It must signal an error on any filename it can't handle, and
not use any mangled form of the filename for any purpose.  Furthermore,
this limitation must be documented.

-zefram

Bug#1052028: Bug#1052619: ITP: pydantic-core -- Rust implementation of pydantic core functionality

[Timo Röhling]

Hi Andreas,

* Andreas Tille  [2024-02-22 08:49]:

any progress with pydantic-core?  I've checked Salsa for the string
"pydantic" but did not found pydantic-core there.  It would be really
great to have pydantic 2.x (I stumbled upon python-semantic-release
which also needs it to easily fix #1056503 by upgrading to latest
upstream which seems to work with Python3.12)
The pydantic-core packaging itself is pretty much done, but I still 
need the Rust crate "speedate" as dependency. For the latest 
upstream version of pydantic-core, "jitter" is needed as well.



I need to admit I have no experience in Rust packaging so I can't
really help here but pushing some start to Salsa could be the first
step.
The Rust team has a very unusual workflow, which is not difficult to 
follow but somewhat more involved than "file ITP, upload package", 
which caused me to procrastinate. :/



Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1064349: amavisd-new: fails to install with sysvinit-core

[Brian May]

Michal Mauser  writes:

> we are trying to install new KVM virtual machines with Debian 12 and 
> here is what happens after reboot with sysvinit and apt install:
>
> Creating group 'amavis' with GID 996.
> Creating user 'amavis' (AMaViS system user) with UID 996 and GID 996.
> Starting amavisd: You are missing a dpkg-statoverride on 
> /var/run/amavis.  Fix it, otherwise you risk silent breakage on
>   upgrades.
> invoke-rc.d: initscript amavis, action "start" failed.
>
> The installation works on systemd. /var/run/amavis doesn't exist. I 
> haven't checked it on Debian 11 but we use amavis on Debian 10
> sysvinit.

The postinst script should be installing the dpkg-statoverride, but no
idea why this isn't working

Hmmm. Wonder if the problem is that the postinst script is trying to
start the daemon first before it sets the dpkg-statoverride stuff.

But if that is the case, I would have thought it would fail with systemd
also.

Just my random thoughts, I don't have time to look at this right now.
-- 
Brian May @ Debian

Bug#1064442: fai-client - Unable to disable mkramdisk

[Bastian Blank]

Package: fai-client
Version: 6.0.5
Severity: important
X-Debbugs-Cc: wa...@debian.org

It is impossible to disable the use of mkramdisk.  By default this tries
to setup a tmpfs for /var/lib/dpkg and does scary copy operations.

It expects an environment variable from the outside, which can never be
empty.

Bastian


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'proposed-updates'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 fai-client depends on:
ii  debconf-utils1.5.86
ii  file 1:5.45-2+b1
ii  iproute2 6.7.0-2
ii  libfile-lchown-perl  0.02-3+b2
ii  perl 5.38.2-3
ii  procps   2:4.0.4-4
ii  zstd 1.5.5+dfsg2-2

Versions of packages fai-client recommends:
ii  fdisk   2.39.3-6
ii  util-linux  2.39.3-6

Versions of packages fai-client suggests:
pn  libgraph-perl  
pn  logtail

-- no debconf information

Bug#1058265: Status of sqlalchemy

[Andreas Tille]

Hi,

we have quite some Python3.12 related bugs caused by sqlalchemy which
seem to be fixed in experimental (which is lagging behind upstream
2.0.27 as well as version 1.4 in unstable where upstream just released
1.4.51).

It seems the issue that leads to bug #1058265

  >   File "/usr/lib/python3/dist-packages/sqlalchemy/sql/sqltypes.py", line 
2061, in Interval
  > epoch = dt.datetime.utcfromtimestamp(0)

is not fixed in 1.4.51 so sticking to 1.4 maintenance releases will not
simply solve our Python3.12 issues if we do not fix these ourselves with
patches.  So the question remains for Thomas wo wrote in bug #1058895:

 > It'd be nice if we could have the patch in Unstable with this series 1.4.x
 > before uploading 2.x, so that I have a chance to fix all Python 3.12 bugs and
 > not mix SQLA 2.x and Py 3.12 problems.

Do yuo really want to fix 1.4.x (maybe x=51) first or do we want to
switch to 2.0.27 and fix remaining problems with this latest version?  I
have no resources to run all the tests but I stumbled upon this question
when trying to do some general Python3.12 bug hunting.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1064444: filename on command line gets mangled

[Zefram]

Package: guile-2.2
Version: 2.2.7+1-6
Severity: normal

The guile-2.2(1) command-line interface is documented to take the filename
of a script to execute.  Here's how well it understands filenames:

$ echo '(display "sadness") (newline)' > 'L?on.scm'
$ echo '(display "joy") (newline)' > $'L\xe9on.scm'
$ LC_ALL=C guile-2.2 --no-auto-compile $'L\xe9on.scm'
sadness
$ LC_ALL=de_DE.utf8 guile-2.2 --no-auto-compile $'L\xe9on.scm'
sadness
$ LC_ALL=de_DE.iso88591 guile-2.2 --no-auto-compile $'L\xe9on.scm'
joy

In this example I've created two different script files, with different
but related names, I've told guile-2.2(1) three times to run one
of them, and it's run the wrong one on two of the three attempts.
(The --no-auto-compile option doesn't affect the substantive result,
I'm just using it to avoid the noise that the caching system would
otherwise make.)  In the invocations that ran the wrong file, one can see
via strace(1) that guile-2.2(1) doesn't use the correct filename for any
file operations at all; it completely substitutes the erroneous filename.
The use of the wrong filename doesn't depend on the file of that wrong
name existing: if there is no file of that name then guile-2.2(1) will
fail to find any script to execute, and will generate an error message
that shows the erroneous filename.

How guile-2.2(1) mangles the script filename on each invocation depends
on the locale implied by the environment, and more specifically on the
character encoding nominated by the LC_CTYPE component of the locale.
Nominating a locale that's not installed behaves the same as nominating
the C locale.  Part of my example above depends on having the de_DE.utf8
and de_DE.iso88591 locales installed.  If you don't have the specific
locales that I used then you can get the same results as me by
substituting an installed locale that nominates the same encoding.

This bug occurs in most cases where the supplied filename doesn't have
the syntax of locale-nominated encoding of text.  (A different bug occurs
in some other cases of the supplied filename not having such syntax,
report to come.)  The nature of the manglement is that each octet that
doesn't look like valid encoded text gets replaced with "?".

It appears that the supplied filename is being decoded, according
to the locale-nominated encoding, with decoding errors muffled and
"?" silently substituted in, and then the lossily-decoded filename is
re-encoded according to the locale-nominated encoding, and the result
of that process is the filename that gets actually used.  As far as I
can see the manglement comes only from character decoding: there isn't
also any Unicode normalisation.

This could cause a security problem in some circumstances that are only
slightly strange.  Suppose a privileged program is using guile-2.2(1)
to run scripts that partly derive from untrusted user input.  Suppose the
program has created an innocuous script to run, has permitted an untrusted
user to determine part of the filename for that script, and has ensured
that the supplied filename is innocuous from a Unix point of view but
isn't preventing the use of filenames with high-half octets.  Suppose
further that an untrusted user can cause the same program to create
another file, of content that the program doesn't intend to execute,
under the mangled name, which is almost as innocuous from a Unix point
of view.  Then it could execute code determined by a malicious user,
due entirely to guile-2.2(1) misinterpreting a filename.  I'm not aware
of any specific program that can be exploited in this way, and I haven't
based the declared severity of this bug report on this security issue.

Preferably, guile-2.2(1) should use the script file of the name that
was supplied on the command line.  It must pass to the file syscalls
the same octet string that was supplied as a command line argument,
without assuming anything about its syntax.

If it cannot be made to handle arbitrary filenames correctly, then
guile-2.2(1) must at least detect that it can't handle the specified
filename.  It must signal an error on any filename it can't handle, and
not use any mangled form of the filename for any purpose.  Furthermore,
this limitation must be documented.

-zefram

Bug#1064445: filename on command line gets rejected

[Zefram]

Package: guile-2.2
Version: 2.2.7+1-6
Severity: normal

The guile-2.2(1) command-line interface is documented to take the filename
of a script to execute.  Here's how well it understands filenames:

$ echo '(display "perplexity") (newline)' > $'foo\xf4\x90\x80\x80bar.scm'
$ LC_ALL=de_DE.iso88591 guile-2.2 --no-auto-compile 
$'foo\xf4\x90\x80\x80bar.scm' 2>&1 | cat -v
perplexity
$ LC_ALL=de_DE.utf8 guile-2.2 --no-auto-compile $'foo\xf4\x90\x80\x80bar.scm' 
2>&1 | cat -v
;;; Stat of /home/zefram/tmp/g0/fooM-tM-^PM-^@M-^@bar.scm failed:
;;; Throw to key `decoding-error' with args `("scm_to_utf8_stringn" "invalid 
codepoint in string" 84 "/home/zefram/tmp/g0/foo\U11bar.scm")'.
Backtrace:
   0 (primitive-load "/home/zefram/tmp/g0/foo\U11bar.scm")

ERROR: In procedure primitive-load:
Throw to key `decoding-error' with args `("scm_to_utf8_stringn" "invalid 
codepoint in string" 84 "/home/zefram/tmp/g0/foo\U11bar.scm")'.
$

In this example I've created a script files, I've told guile-2.2(1)
twice to run it, and on one of the two attempts it's signalled an error.
(The --no-auto-compile option doesn't affect the substantive result, I'm
just using it to avoid the noise that the caching system would otherwise
make.)  In the invocation that failed, one can see via strace(1) that
guile-2.2(1) doesn't use the filename for any file operations at all;
the error occurs at an earlier stage.  The error thus doesn't depend
on the file existing: if there is no file of that name then the same
error occurs.

This bug depends on the locale implied by the environment, and more
specifically on the character encoding nominated by the LC_CTYPE component
of the locale.  Nominating a locale that's not installed behaves the same
as nominating the C locale.  Part of my example above depends on having
the de_DE.utf8 and de_DE.iso88591 locales installed.  If you don't have
the specific locales that I used then you can get the same results as
me by substituting an installed locale that nominates the same encoding.

This bug occurs when the locale nominates the UTF-8 encoding and the
supplied filename includes what looks like UTF-8 encoding of a codepoint
outside the Unicode range.  The filename as a whole doesn't need to have
the syntax of UTF-8 encoding of text.  (A different bug, Bug#106,
occurs if this error is not hit and the filename does not have the syntax
of locale-nominated encoding of text.)

Preferably, guile-2.2(1) should use the script file specified on the
command line, regardless of locale.  It shouldn't be attempting to treat
the filename as encoded text.  Alternatively, if it cannot be made to
handle arbitrary filenames, then this limitation must be documented.

-zefram

Bug#1064446: confused by changing absolute pathname

[Zefram]

Package: guile-2.2
Version: 2.2.7+1-6
Severity: normal

The guile-2.2(1) command-line interface is documented to take the filename
of a script to execute.  Here's how well it resolves filenames:

$ mkdir a
$ cd a
$ echo '(display "ok") (newline)' > ok.scm
$ perl -e 'chdir ".."; while(1) { rename("a", "b"); rename("b", "a"); }' &
[1] 390457
$ guile-2.2 --no-auto-compile ok.scm
ok
$ guile-2.2 --no-auto-compile ok.scm
Backtrace:
   0 (primitive-load "/home/zefram/tmp/g0/b/ok.scm")

ERROR: In procedure primitive-load:
In procedure open-file: No such file or directory: 
"/home/zefram/tmp/g0/b/ok.scm"
$ guile-2.2 --no-auto-compile ok.scm
Backtrace:
   0 (primitive-load "/home/zefram/tmp/g0/a/ok.scm")

ERROR: In procedure primitive-load:
In procedure open-file: No such file or directory: 
"/home/zefram/tmp/g0/a/ok.scm"
$ guile-2.2 --no-auto-compile ok.scm
;;; Stat of /home/zefram/tmp/g0/b/ok.scm failed:
;;; In procedure stat: No such file or directory: "/home/zefram/tmp/g0/b/ok.scm"
ok
$ guile-2.2 --no-auto-compile ok.scm
ok

Each time that I invoked guile-2.2(1), the filename "ok.scm" given on
the command line unambiguously referred to an extant script file in the
current directory.  Some invocations successfully ran it, but others
got confused.  The confused invocations either entirely fail to run the
script, or produce some extra stderr noise and then run the script.

guile-2.2(1) is getting confused because the absolute pathname of the
current directory is changing.  It works out an absolute pathname for
the specified script, and then tries to use that at a time when it may
be stale.  The manifestation of the bug varies from run to run because
it is subject to this race condition.

I use the --no-auto-compile option in my example in order to avoid the
extra noise of guile's caching system.  If caching is allowed to occur
then similar results ensue, but there's extra stderr noise that doesn't
indicate a real problem, and the situation is semantically a bit more
complicated because of the caching.

guile-2.2(1) shouldn't need to use an absolute pathname for the script
file.  The name given on the command line should be used; relative
pathnames should work.

-zefram

Bug#1064449: open-infrastructure-system-build: ineffective diversions due to /usr-move (DEP17)

[Helmut Grohne]

Package: open-infrastructure-system-build
Version: 20190301-lts1-3
User: helm...@debian.org
Usertags: dep17m3
Tags: patch trixie sid
Control: affects -1 + dpkg hostname

Some of the scripts contained in open-infrastructure-systemd-build
divert /sbin/start-stop-daemon and /bin/hostname. These files have been
moved to /usr in unstable to remove aliasing effects arising from the
/usr-merge transition. As a result, these diversions have become
ineffective. I'm attaching a patch that duplicates them to temporarily
cover both locations until we can remove the diversions for aliased
locations post trixie.

Helmut
--- open-infrastructure-system-tools-20190301-lts1.orig/system-build/scripts/build/chroot_dpkg
+++ open-infrastructure-system-tools-20190301-lts1/system-build/scripts/build/chroot_dpkg
@@ -41,9 +41,15 @@ case "${1}" in
 		Create_lockfile .lock
 
 		# Create custom start-stop-daemon program
-		Chroot chroot dpkg-divert --rename --quiet --add /sbin/start-stop-daemon
+		Chroot chroot dpkg-divert --rename --quiet --add /usr/sbin/start-stop-daemon
+		# begin-remove-after: released:trixie
+		# In the bookworm to trixie upgrade, dpkg moves
+		# start-stop-daemon from /sbin to /usr/sbin. Duplicate the
+		# diversion to cover both. DEP17 P3 M18
+		Chroot chroot dpkg-divert --rename --quiet --add --divert /sbin/start-stop-daemon.distrib.usr-is-merged
+		# end-remove-after
 
-cat > chroot/sbin/start-stop-daemon << EOF
+cat > chroot/usr/sbin/start-stop-daemon << EOF
 #!/bin/sh
 
 exit 0
@@ -89,8 +95,11 @@ EOF
 		Chroot chroot dpkg-divert --rename --quiet --remove /usr/sbin/flash-kernel
 
 		# Remove custom start-stop-daemon program
-		rm -f chroot/sbin/start-stop-daemon
+		rm -f chroot/usr/sbin/start-stop-daemon
+		# begin-remove-after: released:trixie
 		Chroot chroot dpkg-divert --rename --quiet --remove /sbin/start-stop-daemon
+		# end-remove-after
+		Chroot chroot dpkg-divert --rename --quiet --remove /usr/sbin/start-stop-daemon
 
 		# Remove dpkg sync configuration
 		rm -f chroot/etc/dpkg/dpkg.cfg.d/live-build
--- open-infrastructure-system-tools-20190301-lts1.orig/system-build/scripts/build/chroot_hostname
+++ open-infrastructure-system-tools-20190301-lts1/system-build/scripts/build/chroot_hostname
@@ -46,15 +46,21 @@ case "${1}" in
 		# Create custom hostname
 		Echo_message "Configuring file /bin/hostname"
 
-		Chroot chroot dpkg-divert --rename --quiet --add /bin/hostname
+		Chroot chroot dpkg-divert --rename --quiet --add /usr/bin/hostname
+		# begin-remove-after: released:trixie
+		# In the bookworm to trixie upgrade, hostname moves hostname
+		# from /bin to /usr/bin. Duplicate the diversion to cover both.
+		# DEP17 P3 M18
+		Chroot chroot dpkg-divert --rename --quiet --add --divert /bin/hostname.distrib.usr-is-merged /bin/hostname
+		# end-remove-after
 
-cat > chroot/bin/hostname << EOF
+cat > chroot/usr/bin/hostname << EOF
 #!/bin/sh
 
 echo "localhost.localdomain"
 EOF
 
-		chmod 755 chroot/bin/hostname
+		chmod 755 chroot/usr/bin/hostname
 
 		# Creating stage file
 		Create_stagefile .build/chroot_hostname
@@ -79,7 +85,10 @@ EOF
 
 		# Remove custom hostname
 		rm -f chroot/bin/hostname
+		# begin-remove-after: released:trixie
 		Chroot chroot dpkg-divert --rename --quiet --remove /bin/hostname
+		# end-remove-after
+		Chroot chroot dpkg-divert --rename --quiet --remove /usr/bin/hostname
 
 		# Removing stage file
 		rm -f .build/chroot_hostname

Bug#1064450: clonezilla: ineffective diversions due to /usr-move (DEP17)

[Helmut Grohne]

Package: clonezilla
Version: 5.5.23-2
Tags: patch
User: helm...@debian.org
Usertags: dep17p3
Control: affects -1 + dpkg hostname
Control: block -1 by 1064408

clonezilla has an integration script for working with live-build.
live-build employs diversions of /sbin/start-stop-daemon and
/bin/hostname. Those files have been moved to /usr in unstable and
therefore these diversions have become ineffective. I've file a bug for
live-build to duplicate these diversions. Once it does clonezilla will
need an update for the changed live-build as well. I'm attaching a patch
with the necessary adaptions for your convenience. Due to the employed
detection mechanism, it should also work with older versions of
live-build, so the block marking kinda is a lie, but it establishes the
relation of these bugs.

Helmut
--- clonezilla-5.5.23.orig/setup/files/ocs/live-hook/ocs-live-hook-functions
+++ clonezilla-5.5.23/setup/files/ocs/live-hook/ocs-live-hook-functions
@@ -288,21 +288,41 @@ remove_start_stop_daemon_diverts(){
   # root@debian:/sbin# ls -alFh start-stop-da*
   # -rwxr-xr-x 1 root root 27K Mar 18 06:16 start-stop-daemon.distrib*
   lb_3_start_stop_daemon_revert_flag="false"
-  if [ -e /sbin/start-stop-daemon.distrib ]; then
+  if [ -e /usr/sbin/start-stop-daemon.distrib ]; then
 # Remove the existing text exec script file, otherwise dpkg-divert won't revert.
 # Then dpkg-divert will rename /sbin/start-stop-daemon.distrib as /sbin/start-stop-daemon
 # //NOTE// For live-build v3.x, after drblpush, we have to revert the status to fake, temp one, so the rest of chroot_dpkg command won't remove the real /sbin/start-stop-daemon.
+rm -f /usr/sbin/start-stop-daemon
+dpkg-divert --rename --remove /usr/sbin/start-stop-daemon
+lb_3_start_stop_daemon_revert_flag="true"
+  fi
+  # begin-remove-after: released:trixie
+  # The diversion may be duplicated by live-build due to the target having been
+  # moved to /usr/sbin. See DEP17 P3 M18.
+  lb_3_start_stop_daemon_revert_aliased_flag="false"
+  if [ -e /sbin/start-stop-daemon.distrib.usr-is-merged ]; then
 rm -f /sbin/start-stop-daemon
 dpkg-divert --rename --remove /sbin/start-stop-daemon
-lb_3_start_stop_daemon_revert_flag="true"
+lb_3_start_stop_daemon_revert_aliased_flag="true"
   fi
+  # end-remove-after
 }
 #
 set_start_stop_daemon_diverts(){
   # For live-build v3.x, after drblpush, we have to revert the status to fake, temp one, so the rest of chroot_dpkg command won't remove the real /sbin/start-stop-daemon.
   # Ref: /usr/lib/live/build/chroot_dpkg
   if [ "$lb_3_start_stop_daemon_revert_flag" = "true" ]; then
-dpkg-divert --rename --add /sbin/start-stop-daemon
+dpkg-divert --rename --add /usr/sbin/start-stop-daemon
+cat > /usr/sbin/start-stop-daemon << EOF
+#!/bin/sh
+
+exit 0
+EOF
+chmod 755 /usr/sbin/start-stop-daemon
+  fi
+  # begin-remove-after: released:trixie
+  if [ "$lb_3_start_stop_daemon_revert_aliased_flag" = "true" ]; then
+dpkg-divert --rename --add --divert /sbin/start-stop-daemon.distrib.usr-is-merged /sbin/start-stop-daemon
 cat > /sbin/start-stop-daemon << EOF
 #!/bin/sh
 
@@ -310,6 +330,7 @@ exit 0
 EOF
 chmod 755 /sbin/start-stop-daemon
   fi
+  # end-remove-after
 }
 #
 remove_service_in_system() {

Bug#1064448: ocrad FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: ocrad
Version: 0.28-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ocrad fails to cross build from source, because it uses the build
architecture compiler. debian/rules has an override_dh_auto_configure
that invokes the upstream configure without any indiciation of which
architecture we are building for. Passing CXX fixes that. I'm attaching
a patch for your convenience.

Helmut
diff --minimal -Nru ocrad-0.28/debian/changelog ocrad-0.28/debian/changelog
--- ocrad-0.28/debian/changelog 2022-08-23 15:55:51.0 +0200
+++ ocrad-0.28/debian/changelog 2024-02-22 09:38:50.0 +0100
@@ -1,3 +1,10 @@
+ocrad (0.28-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass CXX to configure. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 22 Feb 2024 09:38:50 +0100
+
 ocrad (0.28-3) unstable; urgency=medium
 
   * New maintainer (Closes: #974154). Thanks Gürkan Myczko for your work!
diff --minimal -Nru ocrad-0.28/debian/rules ocrad-0.28/debian/rules
--- ocrad-0.28/debian/rules 2022-08-23 15:55:51.0 +0200
+++ ocrad-0.28/debian/rules 2024-02-22 09:38:45.0 +0100
@@ -3,11 +3,13 @@
 export DEB_CPPFLAGS_MAINT_APPEND = -fPIC
 export DEB_CXXFLAGS_MAINT_APPEND = -fPIC
 
+-include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- $(shell dpkg-buildflags --export=cmdline)
+   dh_auto_configure -- CXX='$(CXX)' $(shell dpkg-buildflags 
--export=cmdline)
 
 override_dh_auto_build:
dh_auto_build -- all ocradcheck

Bug#901631: Bug#901507: lintian: warn if dh-* sequence is in B-D-Arch or B-D-Indep but not Build-Depends

[Simon McVittie]

On Wed, 21 Feb 2024 at 21:55:08 +0100, Niels Thykier wrote:
> On Mon, 18 Jun 2018 12:16:55 +0100 Simon McVittie  wrote:
> > I hadn't intended that you'd add this mechanism for packages that
> > ship debhelper addons alongside other content, just the ones that have
> > little or no purpose other than their debhelper addons, like most/all
> > of the dh-$addon family, and maybe some of the pkg-$team-tools family.
> 
> Some dh add-ons can be in ``Build-Depends-Indep`` now and is used to support
> cross-building in some cases. I do not remember when the feature was added
> though, so it might not have been possible at the time this was filed.

If I remember correctly, the reason I opened the bug is that while
doing unrelated bug-fixing I was seeing a significant number of source
packages that failed to `debian/rules clean` if you install only the
Build-Depends. The typical scenario was that a source package that only
builds Architecture: all binaries would have debhelper or a sequence addon
that runs during clean (like gnome-pkg-tools) in its Build-Depends-Indep.
At the time I opened this bug, I think the only way to activate a sequence
addon was like `dh $@ --with gnome`, which is difficult to set up to
happen conditionally for some but not all builds.

I think the whole dh-sequence-foo mechanism was added since then, and
is a big improvement. Yes, if an addon is activated via dh-sequence-foo
(for example "Build-Depends(|-Arch|-Indep): dh-sequence-gnome"), then it
can be in Build-Depends-Indep, and it will just not be activated during
-B builds. For some addons this is normal, and for some addons this will
mean it doesn't work as intended - it depends what the addon does. But,
either way, that isn't going to break the ability to `debian/rules clean`
without the addon. So I think it would make sense for the the
dh-sequence-foo names to be excluded from any check that is intended to be
a solution for this bug.

smcv

Bug#1064451: the problem with sending an error message via the reportbug package

[Николай Сабельников]

thanks for the information. but why is there no such information in the Debian 
wiki? I think it's worth writing it in the wiki.

22 февраля 2024 г. 19:34:52 GMT+03:00, Sandro Tosi  
пишет:
>please read the doc and configure programs according to your needs:
>https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/conf/reportbug.conf?ref_type=heads#L64-72
>
>On Thu, Feb 22, 2024 at 6:03 AM Nikolay Sabelnikov
><79625490...@yandex.ru> wrote:
>>
>> Package: reportbug
>> Version: 12.0.0
>>
>> hello. There is a problem with sending error information via reportbug. I 
>> use Yandex mail. And I have two-factor protection set up there. And when 
>> setting up, you need to add the ability to add a username and password that 
>> I can generate in my mail account.
>>
>>
>
>

Bug#1064451:

[Николай Сабельников]

done

Bug#1063635: mirror listing update for mirror.limda.net

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sat, 2024-02-10 at 08:09 +, Limda Host wrote:
> Submission-Type: update
> Site: mirror.limda.net
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Limda Host 
> Country: BD Bangladesh
> Location: Dhaka
> Sponsor: Limda Host https://www.limda.net

Please could you clarify what has changed relative to your current
listing?

Regards,

Adam

Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed

[Simon McVittie]

On Wed, 14 Feb 2024 at 16:47:23 +, Gayathri Berli wrote:
> In the current issue of gtk4 When I tried to reproduce
> the issue on s390x there are 1507 tests that are failing. Can you please
> suggest that version of dependency packages being used/issue reproduce steps/
> logs.

I'm sorry, I don't understand the question. You say you can reproduce 1507
test failures: if that's the case, why do you need steps-to-reproduce?
It seems like you can already reproduce a problem that needs solving?

smcv

Bug#1064428: [Britney] does not migrate new arch:all packages after initial migration of same source

[Dalton Durst]

Hi Paul,

Thanks very much for your reply.

For what it's worth, I don't necessarily need britney2 to handle these
migrations "correctly", and I don't think Debian does either. However,
there is some behavior instability when arch-indep and arch-dep packages
are proposed in different ways in the same source. It would be okay if
britney2 simply threw the migration out with the message "this is too
complicated, some human should tell the archive what to do." Instead, it
either passes the arch-indep package through as a rider on another
change or seems to ignore the package entirely.

On Wed, Feb 21, 2024, at 11:59 PM, Paul Gevers wrote:
> On 21-02-2024 23:50, Dalton Durst wrote:
>
> > If the
> > package were binNMU'd, though, britney would migrate everything
> > including the arch:all package if it passed checks.
>
> In Debian, binNMU-ing a arch:all package is known to not work. I don't
> know if this bug is the reason why it doesn't work, but I've been taught
> this when I joined the Release Team. I think I tried once by accident
> (or ignorance) and the binNMU didn't work.

Sorry, I might not have been as clear as possible here. The problem is
that the arch:all packages won't migrate unless there's another valid
migration item in the source. So an arch:all package could be stuck in
unstable for a while without moving. As soon as a valid binNMU appears
(without replacing the arch:all package, as is policy), the arch:all
package might migrate too.

> > This behavior
> > instability might be undesirable.
>
> But there _might_ be more infrastructure problems than britney2.

Agreed. In fact, I found even spookier behavior in britney2 while adding
more tests.

To explain: when this odd situation occurs, the arch:all package seems
to be checked for validity, at least a little. If it is installable, it
migrates with the binNMU. If it is not installable, it does not migrate
with the binNMU. This seems like a good thing, britney2 is somehow
avoiding a non-installable package in testing. However, in all cases,
the excuses output does not accurately reflect the decisions that were
made during britney's run.

Depending on how the downstream software actually performs migration,
you could still get different results from the same britney run. When
the arch:all package is "accepted" (scare quotes because britney2 says
the package is ignored in excuses), it appears in HeidiResult but not
HeidiResultDelta.

This is a little hard to explain, so I've attached another three tests
which demonstrate the situation. "arch-all-migrates-with-broken"
demonstrates what happens when the arch:all package itself is not
installable, but the binNMU is. "arch-all-migrates-with-others" shows
an OK arch:all and arch:any migration (with the :all package appearing
in HeidiResult but not the delta). "arch-all-migrates-without-others"
shows what happens "at rest," when all arch-dep binaries for the source
are already in testing. "...without-others" should be a repeat of the
test attached in my first message, but they can all be run with
"bin/runtests ../britney2/britney.py t test-out /arch-all-migrates.*/"
which is nice.

>
> > The code which skips arch:all packages dates all the way back to
> > britney2's original import[1], so it's not clear if it's still
> > load-bearing.
>
> In the old days, an arch:all package was never build on a buildd, but
> uploaded by the uploader (together with the source). It's very possible
> that that fact is related to the original intent.

Makes sense.

> I am currently working an a change to britney2 that (based on
> Package-List entries in the Sources) will prevent migration of sources
> which build arch:all binaries. That will also work around bug #915948
> (in dak) and fix bug #887060 (in britney2 for Sources build from
> source.changes files). From our conversation on IRC I take it that that
> wouldn't solve *your* case as you're using aptly and apparently that
> builds the Sources (with or without a Package-List) from what's in the
> archive so it would still run into this issue.

That sounds like a really good addition. I suppose it would mark a
change in my situation because the unstable source package's
Package-List would be different from the testing package. Maybe that
change would be enough to get some output from britney2 when this odd
situation is hit?

Thanks again,
Dalton

0001-WIP-Add-tests-for-new-arch-all-binaries.patch
Description: Binary data

Bug#1001802: Update on bug 1001802

[陈 晟祺]

control: forwarded -1 https://github.com/openzfs/openzfs-docs/issues/237
control: notfound -1 2.0.3-9

> - while the script indeed waits for user input, snapshots list and 
prompt are not displayed to the user

Please disable "quiet" in your kernel cmdline, or you won't get stderr from 
initramfs.

> - the script does not check that the value given by the user is valid

Yes. You can submit an PR to openzfs/zfs, it is located at 
contrib/initramfs-tools.

Thanks,
Shengqi Chen

Bug#1064466: RFP: xsqlite -- forensic analysis of SQLite database files

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: vil...@debian.org

* Package name: xsqlite
  Version : 2.0.6
  Upstream Contact: Netherlands Forensic Institute
* URL : https://github.com/NetherlandsForensicInstitute/xsqlite
* License : Expat
  Programming Lang: Python
  Description : forensic analysis of SQLite database files

 Xsqlite is a Python 3 package that can be used for forensic analysis of
 SQLite database files. It's main purpose is to recover deleted records,
 but it can also be used to analyse the low-level file structure for
 forensic purposes. The package includes a simple command-line tool for
 basic record recovery, but for more advanced usage it can be used as
 Python module or in the interactive Python shell.

Bug#1060214: mirror listing update for repository.su

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2024-01-07 at 17:42 +, repository.su wrote:
> Submission-Type: update
> Site: repository.su
[...]
> Comment: This address is a replacement for the existing mirror
> mirror.surf

The tracefile still contains:

Running on host: mirror.surf

Please fix that and let us know when done. (Likely be changing the
MIRRORNAME variable in your ftpsync config.)

Regards,

Adam

Bug#1064419: bookworm-pu: package node-neo-async/2.6.2+~cs3.0.0-2

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Feb 22, 2024 at 02:02:29AM +0530, Praveen Arimbrathodiyil wrote:
> [ Reason ]
> #1064411 some files that are present in npm dist tarball was missing in the
> binary package (it was built but not included in the binary) shipped in
> debian. We noticed this only now since we are trying to integrate
> yarn-plugin-apt (which will use apt installed node modules when available)
> with gitlab in bookworm-fasttrack (fasttrack.debian.net) only now and which
> expects these missing files to be present.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1064468: Settings schema 'org.gnome.desktop.a11y.interface' does not contain a key named 'show-status-shapes'

[Simon McVittie]

Control: forcemerge 1064438 -1

On Thu, 22 Feb 2024 at 12:25:53 -0500, David Mandelberg wrote:
> Upgrading gsettings-desktop-schemas from 45.0-2 to 46~beta-3 seems to have
> fixed the problem. So I think gnome-settings-daemon's dependency on
> gsettings-desktop-schemas (>= 42~) should be updated to require a newer
> version?

Yes, it's already marked as release-critical and pending upload.

smcv

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

[Richard Lewis]

On Thu, 22 Feb 2024, 10:15 Ralf Schlatterbeck,  wrote:

> On Wed, Feb 21, 2024 at 02:52:33PM +0100, Ralf Schlatterbeck wrote:
> >
> > I forgot to mention:
> > There is an upstream (rsyslog) bug-report at
> > https://github.com/rsyslog/rsyslog/issues/5332
>
> Upstream has decided that it is not a bug and that both timestamp
> formats are valid RFC 3339 (I've checked, the grammar explicitly defines
> the sub-seconds part of the timestamp as optional). See link above.
> They also think, logcheck should cope with both formats.
>
> So I guess that logcheck should be prepared to receive both kinds of
> timestamps, the 32-byte version and the 25-byte version (without the
> subseconds timestamp).
>

what is the default, and does logcheck cope with that? there's a limit to
how much to suport out of the box - especially as rsyslog is no longer the
default.

if you configure a logger to produce a certain format it's not unreasonable
to also have to edit logcheck rules accordingly

But a longer-term solution is perhaps to allow easier customisation of
rules via "macros"/variables --- a proof-of-concept for this is in
progress, but not.yet ready for testing

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

[Julian Andres Klode]

On Sun, Feb 04, 2024 at 09:20:09PM +0100, Helmut Grohne wrote:
> Hi Aurelien and Sven,
> 
> On Wed, Jan 24, 2024 at 09:19:12PM +0100, Aurelien Jarno wrote:
> > On 2024-01-23 17:40, Helmut Grohne wrote:
> > > Conflicting runtime dynamic linkers between multiarch packages
> > > ==
> > > 
> > > Some architecture combinations such as s390, powerpc, hppa, m68k,
> > > mipsn32, and hurd-i386 or alpha, i386, sh4, and sparc have conflicting
> > > runtime dynamic loaders. In theory this violates Multi-Arch: same, but
> > > there is basically nothing we can do about this and dropping Multi-Arch:
> > > same from the packages would completely break any kind of multiarch
> > > setup. There is little we can do here and this is also unrelated to
> > > DEP17.
> > 
> > We tried to add conflicts for those, like it's done for the multilib
> > packages, but at the time the infrastructure exploded (see #745552). I
> > don't remember the details, but I guess it was either dak or
> > dose-builddebcheck.
> 
> Yeah, I also remember something like that. It's not the first time I
> trip into this. "There is little we can do here" still counts.
> 
> > I guess the symlink in the maintainer script could indeed work. I am not
> > sure why it has been done like that, it was part of the multiarch
> > patchset from Steve Langasek more than 10 years ago.
> 
> Practically speaking, it appears to work rather well. On the flip side,
> I also thought that way of my first patch. ;)
> 
> > Note however that the those packages are used by cross-toolchain-base
> > (which builds them from glibc-source) and mangled to install them in the
> > cross path. See for instance libc6-amd64-x32-cross. For such cases, we
> > probably do want to keep the dynamic linker symlink, as those packages
> > do not have maintainer scripts.
> 
> I don't think those -$arch-cross packages need the runtime dynamic
> linker at all. Unlike the libc6-$multilib packages, we don't use
> -$arch-cross packages to actaully run any binary. Simply not installing
> it might just work in practice.
> 
> So here is an updated patch with a few notes:
>  * This patch moves all the files including the runtime dynamic linker
>in the main multiarch library. Therefore, this patch needs to be
>synced with the corresponding base-files change to add the aliasing
>symlinks or debootstrap breaks. In other words: Don't upload this
>yet.
>  * As mentioned earlier, only the multiarch packages install the runtime
>dynamic linker via data.tar. All the multilib packages install it via
>maintainer scripts now.
>  * When installing libc6-x32, /libx32 will be created because partial
>upgrades might otherwise be broken. Removing libc6-x32 will not
>remove /libx32 though. I suggest fixing this in base-files by
>installing a trigger interest in /usr/libx32 and having
>base-files.postinst create/remove /libx32 as needed. This way, we
>centralize the management of aliasing links into base-files. libx32
>only serves as an example here and it works the same way for any
>other non-essential multilib directory. Do you agree with the
>approach?
>  * The multilib packages install a trigger interest on the runtime
>dynamic linker such that they notice when a multiarch package deletes
>it and can then recreate it as needed. Thus the multiarch packages do
>not have to pay attention to a possibly installed multilib package
>when they are removed.
>  * I've tried quite a few multiarch upgrades involving amd64 and i386
>using dpkg --auto-deconfigure --unpack with various packages and even
>cross grading libc6-x32 from :i386 to :amd64 during the upgrade.
>While dpkg --verify was occasionally unhappy during a partial upgrade
>(where half-unpacked packages were around), once no package was
>half-installed, dpkg --verify was also happy again in all attempts. I
>did not come up with a systematic enumeration of possible upgrade
>scenarios though.
>  * The patch works will deboostrap/cdebootstrap/mmdebstrap (in
>combination with more patches including base-files, bash, dash and
>util-linux).
>  * The change to install ldconfig to /usr/sbin can be uploaded right
>away. It's limited to debian/debhelper.in/libc-bin.install and
>debian/debhelper.in/libc-bin.lintian-overrides and doesn't contribute
>much diff, so doing it later is fine as well.
> 
> I hope you don't manage to punch holes into my theory this time around.

Ubuntu testing revealed that due to /lib64 going away in the package we
also are going to need Depends or PreDepends on base-files, such that
base-files trigger can then create the symlink.

Or we temporarily handle the trigger ourselves or so.

I am not sure if Depends are enough, I guess if you do a release
upgrade we could end up with

unpack base-files
unpack libc6 
preinst for something we want to unpack -> poof, no /lib64 here, can't 

Bug#1038434: Update on bug 1038434

[陈 晟祺]

Control: notfound -1 2.1.11-1
Control: tags -1 + wontfix

> There is a zfs-load-key service that is masked, and as such never
> starts, and the script in init.d doesn't do anything either because of
> that.

This service is intentionally masked. This functionality is now provided by
zfs-mount-generator(8). Please refer to its man pages for usage.

Thanks,
Shengqi Chen

Bug#1061290: RFS: rgbds/0.7.0-3 [ITP] -- Game Boy ASM programming tools

[P. J. McDermott]

I'm not a DD so I can't upload this, but I took a look.  I see you've
addressed most of the comments on Mentors in the repository on GitHub,
so I'm reviewing that rather than the older upload on Mentors.

Build-Depends lists pkg-config, which is a transitional package since
bookworm that should be replaced with the newer pkgconf.  lintian warns
about this:

W: rgbds source: build-depends-on-obsolete-package Build-Depends: 
pkg-config => pkgconf

This is just a suggestion/tip and not at all required, but it's popular
to use `wrap-and-sort -ast` to put each dependency on its own line (with
a trailing comma).  This would make the diff clearer in commits like
d1842536 and 22baba8b.

The years in the Copyright field of the "Files: *" stanza of d/copyright
look outdated: "1997-2020" when LICENSE says "1997-2023" since commit
f8af5696.

Not required by all sponsors, but Emmanuel on Mentors and Tobias here
suggested maintaining the packaging Git repository on Salsa (and
updating the Vcs- fields):

https://salsa.debian.org/
https://salsa.debian.org/games-team
https://salsa.debian.org/debian

You may also want to look into git-buildpackage with pristine-tar and a
DEP-14 branch layout:

https://honk.sigxcpu.org/piki/projects/git-buildpackage/
https://www.eyrie.org/~eagle/notes/debian/git.html
https://dep-team.pages.debian.net/deps/dep14/

Looks OK otherwise to me, and the package builds fine under sbuild with
no lintian tags (even informational or pedantic) other than the obsolete
package warning above; nice work!  So, once the pkg-config -> pkgconf
switch and copyright years update are done, I think it's good enough for
someone to upload.

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Facundo Gaich]

Hi,

I can work on packaging this if you're still interested, I'd need a sponsor.

I've already done some preliminary work on this, in particular I renamed
the bin to "rust-toml2json" but maybe you've got a better idea?

Best,
Facundo

Bug#1064461: gnome-settings-daemon: Xft.dpi not set correctly for 4K monitor at 200% scale

[Simon McVittie]

On Thu, 22 Feb 2024 at 14:21:38 +, Daniel Thompson wrote:
> I assume this is a version skew problem caused by gnome-settings-daemon
> updating to GNOME 46 before other components

If you upgrade both gnome-settings-daemon and gsettings-desktop-schemas
to their versions from unstable, does that resolve this?

(Possibly the same bug as #1064438)

smcv

Bug#1064031: chromium and rustc in bookworm

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2024-02-15 at 19:25 -0500, Andres Salomon wrote:
> Chromium now requires a Rust compiler to build, and it specifically 
> needs a rustc with profiler support built into it. This package can 
> hopefully be shared with firefox and other browser/web engines that
> end  up needing a newer rustc.

Please go ahead.

Regards,

Adam

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Sam Hartman]

> "Sean" == Sean Whitton  writes:
Sean> In general, I agree with Santiago.  I find Policy's current
Sean> scope and working process effective, and not especially
Sean> ambiguous.  I think everyone should read it during the NM
Sean> process, if not sooner.

Sean> Russ has concretely considered these issues much more than me,
Sean> and Niels has worked extensively on an implementation, and I
Sean> have not.  These things count, so my sense that things are
Sean> broadly okay as they are only goes so far.

I agree with the above.
When Russ brought up concerns I didn't want to add stop energy to making
things better.
But I also am generally happy with policy today.  I find it useful and
refer to it often.  I find that with almost all of my NM applicants I
end up asking them to look at policy at various points in the process
and they do not run into trouble using the document.
The only reason they did not before is they were not in the practice of
doing so.

Bug#1063821: python-dnslib 0.9.14-1+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1063821 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: python-dnslib
Version: 0.9.14-1+deb11u1

Explanation: validate transaction ID in client.py

Bug#1064371: mirror submission for mirror.xeonbd.com

[Adam D. Barratt]

On Tue, 2024-02-20 at 22:14 +, XeonBD wrote:
> Site: mirror.xeonbd.com
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
> Archive-http: /debian/
> Maintainer: XeonBD 
> Country: BD Bangladesh
> Location: Bangladesh
> Sponsor: XeonBD https://www.xeonbd.com

Our automated checks noticed an issue with your setup:

o We recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only HTTP is guaranteed to be available at
  ftp. sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Regards,

Adam

Bug#1062928:

[Michael Hudson-Doyle]

FWIW adding a quirk to the analysis confirms that this package is
unaffected by both the lfs and time_t transitions.

Bug#1064465: chromium: Chromium cannot use webgl without X (should be compiled with swiftshader)

[Charles Samuels]

Package: chromium
Version: 121.0.6167.160-1~deb12u1
Severity: normal
X-Debbugs-Cc: char...@derkarl.org

Dear Maintainer,

I'd like to use Chromium's webgl support in headless mode. However, If I don't 
have an X-server running, and I try to access a website that uses webgl, the 
browser simply doesn't support webgl, which forces me to use a non-Debian 
Chromium.

I can reproduce this problem with:
$ unset DISPLAY
$ chromium --headless=new --enable-webgl --screenshot https://get.webgl.org

Then Chromium outputs messages like:

[843245:843245:0222/035252.118199:ERROR:gl_display.cc(520)] EGL Driver message
(Critical) eglInitialize: Could not open the default X display.

In theory, I should be able to run Chromium, per their documentation:

$ chromium --headless=new --use-gl=swiftshader --enable-webgl --screenshot
https://get.webgl.org

But it indicates that that is not supported.

In order to support swiftshader, a clone of
 must be present in third_party/ 
and the debian/rules should set the features: enable_swiftshader=true
dawn_use_swiftshader=true . It might also make sense to use 
enable_swiftshader_vulkan=true as well

Thank you for your attention and the efforts you put into Debian.

cs


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

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

Versions of packages chromium depends on:
pn  chromium-common 
ii  libasound2  1.2.8-1+b1
ii  libatk-bridge2.0-0  2.46.0-5
ii  libatk1.0-0 2.46.0-5
ii  libatomic1  12.2.0-14
ii  libatspi2.0-0   2.46.0-5
ii  libbrotli1  1.0.9-2+b6
ii  libc6   2.36-9+deb12u3
ii  libcairo2   1.16.0-7
ii  libcups22.4.2-3+deb12u5
ii  libdbus-1-3 1.14.10-1~deb12u1
ii  libdouble-conversion3   3.2.1-1
ii  libdrm2 2.4.114-1+b1
ii  libevent-2.1-7  2.1.12-stable-8
ii  libexpat1   2.5.0-1
ii  libflac12   1.4.2+ds-2
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgbm1 22.3.6-1+deb12u1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.38-2~deb12u1
ii  libjpeg62-turbo 1:2.1.5-2
ii  libjsoncpp251.9.5-4
ii  liblcms2-2  2.14-2
ii  libminizip1 1.1-8+deb12u1
ii  libnspr42:4.35-1
ii  libnss3 2:3.87.1-1
ii  libopenh264-7   1:2.3.1-dmo1
ii  libopenjp2-72.5.0-2
ii  libopus01.3.1-3
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpng16-16 1.6.39-2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsnappy1v51.1.9-3
ii  libstdc++6  12.2.0-14
ii  libwebp71.2.4-0.2+deb12u1
ii  libwebpdemux2   1.2.4-0.2+deb12u1
ii  libwebpmux3 1.2.4-0.2+deb12u1
ii  libwoff11.0.2-2
ii  libx11-62:1.8.4-2+deb12u2
ii  libxcb1 1.15-1
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.6-1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2
ii  libxkbcommon0   1.5.0-1
ii  libxml2 
2.9.14+dfsg-1.3~deb12u1
ii  

Bug#1064465: chromium: Chromium cannot use webgl without X (should be compiled with swiftshader)

[Andres Salomon]

Swiftshader is manually disabled in Debian's chromium package. It's one 
of those legacy patches that I've long meant to look at (and remove if 
conditions allow it), but I haven't gotten to yet: 
https://salsa.debian.org/chromium-team/chromium/-/commit/84db0501b0d6cb055fe9f22057cd129fdefac710


It wasn't documented *why* swiftshader was disabled. Maybe related to 
non-DFSG third party libs (see https://bugs.debian.org/909156)? In order 
to reenable it, I need to poke around and see if I can figure out why it 
was disabled in the first place.



On 2/22/24 10:32, Charles Samuels wrote:

Package: chromium
Version: 121.0.6167.160-1~deb12u1
Severity: normal
X-Debbugs-Cc: char...@derkarl.org

Dear Maintainer,

I'd like to use Chromium's webgl support in headless mode. However, If I don't
have an X-server running, and I try to access a website that uses webgl, the
browser simply doesn't support webgl, which forces me to use a non-Debian
Chromium.

I can reproduce this problem with:
$ unset DISPLAY
$ chromium --headless=new --enable-webgl --screenshot https://get.webgl.org

Then Chromium outputs messages like:

[843245:843245:0222/035252.118199:ERROR:gl_display.cc(520)] EGL Driver message
(Critical) eglInitialize: Could not open the default X display.

In theory, I should be able to run Chromium, per their documentation:

$ chromium --headless=new --use-gl=swiftshader --enable-webgl --screenshot
https://get.webgl.org

But it indicates that that is not supported.

In order to support swiftshader, a clone of
 must be present in third_party/
and the debian/rules should set the features: enable_swiftshader=true
dawn_use_swiftshader=true . It might also make sense to use
enable_swiftshader_vulkan=true as well

Thank you for your attention and the efforts you put into Debian.

cs


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

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

Versions of packages chromium depends on:
pn  chromium-common 
ii  libasound2  1.2.8-1+b1
ii  libatk-bridge2.0-0  2.46.0-5
ii  libatk1.0-0 2.46.0-5
ii  libatomic1  12.2.0-14
ii  libatspi2.0-0   2.46.0-5
ii  libbrotli1  1.0.9-2+b6
ii  libc6   2.36-9+deb12u3
ii  libcairo2   1.16.0-7
ii  libcups22.4.2-3+deb12u5
ii  libdbus-1-3 1.14.10-1~deb12u1
ii  libdouble-conversion3   3.2.1-1
ii  libdrm2 2.4.114-1+b1
ii  libevent-2.1-7  2.1.12-stable-8
ii  libexpat1   2.5.0-1
ii  libflac12   1.4.2+ds-2
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgbm1 22.3.6-1+deb12u1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.38-2~deb12u1
ii  libjpeg62-turbo 1:2.1.5-2
ii  libjsoncpp251.9.5-4
ii  liblcms2-2  2.14-2
ii  libminizip1 1.1-8+deb12u1
ii  libnspr42:4.35-1
ii  libnss3 2:3.87.1-1
ii  libopenh264-7   1:2.3.1-dmo1
ii  libopenjp2-72.5.0-2
ii  libopus01.3.1-3
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpng16-16 1.6.39-2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsnappy1v51.1.9-3
ii  libstdc++6  12.2.0-14
ii  libwebp71.2.4-0.2+deb12u1
ii  libwebpdemux2   1.2.4-0.2+deb12u1
ii  libwebpmux3 1.2.4-0.2+deb12u1
ii  libwoff1   

Bug#1064469: debgpt: does not handle errors

[Vincent Lefevre]

Package: debgpt
Version: 0.4.94
Severity: minor

debgpt does not handle errors:

qaa:~> debgpt -Q -A "who are you?"
[19:06:24] OpenAIFrontend> Starting conversation  frontend.py:66
[...]
LLM[2]> Traceback (most recent call last):
  File "/bin/debgpt", line 8, in 
sys.exit(main())
 ^^
  File "/usr/lib/python3/dist-packages/debgpt/cli.py", line 455, in main
frontend.query_once(f, msg)
  File "/usr/lib/python3/dist-packages/debgpt/frontend.py", line 218, in 
query_once
reply = f(text)
^^^
  File "/usr/lib/python3/dist-packages/debgpt/frontend.py", line 96, in __call__
return self.query(*args, **kwargs)
   ^^^
  File "/usr/lib/python3/dist-packages/debgpt/frontend.py", line 131, in query
completion = self.client.chat.completions.create(
 
  File "/usr/lib/python3/dist-packages/openai/_utils/_utils.py", line 275, in 
wrapper
return func(*args, **kwargs)
   ^
  File "/usr/lib/python3/dist-packages/openai/resources/chat/completions.py", 
line 663, in create
return self._post(
   ^^^
  File "/usr/lib/python3/dist-packages/openai/_base_client.py", line 1200, in 
post
return cast(ResponseT, self.request(cast_to, opts, stream=stream, 
stream_cls=stream_cls))
   
^
  File "/usr/lib/python3/dist-packages/openai/_base_client.py", line 889, in 
request
return self._request(
   ^^
  File "/usr/lib/python3/dist-packages/openai/_base_client.py", line 980, in 
_request
raise self._make_status_error_from_response(err.response) from None
openai.AuthenticationError: Error code: 401 - {'error': {'message': 'Incorrect 
API key provided: empty. You can find your API key at 
https://platform.openai.com/account/api-keys.', 'type': 
'invalid_request_error', 'param': None, 'code': 'invalid_api_key'}}

I would expect just a clear error message.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 debgpt depends on:
ii  python3 3.11.6-1
ii  python3-bs4 4.12.3-1
ii  python3-openai  1.12.0-1
ii  python3-prompt-toolkit  3.0.43-1
ii  python3-requests2.31.0+dfsg-1
ii  python3-rich13.3.1-2
ii  python3-tomli   2.0.1-2

Versions of packages debgpt recommends:
ii  git  1:2.43.0-1
ii  man-db   2.12.0-3
ii  python3-zmq  24.0.1-5+b1
ii  tldr 0.9.2-5

Versions of packages debgpt suggests:
pn  python3-torch | python3-torch-cuda | python3-torch-rocm  
pn  python3-transformers 

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1063703: RFP: swappy -- screenshot editing tool for sway

[Krzysztof Adamski]

retitle 1063703 ITP: swappy -- screenshot editing tool for sway
owner 1063703 !
thanks

I'm using that software daily and I already created a package for myself
so I could happily maintain it in Debian.

Best regards,
Krzysztof Adamski

Bug#1062744:

[Michael Hudson-Doyle]

> There are no mentions of 'time_t' in the public headers of this
> library.

Uh, this is not the case? zypp-core/Date.h contains a class with public
time_t members. Were you grepping the wrong library or something?

The library is also affected by the off_t transition.

> The logs shows that it's a false positive, as the automated
> tool simply wasn't able to build it:
>
>
https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/logs/libzypp-dev/base/log.txt

This is 100% not reliable logic as demonstrated above. Adrien added a quirk
to confirm that the library is affected by both transitions but I feel bad
for asking him to do this as the visual inspection turned out to be trivial.

> Closing as not applicable.

Reopening.

Bug#1062744:

[Michael Hudson-Doyle]

I've just reuploaded the package to experimental, new debdiff attached.

Bug#1062744:

[Michael Hudson-Doyle]

Sigh, attached to *this* mail


nmu_libzypp.debdiff
Description: Binary data

Bug#1062756: reported upstream

[Patrick Schleizer]

https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2053153/

Bug#1064447: debuerreotype: ineffective diversions (due to /usr-merge DEP17) for obsolete upstart files

[Tianon Gravi]

On Thu, 22 Feb 2024 at 01:48, Helmut Grohne  wrote:
> debuerreotype diverts /sbin/initctl. This file is part of upstart, which
> has been deleted from Debian since at least bullseye. If it still were
> part of Debian, we'd have to move the file and hence this diversion
> would become ineffective. Rather than fix it, I propose deleting the
> dead code.

It is precisely those older versions that the code still exists for --
I use debuerreotype for creating reproducible rootfs builds all the
way back to slink. 

You can see in [1] that it only runs that diversion iff "upstart"
exists in the repos we're pointed at.

[1]: 
https://github.com/debuerreotype/debuerreotype/blob/60b625d1ce31bd81525bb67fc3a33f9686bc3433/scripts/debuerreotype-minimizing-config#L40

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1064451: the problem with sending an error message via the reportbug package

[Sandro Tosi]

please read the doc and configure programs according to your needs:
https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/conf/reportbug.conf?ref_type=heads#L64-72

On Thu, Feb 22, 2024 at 6:03 AM Nikolay Sabelnikov
<79625490...@yandex.ru> wrote:
>
> Package: reportbug
> Version: 12.0.0
>
> hello. There is a problem with sending error information via reportbug. I use 
> Yandex mail. And I have two-factor protection set up there. And when setting 
> up, you need to add the ability to add a username and password that I can 
> generate in my mail account.
>
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1064451: the problem with sending an error message via the reportbug package

[Sandro Tosi]

it's a wiki, you can write it yourself if you want

On Thu, Feb 22, 2024 at 11:43 AM Николай Сабельников
<79625490...@yandex.ru> wrote:
>
> thanks for the information. but why is there no such information in the 
> Debian wiki? I think it's worth writing it in the wiki.
>
> 22 февраля 2024 г. 19:34:52 GMT+03:00, Sandro Tosi  
> пишет:
> >please read the doc and configure programs according to your needs:
> >https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/conf/reportbug.conf?ref_type=heads#L64-72
> >
> >On Thu, Feb 22, 2024 at 6:03 AM Nikolay Sabelnikov
> ><79625490...@yandex.ru> wrote:
> >>
> >> Package: reportbug
> >> Version: 12.0.0
> >>
> >> hello. There is a problem with sending error information via reportbug. I 
> >> use Yandex mail. And I have two-factor protection set up there. And when 
> >> setting up, you need to add the ability to add a username and password 
> >> that I can generate in my mail account.
> >>
> >>
> >
> >



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1064459: base-files: install aliasing symlinks for merged-/usr DEP17

[Helmut Grohne]

block 1064459 by 1053111 1055959 1059533 1059919 1059981 106 1060089 
1060139 1060160 1060270 1061274
user helm...@debian.org
usertags 1064459 dep17m2
thanks

Hi Santiago,

Thanks for the quick feedback.

On Thu, Feb 22, 2024 at 03:27:20PM +0100, Santiago Vila wrote:
> Hi> Please respect any already existing coding style that
> you can notice in other parts of base-files.
> 
> Some examples:
> 
> Indent in shell script using 2 spaces.
> Quotes around "triggered" and similar places.

I'm sorry. I've attached an updated patch correcting this in all places.

> (Also, I wonder if it would be possible to create debian/triggers
> using some sort of dh-exec-like template instead of having
> extra variables and a for loop in debian/rules).

Difficult. The problem is that we need a looping construct here or
duplicate the logic from debian/rules. I value don't-repeat-yourself
higher than being able to use dh-exec and hence interpolated the
triggers from debian/rules.

I somewhat simplified the logic using make's filter-out now. Hope that
makes things more clear.

> While we are at it: Is there an estimated date when you will want
> to upload this?

We can only move forward once all of the bugs marked as blockers have
been fixed (ideally in trixie). I'll have to look into NMUing them soon.
If all goes well and time64 settles, I can do the synced NMU around the
end of March. Does that work for you?

An unsolved problem at this time is how to ensure that all of the
relevant packages migrate to trixie at the same time. Possibly we'll
have to add mutual versioned Breaks to the mix.

Helmut
diff --minimal -Nru base-files-13/debian/base-files.dirs 
base-files-13+nmu1/debian/base-files.dirs
--- base-files-13/debian/base-files.dirs2023-03-02 14:00:00.0 
+0100
+++ base-files-13+nmu1/debian/base-files.dirs   2024-01-24 08:10:53.0 
+0100
@@ -1,4 +1,3 @@
-bin
 boot
 dev
 etc
@@ -8,19 +7,14 @@
 etc/skel
 etc/update-motd.d
 home
-lib
 proc
 root
 run
-sbin
 sys
 tmp
 usr
-usr/bin
 usr/games
 usr/include
-usr/lib
-usr/sbin
 usr/share
 usr/share/base-files
 usr/share/common-licenses
diff --minimal -Nru base-files-13/debian/base-files.lintian-overrides 
base-files-13+nmu1/debian/base-files.lintian-overrides
--- base-files-13/debian/base-files.lintian-overrides   2023-03-02 
14:00:00.0 +0100
+++ base-files-13+nmu1/debian/base-files.lintian-overrides  2024-02-22 
17:16:54.0 +0100
@@ -20,3 +20,14 @@
 base-files: extra-license-file [usr/share/common-licenses/LGPL-2]
 base-files: extra-license-file [usr/share/common-licenses/LGPL-2.1]
 base-files: extra-license-file [usr/share/common-licenses/LGPL-3]
+
+# Yes, these links really should be relative
+base-files: relative-symlink usr/bin [bin]
+base-files: relative-symlink usr/lib [lib]
+base-files: relative-symlink usr/lib64 [lib64]
+base-files: relative-symlink usr/libx32 [libx32]
+base-files: relative-symlink usr/sbin [sbin]
+
+# Yes, we need these for the relevant architectures
+base-files: non-multi-arch-lib-dir [usr/lib64/]
+base-files: non-multi-arch-lib-dir [usr/libx32/]
diff --minimal -Nru base-files-13/debian/changelog 
base-files-13+nmu1/debian/changelog
--- base-files-13/debian/changelog  2023-06-11 17:00:00.0 +0200
+++ base-files-13+nmu1/debian/changelog 2024-02-22 17:16:54.0 +0100
@@ -1,3 +1,10 @@
+base-files (13+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * DEP17: Install /usr-merge aliasing symlinks. Closes: #-1.
+
+ -- Helmut Grohne   Thu, 22 Feb 2024 17:16:54 +0100
+
 base-files (13) unstable; urgency=medium
 
   * Change issue, issue.net, debian_version and os-release
diff --minimal -Nru base-files-13/debian/clean base-files-13+nmu1/debian/clean
--- base-files-13/debian/clean  2023-03-02 14:00:00.0 +0100
+++ base-files-13+nmu1/debian/clean 2024-01-24 08:30:30.0 +0100
@@ -1 +1,2 @@
 debian/postinst
+debian/triggers
diff --minimal -Nru base-files-13/debian/control 
base-files-13+nmu1/debian/control
--- base-files-13/debian/control2023-03-02 14:00:00.0 +0100
+++ base-files-13+nmu1/debian/control   2024-01-24 08:25:17.0 +0100
@@ -7,7 +7,7 @@
 Rules-Requires-Root: binary-targets
 
 Package: base-files
-Provides: base
+Provides: base, usr-is-merged
 Architecture: any
 Pre-Depends: awk
 Depends: ${misc:Depends}
diff --minimal -Nru base-files-13/debian/postinst.in 
base-files-13+nmu1/debian/postinst.in
--- base-files-13/debian/postinst.in2023-03-02 14:00:00.0 +0100
+++ base-files-13+nmu1/debian/postinst.in   2024-02-22 17:15:11.0 
+0100
@@ -106,3 +106,15 @@
 install_directory mnt 755 root
   fi
 fi
+
+if [ "$1" = "triggered" ]; then
+  for d in #USR_MERGE_MULTILIB#; do
+if test -d "$DPKG_ROOT/usr/$d"; then
+  test -h "$DPKG_ROOT/$d" && continue
+  ln -s "usr/$d" "$DPKG_ROOT/$d"
+else
+  test -h "$DPKG_ROOT/$d" || continue
+  rm "$DPKG_ROOT/$d"
+fi
+  done
+fi
diff --minimal -Nru 

Bug#1064451: the problem with sending an error message via the reportbug package

[Николай Сабельников]

so we'll write it. can you tell me how to close the bug?

22 февраля 2024 г. 19:45:19 GMT+03:00, Sandro Tosi  
пишет:
>it's a wiki, you can write it yourself if you want
>
>On Thu, Feb 22, 2024 at 11:43 AM Николай Сабельников
><79625490...@yandex.ru> wrote:
>>
>> thanks for the information. but why is there no such information in the 
>> Debian wiki? I think it's worth writing it in the wiki.
>>
>> 22 февраля 2024 г. 19:34:52 GMT+03:00, Sandro Tosi  
>> пишет:
>> >please read the doc and configure programs according to your needs:
>> >https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/conf/reportbug.conf?ref_type=heads#L64-72
>> >
>> >On Thu, Feb 22, 2024 at 6:03 AM Nikolay Sabelnikov
>> ><79625490...@yandex.ru> wrote:
>> >>
>> >> Package: reportbug
>> >> Version: 12.0.0
>> >>
>> >> hello. There is a problem with sending error information via reportbug. I 
>> >> use Yandex mail. And I have two-factor protection set up there. And when 
>> >> setting up, you need to add the ability to add a username and password 
>> >> that I can generate in my mail account.
>> >>
>> >>
>> >
>> >
>
>
>

Bug#1064467: ITP: fonts-sn-pro -- friendly new typeface based on Nunito

[Agathe Porte]

Package: wnpp
Severity: wishlist
Owner: Agathe Porte 
X-Debbugs-Cc: debian-de...@lists.debian.org, gag...@debian.org

* Package name: fonts-sn-pro
  Version : 1.0.0
  Upstream Contact: Tobias https://tobias.so/
* URL : https://supernotes.app/open-source/sn-pro/
* License : OFL-1.1
  Programming Lang: N/A
  Description : friendly new typeface based on Nunito

A friendly new typeface that's open source and free for both personal and
commercial use. We've carefully re-designed each character, improving support
for Markdown and ligatures. This font family is continually being updated and
improved.
.
Designed at Supernotes. Based on Nunito by Vernon Adams.

Will be maintained in the debian-fonts team.

Bug#1064468: Settings schema 'org.gnome.desktop.a11y.interface' does not contain a key named 'show-status-shapes'

[David Mandelberg]

Package: gnome-settings-daemon
Version: 46~beta-1

After a recent upgrade, many applications running under gnome X11 
stopped using gnome's settings. (Like large text, cursor theme, etc.) 
Digging into it, I found that org.gnome.SettingsDaemon.XSettings.service 
had failed to start with this error message:


feb 21 23:54:27 solaria gsd-xsettings[2760]: Settings schema 
'org.gnome.desktop.a11y.interface' does not contain a key named 
'show-status-shapes'


Upgrading gsettings-desktop-schemas from 45.0-2 to 46~beta-3 seems to 
have fixed the problem. So I think gnome-settings-daemon's dependency on 
gsettings-desktop-schemas (>= 42~) should be updated to require a newer 
version?

Bug#1064343: tput sgr0 adds uncalled-for codes

[Sven Joachim]

I would like to add a few more points here, not to prolong the
discussion but rather for future reference and for myself.

On 2024-02-21 07:06 +0100, Adam Borowski wrote:

> On Tue, Feb 20, 2024 at 07:41:42PM +0100, Sven Joachim wrote:
>> The reason for including \E(B here is that sgr0 should cancel the
>> effects of a previous smacs (start alternate character set) sequence and
>> thus includes the rmacs (end alternate character set) escape sequence.

This has been the case from the early days of ncurses when ESR started
to maintain the terminfo collection.  On archive.debian.org I found a
version on ncurses 1.9.4 with the terminfo.src file version 9.8[1].

The ncurses manpages do not seem to explicitly mention this detail, but
implicitly it appears a few times, for instance in termcap(3ncurses):

,
| termcap has nothing analogous to terminfo's set_attributes (sgr)
| capability.  One consequence is that termcap applications assume that
| “me” (equivalent to terminfo's exit_attribute_mode (sgr0) capability)
| does not reset the alternate character set.  ncurses checks for, and
| modifies the data shared with, the termcap interface to accommodate the
| latter's limitation in this respect.
`

> Then it combines two completely different concepts in one label.  SGR is
> for character attributes, G0/G1 are for encoding.

You might think of it that way, but in (n)curses A_ALTCHARSET is just
another video attribute, the concepts are not that different.

>> Closing the bug, because everything works as intended.
>
> Well, I'm not going to fight a BTS war, but I don't agree with your
> decision.

If you want to see changes, please propose them upstream.  If Thomas
follows your reasoning, great for you.  Otherwise nothing is ever going
to happen anyway, because there is no way I am going to deviate from
upstream here (and patch sgr0 in a gazillion terminfo entries).

Cheers,
   Sven


1. 
https://archive.debian.org/debian/dists/Debian-0.93R6/source/devel/ncurses-1.9.4-0.tar.gz

Bug#1064431: mirror submission for mirror.fra.macarne.com

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2024-02-21 at 23:45 +, Macarne LLC wrote:
> Submission-Type: new
> Site: mirror.fra.macarne.com

Our automated checks found an issue with your mirror:

o The trace file at
  http://mirror.fra.macarne.com/debian/project/trace/mirror.fra.macarne.com
  is missing some required information.

  We expect at least the Maintainer and Upstream-mirror values to be filled in,
  and your trace file is missing one or both of them.


Please fix that and let us know once it's done.

Regards,

Adam

Bug#866340: aa-genprof: ERROR: Can't find system log "/var/log/syslog" (journald-only setup)

[3a58f101-de75-4b85-b8fe-127896854a50]

This bug is now 7 years old and has not been fixed yet? Jesus!

Bug#1064289: mirror submission for elmirror.cl

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Mon, 2024-02-19 at 18:57 +, https://elmirror.cl wrote:
> Site: elmirror.cl
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
> Archive-http: /debian/

Our automated checks noticed an issue with your setup:

o The trace file at
  http://elmirror.cl/debian/project/trace/elmirror.cl
  is missing some required information.

  We expect at least the Maintainer and Upstream-mirror values to be filled in,
  and your trace file is missing one or both of them.


Please fix that and let us know once it's done.

Regards,

Adam

Bug#1064470: barfs on superfluous environment variable

[Zefram]

Package: rakudo
Version: 2020.12+dfsg-1
Severity: normal

Here's an invocation of raku(1) to perform a trivial action:

$ raku -e 'say "hi"'
hi
$

And here's the same invocation with an irrelevant environment variable
added:

$ A=$'\xcc\x81'
$ for p in 0 1 2 3 4 5 6 7 8 9; do A=$A$A; done
$ export A
$ raku -e 'say "hi"'
Unhandled exception: Too many codepoints (1025) in grapheme
   at src/vm/moar/ModuleLoader.nqp:11  
(/usr/share/nqp/lib/ModuleLoader.moarvm:search_path)
 from src/vm/moar/ModuleLoader.nqp:133  
(/usr/share/nqp/lib/ModuleLoader.moarvm:)
 from src/vm/moar/ModuleLoader.nqp:130  
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_setting)
 from :1  
(/usr/lib/perl6/runtime/perl6.moarvm:)
$

raku(1) should not be failing because of an environment variable that
isn't controlling anything and isn't being referenced.

-zefram

Bug#1064471: python-pygraphviz: please package v1.12

[Alexandre Detiste]

Source: python-pygraphviz
Version: 1.7-3
Severity: normal

The current watch file does not work

https://pypi.org/project/pygraphviz/

https://github.com/pygraphviz/pygraphviz/releases/tag/pygraphviz-1.12

Greetings

Bug#1064472: librust-zerocopy-dev: impossible to install: depends on gone version of librust-zeroize-derive-dev

[Jonas Smedegaard]

Package: librust-zerocopy-dev
Version: 0.6.1-1+b1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: affects -1 rust-ahash

As subject says, the package is impossible to install: depends on gone
version of librust-zeroize-derive-dev

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXXnXMACgkQLHwxRsGg
ASFxoQ/+L0lbPWgl4ZPenJnpFsE7SXe2DcBEN7CLCvkJuLjSNiK87fxMOjJwdEEQ
6MgFMutcvVX78jxjotGuP/ZKFPPuKU+hO7E/vppp9YK0o2HtUsEaxwAMJisTkGyj
D6FXUVhKxh+5JMEP2GcIHnRnNcCET4jxpd3wp2TDoan8E/9P7VqYLOwdbK4JIg3J
L5U2sLZsddqWTO7MToGUMKqaPuUxBKlU4UZm+1vuNAZ2eS92yDKzGMQ1DQXevZx1
Rl7BcMt2+BTZhJ1Hs0uHKK+iZV3nnuXBnMCOZ9gAfMJH5ocBwjivpU2KwXzjKy9m
HqS4QOLbA48qU36nU8VW7xRIABoiCkXZRJEn3+DItXECGYzofH7k6U3XnIRJgyY4
9X3fGy/tZmu5VvZRVOaxvYFvqsAKFuOWQIpEkR81k8mmBfcsvOkcXiCBcg4Z5cBr
HopsSwI0/VVJXkQFZa/4R5zQ3I4Ot1hK+haE0RxV0DbPIZUxfK0HTUkYTD4c+vv+
A2YMOIH9FDwCsp+zgjFec6KeYQizBO1lQ7WCDOz5N3ppzLivdg757IZp12dQ5K7N
6PdjwIP5tFvwSj9AHRSPbEiPn4u7/dMMhOA4EeCJ56IjYkPJDimEcWqZCX2sjiCP
kRrvUDX7jG1HGV2UhWsL+Ib00NmgAkdLl+MfaUwPQ9l/oF49wp8=
=PsHr
-END PGP SIGNATURE-

Bug#1062770:

[Michael Hudson-Doyle]

> I published an updated consolidated report this morning. As you can see,
> there is an ABI change due to LFS in raft/uv.h
>
>
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-22T10%3A55%3A00/compat_reports/libraft-dev/base_to_lfs/compat_report.html
>
> It is possible some API is not supposed to be exposed or does not appear
> in a shared library or something else, and it would therefore be safe to
> ignore an ABI change that abi-compliance-checker reports. Since I don't
> have specific experience with this package, I can't take such decisions
> and it is ultimately your call.

I think a-c-c is confused here, the symbols it is complaining about are all
from libuv (maybe it got confused by multiple files called "uv.h"?).

So I think this package itself is unaffected, but will require a binNMU
once all the directly affected packages have been rebuilt (like ~5000 other
packages or whatever it is).

Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed

[Simon McVittie]

On Wed, 14 Feb 2024 at 16:47:23 +, Gayathri Berli wrote:
> In librsvg also we have seen some test failures and regressions. when we
> debugged, we came to know that pixman code changes are triggering the
> regression in librsvg.

That's good to know. I see in
https://gitlab.freedesktop.org/pixman/pixman/-/issues/78 that there is
some confusion over which layer of the stack is the right one to be doing
this byteswapping: the original change was made to fix a bug seen in
gnome-characters, but then that change caused the librsvg bug.

In my experience the only way to solve endianness issues without causing
regressions is to have clear documentation of what endianness each layer
of the stack is aiming to use, so that you can check the behaviour of
each function against that documentation/specification and say "this is
correct" or "this is wrong" with confidence. The majority of computers this
decade are little-endian, so it's mainly the people who are interested in
supporting big-endian computers who need to get this right.

For instance, if a function is returning 32-bit RGBA data, you need
to be able to know whether the correct format is "red first" or "alpha
first" or "red in the least significant byte of the first 32-bit word"
or "alpha in the least significant byte". Otherwise, you can't know
whether a change is actually correct, or whether it's a workaround for
the layer above or below also being wrong.

I think this is what Simon Ser means in their comments on
https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/92.
In your commit message you said "This will write out the pixels as BGRA
on big endian systems but obviously that's wrong", but that isn't obvious
(at least not to me, and probably not immediately obvious to the other
Simon either).

In https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/92
you mentioned that before reverting that change, pixman was failing its
test suite on big-endian, and reverting the change makes its test suite
pass. That's probably relatively good evidence that the revert is the
correct thing to do, but that means it deserves to be mentioned in the
commit message.

This SDL change might be a good example of making sure that an intended
endianness is documented clearly:
https://github.com/libsdl-org/SDL/pull/8318/files

and this one might be a good example of justifying why a change is the
correct change:
https://github.com/libsdl-org/SDL/pull/8819

smcv

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[Jonas Smedegaard]

Quoting Facundo Gaich (2024-02-22 17:12:22)
> I can work on packaging this if you're still interested, I'd need a sponsor.
> 
> I've already done some preliminary work on this, in particular I renamed
> the bin to "rust-toml2json" but maybe you've got a better idea?

If the command-line tool does somewhat the same as the existing one, I
suggest to rename it with the deviating part as the end instead, so that
users TAB-completing would easier notice the alternative:
toml2json-rust.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Bug#1063898: pipewire-bin: customization file in ALSA profile-sets wrongly packaged

[Dylan Aïssi]

Le jeu. 15 févr. 2024 à 16:03, Sander van Grieken
 a écrit :
>
> Using dpkg-divert is fine. Maybe adding a single comment line mentioning 
> dpkg-divert in /usr/share/alsa-card-profile/mixer/profile-sets/default.conf, 
> just above the include of -custom.conf would be helpful.
>

Patching files always has a maintenance cost that I would like to avoid and
since dpkg-divert is something specific to Debian, I am not sure upstream is
interested by adding such comment. But, we can install a -custom.conf.README
explaining how to use dpkg-divert on it. What do you think?

Best,
Dylan

Bug#1064471: python-pygraphviz: please package v1.12

[Sandro Tosi]

is there a reason you need a newer version of pygraphviz?

On Thu, Feb 22, 2024 at 1:51 PM Alexandre Detiste
 wrote:
>
> Source: python-pygraphviz
> Version: 1.7-3
> Severity: normal
>
> The current watch file does not work
>
> https://pypi.org/project/pygraphviz/
>
> https://github.com/pygraphviz/pygraphviz/releases/tag/pygraphviz-1.12
>
> Greetings



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

[Ralf Schlatterbeck]

On Thu, Feb 22, 2024 at 07:01:05PM +, Richard Lewis wrote:
> >
> > So I guess that logcheck should be prepared to receive both kinds of
> > timestamps, the 32-byte version and the 25-byte version (without the
> > subseconds timestamp).
> 
> what is the default, and does logcheck cope with that? there's a limit to
> how much to suport out of the box - especially as rsyslog is no longer the
> default.

The current default of Debians rsyslog (after a long time where it was
the 'traditional' format) it is now RFC 3339 timestamps. This comes in
two variants, with or without the sub-seconds part. Logcheck only
supports the variant *with* sub-seconds.

By default, logcheck supports the 'traditional' format and the 32-byte
header, the pattern in most logcheck rules is

^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32})

The first alternative matched by this is something like

Feb 18 00:01:36

while the second is

2024-02-16T20:59:34.218904+01:00

The short form also produced by rsyslog is

2024-02-16T22:06:02+01:00

The third (short) form with no sub-seconds part is currently not matched
by logcheck.

You might want to simply set the match pattern to

^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{25,32})

Although rsyslog would probably never produce it, RFC 3339 allows the
sub-seconds part to be short (min 1 digit). There is no maximum in RFC
3339 but RFC 5424 prohibits more than 6 digits:
https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.3.1
For RFC 3339 see p.7 section 5.6 in
https://www.rfc-editor.org/rfc/rfc3339#section-5.6

So it makes sense to match a range of lengths.

> if you configure a logger to produce a certain format it's not unreasonable
> to also have to edit logcheck rules accordingly

I'm talking about the new Debian rsyslog package's default.
And, yes, but that would mean to edit logcheck rules for each installed
package? And the new default of the rsyslog package is the two variants
of RFC 3339. Unfortunately the default for remote logging does *not*
transmit the sub-seconds part. So you end up with two timestamp formats
in the same logfile. Which is fine according to the syslog standard in
RFC 5424.

> But a longer-term solution is perhaps to allow easier customisation of
> rules via "macros"/variables --- a proof-of-concept for this is in
> progress, but not.yet ready for testing

Nice!

Thanks
Ralf
-- 
Dr. Ralf Schlatterbeck  Tel:   +43/2243/26465-16
Open Source Consulting  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling   email: off...@runtux.com

Bug#1052939: marked as done (lsp-mode: FTBFS: make: *** [debian/rules:4: binary] Error 25)

[Xiyue Deng]

Control: tags -1 pending

Xiyue Deng  writes:

> Control: reopen -1
> Control: found -1 8.0.0-6
>
> It looks like the attempted fix in 8.0.0-6 is not reliable and still
> fails in ppc64el[1] and s390x[2].  I'm working on a better fix which
> is also forwarded upstream.
>
> [1] https://ci.debian.net/packages/l/lsp-mode/testing/ppc64el/40221847/
> [2] https://ci.debian.net/packages/l/lsp-mode/testing/s390x/40222364/

I have prepared a newer snapshot that has the fix incorporated upstream.
There is a separate RFS[1], and the prepared package has been uploaded
to mentors[2].  Team repo can be found at [3].  Looking for sponsorship
:)

[1] https://bugs.debian.org/1059065
[2] https://mentors.debian.net/package/lsp-mode/
[3] https://salsa.debian.org/emacsen-team/lsp-mode

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Miguel Landaeta]

On Thu, Feb 22, 2024 at 02:19:21AM +, Amin Bandali wrote:
> Hi Miguel,
> 
> I'm interested in helping with this.  Do you have the current state 
> of your work available on Salsa or elsewhere that I could pull in
> and work on?  Otherwise I'll just start with a repo under my own
> account and we could later transfer it to the 'debian' group or
> elsewhere.

Hi Amin, thanks for reaching out.

I'll push my repo tomorrow or during the weekend to salsa and
update this thread with the link.

I started to work on this package a few weeks ago but I decided to
wait for qbe 1.2 before uploading a package and I just noticed
it finally happened this week so I was planning to resume my work
on it.

I don't have time to work on it this weekend but I'll publish it
in a few hours to unblock you and other folks interested in
collaborating.

If you want, I can add you as co-maintainer.

Cheers,
Miguel.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1058645: Do you need help with this package?

[Miguel Landaeta]

On Thu, Jan 18, 2024 at 07:50:29PM +0100, Martin Quinson wrote:
> Hello,
> 
> I'm wondering whether you need some help with the packaging of Hare. Is your
> current state available somewhere?

Hi Martin,

I apologize that I somehow missed this message in January.

I prepared a package a few weeks ago but I was waiting for qbe new
upstream release (#1058646) before proceeding with uploads to the
archive. 

Since I'm now noticing there are more folks interested in collaborating,
I'll prioritize this to push my repo to salsa this weekend so other
folks can help to get it ready or just reuse bits from other packaging
efforts if they meet Debian archive expectations.

I don't have my debian laptop handy but tomorrow I'll spend some time
on this and update this bug report with the repo link.

Cheers,
Miguel.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche

Bug#1064476: dpkg-buildflags: add support for building with frame pointers enabled

[Matthias Klose]

Package: dpkg-dev
Version: 1.22.1
Severity: wishlist
Tags: patch

Please add support to enable to build with frame-pointer turned on. The 
compilers in unstable default to -fomit-framepointer, this turns on 
-fno-omit-framepointer plus an architecture specific option.


To enable it, use

   DEB_BUILD_MAINT_OPTIONS="... qa=+framepointer"

The chosen area might not be ideal, it could also be added to the 
optimize area, however it is a "negative" optimization.


Currently the default is not changed in Debian.diff -Nru dpkg-1.22.1ubuntu3/debian/changelog dpkg-1.22.1ubuntu4/debian/changelog
--- dpkg-1.22.1ubuntu3/debian/changelog	2023-11-23 10:55:44.0 +0100
+++ dpkg-1.22.1ubuntu4/debian/changelog	2023-12-13 09:35:27.0 +0100
@@ -1,3 +1,15 @@
+dpkg (1.22.1ubuntu4) UNRELEASED; urgency=medium
+
+  * dpkg-buildflags: Add a new feature "framepointer" in the "qa" area.
+  * Turn on the use of frame pointers by default on 64bit architectures.
+- Add -fno-omit-frame-pointer.
+- On amd64 and arm64 also add -mno-omit-leaf-frame-pointer.
+- On s390x, also add -mbackchain.
+  * To build without frame pointers, set before setting up buildflags:
+DEB_BUILD_MAINT_OPTIONS="... qa=-framepointer ...".
+
+ -- Matthias Klose   Wed, 13 Dec 2023 09:35:27 +0100
+
 dpkg (1.22.1ubuntu3) noble; urgency=medium
 
   * Disable -fstack-clash-protection on armhf since it causes crashes
diff -Nru dpkg-1.22.1ubuntu3/scripts/Dpkg/Vendor/Debian.pm dpkg-1.22.1ubuntu4/scripts/Dpkg/Vendor/Debian.pm
--- dpkg-1.22.1ubuntu3/scripts/Dpkg/Vendor/Debian.pm	2023-11-23 10:55:44.0 +0100
+++ dpkg-1.22.1ubuntu4/scripts/Dpkg/Vendor/Debian.pm	2023-12-13 09:35:27.0 +0100
@@ -118,6 +118,7 @@
 qa => {
 bug => 0,
 canary => 0,
+framepointer => 0,
 },
 reproducible => {
 timeless => 1,
@@ -463,6 +464,20 @@
 $flags->append('LDFLAGS', "-Wl,-z,deb-canary-${id}");
 }
 
+require Dpkg::Arch;
+my $arch = Dpkg::Arch::get_host_arch();
+
+if ($flags->use_feature('qa', 'framepointer')) {
+$flags->append($_, '-fno-omit-frame-pointer') foreach @compile_flags;
+	if (Dpkg::Arch::debarch_eq($arch, 'amd64')) {
+	$flags->append($_, '-mno-omit-leaf-frame-pointer') foreach @compile_flags;
+	} elsif (Dpkg::Arch::debarch_eq($arch, 'arm64')) {
+	$flags->append($_, '-mno-omit-leaf-frame-pointer') foreach @compile_flags;
+	} elsif (Dpkg::Arch::debarch_eq($arch, 's390x')) {
+	$flags->append($_, '-mbackchain') foreach @compile_flags;
+	}
+}
+
 ## Area: reproducible
 
 # Warn when the __TIME__, __DATE__ and __TIMESTAMP__ macros are used.
diff -Nru dpkg-1.22.1ubuntu3/scripts/Dpkg/Vendor/Ubuntu.pm dpkg-1.22.1ubuntu4/scripts/Dpkg/Vendor/Ubuntu.pm
--- dpkg-1.22.1ubuntu3/scripts/Dpkg/Vendor/Ubuntu.pm	2023-11-23 10:55:44.0 +0100
+++ dpkg-1.22.1ubuntu4/scripts/Dpkg/Vendor/Ubuntu.pm	2023-12-13 09:35:27.0 +0100
@@ -177,6 +177,10 @@
 	$use_feature->{optimize}{lto} = 0;
 	}
 }
+
+if (any { $_ eq $arch } qw(amd64 arm64 ppc64el riscv64 s390x)) {
+$use_feature->{qa}{framepointer} = 1;
+}
 }
 
 sub set_build_features {

Bug#1064482: libdemeter-perl: Missing dependence on libwx-perl

[Carlo Segre]

Package: libdemeter-perl
Severity: grave
Justification: renders package unusable

The dathena program will not start without the libwx-perl package.


--
Carlo Segre 


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

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAIN
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 libdemeter-perl depends on:
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-2
ii  libchemistry-elements-perl  1.077-1
ii  libconfig-ini-perl  1:0.029-1
ii  libconst-fast-perl  0.014-2
ii  libdatetime-perl2:1.59-1+b1
ii  libdigest-sha-perl  6.04-1+b1
ii  libencoding-fixlatin-perl   1.04-3
ii  libfile-copy-recursive-perl 0.45-4
ii  libfile-countlines-perl 0.0.3-4
ii  libfile-touch-perl  0.12-2
ii  libfile-which-perl  1.27-2
ii  libgraph-perl   1:0.9727-1
ii  libheap-perl0.80-5
ii  libifeffit-perl 2:1.2.11d-12.5+b1
ii  libjson-perl4.1-1
ii  liblist-moreutils-perl  0.430-2
ii  libmath-combinatorics-perl  0.09-6
ii  libmath-derivative-perl 1.01-3
ii  libmath-random-perl 0.72-2+b3
ii  libmath-round-perl  0.08-1
ii  libmath-spline-perl 0.02-4
ii  libmoose-perl   2.2207-1
ii  libmoosex-aliases-perl  0.11-2
ii  libmoosex-types-laxnum-perl 0.04-2
ii  libmoosex-types-perl0.50-2
ii  libpdl-stats-perl   0.83-1+b1
ii  libpod-pom-perl 2.01-4
ii  libregexp-assemble-perl 0.38-2
ii  libregexp-common-perl   2017060201-3
ii  librpc-xml-perl 0.82-1
ii  libspreadsheet-writeexcel-perl  2.40-4
pn  libstar-parser-perl 
ii  libstatistics-descriptive-perl  3.0801-1
ii  libtext-template-perl   1.61-1
ii  libtext-unidecode-perl  1.30-3
ii  libtree-simple-perl 1.34-2
ii  libwant-perl0.29-2+b2
ii  libxmlrpc-lite-perl 0.717-5
ii  libxray-absorption-perl 3.0.1-4
ii  libxray-scattering-perl 3.0.1-3
ii  libyaml-tiny-perl   1.74-1
ii  pdl 1:2.085-1
ii  perl [libdigest-sha-perl]   5.38.2-3

libdemeter-perl recommends no packages.

libdemeter-perl suggests no packages.

-- 
Carlo U. Segre (he/him) -- Duchossois Leadership Professor of Physics
Professor of Materials Science & Engineering
Director, Center for Synchrotron Radiation Research and Instrumentation
Illinois Institute of Technology
Phone: 312.567.3498
se...@iit.edu   http://phys.iit.edu/~segre   se...@debian.org

Bug#1064394: release-notes: English language output for the commands into script session

[Franco Martelli]

On 21/02/24 at 23:49, Justin B Rye wrote:


Sorry I missed the sense, what explanation?


If we said "LC_ALL=C.UTF-8 LANGUAGE= script -T ..." it would have all
sorts of disadvantages, including the fact that we'd have to explain
all of it together.  Much easier to explain about script, then suggest
a "script -T..." commandline, *then* deal with locales separately.


Yes, users have to choice if they want to change localization inside the 
"script" session.



The question is, will users realise that they're putting the files in
*root's* home directory, and will they even know where that is?


A minimal assumption of knowledge base of the FHS ¹  and tilde-expansion 
should be take by Release Notes writers. I think we shouldn't worry 
about this.



If we really can't suggest using /var/tmp for this, that seems a pity;
that location *shouldn't* be wiped on reboot, and it's usable whether
you're running "sudo; screen" or "sudo screen" or "screen; sudo".


It's more popular to use a non-privileged home directory. Few people 
strictly adhere to the FHS ¹  specifications. This is why I am in favor 
of using tilde-expansion. No matters if the reader becomes root or runs 
"script" as non-privileged user: the files will always go in the home 
directory, where they will be used by "scriptreplay" command. By doing 
so we won't have to take care of where the files reside.



¹ https://refspecs.linuxfoundation.org/fhs.shtml
--
Franco Martelli

Bug#1064478: wireless-regdb: install firmware files into /usr

[Michael Biebl]

Source: wireless-regdb
Version: 2022.06.06-1
Severity: normal
Tags: patch trixie sid
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. wireless-regdb installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru wireless-regdb-2022.06.06/debian/changelog 
wireless-regdb-2022.06.06/debian/changelog
--- wireless-regdb-2022.06.06/debian/changelog  2022-07-30 22:10:23.0 
+0200
+++ wireless-regdb-2022.06.06/debian/changelog  2024-02-22 22:52:06.0 
+0100
@@ -1,3 +1,10 @@
+wireless-regdb (2022.06.06-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install firmware files into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Thu, 22 Feb 2024 22:52:06 +0100
+
 wireless-regdb (2022.06.06-1) unstable; urgency=medium
 
   * New upstream version:
diff -Nru wireless-regdb-2022.06.06/debian/rules 
wireless-regdb-2022.06.06/debian/rules
--- wireless-regdb-2022.06.06/debian/rules  2022-07-12 20:40:10.0 
+0200
+++ wireless-regdb-2022.06.06/debian/rules  2024-02-22 22:52:06.0 
+0100
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
-export CRDA_PATH = /lib/crda
+export CRDA_PATH = /usr/lib/crda
+export FIRMWARE_PATH = /usr/lib/firmware
 export REGDB_AUTHOR  = $(shell dpkg-parsechangelog -SMaintainer | sed 
's:.*<\(.*\)>:\1:')
 export V = 1
 # prevent the build system from calling lsb_release
@@ -41,11 +42,11 @@
 install-wireless-regdb:
$(MAKE) -C debian/build DESTDIR=$(CURDIR)/$(DIR) install
for file in regulatory.db regulatory.db.p7s; do \
-   install -m644 $$file $(DIR)/lib/firmware/$$file-upstream \
-   && mv $(DIR)/lib/firmware/$$file 
$(DIR)/lib/firmware/$$file-debian \
+   install -m644 $$file $(DIR)/usr/lib/firmware/$$file-upstream \
+   && mv $(DIR)/usr/lib/firmware/$$file 
$(DIR)/usr/lib/firmware/$$file-debian \
|| exit; \
done
-   rm -r $(DIR)/lib/crda
+   rm -r $(DIR)/usr/lib/crda
 # regulatory.db.5 just includes regulatory.bin.5, so we need to
 # install the latter as regulatory.db.5
mv $(DIR)/usr/share/man/man5/regulatory.bin.5.gz \
@@ -54,7 +55,7 @@
 install-wireless-regdb-udeb: DIR = debian/wireless-regdb-udeb
 install-wireless-regdb-udeb:
$(MAKE) -C debian/build DESTDIR=$(CURDIR)/$(DIR) install
-   rm -r $(DIR)/lib/crda $(DIR)/usr/share/man
+   rm -r $(DIR)/usr/lib/crda $(DIR)/usr/share/man
rmdir --ignore-fail-on-non-empty -p $(DIR)/usr/share
 
 override_dh_auto_clean:

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Tobias Frost]

Control: tags -1 moreinfo

Hi Joachim,

review based on the dsc containing:
Checksums-Sha256:
 75aa7ed495b21d360340c84a4def6e16e25ecc36dab91e2481631993b2624bde 5128639 
vzlogger_0.8.3.orig.tar.gz
 c6737877696173e8daa4c9e4d4a1b6663ae5256f669c87554360e665f154e292 6252 
vzlogger_0.8.3-1.debian.tar.xz

It is only a partial review, especially I did not do a d/copyright
review yet.

Please check my remarks and remove the moreinfo tag when ready.

On Tue, Feb 20, 2024 at 12:34:04PM +0100, Joachim Zobel wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "vzlogger":
> 
>  * Package name : vzlogger
>  Version : 3.1-4
>  Upstream contact : Joachim Zobel 
>  * URL : http://wiki.volkszaehler.org/software/controller/vzlogger
>  * License : GPL-3
>  * Vcs : https://github.com/volkszaehler/vzlogger
>  Section : net 
> 
> The source builds the following binary packages:
> 
>  vzlogger - program to read measurements from smart meters and log them
> to Influxdb or forward them via MQTT.
> 
> vzlogger is a tool to read and log measurements of a wide variety of
> smart meters and sensors. It supports various commonly used protocols
> such as s0, d0, sml, oms and others. It can write these data to an
> Influxdb, forward them via MQTT, make them available via HTTP or eport
> them to a volkszaehler.org middleware.
> 
> The package is maintained in the upstream repository. Upstream (which I
> am part of) currently builds native packages. These are patched (a
> switch from native to quilt, a different changelog and a version >= 3.0
> for the dependency on openssl) to make them more suitable for debian.
> The package is therefore availabe in the upstream repo 

Yeah, format 3.0 quilt is the way, it is not a native package.

> https://github.com/volkszaehler/vzlogger.git 
> 
> on branch debian-0.8.3-1.

(There is no such branch on that repo, but a "debian" one.)

Please see dep14 (https://dep-team.pages.debian.net/deps/dep14/) for 
recommendation how to layout the repository used for packaging, I'd
even recommend to use an extra repository for the packaging.

> Alternatively, you can download thepackage with 'dget' using this
> command:
> 
>  dget -x 
> http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.3-1.dsc
> 
> Regards,
> -- 
>  Joachim Zobel

As you are upstream:
https://wiki.debian.org/UpstreamGuide

d/source/lintian-overrides
 - delete the overrides, seems to be some remnant of earlier packaging.

d/DEBIAN_RELEASE.txt
 - delete this file; the information contained in this files would not
   be a process how to create a package for Debian. (and if you need a
   file describing certain unusal aspects of the Debian packaging, it
   would be README.source (see Debian Policy §4.14)
   I recommend checking out git-buildpackage:
   https://honk.sigxcpu.org/piki/projects/git-buildpackage/ 
   https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/
   - remove Debian_release.patch -- this is not needed, you work with
   your debian/ directory and evolve it, you do not patch it when you
   create a new version. 

d/control
 - specify Rules-Require-Root
 - you manually depend on libsml1. Can you expand why this is needed?
 - Build-Depend: s/pkg-config/pkgconf
 - remove versions from the versioned build dependencies, if the
   debpendency is already fulfilled in oldstable:
   - libjson-c-dev, libcurl4-openssl-dev, 


d/postinst / postrm
 - When you create a user, it should start with "_" - see policy 9.2.1
   - Another option might be using systemd's DynamicUser feature to 
 create the user at runtime. (bonus: some hardening for free.)
   - there's systemd-sysuser (works also without systemd as init system)
 to use sysusers.d 
   - do not delete users/groups on package removal. 

As you are involved with upstream:
The manpage, initfile, systemd service file should probably be included in the
upstream part, it is not only useful for Debian alone.

Linitian emits:
W: vzlogger source: build-depends-on-obsolete-package Build-Depends: pkg-config 
(>= 0.25) => pkgconf
W: vzlogger: groff-message troff::5: warning: cannot select 
font 'CB' [usr/share/man/man8/vzlogger.8.gz:1]
I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:12]
I: vzlogger: file-references-package-build-path [usr/bin/vzlogger]
I: vzlogger: file-references-package-build-path [usr/lib/static/libvz.a]
I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger]
I: vzlogger: hardening-no-fortify-functions [usr/bin/vzlogger]
I: vzlogger: systemd-service-file-missing-documentation-key 
[usr/lib/systemd/system/vzlogger.service]
I: vzlogger source: unused-override odd-historical-debian-changelog-version 
*0.3.4-rc1* [debian/source/lintian-overrides:2]
P: vzlogger source: capitalization-in-override-comment 
odd-historical-debian-changelog-version debian Debian 
[debian/source/lintian-overrides:1]
P: vzlogger source: silent-on-rules-requiring-root 

Bug#1064465: chromium: Chromium cannot use webgl without X (should be compiled with swiftshader)

[Charles Samuels]

On Thursday, February 22, 2024 9:52:03 A.M. PST Andres Salomon wrote:
> Swiftshader is manually disabled in Debian's chromium package. It's one 
> of those legacy patches that I've long meant to look at (and remove if 
> conditions allow it), but I haven't gotten to yet: 
> https://salsa.debian.org/chromium-team/chromium/-/commit/84db0501b0d6cb055fe
> 9f22057cd129fdefac710
 
> It wasn't documented *why* swiftshader was disabled. Maybe related to 
> non-DFSG third party libs (see https://bugs.debian.org/909156)? In order 
> to reenable it, I need to poke around and see if I can figure out why it 
> was disabled in the first place.

I looked at all of swiftshader's dependencies' licenses:

SPIRV: Apache
astc-encoder: Apache
benchmark: Apache
boost: Boost license (already part of Debian)
cppdap: Apache
glslang: 3-BSD, 2-BSD, MIT, Apache, GPL3, an NVIDIA license, which seems to be 
similar to the MIT/BSD licenses, Khronos License, already part of debian. 
glslang is already part of Debian
json: MIT
libbacktrace: BSD
llvm: llvm is already part of Debian
llvm-subzero: same license as LLVM
marl: Apache

Let me know if there is any way I can help!

c

Bug#1064454: debian-policy: Restrict deb822 field names more

[gregor herrmann]

On Thu, 22 Feb 2024 14:08:38 +0100, Simon Josefsson wrote:

> Would it make sense to change this to use an inclusive list of permitted
> characters instead?  How about checking the field names that is in use
> today, and construct a regexp of permitted symbols out of that?
> Starting point: [A-Za-z][A-Za-z0-9-_]*

Right, also: defining this as a regexp would be helpful for
implementation in all parsers (and I suspect there are many of them
…).


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1064454: debian-policy: Restrict deb822 field names more

[Sam Hartman]

> "Niels" == Niels Thykier  writes:

Niels> Simon Josefsson:
>> Would it make sense to change this to use an inclusive list of
>> permitted characters instead?  How about checking the field names
>> that is in use today, and construct a regexp of permitted symbols
>> out of that?  Starting point: [A-Za-z][A-Za-z0-9-_]*
>> 
>> /Simon

Niels> That is an option and would work for me.

I'd support something along these lines--an inclusive description rather
than an exclusive description.

Bug#1064474: ITP: rust-rustls-pki-types -- shared types for the rustls PKI ecosystem

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-rustls-pki-types
  Version : 1.3.0
  Upstream Contact: Dirkjan Ochtman 
* URL : https://github.com/rustls/pki-types
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : shared types for the rustls PKI ecosystem

 This crate provides types
 for representing X.509 certificates, keys and other types
 as commonly used in the rustls ecosystem.
 It is intended to be used
 by crates that need to work with such X.509 types,
 such as rustls, rustls-webpki, rustls-pemfile, and others.

This package is needed by recent releases of rust-rustls and others.
It will be maintained in the collaborative Debian section of salsa, at
.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXXsb4ACgkQLHwxRsGg
ASHhSw/+JRLgav5wk3niZQvqMtyKmXTb3DfZlx5DK+GMJL2qFtf3TG3hbrWURe2X
iX/OZqGSk5/IFJamgKbEFQI6JBtXjzCti6oXaPfVRIHBCF6ZPyISNdStKA2KAf5K
q/mh4NpbsSxDhJ00y5dkHSdg5d2p8DFAH+2ZvoW+TdS8eQHORYJ7Tty4G8N60CY7
YnlqefMIFa9i9AU57PlM1sUhTY71jrnwuCeR1dGL1VavBpeQrQihN+j0UdzDaTO7
jjvpmesrdfRMv9wUgvGaZ9GQLeox/rCFp7m5Cktdp5M4pX0itGhIljUd3iFcnvAq
hZoJTGvehWdia8GIJHtGk/Ivf9pajTIb4XFT6VWKeoM74H0zpjQSO4AA+WP/TzBk
vliuf5moOXVjV3UnvIKdPeLlsr1PtZm7dAzHryoxuru8rI4Sfz3zAU1uFbGrJ2jR
DkMSV9ozwPuOXliCaIdQdKzgITz3UN6lcqC9OqNhxJMpI1MOzx1wgNYYcVGOYGMz
FaI1yYakhjfJ4W/Jl+PE2sqjuY5dp/kEa8rL7Dq2346rGFOjzSOVIW6gX98QfiMr
eug0EBwYDO3QjEfQ/ziLmrt3ClPlSWw5hEAiISJjEEQaMQM2+4ABfndtP8cHWq77
9inuoMQmFyZuvB0CquuyO1Lx3BsBCe8uSjIAINo2JtMnk98pLLw=
=oPvz
-END PGP SIGNATURE-

Bug#1064483: ITP: rust-self-encryption -- self-encrypting files

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-self-encryption
  Version : 0.29.1
  Upstream Contact: MaidSafe.net limited
* URL : https://github.com/maidsafe/self_encryption
* License : GPL-3
  Programming Lang: Rust
  Description : self-encrypting files

 self_encryption implements a version of convergent encryption
 with an additional obfuscation step.
 This pattern allows secured data that can also be de-duplicated.
 .
 Convergent encryption, also known as content hash keying,
 is a cryptosystem
 that produces identical ciphertext from identical plaintext files.

This package is needed by safenet (bug#1008016).
It will be maintained in the collaborative Debian section of Salsa, at
.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXX2mIACgkQLHwxRsGg
ASGebBAAlpdeliOH5hFVNQGgEFWTK93RaB+FmdJlp6y8ug8jEZncuxzYZfb7Nf7L
K/tccUfifB9lqz6tGQBhqKFRJ8iOtYk0IqxIdhZqjAagmQMSZYS0+lTw/NY4WCrl
M3hGcrpu4+dibj59FNxj3uoMBBfe7wLMn5pHzzcBL3BBUl9VLAGH82YcLTAeh0jW
heBjdy4Ro3IQ8Y1ZcnXgr7QINlRrm57JtG0LxzSnrIKeISLsDO/YqIaM6e7gUcSd
4giz/2Urv9N3fysMR+JXyxq651z4LICh+jnUmVWB2O+Fbh1v5X4JqwxOAnr0BZQF
W667aj1MzOpC8A7wqxDGz24zKcgE0fHAVKoVSP45AG/lkVSWD+ppIiyZXXrX6fwE
lWXwwXnN7SaFNXxZzM4/w+GREnvqa7loNZ+AKFSh+qBQVjvd1/1Q4Dkn5jezNbjz
ZK6hcL7YmR8eMKOo08OpWBk9e1JRU4TGsLIKFR6PepvZCES71X4Vm8mPshSDSeQ3
Uadv1gQtTW5akLDz8s+SDwZ5V82GYM4H4JDHonaSCyDNR85oxeNASUz9VMCBv3BW
uJXMXa7xzDk/T5y7lMIA7D/ioKwEsHL/prYB3Tdfv+RLi0C4Z9VA5I+ftA9adzo5
G0dfPHNkzdLSMBfV7s4GT6Z6dbmsim6Qm7s3VHhqZ5zPAsLb5nA=
=mQH1
-END PGP SIGNATURE-

Bug#1064289: mirror submission for elmirror.cl

[Jonathan Gutierrez]

Hello Adam.



This should be fixed now. Sorry for the inconvenience.



Best,


Jonathan Gutiérrez








 El jue., 22 feb. 2024 15:30:39 -0300, Adam D. Barratt 
 escribió 



Control: tags -1 + moreinfo 
 
On Mon, 2024-02-19 at 18:57 +, https://elmirror.cl wrote: 
> Site: elmirror.cl 
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd- 
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x 
> Archive-http: /debian/ 
 
Our automated checks noticed an issue with your setup: 
 
o The trace file at 
 http://elmirror.cl/debian/project/trace/elmirror.cl 
 is missing some required information. 
 
 We expect at least the Maintainer and Upstream-mirror values to be filled in, 
 and your trace file is missing one or both of them. 
 
 
Please fix that and let us know once it's done. 
 
Regards, 
 
Adam

Bug#1063562: dt-schema: Please add version dependency for jsonschema

[Sebastian Reichel]

Hello Agathe,

On Thu, Feb 22, 2024 at 04:32:11PM +0100, Agathe Porte wrote:
> > This package completly breaks when using python3-jsonschema from
> > experimental (4.19.2-1). I had a quick look and upstream is aware
> > of the issue. The build script wants a version < 4.18:
> 
> Note that the 4.19.2 version was uploaded to unstable [1].

I guess that means the Priority of this bug should be increased
to grave (which should also result in an autoremove from testing).

> Even if we add this new `Depends: python3-jsonschema (<< 4.18)` the
> package will fail to build on unstable thus never migrate to testing.

If you add that dependency for the _binary_ package it should not fail
to build. It cannot migrate to testing, but IMHO that's good. Once
jsonschema migrates to testing it will be broken anyways.

> So I am delaying this for now until upstream decides what to do [2],
> or until jsonschema is fixed [3].
> 
> [1] 
> https://tracker.debian.org/news/1504986/accepted-python-jsonschema-4192-2-source-into-unstable/
> [2] https://github.com/devicetree-org/dt-schema/issues/109
> [3] https://github.com/python-jsonschema/jsonschema/issues/1085

Greetings,

-- Sebastian


signature.asc
Description: PGP signature

Bug#1063562: dt-schema: Please add version dependency for jsonschema

[Agathe Porte]

Hi,

> This package completly breaks when using python3-jsonschema from
> experimental (4.19.2-1). I had a quick look and upstream is aware
> of the issue. The build script wants a version < 4.18:

Note that the 4.19.2 version was uploaded to unstable [1].

Even if we add this new `Depends: python3-jsonschema (<< 4.18)` the
package will fail to build on unstable thus never migrate to testing.

So I am delaying this for now until upstream decides what to do [2],
or until jsonschema is fixed [3].

[1] 
https://tracker.debian.org/news/1504986/accepted-python-jsonschema-4192-2-source-into-unstable/
[2] https://github.com/devicetree-org/dt-schema/issues/109
[3] https://github.com/python-jsonschema/jsonschema/issues/1085

Bug#1064475: lists.debian.org: missing recent posts in search indices.

[James Addison]

Package: lists.debian.org
Severity: important

Dear Maintainer,

Some recent discussion from the Debian mailing lists appears to be missing
from the mailing list search engine[1] indices.

For example:

  * Searching for 'Debian'[2] in the debian-devel mailing list, results sorted
by date, currently retrieves a most-recent result dated February of Y2023.

  * A wider search for 'Debian'[3] without specifying an individual mailing
list currently retrieves results up to December of Y2023.

Could you inspect the indexing hosts/processes to check whether posts are being
indexed as expected?

Thank you,
James

[1] - https://lists.debian.org/search.html

[2] - https://lists.debian.org/cgi-bin/search?P=debian=Gdebian-devel=0

[3] - https://lists.debian.org/cgi-bin/search?P=debian=0

Bug#1064480: aardvark-dns - upcoming rust-nix update.

[Peter Green]

Package: greetd
Version: 0.9.0-6

We are preparing an update of rust-nix to version 0.27, the new version has
been uploaded to experlmental.

To build with this new version of nix, aardvark-dns needs a small patch
taken from upstream. A debdiff is attached, if I get no response I will
likely NMU this once the new version of rust-nix is in unstable.diff -Nru greetd-0.9.0/debian/changelog greetd-0.9.0/debian/changelog
--- greetd-0.9.0/debian/changelog   2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/changelog   2024-02-22 22:50:17.0 +
@@ -1,3 +1,11 @@
+greetd (0.9.0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch for nix 0.27
+  * Tighten build-dependency on nix.
+
+ -- Peter Michael Green   Thu, 22 Feb 2024 22:50:17 +
+
 greetd (0.9.0-6) unstable; urgency=medium
 
   * Relax dependency on rpassword (Closes: #1057931).
diff -Nru greetd-0.9.0/debian/control greetd-0.9.0/debian/control
--- greetd-0.9.0/debian/control 2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/control 2024-02-22 22:50:17.0 +
@@ -6,7 +6,7 @@
  debhelper-compat (= 13),
  dh-cargo,
 # greetd & greetd_ipc
- librust-nix-dev (>= 0.25),
+ librust-nix-0.27-dev,
  librust-pam-sys-dev (>= 0.5.6),
  librust-users-dev (>= 0.11.0),
  librust-serde-derive-dev (>= 1.0),
diff -Nru greetd-0.9.0/debian/patches/nix-0.27.patch 
greetd-0.9.0/debian/patches/nix-0.27.patch
--- greetd-0.9.0/debian/patches/nix-0.27.patch  1970-01-01 00:00:00.0 
+
+++ greetd-0.9.0/debian/patches/nix-0.27.patch  2024-02-22 22:46:40.0 
+
@@ -0,0 +1,43 @@
+This patch is based on the upstream commit described below, adapted for use
+in the Debian package by Peter Michael Green.
+
+commit 161218164d366482ab7fab9dcc59cbd40623ac2c
+Author: Kenny Levinsen 
+Date:   Wed Feb 7 15:14:24 2024 +0100
+
+Update dependencies
+
+diff --git a/greetd/Cargo.toml b/greetd/Cargo.toml
+index c206ac1..3b1446f 100644
+--- a/greetd/Cargo.toml
 b/greetd/Cargo.toml
+@@ -14,1 +14,1 @@ repository = "https://git.sr.ht/~kennylevinsen/greetd/;
+-nix = "0.26"
++nix = { version = "0.27", features = ["ioctl", "signal", "user", "fs", 
"mman"] }
+diff --git a/greetd/src/main.rs b/greetd/src/main.rs
+index b88c6dc..92a53d4 100644
+--- a/greetd/src/main.rs
 b/greetd/src/main.rs
+@@ -22,7 +22,7 @@ use crate::{error::Error, session::worker};
+ 
+ async fn session_worker_main(config: config::Config) -> Result<(), Error> {
+ let raw_fd = config.internal.session_worker as RawFd;
+-let mut cur_flags = unsafe { FdFlag::from_bits_unchecked(fcntl(raw_fd, 
FcntlArg::F_GETFD)?) };
++let mut cur_flags = FdFlag::from_bits_retain(fcntl(raw_fd, 
FcntlArg::F_GETFD)?);
+ cur_flags.insert(FdFlag::FD_CLOEXEC);
+ fcntl(raw_fd, FcntlArg::F_SETFD(cur_flags))?;
+ let sock = unsafe { UnixDatagram::from_raw_fd(raw_fd) };
+diff --git a/greetd/src/session/interface.rs b/greetd/src/session/interface.rs
+index f1d3f04..b31f47f 100644
+--- a/greetd/src/session/interface.rs
 b/greetd/src/session/interface.rs
+@@ -99,8 +99,7 @@ impl Session {
+ UnixDatagram::pair().map_err(|e| format!("could not create pipe: 
{}", e))?;
+ 
+ let raw_child = childfd.as_raw_fd();
+-let mut cur_flags =
+-unsafe { FdFlag::from_bits_unchecked(fcntl(raw_child, 
FcntlArg::F_GETFD)?) };
++let mut cur_flags = FdFlag::from_bits_retain(fcntl(raw_child, 
FcntlArg::F_GETFD)?);
+ cur_flags.remove(FdFlag::FD_CLOEXEC);
+ fcntl(raw_child, FcntlArg::F_SETFD(cur_flags))?;
+ 
diff -Nru greetd-0.9.0/debian/patches/relax_deps.patch 
greetd-0.9.0/debian/patches/relax_deps.patch
--- greetd-0.9.0/debian/patches/relax_deps.patch2023-12-21 
14:17:58.0 +
+++ greetd-0.9.0/debian/patches/relax_deps.patch2024-02-22 
22:48:38.0 +
@@ -15,15 +15,4 @@
  getopts = "0.2"
  enquote = "1.1"
 -nix = "0.26"
-+nix = ">=0.26"
 a/greetd/Cargo.toml
-+++ b/greetd/Cargo.toml
-@@ -11,7 +11,7 @@
- debug = []
- 
- [dependencies]
--nix = "0.26"
-+nix = ">=0.26"
- pam-sys = "0.5.6"
- users = "0.11.0"
- serde = { version = "1.0", features = ["derive"] }
++nix = ">= 0.26"
diff -Nru greetd-0.9.0/debian/patches/series greetd-0.9.0/debian/patches/series
--- greetd-0.9.0/debian/patches/series  2023-12-21 14:17:58.0 +
+++ greetd-0.9.0/debian/patches/series  2024-02-22 22:46:06.0 +
@@ -2,3 +2,4 @@
 config_tweaks.patch
 relax_deps.patch
 rpassword_6.0_adaptation.patch
+nix-0.27.patch

Bug#1064484: pytorch-cuda: FTBFS: error: cannot convert ‘dnnl::memory::data_type’ to ‘const ideep::dims&’

[Andreas Beckmann]

Source: pytorch-cuda
Version: 2.0.1+dfsg-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

while locally rebuilding all packages build-depending on
nvidia-cuda-toolkit, I noticed that pytorch-cuda started to FTBFS:

[621/2435] /usr/bin/cuda-g++ -DAT_PER_OPERATOR_HEADERS -DFMT_HEADER_ONLY=1 
-DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MMAP=1 -DHAVE_SHM_OPEN=1 -DHAVE_SHM_UNLINK=1 
-DMINIZ_DISABLE_ZIP_READER_CRC32_CHECKS -DONNXIFI_ENABLE_EXT=1 -DONNX_ML=1 
-DONNX_NAMESPACE=onnx -DUSE_
C10D_GLOO -DUSE_DISTRIBUTED -DUSE_EXTERNAL_MZCRC -DUSE_FLASH_ATTENTION 
-DUSE_RPC -DUSE_TENSORPIPE -D_FILE_OFFSET_BITS=64 -Dtorch_cpu_EXPORTS 
-I/build/pytorch-cuda-2.0.1+dfsg/build/aten/src 
-I/build/pytorch-cuda-2.0.1+dfsg/aten/src -I/build/pytorch-cuda-2.0.1
+dfsg/build -I/build/pytorch-cuda-2.0.1+dfsg 
-I/build/pytorch-cuda-2.0.1+dfsg/cmake/../third_party/benchmark/include 
-I/build/pytorch-cuda-2.0.1+dfsg/debian/foxi 
-I/build/pytorch-cuda-2.0.1+dfsg/build/debian/foxi 
-I/build/pytorch-cuda-2.0.1+dfsg/torch/csrc/a
pi -I/build/pytorch-cuda-2.0.1+dfsg/torch/csrc/api/include 
-I/build/pytorch-cuda-2.0.1+dfsg/caffe2/aten/src/TH 
-I/build/pytorch-cuda-2.0.1+dfsg/build/caffe2/aten/src/TH 
-I/build/pytorch-cuda-2.0.1+dfsg/build/caffe2/aten/src 
-I/build/pytorch-cuda-2.0.1+dfsg/b
uild/caffe2/../aten/src -I/build/pytorch-cuda-2.0.1+dfsg/torch/csrc 
-I/build/pytorch-cuda-2.0.1+dfsg/third_party/miniz-2.1.0 
-I/build/pytorch-cuda-2.0.1+dfsg/debian/kineto/libkineto/include 
-I/build/pytorch-cuda-2.0.1+dfsg/debian/kineto/libkineto/src -I/buil
d/pytorch-cuda-2.0.1+dfsg/aten/../third_party/catch/single_include 
-I/build/pytorch-cuda-2.0.1+dfsg/aten/src/ATen/.. 
-I/build/pytorch-cuda-2.0.1+dfsg/c10/.. 
-I/build/pytorch-cuda-2.0.1+dfsg/aten/src/ATen/native/quantized/cpu/qnnpack/include
 -I/build/pytorch-
cuda-2.0.1+dfsg/aten/src/ATen/native/quantized/cpu/qnnpack/src 
-I/build/pytorch-cuda-2.0.1+dfsg/aten/src/ATen/native/quantized/cpu/qnnpack/deps/clog/include
 -I/build/pytorch-cuda-2.0.1+dfsg/third_party/flatbuffers/include -isystem 
/build/pytorch-cuda-2.0.1+d
fsg/build/third_party/gloo -isystem 
/build/pytorch-cuda-2.0.1+dfsg/cmake/../third_party/gloo -isystem 
/build/pytorch-cuda-2.0.1+dfsg/cmake/../third_party/googletest/googlemock/include
 -isystem /build/pytorch-cuda-2.0.1+dfsg/cmake/../third_party/googletest/go
ogletest/include -isystem /usr/include/opencv4 -isystem /usr/include/eigen3 
-isystem /build/pytorch-cuda-2.0.1+dfsg/caffe2 -Wdate-time -D_FORTIFY_SOURCE=2 
-g -O2 -ffile-prefix-map=/build/pytorch-cuda-2.0.1+dfsg=. 
-fstack-protector-strong -fstack-clash-protec
tion -Wformat -Werror=format-security -fcf-protection -gsplit-dwarf 
-Wno-dangling-reference -fuse-ld=lld -I/usr -D_GLIBCXX_USE_CXX11_ABI=1 
-Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -DUSE_KINETO 
-DLIBKINETO_NOCUPTI -DLIBKINETO_NOROCTRACER
-DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC 
-Wall -Wextra -Werror=return-type -Werror=non-virtual-dtor 
-Werror=range-loop-construct -Werror=bool-operation -Wnarrowing 
-Wno-missing-field-initializers -Wno-type-limits -Wno-a
rray-bounds -Wno-unknown-pragmas -Wunused-local-typedefs -Wno-unused-parameter 
-Wno-unused-function -Wno-unused-result -Wno-strict-overflow 
-Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow 
-Wno-psabi -Wno-error=pedantic -Wno-err
or=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always 
-faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized 
-fno-math-errno -fno-trapping-math -Werror=format -Werror=cast-function-type 
-Wno-stringop-overflow -DHAVE_AVX512_CPU_
DEFINITION -DHAVE_AVX2_CPU_DEFINITION -O2 -g -DNDEBUG -std=gnu++17 -fPIC 
-DCAFFE2_USE_GLOO -DTH_HAVE_THREAD -Wall -Wextra -Wno-unused-parameter 
-Wno-unused-function -Wno-unused-result -Wno-missing-field-initializers 
-Wno-write-strings -Wno-unknown-pragmas -W
no-type-limits -Wno-array-bounds -Wno-sign-compare -Wno-strict-overflow 
-Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-missing-braces 
-Wno-maybe-uninitialized -fvisibility=hidden -O2 -DCAFFE2_BUILD_MAIN_LIB 
-fopenmp -Wno-deprecated-declarations
 -MD -MT 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp.o
 -MF 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp.o.d
 -o caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/
quantized/cpu/qlinear_prepack.cpp.o -c 
/build/pytorch-cuda-2.0.1+dfsg/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp
FAILED: 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp.o
/usr/bin/cuda-g++ -DAT_PER_OPERATOR_HEADERS -DFMT_HEADER_ONLY=1 
-DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MMAP=1 -DHAVE_SHM_OPEN=1 -DHAVE_SHM_UNLINK=1 
-DMINIZ_DISABLE_ZIP_READER_CRC32_CHECKS -DONNXIFI_ENABLE_EXT=1 -DONNX_ML=1 
-DONNX_NAMESPACE=onnx -DUSE_C10D_GLOO -
DUSE_DISTRIBUTED -DUSE_EXTERNAL_MZCRC -DUSE_FLASH_ATTENTION 

Bug#1064473: ITP: taskflow -- Parallel and Heterogeneous Task Programming System for C++

[Julian Gilbey]

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

* Package name: taskflow
  Version : 3.6.0+git20240218.9616467
  Upstream Contact: Dr. Tsung-Wei Huang 
* URL : https://taskflow.github.io/
* License : Expat
  Programming Lang: C++
  Description : Parallel and Heterogeneous Task Programming System for C++

 Taskflow helps you quickly write parallel and heterogeneous task
 programs with high performance and simultaneous high productivity. It
 is faster, more expressive, with fewer lines of code, and easier for
 drop-in integration than many of existing task programming libraries.
 It is provided as a collecion of C++ header files, using C++17.

This package is a dependency of rapidfuzz, which is a C++ and Python
library for rapid string distance calculations.  In turn, rapidfuzz is
a dependency of newer versions of other Python packages.

It is also a great package in itself, providing a library that can be
used to great effect, as described in several papers and conference
presentations.

I don't think it fits within the Debian Python Team's remit, yet it is
needed by them.  So my proposal is to have myself as maintainer for
now but for the Debian Python Team to be listed as an Uploader.

Bug#1050220: mutter: autopkgtest regression on s390x: tests time out after 5 minutes

[Simon McVittie]

On Tue, 20 Feb 2024 at 16:08:26 +, Gayathri Berli wrote:
> Please let us know if this bug still needs to be fixed.

I have never seen a s390x machine and probably never will, so you will
know much better than I do whether it's advantageous to our users for
mutter and gnome-shell to be available on that platform, or whether
it would be better to ask for architecture-specific removals of these
packages from s390x and stop spending time on them.

If you would like mutter and gnome-shell to be supportable on s390x,
then yes, we would like their tests to pass reliably there, because
otherwise we have no evidence that they work.

Does it make any sense for gnome-shell to exist on s390x? Or is s390x
only useful as a server platform?

smcv

Bug#1064477: lzo2: install shared library into /usr

[Michael Biebl]

Source: lzo2
Version: 2.10-2
Severity: normal
Tags: patch trixie sid
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. lzo2 installs files into /lib; these should be moved into the
respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru lzo2-2.10/debian/changelog lzo2-2.10/debian/changelog
--- lzo2-2.10/debian/changelog  2020-01-22 21:35:19.0 +0100
+++ lzo2-2.10/debian/changelog  2024-02-22 22:44:26.0 +0100
@@ -1,3 +1,10 @@
+lzo2 (2.10-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install shared library into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Thu, 22 Feb 2024 22:44:26 +0100
+
 lzo2 (2.10-2) unstable; urgency=medium
 
   * Add missing pkg-config build-dependency.
diff -Nru lzo2-2.10/debian/liblzo2-2.install lzo2-2.10/debian/liblzo2-2.install
--- lzo2-2.10/debian/liblzo2-2.install  2020-01-20 11:42:23.0 +0100
+++ lzo2-2.10/debian/liblzo2-2.install  2024-02-22 22:44:18.0 +0100
@@ -1 +1 @@
-lib/*/*.so.*
+usr/lib/*/*.so.*
diff -Nru lzo2-2.10/debian/liblzo2-2-udeb.install 
lzo2-2.10/debian/liblzo2-2-udeb.install
--- lzo2-2.10/debian/liblzo2-2-udeb.install 2020-01-20 11:42:23.0 
+0100
+++ lzo2-2.10/debian/liblzo2-2-udeb.install 2024-02-22 22:44:21.0 
+0100
@@ -1 +1 @@
-lib/*/*.so.*
+usr/lib/*/*.so.*
diff -Nru lzo2-2.10/debian/rules lzo2-2.10/debian/rules
--- lzo2-2.10/debian/rules  2020-01-22 19:13:05.0 +0100
+++ lzo2-2.10/debian/rules  2024-02-22 22:44:10.0 +0100
@@ -18,9 +18,6 @@
 
 override_dh_auto_install:
dh_auto_install
-   mkdir -p $(DEB_DESTDIR)/lib/$(DEB_HOST_MULTIARCH)
-   mv $(DEB_DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/*.so.* 
$(DEB_DESTDIR)/lib/$(DEB_HOST_MULTIARCH)
-   ln -sf /lib/$(DEB_HOST_MULTIARCH)/$$(basename $$(readlink 
$(DEB_DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/*.so)) 
$(DEB_DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/*.so
mkdir -p $(DEB_DESTDIR)/usr/share/lzo/minilzo
install -D -m 644 minilzo/README.LZO minilzo/minilzo.c 
minilzo/minilzo.h include/lzo/lzoconf.h include/lzo/lzodefs.h 
$(CURDIR)/debian/tmp/usr/share/lzo/minilzo
 

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Amin Bandali]

Hi Miguel,

On Thu, Feb 22, 2024 at 09:23:20PM +, Miguel Landaeta wrote:
> On Thu, Feb 22, 2024 at 02:19:21AM +, Amin Bandali wrote:
> > Hi Miguel,
> > 
> > I'm interested in helping with this.  Do you have the current state 
> > of your work available on Salsa or elsewhere that I could pull in
> > and work on?  Otherwise I'll just start with a repo under my own
> > account and we could later transfer it to the 'debian' group or
> > elsewhere.
> 
> Hi Amin, thanks for reaching out.
> 
> I'll push my repo tomorrow or during the weekend to salsa and
> update this thread with the link.
> 
> I started to work on this package a few weeks ago but I decided to
> wait for qbe 1.2 before uploading a package and I just noticed
> it finally happened this week so I was planning to resume my work
> on it.
> 
> I don't have time to work on it this weekend but I'll publish it
> in a few hours to unblock you and other folks interested in
> collaborating.

Sounds great, thanks in advance!

FWIW I was browsing Hare's website again earlier, and saw this bit
on https://harelang.org/installation:

  Step 0: Pre-requisites

[...]
QBE (the latest version on the git master branch, not the latest versioned 
release)

Though I think/hope that that's a remnant from earlier times before
Hare's first versioned release.  Hare's new release policy at
https://git.sr.ht/~sircmpwn/hare/tree/master/item/docs/release.md
is more reassuring:

  The Hare toolchain's chief dependency is qbe. Each Hare version
  is pinned to a specific qbe release, which is documented in the
  release notes corresponding to that Hare version.

So I'm hopeful that at this point and onwards, Hare would depend
on tagged release versions of qbe rather than git trunk commits.

> If you want, I can add you as co-maintainer.
> 
> Cheers,
> Miguel.

Sure, that would be great - many thanks. :-)

Best,
-amin

Bug#1064479: aardvark-dns - upcoming rust-nix update.

[Peter Green]

Package: aardvark-dns
Version: 1.4.0-5

We are preparing an update of rust-nix to version 0.27, the new version has
been uploaded to experlmental.

To build with this new version of nix, aardvark-dns needs the cargo dependency
on nix relaxing, and needs some features of the nix crate specifying explicitly.
A debdiff is attatched, if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.diff -Nru aardvark-dns-1.4.0/debian/changelog 
aardvark-dns-1.4.0/debian/changelog
--- aardvark-dns-1.4.0/debian/changelog 2023-09-07 00:45:48.0 +
+++ aardvark-dns-1.4.0/debian/changelog 2024-02-22 22:11:17.0 +
@@ -1,3 +1,11 @@
+aardvark-dns (1.4.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax cargo dependency on nix to support 0.27 and explicitly enable
+required features, since nix no longer enables any features by default.
+
+ -- Peter Michael Green   Thu, 22 Feb 2024 22:11:17 +
+
 aardvark-dns (1.4.0-5) unstable; urgency=medium
 
   * Build against clap version 4, Closes: #1040876, #1040877
diff -Nru aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 
aardvark-dns-1.4.0/debian/patches/update-dependencies.patch
--- aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2023-09-07 
00:45:48.0 +
+++ aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2024-02-22 
22:10:55.0 +
@@ -25,7 +25,7 @@
 +async-broadcast = ">= 0.4.1"
  resolv-conf = "0.7.0"
 -nix = "0.25.0"
-+nix = "0.26"
++nix = { version = ">= 0.25.0", features = ["fs", "signal"] }
  libc = "0.2"
  
  [build-dependencies]

Bug#525813: apt-file: Doesn't work very well when multiple package versions are available

[Christoph Anton Mitterer]

On Thu, 2024-02-22 at 08:59 +0100, Niels Thykier wrote:
> One challenge we have here is that a package can have multiple
> versions 
> in a given suite at the same time; notably in unstable.

And multiple arches...


> For people that want better support here, please request the archive 
> maintainers to provide an index with versioning so that apt-file can
> do 
> proper filtering.

Against what would one file such request? ftp.debian.org?


Cheers,
Chris.

Bug#1064481: ITP: golang-github-liggitt-tabwriter -- Drop in replacement for https://golang.org/pkg/text/tabwriter with additional features

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: golang-github-liggitt-tabwriter
  Version : 0.0~git20181228.89fcab3-1
  Upstream Author : Jordan Liggitt
* URL : https://github.com/liggitt/tabwriter
* License : BSD-3-clause
  Programming Lang: Go
  Description : Drop in replacement for the golang text/tabwriter with some 
additional features

 This library is a drop-in replacement for the golang text/tabwriter
 .
 The following additional features are supported:
 - The RememberWidths flag allows remembering maximum widths seen per column
   even after Flush() is called.
 - RememberedWidths() []int and SetRememberedWidths([]int) *Writer allow
   obtaining and transferring remembered column width between writers.

Bug#1064485: RFS: samplebrain/0.18.5-1 [ITP] -- Custom sample smashing app designed by Aphex Twin

[tous]

Package: sponsorship-requests

Severity: wishlist

Dear mentors,

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

* Package name : samplebrain
   Version  : 0.18.5-1
   Upstream contact : Dave Griffiths 
 * URL  : http://thentrythis.org/projects/samplebrain
 * License  : CC0-1.0, GPL-2+
 * Vcs  : https://salsa.debian.org/touss-guest/samplebrain
   Section  : sound

The source builds the following binary packages:

  samplebrain - Custom sample smashing app designed by Aphex Twin

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/s/samplebrain/samplebrain_0.18.5-1.dsc


Changes for the initial release:

 samplebrain (0.18.5-1) unstable; urgency=medium
 .
   * Initial release. (Closes: 1040745)

Regards,
--
  tous

Bug#1064491: gdb: symbol lookup error: gdb: undefined symbol: rl_eof_found

[Natalia Lewandowska]

Package: gdb
Version: 13.1-3
Severity: important
X-Debbugs-Cc: nlewandow...@posteo.net

Dear Maintainer,

When trying to launch gdb I receive the following error message:
  symbol lookup error: gdb: undefined symbol: rl_eof_found
and gdb never starts.


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

Kernel: Linux 6.1.0-18-amd64 (SMP w/24 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 gdb depends on:
ii  libbabeltrace1  1.5.11-1+b2
ii  libc6   2.36-9+deb12u4
ii  libdebuginfod1  0.188-2.1
ii  libexpat1   2.5.0-1
ii  libgcc-s1   12.2.0-14
ii  libgmp102:6.2.1+dfsg1-1.1
ii  libipt2 2.0.5-1
ii  liblzma55.4.1-0.2
ii  libmpfr64.2.0-1
ii  libncursesw66.4-4
ii  libpython3.11   3.11.2-6
ii  libreadline88.2-1.3
ii  libsource-highlight4v5  3.1.9-4.2+b3
ii  libstdc++6  12.2.0-14
ii  libtinfo6   6.4-4
ii  libxxhash0  0.8.1-1
ii  libzstd11.5.4+dfsg2-5
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.36-9+deb12u4

Versions of packages gdb suggests:
ii  gdb-doc13.1-1
pn  gdbserver  

-- no debconf information

Bug#1064486: rnp: FTBFS: Errors while running CTest

[Bo YU]

Source: rnp
Version: 0.17.0-3
Severity: serious 

Dear Maintainer,

The package has a ftbfs issue on my local amd64 build:

```
260/260 Test #255: cli_tests-Encryption 
..   Passed   60.86 sec

98% tests passed, 6 tests failed out of 260

Total Test time (real) =  71.61 sec

The following tests FAILED:
 90 - rnp_tests.test_ffi_security_profile (Failed)
159 - rnp_tests.test_rnp_access (Failed)
166 - rnp_tests.rnpkeys_generatekey_verifykeyHomeDirNoPermission 
(Failed)
174 - rnp_tests.test_key_add_userid (Failed)
258 - cli_tests-EncryptElgamal (Failed)
259 - cli_tests-Misc (Failed)
Errors while running CTest
make[1]: *** [Makefile:94: test] Error 8
make[1]: Leaving directory '/<>/build'
dh_auto_test: error: cd build && make -j16 test ARGS\+=--verbose ARGS\+=-j16 
returned exit code 2
make: *** [debian/rules:33: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Build finished at 2024-02-22T22:48:30Z
```

It was failed on riscv64 also, but less test cases than amd64:

```
The following tests FAILED:
 90 - rnp_tests.test_ffi_security_profile (Failed)
174 - rnp_tests.test_key_add_userid (Failed)
251 - cli_tests-EncryptElgamal (Failed)
Errors while running CTest
make[1]: *** [Makefile:94: test] Error 8
```

The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=rnp=riscv64=0.17.0-3%2Bb2=1708576037=0


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#879723: can get stuck in state INSANE and stop responding

[Pali Rohár]

On Saturday 16 December 2023 11:26:14 Pali Rohár wrote:
> On Friday 15 December 2023 21:53:08 Chris Hofstaedtler wrote:
> > On Wed, Oct 25, 2017 at 12:01:32AM -0400, Joey Hess wrote:
> > > If the netplug script fails to bring up the interface, netplug can
> > > put it into state INSANE. Unfortunately, it never leaves that state,
> > > preventing netplug from responding to further link changes.
> > [..]
> > 
> > A user on #Debian today reported something similar, on their
> > downstream distro vyos: https://vyos.dev/T5686
> > 
> > I'm leaving this here, just in case somebody has any use for this
> > info.
> 
> Thanks for reminder, I will look at it during next weeks.

I have looked at the whole netplugd state machine and transitions
between states. I identified more bugs than the one described in this
issue report. I have prepared fixes for all of them.

Joey, would you be interested in testing netplugd fixes?

Btw, I was trying to contact vyos people but they are not interested in
any discussion about netplugd, so I see no reason to link vyos issues.

Bug#1064489: python-packaging: please remove obsolete package python3-six from the build dependency

[Alexandre Detiste]

Source: python-packaging
Version: 23.2-1
Severity: normal

Hi,

This package does not use python3-six,
the old dependency can be dropped.

Greetings,

Alexandre