Bug#1030984: Bug on Debian 11 Bullseye - Kernel 5.9 and up - linux-image amd64

[pham...@bluewin.ch]

Package:  linux-image amd64
Version: 5.9 and up to linux-image amd64
NVIDIA drivers version: NVIDIA-Linux-x86_64-525.89.02.run

Bug Description:
Hello,
Since kernel 5.9 it has become very complicated to install recent Nvidia 
drivers.
With kernel 5.8 and earlier it was enough to do : 
/etc/init.d/*dm stop
cd ..
cd /home/username/Download
sh ./NVIDIA-Linux-x86_64-455.38.run
Since Kernel 5.9 I can no longer install the Nvidia drivers directly on these 
recent kernels, or I have an error message that appears on reboot indicating 
that lightdm (from Cinnamon) could not start.
To work around this problem I must have the 5.10.x kernel installed. Then I 
have to remove the 6.1.x kernel from my system and reboot to 5.10.x. After that 
I can install the latest Nvidia driver, then once this process is finished, 
after the next reboot I can reinstall the 6.1.x kernel with it headers and 
finally reboot on it.
I need to specify to the system that Kernel 5.10 was installed manually, 
otherwise it is deleted after running the command :
apt-get clean && apt-get autoclean && apt-get autoremove -y
And in this situation the Kernel 5.10.x does not update automatically anymore 
;-(
In short since kernel 5.9 the situation has become complicated and I lose at 
least 20 minutes each time I have to update this Nvidia graphics driver ;-(
Thank you for seeing what is happening and for trying to lighten the 
arduousness of the tasks to be performed to carry out a simple update of these 
drivers...
There is another problem when you want to resoft a machine using the advanced 
options of the Debian installer and you select the kernel from Backports 6 or 
higher (with firmware and headers). Theoretically, this should support an Intel 
AX201 Wifi card and provide access to the local network as well as the 
Internet. But unfortunately, it doesn't work, the Backport kernel installs 
correctly, but recent hardware (Intel AX201) is not recognized when it should 
be and no network or internet access is possible on my laptop Dell 9520.   
Best regards.

Philippe

Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings

[Marco]

Am 09.02.2023 schrieb Tormod Volden :

> From searching about failing X_SetInputFocus requests, one common
> cause is that the window hasn't been mapped by the window manager yet.
> I notice that Teoh is using the ratpoison window manager.
> 
> Marco, which window manager are you using?

mwm (motif window manager), on both machines.

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

[Helge Deller]

Package: gdnsd
Tags: ftbfs, hppa, lfs
Version:  3.5.2-1

On 32-bit platforms this package may fail to build when running on large discs.
One example is visible in log from the hppa platform:
https://buildd.debian.org/status/fetch.php?pkg=gdnsd=hppa=3.8.0-1=1676009104=0
which reports
error: rfc1035: 
readdir(/<>/t/testout/027tcp_control_055tcp_control_chal/etc/zones/)
 failed: Value too large for defined data type

Please add "future=+lfs" to DEB_BUILD_MAINT_OPTIONS in the debian/rules file to 
overcome this issue, e.g.:
export DEB_BUILD_MAINT_OPTIONS = hardening=+all future=+lfs

This doesn't fix all tests in the testcase, but avoids at least this specific 
(basic and important) issue.
I will analyze the other issues too...

Thanks,
Helge

Bug#1030306: xsane experiments

[Janusz S . Bień]

xsane finds the device twice, at smfp:net and as xerox_mfp:tcp.
Using xerox_mfp:tcp fails with
Not a JPEG file: starts with 0x00 0x00

Using smfp:net seems to work.

Janusz

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#1030888: bullseye-pu: package ncurses/6.2+20201114-2+deb11u1

[Cyril Brulebois]

Sven Joachim  (2023-02-08):
> Since ncurses builds a udeb, I have put debian-boot in X-Debbugs-Cc.
> The changes should not affect the installer.

ACK on principle; I'll try and make sure to test nano at some point.


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


signature.asc
Description: PGP signature

Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Cyril Brulebois]

Theodore Ts'o  (2023-02-09):
> On Thu, Feb 09, 2023 at 06:55:08PM +0100, Sven Joachim wrote:
> > That is not going to help, because IIUC grub-install is run from the
> > target system that you are installing, and there is no
> > grub2-common-udeb.
> 
> Right, but if the conflict in e2fsprogs-udeb prevents the installer
> from pulling in an overly new version of e2fsprogs-udeb, that woul be
> sufficient, no?

As Sven rightfully pointed out, there are two different environments:
 - installer, with anna and udebs (but that would be the same with apt
   and debs);
 - target.

There are no connections between both environments, so you can't have
package relationships in a cross-environment manner.

The installer uses whatever was available at build-time, or for
components that aren't built-in, whatever is available on the
installation image, or on the mirror. There's no “pulling in an overly
new version” that can be avoided. There's *one* version in the suite,
that's the one that's getting used, there's no alternative.

TL;DR: Some Conflicts, even if that were possible (which it is not)
   wouldn't achieve anything (except probably not offering any ext*
   option at the partioning step — not a huge win).

> The reason why I really don't want to add the conflicts with e2fsprogs
> 1.47 is because for people who are using sid, there is aboslutely
> nothing wrong with installing e2fsprogs 1.47.  It's only if they use
> the installer that sucks in e2fsprogs that there's a problem --- it's
> not an inherent conflict with grub per se.  If it were, then we
> shouldn't allow installation of e2fsprogs 1.46 because grub2 upstream
> is painfully slow in putting out releases --- and that's not
> reasonable.

*sigh* @ the heavy finger pointing in various parts of your mail.

> Now, what I *could* do is change the mke2fs.conf in e2fsprogs-udeb to
> remove the default use of the csum-seed feature  but is it worth
> it?  Hopefully the new version of grub2 will come out soon, at which
> point I would then need to revert the hacked mke2fs.conf --- and your
> dup'ing this bug should prevent the installer from picking up
> e2fsprogs 1.47 until the new version of grub gets released.

Right now what I'm most concerned with is getting grub2 fixed in
unstable, candidate for migration into testing. Until that happens,
e2fsprogs must be kept out of testing, so that the installer cannot get
a too-new e2fsprogs with a too-old grub2.

Whether we introduce a relationship between both packages making britney
wait on grub2's being ready to allow e2fsprogs to migrate alongside it,
or we keep an RC bug on e2fsprogs to keep it out of testing until grub2
gets fixed and migrated into testing… doesn't matter much to me.


I'll word it differently because I'd like to avoid more mails on this
thread: The installer pulls components for the target system from a
single distribution, there's no set of existing packages that can be
kept around (as that would be the case for existing systems using
testing or unstable), so we need packages in the distribution being
installed to be consistent.

Right now: unstable is broken; testing isn't.


[ snip stuff about grub design ]

> Holding back file system development because grub2 uptsream is super
> slow doesn't seem like a reasonable way forward, so I really don't
> want to set this precedent.

The Bookworm freeze has started, we need to be able to install stuff, so
we need a solution for the grub2/e2fsprogs situation *now*.

I really don't care about “setting a precedent”.

[ snip brainstorming ]


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


signature.asc
Description: PGP signature

Bug#1030982: gscan2pdf: Segmentation fault

[Janusz S . Bień]

Package: gscan2pdf
Version: 2.11.0-1
Severity: grave
X-Debbugs-Cc: none, Janusz S. Bień 
 
Not a JPEG file: starts with 0x00 0x00

The same bug occurs in simple-scan, cf.  Bug#1030306.

The device is  Samsung Xpress M2070FW connected by Wi-Fi, scanning with
GIMP and printing works.

I will appreciate your help.

Janusz

-- System Information: Debian Release: 11.6 APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'unstable'), (500, 'stable'), (100, 'bullseye-fasttrack'), (100,
'bullseye-backports-staging') Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_CRAP, 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 gscan2pdf depends on:
ii  imagemagick8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1.3
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1.1
ii  libfilesys-df-perl 0.92-6+b6
ii  libgoocanvas2-perl 0.06-2
ii  libgtk3-imageview-perl 6-1
ii  libgtk3-perl   0.038-1
ii  libgtk3-simplelist-perl0.21-1
ii  libhtml-parser-perl3.75-1+b1
ii  libimage-magick-perl   8:6.9.11.60+dfsg-1.3
ii  libimage-sane-perl 5-1+b1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-codes-perl   3.66-1
ii  liblocale-gettext-perl 1.07-4+b1
ii  liblog-log4perl-perl   1.54-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b9
ii  libpdf-builder-perl3.021-2
ii  libproc-processtable-perl  0.59-2+b1
ii  libreadonly-perl   2.050-3
ii  librsvg2-common2.50.3+dfsg-1
ii  libset-intspan-perl1.19-1.1
ii  libtiff-tools  4.2.0-1+deb11u3
ii  libtry-tiny-perl   0.30-1
ii  sane-utils 1.0.31-4.1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin   3.5.28-2
ii  pdftk   2.02-5+b1
ii  pdftk-java [pdftk]  3.2.2-1
ii  tesseract-ocr   4.1.3-2
ii  unpaper 6.1-2+b2
ii  xdg-utils   1.1.3-4.1

gscan2pdf suggests no packages.

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#1030981: nvidia-kernel-dkms: Depends on missing firmware-nvidia-gsp-525.85.12

[Scott Tripp]

Package: nvidia-kernel-dkms
Version: 525.85.12-1
Severity: important
X-Debbugs-Cc: kscott.tr...@gmail.com

Dear Maintainer,

I cannot install nvidia-driver, as that depends on nvidia-kernel-dkms
(this package), which in turn depends on firmware-nvidia-gsp-525.85.12,
which is missing.

The following packages have unmet dependencies:
 nvidia-kernel-dkms : Depends: firmware-nvidia-gsp (= 525.85.12) but it is not 
installable or
   firmware-nvidia-gsp-525.85.12 but it is not 
installable

Thanks,
Scott

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
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 nvidia-kernel-dkms depends on:
ii  dkms 3.0.10-5
pn  firmware-nvidia-gsp | firmware-nvidia-gsp-525.85.12  
pn  nvidia-installer-cleanup 
pn  nvidia-kernel-support--v1

Versions of packages nvidia-kernel-dkms recommends:
pn  nvidia-driver | libcuda1  

nvidia-kernel-dkms suggests no packages.

Bug#1030096: dask.distributed intermittent autopkgtest fail

[Andreas Tille]

Hi,

Am Fri, Feb 10, 2023 at 08:44:01AM +0530 schrieb Nilesh Patra:
> Some tests passed after I put it for (multiple) retries. The
> current state looks fine
> 
>   https://qa.debian.org/excuses.php?package=dask.distributed

Thanks to you all three for your work.

> But I am not sure if this counter would be set to 2 days (from 5 days)
> or not -- will likely need to ask release team.

As far as I observed the migration time is now 5 days (no matter whether
autopkgtest or not).

> In any case it might be a nice idea to hold off any further uploads
> until this migrates.

+1

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1030254: debvm: Please support "--variant=custom" VMs

[Helmut Grohne]

Hi Johannes,

On Wed, Feb 08, 2023 at 03:03:58PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> I think this boils down to deciding whether or not you want systemd
> specifically or not. If you don't (and I'd like that because I want to use
> debvm to work even on snapshot.d.o timestamps from before systemd) then the
> --skip=systemdnetwork skip option doesn't make much sense. In that case, the
> features that debvm offers should be agnostic of the init system and you 
> should
> not have features that require a specific init system. If there is no systemd,
> use something else to set up networking and disable that mechanism with
> --skip=network. Same with autologin. If it doesn't work with with other init
> systems, don't offer it as a (skippable) default. Making skippable features
> init system agnostic would also do away with the problem of unskippable skip
> implications.

I'm not enthusiastic about supporting non-systemd systems. It is a case
where I don't expect much usage and it is difficult to keep working (or
takes a lot of effort to write tests).

Of course it would be awesome to be more flexible, but at the same time,
debvm doesn't make any attempt to supporting non-linux architectures
either. The initial idea of it was to make the common case simple as it
was too difficult to remember that complex mmdebstrap and qemu
invocations.

That said, if that's what you need, let's figure out what that is
exactly and make it work. That debsnap use case looks a little strange
to me. Honestly, if a bug is present since longer than jessie, I
wouldn't try tracking it down but consider it always present and just
fix it as if it never was fixed. The annoyances of going that far back
don't seem worth the effort to me. I recognize that you see things
differently somehow.

> In mmdebstrap I use the slash to create a hirarchy of skip options. Adding
> --skip=cleanup will also imply --skip=cleanup/apt and
> --skip=cleanup/reproducible. Maybe you could do the same if you decide to 
> force
> systemd as init system unless the user adds --skip=systemd: Rename
> --skip=systemdnetwork to --skip=systemd/network and rename --skip=autologin to
> --skip=systemd/autologin. That way, when the user adds --skip=systemd, it can
> easily be guessed that all system/* options are skipped by doing that. The
> problem with that approach is, that you cannot anymore easily add a
> init-system-agnostic network and autologin functionality because if you want 
> to
> then skip that, it's not clear whether or not --skip=network would imply
> --skip=systemd/network.

I saw that, but wasn't enthusiastic about the hierarchy yet.

> Also, is --skip=systemd not a bit misleading? Because what you are skipping is
> not systemd but systemd-sysv, no?

I see you also dislike that. Based on Jochen's feedback I called it
initsystem already.

Helmut

Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6

[Helmut Grohne]

Package: qt6-base-dev
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:fcitx-qt5

Hi,

thanks for adding the -qmake6 wrapper. This piece seems to work
fine. The next step is making packages actually use it and this is where
it gets difficult.

fcitx-qt6 extracts the Qt6::qmake IMPORTED_LOCATION and expects to find
a working qmake there. What it gets is the build architecture qmake
instead of our lovely wrapper. Bummer.

I looked into how this could be fixed and got entangled in the mess of
cmake files until I completely lost track. What I found is that the
imported location is (wrongly) defined in
/usr/lib//cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake as
${_IMPORT_PREFIX}/lib/qt6/libexec/qmake aka /usr/lib/qt6/libexec/qmake
while it should be /usr/bin/-qmake6.  Tracking down how this
file is generated is where I failed. Would someone be available to
support me with that task?

Thanks in advance

Helmut

Bug#1030979: Script error: "cannot create /dev/stdout: No such device or address"

[Daniel Richard G.]

Package: ifupdown-extra
Version: 0.33+nmu1
Severity: minor

In testing ifupdown-extra, I noticed this in syslog:

Feb  9 22:14:53 image-debian64 ifup[495]: 
/etc/network/if-up.d/10check-duplicate-ip: 86: cannot create /dev/stdout: No 
such device or address

/dev/stdout is a Bash feature, but 10check-duplicate-ip is run using
/bin/sh (see first line). On Debian systems, /bin/sh is normally a
symlink to dash, which is a much more limited implementation of the
Bourne shell.

The script should either limit itself to using POSIX standard shell
features, or switch to a /bin/bash shebang line.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1030978: webalizer: Webalizer.org no longer takes you to the webalizer site.

[Andrew JF Clark]

Package: webalizer
Version: 2.23.08-3.3
Severity: normal
Tags: upstream patch

Dear Maintainer,

Webalizer.org appears to have been purchased by NC 2nd Amendment Lawyers and 
the links in the report footers, documentation, etc take you to their site, not 
the webalizer one.

Webalizer.net still has the correct site.

Included is a basic patch to correct the issue.

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

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

Versions of packages webalizer depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-8
ii  libdb5.3   5.3.28+dfsg2-1
ii  libgd3 2.3.3-7+b1
ii  libgeoip1  1.6.12-10
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages webalizer recommends:
ii  geoip-database  20230203-1

Versions of packages webalizer suggests:
ii  apache2 [httpd] 2.4.55-1
ii  fonts-dejavu-core   2.37-2
ii  fonts-freefont-ttf  20120503-10
ii  nginx-core [httpd]  1.22.1-5
ii  nginx-full [httpd]  1.22.1-5

-- debconf information excluded

Bug#1030893:

[Matthias Klose]

> I am unsure why you are uploading gdb snapshots for Debian bookworm.

I tried to reach you on IRC and by email. Getting no reply, I asked your 
co-maintainer if he's ok to do that upload. Sergio was ok.


It's not a snapshot, it's a release candidate, allowing to read zstd compressed 
debug sections and ctf information.  Users may expect in a Debian release a gdb 
which can understand what is shipped with the distro.


> In anycase, could you look at this failure, you may need
> to generate a DFSG tarball without the GFDL documentation.

I tried my best, however debian/copyright just says:

Source: https://www.gnu.org/software/gdb/download/ w/ GFDL'd files stripped

However, GFDL'd files are allowed. Please be more precise saying that these are 
GFDL files with invariant sections.


It looks like your script to regenerate the tarball removed all documentation, 
not just the one with invariant sections.


I also now upload a corresponding gdb-doc package.

Bug#1030096: dask.distributed intermittent autopkgtest fail

[Diane Trout]

On Fri, 2023-02-10 at 08:44 +0530, Nilesh Patra wrote:
> Control: fixed -1 2022.12.1+ds.1-2
> 
> Some tests passed after I put it for (multiple) retries. The
> current state looks fine
> 
> https://qa.debian.org/excuses.php?package=dask.distributed
> 
> But I am not sure if this counter would be set to 2 days (from 5
> days)

That explains why the tests suddenly passed when i wasn't looking.

When I'd last looked in the morning most of them were marked failed.

> or not -- will likely need to ask release team.
> In any case it might be a nice idea to hold off any further uploads
> until this migrates.
> 

Yeah I need to beg the release team for forgiveness.

Though I made two changes that should dramatically increase the odds of
the tests passing.

One I told it to skip all the "isinstalled" marked tests, which are all
skipped during build time, and the build seems to run far more
reliably.

I got the idea because it seemed like the vast majority of test
failures are related to the daemons running or failing to shut down.

While talking on IRC about dask.distributed problems I learned of the
flaky autopkgtest restriction which says the test is expected to fail
intermittently and is not suitable for gating continuous integratin.

So I marked the current whole autopkgtest run as flaky.

So CI should also ignore the results of failed test runs now.

When under less time pressure I think a good plan might be two split
the tests internally marked as isinstalled or flaky into a separate
autopkgtest run that's marked flaky and let the CI gate on the more
reliable tests.

Diane


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

Bug#1030977: DO_SYSLOG=yes produces duplicate messages in syslog

[Daniel Richard G.]

Package: ifupdown-extra
Version: 0.33+nmu1

In testing out a stock installation of ifupdown-extra, I noticed the
following pair of messages in syslog:

Feb  9 22:06:44 image-debian64 root[493]: WARNING: Initialising interface 
enp0s3 which does not have a link
Feb  9 22:06:44 image-debian64 ifup[493]: <27>Feb  9 22:06:44 root[493]: 
WARNING: Initialising interface enp0s3 which does not have a link

This is coming from 00check-network-cable, and DO_SYSLOG is untouched
from its default value of "yes". The second message, of course, appears
to be a repackaged duplicate of the first and should not be there.

If I set DO_SYSLOG=no in /etc/default/network-test, then all I see is

Feb  9 22:12:21 image-debian64 ifup[480]: WARNING: Initialising interface 
enp0s3 which does not have a link

There is apparently something in the Debian standard logging system that
causes logger(1) messages to be duplicated. Since stdout is going to
syslog anyway, making DO_SYSLOG=no the shipped default seems like a
reasonable solution.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1030976: Scripts do not handle IFACE="--all" case correctly

[Daniel Richard G.]

Package: ifupdown-extra
Version: 0.33+nmu1

In testing out an installation of ifupdown-extra, I noticed the
following trio of messages in syslog:

Feb  9 22:12:21 image-debian64 ifup[526]: ERROR: Interface --all does not 
seem to be present in the system
Feb  9 22:12:21 image-debian64 ifup[533]: Device "--all" does not exist.
Feb  9 22:12:21 image-debian64 ifup[531]: WARNING: Cannot check for 
duplicate IP address in the network as the script could not find the ip address 
of --all. You can disable this test by setting DO_ARPING to 'no' in 
/etc/default/network-test .

The first and third messages appear to come from the 00check-network-cable
and 10check-duplicate-ip scripts, respectively.

Note that IFACE="--all" is a valid invocation of the if-*.d scripts, per
bug #826000.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1030952: [Pkg-javascript-devel] Bug#1030952: npm depends on webpack and 200+ other packages

[Yadd]

Control: reassign -1 node-css-loader

On 2/10/23 07:09, Yadd wrote:

Control: reassign -1 node-postcss-selector-parser

On 2/10/23 01:35, Christopher Hagar wrote:

Package: npm
Version: 9.2.0~ds1-1
Severity: normal
X-Debbugs-Cc: cmha...@gmail.com

After recent changes in npm and node-css-loader 
(node-postcss-selector-parser),

installing npm installs webpack and 200+ other node-related packages.

Given that npm is a package manager, it should not require so many
dependencies.

Morever, npm is for installing packages outside of the Debian package 
manager!

It should not bring in tons of Debian packages that will never be used.

Debian Policy says that Depends declares an "absolute dependency". 
Recommends
declares a "strong, but not absolute, dependency". Suggests declares 
that a
packages "may be more useful with one or more others". And it is 
possible there
should be no dependency relationship of any kind for npm depending on 
webpack.


Hi,

if you install upstream npm, you'll have hundreds packages in 
npm/node_modules (around 200 MB). The way chosen in Debian is to reuse 
modules that already exist in Debian (and then drop them from npm).
So yes, there are a lot of dependencies but /usr/share/nodejs/npm (and 
related dirs like  @npmcli/) contains only 3 MB including 
/usr/share/nodejs/npm/node_modules/.


Anyway npm doesn't need webpack.
Link between npm and webpack:
  - npm requires node-postcss-selector-parser (for @npmcli/query)
  - node-postcss-selector-parser requires node-css-loader because it
    requires node-indexes-of which is a virtual package provided by
    node-postcss-selector-parser
  - node-css-loader requires webpack

So the bug is in node-postcss-selector-parser, it may embed indexes-of 
which is a 5-lines modules instead of depending of node-css-loader.


I'm wrong here, node-postcss-selector-parser is a virtual package 
provided by node-css-loader.

Bug#1030096: dask.distributed intermittent autopkgtest fail

[Nilesh Patra]

Control: fixed -1 2022.12.1+ds.1-2

Some tests passed after I put it for (multiple) retries. The
current state looks fine

https://qa.debian.org/excuses.php?package=dask.distributed

But I am not sure if this counter would be set to 2 days (from 5 days)
or not -- will likely need to ask release team.
In any case it might be a nice idea to hold off any further uploads
until this migrates.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1030952: npm depends on webpack and 200+ other packages

[Yadd]

Control: reassign -1 node-postcss-selector-parser

On 2/10/23 01:35, Christopher Hagar wrote:

Package: npm
Version: 9.2.0~ds1-1
Severity: normal
X-Debbugs-Cc: cmha...@gmail.com

After recent changes in npm and node-css-loader (node-postcss-selector-parser),
installing npm installs webpack and 200+ other node-related packages.

Given that npm is a package manager, it should not require so many
dependencies.

Morever, npm is for installing packages outside of the Debian package manager!
It should not bring in tons of Debian packages that will never be used.

Debian Policy says that Depends declares an "absolute dependency". Recommends
declares a "strong, but not absolute, dependency". Suggests declares that a
packages "may be more useful with one or more others". And it is possible there
should be no dependency relationship of any kind for npm depending on webpack.


Hi,

if you install upstream npm, you'll have hundreds packages in 
npm/node_modules (around 200 MB). The way chosen in Debian is to reuse 
modules that already exist in Debian (and then drop them from npm).
So yes, there are a lot of dependencies but /usr/share/nodejs/npm (and 
related dirs like  @npmcli/) contains only 3 MB including 
/usr/share/nodejs/npm/node_modules/.


Anyway npm doesn't need webpack.
Link between npm and webpack:
 - npm requires node-postcss-selector-parser (for @npmcli/query)
 - node-postcss-selector-parser requires node-css-loader because it
   requires node-indexes-of which is a virtual package provided by
   node-postcss-selector-parser
 - node-css-loader requires webpack

So the bug is in node-postcss-selector-parser, it may embed indexes-of 
which is a 5-lines modules instead of depending of node-css-loader.

Bug#1030975: 00check-network-cable script is in wrong directory

[Daniel Richard G.]

Package: ifupdown-extra
Version: 0.33+nmu1
Severity: important

The 00check-network-cable script is currently in /etc/network/if-up.d/,
but it should be in if-pre-up.d/, because it needs to run before the
interface is configured. (Running after configuration defeats the entire
purpose of checking whether a cable is connected.) The script even has a
comment at the top stating

# This script should be installed in /etc/network/if-pre-up.d/

I've confirmed that this breaks the intended behavior when
ABORT_NO_LINK=yes is set in /etc/default/network-test . This issue is
also present in the bullseye version of the package (0.32).


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1030974: RM: mstflint [mips64el] -- RoQA; upstream no longer supports mips64el

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

Upstream no longer supports mips64el.

Bug#1003926: Fix uploaded to "proposed-updates"

[Runamile Czyborra]

Wow, thank thee Håvard!

Op zo 5 feb. 2023 20:23 schreef Håvard F. Aasen :

> Hello,
>
> A fix for this bug has been uploaded to the "proposed-updates"
> queue, which will be made available in the next point release
> for Bullseye, (11.7). The date for the release is still TBD.
>
>
> Regards,
> Håvard
>

Bug#1030973: fails to support files outside of /lib/firmware/updates

[Dmitry Baryshkov]

Source: tqftpserv
Version: 1.0-2
Severity: grave
Tags: patch

Recent additions to enable /lib/firmware/updates broke tqftpserv on all
systems not using this dir. Duplicated dirname() call results in
looking for the requested files in the wrong directory.

The proposed fixes are posted at [1]. Please consider applying it.

Also could you please post your proposals to Bjorn's github so that we
can review them?

[1] https://salsa.debian.org/DebianOnMobile-team/tqftpserv/-/merge_requests/2

-- 
With best wishes
Dmitry

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

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

Bug#1030972: RM: calcurse [s390x] -- RoQA; package no longer builds on s390x

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

The package no longer builds on s390x, see #1004103 for background.

Bug#1030971: rust-configparser: autopkgtest failure

[Adrian Bunk]

Source: rust-configparser
Version: 2.0.0-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-configparser/31203190/log.gz

...
running 2 tests
Error: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }
Error: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }
test non_cs ... FAILED
test cs ... FAILED

failures:

 non_cs stdout 
thread 'non_cs' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`: the test returned a termination value with a non-zero status code 
(1) which indicates a failure', 
/usr/src/rustc-1.63.0/library/test/src/lib.rs:184:5
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:181:5
   4: test::assert_test_result
 at /usr/src/rustc-1.63.0/library/test/src/lib.rs:184:5
   5: test::non_cs::{{closure}}
 at ./tests/test.rs:5:1
   6: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   7: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.

 cs stdout 
thread 'cs' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`: the test returned a termination value with a non-zero status code 
(1) which indicates a failure', 
/usr/src/rustc-1.63.0/library/test/src/lib.rs:184:5
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:181:5
   4: test::assert_test_result
 at /usr/src/rustc-1.63.0/library/test/src/lib.rs:184:5
   5: test::cs::{{closure}}
 at ./tests/test.rs:108:1
   6: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   7: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.


failures:
cs
non_cs

test result: FAILED. 0 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; 
finished in 0.01s

error: test failed, to rerun pass `--test test`
autopkgtest [02:09:53]: test librust-configparser-dev:: ---]
autopkgtest [02:09:53]: test librust-configparser-dev::  - - - - - - - - - - 
results - - - - - - - - - -
librust-configparser-dev: FAIL non-zero exit status 101
autopkgtest [02:09:53]:  summary
rust-configparser:@  FAIL non-zero exit status 101
librust-configparser-dev:default FAIL non-zero exit status 101
librust-configparser-dev: FAIL non-zero exit status 101

Bug#1030970: rust-parsec-interface: autopkgtest failure

[Adrian Bunk]

Source: rust-parsec-interface
Version: 0.27.0-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-parsec-interface/31199857/log.gz

...
 Running 
`/tmp/tmp.y3xFExYcfq/target/debug/build/parsec-interface-24da2a6140058d50/build-script-build`
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/delete_client.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/list_authenticators.rs': Permission 
denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/list_clients.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/list_keys.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/list_opcodes.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/list_providers.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/ping.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_aead_decrypt.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_aead_encrypt.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_algorithm.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_asymmetric_decrypt.rs': Permission 
denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_asymmetric_encrypt.rs': Permission 
denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_cipher_decrypt.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_cipher_encrypt.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_destroy_key.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_export_key.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_export_public_key.rs': Permission 
denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_generate_key.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_generate_random.rs': Permission 
denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_hash_compare.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_hash_compute.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_import_key.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_key_attributes.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_mac_compute.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_mac_verify.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_raw_key_agreement.rs': Permission 
denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_sign_hash.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_sign_message.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_verify_hash.rs': Permission denied
[parsec-interface 0.27.0] cp: cannot create regular file 
'src/operations_protobuf/generated_ops/psa_verify_message.rs': Permission denied
[parsec-interface 0.27.0] Error: Custom { kind: InvalidData, error: "failed 
copying generated protobuf files" }
error: failed to run custom build command for `parsec-interface v0.27.0 
(/usr/share/cargo/registry/parsec-interface-0.27.0)`

Caused by:
  process didn't exit successfully: 
`/tmp/tmp.y3xFExYcfq/target/debug/build/parsec-interface-24da2a6140058d50/build-script-build`
 (exit status: 1)
  --- stderr
  cp: cannot create regular file 
'src/operations_protobuf/generated_ops/delete_client.rs': Permission denied
  cp: cannot create regular file 
'src/operations_protobuf/generated_ops/list_authenticators.rs': 

Bug#1030969: fails to map domains if /lib/firmware/updates is not present

[Dmitry Baryshkov]

Source: protection-domain-mapper
Version: 1.0-3
Severity: grave
Tags: patch

Recent additions to enable /lib/firmware/updates broke pd-mapper for all
other systems. Improper error handling of opendir() results in segfaults
and duplicated dirname() call results in looking for the JSON file in
the wrong directory.

The proposed fixes are posted at [1]. Please consider applying

Also could you please post your proposals to Bjorn's github so that we
can review them?

[1] 
https://salsa.debian.org/DebianOnMobile-team/protection-domain-mapper/-/merge_requests/3

-- 
With best wishes
Dmitry


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

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

Bug#1030968: fapolicyd fails to install

[Adrian Bunk]

Package: fapolicyd
Version: 1.1.7-2
Severity: serious

https://piuparts.debian.org/sid/fail/fapolicyd_1.1.7-2.log

...
  Setting up fapolicyd (1.1.7-2) ...
  Adding group `fapolicyd' (GID 150) ...
  Done.
  chown: cannot access '/var/lib/fapolicyd': No such file or directory
  dpkg: error processing package fapolicyd (--configure):
   installed fapolicyd package post-installation script subprocess returned 
error exit status 1
  Processing triggers for libc-bin (2.36-8) ...
  Errors were encountered while processing:
   fapolicyd

Bug#1030967: vip-manager2: autopkgtest failure

[Adrian Bunk]

Source: vip-manager2
Version: 2.1.0-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/v/vip-manager2/31169753/log.gz

...
autopkgtest [15:34:34]: test cacert_test: [---
dpkg-architecture: warning: cannot determine CC system type, falling back to 
default (native compilation)
2023-02-08 15:34:34.852072 W | pkg/flags: unrecognized environment variable 
ETCD_UNSUPPORTED_ARCH=
[WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag 
instead
2023-02-08 15:34:34.852125 I | etcdmain: etcd Version: 3.4.23
2023-02-08 15:34:34.852128 I | etcdmain: Git SHA: Not provided (use ./build 
instead of go build)
2023-02-08 15:34:34.852130 I | etcdmain: Go Version: go1.19.4
2023-02-08 15:34:34.852132 I | etcdmain: Go OS/Arch: linux/amd64
2023-02-08 15:34:34.852136 I | etcdmain: setting maximum number of CPUs to 64, 
total number of available CPUs is 64
2023-02-08 15:34:34.852140 W | etcdmain: no data-dir provided, using default 
data-dir ./default.etcd
[WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag 
instead
2023-02-08 15:34:34.852454 C | etcdmain: listen tcp 127.0.0.1:2380: bind: 
address already in use
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:12345
{"level":"warn","ts":"2023-02-08T15:34:41.855Z","caller":"clientv3/retry_interceptor.go:62","msg":"retrying
 of unary invoker 
failed","target":"endpoint://client-42f26925-0cba-4cc3-b014-8c4d184782bc/127.0.0.1:2379","attempt":0,"error":"rpc
 error: code = DeadlineExceeded desc = latest balancer error: all SubConns are 
in TransientFailure"}
Error: context deadline exceeded
{"level":"warn","ts":"2023-02-08T15:34:48.868Z","caller":"clientv3/retry_interceptor.go:62","msg":"retrying
 of unary invoker 
failed","target":"endpoint://client-285abd0a-edf8-4146-a93d-ee1dc21cf16b/127.0.0.1:2379","attempt":0,"error":"rpc
 error: code = DeadlineExceeded desc = latest balancer error: all SubConns are 
in TransientFailure"}
Error: context deadline exceeded
### Some tests failed! ###
autopkgtest [15:34:49]: test cacert_test: ---]
autopkgtest [15:34:49]: test cacert_test:  - - - - - - - - - - results - - - - 
- - - - - -
cacert_test  FAIL non-zero exit status 1
autopkgtest [15:34:49]: test clientcert_test: preparing testbed
Reading package lists...
Building dependency tree...
Reading state information...
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up autopkgtest-satdep (0) ...
(Reading database ... 12989 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [15:34:51]: test clientcert_test: [---
dpkg-architecture: warning: cannot determine CC system type, falling back to 
default (native compilation)
2023-02-08 15:34:51.513732 W | pkg/flags: unrecognized environment variable 
ETCD_UNSUPPORTED_ARCH=
[WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag 
instead
2023-02-08 15:34:51.513777 I | etcdmain: etcd Version: 3.4.23
2023-02-08 15:34:51.513781 I | etcdmain: Git SHA: Not provided (use ./build 
instead of go build)
2023-02-08 15:34:51.513783 I | etcdmain: Go Version: go1.19.4
2023-02-08 15:34:51.513787 I | etcdmain: Go OS/Arch: linux/amd64
2023-02-08 15:34:51.513789 I | etcdmain: setting maximum number of CPUs to 64, 
total number of available CPUs is 64
2023-02-08 15:34:51.513793 W | etcdmain: no data-dir provided, using default 
data-dir ./default.etcd
[WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag 
instead
2023-02-08 15:34:51.514308 C | etcdmain: listen tcp 127.0.0.1:2380: bind: 
address already in use
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:12345
{"level":"warn","ts":"2023-02-08T15:34:58.517Z","caller":"clientv3/retry_interceptor.go:62","msg":"retrying
 of unary invoker 
failed","target":"endpoint://client-06e11fbd-d9ed-4e1b-9c26-fe8524214f9a/127.0.0.1:2379","attempt":0,"error":"rpc
 error: code = DeadlineExceeded desc = latest balancer error: all SubConns are 
in TransientFailure"}
Error: context deadline exceeded
{"level":"warn","ts":"2023-02-08T15:35:05.541Z","caller":"clientv3/retry_interceptor.go:62","msg":"retrying
 of unary invoker 
failed","target":"endpoint://client-b1551d5c-c0a9-4432-80bf-af31336a56a5/127.0.0.1:2379","attempt":0,"error":"rpc
 error: code = DeadlineExceeded desc = latest balancer error: all SubConns are 
in TransientFailure"}
Error: context deadline exceeded
### Some tests failed! ###
autopkgtest [15:35:05]: test clientcert_test: ---]
autopkgtest [15:35:05]: test clientcert_test:  - - - - - - - - - - results - - 
- - - - - - - -
clientcert_test  FAIL non-zero exit status 1
autopkgtest [15:35:06]: 

Bug#1030966: ruby-jekyll-remote-theme accesses the internet during the build

[Adrian Bunk]

Source: ruby-jekyll-remote-theme
Version: 0.4.3-3
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-jekyll-remote-theme.html

...
2) Jekyll::RemoteTheme::Munger with a malicious theme requires whitelisted 
plugins
 Failure/Error:
   http.request(request) do |response|
 raise_unless_sucess(response)
 enforce_max_file_size(response.content_length)
 response.read_body do |chunk|
   zip_file.write chunk
 end
   end

 SocketError:
   Failed to open TCP connection to codeload.github.com:443 (getaddrinfo: 
Temporary failure in name resolution)
...
Failed examples:

rspec ./spec/jekyll-remote-theme/munger_spec.rb:127 # 
Jekyll::RemoteTheme::Munger with a malicious theme doesn't require malicious 
plugins
rspec ./spec/jekyll-remote-theme/munger_spec.rb:122 # 
Jekyll::RemoteTheme::Munger with a malicious theme requires whitelisted plugins
rspec ./spec/jekyll-remote-theme/munger_spec.rb:116 # 
Jekyll::RemoteTheme::Munger with a malicious theme sets the theme
rspec ./spec/jekyll-remote-theme/munger_spec.rb:99 # 
Jekyll::RemoteTheme::Munger with a remote theme requires plugins
rspec ./spec/jekyll-remote-theme/munger_spec.rb:93 # 
Jekyll::RemoteTheme::Munger with a remote theme sets layouts
rspec ./spec/jekyll-remote-theme/munger_spec.rb:73 # 
Jekyll::RemoteTheme::Munger with a remote theme downloads
rspec ./spec/jekyll-remote-theme/munger_spec.rb:89 # 
Jekyll::RemoteTheme::Munger with a remote theme sets include paths
rspec ./spec/jekyll-remote-theme/munger_spec.rb:67 # 
Jekyll::RemoteTheme::Munger with a remote theme sets the theme
rspec ./spec/jekyll-remote-theme/munger_spec.rb:77 # 
Jekyll::RemoteTheme::Munger with a remote theme sets sass paths
rspec ./spec/jekyll_remote_theme_spec.rb:13 # Jekyll::RemoteTheme inits
...

Bug#1030965: libsmali-java: autopkgtest regression

[Adrian Bunk]

Source: libsmali-java
Version: 2.5.2.git2771eae-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/libs/libsmali-java/31172804/log.gz

...
autopkgtest [21:48:48]: test roundtrip: [---
readlink: missing operand
Try 'readlink --help' for more information.
autopkgtest [21:48:48]: test roundtrip: ---]
autopkgtest [21:48:48]: test roundtrip:  - - - - - - - - - - results - - - - - 
- - - - -
roundtripFAIL non-zero exit status 1

Bug#1030964: RM: dials [arm64 ppc64el] -- NBS; package is now only built on amd64

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

dials (3.12.1+dfsg3-3) unstable; urgency=medium

  * Restrict building to amd64 until fixes for the arm64 and ppc64el are
ready.

 -- Roland Mas   Wed, 18 Jan 2023 17:45:41 +0100

Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings

[H. S. Teoh]

On Thu, Feb 09, 2023 at 11:16:15AM +0100, Tormod Volden wrote:
> On Thu, Feb 9, 2023 at 10:20 AM Tormod Volden wrote:
> > Would it be possible for you to build the upstream sources, without
> > optimization, and try it out? You shouldn't need to install any of
> > it, just run driver/xscreensaver-settings --debug from the build
> > tree. And also rename your ~/.xscreensaver so that it runs with
> > default settings.
> 
> Now it gets a bit complicated if we don't want to install it, but at
> the same time let the built xscreensaver-settings find the
> screensavers from the already installed Debian packages, we need to
> set the exec-prefix. In this case do not run make install afterwards!
> >From unpacked upstream sources:
> 
> ./configure CFLAGS="-g -O0" --exec-prefix=/usr
> make -j4
> driver/xscreensaver-settings --debug
[...]

Here is the output:

--snip---
$ driver/xscreensaver-settings --debug 
xscreensaver-settings: 16:11:29: DISPLAY=:0.0
xscreensaver-settings: 16:11:29: added "/usr/libexec/xscreensaver" to $PATH
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkCheckButton
xscreensaver-settings: 16:11:29: pref changed: GtkCheckButton
xscreensaver-settings: 16:11:29: pref changed: GtkCheckButton
xscreensaver-settings: 16:11:29: pref changed: GtkRadioButton
xscreensaver-settings: 16:11:29: pref changed: GtkRadioButton
xscreensaver-settings: 16:11:29: list selection changed
xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 
120-cell"
xscreensaver-settings: 16:11:29: 
/usr/local/share/xscreensaver/config/polytopes.xml does not exist.
xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 
120-cell"
xscreensaver-settings: 16:11:29: 
/usr/local/share/xscreensaver/config/polytopes.xml does not exist.
xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 
120-cell"
xscreensaver-settings: 16:11:29: select list elt 168
xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 
120-cell"
xscreensaver-settings: 16:11:29: 
/usr/local/share/xscreensaver/config/polytopes.xml does not exist.
xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 
120-cell"
xscreensaver-settings: 16:11:29: xscreensaver-gl-visual did not report a GL 
visual!
Segmentation fault
--snip---

Apparently there *is* a segfault, even though it doesn't appear that way
when I run the official binaries.  This looks to be the same bug as
#1030659 after all.


T

-- 
If it tastes good, it's probably bad for you.

Bug#1030963: RM: equinox-bundles -- ROM; Replaced by eclipse-equinox

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: eclipse-equi...@packages.debian.org
Control: affects -1 + src:eclipse-equinox

Hi, please remove the equinox-bundles package, it has been replaced by 
eclipse-equinox.

Thank you

Bug#1030962: RM: equinox-framework -- ROM; Replaced by eclipse-equinox

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: equinox-framew...@packages.debian.org
Control: affects -1 + src:equinox-framework

Hi, please remove the equinox-framework package, it has been replaced by 
eclipse-equinox.

Thank you

Bug#997184: ncurses-hexedit: diff for NMU version 0.9.7+orig-7.2

[Adrian Bunk]

Dear maintainer,

I've uploaded an NMU for ncurses-hexedit (versioned as 0.9.7+orig-7.2). 
The diff is attached to this message.

cu
Adrian
diff -Nru ncurses-hexedit-0.9.7+orig/debian/changelog ncurses-hexedit-0.9.7+orig/debian/changelog
--- ncurses-hexedit-0.9.7+orig/debian/changelog	2021-02-06 23:35:33.0 +0200
+++ ncurses-hexedit-0.9.7+orig/debian/changelog	2023-02-10 02:03:53.0 +0200
@@ -1,3 +1,11 @@
+ncurses-hexedit (0.9.7+orig-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Reiner Herrmann for newer ncurses.
+(Closes: #997184)
+
+ -- Adrian Bunk   Fri, 10 Feb 2023 02:03:53 +0200
+
 ncurses-hexedit (0.9.7+orig-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ncurses-hexedit-0.9.7+orig/debian/patches/ncurses.patch ncurses-hexedit-0.9.7+orig/debian/patches/ncurses.patch
--- ncurses-hexedit-0.9.7+orig/debian/patches/ncurses.patch	1970-01-01 02:00:00.0 +0200
+++ ncurses-hexedit-0.9.7+orig/debian/patches/ncurses.patch	2023-02-10 02:00:57.0 +0200
@@ -0,0 +1,25 @@
+Author: Reiner Herrmann 
+Bug-Debian: https://bugs.debian.org/997184
+
+--- a/src/init.c
 b/src/init.c
+@@ -385,7 +388,7 @@
+  box (wpopup, 0, 0);
+  wmove (wpopup, 1, (FILE_ERR_WIDTH / 2)
+  - (strlen (msg) / 2));
+- wprintw (wpopup, (char *) msg);
++ wprintw (wpopup, "%s", (char *) msg);
+  wmove (wpopup, FILE_ERR_HEIGHT - 3, (FILE_ERR_WIDTH / 2) -
+ (strlen (strerror (errno)) + strlen ("Reason: ")) / 2);
+  wprintw (wpopup, "Reason: %s", 
+--- a/src/widgets.c
 b/src/widgets.c
+@@ -366,7 +368,7 @@
+if (!rstr.str)
+{
+   wmove (win, 4, boxleft);
+-  wprintw (win, (char *) NOT_ENOUGH_MEMORY);
++  wprintw (win, "%s", (char *) NOT_ENOUGH_MEMORY);
+   getch ();
+   return NULL;
+}
diff -Nru ncurses-hexedit-0.9.7+orig/debian/patches/series ncurses-hexedit-0.9.7+orig/debian/patches/series
--- ncurses-hexedit-0.9.7+orig/debian/patches/series	2021-02-06 23:35:31.0 +0200
+++ ncurses-hexedit-0.9.7+orig/debian/patches/series	2023-02-10 02:01:23.0 +0200
@@ -17,3 +17,4 @@
 fix_buffer_overruns.patch
 fix_spelling_errors.patch
 gcc_10.patch
+ncurses.patch

Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings

[H. S. Teoh]

On Thu, Feb 09, 2023 at 08:57:22PM +0100, Tormod Volden wrote:
> > Since upgrading to 6.06+dfsg1-2, I have been unable to run
> > xscreensaver-settings or xscreensaver-demo.  The main xscreensaver
> 
> >From which version did you upgrade?

5.45+dfsg1-2


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.

Bug#1030961: ftp.debian.org: auto-reject based on lintian license-problem-md5sum-non-free-file blocks icc-profiles

[Jonas Smedegaard]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I maintain the package icc-profiles but cannot issue any updates because
it (correctly!) gets detected that it contains non-free files which
belongs to... icc-profiles!

I get a rejection email with a bunch of messages like this:

> icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file 
> ECI/PSO_Coated_300_NPscreen_ISO12647_eci.icc usual name is
PSO_Coated_300_NPscreen_ISO12647_eci.icc. Does not allow modification See also 
https://packages.debian.org/sid/icc-profiles.', automatically rejected package.

Please loosen the check to not be imposed on icc-profiles itself.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmPlh1cACgkQLHwxRsGg
ASG63w//ZSKo43GEcnA/m17Ncf7zhjE1QC7M+7GmhWL8BTBqLDJSPiVxE114zF/t
zbL9+U0sDs+ELGn2Y8yAzFhE/chDyHCMp7E3wbHPiTn6+fIMsZP6BhINdnZM7UrZ
nb6u3viGz3kOgsxq846osCYC5XfbpCeHZu8MJf9jgqAu8yBchjwGDqaTlQU2N79r
60duPs6moL1p5yy4oA4aBpGADoV1kKgN8Kzfi9EVGNcpuXnlw5ASKpfFfBkpkShx
T9CHw32De2XUR8TZuXm/HdT4Pwoh980mTTist8VYxq5x6ETmqsWSraYOFYid5Keq
76MzbypsNYG0mVTjJoQzW8pB+690H70E1xpRZ5+2molwZQY54ycX55rdkQtYQE9+
OiZ7nnvHrK/JgOEsnoK7D8lWa2Jhvatl9Kgu5BeSZi7jomvcinOj0kDXesAyKnoV
ymAunfRYf6XNt0mbudd2npiDABKSVNvfjedZ7FOzTHbe7MC/8aW10VvhdTknQAP+
VW02k54IY2Oy6/FmiwxuOjSn85sfV3SipvgILPIKBUr99taG7YatbkNg+KLQHIhI
3xtXV1hhmrKnSsmSJguj7IiAcY1mzh4CoHx5qk8lLy5lK46hOcM8io6CSVPkw2vx
Yl2b2WHkHJljPphDcoMqRCJ+rnJGzsxsxt/7Mg9F+PpC26XPQGA=
=AwgM
-END PGP SIGNATURE-

Bug#1030960: debootstrap: Add Trisquel to debootstrap

[Denis 'GNUtoo' Carikli]

Package: debootstrap
Version: 1.0.118ubuntu1.8+10.0trisquel6
Severity: wishlist
Tags: patch

Dear Maintainer,

Trisquel is a GNU/Linux distribution certified by the FSF that is
based on Ubuntu.

Adding Trisquel to debootstrap would enable to generate Trisquel
images (with mkosi, debuerreotype, or even debootstrap) from
other distributions.

This could also benefit Replicant (an Android distribution
certified by the FSF) as it depends on various Trisquel versions
for building the images.

This merge request adds Trisquel to debootstrap:
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/89

Thanks a lot in advance for the review.

Denis.

-- System Information:
Debian Release: bullseye/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.6-gnu-2-vanilla (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debootstrap depends on:
ii  wget  1.20.3-1ubuntu2

Versions of packages debootstrap recommends:
ii  gnupg   2.2.19-3ubuntu2.2
pn  ubuntu-keyring  

Versions of packages debootstrap suggests:
pn  arch-test   
pn  squid-deb-proxy-client  

-- no debconf information

Bug#964540: dropwatch build times out in the testsuite

[Santiago Vila]

Hello.

Since this package is orphaned, I've just made a QA upload
with the absolute minimal change below which seems to fix
the issue.

I'll care about putting this in salsa tomorrow.

Thanks.

diff -Nru dropwatch-1.5.4/debian/changelog dropwatch-1.5.4/debian/changelog
--- dropwatch-1.5.4/debian/changelog2022-11-01 14:05:23.0 +0100
+++ dropwatch-1.5.4/debian/changelog2023-02-10 00:30:00.0 +0100
@@ -1,3 +1,11 @@
+dropwatch (1.5.4-2) unstable; urgency=medium
+
+  * QA upload.
+  * Add psmisc to Build-Depends. Hopefully the test suite will not hang
+after this. Reported by Matthias Klose. Closes: #964540.
+
+ -- Santiago Vila   Fri, 10 Feb 2023 00:30:00 +0100
+
 dropwatch (1.5.4-1) unstable; urgency=medium
 
   * QA upload.

diff -Nru dropwatch-1.5.4/debian/control dropwatch-1.5.4/debian/control
--- dropwatch-1.5.4/debian/control  2022-11-01 14:05:23.0 +0100
+++ dropwatch-1.5.4/debian/control  2023-02-10 00:30:00.0 +0100
@@ -10,6 +10,7 @@
 ,libpcap-dev
 ,libreadline-dev
 ,pkgconf | pkg-config
+,psmisc
 Rules-Requires-Root: no
 Homepage: https://github.com/nhorman/dropwatch
 Vcs-Git: https://salsa.debian.org/debian/dropwatch.git

Bug#1030959: singular-doc: install-info reports /usr/share/info/singular.info has no info dir entry

[Eric Towers]

Package: singular-doc
Version: 1:4.3.1-p3+ds-1
Severity: normal
X-Debbugs-Cc: fuzzye...@gmail.com

Dear Maintainer,
On bookworm, the last few apt dist-upgrade runs have ended with the diagnostic 
"install-info: warning: no info dir entry in `/usr/share/info/singular.info'".  
dpkg-query -S singular.info reports that singular-doc provides this file.  apt 
reinstall singular-doc ends with the same diagnostic.

Interestingly, the file /usr/share/info/singular.info exists and starts 
This is singular.info, produced by makeinfo version 4.13 from
singular.tex.

This is the texinfo file describing Singular (version 4.3.1)
and goes on for about 6.2 MB.  Oddly, this is the only info file in that 
directory that is not an .info.gz...  (I can't verify that gzip 
/usr/share/info/singular.info worked because apt dist-upgrades are NO-OPs for 
me right now.)


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

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

singular-doc depends on no packages.

singular-doc recommends no packages.

Versions of packages singular-doc suggests:
ii  atril [pdf-viewer] 1.26.0-2+b1
ii  chromium [www-browser] 109.0.5414.119-1
ii  evince [pdf-viewer]43.1-2+b1
ii  firefox-esr [www-browser]  102.6.0esr-1
ii  lynx [www-browser] 2.9.0dev.12-1
ii  singular   1:4.3.1-p3+ds-1
ii  w3m [www-browser]  0.5.3+git20230121-2

-- no debconf information

Bug#1030676: pysdl2: autopkgtest failure on s390x

[James Addison]

Source: pysdl2
Followup-For: Bug #1030676

On Tue, 07 Feb 2023 at 21:07:50 +, Simon McVittie wrote:
> I have intentionally not uploaded those versions to unstable when doing
> team-uploads to stop it from regressing and blocking libsdl2, because
> I have no good way to test them: nothing in Debian depends on pysdl2,
> and I'm not actively using it for any non-Debian software.

Thanks, Simon - I hadn't considered the reasons why it might make sense _not_
for more recent versions to have been uploaded, and wanted to ensure that your
investigation work upstream (which I read through) was linked from the bug.

Agreed that RC this probably was not (although who knows, perhaps we'll learn
of an appreciative s390x gamer some day).

Bug#1029164: Main. and order_by_innodb testing

[Daniel Black]

Rex has created a commit to try to identify the cause of the problem
in the main.order_by_innodb tests:

https://github.com/MariaDB/server/commit/a0300390b5efbd7b408cb166e0ee715364a85f3c

I don't know if salsa supports this, but a PR is
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/35.

If this could be applied and Rex notified of the build logs that would be great.

Bug#1030957: release.debian.org: please have rust-rustls ignore CI tests for s390x and ppc64el

[Jonas Smedegaard]

Package: release.debian.org
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

ckage src:rust-rustls is not migrating to testing because tests fail for
s390x and ppc64el.  On both arches the failure is that the test
environment thinks it needs to install an arch-specific
librust-rustls-dev to satisfy a virtual dependency pointing back to
itself, which is (since recently) an arch-all package.

I can only interpret that as the test environment on thos arches being
broken.  Please don't punish the package for that :-(

There seems to be same problem for rust-oxhttp, and rust-hyper-rustls.
Do you want a separate bugreport for each, or is it fine just mentioning
it here?

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmPlesoACgkQLHwxRsGg
ASHWew/+P4ARdVeceSslT016FEdGE8y5oQ0Ee/gcNqLFQN7U/xwLLvyFq2PDcIWH
uwAJUL4QVipEwQd1J7AzpCuWly5ac7G1iQB/wAslAs9SbFeoQ2rOhZNQZv6Qf9vj
OkLB1v1hDkGgiQAjwDSc7mUhn7O/p/o0FZwlbtcoMAFm5se8rWptrMvmcUy9AweR
PJkc08guOQD8+Fn28BwbEduprHCqPwwdVWzgMZwNT7ID10TTl7nuY365HvguOa5z
iHcctNoQd4Sm3wQMp3YaZp0LFa7MpZH6wvf4mNGheKzLsn0HZuRaVd0gJBo5MJCD
OZ9izaiicGGgE+2QGOLoomT9/UT6K6xsfkTJnDnXjyOYH4FmPNorCNlfz/dvKtEo
PdAvoxE9gO+sMXFUuxc7HJZAxV1zOo85WGBoB8Bjfb0sSX9+KC/GyULLdVEGJ0su
zKzLh99jQRhLXPYifBt9JpstLWdg7WGOd1GEvNW0J8/lpQoC627TDF4hutLb4KFl
Ffzl9Y91e1oI59L5mO8BfYezjJe8VifFM4QR2kQqGUe/7fIUVRFvNGis/FKX67wn
b2/t0rBJymqkdrz+hoavmV/iO3iBiNjDCLxak3VW6d8CVsfkn3mHVZeJ4UQU9qyu
05j7I0D1rSagheRAjpfVyfC3yIMMz1/GaFQGOqbJIimJhQ7mNhc=
=GkQb
-END PGP SIGNATURE-

Bug#1030956: yarnpkg key is out of date

[David Mandelberg]

Source: extrepo-data
Version: 1.0.3

Running this command: extrepo enable yarnpkg && apt-get update

Gives this error:
Err:4 https://dl.yarnpkg.com/debian stable InRelease
  The following signatures were invalid: EXPKEYSIG 23E7166788B63E1E Yarn
Packaging 

I think the key just needs to be updated?

Bug#1030096: dask.distributed intermittent autopkgtest fail

[Rebecca N. Palmer]

Upstream's reason for treating warnings as errors is just generic 'find 
potential problems' (https://github.com/dask/distributed/issues/6048).


On 09/02/2023 21:33, Diane Trout wrote:

That worked, but armel (test_steal_twice), armhf (something outright
crashing) and s390x (lots) all failed.


Aren't those all still on -1? I only see amd64 and arm64 having run
2022.12.1+ds1-2

At https://ci.debian.net/packages/d/dask.distributed/


That summary listing is the wrong place to look for that information - 
either use tracker.debian.org or click the 'testing' (*not* 'unstable') 
links.


All 3 of them have failed repeatedly.  (armel's failure is sometimes 
test_single_executable_deprecated instead.)


The armhf crash is a bus error (possibly unaligned memory access?) in 
protocol/tests/test_highlevelgraph.py, and the traceback suggests it 
*may* be in something other than dask.distributed, though it's also 
possible that dask.distributed is copying objects around with the wrong 
alignment:


  File 
"/usr/lib/python3/dist-packages/pandas/core/array_algos/take.py", line 
163 in _take_nd_ndarray
  File 
"/usr/lib/python3/dist-packages/pandas/core/array_algos/take.py", line 
117 in take_nd
  File 
"/usr/lib/python3/dist-packages/pandas/core/internals/blocks.py", line 
880 in take_nd
  File 
"/usr/lib/python3/dist-packages/pandas/core/internals/managers.py", line 
752 in 
  File 
"/usr/lib/python3/dist-packages/pandas/core/internals/managers.py", line 
751 in reindex_indexer
  File 
"/usr/lib/python3/dist-packages/pandas/core/internals/managers.py", line 
978 in take
  File "/usr/lib/python3/dist-packages/pandas/core/generic.py", line 
3886 in _take
  File "/usr/lib/python3/dist-packages/pandas/core/generic.py", line 
3871 in take
  File "/usr/lib/python3/dist-packages/dask/dataframe/backends.py", 
line 517 in group_split_pandas

  File "/usr/lib/python3/dist-packages/dask/utils.py", line 640 in __call__
  File "/usr/lib/python3/dist-packages/dask/dataframe/shuffle.py", line 
941 in shuffle_group

  File "/usr/lib/python3/dist-packages/dask/layers.py", line 47 in __call__
  File "/usr/lib/python3/dist-packages/distributed/worker.py", line 
3047 in apply_function_simple
  File "/usr/lib/python3/dist-packages/distributed/worker.py", line 
3025 in apply_function
  File 
"/usr/lib/python3/dist-packages/distributed/_concurrent_futures_thread.py", 
line 65 in run
  File 
"/usr/lib/python3/dist-packages/distributed/threadpoolexecutor.py", line 
57 in _worker

  File "/usr/lib/python3.11/threading.py", line 975 in run
  File "/usr/lib/python3.11/threading.py", line 1038 in _bootstrap_inner
  File "/usr/lib/python3.11/threading.py", line 995 in _bootstrap

Bug#1030955: golang-github-hhatto-gorst: autopkgtest failure

[Adrian Bunk]

Source: golang-github-hhatto-gorst
Version: 0.0~git20181029.ca9f730-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-hhatto-gorst/31199561/log.gz

...
   dh_auto_test -O--builddirectory=_build -O--buildsystem=golang
cd _build && go test -vet=off -v -p 64 github.com/hhatto/gorst 
github.com/hhatto/gorst/cmd/gorst
=== RUN   TestExampleOfSimpleText
2023/02/09 22:05:24 open data/simple.rst: no such file or directory
--- PASS: TestExampleOfSimpleText (0.00s)
=== RUN   TestExampleOfPydebsignReadme
2023/02/09 22:05:24 open data/pydebsign.readme.rst: no such file or directory
rst_test.go:46: invalid convert
--- FAIL: TestExampleOfPydebsignReadme (0.00s)
=== RUN   TestExampleOfMeowReadme
2023/02/09 22:05:24 open data/meow.readme.rst: no such file or directory
--- PASS: TestExampleOfMeowReadme (0.00s)
=== RUN   TestExampleOfAutopep8Readme
2023/02/09 22:05:24 open data/autopep8.readme.rst: no such file or directory
rst_test.go:61: contain heading in autopep8
rst_test.go:64: para in autopep8
--- FAIL: TestExampleOfAutopep8Readme (0.00s)
=== RUN   TestExampleOfHeadingTitle
--- PASS: TestExampleOfHeadingTitle (0.00s)
=== RUN   TestExampleOfHeading
--- PASS: TestExampleOfHeading (0.00s)
=== RUN   TestAutoLink
--- PASS: TestAutoLink (0.00s)
=== RUN   TestLinkContainsUnderbar
--- PASS: TestLinkContainsUnderbar (0.00s)
=== RUN   TestLinkComplexCases
--- PASS: TestLinkComplexCases (0.00s)
=== RUN   TestUnquotedRefLinkUnderbarWithDot
--- PASS: TestUnquotedRefLinkUnderbarWithDot (0.00s)
=== RUN   TestUnquotedRefLinkUnderbarWithDotAndList
--- PASS: TestUnquotedRefLinkUnderbarWithDotAndList (0.00s)
=== RUN   TestSimpleLinkRef
--- PASS: TestSimpleLinkRef (0.00s)
=== RUN   TestNotLinkRef
--- PASS: TestNotLinkRef (0.00s)
=== RUN   TestEmbeddedURI
--- PASS: TestEmbeddedURI (0.00s)
=== RUN   TestEmbeddedURIwithNewline
--- PASS: TestEmbeddedURIwithNewline (0.00s)
=== RUN   TestEmbeddedAnonymouseURI
--- PASS: TestEmbeddedAnonymouseURI (0.00s)
=== RUN   TestImage
--- PASS: TestImage (0.00s)
=== RUN   TestImageWithAlt
--- PASS: TestImageWithAlt (0.00s)
=== RUN   TestImageWithTarget
--- PASS: TestImageWithTarget (0.00s)
=== RUN   TestImageWithAltAndTarget
--- PASS: TestImageWithAltAndTarget (0.00s)
=== RUN   TestGridTable
--- PASS: TestGridTable (0.00s)
=== RUN   TestHeaderLessGridTable
--- PASS: TestHeaderLessGridTable (0.00s)
=== RUN   TestApplicationDepent
--- PASS: TestApplicationDepent (0.00s)
FAIL
FAILgithub.com/hhatto/gorst 0.006s
?   github.com/hhatto/gorst/cmd/gorst   [no test files]
FAIL
dh_auto_test: error: cd _build && go test -vet=off -v -p 64 
github.com/hhatto/gorst github.com/hhatto/gorst/cmd/gorst returned exit code 1
make: *** [debian/rules:6: build] Error 25


The Ubuntu diff contains a patch that looks like a workaround (untested).

Bug#1030683: gnome-shell-extensions-extra: unmaintainable

[Daniel Baumann]

Hi Simon,

On 2/9/23 14:50, Simon McVittie wrote:
> My understanding from the changelog is that the maintainer Daniel Baumann
> first packaged a bunch of GNOME Shell extensions according to the GNOME
> team's usual convention (one package per independent upstream project),
> and then was asked by the ftp team to replace them with a single package
> collecting together multiple unrelated extensions?

yes, that's correct.

> If one of the bundled extensions isn't ready for a new GNOME Shell and
> can't easily be ported, then "hold back all the bundled extensions" isn't
> really an option: we are not going to delay a GNOME Shell upgrade just
> because an extension isn't keeping up, because GNOME Shell is much more
> important to the distribution than any individual extension.

absolutely, yes; however..

> The options
> would be to drop incompatible extensions from the bundled package, or
> to remove the entire bundled package from testing until it can be made
> compatible again.

..I don't think for this case it matters whetever an extension is part
of an aggregated package or not:

  * if it's a standalone src+bin package, the extension would have an RC
bug and would eventually be removed from testing until it's fixed.

  * if it's part of an aggregated package, the extension would be
dropped from the aggregated package until it's fixed.

so, basically same result from a testing users point of view wrt/
availability of the extension in the archive.

Regards,
Daniel

Bug#1030954: quorum: ftbfs with LTO (link time optimization) enabled

[Sergio Durigan Junior]

Package: src:quorum
Version: 1.1.1-7
Severity: minor
Tags: sid bookworm
User: debian-...@lists.debian.org
Usertags: ftbfs-lto

This package currently fails to build (at least on the amd64
architecture) with link time optimizations enabled.  For a background
for LTO please see

https://wiki.debian.org/ToolChain/LTO

The goal is to enable this optimization by default in an upcoming
Debian release in dpkg-buildflags for 64bit architectures.  The goal
is to get this package to build with link time optimizations, or to
explicitly disable link time optimizations for this package build.

To reproduce the build failure, enable the lto optimization in
testing/unstable by adding "optimize=+lto" to DEB_BUILD_MAINT_OPTIONS
in the debian/rules file, or if this macro is unset, just set it:

export DEB_BUILD_MAINT_OPTIONS = optimize=+lto

Please try to fix the build with lto enabled, fixing the packaging or
forwarding the issue upstream. If the issue cannot be fixed,
explicitly disallow building the package with lto by adding to your
rules file:

export DEB_BUILD_MAINT_OPTIONS = optimize=-lto

or adding that string to your existing setting of DEB_BUILD_MAINT_OPTIONS.

This is the excerpt of the build log that shows the failure:

--8<---cut here---start->8---
/bin/bash ./libtool  --tag=CXX   --mode=link g++ -Wall -g -O2 -std=c++0x 
-Werror -g -O2 -ffile-prefix-map=/<>=. -flto=auto -f
fat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-DHAVE_NUMERIC_LIMITS128  -flto=auto -ffat-lto-objects -Wl,-z,re
lro -Wl,-z,now -o quorum_error_correct_reads src/error_correct_reads.o 
src/err_log.o -ljellyfish-2.0 -lpthread  -lrt -lpthread
libtool: link: g++ -Wall -g -O2 -std=c++0x -Werror -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -fstack-protec
tor-strong -Wformat -Werror=format-security -DHAVE_NUMERIC_LIMITS128 -flto=auto 
-ffat-lto-objects -Wl,-z -Wl,relro -Wl,-z -Wl,now -o quoru
m_error_correct_reads src/error_correct_reads.o src/err_log.o  
/usr/lib/x86_64-linux-gnu/libjellyfish-2.0.so -lrt -lpthread
In member function '__ct ', 
  
inlined from '__ct_base .constprop' at 
./include/jflib/multiplexed_io.hpp:82:18:
./include/jflib/pool.hpp:36:26: error: argument 1 value '18446744073709551615' 
exceeds maximum object size 9223372036854775807 [-Werror=al
loc-size-larger-than=]   
   36 |   size_(size), elts_(new T[size]), B2A(size, elts_), A2B(size, 
elts_)
  |  ^ 
/usr/include/c++/12/new: In member function '__ct_base .constprop': 
  
/usr/include/c++/12/new:128:26: note: in a call to allocation function 
'operator new []' declared here
  128 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW 
(std::bad_alloc)
  |  ^ 
lto1: all warnings being treated as errors
make[3]: *** [/tmp/ccrQQ24o.mk:5: /tmp/ccOYZvOS.ltrans1.ltrans.o] Error 1
make[3]: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:897: quorum_error_correct_reads] Error 1
make[2]: Leaving directory '/<>'   
make[1]: *** [Makefile:707: all] Error 2
make[1]: Leaving directory '/<>'
dh_auto_build: error: make -j1 returned exit code 2
make: *** [debian/rules:12: binary] Error 25
--8<---cut here---end--->8---

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1030096: dask.distributed intermittent autopkgtest fail

[Rebecca N. Palmer]

On 09/02/2023 21:33, Diane Trout wrote:

The place to ask is debian-release; no comment on the likely result.



I'll try to ask.


Looking at the old logs, I think the old "passing" test *didn't actually 
run* the tests (just collected them, which was enough to fail on a 
dask/dask.distributed mismatch), because it did -k "not ( $SKIP_TEST )" 
when the variable was actually called SKIP_TESTS, causing


ERROR: Wrong expression passed to '-k': not (  ): at column 8: expected 
not OR left parenthesis OR identifier; got right parenthesis


and apparently-no tests run.

(This was fixed in
https://salsa.debian.org/python-team/packages/dask.distributed/-/commit/24cb367f4608a72d9f770cc619af3520bfdb1990 
, apparently without noticing that it had ever existed.)


Which makes this not-a-regression...

Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12

[Roger Shimizu]

Dear Jochen,

Thanks for your reply, and kindness trying to help!

> On Thu, Feb 9, 2023 at 1:30 PM Jochen Sprickerhof 
wrote:
> What exactly did you test?

Please try the version in experimental.
and also refer the version info of this ticket:

Found in versions android-platform-frameworks-base/1:10.0.0+r36-5,
android-platform-frameworks-base/13~beta3-1~exp1
Fixed in version android-platform-frameworks-base/1:10.0.0+r36-6

Cheers,
Roger

Bug#1030953: pipewire-libcamera: Please rename to libspa-0.2-libcamera

[Thomas Uhle]

Package: pipewire-libcamera
Version: 0.3.60-3
Severity: wishlist
X-Debbugs-Cc: Dylan Aïssi 

Dear maintainers,

for the sake of consistency, can you please rename the package 
"pipewire-libcamera" to "libspa-0.2-libcamera" similar to the other 
packages libspa-0.2-bluetooth and libspa-0.2-jack.


Dylan has already told me that it's too late for Debian bookworm because 
of the upcoming freeze. So this is more like a reminder for later in the 
year.


Thank you in advance!

Best regards,

Thomas Uhle

Bug#1030952: npm depends on webpack and 200+ other packages

[Christopher Hagar]

Package: npm
Version: 9.2.0~ds1-1
Severity: normal
X-Debbugs-Cc: cmha...@gmail.com

After recent changes in npm and node-css-loader (node-postcss-selector-parser),
installing npm installs webpack and 200+ other node-related packages.

Given that npm is a package manager, it should not require so many
dependencies.

Morever, npm is for installing packages outside of the Debian package manager!
It should not bring in tons of Debian packages that will never be used.

Debian Policy says that Depends declares an "absolute dependency". Recommends
declares a "strong, but not absolute, dependency". Suggests declares that a
packages "may be more useful with one or more others". And it is possible there
should be no dependency relationship of any kind for npm depending on webpack.

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
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 npm depends on:
ii  ca-certificates   20211016
ii  node-abbrev   1.1.1+~1.1.2-1
ii  node-agent-base   6.0.2+~cs5.4.2-2
ii  node-aproba   2.0.0-3
ii  node-archy1.0.0-6
ii  node-base64-js1.5.1+dfsg+~1.3.0-2
ii  node-binary-extensions2.2.0-2
ii  node-cacache  17.0.3+~cs10.3.7-1
ii  node-chalk5.2.0-1
ii  node-chownr   2.0.0-2
ii  node-ci-info  3.6.1+~cs1.1.0-1
ii  node-cli-table [node-cli-table3]  0.3.11+~cs0.13.4-3
ii  node-colors   1.4.0-4
ii  node-columnify1.6.0+~1.5.1-1
ii  node-css-loader [node-postcss-selector-parser]5.0.1+~cs14.0.5-1
ii  node-css-selector-tokenizer [node-cssesc] 0.8.0+~cs4.8.3-1
ii  node-debug4.3.4+~cs4.1.7-1
ii  node-depd 2.0.0-2
ii  node-diff 5.0.0~dfsg+~5.0.1-4
ii  node-encoding 0.1.13-2
ii  node-events   3.3.0+~3.0.0-3
ii  node-glob 8.0.3+~cs8.4.15-1
ii  node-got  11.8.5+~cs58.13.36-3
ii  node-graceful-fs  4.2.10-1
ii  node-gyp  9.3.0-2
ii  node-hosted-git-info  6.1.1-2
ii  node-https-proxy-agent [node-http-proxy-agent]5.0.1+~cs8.0.0-3
ii  node-ieee754  1.2.1-3
ii  node-ini  3.0.1-2
ii  node-ip   2.0.0+~1.1.0-1
ii  node-ip-regex 4.3.0+~4.1.1-1
ii  node-json-parse-better-errors 1.0.2+~cs3.3.1-2
ii  node-jsonparse1.3.1-10
ii  node-lru-cache7.14.1-1
ii  node-minimatch5.1.1+~5.1.2-1
ii  node-minipass 3.3.6+~cs9.4.19-1
ii  node-mkdirp   1.0.4+~1.0.2-4
ii  node-ms   2.1.3+~cs0.7.31-3
ii  node-negotiator   0.6.3+~0.6.1-1
ii  node-nopt 5.0.0-4
ii  node-normalize-package-data   4.0.1+~2.4.1-1
ii  node-npm-bundled  2.0.1-2
ii  node-npm-package-arg  10.0.0+~3.0.0-2
ii  node-npmlog   7.0.1+~4.1.4-1
ii  node-once 1.4.0-7
ii  node-p-map4.0.0+~3.1.0+~3.0.1-1
ii  node-promise-retry2.0.1-4
ii  node-promzard 0.3.0-2
ii  node-read 1.0.7-5
ii  node-read-package-json [node-npm-normalize-package-b  5.0.2+~2.0.0-1
in]
ii  node-rimraf   3.0.2-2
ii  node-semver   7.3.5+~7.3.9-2
ii  

Bug#1030096: dask.distributed intermittent autopkgtest fail

[Diane Trout]

On Thu, 2023-02-09 at 21:21 +, Rebecca N. Palmer wrote:
> 
> 
> On 09/02/2023 17:07, Diane Trout wrote:
> > Would it make sense to drop those errors back to warnings, and do
> > you
> > know enough about the setup.cfg language to do it quickly?
> > 
> 
> Plausibly yes but I don't actually know, and remove the 'error' line
> at 
> setup.cfg:60.

My current frustrated idea is to do what's going on in d/rules and skip
the isinstalled tests.

My local build is running now, and I was probably thinking of pushing a
proposed -3 to salsa in an hour or so 

> 
> > I went ahead and requested another run for the failed amd64 run and
> > left the passing arm64 run alone.
> 
> That worked, but armel (test_steal_twice), armhf (something outright 
> crashing) and s390x (lots) all failed.

Aren't those all still on -1? I only see amd64 and arm64 having run
2022.12.1+ds1-2

At https://ci.debian.net/packages/d/dask.distributed/

> 
> The place to ask is debian-release; no comment on the likely result.
> 

I'll try to ask.

Diane

Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12

[Jochen Sprickerhof]

Hi Roger,

* Roger Shimizu  [2023-02-04 10:47]:

On Sat, Feb 4, 2023 at 12:09 AM Roger Shimizu  wrote:


control: reopen -1

Yes, it ftbfs on sid now.
And I tried latest upstream 13.0.0_r24, result is the same.
Have to fix this issue before we can migrate to sid.


Error log is not originally reported, for latest error log please refer to:
- https://bugs.debian.org/1012890#17

I guess the issue is caused due to upstream using clang stdc++ lib,
but we're using gcc/g++ one.
Those two have slight differences.


I can't reproduce this. The unstable version (1:10.0.0+r36-10) builds 
fine in sbuild and also reproducible builds shows no ftbfs:


https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/i386/android-platform-frameworks-base.html

What exactly did you test?

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1007026: rust-weedle - needs nom 5

[Peter Green]

reopen 1007026
thanks


  * Revert to nom 4, porting to nom 7 seems to be non-trivial and I do not
want to further increase the proliferation of nom versions in Debian.


As I said in the initial mail, I did indeed patch weedle to revert
to nom 4. However in doing so I caused an API break. As such I don't
think this package in it's current state is fit for release.

Bug#1030951: dvhtool: diff for NMU version 1.0.1-6.1

[Adrian Bunk]

Package: dvhtool
Version: 1.0.1-6
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for dvhtool (versioned as 1.0.1-6.1) and uploaded 
it to DELAYED/1. Please feel free to tell me if I should cancel it.


https://tracker.debian.org/pkg/dvhtool

Issues preventing migration:
∙ ∙ autopkgtest for dvhtool/1.0.1-6: amd64: Regression ♻ , arm64: Regression ♻ 
, armel: Regression ♻ , armhf: Regression ♻ , i386: Regression ♻ , ppc64el: 
Regression ♻ , s390x: Regression ♻ 


https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dvhtool/30949163/log.gz

...
autopkgtest [09:28:15]: test command1: dvhtool --print-all 
/usr/share/doc/dvhtool/examples/volhdr-1.dat
autopkgtest [09:28:15]: test command1: [---
bash: line 1: dvhtool: command not found
autopkgtest [09:28:15]: test command1: ---]
autopkgtest [09:28:15]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 127



cu
Adrian
diff -Nru dvhtool-1.0.1/debian/changelog dvhtool-1.0.1/debian/changelog
--- dvhtool-1.0.1/debian/changelog	2022-01-13 22:40:03.0 +0200
+++ dvhtool-1.0.1/debian/changelog	2023-02-09 23:23:54.0 +0200
@@ -1,3 +1,10 @@
+dvhtool (1.0.1-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the path to dvhtool in the autopkgtest.
+
+ -- Adrian Bunk   Thu, 09 Feb 2023 23:23:54 +0200
+
 dvhtool (1.0.1-6) unstable; urgency=medium
 
   [ Guido Günther ]
diff -Nru dvhtool-1.0.1/debian/tests/control dvhtool-1.0.1/debian/tests/control
--- dvhtool-1.0.1/debian/tests/control	2022-01-13 22:38:52.0 +0200
+++ dvhtool-1.0.1/debian/tests/control	2023-02-09 23:23:51.0 +0200
@@ -1,2 +1,2 @@
-Test-Command: dvhtool --print-all /usr/share/doc/dvhtool/examples/volhdr-1.dat
+Test-Command: /usr/sbin/dvhtool --print-all /usr/share/doc/dvhtool/examples/volhdr-1.dat
 Depends: @

Bug#1030096: dask.distributed intermittent autopkgtest fail

[Rebecca N. Palmer]

On 09/02/2023 17:07, Diane Trout wrote:

Would it make sense to drop those errors back to warnings, and do you
know enough about the setup.cfg language to do it quickly?



Plausibly yes but I don't actually know, and remove the 'error' line at 
setup.cfg:60.



I went ahead and requested another run for the failed amd64 run and
left the passing arm64 run alone.


That worked, but armel (test_steal_twice), armhf (something outright 
crashing) and s390x (lots) all failed.




Also how did numba 0.56.4-1 get overridden to be back in testing?

Can we get dask.distributed forced back in? It looks like it mostly
works, it feels like we're mostly fighting over it not being robust to
environment specific issues.


The place to ask is debian-release; no comment on the likely result.

Bug#1030775: xtensor: baseline violation: builds with -march=native

[Drew Parsons]

Source: xtensor
Followup-For: Bug #1030775
Control: tags -1 wontfix moreinfo

I think this is not a bug.  xtensor is a header-only library. The
builds you're seeing with -march=native are in the tests only, not
compiled into the binary package.

We could make some effort to prevent the tests running with
-march=native. But I prefer to leave the flag there for tests, since
it better reflects how the package might be used by an end-user.

I think we can close this bug, but I'll leave it open for a little
while in case further discussion is needed.

Bug#1030950: btrfs-convert is built without support for reiserfs

[Oswald Buddenhagen]

Package: btrfs-progs
Version: 6.1.2-1
Severity: normal

for the purpose of helping people to move away from reiserfs, it would 
make sense to actually build btrfs-convert with support for it.

the catch is that libreiserfscore is not packaged separately; rather, 
it's built into reiserfsprogs. i guess factoring out a static-only 
libreiserfscore-dev would make sense.

Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings

[Tormod Volden]

>From searching about failing X_SetInputFocus requests, one common
cause is that the window hasn't been mapped by the window manager yet.
I notice that Teoh is using the ratpoison window manager.

Marco, which window manager are you using?

Bug#1030382: encourage Vcs-Git over other Vcs-* headers

[Sean Whitton]

Hello,

On Fri 03 Feb 2023 at 05:24PM GMT, Jelmer Vernooij wrote:

> Package: debian-policy
> Severity: wishlist
>
> Policy currently describes Vcs-* headers as something optional, but stops to
> endorse a particular Vcs.
>
> At this point, it seems uncontroversial to encourage use of Vcs-Git
> specifically here. Apart from technical arguments, it's the vcs that the
> majority of packages in the archive uses - and thus will have the better
> tooling, less of a learning curve for other contributors, etc.
>
> There are very few holdouts of other vcses in the archive. I count 62
> (ignoring those with an alioth URL):
>
>  * 26 on Svn
>  * 3 on Cvs
>  * 4 on Hg (2 are hg/hg-buildpackage)
>  * 39 on bzr (half of these are actually bzr and related packages, which I 
> maintain)

This strikes me as a matter for devref not Policy?

-- 
Sean Whitton

Bug#1011656: [seqan/flexbar] Please upgrade to onetbb (Issue #38)

[Andreas Tille]

Hi,

Am Thu, Feb 09, 2023 at 07:56:16AM -0800 schrieb Liam Keegan:
> @tillea I've made an initial attempt at this in #41 if helpful for you
> 
> I don't actually use this software directly so haven't been able to test it, 
> but at least it compiles...

Thanks a lot for the patch.  I confirm the binary builds with your patch which 
I applied to the Debian packaging.  Unfortunately the test seems to end in some 
endless loop:

cd test ; \
export PATH="/build/flexbar-3.5.0/obj-x86_64-linux-gnu:$PATH" ; \
echo $PATH ; \
export HOME=/tmp ; \
which flexbar ; \
./flexbar_test.sh
/build/flexbar-3.5.0/obj-x86_64-linux-gnu:/usr/sbin:/usr/bin:/sbin:/bin
/build/flexbar-3.5.0/obj-x86_64-linux-gnu/flexbar
  
Testing fasta:

Hopefully someone will be able to fire up gdb and find a fix.

Kind regards, Andreas.

Bug#1030883: release.debian.org: CI for rust-ureq mysteriously "in progress" for 5 days even on most powerful arches

[Paul Gevers]

Control: reassign -1 debci-collector
Control: retitle -1 missing filename sanitizing

Hi Jonas,

On 08-02-2023 21:20, Paul Gevers wrote:
So it's either the timing was extremely unfortunate and your package hit 
something unknown on our infrastructure, or it's actually the package 
that's causing issues on our infrastructure.


We have tracked down the issue and it turns out that this:

-ureq-2:gzip PASS
triggers a bug in debci. The testname is used for filenames and the 
hyphen is interpreted as an option to tar, triggering:
tar: You may not specify more than one '-Acdtrux', '--delete' or 
'--test-label' option


We're working on a fix.

@terceiro: thinking of it, should we request a CVE for this?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030949: openresolv: Typo in /usr/share/doc/openresolv/README.Debian: ATUO_MODE

[arnold metselaar]

Package: openresolv
Version: 3.12.0-3
Severity: minor

Dear Maintainer,

>From the file README.Debian:

pdnsd users are advised to follow the configuration described in
resolvconf.conf(5) and set
ATUO_MODE=
in /etc/default/pdnsd
to ensure that /etc/pdsnd.conf is used.

I assume ppnsd users should rather set
AUTO_MODE=
in /etc/default/pdnsd

Kind regards,
Arnold Metselaar


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

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

-- no debconf information

Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Bastian Blank]

Hi

On Thu, Feb 09, 2023 at 03:16:15PM -0500, Theodore Ts'o wrote:
> Right, but if the conflict in e2fsprogs-udeb prevents the installer
> from pulling in an overly new version of e2fsprogs-udeb, that woul be
> sufficient, no?

No, it does not.  Conflicts have undefined behaviour for udebs.

Bastian

-- 
There are certain things men must do to remain men.
-- Kirk, "The Ultimate Computer", stardate 4929.4

Bug#1030907: [Help] Possible scikit-learn issue (Was: Bug#1030907: umap-learn: FTBFS (failing tests))

[Drew Parsons]

On 2023-02-09 20:37, Andreas Tille wrote:

Hi again,

Am Thu, Feb 09, 2023 at 05:52:13PM +0100 schrieb Andreas Tille:

> That said, the np.matrix discrepancy was only just fixed recently, in
> December, by
> https://github.com/lmcinnes/umap/pull/946


I've updated the packaging, added the PR, fixed some test issues that
were not yet addressed by these patches but there are remaining issues:

   https://salsa.debian.org/med-team/umap-learn/-/jobs/3925631

Any idea how to fix these?




First error looks like it might be 
https://github.com/lmcinnes/umap/commit/949abd082524fce8c45dfb147bcd8e8ef49eade3


Error 2 *might* be https://github.com/lmcinnes/umap/pull/952
via umap/utils.py:161: in csr_unique

Bug#1030948: rust-test-dir: autopkgtest failure

[Adrian Bunk]

Source: rust-test-dir
Version: 0.2.0-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-test-dir/31197295/log.gz

...
running 6 tests
test tests::test_testdir_temp_dir ... ok
test tests::test_testdir_remove ... ok
test tests::test_testdir_path ... ok
test tests::test_testdir_create ... ok
test tests::test_testdir_current_dir ... FAILED
test tests::test_testdir_current_rnd_dir ... FAILED

failures:

 tests::test_testdir_current_dir stdout 
thread 'tests::test_testdir_current_dir' panicked at 'Cannot create dir in 
current directory', src/lib.rs:155:13
stack backtrace:
   0: std::panicking::begin_panic
 at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:616:12
   1: test_dir::TestDir::current
 at /usr/share/cargo/registry/test-dir-0.2.0/src/lib.rs:155:13
   2: test_dir::tests::test_testdir_current_dir
 at /usr/share/cargo/registry/test-dir-0.2.0/src/lib.rs:335:23
   3: test_dir::tests::test_testdir_current_dir::{{closure}}
 at /usr/share/cargo/registry/test-dir-0.2.0/src/lib.rs:332:5
   4: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   5: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.

 tests::test_testdir_current_rnd_dir stdout 
thread 'tests::test_testdir_current_rnd_dir' panicked at 'Cannot create temp 
dir in current directory', src/lib.rs:145:13
stack backtrace:
   0: std::panicking::begin_panic
 at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:616:12
   1: test_dir::TestDir::current_rnd
 at /usr/share/cargo/registry/test-dir-0.2.0/src/lib.rs:145:13
   2: test_dir::tests::test_testdir_current_rnd_dir
 at /usr/share/cargo/registry/test-dir-0.2.0/src/lib.rs:316:23
   3: test_dir::tests::test_testdir_current_rnd_dir::{{closure}}
 at /usr/share/cargo/registry/test-dir-0.2.0/src/lib.rs:313:5
   4: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   5: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.


failures:
tests::test_testdir_current_dir
tests::test_testdir_current_rnd_dir

test result: FAILED. 4 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; 
finished in 0.01s

error: test failed, to rerun pass `--lib`
autopkgtest [20:24:51]: test librust-test-dir-dev:: ---]
autopkgtest [20:24:51]: test librust-test-dir-dev::  - - - - - - - - - - 
results - - - - - - - - - -
librust-test-dir-dev: FAIL non-zero exit status 101

Bug#1030659: xscreensaver: segfault when starting xscreensaver-settings or xscreensaver-demo

[Tormod Volden]

retitle 1030659 xscreensaver-gl-visual did not report a GL visual!
thanks

On Thu, Feb 9, 2023 at 9:01 PM Jamie Zawinski wrote:
>
> Not having a GL visual reported here is definitely a problem in the "should 
> never happen" category, so trying to figure out where that's going wrong 
> would be helpful.
>

Yes, let's keep this bug report for this missing GL visual issue, and
rather focus on the failed "X_SetInputFocus" request in #1030909.

Tormod

Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Theodore Ts'o]

On Thu, Feb 09, 2023 at 06:55:08PM +0100, Sven Joachim wrote:
> >>
> >> Thanks from me as well :-).  To prevent e2fsprogs from migrating to
> >> testing before grub2 and breaking d-i, I am reassigning a copy of this
> >> bug back to e2fsprogs.  It may be closed once grub2 2.06-8 enters
> >> Bookworm.   Perhaps it would also be a good idea to add a versioned
> >> "Breaks: grub2-common (<< 2.06-8~)" to e2fsprogs.
> >
> > Perhaps we could just add a "Breaks: grub2-common (<< 2.06-8~)" to
> > e2fsprogs-udeb?
> 
> That is not going to help, because IIUC grub-install is run from the
> target system that you are installing, and there is no
> grub2-common-udeb.

Right, but if the conflict in e2fsprogs-udeb prevents the installer
from pulling in an overly new version of e2fsprogs-udeb, that woul be
sufficient, no?

After all, you can install e2fsprogs 1.47, and install a newer version
of grub, and there is no problem --- unless you enable the the
csum-seed function on an already installed system.  And you can't do
that, because you it's an incompat feature.

OTOH, with e2fsprogs 1.46 you can *ready* run the command "tune2fs -O
large_dir /dev/root" on a running system, and then when you reboot,
the system won't come back, because grub will see the large_dir
feature and freak out (unecessarily).  But adding an conflict with
1.46 and grub makes no sense, since it's not _that_ likely that user
will deploy that particular foot-gun.  (It happens with Arch and
Gentoo, but those users tend to be much more adventurous, aided and
abetted by Wiki pages that encourage users to help kernel developers
beta test new features.  :-)

The reason why I really don't want to add the conflicts with e2fsprogs
1.47 is because for people who are using sid, there is aboslutely
nothing wrong with installing e2fsprogs 1.47.  It's only if they use
the installer that sucks in e2fsprogs that there's a problem --- it's
not an inherent conflict with grub per se.  If it were, then we
shouldn't allow installation of e2fsprogs 1.46 because grub2 upstream
is painfully slow in putting out releases --- and that's not
reasonable.

Now, what I *could* do is change the mke2fs.conf in e2fsprogs-udeb to
remove the default use of the csum-seed feature  but is it worth
it?  Hopefully the new version of grub2 will come out soon, at which
point I would then need to revert the hacked mke2fs.conf --- and your
dup'ing this bug should prevent the installer from picking up
e2fsprogs 1.47 until the new version of grub gets released.

I'll note that grub is trying to use an independent implementation of
ext4, as opposed to using the upstream libraries such as libext2 for
ext2/3/4 and libxfs for XFS, combined with grub's very slow release
cycle, means that this kind of thing is going to be happening a *lot*.
It's something that I and Darrick Wong (the XFS maintainer) have
kvetched about a number of times on our weekly conference calls.

For example, recent grub commits that impact XFS that aren't in 2.06
include:

commit a4b495520e4dc41a896a8b916a64eda9970c50ea
Author: Erwan Velu 
Date:   Wed Aug 25 15:31:52 2021 +0200

fs/xfs: Fix unreadable filesystem with v4 superblock

The commit 8b1e5d193 (fs/xfs: Add bigtime incompat feature support)
introduced the bigtime support by adding some features in v3 inodes

Holding back file system development because grub2 uptsream is super
slow doesn't seem like a reasonable way forward, so I really don't
want to set this precedent.

Thinking about this some more, I'd much rather have some kind of
explicit scheme, such as:

   mkfs.xfs -T grub2-dumbdown /dev/XXX

Which disables various new file system features that aren't yet
supported by grub, but which users might very well want to use on
non-boot disks.  

This could be done by doing something as simple as adding to mke2fs.conf:

[fs_types]
 grub2-dumbdown = {
features = ^large_dir,^metadata_csum
 }

Then we could teach the Debian installer to use the file system usage
type "grub2-dumbdown".

Of course, moving forward we'd have to update mke2fs.conf as grub
finally learns new features, and since mke2fs.conf is a config file,
people would have to edit it by hand post-install if they have
customized it in any way.  Unless we add the above in
/etc/mke2fs.conf.d/grub2-dumbdown, and then teach mke2fs to understand
the /etc/mke2fs.conf.d directory...

  - Ted

Bug#1030659: xscreensaver: segfault when starting xscreensaver-settings or xscreensaver-demo

[Jamie Zawinski]

Not having a GL visual reported here is definitely a problem in the "should 
never happen" category, so trying to figure out where that's going wrong would 
be helpful.

-- 
Jamie Zawinski • jwz.org • dnalounge.com

Bug#1030947: scipy: FTBFS on hppa

[Mattias Ellert]

Source: scipy
Version: 1.10.0-4
Severity: important
Tags: ftbfs patch

Merge request:
https://salsa.debian.org/python-team/packages/scipy/-/merge_requests/1



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

Bug#1030946: unblock: tuiwidgets/0.2-1.1

[Christoph Hueffelmann]

Package: release.debian.org
Control: affects -1 + src:tuiwidgets
X-Debbugs-Cc: tuiwidg...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: textsh...@uchuujin.de
Severity: normal

Please unblock package tuiwidgets and hint src:tuiwidgets into testing.

The initial testing migration is blocked by the failing autopkg tests 
because the package does not build currently for armel architecture.


The package is not yet in testing and we hope to get this done before 
the deadline.



unblock tuiwidgets/0.2-1.1

Bug#1030944: notcurses: FTBFS against doctest 2.4.9

[Daniel Bungert]

Package: notcurses
Version: 3.0.7+dfsg.1-1
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

As reported[1] in github, builds of notcurses will FTBFS when built
against doctest 2.4.9.
This happens both with Debian Sid and Ubuntu Lunar.

Version 3.0.9 of notcurses works around the problem.  That version
also includes s390x fixes, unrelated to the doctest FTBFS.

-Dan

1: https://github.com/dankamongmen/notcurses/issues/2673

Bug#1030945: puddletag: No icon on Dash nor on top panel in GNOME Wayland

[Amr Ibrahim]

Package: puddletag
Version: 2.2.0-1
Severity: normal
Tags: upstream

Dear Maintainer,

In GNOME Wayland, while puddletag is running, puddletag does not show its icon
on the Dash nor on the top panel. It shows a generic icon instead.

I found this upstream commit, which may fix it:
https://github.com/puddletag/puddletag/pull/769

Best,
Amr


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

Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 puddletag depends on:
ii  libjs-sphinxdoc 5.3.0-3
ii  python3 3.11.1-3
ii  python3-acoustid1.2.2-1
ii  python3-audioread   2.1.9-3
ii  python3-certifi 2022.9.24-1
ii  python3-charset-normalizer  3.0.1-2
ii  python3-configobj   5.0.8-1
ii  python3-idna3.3-1
ii  python3-lxml4.9.2-1+b1
ii  python3-mutagen 1.46.0-1
ii  python3-pyparsing   3.0.9-1
ii  python3-pyqt5   5.15.7+dfsg-3+b3
ii  python3-pyqt5.qtsvg 5.15.7+dfsg-3+b3
ii  python3-pyqt5.sip   12.11.1-1
ii  python3-requests2.28.1+dfsg-1
ii  python3-six 1.16.0-4
ii  python3-urllib3 1.26.12-1

Versions of packages puddletag recommends:
pn  libchromaprint-tools  
pn  python3-levenshtein   

Versions of packages puddletag suggests:
pn  quodlibet  

-- no debconf information

Bug#1030907: [Help] Possible scikit-learn issue (Was: Bug#1030907: umap-learn: FTBFS (failing tests))

[Andreas Tille]

Hi again,

Am Thu, Feb 09, 2023 at 05:52:13PM +0100 schrieb Andreas Tille:
> > That said, the np.matrix discrepancy was only just fixed recently, in
> > December, by
> > https://github.com/lmcinnes/umap/pull/946

I've updated the packaging, added the PR, fixed some test issues that
were not yet addressed by these patches but there are remaining issues:

   https://salsa.debian.org/med-team/umap-learn/-/jobs/3925631 

Any idea how to fix these?

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1030943: RM: oysttyer -- ROM; Dead upstream and software is no longer allowed to interact with Twitter

[Thorsten Alteholz]

Package: ftp.debian.org
Severity: normal

As the twitter API is no longer free to use, the upstream developer of 
oysttyer stopped maintaining this software.


According to §II.a of the Developer Agreement [1] as of today it is 
forbidden to "use or access the Licensed Materials to create or attempt 
to create a substitute or similar service or product to the Twitter 
Applications"


So this software must not be used to access Tweets and Debian should no 
longer distribute it.


Apart from this, I don't think that Debian should do anything at all to 
support this plattform any longer.


   Thorsten


[1] https://developer.twitter.com/en/developer-terms/agreement

Bug#1030865: RFS: ncdu/1.18-0.2 [NMU] -- ncurses disk usage viewer

[Christian Göttsche]

On Thu, 9 Feb 2023 at 15:51, Santiago Ruano Rincón
 wrote:
>
> Have you been able to test how it builds on GNU/Hurd, and confirm it
> fixes the FTBFS?

I have not tested the fixes directly on GNU/Hurd.
But the main difference for the build is the absence of
, and I tested building with HAVE_LINUX_MAGIC_H in
config.h commented out.
Without the two patches the build fails similar to the buildd log, and
with them included the build passes.

Bug#1026725: python-structlog: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.11 3.10" returned exit code 13

[Nick Rosbrook]

Package: python-structlog
Followup-For: Bug #1026725
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

I found that an upstream commit[1] already contained the fix for this.
This patch just takes the relevant portion of that commit.

Thanks,
Nick

[1] 
https://github.com/hynek/structlog/commit/1012f5606b356d4fe1a9027513602c758bf51ab8
diff -Nru 
python-structlog-20.1.0/debian/patches/fix-assertion-in-test_delattr_missing.patch
 
python-structlog-20.1.0/debian/patches/fix-assertion-in-test_delattr_missing.patch
--- 
python-structlog-20.1.0/debian/patches/fix-assertion-in-test_delattr_missing.patch
  1969-12-31 19:00:00.0 -0500
+++ 
python-structlog-20.1.0/debian/patches/fix-assertion-in-test_delattr_missing.patch
  2023-02-08 15:50:24.0 -0500
@@ -0,0 +1,20 @@
+Description: Fix test_delattr_missing for python 3.11
+Origin: upstream, 
https://github.com/hynek/structlog/commit/1012f5606b356d4fe1a9027513602c758bf51ab8
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026725
+Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/python-structlog/+bug/2006634
+Last-Update: 2023-02-08
+---
+--- a/tests/test_threadlocal.py
 b/tests/test_threadlocal.py
+@@ -251,7 +251,10 @@
+ with pytest.raises(AttributeError) as e:
+ d._tl.__delattr__("does_not_exist")
+ 
+-assert "does_not_exist" == e.value.args[0]
++assert e.value.args[0] in (
++"does_not_exist",
++"'_thread._local' object has no attribute 'does_not_exist'",
++)
+ 
+ def test_del(self, D):
+ """
diff -Nru python-structlog-20.1.0/debian/patches/series 
python-structlog-20.1.0/debian/patches/series
--- python-structlog-20.1.0/debian/patches/series   1969-12-31 
19:00:00.0 -0500
+++ python-structlog-20.1.0/debian/patches/series   2023-02-08 
15:46:13.0 -0500
@@ -0,0 +1 @@
+fix-assertion-in-test_delattr_missing.patch

Bug#1030935: apt-file: patch proposal for #988105 and change its output to add release and arch

[Patrice Duroux]

Many thanks for your advices.

Will apt sooner or later provide similar functionality to apt-file?
So that the development would become more integrated/consistent.

In a first approach I tried using 'dpkg-query -W' but found 'apt list' more
direct for purposes. How can I get also the release of the installed package: no
way with 'dpkg-query -W -f '${Package} ${Release} ${Architecture} ${Status}\n'?
And with the version instead, I have then to know which release provides it.
By the way, dpkg-query(1) manpage cites 'Origin' as a possible field but it
seems always empty on my system.
Maybe I should go back then to this first approach.

Patrice

Bug#1030886: No Package Available

[Vincas Dargis]

On Wed, 08 Feb 2023 13:07:49 -0700 Soren Stoutner  wrote:
In the future it would be ideal to package everything in Debian necessary to fully support 
hardware ledgers.  However, as that is not likely to happen in the short term, I think it 
would be valuable to at least document what a user needs to add to get hardware wallets 
working in a README file installed with Electrum.


Yes it would be nice to have all these third party dependencies available. Not sure how feasible it is. Vendors could 
contribute them by themselves if they though this was useful


Would you be willing to send me a list of what you have done to get hardware wallets 
working for you and which hardware wallets are supported by these steps?


I only own Ledger, and it was enough to do `pip install ledger_bitcoin[hid]` as specified in 
https://pypi.org/project/ledger-bitcoin/ to make it work again. I do not recall what I have additionally installed years 
ago when I first started using Electrum.


The problem is that after some time in the future, I'll need to do the same thing again, and hope I remember what's 
missing and not spam Debian bug tracker again :) .

Bug#1030855: ring_20230206.0~ds1-2_amd64-buildd.changes REJECTED

[Aurelien Jarno]

Hi,

On 2023-02-09 09:41, Amin Bandali wrote:
> Hello,
> 
> Aurelien Jarno writes:
> 
> > Source: ring
> > Version: 20230206.0~ds1-2
> > Severity: serious
> >
> > On 2023-02-08 08:40, Debian FTP Masters wrote:
> >> jami_20230206.0~ds1-2_amd64.deb: has 5 file(s) with a timestamp too far in 
> >> th=
> >> e past:
> >>   usr/share/applications/jami.desktop (Thu Jan  1 00:00:01 1970)  
> >> usr/share/i=
> >> cons/hicolor/scalable/apps/jami.svg (Thu Jan  1 00:00:01 1970)  
> >> usr/share/jam=
> >> i/jami.desktop (Thu Jan  1 00:00:01 1970)  
> >> usr/share/metainfo/jami.appdata.xm=
> >> l (Thu Jan  1 00:00:01 1970)  usr/share/pixmaps/jami.xpm (Thu Jan  1 
> >> 00:00:01=
> >>  1970)
> >> 
> >> 
> >> 
> >> =3D=3D=3D
> >> 
> >> Please feel free to respond to this email if you don't understand why
> >> your files were rejected, or if you upload new files which address our
> >> concerns.

Please note I am only the messenger here, I am just forwarding a mail
(in the BTS so that there is a trace) from Debian FTP Masters
 telling that your package has been
rejected from the archive. I have added them in Cc so they can provide
an answer to your question.

> Yes please, I'd like to understand why timestamps in the far past are
> a 'serious' bug and warrant a rejection.  Upstream Jami project has

The serious severity of the bug is because your source package has been
rejected by Debian FTP Masters, and thus the source and binaries are not
in sync, not the timestamp issue.

> worked on making various aspects of the release and build processes of
> Jami reproducible over the years, including Jami's release tarballs.
> The release tarballs are generated with a few additional options[1] to
> aide reproducibility, including setting '--mtime=@1' to use the epoch
> as the timestamp for all the files included in the release tarballs.
> This is quite close to the archive recommendations[2] by the
> reproducible builds project.
> 
> So, why would this be considered an issue?
> 

This is a question to be answered by Debian FTP Masters.

Regards
Aurelien

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

Bug#1030916: Submit Upstream?

[Soren Stoutner]

Would this be the type of patch that is more appropriate to submit upstream?

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1028664: colord: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test --timeout-multiplier 3 returned exit code 1

[Mark Hindley]

Control: reassign -1 liblcms2-2 2.14-1
Control: affects -1 colord

I hit this FTBFS today.

The gdb backtrace of the failing test is

Thread 1 "colord-test-pri" received signal SIGSEGV, Segmentation fault.
0x77bd359a in cmsMLUtranslationsCodes () from 
/usr/lib/x86_64-linux-gnu/liblcms2.so.2
(gdb) bt
#0  0x77bd359a in cmsMLUtranslationsCodes () at 
/usr/lib/x86_64-linux-gnu/liblcms2.so.2
#1  0x77f9c598 in cd_icc_to_string (icc=icc@entry=0x5559e2c0) at 
../lib/colord/cd-icc.c:435
#2  0x55566c4e in colord_icc_func () at 
../lib/colord/cd-test-private.c:1529
#3  0x77c8764e in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77c873b5 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x77c87b52 in g_test_run_suite () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x77c87bbd in g_test_run () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0xb428 in main (argc=, argv=) at 
../lib/colord/cd-test-private.c:2400
(gdb)

I suppose this has been caused by the upload of version 2.14-1 of liblcms2-2,
but I don't immediately see the change there that has caused it.

Reassigning.

Mark

Bug#1030935: apt-file: patch proposal for #988105 and change its output to add release and arch

[David Kalnischkies]

Hi,

On Thu, Feb 09, 2023 at 03:10:39PM +0100, Patrice Duroux wrote:
> Dear Maintainer,

(Disclaimer: I am not an apt-file, but an apt maintainer)


> The first is regarding the sub std_release that I add to match the 'apt list'

You are not allowed to use 'apt' in a script. We could change its output
any second breaking your ad hoc parsing without any qualms.


> that gives 'unstable' even if the apt sources.list is using 'sid' and then

'apt list' for some reason prints the 'Suite' value. I suppose it really
shouldn't and pick 'Release' (which is what the sources.list includes,
which is either 'Suite' or 'Codename' usually). We might change that
(q.e.d. previous paragraph).

There is no absolute right answer here, it is a question of UI and the
specific use case which you prefer.


> accordingly the name of the content files. Is there a better way? (apt API?
> metadata file?...)

I have no idea about perl & libapt-pkg-perl, but I suppose getting
a list of installed packages is such a basic task that it should be
possible with it. If you really want to parse a program, dpkg would be
the better choice here.

Accessing the names of files (including the Content files) is
a relatively new feature (like ~2 Debian releases old), so I am not sure
how much if any is accessible in perl. Command line wise it would be via
'apt-get indextargets'. You will need this as a) Content files have
different filenames in different repositories as they have different
storage locations (Debian vs Ubuntu mostly). b) are likely compressed,
but if and with what is a configuration detail. c) I have plans, but
nothing concrete yet to have apt store files elsewhere and with names
where your guessing wouldn't work at all.

As I am not sure what apt-file does here and what your (perl) code
changes, I have no comment on the patch itself and what effects output
changes would have.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#213316: krb5-user: kinit doesn't use alternatives system

[Sam Hartman]

> "Danielll" == Daniel Schreiber  
> writes:

Danielll> Hi is there any chance to get this fixed? We have reasons
Danielll> to use MIT Kerberos on the clients and Heimdal for
Danielll> KDC. Therefore we need kinit/klist from MIT and kadmin
Danielll> from Heimdal on some of our machines.


Wow, I really dropped the ball on this one.
Reading back from the history, I don't see how this got missed for so
many years.

Unfortunately, krb5 is part of build-essential and is already frozen for
bookworm.
I'd be happy to fix this once development opens up for the next release
and look at a backport for bookworm.
My apologies for letting this slip through the cracks so much.

Bug#1030893: gdb FTBFS

[Héctor Orón Martínez]

Hello Matthias,

  I am unsure why you are uploading gdb snapshots for Debian bookworm.
  In anycase, could you look at this failure, you may need to generate
a DFSG tarball without the GFDL documentation.

Regards

On Wed, 8 Feb 2023 at 21:18, Adrian Bunk  wrote:
>
> Source: gdb
> Version: 13.0.91-0.1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/logs.php?pkg=gdb=13.0.91-0.1
>
> ...
> make[5]: Entering directory '/<>/build/default/gdb/doc'
> (test "ln -s" = "ln -s" && \
>   ln -s /<>/gdb/doc/all-cfg.texi gdb-cfg.texi) || \
> ln /<>/gdb/doc/all-cfg.texi gdb-cfg.texi || \
> cp /<>/gdb/doc/all-cfg.texi gdb-cfg.texi
> makeinfo --split-size=500 --split-size=500  -DHAVE_MAKEINFO_CLICK  -I 
> /<>/gdb/doc/../mi -I /<>/gdb/doc \
> -o gdb.info /<>/gdb/doc/gdb.texinfo
> makeinfo --split-size=500 --split-size=500  -DHAVE_MAKEINFO_CLICK -I 
> /<>/gdb/doc -o stabs.info /<>/gdb/doc/stabs.texinfo
> makeinfo --split-size=500 --split-size=500  -DHAVE_MAKEINFO_CLICK -I 
> /<>/gdb/doc -o annotate.info 
> /<>/gdb/doc/annotate.texinfo
> gdb.texinfo:39177: @include: could not find rluser.texi
> gdb.texinfo:39178: @include: could not find hsuser.texi
> gdb.texinfo:26429: @xref reference to nonexistent node `Command Line Editing'
> gdb.texinfo:26461: @xref reference to nonexistent node `Using History 
> Interactively'
> gdb.texinfo:26557: @xref reference to nonexistent node `Event Designators'
> gdb.texinfo:29361: @pxref reference to nonexistent node `Command Line Editing'
> gdb.texinfo:172: @menu reference to nonexistent node `Command Line Editing'
> gdb.texinfo:173: @menu reference to nonexistent node `Using History 
> Interactively'
> make[5]: *** [Makefile:491: gdb.info] Error 1



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Sven Joachim]

[Switching over to the cloned bug.]

On 2023-02-09 12:31 -0500, Theodore Ts'o wrote:

> On Thu, Feb 09, 2023 at 06:04:23PM +0100, Sven Joachim wrote:
>>
>> Thanks from me as well :-).  To prevent e2fsprogs from migrating to
>> testing before grub2 and breaking d-i, I am reassigning a copy of this
>> bug back to e2fsprogs.  It may be closed once grub2 2.06-8 enters
>> Bookworm.   Perhaps it would also be a good idea to add a versioned
>> "Breaks: grub2-common (<< 2.06-8~)" to e2fsprogs.
>
> Perhaps we could just add a "Breaks: grub2-common (<< 2.06-8~)" to
> e2fsprogs-udeb?

That is not going to help, because IIUC grub-install is run from the
target system that you are installing, and there is no
grub2-common-udeb.

> After all, it's not that e2fsprogs breaks
> grub2-common, per se, unless the *installer* happens to to use << grub
> 2.06-8~ and e2fsprogs 1.47.0-1.

I was also thinking of the cases where the /boot filesystem is
recreated, e.g. when transferring the installation to a different disk.

Cheers,
   Sven

Bug#1030941: librsb: build-depends unsatisfiable on armhf

[Peter Green]

Package: librsb
Version: 1.3.0.2+dfsg-1
Tags: bookworm, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable

librsb build-depends on coccinelle which appears to have been removed
on armhf, presumablly because it fails to build with an out of memory
error. This leaves your package in violation of the rc policy.

In general in cases like this there are three possible ways forward,
in roughly descending order of preference.

1. Fix the package you depend on so that it once again builds on
   all release architectures.
2. Modify your package to eliminate the build-dependency in question
   on architectures where it is not available.
3. Decide it is not reasonable to support your package on armhf and
   file a removal request with the ftp team.

I do not know enough about your individual package to say which are
feasible in your particular case.

Bug#934536: info version not shipped, close this bug?

[Bill Allombert]

On Thu, Feb 09, 2023 at 02:35:42PM +, Holger Levsen wrote:
> control: tags -1 +moreinfo
> thanks
> 
> hi,
> 
> (originally sent to the wrong (but archived) bug number...)
> 
> we're not shipping the manual in .info format, so I'm wondering whether this
> bug should simply be closed, or why not?

$ dpkg -L developers-reference | grep info
/usr/share/info
/usr/share/info/developers-reference.info.gz

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Theodore Ts'o]

On Thu, Feb 09, 2023 at 06:04:23PM +0100, Sven Joachim wrote:
> 
> Thanks from me as well :-).  To prevent e2fsprogs from migrating to
> testing before grub2 and breaking d-i, I am reassigning a copy of this
> bug back to e2fsprogs.  It may be closed once grub2 2.06-8 enters
> Bookworm.   Perhaps it would also be a good idea to add a versioned
> "Breaks: grub2-common (<< 2.06-8~)" to e2fsprogs.

Perhaps we could just add a "Breaks: grub2-common (<< 2.06-8~)" to
e2fsprogs-udeb?  After all, it's not that e2fsprogs breaks
grub2-common, per se, unless the *installer* happens to to use << grub
2.06-8~ and e2fsprogs 1.47.0-1.

- Ted

Bug#1030659: xscreensaver: segfault when starting xscreensaver-settings or xscreensaver-demo

[Tormod Volden]

Thanks! So the segfault is just a small bug in the debug printing, it
can be avoided with this patch:
--- driver/demo-Gtk.c.orig2022-12-07 02:12:13.577705209 +0100
+++ driver/demo-Gtk.c2023-02-09 16:59:22.656746738 +0100
@@ -3302,7 +3302,7 @@ fix_preview_visual (state *s)
   if (s->debug_p)
 fprintf (stderr, "%s: couldn't convert X Visual 0x%lx to a GdkVisual;"
  " winging it.\n",
- blurb(), (unsigned long) xvisual->visualid);
+ blurb(), (xvisual ? (unsigned long) xvisual->visualid : 0L));
 }

   if (s->debug_p)

With above patch you will probably end up the same as when running
without --debug. The NULL xvisual that was causing the segfault is
because /usr/libexec/xscreensaver/xscreensaver-gl-visual doesn't give
any visual, and you thus see the warning "xscreensaver-gl-visual did
not report a GL visual!". It will then use a default visual.

OTOH on my machine, /usr/libexec/xscreensaver/xscreensaver-gl-visual
prints "0x21".

I notice that in bug #1030909 the returned visual is also "0x21" like
on my computer, and it still ends up with the failed "X_SetInputFocus"
request.

So I think the major issue of xscreensaver-settings crashing is the
same as in #1030909 but you have the extra complication of no reported
GL visual (which caused the segfault).

Tormod

Bug#1030096: dask.distributed intermittent autopkgtest fail

[Diane Trout]

On Thu, 2023-02-09 at 07:44 +, Rebecca N. Palmer wrote:
> On 09/02/2023 06:36, Diane Trout wrote:
> > Also there's still some flaky tests as the rebuild triggered by my
> > just
> > committing the changelog release had a failure in
> > "test_release_retry"
> 
> I don't think I've seen that particular one before, though like
> several 
> others it's a warning being treated as an error because
> dask.distributed 
> now does that (in setup.cfg).

Would it make sense to drop those errors back to warnings, and do you
know enough about the setup.cfg language to do it quickly?

> 
> debci doesn't appear to have run yet.  (If it does and fails, note
> that 
> there's a retry button next to failure reports.  Given how tight we
> are 
> on time (we need to be in testing by the 12th), I'd rather not re-
> upload 
> (restarting the migration clock) if we don't have to.)

It says it failed on 4 tests on ci for amd64 but I could only find the
traceback for test_default_5 with a bunch of OS errors having run out
of file handles.

I went ahead and requested another run for the failed amd64 run and
left the passing arm64 run alone.

> 
> Also, we need to close this bug (by email _not_ by uploading).


Also how did numba 0.56.4-1 get overridden to be back in testing?

Can we get dask.distributed forced back in? It looks like it mostly
works, it feels like we're mostly fighting over it not being robust to
environment specific issues.

Diane

Bug#767756:

[Maksim Dmitrichenko]

Sorry guys, may be I'm telling well known things but Ubuntu has libc6-prof
package which installs alternative version of libc6 with
no-omit-frame-pointer to /lib/libc6-prof/x86_64-linux-gnu/ . Any who need
to profile his program can use it via LD_LIBRARY_PATH environment variable
while other programs by default use optimized version.

Why reinvent the wheel?

-- 
With best regards
  Maksim Dmitrichenko

Bug#1030846: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Sven Joachim]

Control: clone -1 -2
Control: reopen -2
Control: reassign -2 e2fsprogs 1.47.0-1
Control: severity -2 serious

On 2023-02-08 21:35 -0500, Theodore Ts'o wrote:

> On Wed, Feb 08, 2023 at 09:12:05PM +, Steve McIntyre wrote:
>>
>> I've just queued these up in our repo for the next grub upload, due in
>> a few days.
>
> Many thanks, Steve!

Thanks from me as well :-).  To prevent e2fsprogs from migrating to
testing before grub2 and breaking d-i, I am reassigning a copy of this
bug back to e2fsprogs.  It may be closed once grub2 2.06-8 enters
Bookworm.   Perhaps it would also be a good idea to add a versioned
"Breaks: grub2-common (<< 2.06-8~)" to e2fsprogs.

Cheers,
   Sven

Bug#1030938: os-prober: Does not detect OpenSuse Tumbleweed

[Frank McCormick]

Package: os-prober
Version: 1.81
Severity: wishlist
X-Debbugs-Cc: bea...@videotron.ca


Debian Sid updated Grub today and when os-prober ran via update-grub it did not 
detect
my OpenSuse Tumbleweed partition.
The update had installed the new Grub so I could not boot into
Tumbleweed.

Now I have held all the grub packages so I won't be faced
with this again. The Tumbleweed grub installation and it's version
of os-prober does detect both Debian and Fedora on another partition.
FYI Fedoras os-prober also doesn't detect Tumbleweed but that's a 
problem I'll report to them.





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

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

Versions of packages os-prober depends on:
ii  grub-common  2.06-8
ii  libc62.36-8
ii  mount2.38.1-4

os-prober recommends no packages.

os-prober suggests no packages.

-- no debconf information

Bug#1030933: jdupes: internal error: travdone_free() was passed NULL

[Alberto Garcia]

On Thu, Feb 09, 2023 at 01:51:18PM -0300, Eriberto wrote:
> > I actually just realized that this breaks the webkit2gtk build
> > if the documentation is not built (i.e the binary-arch builds)
> > because jdupes is run with a non-existent directory, which now
> > produces an error.
> 
> Sorry for this. I saw that webkit2gtk already arrived to testing and
> it is saved.

Yeah no problem, it only affected one of the builds in experimental
so it didn't really break anything important. If jdupes is going to
be fixed in a few days then there's no problem from the webkit side,
there is no upload planned at the moment.

Obrigado,

Berto

Bug#1030933: jdupes: internal error: travdone_free() was passed NULL

[Eriberto]

Hi Berto,

Em qui., 9 de fev. de 2023 às 13:03, Alberto Garcia  escreveu:
>
> On Thu, Feb 09, 2023 at 02:37:07PM +0100, Alberto Garcia wrote:
>
> Thanks for handling this so quickly, I saw the upstream bug report!

Thanks for your report.

> > The exit status also changes: 1 in the affected version, 0 in the
> > earlier ones. This could break some scripts.
>
> I actually just realized that this breaks the webkit2gtk build if the
> documentation is not built (i.e the binary-arch builds) because jdupes
> is run with a non-existent directory, which now produces an error.

Sorry for this. I saw that webkit2gtk already arrived to testing and
it is saved.

> I can fix this in webkit but I wouldn't be surprised if other packages
> are also affected.

jdupes will arrive to testing in 2 days, so I will apply a patch and
upload again.

Maybe applying the jdupes inside an override_dh_install-indep solves
your problem.

Cheers,

Eriberto

Bug#1030907: [Help] Possible scikit-learn issue (Was: Bug#1030907: umap-learn: FTBFS (failing tests))

[Andreas Tille]

Am Thu, Feb 09, 2023 at 04:57:03PM +0100 schrieb Drew Parsons:
> tldr;  https://github.com/lmcinnes/umap/pull/946

Thanks for the hint.
 
> There's a couple of strange aspects to this problem.  The np.matrix seems to
> be generated by scipy.sparse.  np.matrix is "not recommended" by numpy, but
> not actually deprecated (at least not removed) yet.  scikit-learn is jumping
> the gun by declaring it's not supported.
> 
> On the other hand, scitkit-learn has been "not supporting" it for two years
> now.  This corner of the debian archive is quite a bit out of date.  The
> current version of umap (i.e. umap-learn) is 0.5.3, released April last
> year.
> 
> That said, the np.matrix discrepancy was only just fixed recently, in
> December, by
> https://github.com/lmcinnes/umap/pull/946

I did not updated umap-learn since it had a new dependency from tensorflow.
However, I can skip those dependency and will upgrade to the latest version.

Kind regards
   Andreas. 

-- 
http://fam-tille.de