Bug#994521: ledmon: libsgutils2-2 1.46 update breaks ledmon

[Chris Putnam]

Package: ledmon
Version: 0.95-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After updating libsgutils2-2 to 1.46-1, ledmon no longer runs as the library
it is linked to (1.45) is no longer present on the system.

This happened also when libsgutils2-2 was updated to 1.45; see bug #957088.

Is there a way to prevent this from happening in the build system?

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

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

Versions of packages ledmon depends on:
ii  libc6  2.31-17
ii  libpci31:3.7.0-6
ii  libsgutils2-2  1.46-1
ii  libudev1   247.9-1
ii  openipmi   2.0.29-0.1+b1

ledmon recommends no packages.

ledmon suggests no packages.

-- no debconf information

Bug#992155: alternative approach to automatically updating extrepo repo keys

[Tomas Pospisek]

An alternative approach could be that an `apt update` would trigger an 
`extrepo update`.


I don't know enough about apt hooks etc. to be able to say if that would 
be feasible or - in case such a mechanism isn't available today -  if 
apt's maintainers would be in favor of it?


Installing a cron job that periodically retrieves extrepo updates would be 
easier to implement. However the problem of offline systems should be 
considered then. What do you do with systems (laptops f.ex.) that sleep 
when a cron job would be triggered or that are not connected to the 
internet at that time? One could look into systemd's timer mechanisms if 
the support being deferred until the system wakes up and is connected to 
the internet.


*t

Bug#520305: pssh: Allow '-' as an alias for stdin

[andrew bezella]

hello -

On Thu, 2021-09-16 at 23:34 +0200, Hilmar Preuße wrote:
> 
> > 
> I guess you speak about this patch, right?
> 
> https://cgit.freebsd.org/ports/tree/security/pssh/files/patch-psshlib_psshutil.py
> 
> The change wasn't implemented at upstream yet. Are you willing to
> test a 
> patched Debian package?
> 

yes, that looks like it is the patch, thank you!

i'm not using the pssh-suite of tools daily so it wouldn't be an
exhaustive test, but yes, i would be willing to install and try out a
patched .deb.

thanks again!

andy

-- 
andrew bezella 
internet archive

Bug#994285: libseccomp: FTBFS on arm64, armhf, mips64el and mipsel

[Johannes Schauer Marin Rodrigues]

Hi Felix,

you set the upstream bug to https://github.com/seccomp/libseccomp/issues/336
but I don't think that is correct. The failures is not the same for the
different architectures. mipsel fails different than arm64. I bisected upstream
git on both architectures and found out that the arm64 failure was introduced
in aa0f858 and the mipsel failure comes from e976080.

I contacted upstream about that here: 
https://github.com/seccomp/libseccomp/issues/338

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Anton Gladky]

Thanks, Vincent, for the information. I would still wait for CVE,
so we can apply a patch and track vulnerability for other
Debian versions (stable/oldstable/o-o-stable etc.).

Regards

Anton


Am Fr., 17. Sept. 2021 um 01:17 Uhr schrieb Vincent Lefevre <
vinc...@vinc17.net>:

> On 2021-09-16 21:23:34 +0200, Anton Gladky wrote:
> > Thanks for the bug report. We will fix it when CVE (if any) will be
> > assigned and upstream patch will be available.
>
> FYI, an upstream patch is now available here:
>
>   https://gmplib.org/list-archives/gmp-bugs/2021-September/005087.html
>
> > Though, the integer overflows are not making the package unusable in
> > most cases.
>
> Yes, but they may introduce security issues, in particular here
> because the behavior depends on data from a file, which may be
> untrusted. That said, here it is probably wise to check that the
> size is not too large in order to prevent the address space from
> being exhausted.
>

Bug#994516: mirror submission for mirror.johnnybegood.fr

[Valentin DI BETTA]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.johnnybegood.fr
Type: leaf
Archive-architecture: amd64 arm64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Valentin DI BETTA 
Country: FR France
Location: Paris




Trace Url: http://mirror.johnnybegood.fr/debian/project/trace/
Trace Url: 
http://mirror.johnnybegood.fr/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.johnnybegood.fr/debian/project/trace/mirror.johnnybegood.fr

Bug#994515: memtest86+: Bullseye version freezes, buster version was okay

[Stefan Ott]

Package: memtest86+
Version: 5.01-3.1
Severity: normal

Dear Maintainer,

The memtest86+ package shipping with Bullseye (5.01-3.1) freezes during
Test #2 (Address test, own address Parallel) on my machine.

If I downgrade to the package from Buster (5.01-3), it works perfectly
fine.

This is on an older machine (ASUS P5Q-EM DO with Core2 Duo E7400, 6 GB
DDR2).

Let me know if you need further details.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.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 memtest86+ depends on:
ii  debconf [debconf-2.0]  1.5.77

memtest86+ recommends no packages.

Versions of packages memtest86+ suggests:
ii  grub-pc  2.04-20
pn  hwtools  
pn  kernel-patch-badram  
pn  memtest86
pn  memtester
pn  mtools   

-- debconf information excluded

Bug#915541: [Debian-med-packaging] Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Charles Plessy]

Le Thu, Sep 16, 2021 at 08:37:38PM +0200, Lucas Nussbaum a écrit :
> https://salsa.debian.org/med-team/parallel/-/blob/master/debian/patches/remove-overreaching-citation-request.patch).

Hi all,

sorry but how likely is it that we will break user scripts with this patch ?

https://github.com/search?q=%22parallel+--citation%22=code

I think that it would be better to disable citation checks without
changing availability of the command-line options.  (Sorry that I
can not do it myself).

Ole, in Debian we put a lot of effort providing citation information in
a central space, so that one can collect detailed references for
complete pipelines made using our packages.

https://salsa.debian.org/med-team/parallel/-/blob/master/debian/upstream/metadata

But better than a bibliographic DOI, have you consideded registering a
RRID ? (https://www.rrids.org/) (https://scicrunch.org/resources) This
will give scientists an easier way to declare their use of your work in
their publications without going to troubles about space in the
bibliography section, which is limited by many journals.

To the others: do you know a way to list or count the publications that
refer to a given RRID ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#994520: yubikey-manager: please Depend or Recommend libyubikey-udev

[Florian Schlichting]

Package: yubikey-manager
Version: 4.0.0~a1-4
Severity: normal

Hi,

please consider adding libyubikey-udev to yubikey-manager's Depends (or
at least Recommends).

Trying to access the 'ykman otp' functions as unprivileged user fails in
non-obvious ways ("No YubiKey found with the given interface(s)") when
it should "just work". yubikey-personalization already depends on
libyubikey-udev, while libykpers-1-1 recommends it.

Florian

Bug#994519: libyubikey-udev: please run udevadm trigger to activate udev rule

[Florian Schlichting]

Package: libyubikey-udev
Version: 1.20.0-3
Severity: normal

Hi,

The libyubikey-udev basically ships a udev rule. It would be nice if it
ran the equivalent of 'sudo udevadm trigger' from its postinst in order
for the rule to become active.

BTW the salsa repo lacks the debian/1.20.0-3 tag.

Florian

Bug#992569: missing-debian-watch-file-standard files for watch files without content

[Felix Lechner]

Hi,

On Fri, Aug 20, 2021 at 3:33 AM Jelmer Vernooij  wrote:
>
> The missing-debian-watch-file-standard tag triggers for a lot of debian/watch
> files that have no contents, or only contain comments.

The watch file is probably not the best place to add manual download
instructions. For aladdin, it looks like a different version of the
link is listed in d/copyright. In addition to upstream metadata, there
is also README.source [1] which I personally find the best place to
document how to get sources.

For an example, please consider ppp: [2]

# How to create a snapshot from git:
#
# mkdir GIT
# git clone git://ozlabs.org/~paulus/ppp.git
# cd ..
#
# rsync --delete --archive --verbose GIT/ppp/ ppp-2.4.5~$(date
+%Y%m%d).orig/ --exclude=.git
# cp -a ppp-2.4.5~$(date +%Y%m%d).orig/ ppp-2.4.5~$(date +%Y%m%d)/
#

Kind regards
Felix Lechner

[1] 
https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source
[2] https://sources.debian.org/src/ppp/2.4.6-3.1/debian/README.source/

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

[Felix Lechner]

Hi Daniel,

On Thu, Sep 16, 2021 at 9:39 AM Daniel Kahn Gillmor  wrote:
>
> The fact that silencing this warning in the expected way ended up
> injecting a grave bug seems problematic.

It is an RPATH issue. I spotted '-rpath /usr/lib/x86_64-linux-gnu' in
the libtool invocation. [1]

Interestingly, the call to ./configure specified '--disable-rpath' but
was not successful. It seemed to resemble an issue in opendkim [2].
Perhaps this Debian doc about the topic [3] is helpful to you.

Kind regards
Felix Lechner

[1] https://salsa.debian.org/auth-team/shishi/-/jobs/1835930
[2] https://sourceforge.net/p/opendkim/bugs/189/
[3] https://wiki.debian.org/RpathIssue

Bug#994518: ITP: libxml-amazon-perl -- Perl extension for getting information from Amazon websites

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libxml-amazon-perl
  Version : 0.14
  Upstream Author : Shlomi Fish 
* URL : https://metacpan.org/release/XML-Amazon
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl extension for getting information from Amazon websites

XML::Amazon provides a simple way to get information from Amazon. The
XML::Amazon module can connect to the US, JP, UK, FR, DE and CA sites.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

[Felix Lechner]

Hi Daniel,

Sorry about the delayed response on this part.

On Thu, Aug 19, 2021 at 4:30 PM Daniel Kahn Gillmor  wrote:
>
> instead i get a lintian warning
> lacks-unversioned-link-to-shared-library

That is a very simple check. [1] Would you please include the full tag
context and a list of shipped files? The context mentions the expected
filename, which can be easily found in a shipping manifest (or not, in
your case).

There are two possible sources of bugs:

a) The expected file name is wrong. [2]
b) Lintian looks in the wrong folders. [3]

For (b) Lintian looks in the ld-config paths derived here [4] in part
from the multiarch path components found here. [5][6]

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/SharedLibs.pm#L307-309
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/SharedLibs.pm#L220-224
[3] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/SharedLibs.pm#L105
[4] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Data/Architectures.pm#L115
[5] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Data/Architectures.pm#L87
[6] 
https://salsa.debian.org/lintian/lintian/-/blob/master/data/architectures/host.json

Bug#994517: ITP: libfirefox-marionette-perl -- module to automate the Firefox browser with the Marionette protocol

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libfirefox-marionette-perl
  Version : 1.12
  Upstream Author : David Dick 
* URL : https://metacpan.org/release/Firefox-Marionette
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to automate the Firefox browser with the Marionette 
protocol

Firefox::Marionette is a client module to automate the Mozilla Firefox browser
via the Marionette protocol
(https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette/Protocol).

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#994514: ITP: libsyntax-keyword-match-perl -- match/case syntax plugin for perl

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libsyntax-keyword-match-perl
  Version : 0.08
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Syntax-Keyword-Match
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : match/case syntax plugin for perl

Syntax::Keyword::Match provides a syntax plugin that implements a
control-flow block called match/case, which executes at most one of a choice
of different blocks depending on the value of its controlling expression.

This is similar to C's switch/case syntax (copied into many other languages),
or syntax provided by Switch::Plain.

This is an initial, experimental implementation. Furthermore, it is built as
a non-trivial example use-case on top of XS::Parse::Keyword, which is also
experimental. No API or compatbility guarantees are made at this time.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

[Felix Lechner]

Hi Aurelien,

On Thu, Sep 16, 2021 at 4:00 PM Aurelien Jarno  wrote:
>
> Why is that supposed to be an issue?

I do not know, but the relocation error shows that the shared library
installed in /lib by libgpg-error0 is not found unless
libgpg-error0-dev ships a "breakout" link in /usr/lib.

On my local system, /lib has precedence over /usr/lib:

$ more /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

What reason could there be besides Pkgconfig for shishi's builder to
look only in /usr/lib?

> glibc has always been installed like that.

The analysis may not apply to Glibc. I do not see a Pkgconfig in
libc6-dev (and would have been surprised). Does Glibc recommend any
linker paths to consuming packages?

Kind regards
Felix Lechner

Bug#949985: cmake vs blender

[Timo Röhling]

Control: reassign src:qtbase-opensource-src 5.15.2+dfsg-9

On Mon, 14 Sep 2020 09:42:50 +0200 Mathieu Malaterre  wrote:

Control: reassign -1 src:cmake 3.15.4-1

> Package: blender
> Version: 2.81.a+dfsg-5
[...]
> 
https://buildd.debian.org/status/fetch.php?pkg=cmake=alpha=3.15.4-1=1579830052=0

Assuming user error, so reassigning to cmake package.


Looks more like a Qt5 configuration problem to me.

Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Vincent Lefevre]

On 2021-09-16 21:23:34 +0200, Anton Gladky wrote:
> Thanks for the bug report. We will fix it when CVE (if any) will be
> assigned and upstream patch will be available.

FYI, an upstream patch is now available here:

  https://gmplib.org/list-archives/gmp-bugs/2021-September/005087.html

> Though, the integer overflows are not making the package unusable in
> most cases.

Yes, but they may introduce security issues, in particular here
because the behavior depends on data from a file, which may be
untrusted. That said, here it is probably wise to check that the
size is not too large in order to prevent the address space from
being exhausted.

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

Bug#994513: buster-pu: package debconf/1.5.71+deb10u1

[Colin Watson]

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

[ Reason ]
https://bugs.debian.org/984533 and its clone
https://bugs.debian.org/985572 showed a buster-to-bullseye upgrade bug
in which debconf was unable to execute whiptail between unpacking the
new libslang2 and unpacking the new libc6.  Part of the fix for that
involved adjusting debconf in bullseye to detect this situation and
gracefully fall back to text mode.  The other part of the fix was to
adjust libc6.preinst to do something similar, in case debconf has not
yet been upgraded or the running debconf frontend is still from an old
version.

Unfortunately, the code in libc6.preinst was somewhat broken, resulting
in buster-to-bullseye upgrades that hang in some situations.  We only
noticed this after bullseye released because the breakage is only
apparent with certain package sets that provoke apt into choosing
particular upgrade orderings; even with this, I only know of it
happening for people who run "apt upgrade" as a separate step before
"apt full-upgrade" (IMO unnecessarily, but it seems to be some people's
habit).  https://bugs.debian.org/994042 has an analysis of the situation
and a reproduction recipe.

While fixing this particular upgrade bug requires fixing libc6.preinst
(because its broken logic happens before debconf has an opportunity to
decide what to do), it's possible for apt to attempt to unpack some
*other* package between unpacking the new libslang2 and the new libc6
which also tries to use debconf in its preinst, and that would run into
a similar bug.  (I admit to not having a concrete example of such an
upgrade ordering.)  The only way to fix that situation is to cherry-pick
the fix for #985572 into debconf in buster.  As Aurelien points out in
#994042, we can't rely on people having applied all buster updates
before starting the upgrade to bullseye.  Nevertheless, I think this
change would make upgrades more robust, since debconf must take great
care not to crash like this.

I recognize that #985572's severity is only "wishlist", which ordinarily
wouldn't merit an oldstable update; at the time it was thought that a
glibc change in bullseye would be enough to work around this
effectively, and that making debconf more robust would just be icing on
the cake.  #994042 suggests to me that that was too complacent.  If this
request is accepted then I'll unarchive and reopen #985572 and set its
severity to "important".

[ Impact ]
Certain upgrade orderings may crash with something along the lines of
"whiptail: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not
found (required by /lib/x86_64-linux-gnu/libslang.so.2)".

[ Tests ]
The reproduction recipe in #994042 is worth testing with this change,
though that isn't sufficient.  To test this bug directly, the simplest
approach is to install whiptail and/or dialog before an upgrade from
buster to bullseye, but then deliberately break them somehow (for
example by using dpkg-divert to replace them with shell scripts that
write something to standard error and then exit non-zero).

At the moment I've only done some very basic tests along these lines,
but I'll do full upgrade tests before uploading, assuming this request
is accepted.  With a point release coming up soon I thought I'd better
get this request in now.

[ Risks ]
The change itself is simple: it just adds two additional guards.  The
alternative is to do nothing and accept the risk of broken upgrades.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
I think the diff speaks for itself: it's just a couple of extra
--version checks.  (I've confirmed that both whiptail and dialog support
the --version argument in both buster and bullseye; and of course I'll
replace "UNRELEASED" with "buster" before uploading.)

diff -Nru debconf-1.5.71/Debconf/FrontEnd/Dialog.pm 
debconf-1.5.71+deb10u1/Debconf/FrontEnd/Dialog.pm
--- debconf-1.5.71/Debconf/FrontEnd/Dialog.pm   2019-01-15 09:56:11.0 
+
+++ debconf-1.5.71+deb10u1/Debconf/FrontEnd/Dialog.pm   2021-09-16 
23:36:53.0 +0100
@@ -65,7 +65,8 @@
# Autodetect if whiptail or dialog is available and set magic numbers.
if (Debconf::Path::find("whiptail") && 
(! defined $ENV{DEBCONF_FORCE_DIALOG} || ! 
Debconf::Path::find("dialog")) &&
-   (! defined $ENV{DEBCONF_FORCE_XDIALOG} || ! 
Debconf::Path::find("Xdialog"))) {
+   (! defined $ENV{DEBCONF_FORCE_XDIALOG} || ! 
Debconf::Path::find("Xdialog")) &&
+   system('whiptail --version >/dev/null 2>&1') == 0) {
$this->program('whiptail');
$this->dashsep('--');
$this->borderwidth(5);
@@ -77,7 +78,8 @@
$this->hasoutputfd(1);
}
elsif 

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

[Aurelien Jarno]

Hi Felix,

On 2021-09-16 15:56, Felix Lechner wrote:
> Hi Daniel,
> 
> On Thu, Sep 16, 2021 at 9:39 AM Daniel Kahn Gillmor  wrote:
> >
> >
> > The fact that silencing this warning in the expected way ended up
> > injecting a grave bug seems problematic.
> 
> Isn't that an issue with the library paths in libgpg-error?
> 
> On sid, libgpg-error0_1.42-3_amd64.deb installs the shared library into /lib:
> 
> /lib/x86_64-linux-gnu/libgpg-error.so.0
> /lib/x86_64-linux-gnu/libgpg-error.so.0.32.0
> 
> But the corresponding -dev installs the 'breakout-link' and the static
> library into /usr/lib
> 
> /usr/lib/x86_64-linux-gnu/libgpg-error.so
> /usr/lib/x86_64-linux-gnu/libgpg-error.a
> 

Why is that supposed to be an issue? glibc has always been installed
like that.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

[Felix Lechner]

Hi Daniel,

On Thu, Sep 16, 2021 at 9:39 AM Daniel Kahn Gillmor  wrote:
>
>
> The fact that silencing this warning in the expected way ended up
> injecting a grave bug seems problematic.

Isn't that an issue with the library paths in libgpg-error?

On sid, libgpg-error0_1.42-3_amd64.deb installs the shared library into /lib:

/lib/x86_64-linux-gnu/libgpg-error.so.0
/lib/x86_64-linux-gnu/libgpg-error.so.0.32.0

But the corresponding -dev installs the 'breakout-link' and the static
library into /usr/lib

/usr/lib/x86_64-linux-gnu/libgpg-error.so
/usr/lib/x86_64-linux-gnu/libgpg-error.a

I usually see all four files in the same directory. For my own
libwolfssl-dev—which is arguably much less used, if at all—the files
are all in /usr/lib:

/usr/lib/x86_64-linux-gnu/libwolfssl.a (from libwolfssl-dev)
/usr/lib/x86_64-linux-gnu/libwolfssl.so (from libwolfssl-dev)
/usr/lib/x86_64-linux-gnu/libwolfssl.so.24 (from libwolfssl24)
/usr/lib/x86_64-linux-gnu/libwolfssl.so.24.3.0 (from libwolfssl24)

Perhaps more significant, the Pkgconfig file for your libpg-error-dev
points consuming packages to /usr, but the shared libraries are
shipped in /lib:

$ more usr/lib/x86_64-linux-gnu/pkgconfig/gpg-error.pc
prefix=/usr
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${prefix}/lib/x86_64-linux-gnu
host=x86_64-pc-linux-gnu
mtcflags=
mtlibs=-pthread

Name: gpg-error
Description: GPG Runtime
Version: 1.42
Cflags:
Libs: -L${prefix}/lib/x86_64-linux-gnu -lgpg-error
Libs.private:
URL: https://www.gnupg.org/software/libgpg-error/index.html

When the link is dropped in an attempt to cure the Lintian tag [1]
Simon Josephson's build attempt of shishi [2] resorts to the static
version, which results—quite logically—in this relocation error:

/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libgpg-error.a<---
(libgpg_error_la-init.o): relocation R_X86_64_PC32 against symbol
`stderr@@GLIBC_2.2.5' can not be used when making a shared object;
recompile with -fPIC

What happens, please, if you ship the libraries in /usr/lib instead?
Alternatively, you could also ship the following link in /lib, move
the static library to /lib, and adjust the prefix in your Pkgconfig.

dh_link -plibgpg-error-dev
lib/$(DEB_HOST_MULTIARCH)/libgpg-error.so.0
lib/$(DEB_HOST_MULTIARCH)/libgpg-error.so

I am not familiar with all the intricacies of RPATH and related ld.so
features, but I am reading up on this blog page [3].

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/debian/libgpg-error/-/commit/7c408ba0968c14492b6f087c57c6d44af4878de6#8756c63497c8dc39f7773438edf53b220c773f67_34_33
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992573#5
[3] http://blog.tremily.us/posts/rpath/

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Sean Whitton]

Hello,

On Wed 15 Sep 2021 at 12:35PM +01, Simon McVittie wrote:

> On Wed, 15 Sep 2021 at 11:46:11 +0100, Simon McVittie wrote:
>> As for what that advice is, I'm open to suggestions, but I'm drafting
>> some possible wording, which I'll upload to
>> https://salsa.debian.org/debian/tech-ctte/ when I have a bug number
>> for it.
>
> Here it is:
>
> https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md

Thank you very much for this.

> This is a collection of various pieces of advice. I hope that this is
> sufficiently uncontroversial among the TC that we can improve the wording
> where necessary, then take a unanimous or close-to-unanimous vote
> "yes > further discussion" when we feel that it reflects consensus?

I think so, yes.

> If there are individual bits that are more contentious, then I suggest
> we vote on them as formally or informally as we are comfortable
> with, then make the formal resolution reflect the results of those
> votes; alternatively, we could kick out anything more controversial into
> a separate resolution if we need to.

Both those options seem reasonable.

> - §(Upgrade path from Debian 11 to Debian 12): Does everyone agree
>   with what I've written here about the implications of #978636?
>
>   I've tried to be careful to distinguish between the Debian 12
>   stable release and the state of testing/unstable during the development
>   cycle; better wordsmithing welcome.

The implications of this distinction is the main point of contention in
the -devel discussions, so far as I can tell.  I've two things to ask.
You write:

>> - Because Debian 11 installations with the non-merged-/usr layout already
>>   exist, all packages in Debian 12 should be installable onto a 
>> non-merged-/usr
>>   system along with their dependencies, and work correctly on the resulting
>>   system.

(1) The reason for this, to put it a bit simplistically, is that we
don't require apt to perform the upgrade between stable releases in any
particular order, right?  Or are there other reasons distinct from this
one that I'm missing?  I think it would be good to state the thing about
apt (in better language than mine) in the text.

(2) Some people on -devel would seem to think that we can have smooth
upgrades from bullseye to bookworm without requiring support for
non-merged-/usr in every single package in bookworm, i.e., without
supporting non-merged-/usr for testing/unstable installations during the
current release cycle.

What smcv has been arguing for is the most conservative option.  But
which of the following is it the TC wants to say:

- we are sure that this is the only way to ensure smooth upgrades, such
  that it pretty much follows from our previous decision on merged-/usr

- we think there might be viable alternatives to requiring every package
  in bookworm to work on both layouts, but we aren't sure they are safe
  enough, so we're recommending a simple and conservative approach

- we think that ensuring non-merged-/usr testing/unstable installations
  work during this release cycle is reason enough to take this highly
  conservative approach

?

> - §(Upgrade path from Debian 11 to Debian 12): Is the last paragraph
>   "If a suitable transition mechanism is not available by the time the
>   Debian 12 freeze is reached..." necessary, or is it implicit that
>   *obviously* we won't demand that the project carries on with merged-/usr
>   if it turns out not to be possible?

No, it's good to have that text.

> - §(Building packages): Does everyone agree with my interpretation of
>   what we agreed in #914897 and its implications? Do we need to make a
>   recommendation for the Debian 12 development cycle, or is it enough
>   to assume that the "middle" option that we resolved in #914897
>   continues to be our opinion?

I think that the other things said above mean that no-one would think
the situation with regard to building packages has changed since the
Debian 11 cycle.

>   I assume our advice power doesn't extend to unilaterally declaring
>   a class of bugs to be RC, but we can certainly advise the release team
>   and package maintainers that they *should* consider a class of bugs
>   to be RC; if they follow our advice, great, and if they don't, we can
>   consider whether we need to overrule in individual cases.

Agreed.

> - §(Moratorium on moving files' logical locations into /usr):
>   I think we should stop moving files into /usr on an individual basis,
>   at least until the consequences are fully understood, and perhaps for
>   the whole Debian 12 release cycle (after which, assuming merged-/usr
>   goes as we have recommended, maintainers can swap their logical location
>   without needing a transitional mechanism any more). Implementing
>   merged-/usr as the only supported layout means that moving files into
>   /usr on an individual basis is mostly unnecessary, because it has no
>   practical effect any more.

The case you make for this is 

Bug#741537: pssh: IPv6 host address processing broken

[Hilmar Preuße]

Am 13.03.2014 um 16:37 teilte Ivan Vilata i Balaguer mit:

Hi,


The handling of IPv6 addresses is broken since the
``parse_host_entry()`` function in ``psshutil.py`` thinks the colons
in it are an indication for a port and the last component is taken
apart.  Enclosing the address in brackets doesn't work either because
the host name resolution includes the brackets around the IP
address.

I'm pretty sure the issue is still in 2.3.4 available I'm currently 
packaging for Debian unstable. Are you nevertheless willing to test that 
version, in case it has been solved in the meantime?


https://freeshell.de/hille42/pssh_2.3.4/

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#994512: numactl: Please upgrade to 2.0.14

[Laurent Bigonville]

Source: numactl
Version: 2.0.12-1+b1
Severity: wishlist

Hello,

Could you please update to 2.0.14 that has been release in Sept 2020

The current version in debian is from 2018

Note that there might be intresting patches in the git repository like a
fix for s390x, see https://github.com/numactl/numactl/commits/master

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#994275: Reverting breaking changes in debianutils

[Sean Whitton]

Hello,

On Thu 16 Sep 2021 at 03:02PM -07, Sean Whitton wrote:

> The TC can't do detailed design work, so without such a proposal on the
> table, we're left deciding between a complete reversion and doing
> nothing at all.  It would be good to have more options.

This isn't quite right -- we could choose to implement some of your five
requests.  But this would not really yield an alternative transition
plan.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994511: fail2ban: clean bullseye intalation fail config default intalled firewall, nftables

[AngelD]

Package: fail2ban
Version: 0.11.2-2
Severity: normal
X-Debbugs-Cc: ang...@zerutek.com

I made a clean install of Debian bullseye (netinstall).

fail2ban fail becouse default instalation use iptables, not nftables

I guess the package uses iptables for compatibility, but in clean installations 
it fails because it does not use nftables.

I don't know if this configuration can be added by default on clean installs in 
the file /etc/fail2ban/jail.d/defaults-debian.conf the lines:

[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports


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

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

Versions of packages fail2ban depends on:
ii  lsb-base  11.1.0
ii  python3   3.9.2-3

Versions of packages fail2ban recommends:
ii  nftables   0.9.8-3.1
ii  python3-pyinotify  0.9.6-1.3
ii  python3-systemd234-3+b4
ii  whois  5.5.10

Versions of packages fail2ban suggests:
pn  mailx
pn  monit
ii  rsyslog [system-log-daemon]  8.2102.0-2
pn  sqlite3  

-- no debconf information

Bug#994275: Reverting breaking changes in debianutils

[Sean Whitton]

Hello Adrian,

On Wed 15 Sep 2021 at 01:36AM +03, Adrian Bunk wrote:

> Package: tech-ctte
> Severity: normal
>
> This is a request to override the maintainer of debianutils on several
> changes that were done to the package in unstable after the release of
> bullseye.
>
>
> More specifically, I am asking the Technical Committee to decide that:
>
> 1. The "which" program must be provided by an essential package.
>
> 2. The "which" program must not print any deprecation warnings.
>
> 3. The "which" program must not be provided through alternatives.
>
> 4. The debianutils package must continue to provide the "tempfile" program.
>
> 5. Programs in debianutils must not be moved to /usr unless there is
>project-wide consensus on packages doing such a move, and premature
>moving must be reverted.

Roughly speaking, you're asking for a complete reversion of the change.

Do you perhaps have a middle-ground proposal which would

(i) accept the decision of the debianutils maintainer that which should
be removed from the Essential set within a release cycle or so, but
also would

(ii) include a transition/deprecation plan which would impose less of a
 burden, from your point of view, on Debian contributors?

The TC can't do detailed design work, so without such a proposal on the
table, we're left deciding between a complete reversion and doing
nothing at all.  It would be good to have more options.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994504: [Aptitude-devel] Bug#994504: Bug#994504: Don't just say "not a real package"

[Axel Beckert]

Control: tag -1 - moreinfo

Hi Jidanni,

積丹尼 Dan Jacobson wrote:
> In this particular case, all I found was this package was mentioned in
> other installed packages' headers.

Thanks for this detail! And indeed, there are two types of packages
which can be seen as virtual or non-real package and it could help to
make a difference:

* Those provided by a package (can be installed, etc.) — those are
  officially called "virtual" in the Debian Policy.

* Those mentioned in package relations by other packages, but not
  (or no more) existing. Those exist in the dependency tree, but are
  not installable. I've seen those being called "virtual" as well, but
  I think that was never an official term for them. might have been a
  technical thing somewhere.

> I don't know if that makes it a virtual package or not.

Both these types were also called "virtual" and I'm not sure which
terms should be used to distinguish between them. Aptitude calls the
latter usually "UNAVAILABLE" in the context of dependencies, but
something like "mentioned" or "referred to" seems more precise.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#985459: dh-elpa: install error when root user has packages under /root/.emacs.d/elpa

[Nicholas D Steeves]

CCing #989905 (base-files)

> Setting user-package-dir to a nonexistent directory also seems to
> work. Nick, can you try the dh-elpa version at
> https://salsa.debian.org/emacsen-team/dh-elpa ? Or just apply
>
> https://salsa.debian.org/emacsen-team/dh-elpa/-/commit/600a1133903eb2f7d3b7d954467dcee0b2d0277b
>
> to /usr/lib/dh-elpa/helper/install
>

That's a cool low-friction solution! :-)  P.S. How likely is a future
where Emacs will return non-zero exit status if package-user-dir is not
found?  I'm guessing unlikely?

> Some possible alternatives:
>
> 1) maybe Sean remembers the proposed convention for a known empty
> directory? Is this usable in stable?
>
> 2) We could create and clean up an empty temporary directory
>
> 3) We could create /usr/lib/dh-elpa/empty

I have no strong opinion towards any of these options, but I was shocked
to discover that Debian didn't already have a /var/run/empty.

So I filed #989905 requesting /var/run/empty (present in Fedora, RedHat,
CentOS, SUSE, Arch, FreeBSD, and probably more).  It's not FHS, but it
seems like maybe it should be; although, a systemd-centric future
probably dynamically creates empty paths as-needed...

  https://bugs.debian.org/989905

Maybe a TC member could say something about whether a canonical empty
directory equivalent to /dev/null is good design?  Unfortunately it
won't help the situation in stable--unless base-files receives a
stable-update.  It seems like it might also require a point in Policy
along the lines of "packages must not install files nor write to
/var/run/empty".

#1 (via #989905) seems the cleanest, most standard, and conventional to
me, #2 seems like a maintscript (which are increasingly discouraged) or
a dpkg feature, and it seems to me that #3 sets a precedent that
sanctions the proliferation of empty directories (which is maybe
harmless and only kind of ugly and confusing?).  It's possible I'm
biased, so I leave it to you!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#994437: libortp: missing -lbctoolbox

[Dennis Filder]

X-Debbugs-CC: Frank Heckenbach 
Control: tags -1 confirmed

I've put it on the TODO list, so it will be fixed in time.

Regards.

Bug#785356: Investment

[Jacques Attali]

-- 
-
Wir bieten alle Arten von Darlehen, Investitionen und Projektfinanzierungen an
Finanzielle Unterstützung für Einzelpersonen, Unternehmen auf der
ganzen Welt. wir
ein Darlehen von 2% gewähren. Interessierte Kontaktieren Sie uns für
weitere Informationen.

Jacques Attali.

Bug#785356: Investment

[Jacques Attali]

-- 
-
Wir bieten alle Arten von Darlehen, Investitionen und Projektfinanzierungen an
Finanzielle Unterstützung für Einzelpersonen, Unternehmen auf der
ganzen Welt. wir
ein Darlehen von 2% gewähren. Interessierte Kontaktieren Sie uns für
weitere Informationen.

Jacques Attali.

Bug#533416: pssh: cannot parse for more than one -O/-o options; cannot use -i option

[Hilmar Preuße]

Am 17.06.2009 um 12:07 teilte Stéger József mit:

Hi,


Problem description:
parallel-scp and parallel-ssh are not able to accept
1./ more than one -O options and translate them to -o options of the 
corresponding applications.
2./ -i (identity) option.

A patch (for parallel-scp) is attached, which solves the issue, 
though not all possible combination of the optional arguments are 
implemented and/or tested. A similar workaround is available for the 
parallel-ssh. Maybe, the argument parsing of the parallel-scp/ssh

needs some  reconsiderations...

I pointed the new upstream (lilydjwg) author to the patch in the 
launchpad issue. So I hope it will be accepted sooner or later.


Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#520305: pssh: Allow '-' as an alias for stdin

[Hilmar Preuße]

Am 18.03.2009 um 19:07 teilte andy bezella mit:

Hi Andy,

the freebsd port of the pssh toolset has been modified to allow '-' 
as an alias for stdin in the host file specification 
(http://www.freebsdsoftware.org/security/pssh.html).  this feature

is included in other tools (e.g., fping) and is very useful in them.
could it be implemented here?


I guess you speak about this patch, right?

https://cgit.freebsd.org/ports/tree/security/pssh/files/patch-psshlib_psshutil.py

The change wasn't implemented at upstream yet. Are you willing to test a 
patched Debian package?


Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#994275: Reverting breaking changes in debianutils

[Clint Adams]

On Wed, Sep 15, 2021 at 01:36:26AM +0300, Adrian Bunk wrote:
> This is a request to override the maintainer of debianutils on several
> changes that were done to the package in unstable after the release of
> bullseye.

There is quite a lot in here and I disagree with most of it except for
the paragraph above.

However, I don't even know what this means:

> An offer by the maintainer of another essential package to move
> the "which" program there was rejected by the debianutils maintainer.

Because `which` (which I do not in any way view as part of
debianutils's core functionality) is now provided through
alternatives, an infinite number of essential packages could
provide their own `which` implementations and I don't know how
I would veto that even if I wanted to.

Similarly, if you want to move `tempfile` to another package, we can
transition that the same way `mktemp` was moved to coreutils.  You
could package the "original" `tempfile` or you could write a clever
little wrapper around `mktemp`.  I have opinions on this, but I will
keep them to myself because I won't be the one maintaining it.

Bug#994099: twclock: improve .desktop file

[Ervin Hegedüs]

Hi there,

On Mon, Sep 13, 2021 at 06:32:02AM +0200, Ervin Hegedüs wrote:
> Hi Daniele,
> 
> On Sun, Sep 12, 2021 at 10:02:47PM +0200, Daniele Forsi wrote:
> > that lintian pages tells to remove the menu file
> > /usr/share/menu/twclock not the Exec line
> 
> thanks - that's what I also wrote here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994099#26
> 
> but first I have to check the behavior without menu file.

I've installed a Debian Testing into a VM with some desktop
environments.

For now I checked the .desktop file (with and without d/menu
file) that .desktop contained the 'Exec'.

I installed both versions, without any difference.

When I start to type in the search field of Start menu, then I
can find the twclock, and is starts when I click it.

But the installer does not put it under any existing menu.

I've made a counter-test: downloaded the grig package, created
d/menu file, built the package and installed it. The installer
put the package under the "Other" menu item.

Actually, no conclusion. I think I have to make more researches.


73, Ervin

 

Bug#993824: transition: libqalculate

[Sebastian Ramacher]

On 2021-09-10 09:49:05 +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-libqalculate.html
> 
> On 2021-09-06 23:49:01, Phil Morrell wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > https://release.debian.org/transitions/html/auto-libqalculate.html
> > 
> > Please can we go ahead with the auto-libqalculate transition now? The
> > new version is in experimental and has built on all release arches,
> > including ports that gnuplot-nox is available for.
> > 
> > https://buildd.debian.org/status/package.php?p=libqalculate=experimental
> > 
> > It has 4 reverse dependencies which have all been test built with the
> > new version and we have significant team overlap with them for future
> > uploads.
> 
> Please go ahead

It seems that the move from libqalculate20-data to libqalculate-data is
causing some issues. If one has task-kde-desktop installed, apt is
unable to find an upgrade path and offers to remove task-kde-desktop
instead. (This as reported and debugged on #debian-next)

I think a transitional and empty libqalculate20-data that depends on
libqalculate-data and versioned Breaks+Replaces in libqalculate-data
would help in this case. It would make libqalculate20 and libqalculate22
coinstallable hopefolly helping apt to find a better solution than to
remove task-kde-desktop.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993271: RFA: ninka -- license identification tool for source code

[Zhi Han]

Hi Luka,

I'd like to  try to adopt this package.
>From the raspberry pi community, I had some experience of deb package with
tools like dpkg-buildpackage, debuild and gbp.

I think I can start the adoption from solving the problem of uscan, which I
saw on the Developer Information page.
Do you have already some info/idea/limitations ... for the solution?

>From my understanding,  the upstream tarball should be got from
github/dmgerman/ninka.
And at moment it should be from version 1.3.2
But there is no  tag/treeid/tarball... for 1.3.2 in the repository.
Would it be a good idea by sending an email to ask dmgerman?

BR,
Zhi

On Sun, 29 Aug 2021 20:37:49 + Luca Falavigna 
wrote:
> Package: wnpp
> Severity: normal
>
> I request an adopter for the ninka package.
>
> The package description is:
>  Ninka is a lightweight license identification tool for source code. It is
>  sentence-based, and provides a simple way to identify open source
licenses in
>  a source code file. It is capable of identifying several dozen different
>  licenses (and their variations).
>  .
>  Ninka has been designed to be lightweight, fast and accurate.
>  .
>  This package contains the standard ninka application.
>
>

Bug#993973: nss FTBFS with glibc 2.32: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull]

[Aurelien Jarno]

On 2021-09-15 00:06, Aurelien Jarno wrote:
> On 2021-09-09 00:52, Aurelien Jarno wrote:
> > control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=27476
> > 
> > On 2021-09-09 00:21, Helmut Grohne wrote:
> > > Source: nss
> > > Version: 2:3.70-1
> > > Severity: serious
> > > Tags: ftbfs
> > > X-Debbugs-Cc: debian-gl...@lists.debian.org
> > > 
> > > A native build of nss now fails as follows:
> > > 
> > > | x86_64-linux-gnu-gcc -o OBJS/nsinstall.o -c -std=c99 -g -g -fPIC   
> > > -pipe -ffunction-sections -fdata-sections -DHAVE_STRERROR -DLINUX -Dlinux 
> > > -Wall -Wshadow -Werror -DXP_UNIX -DXP_UNIX -DDEBUG -UNDEBUG 
> > > -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE 
> > > -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DDEBUG -UNDEBUG 
> > > -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE 
> > > -DSDB_MEASURE_USE_TEMP_DIR -D_REENTRANT -DNSS_NO_INIT_SUPPORT 
> > > -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT 
> > > -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES 
> > > -I/<>/dist/include -I/<>/dist/public/coreconf 
> > > -I/<>/dist/private/coreconf  nsinstall.c
> > > | nsinstall.c: In function ‘main’:
> > > | nsinstall.c:70:16: error: argument 1 is null but the corresponding size 
> > > argument 2 value is 4096 [-Werror=nonnull]
> > > |70 | #define GETCWD getcwd
> > > |   |^
> > > | nsinstall.c:239:8: note: in expansion of macro ‘GETCWD’
> > > |   239 |  cwd = GETCWD(0, PATH_MAX);
> > > |   |^~
> > > | In file included from nsinstall.c:20:
> > > | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ 
> > > declared with attribute ‘write_only (1, 2)’
> > > |   520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur
> > > |   |  ^~
> > > | nsinstall.c:70:16: error: argument 1 is null but the corresponding size 
> > > argument 2 value is 4096 [-Werror=nonnull]
> > > |70 | #define GETCWD getcwd
> > > |   |^
> > > | nsinstall.c:246:13: note: in expansion of macro ‘GETCWD’
> > > |   246 | todir = GETCWD(0, PATH_MAX);
> > > |   | ^~
> > > | In file included from nsinstall.c:20:
> > > | /usr/include/unistd.h:520:14: note: in a call to function ‘getcwd’ 
> > > declared with attribute ‘write_only (1, 2)’
> > > |   520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur
> > > |   |  ^~
> > > | cc1: all warnings being treated as errors
> > > | make[2]: *** [../../coreconf/rules.mk:292: OBJS/nsinstall.o] Error 1
> > > | make[2]: Leaving directory '/<>/nss/coreconf/nsinstall'
> > > | make[1]: *** [debian/rules:100: override_dh_auto_build] Error 2
> > > | make[1]: Leaving directory '/<>'
> > > | make: *** [debian/rules:195: build] Error 2
> > > | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> > > status 2
> > > 
> > > It looks very much like this is due to the glibc 2.32 upload. My reading
> > > of man getcwd is that the call of nss is legit (as a glibc extension).
> > > Maybe this is a glibc bug?
> > 
> > This is indeed partially a glibc bug, already reported upstream there:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=27476
> > 
> > Note however that the feature of calling getcwd(NULL, >0) is a GNU
> > extension, and that the above code doesn't define _GNU_SOURCE, so this
> > is also a bug in the package.
> > 
> > Please also note that there are discussion to deprecate the support of
> > size > 0 when buf is NULL:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=26545
> 
> I have uploaded a version with a temporary fix, until upstream takes a
> decision. If upstream decides to drop this part of the GNU extension,
> this patch will be removed from the Debian package, so that the
> behaviour is consistent between distribution. Of course in that case
> the documentation will have to be fixed accordingly. The packages using
> this extension will have to get fixed, just like some distributions
> using glibc >= 2.32 started to do.

Note that the patch I submitted has been accepted, so this won't be
reverted.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#994504: [Aptitude-devel] Bug#994504: Don't just say "not a real package"

[積丹尼 Dan Jacobson]

In this particular case, all I found was this package was mentioned in
other installed packages' headers.

I don't know if that makes it a virtual package or not.

Bug#994504: [Aptitude-devel] Bug#994504: Don't just say "not a real package"

[Axel Beckert]

Control: tag -1 + moreinfo

Hi Jidanni,

積丹尼 Dan Jacobson wrote:
> Package: aptitude
> Version: 0.8.13-3
> Severity: wishlist
> 
> $ aptitude show ttf-unifont
> Package: ttf-unifont
> State: not a real package
> $ apt show ttf-unifont
> Package: ttf-unifont
> State: not a real package (virtual)
> 
> That's a little better.

I doubt that. To my knowledge "virtual" and "not a real package" are
equivalent. Adding that would only make sense if there are other types
of non-real packages. Otherwise it'd just be redundant and hence bloat.

Do you know of any other non-real package type than "virtual"?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#992856: pulseaudio: Pulseaudio does not automatically start on newer kernel

[Marco Balmer]

Package: pulseaudio
Version: 14.2-2
Followup-For: Bug #992856

I confirm this bug.

After starting pulseaudio manually
$ pulseaudio --start
audio is working.

How can I workarround this problem?

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.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 pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1.2.2-2
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-2
ii  libgcc-s110.2.1-6
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.2-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-2
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-6
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.3-6
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 14.2-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-2
ii  libpam-systemd [logind]  247.3-6
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
pn  pavucontrol  
pn  pavumeter
ii  udev 247.3-6

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; 

Bug#994510: libunwind8 abuses setcontext() causing SIGSEGV on i386 with glibc >= 2.32

[Aurelien Jarno]

Package: libunwind8
Version: 1.3.2-2
Severity: grave
Tags: upstream
X-Debbugs-Cc: debian-gl...@lists.debian.org

Following the glibc 2.32 upload to unstable, the autopkgtest of the
rspamd package fails on i386, due to a segmentation fault when starting
the daemon [1].

After digging, it appears that the problem is due to libunwind and the
following upstream glibc change [2]:

| commit 15eab1e3e89129ab3ed03f5bdc3415b26e9caeb9 (master)
| Author: H.J. Lu 
| Date:   Sat Feb 1 05:44:55 2020 -0800
| 
| i386: Don't unnecessarily save and restore EAX, ECX and EDX [BZ# 25262]
| 
| On i386, since EAX, ECX and EDX are caller-saved, there are no need
| to save and restore EAX, ECX and EDX in getcontext, setcontext and
| swapcontext.  They just need to clear EAX on success.  The extra
| scratch registers are needed to enable CET.
| 
| Tested on i386.
| 
| Reviewed-by: Adhemerval Zanella 


Basically EAX, ECX and EDX and are not saved anymore across a
getcontext() / setcontext() sequence, and more importantly they are not
restored in setcontext() which is used by libunwind to restore a context
after an exception. In that case, all the registers have to be restored,
including the caller-saved one.

It happens that libunwind shall not have used setcontext() there, but
rather defined its own implementation like its already done for
getcontext() as the behaviour of setcontext() is unspecified when passed
an ucp argument obtained from different sources than getcontext() or
makecontext(). Quoting the GNU libc manual:

| If the context was created by a call to a signal handler or from any
| other source then the behaviour of setcontext is unspecified.

Quoting POSIX.1-2004 (last version before it got removed):

| The effects of passing a ucp argument obtained from any other source
| are unspecified.

Note that upstream bug #69 might be relevant there [3].


[1] https://ci.debian.net/data/autopkgtest/testing/i386/r/rspamd/15290363/log.gz
[2] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=15eab1e3e89129ab3ed03f5bdc3415b26e9caeb9
[3] https://github.com/libunwind/libunwind/issues/69

Bug#994509: --with-recommends: mention what to do if package is already installed

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.8.13-3
Severity: wishlist

Manpage mentions:

   -r, --with-recommends
   Treat recommendations as dependencies when installing new packages
   (this overrides settings in /etc/apt/apt.conf and
   ~/.aptitude/config).

   This corresponds to the configuration option
   APT::Install-Recommends

OK, but mention what to do if the package is already installed.

One would think reinstall would work, but no, it doesn't get the
recommendations.

$ set fonts-noto
$ aptitude --with-recommends -s install $@
fonts-noto is already installed at the requested version (20201225-1)
fonts-noto is already installed at the requested version (20201225-1)
Need to get 0 B of archives. After unpacking 0 B will be used.
$ aptitude --with-recommends -s reinstall $@
The following packages will be REINSTALLED:
  fonts-noto
Need to get 0 B/21.1 kB of archives. After unpacking 0 B will be used.
Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?]
Inst fonts-noto [20201225-1] (20201225-1 Debian:unstable [all])
Conf fonts-noto (20201225-1 Debian:unstable [all])
$ aptitude --with-recommends -s purge $@
The following packages will be REMOVED:
  fonts-noto{p}  fonts-noto-core{pu} (D: fonts-noto)
0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 43.6 MB will be freed.
# dpkg -P fonts-noto
Removing fonts-noto (20201225-1) ...
# aptitude --with-recommends -s install fonts-noto
The following NEW packages will be installed:
  fonts-noto  fonts-noto-cjk{a} (D: fonts-noto-cjk-extra, R: fonts-noto) 
(fonts-noto R: fonts-noto-cjk)  fonts-noto-cjk-extra{a} (R: fonts-noto, S: 
fonts-noto-cjk) (fonts-noto R: fonts-noto-cjk-extra)
  fonts-noto-extra{a} (R: fonts-noto, S: fonts-noto-ui-extra, E: 
fonts-noto-unhinted) (fonts-noto R: fonts-noto-extra)
  fonts-noto-mono{a} (R: fonts-noto, E: fonts-noto-extra, E: 
fonts-noto-unhinted) (fonts-noto R: fonts-noto-mono)
  fonts-noto-ui-core{a} (R: fonts-noto, E: fonts-noto-ui-extra) (fonts-noto R: 
fonts-noto-ui-core)  fonts-noto-ui-extra{a} (R: fonts-noto) (fonts-noto R: 
fonts-noto-ui-extra)
  fonts-noto-unhinted{a} (R: fonts-noto) (fonts-noto R: fonts-noto-unhinted)
0 packages upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 273 MB/273 MB of archives. After unpacking 729 MB will be used.

Ah, finally.

Actually this is a bug: --with-recommends plus reinstall should pull
them in!

Bug#994507: O: gssproxy -- Privilege separation daemon for GSSAPI

[Robbie Harwood (frozencemetery)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu
Control: affects -1 src:gssproxy

I intend to orphan the gssproxy package.

The package description is:
 Applications can choose to use GSS-Proxy for GSSAPI credential management,
 which means that they will not have direct access to the credentials
 themselves.  GSSAPI operations are also offloaded to the gssproxy daemon,
 making it suitable for upcalls from the Kernel as well.
 .
 This package includes both the gssproxy daemon itself and the GSSAPI
 interposer layer for existing applications.

There's nothing particularly wrong with gssproxy, but I am no longer paid to
work on it.

It would help prospective maintainers to have good knowledge of GSSAPI and
NFS.

Be well,
--Robbie

Bug#994508: O: python-gssapi -- Python 3 interface to GSSAPI

[Robbie Harwood (frozencemetery)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu
Control: affects -1 src:python-gssapi

I intend to orphan the python-gssapi package.

The package description is:
 Python3 Bindings for GSSAPI.  These bindings are for both RFC 2743/2744 and
 many extensions.  They are native bindings produced using Cython.
 .
 Available extensions will vary based on what your GSSAPI implementation
 supports; see package documentation for a detailed list of what is available.

There's nothing particularly wrong with python-gssapi, but I am no longer paid
to work on it.

Large codebase churn is unexpected, though new features may be added by
upstream.

Be well,
--Robbie

Bug#994506: Don't hide real packages among the D: stuff!

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.8.13-3

It's just crazy to jumble these like this:

The following packages will be REMOVED:
  bubblewrap{pu} (D: libwebkit2gtk-4.0-37)  gstreamer1.0-plugins-base{pu} (D: 
gstreamer1.0-plugins-good, D: libwebkit2gtk-4.0-37)  
gstreamer1.0-plugins-good{pu} (D: libwebkit2gtk-4.0-37)
  libcdparanoia0{pu} (D: gstreamer1.0-plugins-base)  libharfbuzz-icu0{pu} (D: 
libwebkit2gtk-4.0-37)  libhyphen0{pu} (D: libwebkit2gtk-4.0-37)
  libjavascriptcoregtk-4.0-18{pu} (D: libwebkit2gtk-4.0-37, D: yelp)  
libmanette-0.2-0{pu} (D: libwebkit2gtk-4.0-37)  libshout3{pu} (D: 
gstreamer1.0-plugins-good)
  libtag1v5{pu} (D: gstreamer1.0-plugins-good)  libtag1v5-vanilla{pu} (D: 
libtag1v5)  libvisual-0.4-0{pu} (D: gstreamer1.0-plugins-base)
  libwebkit2gtk-4.0-37{ap} (D: bubblewrap, D: gstreamer1.0-plugins-base, D: 
gstreamer1.0-plugins-good, D: libharfbuzz-icu0, D: libhyphen0, D: 
libjavascriptcoregtk-4.0-18, D: libmanette-0.2-0, D: libwoff1, D: libwpe-1.0-1, 
D: libwpebackend-fdo-1.0-1, D: xdg-dbus-proxy)
  libwoff1{pu} (D: libwebkit2gtk-4.0-37)  libwpe-1.0-1{pu} (D: 
libwebkit2gtk-4.0-37, D: libwpebackend-fdo-1.0-1)  libwpebackend-fdo-1.0-1{p}  
libyelp0{ap} (D: libwebkit2gtk-4.0-37)
  lsb-release{pu} (D: python3-distro)  python3-distro{pu} (D: yelp)  
xdg-dbus-proxy{pu} (D: libwebkit2gtk-4.0-37)
  yelp{a} (D: libjavascriptcoregtk-4.0-18, D: libwebkit2gtk-4.0-37, D: 
libyelp0, D: python3-distro)


It's much better to put one package per line:


The following packages will be REMOVED:
  bubblewrap{pu} (D: libwebkit2gtk-4.0-37)
  gstreamer1.0-plugins-base{pu} (D: gstreamer1.0-plugins-good, D: 
libwebkit2gtk-4.0-37)
  gstreamer1.0-plugins-good{pu} (D: libwebkit2gtk-4.0-37)
  libcdparanoia0{pu} (D: gstreamer1.0-plugins-base)
  libharfbuzz-icu0{pu} (D: libwebkit2gtk-4.0-37)
  libhyphen0{pu} (D: libwebkit2gtk-4.0-37)
  libjavascriptcoregtk-4.0-18{pu} (D: libwebkit2gtk-4.0-37, D: yelp)
  libmanette-0.2-0{pu} (D: libwebkit2gtk-4.0-37)
  libshout3{pu} (D: gstreamer1.0-plugins-good)
  libtag1v5{pu} (D: gstreamer1.0-plugins-good)
  libtag1v5-vanilla{pu} (D: libtag1v5)
  libvisual-0.4-0{pu} (D: gstreamer1.0-plugins-base)
  libwebkit2gtk-4.0-37{ap} (D: bubblewrap, D: gstreamer1.0-plugins-base, D: 
gstreamer1.0-plugins-good, D: libharfbuzz-icu0, D: libhyphen0, D: 
libjavascriptcoregtk-4.0-18, D: libmanette-0.2-0, D: libwoff1, D: libwpe-1.0-1, 
D: libwpebackend-fdo-1.0-1, D: xdg-dbus-proxy)
  libwoff1{pu} (D: libwebkit2gtk-4.0-37)
  libwpe-1.0-1{pu} (D: libwebkit2gtk-4.0-37, D: libwpebackend-fdo-1.0-1)
  libwpebackend-fdo-1.0-1{p}
  libyelp0{ap} (D: libwebkit2gtk-4.0-37)
  lsb-release{pu} (D: python3-distro)
  python3-distro{pu} (D: yelp)
  xdg-dbus-proxy{pu} (D: libwebkit2gtk-4.0-37)
  yelp{a} (D: libjavascriptcoregtk-4.0-18, D: libwebkit2gtk-4.0-37, D: 
libyelp0, D: python3-distro)


So eight lines became 21.

Well yes, but those were eight dangerous lines, potentially hiding
packages we need to notice in the middle of those lines.

Yes, each one of your eight lines starts with a real package, just like
my 21 lines.

But your 8 lines **hides** real packages among the D: stuff!

Bug#994504: Don't just say "not a real package"

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.8.13-3
Severity: wishlist

$ aptitude show ttf-unifont
Package: ttf-unifont
State: not a real package
$ apt show ttf-unifont
Package: ttf-unifont
State: not a real package (virtual)

That's a little better.

Bug#994505: /usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.

[積丹尼 Dan Jacobson]

Package: gconf2-common
Version: 3.2.6-7

Seen on purge:

The following packages will be REMOVED:
  gconf2-common{p}
Removing gconf2-common (3.2.6-7) ...
Processing triggers for sgml-base (1.30) ...
Purging configuration files for gconf2-common (3.2.6-7) ...
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.

Bug#994503: Must Depend, not just Recommend

[積丹尼 Dan Jacobson]

Package: fonts-noto
Version: 20201225-1

For this package to work as intended, you need to make
Depends: fonts-noto-core
Recommends: fonts-noto-cjk, fonts-noto-cjk-extra, fonts-noto-color-emoji, 
fonts-noto-extra, fonts-noto-mono, fonts-noto-ui-core, fonts-noto-ui-extra, 
fonts-noto-unhinted
all Depends! No Recommends.

Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Anton Gladky]

Control: severity -1 important
Control: notfound -1 2:6.2.1+dfsg-2
Control: found -1 2:6.2.1+dfsg-1

Thanks for the bug report. We will fix it when CVE (if any) will be
assigned and upstream patch will be available.

Though, the integer overflows are not making the package unusable in most
cases.
Thus the severity is reduced.

Regards

Anton

Bug#994426: octave-sparsersb: flaky autopkgtest on ci.d.n armhf worker

[Michele Martone]

On 20210916@20:39, Paul Gevers wrote:
> Hi Michele,
> 
> On 16-09-2021 19:58, Michele Martone wrote:
> > You are (well, your CI is) building librsb with support for a limited 
> > threads 
> > count, but invoking it on a machine with lots of cores, without specifying
> > the limited threads count.
> 
> I don't understand what you're saying here. Is the autopkgtest building
> a binary that's unsuitable for it's own use and that fails? That would
> be a bug in the autopkgtest. However, if you're saying that the binaries
> as build in the archive are unsuitable for hosts with many cores, than I
> don't think the package is suitable for Debian as-is. In Debian we build
> once, and expect the binary to run sanely on any machine that meets the
> minimal requirements of that architecture. Debian doesn't (and never
> has) build binaries to match the host the binary is installed onto.
> Switching build parameters based on properties of the build host is
> considered a serious bug in Debian.
> 
> > So the behavior of librsb wrt this situation (it complains) is sane --
> > the user building it shall also know on how many threads to run it (and 
> > 160 won't make any sense for the next few years)..
> 
> I claim that for the package to be suitable for Debian, if this matters,
> it needs to be determined at run time, not at build time.
> 
> I think we agree that this host is extremely powerful.
It is.

> However, Debian
> packages are expected to behave, also on those hosts.

Librsb is a package for efficient multithreaded sparse algebra.
There is no contemporary CPU I'm aware where you can run efficient 
sparse algebra with 160 cores (memory bandwidth won't cope with that).
So any savvy user uses librsb with a number of threads which is much
less than the cores count.
With dense algebra the story is different -- there using all cores makes sense.

Anyway, your points are all sound, sure.
So I'll fix it in a way the CI will pass -- thanks for making me aware of all 
this.

And if you've specific questions, just reiterate.

Ciao, Michele

Bug#994502: llvm-toolchain-11: autopkgtest regression with CMake 3.19+

[Timo Röhling]

Package: src:llvm-toolchain-11
Version: 1:11.0.1-2
Tag: patch

Dear maintainers,

the new upstream release of CMake introduced a deprecation warning
if cmake_minimum_required() requests a minimum version below 2.8.12.
This makes the autopkgtest suite of llvm-toolchain-11 fail due to unexpected
stderr output.

Attached is a patch that bumps the minimum version to something
reasonably recent, i.e. the current oldoldstable version of CMake.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/tests/cmake-test b/debian/tests/cmake-test
index c3dcc504..c73feead 100755
--- a/debian/tests/cmake-test
+++ b/debian/tests/cmake-test
@@ -16,7 +16,7 @@ fi
 
 cd "$AUTOPKGTEST_TMP"
 cat < CMakeLists.txt
-cmake_minimum_required(VERSION 2.6.2)
+cmake_minimum_required(VERSION 3.7)
 project(cmake-test)
 find_package(LLVM 11.0.0 REQUIRED
   COMPONENTS


signature.asc
Description: PGP signature

Bug#994501: llvm-toolchain-9: autopkgtest regression with CMake 3.19+

[Timo Röhling]

Package: src:llvm-toolchain-9
Version: 1:9.0.1-16.1
Tag: patch

Dear maintainers,

the new upstream release of CMake introduced a deprecation warning
if cmake_minimum_required() requests a minimum version below 2.8.12.
This makes the autopkgtest suite of llvm-toolchain-9 fail due to unexpected
stderr output.

Attached is a patch that bumps the minimum version to something
reasonably recent, i.e. the current oldoldstable version of CMake.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/tests/cmake-test b/debian/tests/cmake-test
index 4e774f1f..c47c36e5 100755
--- a/debian/tests/cmake-test
+++ b/debian/tests/cmake-test
@@ -16,7 +16,7 @@ fi
 
 cd "$AUTOPKGTEST_TMP"
 cat < CMakeLists.txt
-cmake_minimum_required(VERSION 2.6.2)
+cmake_minimum_required(VERSION 3.7)
 project(cmake-test)
 find_package(LLVM 9.0.0 REQUIRED
   COMPONENTS


signature.asc
Description: PGP signature

Bug#994500: libsfml: autopkgtest regression with CMake 3.19+

[Timo Röhling]

Package: src:libsfml
Version: 2.5.1+dfsg-1
Tag: patch

Dear maintainer,

the new upstream release of CMake introduced a deprecation warning
if cmake_minimum_required() requests a minimum version below 2.8.12.
This makes the autopkgtest suite of libsfml fail due to unexpected
stderr output.

Attached is a patch that bumps the minimum version to something
reasonably recent, i.e. the current oldoldstable version of CMake.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/tests/CMakeLists.txt b/debian/tests/CMakeLists.txt
index 02c726b..2117d91 100644
--- a/debian/tests/CMakeLists.txt
+++ b/debian/tests/CMakeLists.txt
@@ -1,6 +1,6 @@
 # Test CMake project to ensure FindSFML.cmake works properly
 
-cmake_minimum_required(VERSION 2.8)
+cmake_minimum_required(VERSION 3.7)
 project(SFMLTest CXX)
 
 # Try to find SFML using CMake config file


signature.asc
Description: PGP signature

Bug#994499: libjsoncpp: autopkgtest regression with CMake 3.19+

[Timo Röhling]

Package: src:libjsoncpp
Version: 1.9.4-4
Tag: patch

Dear maintainer,

the new upstream release of CMake introduced a deprecation warning
if cmake_minimum_required() requests a minimum version below 2.8.12.
This makes the autopkgtest suite of libjsoncpp fail due to unexpected
stderr output.

Attached is a patch that bumps the minimum version to something
reasonably recent, i.e. the current oldoldstable version of CMake.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/tests/testsuite b/debian/tests/testsuite
index 78443d4..c5ebc2e 100644
--- a/debian/tests/testsuite
+++ b/debian/tests/testsuite
@@ -30,7 +30,7 @@ else
 fi
 
 cat < CMakeLists.txt
-cmake_minimum_required(VERSION 2.6.2)
+cmake_minimum_required(VERSION 3.7)
 project(jsoncpp_test)
 
 find_package(jsoncpp REQUIRED)


signature.asc
Description: PGP signature

Bug#994498: vim: CVE-2021-3778

[Salvatore Bonaccorso]

Source: vim
Version: 2:8.2.2434-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for vim.

CVE-2021-3778[0]:
| vim is vulnerable to Heap-based Buffer Overflow

Can you batch this one as well for the planned point release, please?

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3778
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3778
[1] https://huntr.dev/bounties/d9c17308-2c99-4f9f-a706-f7f72c24c273
[2] https://github.com/vim/vim/commit/65b605665997fad54ef39a93199e305af2fe4d7f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#994497: vim: CVE-2021-3796

[Salvatore Bonaccorso]

Source: vim
Version: 2:8.2.2434-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for vim.

CVE-2021-3796[0]:
| vim is vulnerable to Use After Free

James, maybe this can be batched as well with the planned point
release update.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3796
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3796
[1] https://huntr.dev/bounties/ab60b7f3-6fb1-4ac2-a4fa-4d592e08008d/
[2] https://github.com/vim/vim/commit/35a9a00afcb20897d462a766793ff45534810dc3 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#994496: glfw3: autopkgtest regression with CMake 3.19+

[Timo Röhling]

Package: src:glfw3
Version: 3.3.2-1
Tag: patch

Dear maintainers,

the new upstream release of CMake introduced a deprecation warning
if cmake_minimum_required() requests a minimum version below 2.8.12.
This makes the autopkgtest suite of libgit2 fail due to unexpected
stderr output.

Attached is a patch that bumps the minimum version to something
reasonably recent, i.e. the current oldoldstable version of CMake.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/tests/CMakeLists.txt b/debian/tests/CMakeLists.txt
index f3d2293..aaa9591 100644
--- a/debian/tests/CMakeLists.txt
+++ b/debian/tests/CMakeLists.txt
@@ -1,6 +1,6 @@
 # Test CMake project to ensure the cmake config files work properly
 
-cmake_minimum_required(VERSION 2.8)
+cmake_minimum_required(VERSION 3.7)
 project(Glfw3Test C)
 
 # Try to find glfw3


signature.asc
Description: PGP signature

Bug#994495: RFS: filezilla/3.55.1-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: filezilla
   Version : 3.55.1-1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : CC0-1.0, permissive, GPL-2+, MIT, BSD-like
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

  filezilla-common - Architecture independent files for filezilla
  filezilla - Full-featured graphical FTP/FTPS/SFTP client

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.55.1-1.dsc

Changes since the last upload:

 filezilla (3.55.1-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 3.55.1
   * Updated libfilezilla-dev versioned build-dep to 0.31.1 or greater

Note: I am skipping all versions that went to experimental during the bullseye 
freeze, as it causes
no harm.

Note: This needs to be processed when libfilezilla 0.32.0-1 clears the NEW 
queue.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#994426: octave-sparsersb: flaky autopkgtest on ci.d.n armhf worker

[Paul Gevers]

Hi Michele,

On 16-09-2021 19:58, Michele Martone wrote:
> You are (well, your CI is) building librsb with support for a limited threads 
> count, but invoking it on a machine with lots of cores, without specifying
> the limited threads count.

I don't understand what you're saying here. Is the autopkgtest building
a binary that's unsuitable for it's own use and that fails? That would
be a bug in the autopkgtest. However, if you're saying that the binaries
as build in the archive are unsuitable for hosts with many cores, than I
don't think the package is suitable for Debian as-is. In Debian we build
once, and expect the binary to run sanely on any machine that meets the
minimal requirements of that architecture. Debian doesn't (and never
has) build binaries to match the host the binary is installed onto.
Switching build parameters based on properties of the build host is
considered a serious bug in Debian.

> So the behavior of librsb wrt this situation (it complains) is sane --
> the user building it shall also know on how many threads to run it (and 
> 160 won't make any sense for the next few years)..

I claim that for the package to be suitable for Debian, if this matters,
it needs to be determined at run time, not at build time.

I think we agree that this host is extremely powerful. However, Debian
packages are expected to behave, also on those hosts.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994494: libgit2: autopkgtest regression with CMake 3.19+

[Timo Röhling]

Package: src:libgit2
Version: 1.1.0+dfsg.1-4
Tag: patch

Dear maintainers,

the new upstream release of CMake introduced a deprecation warning
if cmake_minimum_required() requests a minimum version below 2.8.12.
This makes the autopkgtest suite of libgit2 fail due to unexpected
stderr output.

Attached is a patch that bumps the minimum version to something
reasonably recent, i.e. the current oldoldstable version of CMake.

Cheers
Timo

PS: Hi Utkarsh :)

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/tests/CMakeLists.txt b/debian/tests/CMakeLists.txt
index 24e8efe2e..46241b779 100644
--- a/debian/tests/CMakeLists.txt
+++ b/debian/tests/CMakeLists.txt
@@ -1,4 +1,4 @@
-CMAKE_MINIMUM_REQUIRED (VERSION 2.8)
+CMAKE_MINIMUM_REQUIRED (VERSION 3.7)
 PROJECT (libgit2_test)
  
 ADD_EXECUTABLE (libgit2_test libgit2_test.c)


signature.asc
Description: PGP signature

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Lucas Nussbaum]

Hi,

While I was starting to prepare a non-maintainer upload to re-introduce
the patch that removed --will-cite, I realized that the patch was
already re-introduced in version 20210822+ds-2 (see
https://salsa.debian.org/med-team/parallel/-/blob/master/debian/patches/remove-overreaching-citation-request.patch).

As the patch shows, the "please cite" wording is still mentioned in
--help and in the manpage's AUTHOR section (without the 1 EUR mention).

Also, --help points to the Zenodo for GNU Parallel 20210822 ('Kabul'),
while the manpage points to the USENIX ;login: article, but that
inconsistency is also present in the original version.

So, everything looks fine from my POV.

Lucas

Bug#994458: ITP: anymarkup -- Parse or serialize any markup format in Python

[Sam Hartman]

> "John" == John Paul Adrian Glaubitz  writes:

Description : Parse or serialize any
John> markup format in Python

John> Parse or serialize any markup. Currently supports INI, JSON,
John> JSON5, TOML, XML and YAML.


I'd find it helpful if the description were improved to indicate that
this is for object serialization languages.
When I ran across the one line description I was expecting html,
markdown, rest--a pandoc competitor of some kind.

--Sam

Bug#940096: gajim-omemo on update to debian 10 silently disabled encryption

[Stefan]

Control: forwarded -1 https://dev.gajim.org/gajim/gajim-plugins/-/issues/319

I think it's https://dev.gajim.org/gajim/gajim-plugins/-/issues/319
which you are looking for.

-- 
Stefan

Bug#993700: what equivalent for which -a?

[Clint Adams]

On Sun, Sep 05, 2021 at 10:05:12AM +1000, pe...@chubb.wattle.id.au wrote:
> As a sysadmin, it's one of the first things I ask someone to do when
> helping them, to make sure that the system version of a command (they
> say isn't working) is installed, and that their PATH uses it.

Which interactive shell is the user in?

mksh:
 * which -a

zsh:
 * which -a
 * whence -a
 * type -a
 * where

fish:
 * type -a

For csh and tcsh, this obviously wasn't working in the first place, as
the builtin which commands don't understand an `-a` switch.

For other shells, you could install GNU which or any other alternative
once they pass through the NEW queue.

However, this functionality does not belong in the Essential set.

Bug#974740: gajim-omemo: Messages not appearing from partner

[Stefan]

Keep in mind that the Client "Pix-Art Messanger" doesn't exists
anymore. "Pix-Art Messanger" has been renamed to blabber.im - I
think ~ November 2020.

1) Make sure you buddy is using the latest version of Conversations or
Blabber on Andorid
2) You may already got 2.7.13-1 of the gajim-omemo plugin?

ejabberd logfile may not help. The most part of OMEMO is on
client-side. With a current version of ejabberd the PEP and setup of
access model should be fine.

-- 
Stefan

Bug#994426: octave-sparsersb: flaky autopkgtest on ci.d.n armhf worker

[Michele Martone]

On 20210916@13:58, Paul Gevers wrote:
> Hi Michele,
> 
> On 16-09-2021 12:26, Michele Martone wrote:
> > I suggest to set OMP_NUM_THREADS to something small before tests -- say,
> > min(nproc,4) -- for all purposes of testing librsb and octave-sparsersb.
> > For architectural reasons, using all the cores (e.g.160) is nonsense here.
> > Is that okay?
> 
> That's up to you. I don't really care what you do to make the behavior
> sane. (For avoidance of doubt, I mean the test should do this itself,
> we're not going to set non-default variables on our infrastructure).
You are (well, your CI is) building librsb with support for a limited threads 
count, but invoking it on a machine with lots of cores, without specifying
the limited threads count.

So the behavior of librsb wrt this situation (it complains) is sane --
the user building it shall also know on how many threads to run it (and 
160 won't make any sense for the next few years)..

> > Would be great if you could try the tarball I linked at the beginning of
> > the email -- I'm using some 'unsigned' prints -- that shall help a bit
> > (one bit ;-) .
> 
> That's too much work for me (I now just kick of a test of the package in
> the archive). I suggest you just upload fixed packages.
Let's see if I get access to that exotic machine, otherwise it's not trivial 
to fix all potential surprises..

Bug#994483: meson: import('python').find_installation() requires python3-distutils

[Andrea Pappacoda]

Package: meson
Version: 0.59.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

import('python').find_installation() requires the distutils.core Python module,
found in the python3-distutils package.

Meson should depend on that package as well.

See upstream bug
https://github.com/mesonbuild/meson/issues/4267#issuecomment-920919273


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

Kernel: Linux 5.10.46 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 meson depends on:
ii  ninja-build1.10.1-1
ii  python33.9.2-3
ii  python3-pkg-resources  52.0.0-4

Versions of packages meson recommends:
ii  dpkg-dev  1.20.9

meson suggests no packages.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYUNM1hQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRD/yQfijUdG7feVAP0QKfO72AAh8fobXGE1ei32RlP6dYRl
qUI2iO+t8015ugEAsXLBJ73u9Z5xQBrdZF1DQNAA6vexhb/TT0R90lN1tQk=
=bp3q
-END PGP SIGNATURE-

Bug#994493: RFS: libfilezilla/0.32.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libfilezilla
   Version : 0.32.0-1
   Upstream Author : Tim Kosse 
 * URL : https://lib.filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/libfilezilla
   Section : libs

It builds those binary packages:

  libfilezilla19 - build high-performing platform-independent programs (runtime 
lib)
  libfilezilla-dev - build high-performing platform-independent programs 
(development)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.32.0-1.dsc

Changes since the last upload:

 libfilezilla (0.32.0-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 0.32.0
   * Soname bump rename package to libfilezilla19


Note: I am skipping all versions that went to experimental during the bullseye 
freeze, as it causes
no harm.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#993604: bullseye-pu: package freeradius/3.0.21+dfsg-2.2+deb11u1

[Bernhard Schmidt]

Control: tag -1 - moreinfo

Hi,
> On Fri, Sep 03, 2021 at 05:07:56PM +0200, Bernhard Schmidt wrote:
>> [ Reason ]
>> This update will fix two bugs in the bullseye package by cherry-picking
>> two upstream commits
> 
> #992207 clearly affects bullseye but the BTS doesn't show it as found -
> fixed that.
> 
> Please go ahead, and remove the moreinfo tag from this bug when uploaded.

Done. Upload has been accepted this afternoon.

Thanks,
Bernhard

Bug#994182: headset functionality broken after recent update

[Felipe Sateler]

On Wed, Sep 15, 2021 at 2:04 PM debian-bugs  wrote:

>  > Hi,
>  >
>  > I'm not sure what to do about this issue.
>
> Well, to me it seems pulseaudio 15 should not not be promoted to testing
> until this is sorted out -- given the current boom in video conferencing
> due to working from home, a suddenly broken headset will cause a lot of
> trouble. (Thankfully, I did not have to work this week so I could spend
> three days figuring out what's wrong, couldn't afford this in a work week.)
>
> AFAIU the issue is caused by a change in the btusb kernel driver and
> thus affects most bluetooth devices connected via USB, fixed only in 5.13.


I don't know about most. Mine did not have this problem.


>

So either the fix needs to be back-ported to the current kernel or
> pulseaudio needs to include the workaround outlined in the linked report.
> At the very, very least users should be warned about a potential
> breakage and how to work around that.
>

By I don't know what to do, I mean that this is strictly speaking not a bug
in pulseaudio. The workaround you applied just disables the relevant
functionality.

-- 

Saludos,
Felipe Sateler

Bug#954093: desktop-base: Integration with KDE Plasma on Debian 11 no longer works

[Oliver Freyermuth]

Hi,

after a quick investigation, I found that even for an initial profile (i.e. 
purged before),
the "Image" for [Wallpaper][org.kde.image][General] is already set to the 
default image of the utilized theme
before any Plasma script is actually executed.
So the if-condition:
 if (!d[i].readConfig('Image')) {
will never be true.

Cheers,
Oliver

Bug#994445: Libreoffice suggests wrong KDE package

[Rene Engelhard]

Hi,

Am 16.09.21 um 11:03 schrieb Rene Engelhard:
> Though admittedly -plasma misses a Recommends: on libreoffice-kde5:
> rene@frodo:~$ apt-cache show libreoffice-plasma | grep Recomm
> rene@frodo:~$ apt-cache show libreoffice-gnome | grep Recomm
> Recommends: libreoffice-style-elementary, libreoffice-gtk3
>
>
> Will add  that one.

Obviously I meant -kf5 :)

(cf.
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/8aa042f967976eeb843e68e3ce8ec02d798036a6)

Regards,


Rene

Bug#994492: sg3-utils-udev should not require initramfs-tools[-core]

[Michael Tokarev]

Package: sg3-utils-udev
Version: 1.45-1
Severity: minor

Starting bullseye, sg3-utils-udev requires (depends) on initramfs-tools[-core].
But it does not *use* any of the functionality of this package, except of
_extending_ initramfs-tools.

This dependency forces us to invent more and more dummy versions of
initramfs packages in order just to use core system functionality
(eg multipath-tools now depends on sg3-utils-udev which can not be
installed without initramfs-tools which breaks (replaces) our boot
infrastructure).

For now we installed an empty initramfs-tools-core-dummy package just
to be able to use multipath-tools and not break our systems.

Please note there's no mention of this new dependency in the changelog,
but it makes major issue for ones who does not use initramfs-tools.

Thank you!

Bug#994488: alglib: autopkgtest regression with CMake 3.19+

[Anton Gladky]

Hi Timo,

thanks for the patch! Yes, feel free to upload it. Please update git and
tag a new upload.

Regards

Anton


Am Do., 16. Sept. 2021 um 18:15 Uhr schrieb Timo Röhling <
roehl...@debian.org>:

> Package: src:alglib
> Version: 3.17.0-2
> Tag: patch
>
> Dear maintainer,
>
> the alglib autopkgtest suite fails due to a deprecation warning with
> CMake 3.19+ if cmake_minimum_required() requests a version earlier
> than 2.8.12. The attached patch bumps the minimum version in
> debian/tests to 3.7, which I picked because it is the CMake version
> in oldoldstable.
>
> As I am a member of the Science Team, I can also fix and upload this
> for you if you are starved for developer time; just give me the
> green light.
>
> Cheers
> Timo
>
> --
> ⢀⣴⠾⠻⢶⣦⠀   ╭╮
> ⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
> ⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
> ⠈⠳⣄   ╰╯
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
>

Bug#994174: mirror listing update for debian.astra.in.ua

[tech]

Ok. I'll move all items to the main directory then.

On Thu, Sep 16, 2021 at 7:59 PM Julien Cristau  wrote:
>
> Thanks.  BTW I notice on rsync the mirror is at
> debian.astra.in.ua::debian/debian/ instead of
> debian.astra.in.ua::debian/
>
> Cheers,
> Julien
>
> On Thu, Sep 16, 2021 at 07:49:22PM +0300, tech wrote:
> > Synced well.
> >
> > On Thu, Sep 16, 2021 at 7:41 PM tech  wrote:
> > >
> > > Ok, thank you.
> > > Done.
> > >
> > > On Thu, Sep 16, 2021 at 7:37 PM Julien Cristau  
> > > wrote:
> > > >
> > > > On Thu, Sep 16, 2021 at 07:18:27PM +0300, tech wrote:
> > > > > Hello.
> > > > > What does it mean ?
> > > > > What do we need to change ?
> > > > >
> > > > It seems your ftpsync.conf uses RSYNC_HOST=ftp.de.debian.org, which is
> > > > not appropriate (we may decide to point the ftp.de.debian.org name at a
> > > > different host that does not offer rsync).  Please use
> > > > debian.inf.tu-dresden.de directly instead.
> > > >
> > > > Cheers,
> > > > Julien
> > > >
> > > > > On Thu, Sep 16, 2021 at 7:07 PM Julien Cristau  
> > > > > wrote:
> > > > > >
> > > > > > Control: tag -1 moreinfo
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I was checking your mirror for inclusion and noticed the following:
> > > > > >
> > > > > > o we recommend mirrors not sync directly from service aliases such 
> > > > > > as
> > > > > >   ftp..debian.org (only http is guaranteed to be available at
> > > > > >   ftp..d.o sites).  Maybe change your config to sync from
> > > > > >   the site currently backing the ftp..debian.org service you 
> > > > > > sync
> > > > > >   from?
> > > > > >
> > > > > > Please let us know when that is adjusted.
> > > > > >
> > > > > > Cheers,
> > > > > > Julien
> > > > > >
> > > > > > On Mon, Sep 13, 2021 at 08:22:00AM +, Astra ISP wrote:
> > > > > > > Package: mirrors
> > > > > > > Severity: minor
> > > > > > > User: mirr...@packages.debian.org
> > > > > > > Usertags: mirror-list
> > > > > > >
> > > > > > > Submission-Type: update
> > > > > > > Site: debian.astra.in.ua
> > > > > > > Type: leaf
> > > > > > > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> > > > > > > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el 
> > > > > > > s390x
> > > > > > > Archive-http: /debian/
> > > > > > > Archive-rsync: debian/
> > > > > > > Maintainer: Astra ISP 
> > > > > > > Country: UA Ukraine
> > > > > > > Location: Lviv
> > > > > > > Sponsor: Astra ISP https://astra.in.ua/
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Trace Url: http://debian.astra.in.ua/debian/project/trace/
> > > > > > > Trace Url: 
> > > > > > > http://debian.astra.in.ua/debian/project/trace/ftp-master.debian.org
> > > > > > > Trace Url: 
> > > > > > > http://debian.astra.in.ua/debian/project/trace/debian.astra.in.ua
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > url: https://astra.in.ua/
> > > > > mobile: +38(063)-321-57-50
> > > > > email: n...@astra.in.ua
> > > > >
> > >
> > >
> > >
> > > --
> > > url: https://astra.in.ua/
> > > mobile: +38(063)-321-57-50
> > > email: n...@astra.in.ua
> >
> >
> >
> > --
> > url: https://astra.in.ua/
> > mobile: +38(063)-321-57-50
> > email: n...@astra.in.ua
> >



-- 
url: https://astra.in.ua/
mobile: +38(063)-321-57-50
email: n...@astra.in.ua

Bug#982194: choose-mirror: Rename mirror.netcologne.de to debian.netcologne.de

[Julien Cristau]

On Thu, Aug 19, 2021 at 04:53:19PM +0200, Julien Cristau wrote:
> Control: reassign -1 mirrors
> Control: tag -1 moreinfo
> 
> On Sun, Feb 07, 2021 at 11:40:32AM +0100, Roland Rosenfeld wrote:
> > I noticed the following change in Git commit d51997a5:
> > 
> > -Site: debian.netcologne.de
> > +Site: mirror.netcologne.de
> > +Alias: debian.netcologne.de
> > 
> > This wasn't a very good idea, since I'd like to train users to use
> > debian.netcologne.de as their mirror name.  So I can change the CNAME
> > debian.netcologne.de pointing somewhere else (for example to
> > mirror3.netcologne.de or ftp.de.debian.org) on maintenance or
> > emergency.
> > 
> > This said, mirror.netcologne.de shouldn't be used directly as a debian
> > mirror.
> > 
> > It would be great if you could undo the above change at least for
> > bullseye.
> > 
> That would need a change on the site, for monitoring we require the
> mirror name to match its trace file, and currently that is
> http://mirror.netcologne.de/debian/project/trace/mirror.netcologne.de
> 
> If you update MIRRORNAME in ftpsync.conf and let us know we can update
> the mirror list to match.
> 
Looks like that happened at some point in the past, so I'll update the
mirror list.

FWIW, there's a couple of things our scripts complain about still:

o The tracefile at
  http://debian.netcologne.de/debian/project/trace/debian.netcologne.de
  is missing some required information.

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

o The tracefile
  http://debian.netcologne.de/debian/project/trace/debian.netcologne.de
  suggests that the ftpsync version you are using is very old.  Please upgrade.

  Using a modern ftpsync ensures updates are done in the correct order
  so apt clients don't get confused.   In particular, it processes
  translations, contents, and more files that have been added to the
  archive in recent years in the correct stage.  It also should produce
  trace files that contain more information that is useful for us and helps
  downstream mirrors sync better.

  http://debian.netcologne.de/debian/project/ftpsync/ftpsync-current.tar.gz

Cheers,
Julien

Bug#994174: mirror listing update for debian.astra.in.ua

[Julien Cristau]

Thanks.  BTW I notice on rsync the mirror is at
debian.astra.in.ua::debian/debian/ instead of
debian.astra.in.ua::debian/

Cheers,
Julien

On Thu, Sep 16, 2021 at 07:49:22PM +0300, tech wrote:
> Synced well.
> 
> On Thu, Sep 16, 2021 at 7:41 PM tech  wrote:
> >
> > Ok, thank you.
> > Done.
> >
> > On Thu, Sep 16, 2021 at 7:37 PM Julien Cristau  wrote:
> > >
> > > On Thu, Sep 16, 2021 at 07:18:27PM +0300, tech wrote:
> > > > Hello.
> > > > What does it mean ?
> > > > What do we need to change ?
> > > >
> > > It seems your ftpsync.conf uses RSYNC_HOST=ftp.de.debian.org, which is
> > > not appropriate (we may decide to point the ftp.de.debian.org name at a
> > > different host that does not offer rsync).  Please use
> > > debian.inf.tu-dresden.de directly instead.
> > >
> > > Cheers,
> > > Julien
> > >
> > > > On Thu, Sep 16, 2021 at 7:07 PM Julien Cristau  
> > > > wrote:
> > > > >
> > > > > Control: tag -1 moreinfo
> > > > >
> > > > > Hi,
> > > > >
> > > > > I was checking your mirror for inclusion and noticed the following:
> > > > >
> > > > > o we recommend mirrors not sync directly from service aliases such as
> > > > >   ftp..debian.org (only http is guaranteed to be available at
> > > > >   ftp..d.o sites).  Maybe change your config to sync from
> > > > >   the site currently backing the ftp..debian.org service you sync
> > > > >   from?
> > > > >
> > > > > Please let us know when that is adjusted.
> > > > >
> > > > > Cheers,
> > > > > Julien
> > > > >
> > > > > On Mon, Sep 13, 2021 at 08:22:00AM +, Astra ISP wrote:
> > > > > > Package: mirrors
> > > > > > Severity: minor
> > > > > > User: mirr...@packages.debian.org
> > > > > > Usertags: mirror-list
> > > > > >
> > > > > > Submission-Type: update
> > > > > > Site: debian.astra.in.ua
> > > > > > Type: leaf
> > > > > > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> > > > > > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el 
> > > > > > s390x
> > > > > > Archive-http: /debian/
> > > > > > Archive-rsync: debian/
> > > > > > Maintainer: Astra ISP 
> > > > > > Country: UA Ukraine
> > > > > > Location: Lviv
> > > > > > Sponsor: Astra ISP https://astra.in.ua/
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Trace Url: http://debian.astra.in.ua/debian/project/trace/
> > > > > > Trace Url: 
> > > > > > http://debian.astra.in.ua/debian/project/trace/ftp-master.debian.org
> > > > > > Trace Url: 
> > > > > > http://debian.astra.in.ua/debian/project/trace/debian.astra.in.ua
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > url: https://astra.in.ua/
> > > > mobile: +38(063)-321-57-50
> > > > email: n...@astra.in.ua
> > > >
> >
> >
> >
> > --
> > url: https://astra.in.ua/
> > mobile: +38(063)-321-57-50
> > email: n...@astra.in.ua
> 
> 
> 
> -- 
> url: https://astra.in.ua/
> mobile: +38(063)-321-57-50
> email: n...@astra.in.ua
> 

Bug#994491: dmarc-cat: hostnames are mixed (wrong result)

[Noury]

Package: dmarc-cat
Version: 0.14.0-1+b5
Severity: important

Result is wrong.
for the xml following file
- begin --


  
google.com
noreply-dmarc-supp...@google.com

https://support.google.com/a/answer/2466580
507151472244287070

  1631664000
  1631750399

  
  
dagami.org
r
r
none
none
100
  
  

  23.95.164.22
  1
  
none
pass
fail
  


  dagami.org


  
dagami.org
pass
smtp.dagami.org
  
  
dagami.org
fail
  

  
  

  23.94.105.214
  18
  
none
pass
pass
  


  dagami.org


  
dagami.org
pass
smtp.dagami.org
  
  
dagami.org
pass
  

  

- end --

Displayed result is:
- begin --
dmarc-cat 0.14.0,parallel/j3 by Ollivier Robert

Reporting by: google.com — noreply-dmarc-supp...@google.com
From 2021-09-15 02:00:00 +0200 CEST to 2021-09-16 01:59:59 +0200 CEST

Domain: dagami.org
Policy: p=none; dkim=r; spf=r

Reports(2):
IP  Count   From   RFrom  RDKIM   RSPF
ny.dagami.org.  18  dagami.org dagami.org passpass
colibri.dagami.org. 1   dagami.org dagami.org passfail
- end --

It should be 18 for colibri.dagami.org
and 1 for ny.dagami.org
It's the contrary.

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

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

Versions of packages dmarc-cat depends on:
ii  libc6   2.31-17
ii  libgpgme11  1.16.0-1

dmarc-cat recommends no packages.

dmarc-cat suggests no packages.

-- no debconf information

Bug#994174: mirror listing update for debian.astra.in.ua

[tech]

Synced well.

On Thu, Sep 16, 2021 at 7:41 PM tech  wrote:
>
> Ok, thank you.
> Done.
>
> On Thu, Sep 16, 2021 at 7:37 PM Julien Cristau  wrote:
> >
> > On Thu, Sep 16, 2021 at 07:18:27PM +0300, tech wrote:
> > > Hello.
> > > What does it mean ?
> > > What do we need to change ?
> > >
> > It seems your ftpsync.conf uses RSYNC_HOST=ftp.de.debian.org, which is
> > not appropriate (we may decide to point the ftp.de.debian.org name at a
> > different host that does not offer rsync).  Please use
> > debian.inf.tu-dresden.de directly instead.
> >
> > Cheers,
> > Julien
> >
> > > On Thu, Sep 16, 2021 at 7:07 PM Julien Cristau  
> > > wrote:
> > > >
> > > > Control: tag -1 moreinfo
> > > >
> > > > Hi,
> > > >
> > > > I was checking your mirror for inclusion and noticed the following:
> > > >
> > > > o we recommend mirrors not sync directly from service aliases such as
> > > >   ftp..debian.org (only http is guaranteed to be available at
> > > >   ftp..d.o sites).  Maybe change your config to sync from
> > > >   the site currently backing the ftp..debian.org service you sync
> > > >   from?
> > > >
> > > > Please let us know when that is adjusted.
> > > >
> > > > Cheers,
> > > > Julien
> > > >
> > > > On Mon, Sep 13, 2021 at 08:22:00AM +, Astra ISP wrote:
> > > > > Package: mirrors
> > > > > Severity: minor
> > > > > User: mirr...@packages.debian.org
> > > > > Usertags: mirror-list
> > > > >
> > > > > Submission-Type: update
> > > > > Site: debian.astra.in.ua
> > > > > Type: leaf
> > > > > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> > > > > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el 
> > > > > s390x
> > > > > Archive-http: /debian/
> > > > > Archive-rsync: debian/
> > > > > Maintainer: Astra ISP 
> > > > > Country: UA Ukraine
> > > > > Location: Lviv
> > > > > Sponsor: Astra ISP https://astra.in.ua/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Trace Url: http://debian.astra.in.ua/debian/project/trace/
> > > > > Trace Url: 
> > > > > http://debian.astra.in.ua/debian/project/trace/ftp-master.debian.org
> > > > > Trace Url: 
> > > > > http://debian.astra.in.ua/debian/project/trace/debian.astra.in.ua
> > > >
> > > >
> > >
> > >
> > > --
> > > url: https://astra.in.ua/
> > > mobile: +38(063)-321-57-50
> > > email: n...@astra.in.ua
> > >
>
>
>
> --
> url: https://astra.in.ua/
> mobile: +38(063)-321-57-50
> email: n...@astra.in.ua



-- 
url: https://astra.in.ua/
mobile: +38(063)-321-57-50
email: n...@astra.in.ua

Bug#994174: mirror listing update for debian.astra.in.ua

[tech]

Ok, thank you.
Done.

On Thu, Sep 16, 2021 at 7:37 PM Julien Cristau  wrote:
>
> On Thu, Sep 16, 2021 at 07:18:27PM +0300, tech wrote:
> > Hello.
> > What does it mean ?
> > What do we need to change ?
> >
> It seems your ftpsync.conf uses RSYNC_HOST=ftp.de.debian.org, which is
> not appropriate (we may decide to point the ftp.de.debian.org name at a
> different host that does not offer rsync).  Please use
> debian.inf.tu-dresden.de directly instead.
>
> Cheers,
> Julien
>
> > On Thu, Sep 16, 2021 at 7:07 PM Julien Cristau  wrote:
> > >
> > > Control: tag -1 moreinfo
> > >
> > > Hi,
> > >
> > > I was checking your mirror for inclusion and noticed the following:
> > >
> > > o we recommend mirrors not sync directly from service aliases such as
> > >   ftp..debian.org (only http is guaranteed to be available at
> > >   ftp..d.o sites).  Maybe change your config to sync from
> > >   the site currently backing the ftp..debian.org service you sync
> > >   from?
> > >
> > > Please let us know when that is adjusted.
> > >
> > > Cheers,
> > > Julien
> > >
> > > On Mon, Sep 13, 2021 at 08:22:00AM +, Astra ISP wrote:
> > > > Package: mirrors
> > > > Severity: minor
> > > > User: mirr...@packages.debian.org
> > > > Usertags: mirror-list
> > > >
> > > > Submission-Type: update
> > > > Site: debian.astra.in.ua
> > > > Type: leaf
> > > > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> > > > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> > > > Archive-http: /debian/
> > > > Archive-rsync: debian/
> > > > Maintainer: Astra ISP 
> > > > Country: UA Ukraine
> > > > Location: Lviv
> > > > Sponsor: Astra ISP https://astra.in.ua/
> > > >
> > > >
> > > >
> > > >
> > > > Trace Url: http://debian.astra.in.ua/debian/project/trace/
> > > > Trace Url: 
> > > > http://debian.astra.in.ua/debian/project/trace/ftp-master.debian.org
> > > > Trace Url: 
> > > > http://debian.astra.in.ua/debian/project/trace/debian.astra.in.ua
> > >
> > >
> >
> >
> > --
> > url: https://astra.in.ua/
> > mobile: +38(063)-321-57-50
> > email: n...@astra.in.ua
> >



-- 
url: https://astra.in.ua/
mobile: +38(063)-321-57-50
email: n...@astra.in.ua

Bug#994174: mirror listing update for debian.astra.in.ua

[Julien Cristau]

On Thu, Sep 16, 2021 at 07:18:27PM +0300, tech wrote:
> Hello.
> What does it mean ?
> What do we need to change ?
> 
It seems your ftpsync.conf uses RSYNC_HOST=ftp.de.debian.org, which is
not appropriate (we may decide to point the ftp.de.debian.org name at a
different host that does not offer rsync).  Please use
debian.inf.tu-dresden.de directly instead.

Cheers,
Julien

> On Thu, Sep 16, 2021 at 7:07 PM Julien Cristau  wrote:
> >
> > Control: tag -1 moreinfo
> >
> > Hi,
> >
> > I was checking your mirror for inclusion and noticed the following:
> >
> > o we recommend mirrors not sync directly from service aliases such as
> >   ftp..debian.org (only http is guaranteed to be available at
> >   ftp..d.o sites).  Maybe change your config to sync from
> >   the site currently backing the ftp..debian.org service you sync
> >   from?
> >
> > Please let us know when that is adjusted.
> >
> > Cheers,
> > Julien
> >
> > On Mon, Sep 13, 2021 at 08:22:00AM +, Astra ISP wrote:
> > > Package: mirrors
> > > Severity: minor
> > > User: mirr...@packages.debian.org
> > > Usertags: mirror-list
> > >
> > > Submission-Type: update
> > > Site: debian.astra.in.ua
> > > Type: leaf
> > > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> > > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> > > Archive-http: /debian/
> > > Archive-rsync: debian/
> > > Maintainer: Astra ISP 
> > > Country: UA Ukraine
> > > Location: Lviv
> > > Sponsor: Astra ISP https://astra.in.ua/
> > >
> > >
> > >
> > >
> > > Trace Url: http://debian.astra.in.ua/debian/project/trace/
> > > Trace Url: 
> > > http://debian.astra.in.ua/debian/project/trace/ftp-master.debian.org
> > > Trace Url: 
> > > http://debian.astra.in.ua/debian/project/trace/debian.astra.in.ua
> >
> >
> 
> 
> -- 
> url: https://astra.in.ua/
> mobile: +38(063)-321-57-50
> email: n...@astra.in.ua
> 

Bug#994488: alglib: autopkgtest regression with CMake 3.19+

[Timo Röhling]

On Thu, 16 Sep 2021 18:11:23 +0200 Timo =?utf-8?Q?R=C3=B6hling?= 
 wrote:

Package: src:alglib
Version: 3.17.0-2
Tag: patch

Dear maintainer,

the alglib autopkgtest suite fails due to a deprecation warning with
CMake 3.19+ if cmake_minimum_required() requests a version earlier
than 2.8.12. The attached patch bumps the minimum version in
debian/tests to 3.7, which I picked because it is the CMake version
in oldoldstable.

As I am a member of the Science Team, I can also fix and upload this
for you if you are starved for developer time; just give me the
green light.

Following up on the discussion on debian-science@, I'll go ahead and
fix it directly, no action required on your part. Sorry for the
noise.


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


signature.asc
Description: PGP signature

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

[Daniel Kahn Gillmor]

Control: affects 968525 + libgpg-error-dev

On Thu 2021-08-19 20:52:16 -0400, Daniel Kahn Gillmor wrote:
> Control: affects 968525 - libgpg-error-dev
> Control: retitle 968525 lintian: breakout-link reported for 
> /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks
>
> On Thu 2021-08-19 19:20:16 -0400, Daniel Kahn Gillmor wrote:
>> I see the same issue in libgpg-error-dev with lintian 2.104.0.  If I try
>> to fix it in libgpg-error-dev (i.e. by moving the symlink into lib/
>> instead of usr/lib),
>
> hm, on further experimentation, i now take it back -- this warning
> appeared in libgpg-error-dev because debian/rules in libgpg-error source
> was manually adding an additional breakout-link.  In particular, i think
> for libgpg-error-dev the problem was that there was a link in lib/ that
> was pointing to usr/lib/ (the other way around from what Aurelian
> reported).
>
> After removing the override_dh_link target in libgpg-error, lintian
> doesn't complain about either breakout-link or
> lacks-unversioned-link-to-shared-library

i'm now more confused than ever about this situation.  Apparently,
clearing this lintian warning in libgpg-error introduced #992573 (a
grave bug) despite my testing it locally and it seeming to work (perhaps
my test was on a merged-/usr machine?  i don't have the artifacts from
that test any longer to confirm).

The fact that silencing this warning in the expected way ended up
injecting a grave bug seems problematic.  The test probably needs more
thought and fine-tuning.

--dkg


signature.asc
Description: PGP signature

Bug#993439: mirror submission for mirror.23m.com

[Julien Cristau]

Hi,

thanks for the submission, I'll replace the 23media.de entry.  One note
though:

o The tracefile at
  http://mirror.23m.com/debian/project/trace/mirror.23m.com
  is missing some required information.

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

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

Cheers,
Julien

On Wed, Sep 01, 2021 at 12:17:08PM +, 23M Tech wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirror.23m.com
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: 23M Tech 
> Country: DE Germany
> Location: Frankfurt am Main
> Sponsor: 23M https://23m.com
> 
> 
> 
> 
> Trace Url: http://mirror.23m.com/debian/project/trace/
> Trace Url: http://mirror.23m.com/debian/project/trace/ftp-master.debian.org
> Trace Url: http://mirror.23m.com/debian/project/trace/mirror.23m.com
> 

Bug#994490: bullseye-pu: package node-set-value/3.0.1-2+deb11u1

[Yadd]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org

[ Reason ]
node-set-value is vulnerable to prototype pollution (#994448, CVE-2021-23440)

[ Impact ]
Medium vulnerability

[ Tests ]
New test added, inspired from PoC

[ Risks ]
No risk, patch itself is trivial

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
New check to verify key

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index a836bdb..1ae7498 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-set-value (3.0.1-2+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Fix prototype pollution (Closes: #994448, CVE-2021-23440)
+  * Add test for CVE-2021-23440
+
+ -- Yadd   Thu, 16 Sep 2021 18:17:19 +0200
+
 node-set-value (3.0.1-2) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2021-23440.patch 
b/debian/patches/CVE-2021-23440.patch
new file mode 100644
index 000..55a96f3
--- /dev/null
+++ b/debian/patches/CVE-2021-23440.patch
@@ -0,0 +1,20 @@
+Description: fix prototype pollution
+ Inspired from https://github.com/jonschlinkert/set-value/pull/33/files
+Author: Yadd 
+Bug: https://snyk.io/vuln/SNYK-JS-SETVALUE-1540541
+Bug-Debian: https://bugs.debian.org/994448
+Forwarded: not-needed
+Last-Update: 2021-09-16
+
+--- a/index.js
 b/index.js
+@@ -99,6 +99,9 @@
+ }
+ 
+ function isValidKey(key) {
++  if (typeof key !== 'string' && typeof key !== 'number') {
++key = String(key)
++  }
+   return key !== '__proto__' && key !== 'constructor' && key !== 'prototype';
+ }
+ 
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..22df165
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2021-23440.patch
diff --git a/debian/tests/CVE-2021-23440 b/debian/tests/CVE-2021-23440
new file mode 100755
index 000..d756ed2
--- /dev/null
+++ b/debian/tests/CVE-2021-23440
@@ -0,0 +1,3 @@
+if node debian/tests/CVE-2021-23440.js; then
+   exit 1;
+fi
diff --git a/debian/tests/CVE-2021-23440.js b/debian/tests/CVE-2021-23440.js
new file mode 100644
index 000..177f1d3
--- /dev/null
+++ b/debian/tests/CVE-2021-23440.js
@@ -0,0 +1,9 @@
+const set = require("set-value")
+
+// set({}, ['__proto__','polluted'], 'yes');
+// console.log(polluted); // Error: Cannot set unsafe key: "__proto__"
+
+set({}, [['__proto__'],'polluted'], 'yes');
+if(polluted && polluted === 'yes') {
+  console.error('Vulnerable to CVE-2021-23440');
+}
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..b9d4e6c
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,3 @@
+Tests: CVE-2021-23440
+Depends: @, nodejs
+Restrictions: allow-stderr

Bug#994489: vim-scripts: consider including eregex.vim (PCRE patterns)

[Christoph Anton Mitterer]

Package: vim-scripts
Version: 20210124.1
Severity: wishlist


Hey.

This plugins adds a PCRE style regexp notation for Vim:
https://github.com/othree/eregex.vim
https://www.vim.org/scripts/script.php?script_id=3282

Would be nice if you could consider to include it.


The license is however a bit unclear, it seems to state:
1. License *eregex-license-to-use*

Copyright of eregex.vim and eregex_e.vim belongs to AKUTSU toshiyuki.
It is free to change and redistribute this script. You can think as an
GPL License software.

Author will not take any responsibility for damages due to using this
script (eregex.vim, eregex_e.vim).


Not sure if this "think of it" is enough to be DSFG compatible.


Thanks,
Chris.

Bug#994174: mirror listing update for debian.astra.in.ua

[tech]

Hello.
What does it mean ?
What do we need to change ?

On Thu, Sep 16, 2021 at 7:07 PM Julien Cristau  wrote:
>
> Control: tag -1 moreinfo
>
> Hi,
>
> I was checking your mirror for inclusion and noticed the following:
>
> o we recommend mirrors not sync directly from service aliases such as
>   ftp..debian.org (only http is guaranteed to be available at
>   ftp..d.o sites).  Maybe change your config to sync from
>   the site currently backing the ftp..debian.org service you sync
>   from?
>
> Please let us know when that is adjusted.
>
> Cheers,
> Julien
>
> On Mon, Sep 13, 2021 at 08:22:00AM +, Astra ISP wrote:
> > Package: mirrors
> > Severity: minor
> > User: mirr...@packages.debian.org
> > Usertags: mirror-list
> >
> > Submission-Type: update
> > Site: debian.astra.in.ua
> > Type: leaf
> > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> > Archive-http: /debian/
> > Archive-rsync: debian/
> > Maintainer: Astra ISP 
> > Country: UA Ukraine
> > Location: Lviv
> > Sponsor: Astra ISP https://astra.in.ua/
> >
> >
> >
> >
> > Trace Url: http://debian.astra.in.ua/debian/project/trace/
> > Trace Url: 
> > http://debian.astra.in.ua/debian/project/trace/ftp-master.debian.org
> > Trace Url: http://debian.astra.in.ua/debian/project/trace/debian.astra.in.ua
>
>


-- 
url: https://astra.in.ua/
mobile: +38(063)-321-57-50
email: n...@astra.in.ua

Bug#992125: mirror submission for dal.mirrors.clouvider.net

[Julien Cristau]

Control: tag -1 moreinfo

Hi Maciej,

one issue with this mirror:

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

Let us know when that is adjusted.

Cheers,
Julien

On Thu, Aug 12, 2021 at 10:30:56AM +, Maciej Kupiec wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: dal.mirrors.clouvider.net
> Type: leaf
> Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel 
> ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Maciej Kupiec 
> Country: US United States
> Location: Dallas
> Sponsor: Clouvider https://www.clouvider.com
> Comment: Hello!
>  We are adding more mirrors servers. Dallas is ready, so you can update :-)
>  
>  Two more on the way.
> 
> 
> 
> 
> Trace Url: http://dal.mirrors.clouvider.net/debian/project/trace/
> Trace Url: 
> http://dal.mirrors.clouvider.net/debian/project/trace/ftp-master.debian.org
> Trace Url: 
> http://dal.mirrors.clouvider.net/debian/project/trace/dal.mirrors.clouvider.net
> 

Bug#993546: kmail: KMail sees different signing key on same mail when enabling debian-keyring

[Diederik de Haas]

On donderdag 16 september 2021 12:53:16 CEST Diederik de Haas wrote:
> Control: retitle -1 GPGMe does not take additional keyring into account to
> find keys.

I retitled the bug as Sandro suggested, but I'm having second thoughts as to 
whether it's an (entirely) accurate description.

Both the main key and the subkey used to sign the message are present in both 
my local keyring as well as in the debian-keyring.gpg file.
It succeeds when *only* my local keyring is enabled, but it fails when both 
are enabled, while it then has 2 places to find Joost's public key.

I'll leave further retitlements to maintainers, but wanted to clarify this.

Cheers,
  Diederik

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

Bug#994488: alglib: autopkgtest regression with CMake 3.19+

[Timo Röhling]

Package: src:alglib
Version: 3.17.0-2
Tag: patch

Dear maintainer,

the alglib autopkgtest suite fails due to a deprecation warning with
CMake 3.19+ if cmake_minimum_required() requests a version earlier
than 2.8.12. The attached patch bumps the minimum version in
debian/tests to 3.7, which I picked because it is the CMake version
in oldoldstable.

As I am a member of the Science Team, I can also fix and upload this
for you if you are starved for developer time; just give me the
green light.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff --git a/debian/tests/build1 b/debian/tests/build1
index 5b21c12..9e49228 100755
--- a/debian/tests/build1
+++ b/debian/tests/build1
@@ -15,7 +15,7 @@ mkdir src
 cd src
 
 cat < CMakeLists.txt
-cmake_minimum_required(VERSION 2.6)
+cmake_minimum_required(VERSION 3.7)
 project(demo)
 find_package(ALGLIB REQUIRED)
 include_directories(\${ALGLIB_INCLUDE_DIRS})
diff --git a/debian/tests/build2 b/debian/tests/build2
index aeb5d7c..fcb67d9 100755
--- a/debian/tests/build2
+++ b/debian/tests/build2
@@ -15,7 +15,7 @@ mkdir src
 cd src
 
 cat < CMakeLists.txt
-cmake_minimum_required(VERSION 2.6)
+cmake_minimum_required(VERSION 3.7)
 project(demo)
 find_package(ALGLIB REQUIRED)
 include_directories(\${ALGLIB_INCLUDE_DIRS})
diff --git a/debian/tests/build3 b/debian/tests/build3
index 1f973d3..6656312 100755
--- a/debian/tests/build3
+++ b/debian/tests/build3
@@ -15,7 +15,7 @@ mkdir src
 cd src
 
 cat < CMakeLists.txt
-cmake_minimum_required(VERSION 2.6)
+cmake_minimum_required(VERSION 3.7)
 project(demo)
 find_package(ALGLIB REQUIRED)
 include_directories(\${ALGLIB_INCLUDE_DIRS})
diff --git a/debian/tests/build4 b/debian/tests/build4
index 630f116..b6de25c 100755
--- a/debian/tests/build4
+++ b/debian/tests/build4
@@ -15,7 +15,7 @@ mkdir src
 cd src
 
 cat < CMakeLists.txt
-cmake_minimum_required(VERSION 2.6)
+cmake_minimum_required(VERSION 3.7)
 project(demo)
 find_package(ALGLIB REQUIRED)
 include_directories(\${ALGLIB_INCLUDE_DIRS})
diff --git a/debian/tests/build5 b/debian/tests/build5
index 659f48c..c715ed6 100755
--- a/debian/tests/build5
+++ b/debian/tests/build5
@@ -15,7 +15,7 @@ mkdir src
 cd src
 
 cat < CMakeLists.txt
-cmake_minimum_required(VERSION 2.6)
+cmake_minimum_required(VERSION 3.7)
 project(demo)
 find_package(ALGLIB REQUIRED)
 include_directories(\${ALGLIB_INCLUDE_DIRS})


signature.asc
Description: PGP signature

Bug#994174: mirror listing update for debian.astra.in.ua

[Julien Cristau]

Control: tag -1 moreinfo

Hi,

I was checking your mirror for inclusion and noticed the following:

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

Please let us know when that is adjusted.

Cheers,
Julien

On Mon, Sep 13, 2021 at 08:22:00AM +, Astra ISP wrote:
> Package: mirrors
> Severity: minor
> User: mirr...@packages.debian.org
> Usertags: mirror-list
> 
> Submission-Type: update
> Site: debian.astra.in.ua
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Astra ISP 
> Country: UA Ukraine
> Location: Lviv
> Sponsor: Astra ISP https://astra.in.ua/
> 
> 
> 
> 
> Trace Url: http://debian.astra.in.ua/debian/project/trace/
> Trace Url: 
> http://debian.astra.in.ua/debian/project/trace/ftp-master.debian.org
> Trace Url: http://debian.astra.in.ua/debian/project/trace/debian.astra.in.ua

Bug#993230: mirror listing update for mirror.nju.edu.cn

[Julien Cristau]

Hi,

I can't get to the rsync endpoint, so I won't be including that in the
update.  I'm assuming this entry should replace the existing one for
mirrors.nju.edu.cn (with a "s") that we currently have.

Cheers,
Julien

On Sun, Aug 29, 2021 at 02:53:41AM +, YAO Ge wrote:
> Package: mirrors
> Severity: minor
> User: mirr...@packages.debian.org
> Usertags: mirror-list
> 
> Submission-Type: update
> Site: mirror.nju.edu.cn
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: YAO Ge 
> Country: CN China
> Location: Nanjing
> Sponsor: eScience Center, Nanjing University https://sci.nju.edu.cn
> Comment: http/https/rsync
>  ://mirror.nju.edu.cn/
>  
>  debian
>  debian-archive
>  debian-cd
>  debian-nonfree
>  debian-security
>  
> 
> 
> 
> 
> Trace Url: http://mirror.nju.edu.cn/debian/project/trace/
> Trace Url: http://mirror.nju.edu.cn/debian/project/trace/ftp-master.debian.org
> Trace Url: http://mirror.nju.edu.cn/debian/project/trace/mirror.nju.edu.cn

Bug#994487: Incorrect systemd detection

[Andrey Rahmatullin]

Package: solaar
Version: 1.0.6+dfsg-2
Severity: normal

Not sure why I got this prompt only now, as solaar.config is 7 years old, but
it's outdated:

systemd_running() {
test -e /sys/fs/cgroup/systemd
}

/sys/fs/cgroup/systemd no longer exists.

Bug#994166: Appears to be a debian packaging issue

[Michael Tokarev]

Control: tag -1 + moreinfo

16.09.2021 18:36, David Gilmour wrote:
...

This suggests that the qemu error is being caused by the decision to move 
hw-display-virtio-gpu-gl out of qemu-system-common and into qemu-system-gui.


I haven't seen this bugreport - I only received some status change
report - apparently when it has been reassigned to qemu-system-x86.

I especially moved the *new* device into -gui part since it is new
and since it has never been in use before this version. And this was
the only place left in -common which needs X11 stack, so without -gui
it can be completely "headless".

Please note qemu-system-x86 package recommends -gui part, and once
you explicitly tell apt to NOT install recommends, you accept that
you can deal with such situations and you know what you're doing.

I haven't completed a patch which suggests to install the additional
package which contains the requested functionality - when it's done
things like this will be much easier.

Based on this, I installed the qemu-system-gui package, and the missing object error no longer appears.  However, a new error from qemu stating that 
opengl is not available appears, so installing the qemu-system-gui package is not by itself a workaround.


I don't know how to use libvirt. But a quick search for how
to enable gl with virtio-gpu reveals this:

 qemu-system-x86_64 -device virtio-vga-gl -display gtk,gl=on

and this works with current debian-packaged qemu-6.1, and the
missing hw-display-virtio-gpu-gl is being opened (when -gui
part is installed).

So it seems I need some more context of how to reproduce this.

Thanks,

/mjt

Bug#994217:

[Chris Bainbridge]

According to stackoverflow, the fix is a small commit:

https://stackoverflow.com/questions/66636441/pdf2image-library-failing-to-read-pdf-signed-using-docusign

https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/749/diffs?commit_id=4f478daa6a9734b8f269a6586bdce2909844bb6f

So perhaps this doesn't require a new version of poppler.

Bug#994151: youtube-dl: the youtube-dl project seams to have died

[okgomdjgbm...@gmail.com]

I'm not very familiar with Debian's packaging rules
Do what you think is best.

youtube-dl is not just for youtube,
other sites get constantly fixed or added   
And now there's no activity since the 1 of July.
Waiting for youtube to brake is a bit too conservative.
You can also see a declining activity over time.
The forks got created because of this declining activity.
That they made no statement whatsoever is more concerning
then reassuring.

Given their hum... toxic attitude, it's unlikely they'll
do any statement. It's practically certain, they will never
clearly say that the project is dead.

Bug#994486: cryptsetup-initramfs: include askpass only when needed?

[Christoph Anton Mitterer]

Package: cryptsetup-initramfs
Version: 2:2.4.0-1
Severity: wishlist


Hi.

I think it would be nice if askpass was only included when actually
needed.

That seems to be the case, when no keyscript is set, and the KEY field is none,
cause:
- if a keyscript is set, either this shall perform reading a passphrase (if
  needed a all) on it's own  or  include askpass by itself (via a hook)
- if KEY is not "none", a key file would be used rather than as passphrase


Does the attached patch seem reasonable (haven't had the time to test it).

Cheers,
Chris.
--- /usr/share/initramfs-tools/hooks/cryptroot  2021-08-19 03:11:11.0 
+0200
+++ cryptroot   2021-09-16 17:37:21.670792197 +0200
@@ -67,45 +67,51 @@
 # luck with the unchanged _CRYPTTAB_SOURCE value
 fi
 
-# if keyscript is set, the "key" is just an argument to the script
-if [ -z "${CRYPTTAB_OPTION_keyscript+x}" ] && [ "$CRYPTTAB_KEY" != "none" 
]; then
-crypttab_key_check || return 1
-case "$CRYPTTAB_KEY" in
-$KEYFILE_PATTERN)
-mkdir -pm0700 -- "$DESTDIR/cryptroot/keyfiles"
-# $CRYPTTAB_NAME can't contain '/' (even after unmangling)
-keyfile="/cryptroot/keyfiles/$CRYPTTAB_NAME.key"
-if [ ! -f "$DESTDIR$keyfile" ] && ! copy_file keyfile 
"$CRYPTTAB_KEY" "$keyfile"; then
-cryptsetup_message "WARNING: couldn't copy keyfile 
$CRYPTTAB_KEY"
-fi
-_CRYPTTAB_KEY="/cryptroot/keyfiles/$_CRYPTTAB_NAME.key" # 
preserve mangled name
-;;
-*)
-if [ "$usage" = rootfs ]; then
-cryptsetup_message "WARNING: Skipping root target 
$CRYPTTAB_NAME: uses a key file"
-return 1
-elif [ "$usage" = resume ]; then
-cryptsetup_message "WARNING: Resume target $CRYPTTAB_NAME 
uses a key file"
-fi
-if [ -L "$CRYPTTAB_KEY" ] && keyfile="$(readlink -- 
"$CRYPTTAB_KEY")" &&
-[ "${keyfile#/}" != "$keyfile" ]; then
-cryptsetup_message "WARNING: Skipping target 
$CRYPTTAB_NAME: key file is a symlink with absolute target"
-return 1
-elif [ -f "$CRYPTTAB_KEY" ] && [ "$(stat -L -c"%m" -- 
"$CRYPTTAB_KEY" 2>/dev/null)" != "/" ]; then
-cryptsetup_message "WARNING: Skipping target 
$CRYPTTAB_NAME: key file is not on the root FS"
-return 1
-fi
-if [ ! -e "$CRYPTTAB_KEY" ]; then
-cryptsetup_message "WARNING: Target $CRYPTTAB_NAME has a 
non-existing key file $CRYPTTAB_KEY"
-else
-_CRYPTTAB_KEY="/FIXME-initramfs-rootmnt$_CRYPTTAB_KEY" # 
preserve mangled name
-fi
-esac
-fi
-
+# if a keyscript is set
 if [ -n "${CRYPTTAB_OPTION_keyscript+x}" ]; then
+# in this case the "key field" is just an argument to the keyscript
+
 copy_exec "$CRYPTTAB_OPTION_keyscript"
+else
+# if a key file is set
+if [ "$CRYPTTAB_KEY" != "none" ]; then
+crypttab_key_check || return 1
+case "$CRYPTTAB_KEY" in
+$KEYFILE_PATTERN)
+mkdir -pm0700 -- "$DESTDIR/cryptroot/keyfiles"
+# $CRYPTTAB_NAME can't contain '/' (even after unmangling)
+keyfile="/cryptroot/keyfiles/$CRYPTTAB_NAME.key"
+if [ ! -f "$DESTDIR$keyfile" ] && ! copy_file keyfile 
"$CRYPTTAB_KEY" "$keyfile"; then
+cryptsetup_message "WARNING: couldn't copy keyfile 
$CRYPTTAB_KEY"
+fi
+_CRYPTTAB_KEY="/cryptroot/keyfiles/$_CRYPTTAB_NAME.key" # 
preserve mangled name
+;;
+*)
+if [ "$usage" = rootfs ]; then
+cryptsetup_message "WARNING: Skipping root target 
$CRYPTTAB_NAME: uses a key file"
+return 1
+elif [ "$usage" = resume ]; then
+cryptsetup_message "WARNING: Resume target 
$CRYPTTAB_NAME uses a key file"
+fi
+if [ -L "$CRYPTTAB_KEY" ] && keyfile="$(readlink -- 
"$CRYPTTAB_KEY")" &&
+[ "${keyfile#/}" != "$keyfile" ]; then
+cryptsetup_message "WARNING: Skipping target 
$CRYPTTAB_NAME: key file is a symlink with absolute target"
+return 1
+elif [ -f "$CRYPTTAB_KEY" ] && [ "$(stat -L -c"%m" -- 
"$CRYPTTAB_KEY" 2>/dev/null)" != "/" ]; then
+cryptsetup_message "WARNING: Skipping target 
$CRYPTTAB_NAME: key file is not on the root FS"
+return 1
+fi
+if [ ! -e "$CRYPTTAB_KEY" ]; then
+cryptsetup_message "WARNING: Target