Bug#1031200: hylafax-server: faxgetty.service doesn't work with iaxmodem

[Giuseppe Sacco]

Hi Tino,

Il giorno lun, 13/02/2023 alle 22.47 +, debian-bu...@dc0wh17f.mooo.com
ha scritto:
> Hello Giuseppe,
> from my point of view all we need is a logical OR (||) in this systemd
> unit. Unfortunately I couldn't find such an option in systemd's manpages.
> So, I gave it a shot and tried this:
> 
> [Unit]
> Description=HylaFAX faxgetty %I
> BindsTo=iaxmodem.service || dev-%i.device
> After=network.target
[...]

The problem is if we may just wait for iaxmodem or if we need to wait for
the device.
The dev-%i.device has events when udev sends them, but since that path is
not a real device, no udev events are sent. This probably means that using
dev-%i.device on any systemd unit is useless.
So, I am wondering if the minimal working unit is just

[Unit]
Description=HylaFAX faxgetty %I
BindsTo=iaxmodem.service
After=iaxmodem.service

The question is: could you confirm that you cannot add/remove/start/stop
IAX devices without stopping the iaxmodem.service? In other words, no
(device) events would be possibile once iaxmodem is started?

Thank you,
Giuseppe

Bug#1030669: Only include in Bookworm with commitment to stable updates

[Moritz Muehlenhoff]

On Tue, Feb 14, 2023 at 02:48:43AM +0100, Marco d'Itri wrote:
> On Feb 02, Moritz Muehlenhoff  wrote:
> 
> > Varnish should only be included in Bookworm with a reliable commitment
> > by the maintainers to backport/test security fixes across the typical
> > three year life cycle (two years of stable-security and one year of
> > oldstable-security).
> I do not think that this will be helpful for Varnish users.

Then someone needs to step up, it's as easy as that.

Bug#1031261: Please, provide a valid initial configuration in /etc/multipath.conf

[Francesco P. Lovergine]

Package: multipath-tools
Version: 0.9.4-3
Severity: wishlist

Hi, 

after installation multipath-tools does not work properly in order to activate
mapping for devices automagically after the boot. 

I finally figured out that

multipath -t >/etc/multipath.conf

generates an initial configuration which is usable, but for a

find_multipaths "strict"

which is the least friendly way of defining mappings and 
practically prevents any auto-mapping (wwids need to be provided by hand).

While that is a perfectly working setup if properly manually configured, for 
sure it is 
not the easiast setting to cope with IMHO.

The final result, for instance, is that LVM could catch all single devices at 
boot 
and the  proper multipaths maps result broken, with the admin not familiar with
multipathd inners lost in the dark.

A very simple configuration such as:

defaults {
user_friendly_names yes
find_multipaths yes
}

and a round of update-initramfs after that, gives a proper working 
implementation, with
LVM perfectly capable of coping with variable names at boot time.

Note that RH folks provides a mpathconf script and an initial template
in /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf for that.

-- 
Francesco P. Lovergine

Bug#1031262: apt-listchanges: Separate emails about every package

[Andrzej A. Filip]

Package: apt-listchanges
Version: 3.24
Severity: wishlist

It would be nice to add and option allowing sending separate email about every
package with package name in subject.  It would help a lot with
ordering/searching LONG time email archives.



-- Package-specific info:
==> /etc/apt/listchanges.conf <==
[apt]
frontend=pager
confirm=false
email_address=root+apt-listchanges
save_seen=/var/lib/apt/listchanges.db
which=news
email_format=html
headers=true
reverse=false

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'testing'), (980, 'stable'), 
(500, 'stable-updates'), (60, 'oldstable'), (40, 'unstable')
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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listchanges depends on:
ii  apt2.5.5
ii  debconf [debconf-2.0]  1.5.82
ii  python33.11.1-3
ii  python3-apt2.5.2+b1
ii  python3-debconf1.5.82
ii  sensible-utils 0.0.17+nmu1
ii  ucf3.0043+nmu1

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  dillo [www-browser]   3.0.5-7+b1
ii  elinks [www-browser]  0.13.2-1+b4
ii  epiphany-browser [www-browser]43.0-2
ii  firefox-esr [www-browser] 102.7.0esr-1
ii  gnome-terminal [x-terminal-emulator]  3.46.7-1
ii  links [www-browser]   2.28-1+b1
ii  lxterminal [x-terminal-emulator]  0.4.0-2
ii  lynx [www-browser]2.9.0dev.12-1
ii  midori [www-browser]  7.0-2.1
ii  python3-gi3.42.2-3+b1
ii  qterminal [x-terminal-emulator]   1.2.0-2
ii  sendmail-bin [mail-transport-agent]   8.17.1.9-2
ii  surf [www-browser]2.1+git20221016-4
ii  terminator [x-terminal-emulator]  2.1.2-1
ii  xfce4-terminal [x-terminal-emulator]  1.0.4-1
ii  xterm [x-terminal-emulator]   378-1

-- debconf-show failed

Bug#1031263: RM: golang-github-alangpierce-go-forceexport -- RoQA; Not working since Go1.17, upstream seems abandoned

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: golang-github-alangpierce-go-forceexp...@packages.debian.org, 
z...@debian.org
Control: affects -1 + src:golang-github-alangpierce-go-forceexport


It FTBFS for a long time. Last upstream commit is at 2016.
It was introduced as Build-Depends of Syncthing, not needed anymore.

Bug#1031264: libamdhip64-dev: incorrect path to hip version information

[Cordell Bloor]

Package: libamdhip64-dev
Version: 5.2.3-4
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

This package provides a HIP version file so that Clang can detect the
version of HIP that is available. That file is installed at:

/usr/share/hip/version/.hipVersion

but the path that clang expects for this file is either

   /usr/bin/.hipVersion

or

   /usr/share/hip/version

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libamdhip64-dev depends on:
ii  libamdhip64-55.2.3-4
ii  libhiprtc-builtins5  5.2.3-4

libamdhip64-dev recommends no packages.

libamdhip64-dev suggests no packages.

-- no debconf information

Bug#1031265: ITP: pytorch-sparse -- PyTorch Extension Library of Optimized Autograd Sparse Matrix Operations

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 970575 by -1
Control: block -1 by 1021041

* Package name: pytorch-sparse
  Version : 0.6.16
  Upstream Author : Matthias Fey
* URL : https://github.com/rusty1s/pytorch_sparse
* License : Expat
  Programming Lang: Python
  Description : PyTorch Extension Library of Optimized Autograd 
Sparse Matrix Operations


This package consists of a small extension library of optimized sparse 
matrix operations with autograd support.


pytorch-sparse is needed by pytorch-geometric.

To be maintained under Debian Deep Learning Team 

Bug#1031266: python3-spyder: Unable to switch interface language

[Zheng Xueke]

Package: python3-spyder
Version: 5.4.2+ds-1
Severity: normal
Tags: l10n

Dear Maintainer,

  When I opened the spyder and switched the language to simplified Chinese in 
  Tools- > Preferences- > Application- > Advanced settings, the program guided
  me to restart the spyder, but the interface was still English after the 
restart.

-- 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/16 CPU threads; PREEMPT)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_CN:zh
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-spyder depends on:
ii  ipython3   8.5.0-4
ii  libjs-jquery   3.6.1+dfsg+~3.5.14-1
ii  libjs-mathjax  2.7.9+dfsg-1
ii  pyflakes3  2.5.0-1
ii  pylint 2.15.10-1
ii  python33.11.1-3
ii  python3-atomicwrites   1.4.1-1
ii  python3-autopep8   2.0.1-1
ii  python3-chardet5.1.0+dfsg-2
ii  python3-cloudpickle2.2.0-1
ii  python3-cookiecutter   1.7.3-2
ii  python3-diff-match-patch   20200713-2
ii  python3-docutils   0.19+dfsg-6
ii  python3-flake8 5.0.4-4
ii  python3-intervaltree   3.0.2-1.1
ii  python3-ipython8.5.0-4
ii  python3-jedi   0.18.2-1
ii  python3-jellyfish  0.8.9-1+b4
ii  python3-jsonschema 4.10.3-1
ii  python3-keyring23.9.3-2
ii  python3-mccabe 0.7.0-1
ii  python3-nbconvert  6.5.3-3
ii  python3-numpydoc   1.5.0-1
ii  python3-parso  0.8.3-1
ii  python3-pexpect4.8.0-4
ii  python3-pickleshare0.7.5-5
ii  python3-pkg-resources  66.1.1-1
ii  python3-psutil 5.9.4-1+b1
ii  python3-pycodestyle2.10.0-1
ii  python3-pydocstyle 6.2.3-2
ii  python3-pygments   2.14.0+dfsg-1
ii  python3-pylint-venv2.3.0-2
ii  python3-pyls-spyder0.4.0-2
ii  python3-pylsp  1.7.1-1
ii  python3-pylsp-black1.2.1-2
ii  python3-pyqt5  5.15.9+dfsg-1
ii  python3-pyqt5.qtwebengine  5.15.6-1
ii  python3-qdarkstyle 3.1+ds1-1
ii  python3-qstylizer  0.2.2-1
ii  python3-qtawesome  1.2.2+dfsg-1
ii  python3-qtconsole  5.4.0-1
ii  python3-qtpy   2.3.0-1
ii  python3-rope   1.7.0-1
ii  python3-rtree  1.0.1-1
ii  python3-setuptools 66.1.1-1
ii  python3-sphinx 5.3.0-3
ii  python3-spyder-kernels 2.4.2-1
ii  python3-textdistance   4.5.0-1
ii  python3-three-merge0.1.1-4
ii  python3-watchdog   2.2.1-1
ii  python3-xdg0.28-2
ii  python3-zmq24.0.1-4+b1
ii  spyder-common  5.4.2+ds-1
ii  yapf3  0.32.0-1

Versions of packages python3-spyder recommends:
ii  spyder  5.4.2+ds-1

Versions of packages python3-spyder suggests:
pn  cython3 
ii  python3-matplotlib  3.6.3-1+b1
ii  python3-numpy   1:1.24.1-2+b1
ii  python3-pandas  1.5.3+dfsg-1
ii  python3-pil 9.4.0-1.1+b1
ii  python3-scipy   1.10.0-4
ii  python3-sympy   1.11.1-1

Versions of packages python3-pyqt5 depends on:
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libpython3.11 3.11.1-2
ii  libqt5core5a [qtbase-abi-5-15-8]  5.15.8+dfsg-2
ii  libqt5dbus5   5.15.8+dfsg-2
ii  libqt5designer5   5.15.8-2
ii  libqt5gui55.15.8+dfsg-2
ii  libqt5help5   5.15.8-2
ii  libqt5network55.15.8+dfsg-2
ii  libqt5printsupport5   5.15.8+dfsg-2
ii  libqt5test5   5.15.8+dfsg-2
ii  libqt5widgets55.15.8+dfsg-2
ii  libqt5xml55.15.8+dfsg-2
ii  libstdc++612.2.0-14
ii  python3   3.11.1-3
ii  python3-pyqt5.sip 12.11.1-1

-- no debconf information

Bug#1029439: help fixing this bug

[Thorsten Alteholz]

In case somebody has any idea how to fix this bug, I would be happy to 
apply a patch.


  Thorsten

Bug#1027551: any progress

[Thorsten Alteholz]

Hi,

this is just a ping  ...

  Thorsten

Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full

[Harald Jele]

Package: texlive-full
Version: 2022.20230122-1
Followup-For: Bug #1023391
X-Debbugs-Cc: harald.j...@uni-klu.ac.at

Dear Maintainer,

when installing texlive-full into debian testing the EB Garamond fonts seem to
be not installed correctly. Not all ligatures are available, the bold face does
not even have a dash ...

I put a minimal example to
https://wwwu.aau.at/hjele/texlive_vs_debian_testing/eb_garamond.tgz

Compile the wut.tex via lualatex
2 pdfs are included which shows the differences.
One is the output of a current texlive portable installation.
One comes from a up to date debian testing.
Also the lualatex log files are given to this archive.

I hope, this helps.
Thanks


Harald


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 3381 Feb 14 09:16 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 12 23:25 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jan 24 23:31 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jan 24 23:31 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Nov  3 09:04 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Jan 24 23:31 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Jan 24 23:31 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5130 Feb 14 09:13 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Sep  4  2021 mktex.cnf
-rw-r--r-- 1 root root 475 Nov  3 09:04 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- 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/1 CPU thread; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-full depends on:
ii  asymptote  2.85+ds-1
ii  biber  2.18-1
ii  chktex 1.7.8-1
ii  cm-super   0.3.4-17
ii  context2021.03.05.20230120+dfsg-1
ii  dvidvi 1.0-8.2+b1
ii  dvipng 1.15-1.1+b1
ii  feynmf 1.08-13
ii  fragmaster 1.7-11
ii  info   6.8-6+b1
ii  lacheck1.26-17
ii  latex-cjk-all  4.8.5-1
ii  latexdiff  1.3.2-1
ii  latexmk1:4.79-1
ii  lcdf-typetools 2.108-3
ii  lmodern2.005-1
ii  prerex 6.8.0-1
ii  psutils1.17.dfsg-4
ii  purifyeps  1.1-3
ii  t1utils1.41-4
ii  tex-gyre   20180621-6
ii  texinfo6.8-6+b1
ii  texlive-base   

Bug#1031268: O: openlibm -- standalone implementation of C mathematical functions

[Graham Inggs]

Package: wnpp
Severity: normal
Control: affects -1 + src:openlibm

Openlibm was packaged by the Debian Julia Team as a dependency of
Julia.  Since Julia has been removed from the archive, see #1011382, I
hereby orphan openlibm.

The package description is:
 OpenLibm is an effort to have a high quality, portable, standalone libm
 implementation, under a liberal free software license. It can be used
 standalone in applications and programming language implementations.
 .
 The project was born out of a need to have a good libm for the Julia
 programming language that worked consistently across compilers and operating
 systems, and in 32-bit and 64-bit environments.

Bug#1031269: O: dsfmt -- dSFMT pseudorandom number generator

[Graham Inggs]

Package: wnpp
Severity: normal
Control: affects -1 + src:dsfmt

Dsfmt was packaged by the Debian Julia Team as a dependency of
Julia.  Since Julia has been removed from the archive, see #1011382, I
hereby orphan dsfmt.

The package description is:
 The double-precision SIMD-oriented Fast Mersenne Twister (dSFMT) is a variant
 of the Mersenne Twister pseudorandom number generator designed for modern CPUs
 with multi-stage pipelining and SIMD instructions. dSFMT directly generates
 IEEE 754 format double-precision floating-point pseudorandom numbers in the
 ranges [1, 2), [0, 1), (0, 1] and (0, 1), and supports various periods from
 2^521-1 to 2^216091-1.

Bug#1031267: debmany: shell injection

[Jakub Wilk]

* Jakub Wilk , 2023-02-14 10:53:

attached proof-of-concept exploit.


The code that generated the crafted .deb is here:
https://github.com/jwilk/crafted.deb/blob/master/gen-deb1031267-debmany

--
Jakub Wilk

Bug#1017780: Version bump: 1.4.230

[Jarl Gullberg]

I've got a patchset that reworks the control files for proper CMake
support and a couple of fixes to the existing patches in order to make
1.4.287 play nice with OpenSSL 3.0. I'm not sure if I've updated the
upstream source in line with policy for this package, though, and
could use some help making sure I'm doing it right.

At the moment, this is what I've done:
1. downloaded the upstream release tarball
3. renamed it to mumble_1.4.287.orig.tar.gz
2. cd mumble && pristine-tar commit ../mumble_1.4.287.orig.tar.gz
3. unpack tarball in upstream branch, commit and tag as 'upstream/1.4.287'
4. merge 'upstream' into 'debian'

I only found the 'extras/make-mumble-git-tarball.sh' script after the
fact, and I do see that that script does some cleanup. I'm also seeing
a lot of dpkg-source warnings about removed files when I build, so I'm
pretty sure I've done something wrong.

That aside, everything seems to run fine (with some hiccups related to
config files for mumble-server that I assume has something to do with
the above). I can open up a couple of MRs on Salsa if you want,
provided I can get some handholding in regards to how you want it done
:)

Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full

[Jele, Harald]

Hi Hilmar,

no local fonts are installed anymore and I reproduced this issue again.
I made a reply via reportbug to the bug report #1023391 with a new tgz, 
containing all output files of lualatex.
One made with a portable texlive installation (which is fine), one with texlive 
on a current debian testing.


Thx -- Harald

Von: Hilmar Preuße 
Gesendet: Samstag, 4. Februar 2023 16:12
An: Jele, Harald
Cc: 1023...@bugs.debian.org
Betreff: Re: Bug#1023391: texlive-full: The EB Garamond font is not installed 
properly within debian texlive-full

Am 03.11.2022 um 11:48 teilte Harald Jele mit:

Hi,

> when installing texlive-full into debian testing the EB Garamond fonts seem to
> be not installed correctly. Not all ligatures are available, the bold face 
> does
> not even have a dash ...
>
> I put a minimal example to
> http://wwwu.aau.at/hjele/texlive_vs_debian_testing/eb_garamond.zip
>
> Compile the wut.tex via lualatex
> 2 pdfs are included.
> One is the output of a current texlive portable installation.
> One comes from a up to date debian testing.
>

I'm unable to reproduce the issue. As you did not provide a log file I
can only guess that we have the same root cause as for #1020492: make
sure that the local incarnations of the fonts are deleted.

Hilmar
--
sigfault

Bug#1027542: epl: FTBFS: make: *** [debian/rules:6: build] Error 25

[Adrian Bunk]

On Mon, Jan 02, 2023 at 08:14:55AM -0400, David Bremner wrote:
> Lucas Nussbaum  writes:
> 
> > Source: epl
> > Version: 0.9-5
> > Severity: serious
> > Justification: FTBFS
> > Tags: bookworm sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20230101 ftbfs-bookworm
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> >
> 
> This seems tricky to duplicate
> 
> - building on bare metal (sid/bookworm): works
> - building in sbuild chroot by running dpkg-buildpackage: works
> - building with sbuild: fails.
> 
> As a wild guess I tried adding
> 
>export EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t
> 
> to debian/rules, but it did not help.

FTR, the dates when epl started to FTBFS in sid and bookworm are
a good match for when emacs 1:28.2+1-9 entered sid and bookworm:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epl.html

cu
Adrian

Bug#1031252: hipsparse: FTBFS (c++: error: -E or -x required when input is from standard input)

[Santiago Vila]

reassign 1031252 libamdhip64-5
affects 1031252 + src:hipsparse
found 1031252 5.2.3-1~0exp1
fixed 1031252 5.2.3-2
forcemerge 1031252 1021643
thanks

El 14/2/23 a las 5:15, Cordell Bloor escribió:

This is a bug in libamdhip64-5:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021643

It was fixed in rocm-hipamd 5.2.3-2, but no versions since rocm-hipamd 5.2.3-1 
have migrated to bookworm. This problem will affect all libraries and 
executables that link against libamdhip64-5 using the GCC toolchain.


If this is really a bug in one of the build-depends, please use
reassign and affects, so that this is still visible in the BTS web
page for this package.


I'm still learning how to use these the Debian bug reporting tools. Perhaps 
another maintainer could help set these properties.

Apologies for the incomplete handling, but I hope that this information is 
helpful.


No problem. The information alone is already useful.
I believe the above commands should work (note: I'm using Bcc for 
control@b.d.o).

Thanks.

Bug#1031261: Please, provide a valid initial configuration in /etc/multipath.conf

[Chris Hofstaedtler]

Hi,

multipath-tools upstream has in the past changed the defaults a
number of times, and I think has now settled on "the best thing to
do is manually configure it, because otherwise lots of edge cases
pop up".

* Francesco P. Lovergine  [230214 09:18]:
> I finally figured out that
> 
> multipath -t >/etc/multipath.conf
> 
> generates an initial configuration which is usable, but for a
> 
>   find_multipaths "strict"
> 
> which is the least friendly way of defining mappings and 
> practically prevents any auto-mapping (wwids need to be provided by hand).

Well, it wants you to use the `multipath` program to add a
binding/wwid. This is quite explicit, but also always works.
In my experience, once you leave the realm of test setups, its best
to have explicit configuration.

> While that is a perfectly working setup if properly manually configured, for 
> sure it is 
> not the easiast setting to cope with IMHO.
> 
> The final result, for instance, is that LVM could catch all single devices at 
> boot 
> and the  proper multipaths maps result broken, with the admin not familiar 
> with
> multipathd inners lost in the dark.
> 
> A very simple configuration such as:
> 
> defaults {
>   user_friendly_names yes
>   find_multipaths yes
> }
> 
> and a round of update-initramfs after that, gives a proper working 
> implementation, with
> LVM perfectly capable of coping with variable names at boot time.
> 
> Note that RH folks provides a mpathconf script and an initial template
> in /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf for that.

I'll note that this is a sample for 0.4.9, and this is very old.

Chris

Bug#1031270: mk-sbuild: tries to copy removed file /etc/timezone

[Victor Westerhuis]

Package: ubuntu-dev-tools
Version: 0.192
Severity: normal
File: /usr/bin/mk-sbuild
X-Debbugs-Cc: vic...@westerhu.is, 822...@bugs.debian.org

Hello maintainer,

Since tzdata version 2022g-3 /etc/timezone is removed on upgrade.
mk-sbuild tries to copy this file to the new chroot on line 904,
without checking if it exists. This makes mk-sbuild fail.

--
Groet, Regards,

Victor Westerhuis

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

Kernel: Linux 6.1.10+ (SMP w/20 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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ubuntu-dev-tools depends on:
ii  binutils2.40-2
ii  dctrl-tools 2.24-3+b1
ii  devscripts  2.22.2
ii  diffstat1.65-1
ii  distro-info 1.5
ii  dpkg-dev1.21.20
ii  dput1.1.3
ii  lsb-release 12.0-1
ii  perl5.36.0-7
ii  python3 3.11.1-3
ii  python3-apt 2.5.2+b1
ii  python3-debian  0.1.49
ii  python3-debianbts   4.0.1
ii  python3-distro-info 1.5
ii  python3-httplib20.20.4-3
ii  python3-launchpadlib1.11.0-1
ii  python3-lazr.restfulclient  0.14.5-1
ii  python3-ubuntutools 0.192
ii  sensible-utils  0.0.17+nmu1
ii  sudo1.9.12p2-1
ii  tzdata  2022g-5

Versions of packages ubuntu-dev-tools recommends:
ii  arch-test0.20-1
ii  ca-certificates  20211016
ii  debian-archive-keyring   2021.1.1
ii  debian-keyring   2022.12.24
ii  debootstrap  1.0.128+nmu2
ii  genisoimage  9:1.1.11-3.4
ii  lintian  2.116.3
ii  patch2.7.6-7
ii  python3-dns  3.2.1-2
ii  quilt0.67+really0.66-1
ii  reportbug11.6.0
ii  sbuild   0.85.0
ii  ubuntu-keyring [ubuntu-archive-keyring]  2020.06.17.1-1

Versions of packages ubuntu-dev-tools suggests:
pn  bzr | brz  
pn  bzr-builddeb | brz-debian  
ii  qemu-user-static   1:7.2+dfsg-2

-- no debconf information

Bug#1031271: glib2.0 [experimental]: 2.75.3 FTBFS on big-endian

[Simon McVittie]

Source: glib2.0
Version: 2.75.3-1
Severity: serious
Tags: ftbfs upstream pending
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://gitlab.gnome.org/GNOME/glib/-/issues/2918

See . I'm testing a
solution.

smcv

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

[Daniel Leidert]

Am Montag, dem 13.02.2023 um 21:35 -0500 schrieb Theodore Ts'o:
> On Tue, Feb 14, 2023 at 01:01:38AM +0100, Daniel Leidert wrote:
> > Hi Steve,
> > 
> > I believe that your fix to grub2 in Sid is not enough to handle
> > #1030939/#1030846.
> > 
> > This problem breaks e.g. vmdb2. I can no longer create a Bullseye
> > system image with vmdb2 on Sid, because the grub-install step in the
> > Bullseye chroot now fails, because the created filesystem (created with
> > e2fsprogs on Sid) cannot be recognized by grub.
> 
> I'm confused, why does using vmdb2 on *sid* involve running
> grub-install on a *bulleye* chroot?

My workstation is running Sid. I want to create an image for Bullseye
(in this case using vmdb2, but I could do it manually as well). First,
one creates the paritioning and the filesystems for the target system
with the tools provided by the host system. This involves running the
unfortunate version of e2fsprogs with the breaking change. Then, one
installs the base system with deboostrap (also from the host system)
into the created partitions/filesystem. Then one (bind-)mounts the
virtual filesystems into the target systems, does a chroot into it, and
then one finishes the installation inside the chroot, including running
grub-install.

This is standard and common behavior. I have never ever seen in my
whole life someone to use grub2 from Sid to make a grub-install for a
Bullseye target. I have not even seen anybody suggest that.

Consider another example: Server providers use GRML or Bookworm with
e2fsprogs 1.47.0 as their rescue system. Now people are no longer able
to create a Bullseye system using the deboostrap method [1]. If the
host system uses e2fsprogs 1.47.0 or above and the target system for
[1] uses a grub without a fix, then this no longer works.

[1] https://www.debian.org/releases/stable/amd64/apds03

> That seems to be extremely ill-advised.

I'm sorry? I think you are completely missing the point.

> If you are trying to install a bullseye system, why
> can't you using vmdb2 on bullseye?

Because I am using Sid and because I use features of vmdb2 which are
not available in the version in Bullseye. And this feature breaks vmdb2
and similar tools. It also breaks a standard way of installing Debian
systems.

> And if you are trying to install a sid or bookworm system using vmdb2,
> why can't you (or vmdb2) use a sid or bookworm chroot for doing the
> grub-install?

What are you talking about? You basically break the toolchains and then
you suggest to do non-standard stuff to handle this or even avoid doing
installations of affected systems?!

> > I guess that the fix applied to grub2 in Sid would have to be applied
> > to grub2 in Bullseye as well (and basically to any grub2 package in any
> > Debian or Ubuntu or Raspbian release supported by debootstrap).
> 
> I can understand why we need to keep things synchronized so that a
> debian installer for Bookworm be able to generate a bootable system
> using the version of grub and e2fsprogs in Bookworm.
> 
> But a generalized requirement that we be able to use debootstrap and
> vmdb2 to be able to bootstrap an arbitrarily old distribution doesn't
> seem to be reasonable.

You are completyl wrong. This breaks a standard way of installing any
system supported by deboostrap with a grub without a fix to deal with
this version of e2fsprogs. This isn't just about vmdb2.

What you are saying is ignorant.

If this isn't cared about, then this version of e2fsprogs shouldn't
make it into Bookworm. We are in the middle of a freeze and this breaks
toolchains and a standard way (see [1]) of installing Debian.

Daniel

Bug#1012232: freespace2: FTBFS: ./configure: line 17040: syntax error near unexpected token `ax_cxx_compile_cxx11_required=falsednl'

[Andreas Beckmann]

Followup-For: Bug #1012232
Control: found -1 2.71-3

The problem is still reproducible when rebuilding src:freespace2 in sid
with latest autoconf.


Andreas

Bug#1027542: epl: FTBFS: make: *** [debian/rules:6: build] Error 25

[Adrian Bunk]

On Tue, Feb 14, 2023 at 12:30:59PM +0200, Adrian Bunk wrote:
> On Mon, Jan 02, 2023 at 08:14:55AM -0400, David Bremner wrote:
> > Lucas Nussbaum  writes:
> > 
> > > Source: epl
> > > Version: 0.9-5
> > > Severity: serious
> > > Justification: FTBFS
> > > Tags: bookworm sid ftbfs
> > > User: lu...@debian.org
> > > Usertags: ftbfs-20230101 ftbfs-bookworm
> > >
> > > Hi,
> > >
> > > During a rebuild of all packages in sid, your package failed to build
> > > on amd64.
> > >
> > 
> > This seems tricky to duplicate
> > 
> > - building on bare metal (sid/bookworm): works
> > - building in sbuild chroot by running dpkg-buildpackage: works
> > - building with sbuild: fails.
> > 
> > As a wild guess I tried adding
> > 
> >export EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t
> > 
> > to debian/rules, but it did not help.
> 
> FTR, the dates when epl started to FTBFS in sid and bookworm are
> a good match for when emacs 1:28.2+1-9 entered sid and bookworm:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epl.html

Correct link:
https://tests.reproducible-builds.org/debian/history/epl.html

cu
Adrian

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

[Steve McIntyre]

On Tue, Feb 14, 2023 at 11:34:13AM +0100, Daniel Leidert wrote:
>Am Montag, dem 13.02.2023 um 21:35 -0500 schrieb Theodore Ts'o:

...

>> But a generalized requirement that we be able to use debootstrap and
>> vmdb2 to be able to bootstrap an arbitrarily old distribution doesn't
>> seem to be reasonable.
>
>You are completyl wrong. This breaks a standard way of installing any
>system supported by deboostrap with a grub without a fix to deal with
>this version of e2fsprogs. This isn't just about vmdb2.
>
>What you are saying is ignorant.
>
>If this isn't cared about, then this version of e2fsprogs shouldn't
>make it into Bookworm. We are in the middle of a freeze and this breaks
>toolchains and a standard way (see [1]) of installing Debian.

Sorry Daniel, but I have to (mostly!) agree with Ted here. If you're
creating an image of an older release using newer tools then you'll
need to be aware that sometimes the newer tools will create things
that don't work there. If there's a bug here, I would strongly argue
that it's in vmdb2. deboostrap (for example) includes some
release-specific knowledge to cope with issues like this.

If we don't allow for this kind of change, that wouldn't allow us to
*ever* make breaking changes in some packages, and that's just not
sustainable.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Bug#1029760: evince: AppArmor prevents opening PDF files stored on Google drive

[intrigeri]

Hi,

Laurent Bigonville (2023-01-27):
> It seems that the AppArmor profile is not allowing evince to read file
> accessed via the GVFS on Google drive (and probably other integrations)

I don't have the infrastructure in place to reproduce this easily,
so I'm going to ask some more info.

> I get the following denials:
>
> type=AVC msg=audit(1674751821.962:528): apparmor="DENIED" operation="open" 
> profile="/usr/bin/evince" 
> name="/run/user/1000/gvfs/google-drive:host=example.com,user=foo/" 
> pid=11026 comm="EvJobScheduler" requested_mask="r" denied_mask="r" fsuid=1000 
> ouid=1000FSUID="bigon" OUID="bigon"

I suppose you've redacted this part:

  user=foo/

I'd like to understand why the value for "name" did not match any of
these rules:

  /**.[bB][mM][pP] r,
  /**.[dD][jJ][vV][uU] r,
  /**.[dD][vV][iI] r,
  /**.[gG][iI][fF] r,
  /**.[jJ][pP][gG] r,
  /**.[jJ][pP][eE][gG] r,
  /**.[oO][dD][pP] r,
  /**.[fFpP][dD][fF]   r,
  /**.[pP][nN][mM] r,
  /**.[pP][nN][gG] r,
  /**.[pP][sS] r,
  /**.[eE][pP][sS] r,
  /**.[eE][pP][sS][fFiI23] r,
  /**.[tT][iI][fF] r,
  /**.[tT][iI][fF][fF] r,
  /**.[xX][pP][mM] r,
  /**.[gG][zZ] r,
  /**.[bB][zZ]2r,
  /**.[cC][bB][rRtTzZ7]  r,
  /**.[xX][zZ] r,

Could you please share a bit more about the value of "name" in the
error message, possibly privately?

Does it end with ".pdf", like name="/run//pdf", or does it
look different?

Cheers,
-- 
intrigeri

Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full

[Hilmar Preuße]

Am 14.02.2023 um 10:55 teilte Jele, Harald mit:

Hi Harald,


no local fonts are installed anymore and I reproduced this issue again.
I made a reply via reportbug to the bug report #1023391 with a new
tgz, containing all output files of lualatex. One made with a
portable texlive installation (which is fine), one with texlive on a
current debian testing.


You have the package fonts-ebgaramond installed. Could you remove it and
try again?

Hilmar
--
sigfault

Bug#1031272: ITP: pytorch-scatter -- PyTorch Extension Library of Optimized Scatter Operations

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 1031265 by -1

* Package name: pytorch-scatter
  Version : 2.1.0
  Upstream Author : Matthias Fey
* URL : https://github.com/rusty1s/pytorch_scatter
* License : Expat
  Programming Lang: C
  Description : PyTorch Extension Library of Optimized Scatter 
Operations


This package consists of a small extension library of highly optimized 
sparse update (scatter and segment) operations for the use in PyTorch, 
which are missing in the main package. Scatter and segment operations 
can be roughly described as reduce operations based on a given 
"group-index" tensor. Segment operations require the "group-index" 
tensor to be sorted, whereas scatter operations are not subject to these 
requirements.


Remark: This package is to be maintained with Debian Deep Learning Team at
   https://salsa.debian.org/deeplearning-team/pytorch-scatter

Bug#1031261: Please, provide a valid initial configuration in /etc/multipath.conf

[Francesco P. Lovergine]

On Tue, Feb 14, 2023 at 11:28:50AM +0100, Chris Hofstaedtler wrote:

Hi,

multipath-tools upstream has in the past changed the defaults a
number of times, and I think has now settled on "the best thing to
do is manually configure it, because otherwise lots of edge cases
pop up".

* Francesco P. Lovergine  [230214 09:18]:

I finally figured out that

multipath -t >/etc/multipath.conf

generates an initial configuration which is usable, but for a

find_multipaths "strict"

which is the least friendly way of defining mappings and
practically prevents any auto-mapping (wwids need to be provided by hand).


Well, it wants you to use the `multipath` program to add a
binding/wwid. This is quite explicit, but also always works.
In my experience, once you leave the realm of test setups, its best
to have explicit configuration.



Well, at least some notes about the required manual configuration and steps
to get the wwids (e.g. hinting /lib/udev/scsi_id) and finalize the config,
or even alternative settings would be nice. 
I find the README.Debian included not the most clear possible. 


[...]

I'll note that this is a sample for 0.4.9, and this is very old.

Chris



That's taken from RHEL 7 documentation, I `suppose` now it is updated.


--
Francesco P. Lovergine

Bug#1031273: Uploading DD still in DM ACL

[Bastian Germann]

Package: ftp.debian.org
Severity: minor

I have just noticed that mwei is still in https://ftp-master.debian.org/dm.txt 
even though they are an uploading DD now.
I guess mwei never got removed from that list because before they were DM and 
non-uploading DD.

Bug#1029238: imv not found in $PATH

[Petter Reinholdtsen]

Control: severity -1 normal

[Andreas Metzler]
> | Starting from upstream version 4.0.0 imv ships two binaries that
> | handle Wayland and X11 natively: imv-wayland and imv-x11. To allow
> | seamless usage to users upstream provides a /usr/bin/imv wrapper that
> | checks whether a Wayland compositor is available before running the
> | appropriate binary.
> 
> | The Debian package does not ship the wrapper script to avoid a file
> | name clash with the renameutils package.
> 
> Invoking either imv-wayland or imv-x11 should work perfectly fine on the
> commandline.

This sound like a normal or wishlist issue, not a grave error.  Reducing
severity accordingly.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting

[Jonathan Dowland]

On Sat, Jan 21, 2023 at 09:26:03PM -0600, Aaron Rainbolt wrote:
If the XScreenSaver configuration file is included as a part of the 
core xscreensaver package itself, as a file that is simply unpacked, 
the following situation will result:

…
If the configuration file is split out into its own separate 
xscreensaver-config package

…

This is totally orthogonal to a solution to the bug reporter's issue.
Splitting the xscreensaver package up and shipping the same files in
different sub-packages and adding alternatives or other metapackage
complications will do nothing to solve their problem.

Your motivation for all that extra complexity is also orthogonal to
Debian: you're talking about an enhancement for Ubuntu. As it stands,
you're talking about making Debian worse to make Ubuntu better, and
that's a hard sell.


--
👱🏻  Jonathan Dowland
✎   j...@dow.land
🔗   https://jmtd.net

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

[Daniel Leidert]

Am Dienstag, dem 14.02.2023 um 10:45 + schrieb Steve McIntyre:
> On Tue, Feb 14, 2023 at 11:34:13AM +0100, Daniel Leidert wrote:
> > Am Montag, dem 13.02.2023 um 21:35 -0500 schrieb Theodore Ts'o:
> 
> ...
> 
> > > But a generalized requirement that we be able to use debootstrap and
> > > vmdb2 to be able to bootstrap an arbitrarily old distribution doesn't
> > > seem to be reasonable.
> > 
> > You are completyl wrong. This breaks a standard way of installing any
> > system supported by deboostrap with a grub without a fix to deal with
> > this version of e2fsprogs. This isn't just about vmdb2.
> > 
> > What you are saying is ignorant.
> > 
> > If this isn't cared about, then this version of e2fsprogs shouldn't
> > make it into Bookworm. We are in the middle of a freeze and this breaks
> > toolchains and a standard way (see [1]) of installing Debian.
> 
> Sorry Daniel, but I have to (mostly!) agree with Ted here. If you're
> creating an image of an older release using newer tools then you'll
> need to be aware that sometimes the newer tools will create things
> that don't work there. If there's a bug here, I would strongly argue
> that it's in vmdb2. deboostrap (for example) includes some
> release-specific knowledge to cope with issues like this.

debootstrap does nothing related to grub. So it is a bad example. Again
I refer to [1]: If the host system contains the problematic e2fsprogs
and the target system doesn't contain a grub with the fix [2], then
this breaks installations. This breaks older systems *and* current
systems. For example, I neither see the necessary grub patch in both
Ubuntu 20.04 and 22.04 either. So they also cannot be installed using
the deboostrap method and the toolchain in Sid (and Bookworm if
e2fsprogs makes it there). 

[1] https://www.debian.org/releases/stable/amd64/apds03
[2] Even "our" grub only contains a patch and not an upstream version
with support. So how can you even expect the target system to contain a
fix and be able to handle the created filesystem?!

Whe whole handling is completely wrong here. First, grub should have
been fixed upstream. And the change in e2fsprogs should have been done
only after "fixed" grub versions had settled. If we do it the other way
around, we have to patch grub in affected distributions as well. And
for Debian that means at least to patch Bullseye and any other release
we want to be able to install from Bookworm. I even a lot of companies
using Buster still.

> If we don't allow for this kind of change, that wouldn't allow us to
> *ever* make breaking changes in some packages, and that's just not
> sustainable.

I'm critizicing the way of handling that breaking change and the
ignorance shown reagarding the impact, not that fact that there is a
breaking change. And it breaks a lot! This doesn't affect just a few
minor use cases. It affects the basic way of installing a clean Ubuntu
or Debian (or derivative) on a remote server using the debootstrap
method.


And again: We are in the middle of a freeze here. And e2fsprogs pushes
a breaking change that is not even handled by any existing grub
upstream release, and is also not properly handled within Debian?!

Daniel

Bug#1030478: cannot uninstall open-iscsi package

[Ritesh Raj Sarraf]

Hello Harald,

On Sat, 2023-02-04 at 08:48 +0100, Harald Dunkel wrote:
> Version: 2.1.3-5
> 

I did a quick test with the version in Bookworm and cannot reproduce
the issue. I will try later with the version in Bullseye, if time
permits.


> Trying to uninstall open-iscsi I got
> 
> Removing open-iscsi (2.1.3-5) ...
> rm: cannot remove '/usr/sbin/]': No such file or directory
> dpkg: error processing package open-iscsi (--remove):
>   installed open-iscsi package post-removal script subprocess
> returned error exit status 1
> dpkg: too many errors, stopping
> Errors were encountered while processing:
>   open-iscsi
> Processing was halted because there were too many errors.
> E: Sub-process /usr/bin/dpkg returned an error code (1)

rrs@xps:~$ sudo apt install open-iscsi
[sudo] password for rrs: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libisns0 libopeniscsiusr
Recommended packages:
  finalrd
The following NEW packages will be installed:
  libisns0 libopeniscsiusr open-iscsi
0 upgraded, 3 newly installed, 0 to remove and 1 not upgraded.
Need to get 464 kB of archives.
After this operation, 2,152 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://deb.debian.org/debian testing/main amd64 libisns0 amd64 
0.101-0.2+b1 [92.0 kB]
Get:2 http://deb.debian.org/debian testing/main amd64 libopeniscsiusr amd64 
2.1.8-1 [59.7 kB]
Get:3 http://deb.debian.org/debian testing/main amd64 open-iscsi amd64 2.1.8-1 
[312 kB]
Fetched 464 kB in 3s (156 kB/s) 
Preconfiguring packages ...
Selecting previously unselected package libisns0:amd64.
(Reading database ... 469438 files and directories currently installed.)
Preparing to unpack .../libisns0_0.101-0.2+b1_amd64.deb ...
Unpacking libisns0:amd64 (0.101-0.2+b1) ...
Selecting previously unselected package libopeniscsiusr.
Preparing to unpack .../libopeniscsiusr_2.1.8-1_amd64.deb ...
Unpacking libopeniscsiusr (2.1.8-1) ...
Selecting previously unselected package open-iscsi.
Preparing to unpack .../open-iscsi_2.1.8-1_amd64.deb ...
Unpacking open-iscsi (2.1.8-1) ...
Setting up libopeniscsiusr (2.1.8-1) ...
Setting up libisns0:amd64 (0.101-0.2+b1) ...
Setting up open-iscsi (2.1.8-1) ...

Created symlink /etc/systemd/system/sockets.target.wants/iscsid.socket → 
/lib/systemd/system/iscsid.socket.
Created symlink /etc/systemd/system/iscsi.service → 
/lib/systemd/system/open-iscsi.service.
Created symlink /etc/systemd/system/sysinit.target.wants/open-iscsi.service → 
/lib/systemd/system/open-iscsi.service.
Processing triggers for libc-bin (2.36-8) ...
Processing triggers for man-db (2.11.2-1) ...
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.1.0-4-amd64

Scanning processes...   

  
Scanning candidates...  

  
Scanning processor microcode... 

  
Scanning linux images...

  

The processor microcode seems to be up-to-date.

Restarting services...
Service restarts being deferred:
 systemctl restart NetworkManager.service
 systemctl restart bluetooth.service
 /etc/needrestart/restart.d/dbus.service
 systemctl restart docker.service
 systemctl restart sddm.service
 systemctl restart systemd-logind.service

No containers need to be restarted.

User sessions running outdated binaries:
 rrs @ session #3: sddm-helper[13130]
 rrs @ user manager service: at-spi-bus-laun[14600], bash[14025,15366], 
firefox[168306], jellyfinmediapl[168054], konsole[14012], kwin_wayland[13209], 
kwin_wayland_wr[13203], QtWebEngineProc[168095,168097], systemd[13132],
  xdg-document-po[14582]

No VM guests are running outdated hypervisor (qemu) binaries on this host.





rrs@xps:~$ sudo apt purge open-iscsi
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libisns0 libopeniscsiusr
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  open-iscsi*
0 upgraded, 0 newly installed, 1 to remove and 1 not upgraded.
After this operation, 1,457 kB disk space will be

Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?

[Ritesh Raj Sarraf]

Hello Petter

On Mon, 2023-02-06 at 08:20 +0100, Petter Reinholdtsen wrote:
> Because of issues with the opensnitch build and test, I noticed the
> Debian buildds only build bpfcc on a limited set of architectures. 
> Is
> it written down somewhere why so few of the Debian architectures are
> listed as working with bpfcc?  Any chance to increase the list to all
> supported Debian architectures?

I don't recollect if the list of supported architecture is mentioned
somewhere, but I restricted the build to some of the 64 Bit
architectures only, because of the lack of upstream support.

I personally enabled bpfcc on some extra (64 bit) architectures back
then but learnt that the upstream support is only focused on x86.
Things may have changed lately as I am not on top of the bpfcc
development upstream.


I would love to extend the architecture support. If you already have
changes that enable additional architectures, an MR will be
appreciated. Preferably, first we should let it soak/reside, for 1-2
upstream releases, under Debian Experimental.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#1031160: reason for removal of zeroc-ice on armhf and arm64.

[Peter Green]

I recently became aware that mumble's build-dependencies were no longer
satisfiable on armhf due to a missing zeroc-ice. I looked at the build
logs for zeroc-ice and all were green. So I looked at the removal log
and found the following.


[Date: Sun, 12 Feb 2023 17:56:51 -] [ftpmaster: Scott Kitterman]
Removed the following packages from unstable:

libzeroc-ice-dev |  3.7.8-2.1 | arm64, armhf
libzeroc-ice3.7 |  3.7.8-2.1 | arm64, armhf
libzeroc-icestorm3.7 |  3.7.8-2.1 | arm64, armhf
mumble-server |1.3.4-4 | arm64, armhf
php-zeroc-ice |  3.7.8-2.1 | arm64, armhf
python3-zeroc-ice |  3.7.8-2.1 | arm64, armhf
zeroc-glacier2 |  3.7.8-2.1 | arm64, armhf
zeroc-ice-compilers |  3.7.8-2.1 | arm64, armhf
zeroc-ice-utils |  3.7.8-2.1 | arm64, armhf
zeroc-icebox |  3.7.8-2.1 | arm64, armhf
zeroc-icebridge |  3.7.8-2.1 | arm64, armhf
zeroc-icegrid |  3.7.8-2.1 | arm64, armhf
zeroc-icepatch2 |  3.7.8-2.1 | arm64, armhf
Closed bugs: 1031160

--- Reason ---
RoQA; openjfx no longer builds on arm64 and armhf, build-depends not available


This strikes me as strange in a couple of ways.

1. The only relationships of zeroc-ice to openjfx are in build-depends-indep
   and in the binary dependencies of an arch all package. Afaict it is perfectly
   normal for build-depends-indep and the binary dependencies of arch all
   packages to only be satisfiable on a subset of the architectures where
2. Only one of the two binaries from the mumble source package was removed.

Was this removal just a mistake? or was there a reason behind it that I am not
seeing?

Bug#1031131: open-iscsi: Lot of iscsi/kernel errors in dmesg with Fujitsu Eternus DX100S4 connected with 2 10Gb ethernet paths with multipathd.

[Ritesh Raj Sarraf]

Hello Migo,

On Sun, 2023-02-12 at 11:29 +0100, migo wrote:
> Package: open-iscsi
> Version: 2.1.3-5
> Severity: normal
> X-Debbugs-Cc: migo.ora...@gmail.com
> 
> Dear Maintainer,
> 
> I want to apologize if this is not the right place to report this
> issue, but I need somewhere to start.
> 
> I've lot of this error messages ind dmesg:
> 
> Feb 09 10:56:05 virt2n kernel:  connection2:0: detected conn error
> (1015)
> Feb 09 10:56:05 virt2n iscsid[2790]: connection2:0 is operational
> after recovery (1 attempts)
> Feb 09 10:56:05 virt2n iscsid[2790]: connection1:0 is operational
> after recovery (1 attempts)

Connection dropped and re-established. Looks normal.

> Feb 09 10:56:05 virt2n iscsid[2790]: Kernel reported iSCSI connection
> 1:0 error (1015 - ISCSI_ERR_DATA_DGST: Data digest mismatch) state
> (3)
> Feb 09 10:56:05 virt2n iscsid[2790]: Kernel reported iSCSI connection
> 2:0 error (1015 - ISCSI_ERR_DATA_DGST: Data digest mismatch) state
> (3)
> Feb 09 10:56:10 virt2n iscsid[2790]: connection1:0 is operational
> after recovery (1 attempts)
> Feb 09 10:56:10 virt2n iscsid[2790]: connection2:0 is operational
> after recovery (1 attempts)

Conn 2:0 recovered but the earlier error it gave looks misleading to
me. What target controller you have ? What there a failover across the
nodes ? How does the target handle the transition period to initiator
queries ?

> Feb 09 10:56:28 virt2n kernel:  connection1:0: detected conn error
> (1015)
> Feb 09 10:56:28 virt2n kernel:  connection2:0: detected conn error
> (1015)
> Feb 09 10:56:28 virt2n iscsid[2790]: Kernel reported iSCSI connection
> 1:0 error (1015 - ISCSI_ERR_DATA_DGST: Data digest mismatch) state
> (3)
> Feb 09 10:56:28 virt2n iscsid[2790]: Kernel reported iSCSI connection
> 2:0 error (1015 - ISCSI_ERR_DATA_DGST: Data digest mismatch) state
> (3)
> Feb 09 10:56:33 virt2n kernel:  connection1:0: detected conn error
> (1015)
> Feb 09 10:56:33 virt2n kernel:  connection2:0: detected conn error
> (1015)
> Feb 09 10:56:33 virt2n iscsid[2790]: connection2:0 is operational
> after recovery (1 attempts)
> Feb 09 10:56:33 virt2n iscsid[2790]: connection1:0 is operational
> after recovery (1 attempts)

Same logs again.

> ... snipped ...

> or enventually this:
> 
> Feb 10 20:39:39 virt2n kernel:  connection1:0: ping timeout of 5 secs
> expired, recv timeout 5, last rx 19077132455, last ping 19077133712,
> now 19077134976
> Feb 10 20:39:39 virt2n kernel:  connection1:0: detected conn error
> (1022)
> Feb 10 20:39:39 virt2n kernel: scsi_io_completion_action: 11
> callbacks suppressed
> Feb 10 20:39:39 virt2n kernel: sd 1:0:0:5: [sdl] tag#122 FAILED
> Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
> Feb 10 20:39:39 virt2n kernel: sd 1:0:0:5: [sdl] tag#122 CDB: Test
> Unit Ready 00 00 00 00 00 00
> Feb 10 20:39:39 virt2n kernel: sd 1:0:0:16: [sdah] tag#103 FAILED
> Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
> Feb 10 20:39:39 virt2n kernel: sd 1:0:0:16: [sdah] tag#103 CDB: Test
> Unit Ready 00 00 00 00 00 00
> Feb 10 20:39:39 virt2n kernel: sd 1:0:0:24: [sdax] tag#115 FAILED
> Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
> Feb 10 20:39:39 virt2n kernel: sd 1:0:0:24: [sdax] tag#115 CDB: Test
> Unit Ready 00 00 00 00 00 00
> 
> When this happens iscsi opration is interupted for few seconds,
> multipath -ll reports (this is only example, i/o pending is reported
> dor all 30 dm-s:
> 

This all looks normal to me. If you want the errors to be suppressed,
you can increase the timeouts. On the other hand, otherwise, you could
also use dm-multipath on top, like you have shown below.

> 
> web3v (360e00d2c002c17720012) dm-52 FUJITSU,ETERNUS_DXL
> size=500G features='3 queue_if_no_path queue_mode mq' hwhandler='1
> alua' wp=rw
> `-+- policy='service-time 0' prio=10 status=active
>   |- 1:0:0:16 sdah 66:16  active i/o pending running
>   `- 2:0:0:16 sdai 66:32  active ready running
> ais_app (360e00d2c002c1772001f) dm-99 FUJITSU,ETERNUS_DXL
> size=500G features='3 queue_if_no_path queue_mode mq' hwhandler='1
> alua' wp=rw
> `-+- policy='service-time 0' prio=10 status=active
>   |- 1:0:0:28 sdbh 67:176 active i/o pending running
>   `- 2:0:0:28 sdbf 67:144 active ready running
> 

Looks all correct to me. You already are using feature queue_if_no_path

> SAN consists of one Fujitsu DX100 S4 storage with two controllers
> connected to LAN switch with two 10Gb fibre links (one from
> controller), each link has its own VLAN configured. Errors reported
> ocures on virtualization host that are connected mutipath with two
> 10Gb fibre links to respective VLANs. Jumbo frames are enabled across
> the way.
> 

Good. As I expected, you do have a 2 node target controller setup.

> I'll add all neded info upun request.
> 
> I've consulted this issue with Fujitsu representative and it seems we
> have all configured right and he advised me to contact Debian
> support. So I'm here and would kindly ask to point me the 

Bug#1030890: libwebm: Provide additional headers to alllow building aom with the system libwebm

[Vasyl Gello]

Hi Vladimir,

Thanks for the patch!

I have not built it yet, but from the debdiff I see it only adds symbols, not 
removes them?
If yes, I think we can accept it. Removing symbols would need a transition 
which is no-go
at this stage of bookworm freeze.

-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1030936: vlc: crash on start playing

[Vladimir Stavrinov]

On Sun, Feb 12, 2023 at 8:55 PM Sebastian Ramacher  wrote:
>
> The libva upgrade may have triggered a latent bug in one of the VA-API
> drivers. But as anything with libva (note that libva just loads the
> drivers and directly forwards all calls) these bugs depend on drivers
> and hardware.

dpkg --install /var/backups/libav/*
dpkg: warning: downgrading libva-dev:amd64 from 2.17.0-1 to 2.16.0-1
(Reading database ... 702086 files and directories currently installed.)
Preparing to unpack .../libva-dev_2.16.0-1_amd64.deb ...
Unpacking libva-dev:amd64 (2.16.0-1) over (2.17.0-1) ...
dpkg: warning: downgrading libva-drm2:amd64 from 2.17.0-1 to 2.16.0-1
Preparing to unpack .../libva-drm2_2.16.0-1_amd64.deb ...
Unpacking libva-drm2:amd64 (2.16.0-1) over (2.17.0-1) ...
dpkg: warning: downgrading libva-glx2:amd64 from 2.17.0-1 to 2.16.0-1
Preparing to unpack .../libva-glx2_2.16.0-1_amd64.deb ...
Unpacking libva-glx2:amd64 (2.16.0-1) over (2.17.0-1) ...
dpkg: warning: downgrading libva-wayland2:amd64 from 2.17.0-1 to 2.16.0-1
Preparing to unpack .../libva-wayland2_2.16.0-1_amd64.deb ...
Unpacking libva-wayland2:amd64 (2.16.0-1) over (2.17.0-1) ...
dpkg: warning: downgrading libva-x11-2:amd64 from 2.17.0-1 to 2.16.0-1
Preparing to unpack .../libva-x11-2_2.16.0-1_amd64.deb ...
Unpacking libva-x11-2:amd64 (2.16.0-1) over (2.17.0-1) ...
dpkg: warning: downgrading libva2:amd64 from 2.17.0-1 to 2.16.0-1
Preparing to unpack .../libva2_2.16.0-1_amd64.deb ...
Unpacking libva2:amd64 (2.16.0-1) over (2.17.0-1) ...
Setting up libva2:amd64 (2.16.0-1) ...
Setting up libva-drm2:amd64 (2.16.0-1) ...
Setting up libva-wayland2:amd64 (2.16.0-1) ...
Setting up libva-x11-2:amd64 (2.16.0-1) ...
Setting up libva-glx2:amd64 (2.16.0-1) ...
Setting up libva-dev:amd64 (2.16.0-1) ...
Processing triggers for runit (2.1.2-54) ...
Processing triggers for man-db (2.11.2-1) ...
Processing triggers for libc-bin (2.36-8) ..

All triggers: runit, man-db, libc-bin Did You mean these triggers? I
don't see any drivers there. So only the libva stack was downgraded.

Bug#1031274: mk-sbuild: does not recognize documented --eatmydata option

[Victor Westerhuis]

Package: ubuntu-dev-tools
Version: 0.192
Severity: minor
File: /usr/bin/mk-sbuild
X-Debbugs-Cc: vic...@westerhu.is
Control: found -1 0.181

Hello maintainer,

Since commit f97b195 mk-sbuild enables eatmydata by default. Both the
help text and the man page still list --eatmydata as a valid option,
but it is not recognized by mk-sbuild anymore. Specifying --eatmydata
makes mk-sbuild fail.
--
Groet, Regards,

Victor Westerhuis

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

Kernel: Linux 6.1.10+ (SMP w/20 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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ubuntu-dev-tools depends on:
ii  binutils2.40-2
ii  dctrl-tools 2.24-3+b1
ii  devscripts  2.22.2
ii  diffstat1.65-1
ii  distro-info 1.5
ii  dpkg-dev1.21.20
ii  dput1.1.3
ii  lsb-release 12.0-1
ii  perl5.36.0-7
ii  python3 3.11.1-3
ii  python3-apt 2.5.2+b1
ii  python3-debian  0.1.49
ii  python3-debianbts   4.0.1
ii  python3-distro-info 1.5
ii  python3-httplib20.20.4-3
ii  python3-launchpadlib1.11.0-1
ii  python3-lazr.restfulclient  0.14.5-1
ii  python3-ubuntutools 0.192
ii  sensible-utils  0.0.17+nmu1
ii  sudo1.9.12p2-1
ii  tzdata  2022g-5

Versions of packages ubuntu-dev-tools recommends:
ii  arch-test0.20-1
ii  ca-certificates  20211016
ii  debian-archive-keyring   2021.1.1
ii  debian-keyring   2022.12.24
ii  debootstrap  1.0.128+nmu2
ii  genisoimage  9:1.1.11-3.4
ii  lintian  2.116.3
ii  patch2.7.6-7
ii  python3-dns  3.2.1-2
ii  quilt0.67+really0.66-1
ii  reportbug11.6.0
ii  sbuild   0.85.0
ii  ubuntu-keyring [ubuntu-archive-keyring]  2020.06.17.1-1

Versions of packages ubuntu-dev-tools suggests:
pn  bzr | brz  
pn  bzr-builddeb | brz-debian  
ii  qemu-user-static   1:7.2+dfsg-2

-- no debconf information

Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?

[Petter Reinholdtsen]

[Ritesh Raj Sarraf]
> I don't recollect if the list of supported architecture is mentioned
> somewhere, but I restricted the build to some of the 64 Bit
> architectures only, because of the lack of upstream support.

OK.  What do 'upstream support' mean here, and did they list supported
platforms anywhere?

> I personally enabled bpfcc on some extra (64 bit) architectures back
> then but learnt that the upstream support is only focused on x86.
> Things may have changed lately as I am not on top of the bpfcc
> development upstream.

I am not either.  I was just curious why the arch list was so limited,
when I discovered it while helping out with opensnitch.

> I would love to extend the architecture support. If you already have
> changes that enable additional architectures, an MR will be
> appreciated. Preferably, first we should let it soak/reside, for 1-2
> upstream releases, under Debian Experimental.

I do not plan to send patches for extending it until I understand the
consequences, but agree that the experimental path seem like a sensible
one.  I would be nice if eBPF and opensnitch was available on all
supported architectures, but it might not be worth the effort.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full

[Jele, Harald]

Hi Hilmar,

removing the fonts-ebgaramond seems not to be a good idea:
apt remove fonts-ebgaramond
would remove almost the whole texlive installation because of it's dependencies.


Harald

Von: Hilmar Preuße 
Gesendet: Dienstag, 14. Februar 2023 12:01
An: Jele, Harald
Cc: 1023...@bugs.debian.org
Betreff: Re: Bug#1023391: texlive-full: The EB Garamond font is not installed 
properly within debian texlive-full

Am 14.02.2023 um 10:55 teilte Jele, Harald mit:

Hi Harald,

> no local fonts are installed anymore and I reproduced this issue again.
> I made a reply via reportbug to the bug report #1023391 with a new
> tgz, containing all output files of lualatex. One made with a
> portable texlive installation (which is fine), one with texlive on a
> current debian testing.
>
You have the package fonts-ebgaramond installed. Could you remove it and
try again?

Hilmar
--
sigfault

Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full

[Hilmar Preuße]

Am 14.02.2023 um 13:29 teilte Jele, Harald mit:

Hi,


removing the fonts-ebgaramond seems not to be a good idea:
apt remove fonts-ebgaramond
would remove almost the whole texlive installation because of it's dependencies.


Could you nevertheless try that step, just to prove that is is the
faulty package? Thanks!

Hilmar
--
sigfault

Bug#1031200: hylafax-server: faxgetty.service doesn't work with iaxmodem

[debian-bug23]

Hi Giuseppe,

> The problem is if we may just wait for iaxmodem or if we need to wait for
> the device.
I agree.


> The dev-%i.device has events when udev sends them, but since that path is
> not a real device, no udev events are sent. This probably means that using
> dev-%i.device on any systemd unit is useless.
I don't think they're useless. The intended behavior (from my understanding) of 
BindsTo=dev-%i.device is, to make sure faxgetty binds to that device and start 
it once the device becomes available or terminate it immediately when the 
underlying real device (say: /dev/ttyS0) is not available anymore. Therefore, 
the BindsTo-dependency makes sense to me. And this is why I wanted to keep them 
and add iaxmodem.service in this line with an OR statement, which seems not to 
be supported by systemd.


> So, I am wondering if the minimal working unit is just
> 
> [Unit]
> Description=HylaFAX faxgetty %I
> BindsTo=iaxmodem.service
> After=iaxmodem.service
This works.


> The question is: could you confirm that you cannot add/remove/start/stop
> IAX devices without stopping the iaxmodem.service? In other words, no
> (device) events would be possibile once iaxmodem is started?
No. You can add/remove devices with a seperate call of iaxmodem  
while iaxmodem.service is running. You can even (re)start running devices. 
There is no lock or similar for a device once iaxmodem is started.


Thanks,
Tino

Bug#1031275: partman: Should allow binary multipliers

[Alejandro Colomar]

Package: debian-installer
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com


Dear maintainer,

when installing Debian, it's painful to size the partitions.  I want
them to be aligned with certain boundaries, and want them to have very
specific sizes (usually, multiples of 1 GiB), but the default
partitioning program doesn't allow that.  fdisk or gdisk provide a
much better way of specifying such things by allowing one to specify
initial sector and size in several formats.  Please add such semantics
to the default program, or include fdisk and gdisk in the installer.

I usually format disks from a live system with those tools, and later
run the installer on the formatted disk, because I hate how it formats
disks.

Thanks,

Alex

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

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

Bug#1031276: randomness on armel, armhf mipsel resulting in unreproducible man-db index.db files

[Johannes Schauer Marin Rodrigues]

Source: gdbm
Version: 1.23-3
Severity: normal
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: cjwat...@debian.org, reproducible-b...@lists.alioth.debian.org
Control: affects -1 + mmdebstrap man-db

Hi,

here is a test script that shows the problem:

$ printf "#:len=6\nZm9vYmFy\n#:len=6\nZm9vYmFy\n" > index.dump
$ gdbm_load index.dump index1.db
$ gdbm_load index.dump index2.db
$ md5sum index1.db index2.db

The md5sums of index1.db and index2.db will differ despite both being created
from index.dump. To figure out which architectures are affected by this
problem, we use debvm:

sshcmd="ssh -o NoHostAuthenticationForLocalhost=yes -p 8022 root@127.0.0.1"
failing=
for arch in amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x; do
debvm-create -a $arch -k ~/.ssh/id_rsa.pub -- --include=gdbmtool
debvm-run -s 8022 &
pid=$!
debvm-waitssh -t 300 127.0.0.1:8022
printf "#:len=6\nZm9vYmFy\n#:len=6\nZm9vYmFy\n" | $sshcmd tee 
/index.dump >/dev/null
$sshcmd gdbm_load /index.dump /index1.db
$sshcmd gdbm_load /index.dump /index2.db
ret=0
$sshcmd cmp /index1.db /index2.db || ret=1
if [ $ret -ne 0 ]; then
failing="$failing $arch"
fi
$sshcmd systemctl poweroff
wait $pid
done
echo $failing

This will output "armel armhf mipsel". Note, that qemu-usermode emulation is
not enough to reproduce the problem. So the following will show the issue when
run on arm64 but not when run on amd64:

mmdebstrap --arch=armhf --variant=essential --include=gdbmtool \
--customize-hook='printf "#:len=6\nZm9vYmFy\n#:len=6\nZm9vYmFy\n" > 
"$1/index.dump"' \
--customize-hook='chroot "$1" gdbm_load /index.dump /index1.db' \
--customize-hook='chroot "$1" gdbm_load /index.dump /index2.db' \
--customize-hook='md5sum "$1/index1.db" "$1/index2.db"' \
--customize-hook='cmp "$1/index1.db" "$1/index2.db"' \
unstable /dev/null

I found this problem in an mmdebstrap autopkgtest failure due to different
contents of /var/cache/man/index.db on armel and armhf. When running gdbm_dump
for the two differing index.db files it shows that the contents they store is
actually identical. So this is a gdbm-specific problem and not a problem with
man-db.  I'm able to reproduce it by running gdbm_load on a minimal dump file
as shown above.

You can see the diffoscope output of the mmdebstrap test failure in this log:

https://ci.debian.net/data/autopkgtest/unstable/armhf/m/mmdebstrap/31327623/log.gz

grep for /index.db to find the differences.

Somebody familiar with the gdbm format can maybe spot which part of the file it
is that differs.

Thanks!

cheers, josch

Bug#1030936: vlc: crash on start playing

[Sebastian Ramacher]

On 2023-02-14 15:14:34 +0300, Vladimir Stavrinov wrote:
> On Sun, Feb 12, 2023 at 8:55 PM Sebastian Ramacher  
> wrote:
> >
> > The libva upgrade may have triggered a latent bug in one of the VA-API
> > drivers. But as anything with libva (note that libva just loads the
> > drivers and directly forwards all calls) these bugs depend on drivers
> > and hardware.
> 
> dpkg --install /var/backups/libav/*
> dpkg: warning: downgrading libva-dev:amd64 from 2.17.0-1 to 2.16.0-1
> (Reading database ... 702086 files and directories currently installed.)
> Preparing to unpack .../libva-dev_2.16.0-1_amd64.deb ...
> Unpacking libva-dev:amd64 (2.16.0-1) over (2.17.0-1) ...
> dpkg: warning: downgrading libva-drm2:amd64 from 2.17.0-1 to 2.16.0-1
> Preparing to unpack .../libva-drm2_2.16.0-1_amd64.deb ...
> Unpacking libva-drm2:amd64 (2.16.0-1) over (2.17.0-1) ...
> dpkg: warning: downgrading libva-glx2:amd64 from 2.17.0-1 to 2.16.0-1
> Preparing to unpack .../libva-glx2_2.16.0-1_amd64.deb ...
> Unpacking libva-glx2:amd64 (2.16.0-1) over (2.17.0-1) ...
> dpkg: warning: downgrading libva-wayland2:amd64 from 2.17.0-1 to 2.16.0-1
> Preparing to unpack .../libva-wayland2_2.16.0-1_amd64.deb ...
> Unpacking libva-wayland2:amd64 (2.16.0-1) over (2.17.0-1) ...
> dpkg: warning: downgrading libva-x11-2:amd64 from 2.17.0-1 to 2.16.0-1
> Preparing to unpack .../libva-x11-2_2.16.0-1_amd64.deb ...
> Unpacking libva-x11-2:amd64 (2.16.0-1) over (2.17.0-1) ...
> dpkg: warning: downgrading libva2:amd64 from 2.17.0-1 to 2.16.0-1
> Preparing to unpack .../libva2_2.16.0-1_amd64.deb ...
> Unpacking libva2:amd64 (2.16.0-1) over (2.17.0-1) ...
> Setting up libva2:amd64 (2.16.0-1) ...
> Setting up libva-drm2:amd64 (2.16.0-1) ...
> Setting up libva-wayland2:amd64 (2.16.0-1) ...
> Setting up libva-x11-2:amd64 (2.16.0-1) ...
> Setting up libva-glx2:amd64 (2.16.0-1) ...
> Setting up libva-dev:amd64 (2.16.0-1) ...
> Processing triggers for runit (2.1.2-54) ...
> Processing triggers for man-db (2.11.2-1) ...
> Processing triggers for libc-bin (2.36-8) ..
> 
> All triggers: runit, man-db, libc-bin Did You mean these triggers? I
> don't see any drivers there. So only the libva stack was downgraded.

No, not at all.

Cheers
-- 
Sebastian Ramacher

Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?

[Ritesh Raj Sarraf]

On Tue, 2023-02-14 at 13:22 +0100, Petter Reinholdtsen wrote:
> > I don't recollect if the list of supported architecture is
> > mentioned
> > somewhere, but I restricted the build to some of the 64 Bit
> > architectures only, because of the lack of upstream support.
> 
> OK.  What do 'upstream support' mean here, and did they list
> supported
> platforms anywhere?

By 'upstream support', I meant based on random conversations I had with
them years ago.

So, for curiosity, I did a quick check on where packaging in general
stands.

We have:

* https://koji.fedoraproject.org/koji/buildinfo?buildID=1880777
* https://src.fedoraproject.org/rpms/bcc/blob/rawhide/f/bcc.spec
* https://github.com/iovisor/bcc/issues/2678
* https://repo.iovisor.org/yum/
* https://repo.iovisor.org/apt/
 
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#1031160: reason for removal of zeroc-ice on armhf and arm64.

[Adrian Bunk]

On Tue, Feb 14, 2023 at 11:56:40AM +, Peter Green wrote:
> I recently became aware that mumble's build-dependencies were no longer
> satisfiable on armhf due to a missing zeroc-ice. I looked at the build
> logs for zeroc-ice and all were green. So I looked at the removal log
> and found the following.
> 
> > [Date: Sun, 12 Feb 2023 17:56:51 -] [ftpmaster: Scott Kitterman]
> > Removed the following packages from unstable:
> > 
> > libzeroc-ice-dev |  3.7.8-2.1 | arm64, armhf
> > libzeroc-ice3.7 |  3.7.8-2.1 | arm64, armhf
> > libzeroc-icestorm3.7 |  3.7.8-2.1 | arm64, armhf
> > mumble-server |1.3.4-4 | arm64, armhf
> > php-zeroc-ice |  3.7.8-2.1 | arm64, armhf
> > python3-zeroc-ice |  3.7.8-2.1 | arm64, armhf
> > zeroc-glacier2 |  3.7.8-2.1 | arm64, armhf
> > zeroc-ice-compilers |  3.7.8-2.1 | arm64, armhf
> > zeroc-ice-utils |  3.7.8-2.1 | arm64, armhf
> > zeroc-icebox |  3.7.8-2.1 | arm64, armhf
> > zeroc-icebridge |  3.7.8-2.1 | arm64, armhf
> > zeroc-icegrid |  3.7.8-2.1 | arm64, armhf
> > zeroc-icepatch2 |  3.7.8-2.1 | arm64, armhf
> > Closed bugs: 1031160
> > 
> > --- Reason ---
> > RoQA; openjfx no longer builds on arm64 and armhf, build-depends not 
> > available
> 
> This strikes me as strange in a couple of ways.
> 
> 1. The only relationships of zeroc-ice to openjfx are in build-depends-indep
>and in the binary dependencies of an arch all package. Afaict it is 
> perfectly
>normal for build-depends-indep and the binary dependencies of arch all
>packages to only be satisfiable on a subset of the architectures where
> 2. Only one of the two binaries from the mumble source package was removed.
> 
> Was this removal just a mistake? or was there a reason behind it that I am not
> seeing?

As requestor of #1031160 I would say this was a mistake,
perhaps due to

https://tracker.debian.org/pkg/openjfx
Issues preventing migration:
∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes 
beast2-mcmc/2.7.3+dfsg-1/arm64 uninstallable
∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes 
josm/0.0.svn18646+dfsg-1/arm64 uninstallable
∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes 
pdfsam/4.3.4-1/arm64 uninstallable

This will require a hint from the release team I have not yet requested,
since installability of binary-all packages is tested on amd64 and arm64
but there is no requirement that a binary-all package is installable on
arm64 and several are not.[1]

cu
Adrian

[1] https://release.debian.org/britney/testing_uninst.txt

Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?

[Petter Reinholdtsen]

[Ritesh Raj Sarraf]
> By 'upstream support', I meant based on random conversations I had with
> them years ago.

Aha.  I guess it is limited to the set of architectures the developers
have access to and are interested in.

> So, for curiosity, I did a quick check on where packaging in general
> stands.

As Debian have more build architectures that every other Linux
distribution, it is no surprise that the list of architectures is short
for the other distributors.

Will it be hard to test if the result work during build and reject the
architecure based on build failure instead of a fixed list of
architectures.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?

[Gustavo Iñiguez Goya]

Hello!

The list of supported architectures is here:
https://github.com/libbpf/libbpf/blob/master/src/bpf_tracing.h

Per my experience building opensnitch packages for i386, amd64, armhf and
arm64, gobpf (which uses libpfcc-dev) works fine on those platforms.
eBPF modules loads and works fine.

On Tue, 14 Feb 2023 at 12:56, Ritesh Raj Sarraf  wrote:

> Hello Petter
>
> On Mon, 2023-02-06 at 08:20 +0100, Petter Reinholdtsen wrote:
> > Because of issues with the opensnitch build and test, I noticed the
> > Debian buildds only build bpfcc on a limited set of architectures.
> > Is
> > it written down somewhere why so few of the Debian architectures are
> > listed as working with bpfcc?  Any chance to increase the list to all
> > supported Debian architectures?
>
> I don't recollect if the list of supported architecture is mentioned
> somewhere, but I restricted the build to some of the 64 Bit
> architectures only, because of the lack of upstream support.
>
> I personally enabled bpfcc on some extra (64 bit) architectures back
> then but learnt that the upstream support is only focused on x86.
> Things may have changed lately as I am not on top of the bpfcc
> development upstream.
>
>
> I would love to extend the architecture support. If you already have
> changes that enable additional architectures, an MR will be
> appreciated. Preferably, first we should let it soak/reside, for 1-2
> upstream releases, under Debian Experimental.
>
> --
> Ritesh Raj Sarraf | http://people.debian.org/~rrs
> Debian - The Universal Operating System
>


-- 

Clave Pública:
gpg --keyserver pgp.rediris.es --recv-keys BCF6BE9C

Bug#1031277: gcompris-qt: gcompris doesn't start - Your root item has to be a window

[Stefan Kropp]

Package: gcompris-qt
Version: 3.1-1
Severity: normal
X-Debbugs-Cc: stefan.kr...@posteo.de

Dear Maintainer,

on a testing system, I'm not able to start gcompris. I get an
error message "Your root item has to be a window" on the
terminal.

-- 
Stefan

Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?

[Ritesh Raj Sarraf]

On Tue, 2023-02-14 at 14:35 +0100, Petter Reinholdtsen wrote:
> Will it be hard to test if the result work during build and reject
> the
> architecure based on build failure instead of a fixed list of
> architectures.

Getting it to build is one part, making it behave reliably is comes
immediate next.

Then, there's also the inclusion/exclusion every release, based on
build status.

I chose to stick with the fixed architecture list because:

* Real life is progressing, as in I now have lesser volunteer time
* I don't want to commit when I know I don't have a lot of
time/experience on the subject.


All that said, Debian is about fun. And Experimental is for this very
same purpose. I will make an upload to Experimental soon, as I
expressed the intent earlier. And let it soak there for a couple of
(upstream) release cycles.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#1027706: gourmand: Instructions not saved

[Christian Marillat]

On 02 janv. 2023 10:48, Thierry Jeanmougin  
wrote:

> Package: gourmand
> Version: 1.1.0+really1.0.0-3
> Severity: important
> Tags: upstream
>
> Dear Maintainer,
>
> Instructions are not saved when creating or editing a recipe.
> The instruction section appears blank once the recipe is saved and reopened,
> whereas the information in the other sections (description, ingredients and
> notes) are correcly saved

Could you try the 1.1.0+really1.1.0~rc3-2 package from unstable ?

Christian

Bug#1031278: buddy: Contains non-source file

[Bastian Germann]

Source: buddy
Version: 2.4-11
Severity: serious

The doc/buddy.ps file contained in the package is not a source file.
Please repack to get rid of it or build it from source if it is available.

Bug#1031279: bullseye-pu: package flask-security/4.0.0-1+deb11u1

[Carsten Schoenert]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: flask-secur...@packages.debian.org
Control: affects -1 + src:flask-security

[ Reason ]
The version of flask-security in bullseye is affected by CVE-2021-23385.
https://security-tracker.debian.org/tracker/CVE-2021-23385

[ Impact ]
Without that fix users of Flask based application which using
get_post_logout_redirect and get_post_login_redirect functions might get
an bypassed URL validation and redirect a user to an arbitrary URL.

[ Tests ]
Upstream has added a test to check the code for catching any bypass
while adding the needed source code changes.
https://github.com/Flask-Middleware/flask-security/commit/e39bb04615050448c1b8ba4caa7dacc0edd3e405#diff-56f87108fb8c4605e56b4702938ff2211dd019c94ac130bfbc8016e6a9143dd0
I did not check this fix manually but run several test run while working
on updating flask-security in unstable at time.

[ Risks ]
The added debdiff is quite long as also a lot of documentation in
configuration.rst is added.
The relevant part of the source code changes to fix the CVE are rather
small and not very complex.

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

[ Changes ]
Upstream extended the function validate_redirect_url() in a way if a
configuration value of REDIRECT_VALIDATE_MODE is matching 'regex' the
given URL will get validated.
Upstream also added some more documentation in general to the
documentation and also to functions that are used.
And some test is added to the internal test suite.


[ Other info ]
This fix is backported from
https://github.com/Flask-Middleware/flask-security/pull/489
and is included within the current version in unstable/testing.

Note: The version in bullseye is originally based on the upstream source
https://github.com/mattupstate/flask-security!
But this git tree isn't actively maintained any more and the active
development is happen now on https://github.com/Flask-Middleware/flask-security 
where the version in unstable/testing is based on.

I was in conversation with the security team if this fix is worth to get
an update through stable-security. As the issue is tagged as
low-priority the suggestion was to fix the problem through a point
update for bullseye.
diff -Nru flask-security-4.0.0/debian/changelog 
flask-security-4.0.0/debian/changelog
--- flask-security-4.0.0/debian/changelog   2021-02-01 14:42:21.0 
+
+++ flask-security-4.0.0/debian/changelog   2023-02-14 11:10:52.0 
+
@@ -1,3 +1,12 @@
+flask-security (4.0.0-1+deb11u1) bullseye; urgency=medium
+
+  * Fix for CVE-2021-23385
+Cherry pick partially PR #489 from the upstream project
+(https://github.com/Flask-Middleware/flask-security/pull/489)
+to fix Open Redirect Vulnerability aka CVE-2021-23385.
+
+ -- Carsten Schoenert   Tue, 14 Feb 2023 11:10:52 
+
+
 flask-security (4.0.0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
flask-security-4.0.0/debian/patches/0001-A-hopeful-fix-for-possible-open-redirect.patch
 
flask-security-4.0.0/debian/patches/0001-A-hopeful-fix-for-possible-open-redirect.patch
--- 
flask-security-4.0.0/debian/patches/0001-A-hopeful-fix-for-possible-open-redirect.patch
 1970-01-01 01:00:00.0 +0100
+++ 
flask-security-4.0.0/debian/patches/0001-A-hopeful-fix-for-possible-open-redirect.patch
 2023-02-14 11:02:05.0 +
@@ -0,0 +1,298 @@
+From: jwag956 
+Date: Sat, 29 May 2021 19:18:55 -0700
+Subject: A (hopeful) fix for possible open-redirect.
+
+While this is only an issue if the application sets the Werkzeug response 
variable:
+autocorrect_location_header = False - it none the less poses a small security 
concern.
+
+pyupgrade and black changed again .. sigh...
+pin read the docs sphinx versions.
+
+Closes: #486
+
+Forwared: https://github.com/Flask-Middleware/flask-security/pull/489
+---
+ docs/configuration.rst   | 53 +++-
+ flask_security/core.py   |  7 +-
+ flask_security/datastore.py  |  2 +-
+ flask_security/decorators.py |  4 ++--
+ flask_security/utils.py  | 31 ++
+ requirements/docs.txt|  6 ++---
+ tests/test_misc.py   | 17 ++
+ tests/view_scaffold.py   |  8 +++
+ 8 files changed, 120 insertions(+), 8 deletions(-)
+
+diff --git a/docs/configuration.rst b/docs/configuration.rst
+index 497bd1d..12144da 100644
+--- a/docs/configuration.rst
 b/docs/configuration.rst
+@@ -216,7 +216,7 @@ These configuration keys are used globally across all 
features.
+ .. py:data:: SECURITY_REDIRECT_ALLOW_SUBDOMAINS
+ 
+ If ``True`` then subdomains (and the root domain) of the top-level host 
set
+-by Flask's ``SERVER_NAME`` configuration will be allowed as post-login

Bug#1031280: ITP: ptex -- A texture mapping system developed by Walt Disney Animation Studios for production-quality rendering.

[Andreas Wendleder]

Package: wnpp
Severity: wishlist
Owner: Andreas Wendleder 
X-Debbugs-Cc: debian-de...@lists.debian.org, andreas.wendle...@gmail.com

* Package name: ptex
  Version : 2.4.2
  Upstream Author : David Aguilar 
* URL : https://ptex.us/
* License : BSD
  Programming Lang: C++
  Description : A texture mapping system developed by Walt Disney Animation 
Studios for production-quality rendering.

Ptex is a texture mapping system developed by Walt Disney Animation Studios for 
production-quality rendering:

No UV assignment is required! Ptex applies a separate texture to each face of a 
subdivision or polygon mesh.

The Ptex file format can efficiently store hundreds of thousands of texture 
images in a single file.

The Ptex API provides cached file I/O and high-quality filtering - everything 
that is needed to easily add Ptex
support to a production-quality renderer or texture authoring application.

Bug#1031281: wsgicors: Vcs not available

[Bastian Germann]

Source: wsgicors
Version: 0.4.1-1.1
Severity: important

The Mercurial repository that d/control's Vcs-* fields reference is not 
available.
Please make it available or drop the fields.

Bug#1031282: joe: Vcs points to upstream repo

[Bastian Germann]

Source: joe
Version: 4.6-1
Severity: important

The Mercurial repository that d/control's Vcs-* fields reference is upstream's 
repo.
Those fields are expected to point to the repo where the package is maintained.

Bug#1031267: debmany: shell injection

[Axel Beckert]

Control: tag -1 + confirmed

Hi Jakub,

thanks for the bug report.

Jakub Wilk wrote:
> debmany passes filenames from the .deb (which should be considered untrusted
> input) to eval.
>
> I've attached proof-of-concept exploit.

Thanks. Can reproduce it.

Given that the full path including the exploit code is always shown to
the user before the exploit actually runs, I consider the impact
rather low:

┌┤ Select a file (file:./injection.deb) 
├┐
│   
 │
│  usr/share/doc/$(cowsay${IFS}pwned>/dev/tty;sleep${IFS}inf)/changelog.gz 
changelog.gz  │
│   
 │
│   
 │
│   
 │
└┘

Accordingly a severity of only "normal" seems fitting.

Should be fixed nevertheless. Will look into it.

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


signature.asc
Description: PGP signature

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

[Steve McIntyre]

On Tue, Feb 14, 2023 at 12:50:18PM +0100, Daniel Leidert wrote:
>Am Dienstag, dem 14.02.2023 um 10:45 + schrieb Steve McIntyre:
>> On Tue, Feb 14, 2023 at 11:34:13AM +0100, Daniel Leidert wrote:
>> > Am Montag, dem 13.02.2023 um 21:35 -0500 schrieb Theodore Ts'o:
>> 
>> ...
>> 
>> > > But a generalized requirement that we be able to use debootstrap and
>> > > vmdb2 to be able to bootstrap an arbitrarily old distribution doesn't
>> > > seem to be reasonable.
>> > 
>> > You are completyl wrong. This breaks a standard way of installing any
>> > system supported by deboostrap with a grub without a fix to deal with
>> > this version of e2fsprogs. This isn't just about vmdb2.
>> > 
>> > What you are saying is ignorant.
>> > 
>> > If this isn't cared about, then this version of e2fsprogs shouldn't
>> > make it into Bookworm. We are in the middle of a freeze and this breaks
>> > toolchains and a standard way (see [1]) of installing Debian.
>> 
>> Sorry Daniel, but I have to (mostly!) agree with Ted here. If you're
>> creating an image of an older release using newer tools then you'll
>> need to be aware that sometimes the newer tools will create things
>> that don't work there. If there's a bug here, I would strongly argue
>> that it's in vmdb2. deboostrap (for example) includes some
>> release-specific knowledge to cope with issues like this.
>
>debootstrap does nothing related to grub. So it is a bad example.

That's why I said *like* this, not *exactly* like this. debootstrap
has had knowledge of things like fs layouts etc. that older releases
need (e.g. merged-/usr).

>Again I refer to [1]: If the host system contains the problematic
>e2fsprogs and the target system doesn't contain a grub with the fix
>[2], then this breaks installations. This breaks older systems *and*
>current systems. For example, I neither see the necessary grub patch
>in both Ubuntu 20.04 and 22.04 either. So they also cannot be
>installed using the deboostrap method and the toolchain in Sid (and
>Bookworm if e2fsprogs makes it there).

Breakages happen like this, and this has happened before in similar
circumstances. If you're installing an older system using brand-new
tools, you need to be aware of the potential for things to not
work. In this particular case, all you need to do is tweak the flags
on the ext4 filesystem when you create it. This isn't that hard...

>[1] https://www.debian.org/releases/stable/amd64/apds03
>[2] Even "our" grub only contains a patch and not an upstream version
>with support. So how can you even expect the target system to contain a
>fix and be able to handle the created filesystem?!
>
>Whe whole handling is completely wrong here. First, grub should have
>been fixed upstream. And the change in e2fsprogs should have been done
>only after "fixed" grub versions had settled. If we do it the other way
>around, we have to patch grub in affected distributions as well. And
>for Debian that means at least to patch Bullseye and any other release
>we want to be able to install from Bookworm. I even a lot of companies
>using Buster still.

And I know of folks still working on Stretch and Jessie. How far back
do you want to tie things??

>> If we don't allow for this kind of change, that wouldn't allow us to
>> *ever* make breaking changes in some packages, and that's just not
>> sustainable.
>
>I'm critizicing the way of handling that breaking change and the
>ignorance shown reagarding the impact, not that fact that there is a
>breaking change. And it breaks a lot! This doesn't affect just a few
>minor use cases. It affects the basic way of installing a clean Ubuntu
>or Debian (or derivative) on a remote server using the debootstrap
>method.

People using these tools need to be aware of the potential issue. What
would happen if you ran debootstrap with a filesystem that the target
distro doesn't know how to mount at all, for example?

>And again: We are in the middle of a freeze here. And e2fsprogs pushes
>a breaking change that is not even handled by any existing grub
>upstream release, and is also not properly handled within Debian?!

Grub upstream is already known to be problematic in terms of release
cycles. We now know about this particular issue (thanks Ted!) and
we've fixed it in unstable (and soon testing).

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?

Bug#1031283: apt-cacher-ng: 503 errors while installing many packages

[Blomley, Edmund (IBPT)]

Package: apt-cacher-ng
Version: 3.7.4-1

Dear Maintainer,

With the above version of apt-cacher-ng we encounter a bug while installing
packages. (In our scenario the apt-cacher-ng itself runs in a Docker image
based on ubuntu:jammy-20230126 (22.04 LTS)).

The below error message happens for many packages (below is a more complete
log):

E: Failed to fetch
http://archive.ubuntu.com/ubuntu/pool/main/a/automake-1.16/automake_1.16.1-4
ubuntu6_all.deb  503  Connection closed, check DlMaxRetries [IP: x.x.x.x
3142]

This occurs reproducibly in scenarios where many packages will be installed
at a time (in our case while building docker images). This behaviour is not
100% reproducible and might not occur if only a low number of packages is
being installed. It also sometimes works without issues for a large number
of packages. But most of the times starts failing after 40-60 packages.

The only reliable workaround we found was "downgrading" the apt-cacher-ng
version to 3.6.4 (based on Debian 11, docker image
debian:bullseye-20230208). There is also an open bug report on the ubuntu
bug tracker:
https://bugs.launchpad.net/ubuntu/+source/apt-cacher-ng/+bug/1960264 but it
does not only occur with PPAs, but also regular repositories.

Below is the more detailed log for a situation with a low amount of packages
being installed.

[...]
0 upgraded, 63 newly installed, 0 to remove and 4 not upgraded.
Need to get 26.7 MB of archives.
After this operation, 133 MB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 libssl1.1
amd64 1.1.1f-1ubuntu2.17 [1322 kB]
Get:2 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
libpython3.8-minimal amd64 3.8.10-0ubuntu1~20.04.6 [717 kB]
Get:3 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 libexpat1
amd64 2.2.9-1ubuntu0.6 [74.6 kB]
Get:4 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
python3.8-minimal amd64 3.8.10-0ubuntu1~20.04.6 [1901 kB]
Get:5 http://archive.ubuntu.com/ubuntu focal/main amd64 python3-minimal
amd64 3.8.2-0ubuntu2 [23.6 kB]
Get:6 http://archive.ubuntu.com/ubuntu focal/main amd64 mime-support all
3.64ubuntu1 [30.6 kB]
Get:7 http://archive.ubuntu.com/ubuntu focal/main amd64 libmpdec2 amd64
2.4.2-3 [81.1 kB]
Get:8 http://archive.ubuntu.com/ubuntu focal/main amd64 readline-common all
8.0-4 [53.5 kB]
Get:9 http://archive.ubuntu.com/ubuntu focal/main amd64 libreadline8 amd64
8.0-4 [131 kB]
Get:10 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
libsqlite3-0 amd64 3.31.1-4ubuntu0.5 [549 kB]
Get:11 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
libpython3.8-stdlib amd64 3.8.10-0ubuntu1~20.04.6 [1675 kB]
Get:12 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 python3.8
amd64 3.8.10-0ubuntu1~20.04.6 [387 kB]
Get:13 http://archive.ubuntu.com/ubuntu focal/main amd64 libpython3-stdlib
amd64 3.8.2-0ubuntu2 [7068 B]
Get:14 http://archive.ubuntu.com/ubuntu focal/main amd64 python3 amd64
3.8.2-0ubuntu2 [47.6 kB]
Get:15 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
perl-modules-5.30 all 5.30.0-9ubuntu0.3 [2739 kB]
Get:16 http://archive.ubuntu.com/ubuntu focal/main amd64 libgdbm6 amd64
1.18.1-5 [27.4 kB]
Get:17 http://archive.ubuntu.com/ubuntu focal/main amd64 libgdbm-compat4
amd64 1.18.1-5 [6244 B]
Get:18 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 libperl5.30
amd64 5.30.0-9ubuntu0.3 [3951 kB]
Get:19 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 perl amd64
5.30.0-9ubuntu0.3 [224 kB]
Get:20 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 openssl
amd64 1.1.1f-1ubuntu2.17 [622 kB]
Get:21 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
ca-certificates all 20211016ubuntu0.20.04.1 [141 kB]
Get:22 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
python3-pkg-resources all 45.2.0-1ubuntu0.1 [130 kB]
Get:23 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
libkrb5support0 amd64 1.17-6ubuntu4.2 [31.0 kB]
Get:24 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
libk5crypto3 amd64 1.17-6ubuntu4.2 [80.0 kB]
Get:25 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
libkeyutils1 amd64 1.6-6ubuntu1.1 [10.3 kB]
Get:26 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 libkrb5-3
amd64 1.17-6ubuntu4.2 [330 kB]
Get:27 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
libgssapi-krb5-2 amd64 1.17-6ubuntu4.2 [121 kB]
Get:28 http://archive.ubuntu.com/ubuntu focal/main amd64 libpsl5 amd64
0.21.0-1ubuntu1 [51.5 kB]
Get:29 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 libbrotli1
amd64 1.0.7-6ubuntu0.1 [267 kB]
Get:30 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
libroken18-heimdal amd64 7.7.0+dfsg-1ubuntu1.4 [42.5 kB]
Get:31 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
libasn1-8-heimdal amd64 7.7.0+dfsg-1ubuntu1.4 [181 kB]
Get:32 http://archive.ubuntu.com/ubuntu focal-updates/main amd64
libheimbase1-heimdal amd64 7.7.0+dfsg-1ubuntu1.4 [30.4 kB]
Get:33 http://archive.ubuntu

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

[Daniel Leidert]

Am Dienstag, dem 14.02.2023 um 14:58 + schrieb Steve McIntyre:
> On Tue, Feb 14, 2023 at 12:50:18PM +0100, Daniel Leidert wrote:
> 
> 
[..]
> Breakages happen like this,

This breakage is *unnecessary* and it breaks at the momnent *all*
debootstrap installations except for doing a bookworm/sid installation
themselves. That is just stupid.

Get down from your high horse and ackknowledge the problems your
behavior causes.

> and this has happened before in similar
> circumstances.

No it has not. You are doing a breakage on purpose during a freeze
period while the transition period is over. Do it with a proper
transition during the next release cycle.


> > 
[..]
> > Whe whole handling is completely wrong here. First, grub should have
> > been fixed upstream. And the change in e2fsprogs should have been done
> > only after "fixed" grub versions had settled. If we do it the other way
> > around, we have to patch grub in affected distributions as well. And
> > for Debian that means at least to patch Bullseye and any other release
> > we want to be able to install from Bookworm. I even a lot of companies
> > using Buster still.
> 
> And I know of folks still working on Stretch and Jessie. How far back
> do you want to tie things??

How about staying on topic and explaining, why this transition is
necessary and has to be done the wrong way around, instead of picking
the fact that older systems still exist? You break almost *all*
installation right now. You also broke an Ubuntu 20.04 or 22.04 LTS
installation. Are they new enough?

[..]
> > 
> > I'm critizicing the way of handling that breaking change and the
> > ignorance shown reagarding the impact, not that fact that there is a
> > breaking change. And it breaks a lot! This doesn't affect just a few
> > minor use cases. It affects the basic way of installing a clean Ubuntu
> > or Debian (or derivative) on a remote server using the debootstrap
> > method.
> 
> People using these tools need to be aware of the potential issue. What
> would happen if you ran debootstrap with a filesystem that the target
> distro doesn't know how to mount at all, for example?

That is different from introducing a breaking change for which no grub
upstream release has a fix yet. So basically the only system able to
handle a filesystem created with e2fsprogs 1.47.0 is Sid right now. Can
you please ignore your ego and see the problems you are causing?

You push a breaking change for no reason at all. What is the gain here
compared to the issues you are causing?

> > And again: We are in the middle of a freeze here. And e2fsprogs
> > pushes
> > a breaking change that is not even handled by any existing grub
> > upstream release, and is also not properly handled within Debian?!
> 
> Grub upstream is already known to be problematic in terms of release
> cycles.

That is not enough and it is not a solution for the problem. There is
*no* grub version out there supporting this, except for the patched
version is Sid. Is this the sign for a working transition?

> We now know about this particular issue (thanks Ted!) and
> we've fixed it in unstable (and soon testing).

Which helps exactly nobody, as it still breaks all other Debian or
Ubuntu installation.

I cannot belive that you intentionally break one of the standard
methods to install Debian or Ubuntu for no reason at all and without a
proper transition. Version 1.47.0 of e2fsprogs contains nothing
necessary for Bookworm. I'll bring this to the attention of the release
team. I'm sick of your ignorance. Do a proper transition and don't
start it during a freeze.


Daniel

Bug#557730: /etc/{protocols,network,services} not schroot's to scribble over

[Wookey]

Source: schroot
Version: 1.6.13-3
Followup-For: Bug #557730

Just discovered this bug from 2009. This problem has been annoying me
regularly since about then, and I finally got round to working out what was
actually going on, which led me here.

The primary practical issue is that builds in the chroot are quite likely to 
bring in netbase, and that package contains /etc/protocols and /etc/services so 
when dpkg finds that they are already present in the chroot it stops with:
Setting up netbase (6.4) ...

Configuration file '/etc/protocols'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** protocols (Y/I/N/O/D/Z) [default=N] ?

So I often find that a build has just got stuck at the beginning
unless I inject y\ny\n.  This has caused endless hassle over the
years, and it's a bit sad to see it's not been fixed in 13 years. I
always assumed that someone would sort this out at some point and the
hassle would go away.

There are various ways we could deal with this. Sbuild-createchroot could set
1) Dpkg::Options::force=--force-confnew in its chroots.

Are there reasons you might not want to set this in general? People
would expect conf changes they made in their chroots to be preserved
just the way they are in a normal system. So this seems like it would
be intrusive.

2) netbase could be installed in base chroots then the problem would not arise 
(or only arise once).

The problem here is that chroots can be made by many tools, and the
usual tools (debootstrap and mmdebstrap) do not put netbase in by
default. It would be very easy to make sbuild-createchroot just add
--include=netbase to the invocation, and I'm not sure there is any
real downside to doing that? Documenting the reason for including this
package so that people using other tools to make chroots know it's a
good idea would also be easy and helpful.

3) schroot could just not copy those files over.

Whilst having the passwd database reflected in the chroot is
incredibly useful it's not clear how often the services and protocols
are needed, but I assume people do find that functionality useful.
  
The actual issue here is that schroot is copying them over even when
they don't exist in the chroot, then the thing that is supposed to be
installing them gets tripped up (correctly) by dpkg's checks.

So a simple fix that keeps the functionality when it's useful, but
stops this breakage, would be to only copy over the files in the
nssdatabases list _if they are already present in the
chroot_. Possibly that should apply to all the files in the list?

I'll see if I can come up with a patch to do that.

Bug#1024647: trac: The versiuon packaged by debian contain a bug fixed upstream that prevent it to work with python3

[James Addison]

Package: trac
Followup-For: Bug #1024647

Dear Maintainer,

The upload of 1.5.4-1 to unstable should, I think, also allow closing this bug.

(the changeset[1] linked in the forwarded-to field for this bug is included[2]
in the upstream v1.5.4 release)

Thanks,
James

[1] - https://trac.edgewall.org/changeset/17571

[2] - https://trac.edgewall.org/wiki/1.5/TracChangeLog

Bug#1031284: RFS: wl-mirror/0.12.2-1 [ITP] -- output-mirroring tool for wlroots-based Wayland desktops

[Ferdinand Bachmann]

Package: sponsorship-requests
Severity: wishlist
Owner: Ferdinand Bachmann 
X-Debbugs-Cc: debian-de...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "wl-mirror":

 * Package name : wl-mirror
   Version  : 0.12.2-1
   Upstream contact : Ferdinand Bachmann 
 * URL  : https://github.com/Ferdi265/wl-mirror
 * License  : GPL-3+
 * Vcs  : https://github.com/Ferdi265/wl-mirror-debian
   Section  : x11

The source builds the following binary packages:

  wl-mirror - output-mirroring tool for wlroots-based Wayland desktops

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


  https://mentors.debian.net/package/wl-mirror/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/wl-mirror/wl-mirror_0.12.2-1.dsc


Additionally, my current development tree for the Debian source package, 
including scripts/Dockerfiles (since I am developing this on a 
non-Debian system) is the following URL:


  https://github.com/Ferdi265/wl-mirror-debian

Changes for the initial release:

 wl-mirror (0.12.2-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1012684)

Regards,
--
  Ferdinand Bachmann

Bug#557730: /etc/{protocols,network,services} not schroot's to scribble over

[Ian Jackson]

Wookey writes ("Bug#557730: /etc/{protocols,network,services} not schroot's to 
scribble over"):
> 2) netbase could be installed in base chroots then the problem would not 
> arise (or only arise once).
> 
> The problem here is that chroots can be made by many tools, and the
> usual tools (debootstrap and mmdebstrap) do not put netbase in by
> default. It would be very easy to make sbuild-createchroot just add
> --include=netbase to the invocation, and I'm not sure there is any
> real downside to doing that? Documenting the reason for including this
> package so that people using other tools to make chroots know it's a
> good idea would also be easy and helpful.

A downside is that missing build-dependencies on netbase would no
longer be detected.  One alternative would be to declare netbase
build-essential.  TBH I'm not sure why that hasn't been done already.

I have a 4th option:

scroot could create this file by installing and then removing (but not
purging) a fake netbase.deb ("Version: 0~~).  Then, when the new
netbase appears, the usual conffile mechanism would DTRT, since the
file would not have been "locally created" (or indeed "locally
modified").

The fake netbase.deb could be contained within schroot.deb, in
/usr/share, so schroot wouldn't need to gain runtime build-deps on
dpkg tooling.

> Whilst having the passwd database reflected in the chroot is
> incredibly useful it's not clear how often the services and protocols
> are needed, but I assume people do find that functionality useful.

I had a package that failed its build-time tests due to lack of
/etc/protocols.  The missing build-dep was detected in the buildds,
because my own local sid build chroot has netbase installed, precisely
because of this bug.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1027706: gourmand: Instructions not saved

[thierry.jeanmou...@cegetel.net]

This version crashes, maybe a compatibility issue with Bookworm.
Better wait till it's moved to testing.

Thanks

Le 14/02/2023 à 15:08, Christian Marillat a écrit :

On 02 janv. 2023 10:48, Thierry Jeanmougin  
wrote:


Package: gourmand
Version: 1.1.0+really1.0.0-3
Severity: important
Tags: upstream

Dear Maintainer,

Instructions are not saved when creating or editing a recipe.
The instruction section appears blank once the recipe is saved and reopened,
whereas the information in the other sections (description, ingredients and
notes) are correcly saved

Could you try the 1.1.0+really1.1.0~rc3-2 package from unstable ?

Christian

Bug#1031285: reportbug: redshift-gtk closes returning from monitor standby

[Lorenzo Iannuzzi]

Package: redshift
Version: 1.12-4.2
Severity: normal

Dear Maintainer,
I started receiving error messages from redshift-gtk when I changed my monitors 
configuration. Now I have an external monitor as my main monitor and the 
monitor of my notebook turned off.
The message says:
> Failed to run Redshift
> Failed to start adjustment method wayland.
> Trying next method...
> Waiting for initial location to become available...
> `RANDR Set CRTC Gamma' returned error 148
> Temperature adjustment failed.
Then redshift-gtk closes. This occurs every time I return from monitor standby.
If I reopen redshift-gtk, it works as usual, until my monitor goes standby 
again.


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

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

Versions of packages redshift depends on:
ii  libc6   2.31-13+deb11u5
ii  libdrm2 2.4.104-1
ii  libglib2.0-02.66.8-1
ii  libwayland-client0  1.18.0-2~exp1.1
ii  libx11-62:1.7.2-1
ii  libxcb-randr0   1.14-3
ii  libxcb1 1.14-3
ii  libxxf86vm1 1:1.1.4-1+b2

Versions of packages redshift recommends:
ii  geoclue-2.0  2.5.7-3

redshift suggests no packages.

-- no debconf information

Bug#1027706: gourmand: Instructions not saved

[Christian Marillat]

On 14 févr. 2023 16:55, "thierry.jeanmou...@cegetel.net" 
 wrote:

> This version crashes, maybe a compatibility issue with Bookworm.
> Better wait till it's moved to testing.

Did you install all python packages dependencies ?

Christian

Bug#1031287: clifm -- the shell-like, command line file manager

[Leonardo Abramovich]

Package: wnpp
Severity: wishlist

* Package Name : clifm
Version : 1.10
Upstream Author : Leonardo Abramovich (me)
* URL : https://github.com/leo-arch/clifm
* License : GPLv2+
Programming Lang : C (C99)
Description : A shell-like, command line interface file manager

Clifm is a Command Line Interface File Manager: all input and interaction is 
performed via commands. This is its main feature and strength.

Unlike most terminal file managers out there, indeed, clifm replaces the 
traditional TUI interface (also known as curses or text-menu based interface) 
by a command-line interface (CLI), also known as REPL.

If working with the command-line, your workflow is not affected at all, but 
just enriched with file management functionalities: automatic files listing, 
files selection, bookmarks, tags, directory jumper, directory and commands
history, auto-cd and auto-open, bulk rename, TAB completion, autosuggestions, 
and a trash system, among other features. In this sense, clifm is certainly a 
file manager, but also a shell extension.

Briefly put, with clifm the command-line is always already there, never hidden.

Dependencies: libcap-dev, libacl1-dev, libreadline-dev, libmagic-dev.

Clifm is already packaged (and working perfectly) for Debian via the OpenSUSE 
Build System:
https://build.opensuse.org/package/show/home:archcrack/CliFM

Thank you very much in advance!
Leo.

Bug#1031286: Installer hangs while detecting MT7921 Wi-Fi card

[Wojciech Palacz]

Package: installation-reports

Boot method: USB
Image version: firmware-testing-amd64-netinst.iso 20230209-17:55
Date: 2023-02-14

Machine: ASUS PN51-S1

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

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

Comments/Problems:

The installer on the current weekly "Bookworm" netinst image gets to
the "Detect network hardware" stage and then hangs. It does not matter
if I use the official image, or the unofficial non-free image with
firmware included.

Pressing ^C interrupts the hanged process and brings the install menu
back. I was able to run a shell and check the logs.

There are many error messages from the mt7921e kernel module. It cannot
find its firmware, then it causes some kind of serious error resulting
in a kernel call trace dump.

==
tail end of /var/log/syslog
==

Feb 14 11:48:54 kernel: [  129.903724] Lockdown: archdetect: /dev/mem,kmem,port 
is restricted; see man kernel_lockdown.7
Feb 14 11:49:12 main-menu[410]: INFO: Falling back to the package description 
for brltty-udeb
Feb 14 11:49:12 main-menu[410]: INFO: Menu item 'ethdetect' selected
Feb 14 11:49:12 kernel: [  148.273169] Lockdown: archdetect: /dev/mem,kmem,port 
is restricted; see man kernel_lockdown.7
Feb 14 11:49:13 net/hw-detect.hotplug: Detected hotpluggable network interface 
lo
Feb 14 11:49:13 kernel: [  148.520097] cfg80211: Loading compiled-in X.509 
certificates for regulatory database
Feb 14 11:49:13 kernel: [  148.520217] cfg80211: Loaded X.509 cert 
'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf'
Feb 14 11:49:13 kernel: [  148.520319] cfg80211: Loaded X.509 cert 
'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
Feb 14 11:49:13 kernel: [  148.520419] cfg80211: Loaded X.509 cert 'sforshee: 
00b28ddf47aef9cea7'
Feb 14 11:49:13 kernel: [  148.520451] platform regulatory.0: firmware: 
direct-loading firmware regulatory.db
Feb 14 11:49:13 kernel: [  148.520461] platform regulatory.0: firmware: 
direct-loading firmware regulatory.db.p7s
Feb 14 11:49:13 kernel: [  148.554269] r8169 :02:00.0 eth0: RTL8125B, 
50:eb:f6:ee:eb:2b, XID 641, IRQ 78
Feb 14 11:49:13 kernel: [  148.554274] r8169 :02:00.0 eth0: jumbo features 
[frames: 9194 bytes, tx checksumming: ko]
Feb 14 11:49:13 kernel: [  148.555382] r8169 :02:00.0 enp2s0: renamed from 
eth0
Feb 14 11:49:13 net/hw-detect.hotplug: Detected hotpluggable network interface 
enp2s0
Feb 14 11:49:13 kernel: [  148.696027] mt7921e :03:00.0: enabling device 
( -> 0002)
Feb 14 11:49:13 kernel: [  148.713083] mt7921e :03:00.0: ASIC revision: 
79610010
Feb 14 11:49:13 kernel: [  148.797172] mt7921e :03:00.0: firmware: failed 
to load mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin (-2)
Feb 14 11:49:13 kernel: [  148.797178] firmware_class: See 
https://wiki.debian.org/Firmware for information about missing firmware
Feb 14 11:49:13 kernel: [  148.797183] mt7921e :03:00.0: firmware: failed 
to load mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin (-2)
Feb 14 11:49:13 kernel: [  148.797185] mt7921e :03:00.0: Direct firmware 
load for mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin failed with error -2
Feb 14 11:49:13 kernel: [  148.884630] mt7921e :03:00.0: firmware: failed 
to load mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin (-2)
Feb 14 11:49:13 kernel: [  148.884651] mt7921e :03:00.0: firmware: failed 
to load mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin (-2)
Feb 14 11:49:13 kernel: [  148.884655] mt7921e :03:00.0: Direct firmware 
load for mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin failed with error -2
Feb 14 11:49:13 kernel: [  148.972768] mt7921e :03:00.0: firmware: failed 
to load mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin (-2)
Feb 14 11:49:13 kernel: [  148.972791] mt7921e :03:00.0: firmware: failed 
to load mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin (-2)
Feb 14 11:49:13 kernel: [  148.972795] mt7921e :03:00.0: Direct firmware 
load for mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin failed with error -2
Feb 14 11:49:13 kernel: [  149.056984] mt7921e :03:00.0: firmware: failed 
to load mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin (-2)
Feb 14 11:49:13 kernel: [  149.057007] mt7921e :03:00.0: firmware: failed 
to load mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin (-2)
Feb 14 11:49:13 kernel: [  149.057010] mt7921e :03:00.0: Direct firmware 
load for mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin failed with error -2
Feb 14 11:49:13 kernel: [  149.141061] mt7921e :03:00.0: firmware: failed 
to load mediatek/WIFI_MT7961_patch_mcu

Bug#1031146: RFS: lighttpd/1.4.69-1 [NMU] -- light, fast, functional web server

[Santiago Ruano Rincón]

Hello Glenn,

El 12/02/23 a las 08:54, Glenn Strauss escribió:
> > Since you are listed in Uploaders:, this shouldn't be a NMU. I don't
> > understand why lintian doesn't complain about this in this job:
> > https://salsa.debian.org/debian/lighttpd/-/jobs/3931309
> > but don't have the time to investigate that right now.
> > 
> > Please, fix the changelog.
> 
> changelog updated.  Thanks for your guidance.
> Cheers, Glenn
> 

Sorry I was unable to give you more feedback the first time. So I am
iterating. ENOTIME…

Here you have some comments regarding two files:

1. d/changelog:

lighttpd (1.4.69-1) unstable; urgency=medium

  [ Glenn Strauss ]

Since you are the only one doing changes in this release, no need to
tell that twice. You can remove the line above.

  * New upstream version 1.4.69
  * (changes for 1.4.68; not released in Debian)

I am afraid I cannot parse that entry. What are the changes related to
1.4.68?

  * Remove deprecated lighttpd modules.
  * Skip installing modules now built into lighttpd.
  * Add to not-installed mods now built into lighttpd.

Is it worth to list those modules?
Is there any impact for the uses to they should be warned via e.g.
debian/NEWS too?

  * Declare compliance with policy 4.6.2 - no changes needed.
  * lighttpd.init reopen-logs only if lighttpd is currently running.
  * New upstream version 1.4.68

I don't think the line above is needed. You are doing a release for
1.4.69.

$ git branch --track upstream origin/upstream
$ git branch --track pristine-tar origin/pristine-tar
$ release=1.4.68
$ cd ..
$ wget 
https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-$release.tar.xz
$ wget 
https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-$release.tar.xz.asc

(Just in case, you can use uscan for that)

$ cd -
$ git fetch origin
$ git checkout pristine-tar
$ git pull --rebase
$ git checkout master
$ gbp import-orig --uscan -u $release
# - adds commits to 'pristine-tar' and 'upstream' branches
# - tags 'upstream' branch upstream/$release
# - merges upstream/$release tag into master branch
$ git push origin master pristine-tar upstream/$release

Neither I wouldn't place these instructions in d/changelog.

 -- Glenn Strauss   Fri, 10 Feb 2023 22:34:51 -0500


2. d/lighttpd.NEWS:

As lintian complains, this entry relates a release not known by debian:

lighttpd (1.4.67-2) experimental; urgency=medium

Do you think NEWS could be updated?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#557730: /etc/{protocols,network,services} not schroot's to scribble over

[Wookey]

On 2023-02-14 16:02 +, Ian Jackson wrote:
> Wookey writes ("Bug#557730: /etc/{protocols,network,services} not schroot's 
> to scribble over"):
> > 2) netbase could be installed in base chroots then the problem would not 
> > arise (or only arise once).
> > 
> A downside is that missing build-dependencies on netbase would no
> longer be detected.  One alternative would be to declare netbase
> build-essential.  TBH I'm not sure why that hasn't been done already.

Good point. And related to recent debian-devel discussion about bare
build chroots actually being bare so that missing build-deps are
indeed discovered. I don't think that just adding more things to
'essential' is actually helpful here. netbase is not essential,
especially for builds that explicitly mustn't use the (external)
network.

To be fair schroot has a 'config=buildd' setup where /etc/protocols
and /etc/services are not copied over (and configs 'minimal', 'sbuild'
and 'mini-buildd'). The problematic situation is 'config=default' (and
'desktop') where they are. But I use the 'default' setup a lot because
it mounts /home as well and that's hugely helpful for doing various
sort of work, as opposed to a totally-clean sbuild build. And I think
it may be the default for sbuild-createchroot, but I could be wrong
about that.

For nearly everything I do a config without /etc{protocols|services}
but with /home would work great, but none of the supplied configs:
minimal, buildd, mini-buildd, sbuild, default, desktop do that. Do we
really need a 7th config (and if so what should it be
called?). Obviously I can just make one, but the fact that problem
affects people so often with the 'default' config seems to me to be a
problem we should try to fix.

> I have a 4th option:
> 
> scroot could create this file by installing and then removing (but not
> purging) a fake netbase.deb ("Version: 0~~).  Then, when the new
> netbase appears, the usual conffile mechanism would DTRT, since the
> file would not have been "locally created" (or indeed "locally
> modified").

That is a neat idea.

> The fake netbase.deb could be contained within schroot.deb, in
> /usr/share, so schroot wouldn't need to gain runtime build-deps on
> dpkg tooling.

Except that it has to build this package live in order to contain the
/etc/protocols and /etc/services files from the host
environment. Having these default files with standard contents in a
pre-built .deb is pointless, isn't it?

> > Whilst having the passwd database reflected in the chroot is
> > incredibly useful it's not clear how often the services and protocols
> > are needed, but I assume people do find that functionality useful.
> 
> I had a package that failed its build-time tests due to lack of
> /etc/protocols.  The missing build-dep was detected in the buildds,
> because my own local sid build chroot has netbase installed, precisely
> because of this bug.

Right, which gets back to having a proper minimal environment used by
sbuild to do a clean build. I have that (and it doesn't mount home,
using the 'sbuild' profile). I use it once things are working
reasonably well to get at least one clean build before uploading. This
bug is a problem in the 'less clean, but more useful' 'default' chroot
environment which is best for diagnostic work and builds of various
sorts where some file persistence (of user files) is needed.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1027706: gourmand: Instructions not saved

[thierry.jeanmou...@cegetel.net]

I guess they are automatically installed by apt (see below)
If more updates are needed, I'd rather not break my system, and wait for 
the new version in testing.


$ sudo apt install gourmand/unstable
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
Version choisie « 1.1.0+really1.1.0~rc3-2 » (Debian:unstable [all]) pour 
« gourmand »

Les paquets supplémentaires suivants seront installés :
  python3-isodate python3-recipe-scrapers
Les NOUVEAUX paquets suivants seront installés :
  python3-isodate python3-recipe-scrapers
Les paquets suivants seront mis à jour :
  gourmand

Le 14/02/2023 à 17:10, Christian Marillat a écrit :

On 14 févr. 2023 16:55, "thierry.jeanmou...@cegetel.net" 
 wrote:


This version crashes, maybe a compatibility issue with Bookworm.
Better wait till it's moved to testing.

Did you install all python packages dependencies ?

Christian

Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

[Samuel Thibault]

Source: linux
Version: 6.1.8-1
Severity: normal
Tags: a11y d-i

Hello,

Some people on debian-accessibility wanted to install debian in arm64
under the utm wrapped qemu on Macos. The current installation images
however do not include sound drivers and speakup. Applying the attached
patch to d-i brings:

E: Unable to locate package sound-modules-6.1.0-4-arm64-di
E: Unable to locate package speakup-modules-6.1.0-4-arm64-di

and indeed, it seems these modules are getting built only for amd64,
686, mips, sh4.

Could we consider adding them on arm64 in the linux package?

Thanks,
Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/build/pkg-lists/cdrom/grub/gtk/arm64.cfg 
b/build/pkg-lists/cdrom/grub/gtk/arm64.cfg
index 25992fbe8..def0e98d5 100644
--- a/build/pkg-lists/cdrom/grub/gtk/arm64.cfg
+++ b/build/pkg-lists/cdrom/grub/gtk/arm64.cfg
@@ -5,7 +5,7 @@ event-modules-${kernel:Version}
 xserver-xorg-input-libinput-udeb
 xserver-xorg-video-fbdev-udeb
 
-#speakup-modules-${kernel:Version}
-#sound-modules-${kernel:Version}
-#console-setup-linux-fonts-udeb
-#espeakup-udeb
+speakup-modules-${kernel:Version}
+sound-modules-${kernel:Version}
+console-setup-linux-fonts-udeb
+espeakup-udeb
diff --git a/build/pkg-lists/netboot/gtk/arm64.cfg 
b/build/pkg-lists/netboot/gtk/arm64.cfg
index 25992fbe8..def0e98d5 100644
--- a/build/pkg-lists/netboot/gtk/arm64.cfg
+++ b/build/pkg-lists/netboot/gtk/arm64.cfg
@@ -5,7 +5,7 @@ event-modules-${kernel:Version}
 xserver-xorg-input-libinput-udeb
 xserver-xorg-video-fbdev-udeb
 
-#speakup-modules-${kernel:Version}
-#sound-modules-${kernel:Version}
-#console-setup-linux-fonts-udeb
-#espeakup-udeb
+speakup-modules-${kernel:Version}
+sound-modules-${kernel:Version}
+console-setup-linux-fonts-udeb
+espeakup-udeb

Bug#1031290: python-django: CVE-2023-24580 (denial-of-service vulnerability in file uploads)

[Chris Lamb]

Package: python-django
Version: 1:1.11.29-1+deb10u6
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for python-django.

CVE-2023-24580[0]:

  Potential denial-of-service vulnerability in file uploads

  Passing certain inputs to multipart forms could result in too many
  open files or memory exhaustion, and provided a potential vector for
  a denial-of-service attack.

  The number of files parts parsed is now limited via the new
  DATA_UPLOAD_MAX_NUMBER_FILES setting.

  

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-24580
https://www.cve.org/CVERecord?id=CVE-2023-24580


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1031291: uchardet: New upstream release (0.0.8, 2022-12-08)

[Florian Ernst]

Source: uchardet
Version: 0.0.7-1
Severity: wishlist

Dear maintainer,

there is a new upstream release available, cf.
:

| - New supports:
|   * Norwegian: IBM865, ISO-8859-1, ISO-8859-15 and WINDOWS-1252.
|   * Danish: IBM865.
| - Minimum CMake version bumped to 3.1 (requirement was 2.8.5 before) to
|   have CMake exported targets:
|   * The executable uchardet::uchardet
|   * The library uchardet::libuchardet
|   * The static library uchardet::libuchardet_static
| - Fix build issues for UWP on Windows.
| - Add uchardet CLI tool building support for MSVC.
| - Various bug fixes and docs/README tweaks.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1027706: gourmand: Instructions not saved

[Christian Marillat]

On 14 févr. 2023 18:07, "thierry.jeanmou...@cegetel.net" 
 wrote:

> I guess they are automatically installed by apt (see below)
> If more updates are needed, I'd rather not break my system, and wait
> for the new version in testing.

The best is to test the unstable package now. Broken package in unstable
will never enter testing if broken as we are in the freeze period.

Christian

Bug#1004588: libzip: New upstream release (1.8.0, 2021 Jun 18)

[Florian Ernst]

Control: retitle -1 libzip: New upstream release (1.9.2, 2022 Jun 28)

Dear maintainer,

by now there are several new upstream releases available, cf.
.

The additional changes contain

| libzip 1.9.2
| June 28, 2022
| Fix version number in header file.
| 
| libzip 1.9.1
| June 28, 2022
| Fix zip_file_is_seekable().
| 
| libzip 1.9.0
| June 13, 2022
| Add zip_file_is_seekable().
| Improve compatibility with WinAES.
| Fix encoding handling in zip_name_locate().
| Add option to zipcmp to output summary of changes.
| Various bug fixes and documentation improvements.

which seem nice enough to eventually have in Debian.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1031292: lvm2: Please ship the lvmautoactivation man page

[Ferenc Wágner]

Package: lvm2
Version: 2.03.11-2.1
Severity: normal

Dear Maintainer,

The lvmautoactivation(7) man page is missing from the lvm2 binary
package.  Please consider looking for other possible omissions as well.
-- 
Thanks,
Feri.

Bug#1017921: mpd tries to start on non-interactive sessions

[kaliko]

Hi Antoine,

Le 24/08/2022 à 14:54, Antoine Beaupré a écrit :

[…]
In any case, I think you're right this might not be an actual bug,
although I can't help but think that the [Install] block could target
graphical-session.target instead of default.target, which would possibly
remove a lot of those problems in the future.


Actually my use of MPD requires default.target for users mpd service.
I'm sharing a server with a friend, we both run our own instance of MPD 
to stream music through icecast (and we only have a shell to manage our 
accounts, no graphical env.).


I've always seen MPD as an audio player for advanced *nix users, I don't 
think we should make it too much "foolproof". I believe the current 
defaults for user/system services are a good trade off: user service 
disabled and system service enabled/started. It's well documented both 
in /usr/share/doc/mpd and on the https://wiki.debian.org/mpd


I suggest to close this bug.
Would it be fine with you ?
Cheers
k

ps: sorry for this late reply

Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting

[Aaron Rainbolt]

On 2/14/23 05:25, Jonathan Dowland wrote:

On Sat, Jan 21, 2023 at 09:26:03PM -0600, Aaron Rainbolt wrote:
If the XScreenSaver configuration file is included as a part of the 
core xscreensaver package itself, as a file that is simply unpacked, 
the following situation will result:

…
If the configuration file is split out into its own separate 
xscreensaver-config package

…

This is totally orthogonal to a solution to the bug reporter's issue.
Splitting the xscreensaver package up and shipping the same files in
different sub-packages and adding alternatives or other metapackage
complications will do nothing to solve their problem.

Your motivation for all that extra complexity is also orthogonal to
Debian: you're talking about an enhancement for Ubuntu. As it stands,
you're talking about making Debian worse to make Ubuntu better, and
that's a hard sell.


I don't really understand the purpose of this message - the bug report 
is closed and a solution was already uploaded.


--
Aaron Rainbolt
Lubuntu Developer
https://github.com/ArrayBolt3
https://launchpad.net/~arraybolt3
@arraybolt3:lubuntu.me on Matrix, arraybolt3 on irc.libera.chat



OpenPGP_0x6169B9B4248C0464.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031154: prelude-manager could not load pgsql plugin

[Krzysztof Jastrzębski]

Package: prelude-manager
Version: 5.2.0-2

Under Centos-like distros, postgres backend is usable.

EPEL RPM:
preludedb-pgsql.x86_64  5.2.0-2.el9  @epel

[root@rocky ~]# rpm -ql preludedb-pgsql | grep pgsql.so
/usr/lib64/libpreludedb/plugins/sql/pgsql.so
Above driver is found by prelude-manager, loaded and used.
So if same upstrem sources were used, maybe problem is with Debian 
libpq-dev package?


BTW: also trying pgsql driver with prewikka Debian package ends with:
/usr/lib/x86_64-linux-gnu/libpreludedb/plugins/sql/pgsql: file not found.
(also in 5.2.0-2 version under bookworm)

Centos is not planned - good to see prelude at production...

--
Pozdrawiam Krzysztof Jastrzębski <><
krzysztof[at]jastrzebscy[dot]pl http://www.jastrzebscy.pl/

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

[Theodore Ts'o]

There is another issue with vmdb2 if you are using XFS.  Starting with
xfsprogs 5.15 (which is already in testing), bigtime is enabled by
default, so that newly created XFS file systems won't be subject to
timestamp overflow in 2038.  Grub didn't land support for this feature
until 8b1e5d1936ff ("fs/xfs: Add bigtime incompat feature support") in
May 2021, despite the fact that XFS has had this feature for years and
years and years.

So if you aren't using the latest security fixes, and you are using
XFS as the boot partition --- it won't work on buster and bullseye.
"Fortunately", there were were massive number security vulnerabilities
in grub2 which forced a backport of grub2 2.06 to bullseye and buster,
so if you have the security updates enabled, you'll probably be OK ---
but it was only because of massive number of security problems forced
that backport.


In any case, a version of grub that will support the csum_seed feature
will be landing in Bookworm in just a few days.  So at that point,
you'll be able to create VM images for Bookworm and Sid that will work
with the e2fsprogs in sid.  The current plan of record is that it will
only be at that point that e2fsprogs will be allowed to migrate into
Bookworm.

For slowly moving upstreams like grub2, distributions *have* to take
updates before grub2 finally gets around to doing a release --- to get
security fixes if nothing else!  The support for csum_seed has been in
Fedora and other distributions for a while, since the patches had
landed in grub2 in June 2021.  I probably should have made sure the
feature had landed in Debian's grub2 packaging earlier; that's my bad,
and my apologies for that.

Note that Debian's grub2 has well over 100 patches, nearly all of
which are backports from grub2's git repo.  So the argument that
"there doesn't exist a formally released grub2 release" isn't
particularly compelling, since all the distros are backporting
patches.  The only question is how *many* commits release has an
individual distribution taken.


By the way, in the case of the csum_seed feature, it's pretty
straightforward to just run "tune2fs -O ^metadata_csum_seed
/tmp/boot.img".  If the UUID has been changed since the file system
was created, you'll have to do this while the file system is unmounted
and it will take a few seconds, but that's almost certainly not the
case with vmdb2.

   - Ted

Bug#982099: lxpanel: randomly fails to display one of the configured launchers

[Francesco Poli]

On Sun, 9 May 2021 12:04:38 +0200 Francesco Poli wrote:

[...]
> Hello again,
> any news on bug [#982099]?
> 
> [#982099]: 
[...]

For anyone else who is experiencing this same bug, I seem to have found
a workaround: the trick is to create one separate Application Launch
Bar for each application launcher you need to define.

After applying this trick, each configured launcher seems to be always
displayed, without any issues...

The resulting panel configuration is something like:

  $ cat ~/.config/lxpanel/default/panels/panel 
  # lxpanel  config file. Manually editing is not recommended.
  # Use preference dialog in lxpanel to adjust config when you can.
  
  Global {
edge=bottom
allign=left
margin=275
widthtype=percent
width=100
height=28
transparent=1
tintcolor=#dcdad5
alpha=255
setdocktype=1
setpartialstrut=1
usefontcolor=1
fontcolor=#10394d
usefontsize=0
fontsize=10
background=0
backgroundfile=/usr/share/lxpanel/images/background.png
align=right
  }
  Plugin {
type=launchbar
Config {
  Button {
id=uxterm-start-login.desktop
  }
}
  }
  Plugin {
type=launchbar
Config {
  Button {
id=xscreensaver-lock-screen.desktop
  }
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=pager
Config {
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=taskbar
Config {
  ShowAllDesks=0
  MaxTaskWidth=150
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=tray
Config {
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=dclock
Config {
  ClockFmt=%R
  TooltipFmt=%a, %d %b %Y
  BoldFont=1
  IconOnly=0
  CenterText=1
}
  }
  Plugin {
type=space
Config {
  Size=5
}
  }


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpVjUI2yMSOZ.pgp
Description: PGP signature

Bug#557730: /etc/{protocols,network,services} not schroot's to scribble over

[Ian Jackson]

Wookey writes ("Re: Bug#557730: /etc/{protocols,network,services} not schroot's 
to scribble over"):
> On 2023-02-14 16:02 +, Ian Jackson wrote:
> > The fake netbase.deb could be contained within schroot.deb, in
> > /usr/share, so schroot wouldn't need to gain runtime build-deps on
> > dpkg tooling.
> 
> Except that it has to build this package live in order to contain the
> /etc/protocols and /etc/services files from the host
> environment. Having these default files with standard contents in a
> pre-built .deb is pointless, isn't it?

No, I thinko it's fine.  They mostly contain standardised constants.

schroot could build-depend on netbase and copy the files from there,
or just have fixed copies which would be updated manually once a
release or something.

These files, especially services, do change, but it is rare for
low-level basic things (or build systems) to actually depend on the
new entries.

> > > Whilst having the passwd database reflected in the chroot is
> > > incredibly useful it's not clear how often the services and protocols
> > > are needed, but I assume people do find that functionality useful.
> > 
> > I had a package that failed its build-time tests due to lack of
> > /etc/protocols.  The missing build-dep was detected in the buildds,
> > because my own local sid build chroot has netbase installed, precisely
> > because of this bug.
> 
> Right, which gets back to having a proper minimal environment used by
> sbuild to do a clean build. I have that (and it doesn't mount home,
> using the 'sbuild' profile). I use it once things are working
> reasonably well to get at least one clean build before uploading. This
> bug is a problem in the 'less clean, but more useful' 'default' chroot
> environment which is best for diagnostic work and builds of various
> sorts where some file persistence (of user files) is needed.

IME having a somewhat-dirty build environment is both convenient and
not a problem.

For example, my own sid chroot which *does* mount /home and import my
passwd and so on, reproducibily-builds the same .debs as the buildds
even for src:xen, whose build system is hardly straightforward.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#801065: Documenting how to not fail postinst on service fails to start

[Steve Langasek]

On Mon, Feb 13, 2023 at 09:03:34AM -0500, Marvin Renich wrote:
> * Steve Langasek  [230212 00:03]:
> > FWIW I think that it's the wrong thing to do if the "circumstances" include
> > reverse-dependencies on the package which expect to interact with the
> > service the package provides, as these packages may themselves do such
> > interaction in the maintainer script, resulting in cascading damage.

> > And the decision for whether there are reverse-dependencies on your package
> > is non-local and asynchronous.

> > Therefore I think it's always wrong for a package's postinst to exit 0 if:

> >  - it ships a service,
> >  - it is a new install or an upgrade on a system where the service was
> >previously started successfully, and
> >  - the service fails to start in the postinst.

> I have to strongly disagree with this.  Suppose package A ships a
> service, and package B depends on A and requires A's service to be
> running in order for package B to be useful.  If I install A and disable
> its service, and then install B, I would be very disappointed if B's
> postinst script failed and left B in what dpkg considers an unconfigured
> state.

> Succeeding the install and requiring the user to manually run some
> documented configuration steps is _so_ much more user friendly than
> leaving a broken package (from dpkg's POV).  I intentionally disabled A,
> so when I want to use B, I will take the necessary steps.  I would
> expect that attempting to use B without completing the configuration
> would produce a useful error message.

Up until now the conversation has been about the semantics of exit codes for
package A's maintainer script.

You are now arguing that a package *B* is not allowed to fail on install if
the conditions for its full configuration have not been met.

And I absolutely disagree!  Your rationale that it's user-unfriendly to
leave a package in an unconfigured state, if followed to its logical
conclusion, applies to *any* package.  We might as well not care about
postinst exit codes at all!

This is not hyperbolic.  By imposing restrictions on the ability of packages
to raise error conditions, you are forcing the propagation of erroneous
system state up the dependency stack, breaking untold numbers of assumptions
in the reverse-dependencies.  Keeping the error handling *local* and forcing
the admin to correct the error before proceeding is part of what makes
Debian's system robust.

On 'apt dist-upgrade', having a failing maintainer script can be problematic
wrt the package manager's full state.  But there is no such counterargument
wrt robustness for the simple case of an 'apt install foo' failing its
initial configuration because the system preconditions are not met.

> Package relationships and the idea of "properly configured" have gotten
> much more complex (in a relatively small set of packages) since early
> Debian days.  Packages whose configuration has complex requirements
> should be installable without complete configuration and should be
> resilient and provide good user feedback when run before being properly
> set up.

> I also think that such packages are the exception, rather than the rule,
> and they are usually being administered by people capable of dealing
> with postponing the configuration step.

They are also capable of dealing with 'apt -f install'.

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


signature.asc
Description: PGP signature

Bug#1031293: python3-zstandard 0.19.0-3 supports only libzstd 1.5.2

[Adrian Bunk]

Package: python3-zstandard
Version: 0.19.0-3
Severity: serious
Control: affects -1 src:libzstd src:rpmlint

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-zstandard/31313975/log.gz

...
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/zstandard/__init__.py", line 39, in 

from .backend_c import *  # type: ignore

ImportError: zstd C API versions mismatch; Python bindings were not 
compiled/linked against expected zstd version (10504 returned by the lib, 10502 
hardcoded in zstd headers, 10502 hardcoded in the cext)
...


Due to
https://sources.debian.org/src/python-zstandard/0.19.0-3/c-ext/backend_c.c/#L155

Please remove this version check, it is not supportable and does not
seem to be necessary in practice:
https://github.com/indygreg/python-zstandard/commit/964141349479070486ea25253bd4cc106929b2fc
https://github.com/indygreg/python-zstandard/commit/a1c567edd15cb735f1ae8b91fd994db2fe39f19b

Bug#1031294: doc-debian: misspelled "Control: forwarded"

[Jakub Wilk]

Package: doc-debian
Version: 6.5

bug-reporting.txt gives the following example:

Control: forward -1 https://bugs.debian.org/nnn

This should be "forwarded", not "forward".

It's been already fixed on the website: #863069

--
Jakub Wilk

Bug#1031295: pcp fails to install without systemd

[Adrian Bunk]

Package: pcp
Version: 6.0.2-1
Severity: serious

https://piuparts.debian.org/sid/fail/pcp_6.0.2-1.log

...
Setting up pcp (6.0.2-1) ...
  /var/lib/dpkg/info/pcp.postinst: 242: systemctl: not found
  dpkg: error processing package pcp (--configure):
   installed pcp package post-installation script subprocess returned error 
exit status 127
  Processing triggers for libc-bin (2.36-8) ...
  Errors were encountered while processing:
   pcp
  E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#1031296: sccache FTBFS (on non-i386 32bit?)

[Adrian Bunk]

Source: sccache
Version: 0.4.0~~pre7-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=sccache&ver=0.4.0%7E%7Epre7-1

...
[io-lifetimes 0.7.2] error[E0554]: `#![feature]` may not be used on the stable 
release channel
[io-lifetimes 0.7.2]  --> :1:1
[io-lifetimes 0.7.2]   |
[io-lifetimes 0.7.2] 1 | #![feature(rustc_attrs)]
[io-lifetimes 0.7.2]   | 
[io-lifetimes 0.7.2] 
[io-lifetimes 0.7.2] error: aborting due to previous error
[io-lifetimes 0.7.2] 
[io-lifetimes 0.7.2] For more information about this error, try `rustc 
--explain E0554`.
...

Bug#1031120: does not reset hyperlinks with -R

[Marco d'Itri]

On Feb 12, Marco d'Itri  wrote:

> Package: less
> Version: 590-1.1
> Severity: normal
> 
> When using less -R it does not correctly reset the hyperlink escape 
> sequences (i.e. "ESC]8;;"), causing the hyperlink to be extended to the 
> following terminal output.

While this looks quite similar to the issue described in #1030825, of
which I was not aware when I filed this bug, it is not fixed in less
590-1.2.
Does this issue too have security implications?

> This can be partially reproduced with something like:
> 
> printf 
> "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\e]8;;file://localhost/usr/share/initramfs-tools/scripts/init-top/udev\a/usr/share/initramfs-tools/scripts/init-top/udev
>  we need a longer line... 
> /usr/share/initramfs-tools/scripts/init-top/udev\e]8;;\a\n\n\n\n\n\n\n\n" | 
> less -RS
> 
> in gnome-terminal.
> 
> In this case the link will affect only the less interface, but when 
> using bootctl I can reliably make the link stay open even after quitting 
> less.
> 
> Using -S is not a requirement to reproduce this, it just makes it 
> easier: the bug is also triggered by quitting less when the first line 
> of a multiline link is the bottom line in the screen.
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages less depends on:
> ii  libc6  2.36-8
> ii  libtinfo6  6.4-2
> 
> less recommends no packages.
> 
> less suggests no packages.
> 
> -- no debconf information
> 
> -- 
> ciao,
> Marco



-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1018023: Update on this bug?

[Jose Antonio Jimenez Madrid]

Thanks Matthew for the links.

I will test this patch and let you to know whether the bug is fixed.

Sincerely,
Jose

Matthew Vernon wrote:
> Hi,
>
> Do you have plans to fix this before the bookworm freeze, please?
>
> I think netbsd at least have patched eterm to work with the newer
> imlib; at least per the comment here
> https://github.com/mej/Eterm/issues/4
>
> That linked to
> http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/x11/eterm/patches/
>
> Which has a couple of patches that seem like they'd do the trick...
>
> Thanks,
>
> Matthew

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

[Daniel Leidert]

Am Dienstag, dem 14.02.2023 um 12:34 -0500 schrieb Theodore Ts'o:
> 
[..]
> In any case, a version of grub that will support the csum_seed feature
> will be landing in Bookworm in just a few days.  So at that point,
> you'll be able to create VM images for Bookworm and Sid that will work
> with the e2fsprogs in sid.  The current plan of record is that it will
> only be at that point that e2fsprogs will be allowed to migrate into
> Bookworm.

As soon as this version hits testing, you have successfully disabled
the last working environment to use vmdb2 to create images of Ubuntu
and Debian. As soon as this version hits Testing, one then can no
longer build images for either any Ubuntu release nor Debian Bullseye
or older. I can then only build images for Bookworm and Sid. Please
think about that.

You *seriously* break the debootstrap method of installing Debian or
Ubuntu. vmdb2 ist just another tool that is broken by now, a tool that
I use very often. I explained the impacts of what you are doing often
enough now. By now the impact should be clear. And you are still not
dealing with the aftermath of your intended action?! You haven't done a
proper transition. You haven't given any affected toolchain the
necessary time to adopt. You haven't documented how to disable that
breaking change when creating filesystems for distributions where grub
does not support this (there is not even a NEWS entry). You haven't
even announced that breaking change. And yet you are going to break one
of our two standard methods of installing Debian or Ubuntu. How is any
of what you have been saying so far addressing any of these issues? 

> [..]
> By the way, in the case of the csum_seed feature, it's pretty
> straightforward to just run "tune2fs -O ^metadata_csum_seed
> /tmp/boot.img".  If the UUID has been changed since the file system
> was created, you'll have to do this while the file system is
> unmounted
> and it will take a few seconds, but that's almost certainly not the
> case with vmdb2.

Well, how do you intend to distribute that information, so people who
have to use the deboostrap method to install a Debian or Ubuntu release
with a grub not supporting csum_seed (basically all existing releases,
except for the upcoming Bookworm) know that?

I do not understand why you are pushing 1.47.0 over 1.46.6, which you
had uploaded just five days before the former. You haven't even
presented a reason yet.

Regards, Daniel

Bug#1031297: diffoscope: autopkgtest regression due to unavailable Recommends on several architectures

[Adrian Bunk]

Source: diffoscope
Version: 235
Severity: serious

Issues preventing migration:
∙ ∙ autopkgtest for diffoscope/235: amd64: Pass, arm64: Pass, armel: Regression 
♻ (reference ♻), armhf: Pass, i386: Pass, ppc64el: Regression ♻ (reference ♻), 
s390x: Regression ♻ (reference ♻)


pytest-with-recommends FAIL badpkg
blame: diffoscope
badpkg: Test dependencies are unsatisfiable. A common reason is that your 
testbed is out of date with respect to the archive, and you need to use a 
current testbed or run apt-get update or use -U.




aapt   | 1:10.0.0+r36-10 | unstable| amd64, arm64, armel, 
armhf, i386, mips64el, mipsel
dexdump| 11.0.0+r48-5  | unstable | amd64, arm64, armhf, i386

Bug#1017921: mpd tries to start on non-interactive sessions

[Antoine Beaupré]

On 2023-02-14 18:27:02, kal...@debian.org wrote:

[...]

> I suggest to close this bug.
> Would it be fine with you ?

As you wish, of course. :)

Bug#1031298: ITP: pyproject-api -- API to interact with Python pyproject.toml-based projects

[Faidon Liambotis]

Package: wnpp
Severity: wishlist
Owner: Faidon Liambotis 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: pyproject-api
  Version : 1.5.0
  Upstream Author : Bernát Gábor 
* URL : https://github.com/tox-dev/pyproject-api
* License : Expat
  Programming Lang: Python
  Description : API to interact with Python pyproject.toml-based projects

  pyproject-api aims to abstract away interaction with pyproject.toml
  style projects in a flexible way.

pyproject-api is a new dependency of tox, in the 4.x series, currently
slated for experimental. I intend to maintain this package as part of
the DPT.

The package is trivial, but if anyone is interested in helping maintain
it, or with tox's maintenance, you're more than welcome!

Bug#1031299: r-cran-ggalluvial: autopkgtest regression

[Adrian Bunk]

Source: r-cran-ggalluvial
Version: 0.12.4-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-ggalluvial/31321147/log.gz

...
══ Failed tests 
── Error ('test-stat-flow.r:10'): `stat_flow` weights computed variables but 
drops weight ──
Error in `summarise(.tbl, !!!funs)`: Problem while computing `lode = (function 
(x, order_by = NULL, default =
NULL, na_rm = FALSE) ...`.
ℹ The error occurred in group 1: alluvium = 1, x = 1, yneg = FALSE, stratum =
  "B", deposit = 1, fissure = 1, link = 1, flow = from, adj_deposit = 1.1.3,
  adj_fissure = 1.1.1.
Caused by error in `nth()`:
! unused argument (na_rm = na_rm)
Backtrace:
 ▆
  1. ├─base::as.data.frame(StatFlow$compute_panel(data)) at 
test-stat-flow.r:10:2
  2. ├─StatFlow$compute_panel(data)
  3. │ └─ggalluvial (local) compute_panel(..., self = self)
  4. │   └─dplyr::summarize_at(data, "lode", distill)
  5. │ ├─dplyr::summarise(.tbl, !!!funs)
  6. │ └─dplyr:::summarise.grouped_df(.tbl, !!!funs)
  7. │   └─dplyr:::summarise_cols(.data, dplyr_quosures(...), caller_env = 
caller_env())
  8. │ ├─base::withCallingHandlers(...)
  9. │ └─dplyr:::map(quosures, summarise_eval_one, mask = mask)
 10. │   └─base::lapply(.x, .f, ...)
 11. │ └─dplyr (local) FUN(X[[i]], ...)
 12. │   └─mask$eval_all_summarise(quo)
 13. ├─dplyr (local) ``(lode)
 14. └─base::.handleSimpleError(...)
 15.   └─dplyr (local) h(simpleError(msg, call))
 16. └─rlang::abort(bullets, call = error_call, parent = 
skip_internal_condition(e))
── Error ('test-stat-flow.r:28'): `stat_flow` orders flows correctly with 
negative values ──
Error in `summarise(.tbl, !!!funs)`: Problem while computing `lode = (function 
(x, order_by = NULL, default =
NULL, na_rm = FALSE) ...`.
ℹ The error occurred in group 1: alluvium = 1, x = 1, yneg = FALSE, stratum =
  "A", deposit = 2, fissure = 1, link = 1, flow = from, adj_deposit = 1.2.3,
  adj_fissure = 1.1.1.
Caused by error in `nth()`:
! unused argument (na_rm = na_rm)
Backtrace:
 ▆
  1. ├─StatFlow$compute_panel(data) at test-stat-flow.r:28:2
  2. │ └─ggalluvial (local) compute_panel(..., self = self)
  3. │   └─dplyr::summarize_at(data, "lode", distill)
  4. │ ├─dplyr::summarise(.tbl, !!!funs)
  5. │ └─dplyr:::summarise.grouped_df(.tbl, !!!funs)
  6. │   └─dplyr:::summarise_cols(.data, dplyr_quosures(...), caller_env = 
caller_env())
  7. │ ├─base::withCallingHandlers(...)
  8. │ └─dplyr:::map(quosures, summarise_eval_one, mask = mask)
  9. │   └─base::lapply(.x, .f, ...)
 10. │ └─dplyr (local) FUN(X[[i]], ...)
 11. │   └─mask$eval_all_summarise(quo)
 12. ├─dplyr (local) ``(lode)
 13. └─base::.handleSimpleError(...)
 14.   └─dplyr (local) h(simpleError(msg, call))
 15. └─rlang::abort(bullets, call = error_call, parent = 
skip_internal_condition(e))
── Error ('test-stat-flow.r:56'): `stat_flow` orders alluvia correctly 
according to `aes.bind` ──
Error in `summarise(.tbl, !!!funs)`: Problem while computing `lode = (function 
(x, order_by = NULL, default =
NULL, na_rm = FALSE) ...`.
ℹ The error occurred in group 1: alluvium = 1, x = 1, yneg = FALSE, stratum =
  "A", deposit = 2, fissure = -2, link = 1, flow = from, adj_deposit = 1.2.4,
  adj_fissure = 1.-2.-2.
Caused by error in `nth()`:
! unused argument (na_rm = na_rm)
Backtrace:
 ▆
  1. ├─StatFlow$compute_panel(data) at test-stat-flow.r:56:2
  2. │ └─ggalluvial (local) compute_panel(..., self = self)
  3. │   └─dplyr::summarize_at(data, "lode", distill)
  4. │ ├─dplyr::summarise(.tbl, !!!funs)
  5. │ └─dplyr:::summarise.grouped_df(.tbl, !!!funs)
  6. │   └─dplyr:::summarise_cols(.data, dplyr_quosures(...), caller_env = 
caller_env())
  7. │ ├─base::withCallingHandlers(...)
  8. │ └─dplyr:::map(quosures, summarise_eval_one, mask = mask)
  9. │   └─base::lapply(.x, .f, ...)
 10. │ └─dplyr (local) FUN(X[[i]], ...)
 11. │   └─mask$eval_all_summarise(quo)
 12. ├─dplyr (local) ``(lode)
 13. └─base::.handleSimpleError(...)
 14.   └─dplyr (local) h(simpleError(msg, call))
 15. └─rlang::abort(bullets, call = error_call, parent = 
skip_internal_condition(e))
── Error ('test-stat-flow.r:78'): `stat_flow` preserves missingness to position 
flows ──
Error in `summarise(.tbl, !!!funs)`: Problem while computing `lode = (function 
(x, order_by = NULL, default =
NULL, na_rm = FALSE) ...`.
ℹ The error occurred in group 1: alluvium = 1, x = 1, yneg = FALSE, stratum =
  A, deposit = 1, fissure = 1, link = 1, flow = from, adj_deposit = 1.1.3,
  adj_fissure = 1.1.1.
Caused by error in `nth()`:
! unused argument (na_rm = na_rm)
Backtrace:
 ▆
  1. ├─StatFlow$compute_panel(data) at test-stat-flow.r:78:2
  2. │ └─ggalluvial (local) compute_panel(..., self = self)
  3. │   └─dplyr::summarize_at(data, "lode", distill)
  4. │ ├─dplyr::summaris

Bug#1031300: ITP: sphinx-argparse-cli -- Sphinx extension to render CLI arguments defined by the argparse module

[Faidon Liambotis]

Package: wnpp
Severity: wishlist
Owner: Faidon Liambotis 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: sphinx-argparse-cli
  Version : 1.11.0
  Upstream Author : Bernát Gábor 
* URL : https://github.com/tox-dev/sphinx-argparse-cli/
* License : Expat
  Programming Lang: Python
  Description : Sphinx extension to render CLI arguments defined by the 
argparse module

 sphinx-argparse-cli is an extension for Sphinx to render documentation for
 command-line interface (CLI) arguments defined by the argparse module.
 .
 Unlike the sphinx-argparse module, this module is more capable with regards to
 CLI interfaces that utilize sub-commands. A notable example is the "tox"
 project, from which this module originates.

The package is trivial, but if anyone is interested in helping maintain
it, or with tox's maintenance, you're more than welcome!