Bug#993705: freeorion: 'PythonAI failed to initialize' when starting singleplayer game with AI

[joyfulmange]

Package: freeorion
Version: 0.4.10.2-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   In the unstable version, starting a game with AI fails to allow a
   game to start.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I attempted recompiling the game and researching the bug to see if
 I was missing a dependency, however this resulted in nothing
 worthwhile occouring.
   * What was the outcome of this action?
   'PythonAI failed to initialize' in console and "The connection to the
   server has been lost" as an error from the game
   * What outcome did you expect instead?
   I expected a game to start with AI enabled



-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera)
Release:4
Codename:   n/a
Architecture: x86_64

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages freeorion depends on:
ii  freeorion-data  0.4.10.2-1
ii  libboost-filesystem1.74.0   1.74.0-9
ii  libboost-iostreams1.74.0    1.74.0-9
ii  libboost-locale1.74.0   1.74.0-9
ii  libboost-log1.74.0  1.74.0-9
ii  libboost-python1.74.0 [libboost-python1.74.0-py39]  1.74.0-9
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]   1.74.0-9
ii  libboost-serialization1.74.0    1.74.0-9
ii  libboost-thread1.74.0   1.74.0-9
ii  libc6   2.31-17
ii  libfreetype6    2.10.4+dfsg-1
ii  libgcc-s1   11.2.0-4
ii  libgl1  1.3.4-1
ii  libglew2.1  2.1.0-4+b1
ii  libopenal1  1:1.19.1-2
ii  libpng16-16 1.6.37-3
ii  libpython3.9    3.9.7-2
ii  libsdl2-2.0-0   2.0.14+dfsg2-3
ii  libstdc++6  11.2.0-4
ii  libvorbis0a 1.3.7-1
ii  libvorbisfile3  1.3.7-1

freeorion recommends no packages.

freeorion suggests no packages.

-- no debconf information

Bug#976133: marked as pending in glibc

[Josh Triplett]

On Sat, Sep 04, 2021 at 07:56:12PM +, Aurelien Jarno wrote:
> Hello,
> 
> Bug #976133 in glibc reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/glibc-team/glibc/-/commit/331bb702600840c345d804fe689e0d402dc5ad05
> 
> 
> debian/debhelper.in/libc-dev.install, debian/debhelper.in/libc.install, 
> debian/control.in/libc: move sotruss-lib.so from libc6 to libc6-dev. Closes: 
> #976133.
> 

Thank you!

- Josh

Bug#993707: FTBFS on arm64

[Daniel Baumann]

Package: linux
Version: 5.14-1~exp1
Severity: serious

Hi,

after applying the perf fixes, it builds for me on amd64, i386, armel, 
and armhf, but fails on arm64:


---snip---
dh_prep
kernel-wedge install-files 5.14.0-trunk
install -D -m 644 
debian/linux-image-5.14.0-trunk-arm64/boot/vmlinuz-5.14.0-trunk-arm64 
debian/kernel-image-5.14.0-trunk-arm64-di/boot/vmlinuz
install -d 
debian/kernel-image-5.14.0-trunk-arm64-di/lib/modules/5.14.0-trunk-arm64
install -m 644 
debian/linux-image-5.14.0-trunk-arm64/lib/modules/5.14.0-trunk-arm64/modules.builtin 
debian/linux-image-5.14.0-trunk-arm64/lib/modules/5.14.0-trunk-arm64/modules.order 
debian/kernel-image-5.14.0-trunk-arm64-di/lib/modules/5.14.0-trunk-arm64/
install -D -m 644 
debian/linux-image-5.14.0-trunk-arm64/boot/System.map-5.14.0-trunk-arm64 
debian/kernel-image-5.14.0-trunk-arm64-di/boot/System.map

install -d debian/kernel-image-5.14.0-trunk-arm64-di/usr/lib
cp -a 
debian/linux-image-5.14.0-trunk-arm64/usr/lib/linux-image-5.14.0-trunk-arm64 
debian/kernel-image-5.14.0-trunk-arm64-di/usr/lib/linux-image-5.14.0-trunk-arm64
kernel-wedge copy-moduleven after applying the perf fixes, es 
5.14.0-trunk arm64 5.14.0-trunk-arm64

kernel-wedge find-dups 5.14.0-trunk-arm64
debian/nic-usb-modules-5.14.0-trunk-arm64-di 
lib/modules/5.14.0-trunk-arm64/kernel/net/core/selftests.ko
debian/nic-modules-5.14.0-trunk-arm64-di 
lib/modules/5.14.0-trunk-arm64/kernel/net/core/selftests.ko

some modules are in more than one package
command exited with status 1
make[2]: *** [debian/rules.real:570: install-udeb_arm64] Error 2
make[2]: Leaving directory '/build/linux-5.14-1~exp1'
make[1]: *** [debian/rules.gen:35: binary-arch_arm64] Error 2
make[1]: Leaving directory '/build/linux-5.14-1~exp1'
make: *** [debian/rules:43: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned 
exit status 2

---snap---

Regards,
Daniel

Bug#992243: buster-pu: package psmisc/23.2-1+deb10u1

[Craig Small]

Thanks for looking after this Raphael! This will stop a lot a bug reports
about why does the process not get found.

 - Craig


On Sun, 5 Sep 2021, 01:01 Raphael Hertzog,  wrote:

> Hello,
>
> On Sat, 04 Sep 2021, Adam D. Barratt wrote:
> > On Mon, 2021-08-16 at 12:02 +0200, Raphael Hertzog wrote:
> > > I would like to update "psmisc" in buster to fix a regression in
> > > "killall". The bug https://bugs.debian.org/912748 was never fixed in
> > > that release and "killall command-longer-than-15-char" is thus not
> > > working at all in buster
> >
> > Please go ahead.
>
> Thanks, uploaded.
>
> Cheers,
> --
> Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
> https://www.freexian.com
>

Bug#993706: ITP: golang-go.cypherpunks-recfile -- Pure Go implementation of GNU recutils/recfile databases

[jgoerzen]

Package: wnpp
Severity: wishlist
Owner: jgoerzen 

* Package name: golang-go.cypherpunks-recfile
  Version : 0.4.3-1
  Upstream Author : Sergey Matveev 
* URL : http://www.git.cypherpunks.ru/?p=gorecfile.git;a=summary
* License : GPL3
  Programming Lang: Go
  Description : Pure Go implementation of GNU recutils/recfile databases
 GNU recutils (see package recutils) databases are human-editable,
 text-based databases called recfiles.  This package provides a Go interface
 to working with recfiles.

Required for packaging NNCP

Bug#993704: ITP: balloon -- Balloon password hashing

[jgoerzen]

Package: wnpp
Severity: wishlist
Owner: jgoerzen 

* Package name: balloon
  Version : 1.1.1-1
  Upstream Author : Sergey Matveev 
* URL : http://www.git.cypherpunks.ru/?p=balloon.git;a=summary
* License : LGPL3
  Programming Lang: Go
  Description : Balloon password hashing in pure Go
 This is a pure Go implementation of Balloon password hashing.
 See https://crypto.stanford.edu/balloon/ for a description of
 balloon hashing.
 .
 This package provides both a Go library and a CLI too.

This package is required to package NNCP.

Bug#993703: dh-make-golang: make crashes with certain unknown publishers

[John Goerzen]

Package: dh-make-golang
Version: 0.5.0-1
Severity: important

I am attempting to package up NNCP, and for that I need a 
go.cypherpunks.ru/balloon .

Running dh-make-golang make -type library -allow_unknown_hoster 
go.cypherpunks.ru/balloon , I see:

2021/09/05 01:16:27 Running "git fetch go.cypherpunks"
remote: Enumerating objects: 95, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 95 (delta 0), reused 3 (delta 0), pack-reused 92
Unpacking objects: 100% (95/95), 27.75 KiB | 163.00 KiB/s, done.
>From https://git.cypherpunks.ru/balloon
 * [new branch]  master -> go.cypherpunks/master
 * [new tag] v1.0.0 -> v1.0.0
 * [new tag] v1.1.0 -> v1.1.0
 * [new tag] v1.1.1 -> v1.1.1
tar: This does not look like a tar archive

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
gbp:error: Couldn't unpack 
'/home/jgoerzen/work/nncp-debian/golang-lukechampine-blake3/golang-go.cypherpunks-balloon_1.1.1.orig.tar.gz':
 it exited with 2
2021/09/05 01:16:28 Could not create git repository: import-orig: exit status 1

And indeed, there's a reason it couldn't unpack that:

-rw-r--r-- 1 jgoerzen jgoerzen 0 Sep  5 01:16 
golang-go.cypherpunks-balloon_1.1.1.orig.tar.gz

Looking in the code, the hoster isn't going to have a tarball.  But in make.go, 
there's this:

if u.isRelease {
if !u.hasGodeps { // No need to repack; fetch pristine tarball
u.compression = "gz"
if err := u.tarballFromHoster(); err != nil {
if err.Error() == "unsupported hoster" {
log.Printf("INFO: Hoster does not 
provide release tarball\n")
} else {
return fmt.Errorf("tarball from hoster: 
%w", err)
}
}
return nil

Basically it returns in the same way whether or not tarballFromHoster worked.

If I remove that "return nil", it works for this case (though of course may be 
broken for others).

If you wish to test with this package, you will need the CA certificate from 
http://www.ca.cypherpunks.ru/ installed per the instructions in 
/usr/share/doc/ca-certificates.

Thanks,

John


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

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

Versions of packages dh-make-golang depends on:
ii  git   1:2.30.2-1
ii  git-buildpackage  0.9.22
ii  golang-any2:1.15~1
ii  libc6 2.31-13
ii  pristine-tar  1.49

Versions of packages dh-make-golang recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  golang-golang-x-tools  1:0.1.0+ds-1+b5

dh-make-golang suggests no packages.

-- no debconf information

Bug#993702: transition: soapysdr

[Andreas Bombe]

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

Hi release team,

I request a transition slot for libsoapysdr that changed its ABI
version. This also includes all soapysdr driver modules that are also
versioned and will transition together. soapysdr and all module
providing packages are in experimental.

The auto-soapysdr tracker looks right, the other auto-soapy* and
auto-limesuite transitions can be ignored as these are from the
versioned modules packages.

Test building of dependency level 2 packages showed that soapysdr
changed one function signature and hacktv, libxtrx and srslte fail to
build as a result. Bugs have been filed and the fixes should be trivial,
for two upstream already has them. The other packages build fine.

Ben file generated by reportbug, but probably not needed since
auto-soapysdr is fine:

title = "soapysdr";
is_affected = .depends ~ "libsoapysdr0.7" | .depends ~ "libsoapysdr0.8";
is_good = .depends ~ "libsoapysdr0.8";
is_bad = .depends ~ "libsoapysdr0.7";


Thanks.

Bug#993694: missing Depends: python3-jinja2

[Drew Parsons]

On 2021-09-04 23:45, Diane Trout wrote:

Hmm...

So dask doesn't think jinja is required for base functionality. It's a
dependency for an extended extras.


OK, thanks for checking it.

...

At dask's end jinja should probably be a suggests or recommends, but
since you can use dask without needing widgets I'm not 100% sure jinja
needs to build-dependency.


That sounds reasonable. dask should be consistent with itself, so if it 
doesn't Depend on jinja2, if it's only for extra functionality, then 
Suggests or Recommends is more appropriate than Depends.  I had been 
assuming dask.widgets was a core component.


In that case we could move this bug to python-xarray. If xarray wants to 
access optional functionality then it will need to make sure the 
required packages are installed.



(Do widgets even work on Debian? Last time I tried jupyter widgets I
couldn't get them to work.)


Good question :)

jupyter-sphinx has just been updated, presumably fixing a problem with 
ipywidgets (#950598 vs #896460). Perhaps that's related to jupyter 
widget operations.

Bug#976697: webext-umatrix: no longer developed upstream, remove or switch to LibreMatrix or?

[Paul Wise]

On Sat, 2021-09-04 at 17:08 +0200, Axel Beckert wrote:

> Also it is unclear to me why the source is the Mozilla XPI while the
> package works with both and upstream offers different download files
> for Firefox and for Chromium/Chrome. (Then again, I haven't worked on
> browser extensions since Mozilla ditched XUL…)

I tried updating webext-umatrix to the latest release and immediately
encountered this issue too as the build fails with the upstream source
instead of the upstream prebuilt XPI file. I think that using prebuilt
XPI files when the upstream project has a git repository has a risk of
DFSG item 2 violations. Debian using XPI files is one of the reasons I
started this discussion about not using upstream packaging ecosystems:

   Debian choice of upstream tarballs for packaging
   
https://lists.debian.org/msgid-search/937697e40caf519e18119635db07d7b74b37b980.ca...@debian.org

That said, I expect building WebExtensions from source properly is
going to be a large undertaking that will require lots of node-*
packages and other dependencies to be added to Debian.

So a reasonable way to start is probably to update to the latest XPI
and then start working on the dependencies etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#993701: srslte: FTBFS with libsoapysdr 0.8

[Andreas Bombe]

Source: srslte
Version: 18.06.1+ds.1
Severity: important
Tags: ftbfs

I am building rdeps of libsoapysdr in preparation of the transition to
version 0.8. This version has changed the SoapySDRDevice_setupStream()
function signature to return the SoapySDRStream directly rather than
through a pointer:

*   Recommended keys to use in the args dictionary:
*- "WIRE" - format of the samples between device and host
* \endparblock
  - * \return 0 for success or error code on failure
  + * \return the stream pointer or nullptr for failure
*/
  -SOAPY_SDR_API int SoapySDRDevice_setupStream(SoapySDRDevice *device,
  -SoapySDRStream **stream,
  +SOAPY_SDR_API SoapySDRStream *SoapySDRDevice_setupStream(SoapySDRDevice 
*device,
   const int direction,
   const char *format,
   const size_t *channels,

This change causes a build failure in srslte when building against the
new libsoapysdr. I can see upstream has already fixed that in their
sources. Log of the failed build:

/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c: In function 
'rf_soapy_open_multi':
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:344:52: warning: 
passing argument 2 of 'SoapySDRDevice_setupStream' makes integer from pointer 
without a cast [-Wint-conversion]
  344 | if(SoapySDRDevice_setupStream(handler->device, 
&(handler->rxStream), SOAPY_SDR_RX, SOAPY_SDR_CF32, NULL, 0, NULL) != 0) {
  |^~~~
  ||
  |SoapySDRStream **
In file included from 
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:37:
/usr/include/SoapySDR/Device.h:307:15: note: expected 'int' but argument is of 
type 'SoapySDRStream **'
  307 | const int direction,
  | ~~^
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:344:74: warning: 
passing argument 3 of 'SoapySDRDevice_setupStream' makes pointer from integer 
without a cast [-Wint-conversion]
  344 | if(SoapySDRDevice_setupStream(handler->device, 
&(handler->rxStream), SOAPY_SDR_RX, SOAPY_SDR_CF32, NULL, 0, NULL) != 0) {
  | 
 ^~~~
  | 
 |
  | 
 int
In file included from 
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:37:
/usr/include/SoapySDR/Device.h:308:17: note: expected 'const char *' but 
argument is of type 'int'
  308 | const char *format,
  | ^~
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:344:88: error: passing 
argument 4 of 'SoapySDRDevice_setupStream' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  344 | if(SoapySDRDevice_setupStream(handler->device, 
&(handler->rxStream), SOAPY_SDR_RX, SOAPY_SDR_CF32, NULL, 0, NULL) != 0) {
  | 
   ^~
  | 
   |
  | 
   char *
In file included from 
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:37:
/usr/include/SoapySDR/Device.h:309:19: note: expected 'const size_t *' {aka 
'const long unsigned int *'} but argument is of type 'char *'
  309 | const size_t *channels,
  | ~~^~~~
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:344:104: warning: 
passing argument 5 of 'SoapySDRDevice_setupStream' makes integer from pointer 
without a cast [-Wint-conversion]
  344 | if(SoapySDRDevice_setupStream(handler->device, 
&(handler->rxStream), SOAPY_SDR_RX, SOAPY_SDR_CF32, NULL, 0, NULL) != 0) {
  | 
   ^~~~
  | 
   |
  | 
   void *
In file included from 
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:37:
/usr/include/SoapySDR/Device.h:310:18: note: expected 'size_t' {aka 'const long 
unsigned int'} but argument is of type 'void *'
  310 | const size_t numChans,
  | ~^~~~
/build/srslte-18.06.1+ds.1/lib/src/phy/rf/rf_soapy_imp.c:344:8: error: too many 
arguments to function 'SoapySDRDevice_setupStream'
  344 | if(SoapySDRDevice_setupStream(handler->device, 
&(handler->rxStream), SOAPY_SDR_RX, SOAPY_SDR_CF32, NULL, 0, NULL) != 0) {
  |^~
In file included from 

Bug#993700: what equivalent for which -a?

[peter]

Package: debianutils
Version: 5.4-3

Now that which is going, what's the equivalent command for 'which -a'
???
'command -v' doesn't show all instances of a command in $PATH.

As a sysadmin, it's one of the first things I ask someone to do when
helping them, to make sure that the system version of a command (they
say isn't working) is installed, and that their PATH uses it.

I know I can do:

OIFS="$IFS"
IFS=:
for x in $PATH
do
  [ -e "$x/$cmd" ] && echo "$x/$cmd"
done
IFS="$OIFS"

(suitably extended to ensure correct exit status) but that's a lot
harder to get someone to type in over the phone than to ask them to
type 'which -a cmd'


Peter C

Bug#993699: libxtrx: FTBFS with libsoapysdr 0.8

[Andreas Bombe]

Source: libxtrx
Version: 0.0.1+git20191219.98458ce-1
Severity: important
Tags: ftbfs upstream


I am building rdeps of libsoapysdr in preparation of the transition to
version 0.8. This version has changed the SoapySDRDevice_setupStream()
function signature to return the SoapySDRStream directly rather than
through a pointer:

*   Recommended keys to use in the args dictionary:
*- "WIRE" - format of the samples between device and host
* \endparblock
  - * \return 0 for success or error code on failure
  + * \return the stream pointer or nullptr for failure
*/
  -SOAPY_SDR_API int SoapySDRDevice_setupStream(SoapySDRDevice *device,
  -SoapySDRStream **stream,
  +SOAPY_SDR_API SoapySDRStream *SoapySDRDevice_setupStream(SoapySDRDevice 
*device,
   const int direction,
   const char *format,
   const size_t *channels,

This causes a build failure in libxtrx when building against the new
libsoapysdr. Upstream appears to have switched to the new call signature
in their current code, dropping compatibility with libsoapysdr 0.7 at
the same time. A way to be compatible with both would be using
preprocessor directives to discriminate between API version using
SOAPY_SDR_API_VERSION.

Log of the failed build:

/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c: In function 
'main':
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:70:41: 
warning: passing argument 2 of 'SoapySDRDevice_setupStream' makes integer from 
pointer without a cast [-Wint-conversion]
   70 | if (SoapySDRDevice_setupStream(sdr, , SOAPY_SDR_RX, 
SOAPY_SDR_CF32, NULL, 0, NULL) != 0)
  | ^
  | |
  | SoapySDRStream **
In file included from 
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:1:
/usr/include/SoapySDR/Device.h:307:15: note: expected 'int' but argument is of 
type 'SoapySDRStream **'
  307 | const int direction,
  | ~~^
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:70:52: 
warning: passing argument 3 of 'SoapySDRDevice_setupStream' makes pointer from 
integer without a cast [-Wint-conversion]
   70 | if (SoapySDRDevice_setupStream(sdr, , SOAPY_SDR_RX, 
SOAPY_SDR_CF32, NULL, 0, NULL) != 0)
  |^~~~
  ||
  |int
In file included from 
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:1:
/usr/include/SoapySDR/Device.h:308:17: note: expected 'const char *' but 
argument is of type 'int'
  308 | const char *format,
  | ^~
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:70:66: 
warning: passing argument 4 of 'SoapySDRDevice_setupStream' from incompatible 
pointer type [-Wincompatible-pointer-types]
   70 | if (SoapySDRDevice_setupStream(sdr, , SOAPY_SDR_RX, 
SOAPY_SDR_CF32, NULL, 0, NULL) != 0)
  |  
^~
  |  |
  |  char *
In file included from 
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:1:
/usr/include/SoapySDR/Device.h:309:19: note: expected 'const size_t *' {aka 
'const long unsigned int *'} but argument is of type 'char *'
  309 | const size_t *channels,
  | ~~^~~~
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:70:82: 
warning: passing argument 5 of 'SoapySDRDevice_setupStream' makes integer from 
pointer without a cast [-Wint-conversion]
   70 | if (SoapySDRDevice_setupStream(sdr, , SOAPY_SDR_RX, 
SOAPY_SDR_CF32, NULL, 0, NULL) != 0)
  | 
 ^~~~
  | 
 |
  | 
 void *
In file included from 
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:1:
/usr/include/SoapySDR/Device.h:310:18: note: expected 'size_t' {aka 'const long 
unsigned int'} but argument is of type 'void *'
  310 | const size_t numChans,
  | ~^~~~
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:70:9: error: 
too many arguments to function 'SoapySDRDevice_setupStream'
   70 | if (SoapySDRDevice_setupStream(sdr, , SOAPY_SDR_RX, 
SOAPY_SDR_CF32, NULL, 0, NULL) != 0)
  | ^~
In file included from 
/build/libxtrx-0.0.1+git20191219.98458ce/soapy/test_xtrx_soapy.c:1:
/usr/include/SoapySDR/Device.h:306:31: note: declared here
  306 | SOAPY_SDR_API 

Bug#993698: hacktv: FTBFS with libsoapysdr 0.8

[Andreas Bombe]

Source: hacktv
Version: 0+git20201203-1
Severity: important
Tags: ftbfs upstream upstream

I am building rdeps of libsoapysdr in preparation of the transition to
version 0.8. This version has changed the SoapySDRDevice_setupStream()
function signature to return the SoapySDRStream directly rather than
through a pointer:

*   Recommended keys to use in the args dictionary:
*- "WIRE" - format of the samples between device and host
* \endparblock
  - * \return 0 for success or error code on failure
  + * \return the stream pointer or nullptr for failure
*/
  -SOAPY_SDR_API int SoapySDRDevice_setupStream(SoapySDRDevice *device,
  -SoapySDRStream **stream,
  +SOAPY_SDR_API SoapySDRStream *SoapySDRDevice_setupStream(SoapySDRDevice 
*device,
   const int direction,
   const char *format,
   const size_t *channels,

This causes a build failure in hacktv when building against the new
libsoapysdr. Upstream does not appear to have a fix yet, one way would
be using preprocessor directives to discriminate between API version
using SOAPY_SDR_API_VERSION.

Log of the failed build:

soapysdr.c: In function 'rf_soapysdr_open':
soapysdr.c:135:39: warning: passing argument 2 of 'SoapySDRDevice_setupStream' 
makes integer from pointer without a cast [-Wint-conversion]
  135 |  if(SoapySDRDevice_setupStream(rf->d, >s, SOAPY_SDR_TX, 
SOAPY_SDR_CS16, NULL, 0, NULL) != 0)
  |   ^~
  |   |
  |   SoapySDRStream **
In file included from soapysdr.c:20:
/usr/include/SoapySDR/Device.h:307:15: note: expected 'int' but argument is of 
type 'SoapySDRStream **'
  307 | const int direction,
  | ~~^
soapysdr.c:135:61: warning: passing argument 4 of 'SoapySDRDevice_setupStream' 
from incompatible pointer type [-Wincompatible-pointer-types]
  135 |  if(SoapySDRDevice_setupStream(rf->d, >s, SOAPY_SDR_TX, 
SOAPY_SDR_CS16, NULL, 0, NULL) != 0)
  | 
^~
  | |
  | char *
In file included from soapysdr.c:20:
/usr/include/SoapySDR/Device.h:309:19: note: expected 'const size_t *' {aka 
'const long unsigned int *'} but argument is of type 'char *'
  309 | const size_t *channels,
  | ~~^~~~
soapysdr.c:135:77: warning: passing argument 5 of 'SoapySDRDevice_setupStream' 
makes integer from pointer without a cast [-Wint-conversion]
  135 |  if(SoapySDRDevice_setupStream(rf->d, >s, SOAPY_SDR_TX, 
SOAPY_SDR_CS16, NULL, 0, NULL) != 0)
  | 
^~~~
  | 
|
  | 
void *
In file included from soapysdr.c:20:
/usr/include/SoapySDR/Device.h:310:18: note: expected 'size_t' {aka 'const long 
unsigned int'} but argument is of type 'void *'
  310 | const size_t numChans,
  | ~^~~~
soapysdr.c:135:5: error: too many arguments to function 
'SoapySDRDevice_setupStream'
  135 |  if(SoapySDRDevice_setupStream(rf->d, >s, SOAPY_SDR_TX, 
SOAPY_SDR_CS16, NULL, 0, NULL) != 0)
  | ^~
In file included from soapysdr.c:20:
/usr/include/SoapySDR/Device.h:306:31: note: declared here
  306 | SOAPY_SDR_API SoapySDRStream *SoapySDRDevice_setupStream(SoapySDRDevice 
*device,
  |   ^~

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Nader Nooryani]

Sorry, I should have mentioned that I have the packages you mention as well
as ipp-usb.
Will Debian detect and add both driverless-enabled printers and ones that
require drivers?

When I check Settings -> Printers in GNOME I am presented with this "Sorry!
The system printing service doesn't seem to be available."

I don't have a printer available to test, but I was under the impression
that libcups2 wasn't the only library required for printing.

On Sat, Sep 4, 2021 at 9:43 PM Holger Wansing  wrote:

> Hi,
>
> Holger Wansing  wrote (Sat, 4 Sep 2021 21:09:56
> +0200):
> > (BTW: CUPS also gets installed with the other desktops via
> > gnome-core -> system-config-printer-common -> cups-pk-helper -> libcups2)
>
> Hrr, copy-and-paste error here.
> Should have been:
>
> (BTW: CUPS also gets installed with the other desktops via
> task-xxyy-desktop -> system-config-printer -> libcups2 )
>
>
>
> And:
> KDE's dependency chain:
> task-kde-desktop -> print-manager -> libcups2
>
>
>
> --
> Holger Wansing 
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
>

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sat, 4 Sep 2021 21:09:56 +0200):
> (BTW: CUPS also gets installed with the other desktops via
> gnome-core -> system-config-printer-common -> cups-pk-helper -> libcups2)

Hrr, copy-and-paste error here.
Should have been:

(BTW: CUPS also gets installed with the other desktops via
task-xxyy-desktop -> system-config-printer -> libcups2 )



And: 
KDE's dependency chain:
task-kde-desktop -> print-manager -> libcups2



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#903517: (no subject)

[James Lu]

Control: tag -1 - help

Bug#993696: RM: qnnpack/experimental -- ROM; Deprecated by Upstream

[M. Zhou]

Package: ftp.debian.org
Severity: normal

https://github.com/pytorch/QNNPACK
The codebase has been archived, and merged into
src:pytorch by upstream.

Thank you for using reportbug

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Holger Wansing]

Hi,

Nader Nooryani  wrote (Sat, 4 Sep 2021 16:16:50 +0200):
> As of Debian 11, Print Server is no longer included as an option in the
> Debian installer if you use the defaults: Debian desktop environment, GNOME
> and standard system utilities.  Ref:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950553
> 
> This leaves the user without CUPS after a default install.  This should
> perhaps be included in task-gnome-desktop

I have tested this, and CUPS got installed here with GNOME desktop (default 
install).

The dependency chain turns out to be:
task-gnome-desktop -> gnome-core -> system-config-printer-common -> 
cups-pk-helper -> libcups2

(BTW: CUPS also gets installed with the other desktops via
gnome-core -> system-config-printer-common -> cups-pk-helper -> libcups2)

So, I cannot reproduce this.


Do you have the installation logs available?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#993692:

[tobias]

hello,

looks like the error regarding the forced kill is not a debian issue but 
also happens on ubuntu.

Bug should be closed.

The message seems curious as it is only produced when docker.service is 
stopped, not when a container is stopped using docker stop; next to that 
I do see containers are getting sigterm and correctly process it.

sorry for the inconvenience!

Tobias.

Bug#993695: ITP: golang-lukechampine-blake3 -- A pure-Go implementation of the BLAKE3 cryptographic hash function

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: golang-lukechampine-blake3
  Version : 1.1.5-1
  Upstream Author : Luke Champine
* URL : https://github.com/lukechampine/blake3
* License : Expat
  Programming Lang: Go
  Description : Pure-Go implementation of BLAKE3 cryptographic hash

 blake3 implements the BLAKE3 cryptographic hash function
 (https://github.com/BLAKE3-team/BLAKE3).  This implementation aims to
 be performant without sacrificing (too much) readability, in the hopes
 of eventually landing in x/crypto.
 .
 In addition to the pure-Go implementation, this package
 also contains AVX-512 and AVX2 routines (generated by avo
 (https://github.com/mmcloughlin/avo)) that greatly increase performance
 for large inputs and outputs.

Required for packaging NNCP

Bug#989141: /usr/share/php/smarty3/sysplugins/smarty_security.php: Smarty Security: not trusted file path

[Abhijith PA]

Hello.

I've prepared a build according to what you've said. Build available 
here[1]. Please take a look. Debdiff attached.


--abhijith

[1] - 
https://people.debian.org/~abhijith/upload/vda/smarty3_3.1.31+20161214.1.c7d42e4+selfpack1-2+deb9u4.dsc


diff -Nru smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/changelog 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/changelog
--- smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/changelog
2021-04-15 15:18:24.0 +0530
+++ smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/changelog
2021-09-04 23:49:02.0 +0530
@@ -1,3 +1,10 @@
+smarty3 (3.1.31+20161214.1.c7d42e4+selfpack1-2+deb9u4) UNRELEASED; 
urgency=medium
+
+  * Non-maintainer upload by the LTS Security Team.
+  * Test build for regression test #989141.
+
+ -- Abhijith PA   Sat, 04 Sep 2021 23:49:02 +0530
+
 smarty3 (3.1.31+20161214.1.c7d42e4+selfpack1-2+deb9u3) stretch-security; 
urgency=medium
 
   * Non-maintainer upload by the Debian LTS Team.
diff -Nru 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/patches/CVE-2018-13982-2.patch
 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/patches/CVE-2018-13982-2.patch
--- 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/patches/CVE-2018-13982-2.patch
   2021-04-04 12:45:17.0 +0530
+++ 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/patches/CVE-2018-13982-2.patch
   2021-09-04 23:47:25.0 +0530
@@ -2,8 +2,8 @@
 Origin: 
https://github.com/smarty-php/smarty/commit/f9ca3c63d1250bb56b2bda609dcc9dd81f0065f8
 Last-Update: 2021-04-04
 
 smarty3-3.1.31+20161214.1.c7d42e4+selfpack1.orig/libs/Smarty.class.php
-+++ smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/libs/Smarty.class.php
+--- a/libs/Smarty.class.php
 b/libs/Smarty.class.php
 @@ -978,7 +978,7 @@ class Smarty extends Smarty_Internal_Tem
  $this->plugins_dir = (array) $this->plugins_dir;
  }
@@ -48,8 +48,8 @@
  // resolve '..DIRECTORY_SEPARATOR' pattern, smallest first
  if (strpos($path, '..' . $this->ds) != false &&
  preg_match_all('#[/]([.][.][/])+#u', $path, $match)
 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1.orig/libs/sysplugins/smarty_security.php
-+++ 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/libs/sysplugins/smarty_security.php
+--- a/libs/sysplugins/smarty_security.php
 b/libs/sysplugins/smarty_security.php
 @@ -258,8 +258,6 @@ class Smarty_Security
  public function __construct($smarty)
  {
@@ -71,7 +71,7 @@
  }
 -}
 -if ($isConfig !== false) {
-+
++
  $_dir = $this->smarty->getConfigDir();
  if ($this->_config_dir !== $_dir) {
  $this->_updateResourceDir($this->_config_dir, $_dir)
@@ -82,7 +82,7 @@
  $this->secure_dir = (array)$this->secure_dir;
  foreach($this->secure_dir as $k => $d) {
 -$this->secure_dir[$k] = 
$this->smarty->_realpath($d.DIRECTORY_SEPARATOR,true);
-+$this->secure_dir[$k] = $this->smarty->_realpath($d. 
$this->ds,true);
++$this->secure_dir[$k] = $this->smarty->_realpath($d. 
DIRECTORY_SEPARATOR,true);
  }
  $this->_updateResourceDir($this->_secure_dir, $this->secure_dir);
  $this->_secure_dir = $this->secure_dir;
@@ -123,7 +123,7 @@
 -}
 -$filepath = $this->smarty->_realpath($filepath, true);
 -$directory = dirname($filepath) . DIRECTORY_SEPARATOR;
-+$directory = dirname($this->smarty->_realpath($filepath, true)) . 
$this->ds;
++$directory = dirname($this->smarty->_realpath($filepath, true)) . 
DIRECTORY_SEPARATOR;
  $_directory = array();
  while (true) {
  // test if the directory is trusted
diff -Nru 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/patches/CVE-2018-13982-3.patch
 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/patches/CVE-2018-13982-3.patch
--- 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/patches/CVE-2018-13982-3.patch
   2021-04-15 15:17:32.0 +0530
+++ 
smarty3-3.1.31+20161214.1.c7d42e4+selfpack1/debian/patches/CVE-2018-13982-3.patch
   2021-09-04 23:48:41.0 +0530
@@ -75,7 +75,7 @@
 --- a/libs/sysplugins/smarty_security.php
 +++ b/libs/sysplugins/smarty_security.php
 @@ -527,7 +527,7 @@ class Smarty_Security
- 
+ 
  $_dir = $this->smarty->getConfigDir();
  if ($this->_config_dir !== $_dir) {
 -$this->_updateResourceDir($this->_config_dir, $_dir)
@@ -85,7 +85,7 @@
  if ($this->_secure_dir !== $this->secure_dir) {
 @@ -639,7 +639,8 @@ class Smarty_Security
  {
- $directory = dirname($this->smarty->_realpath($filepath, true)) . 
$this->ds;
+ $directory = dirname($this->smarty->_realpath($filepath, true)) . 
DIRECTORY_SEPARATOR;
  $_directory = array();
 -while (true) {
 +if (!preg_match('#[/][.][.][/]#',$directory)) {
@@ 

Bug#993684: plocate fails with assertion

[Michael Arndt]

Package: plocate
Version: 1.1.10-3
Severity: normal
X-Debbugs-Cc: arndt.mich...@protonmail.com

Dear Maintainer,

running plocate with the options --existing and --regexp causes it to exit with
an assertion (exit code 134). For example the following invocation fails:

plocate --existing --regexp txt

Using only one of the two options is successful. I get the following output
from the failing program:

plocate: ../serializer.h:19: virtual Serializer::~Serializer(): Assertion
`limit_left <= 0 || pending.empty()' failed.
Aborted (core dumped)

I also tried removing the plocate database located at
/var/lib/plocate/plocate.db and recreating it with updatedb but that didn't
help.

Best regards,
Michael

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

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

Versions of packages plocate depends on:
ii  libc6   2.31-17
ii  libgcc-s1   11.2.0-4
ii  libstdc++6  11.2.0-4
ii  liburing1   0.7-3
ii  libzstd11.4.8+dfsg-2.1

plocate recommends no packages.

Versions of packages plocate suggests:
ii  systemd-sysv  247.9-1

Bug#993694: missing Depends: python3-jinja2

[Diane Trout]

Hmm...

So dask doesn't think jinja is required for base functionality. It's a
dependency for an extended extras.

>From dask's setup.py
extras_require = {
"array": ["numpy >= 1.18"],
"bag": [],  # keeping for backwards compatibility
"dataframe": ["numpy >= 1.18", "pandas >= 1.0"],
"distributed": ["distributed == 2021.08.1"],
"diagnostics": [
"bokeh >= 1.0.0, != 2.0.0",
"jinja2",
],
"delayed": [],  # keeping for backwards compatibility
}

At dask's end jinja should probably be a suggests or recommends, but
since you can use dask without needing widgets I'm not 100% sure jinja
needs to build-dependency.

(Do widgets even work on Debian? Last time I tried jupyter widgets I
couldn't get them to work.)

Diane


On Sat, 2021-09-04 at 22:36 +0200, Drew Parsons wrote:
> Package: python3-dask
> Version: 2021.08.1+dfsg-1
> Severity: serious
> Justification: debci
> Control: affects -1 src:python-xarray
> 
> dask imports from jinja2 in
> /usr/lib/python3/dist-packages/dask/widgets/widgets.py, but
> Depends: python3-jinja2 has not been declared.
> 
> dask's own tests are apparently not testing widget since they're
> passing, but
> the error is triggered by python-xarray, see
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-xarray/15028004/log.gz
> 
> 
> I guess debian/control needs Build-Depends: python3-jinja2
> and then dh_python will take care of the Depends field in the binary
> package.
> 
> Drew
> 

Bug#979755: ITA: coyim

[Kushagra Karira]

To become a sponsored maintainer,  i'd like to take up the coyim,
The package seems good enough that people will actually use, it is under
active development according to its github page and small enough to work
with any errors.

Regards
Kushagra Karira

Bug#993684: plocate fails with assertion

[Steinar H. Gunderson]

On Sat, Sep 04, 2021 at 08:17:14PM +0200, Michael Arndt wrote:
> running plocate with the options --existing and --regexp causes it to exit 
> with
> an assertion (exit code 134).

Hi,

You're entirely right; I can confirm. I'll have a look one of these days.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#993527: [debian-mysql] Bug#993527: mariadb-server: At full-upgrade from buster to bullseye mariadb-server (and also client) are removed.

[Otto Kekäläinen]

Thanks Tobias for looking into it.

When you do testing, please don't do any pinning or other stuff that
interferes with apt. There is no need to recompile anything either.
The versions of MariaDB and Galera in Debian Sid, Testing and Bullseye
are all compiled with the exact same toolchain and are still
identical.

Simply test a normal upgrade from Buster to Debian Testing and see if
the issue still repeats with all the MariaDB and Galera packages in
Debian Testing.

- Otto

Bug#993647: libccid >= 1.4.35 breaks SafeNet tokens

[Ludovic Rousseau]

Hello,

Le 04/09/2021 à 09:57, Vladimir K a écrit :

Package: libccid
Version: 1.4.35-2
Severity: important

Dear Maintainer, upgrading libccid to 1.4.35 or 1.4.36 results in non-working 
SafeNet token

The problem is not immediate, appears apparently after some cache refresh 
events of either
pcscd or the middleware (safenetauthenticationclient).

But anyway, when libccid>=1.4.35 is installed, pcscd eventually starts failing 
when I try
accessing objects from the token:

Sep 04 10:13:18 hostname pcscd[677]: 35941163 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0510 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0356 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0338 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0388 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0399 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0387 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0390 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0374 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0350 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0341 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0316 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0322 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:18 hostname pcscd[677]: 0324 winscard.c:264:SCardConnect() 
Reader  Not Found
Sep 04 10:13:23 hostname pcscd[677]: 04990760 commands.c:1557:CCID_Receive() 
Not enough data received: 0 bytes
Sep 04 10:13:23 hostname pcscd[677]: 0059 
openct/proto-t1.c:215:t1_transceive() fatal: transmit/receive failed
Sep 04 10:13:23 hostname pcscd[677]: 0019 ifdwrapper.c:543:IFDTransmit() 
Card not transacted: 612
Sep 04 10:13:23 hostname pcscd[677]: 0016 winscard.c:1620:SCardTransmit() 
Card not transacted: 0x80100016
Sep 04 10:13:23 hostname pcscd[677]: 5775 
openct/proto-t1.c:171:t1_transceive() T=1 state machine is DEAD. Reset the card 
first.
Sep 04 10:13:23 hostname pcscd[677]: 0046 ifdwrapper.c:543:IFDTransmit() 
Card not transacted: 612
Sep 04 10:13:23 hostname pcscd[677]: 0023 winscard.c:1620:SCardTransmit() 
Card not transacted: 0x80100016
Sep 04 10:13:23 hostname pcscd[677]: 3211 
openct/proto-t1.c:171:t1_transceive() T=1 state machine is DEAD. Reset the card 
first.
Sep 04 10:13:23 hostname pcscd[677]: 0031 ifdwrapper.c:543:IFDTransmit() 
Card not transacted: 612
Sep 04 10:13:23 hostname pcscd[677]: 0021 winscard.c:1620:SCardTransmit() 
Card not transacted: 0x80100016
Sep 04 10:13:23 hostname pcscd[677]: 2686 
openct/proto-t1.c:171:t1_transceive() T=1 state machine is DEAD. Reset the card 
first.
Sep 04 10:13:23 hostname pcscd[677]: 0037 ifdwrapper.c:543:IFDTransmit() 
Card not transacted: 612
Sep 04 10:13:23 hostname pcscd[677]: 0022 winscard.c:1620:SCardTransmit() 
Card not transacted: 0x80100016
Sep 04 10:13:23 hostname pcscd[677]: 2299 
openct/proto-t1.c:171:t1_transceive() T=1 state machine is DEAD. Reset the card 
first.
Sep 04 10:13:23 hostname pcscd[677]: 0030 ifdwrapper.c:543:IFDTransmit() 
Card not transacted: 612
Sep 04 10:13:23 hostname pcscd[677]: 0020 winscard.c:1620:SCardTransmit() 
Card not transacted: 0x80100016
Sep 04 10:13:23 hostname pcscd[677]: 2982 
openct/proto-t1.c:171:t1_transceive() T=1 state machine is DEAD. Reset the card 
first.
Sep 04 10:13:23 hostname pcscd[677]: 0028 ifdwrapper.c:543:IFDTransmit() 
Card not transacted: 612
Sep 04 10:13:23 hostname pcscd[677]: 0020 winscard.c:1620:SCardTransmit() 
Card not transacted: 0x80100016
Sep 04 10:13:23 hostname pcscd[677]: 3621 
openct/proto-t1.c:171:t1_transceive() T=1 state machine is DEAD. Reset the card 
first.
Sep 04 10:13:23 hostname pcscd[677]: 0030 ifdwrapper.c:543:IFDTransmit() 
Card not transacted: 612
Sep 04 10:13:23 hostname pcscd[677]: 0019 winscard.c:1620:SCardTransmit() 
Card not transacted: 0x80100016
Sep 04 10:13:23 hostname pcscd[677]: 2932 
openct/proto-t1.c:171:t1_transceive() T=1 state machine is DEAD. Reset the card 
first.
Sep 04 10:13:23 hostname pcscd[677]: 0036 ifdwrapper.c:543:IFDTransmit() 
Card not transacted: 612
Sep 04 10:13:23 hostname pcscd[677]: 0023 winscard.c:1620:SCardTransmit() 
Card not transacted: 0x80100016
Sep 04 10:13:23 hostname pcscd[677]: 2110 
openct/proto-t1.c:171:t1_transceive() T=1 state machine is DEAD. Reset the card 
first.
Sep 04 10:13:23 hostname pcscd[677]: 0032 ifdwrapper.c:543:IFDTransmit() 
Card not transacted: 612
Sep 04 10:13:23 hostname pcscd[677]: 0021 

Bug#993219: [debian-mysql] Bug#993219: Bug#993219: mariadb-server-core: Akonadi database - mysql_upgrade fails always with "FATAL ERROR: Can't execute 'mysqlcheck'"

[Otto Kekäläinen]

> Btw. a successful migration should also take care of  the redo logs. The user
> normally does not know, whether the database was shut down correctly or not.

Maybe they should, or at least take a backup before a big upgrade so
they can go back to the old version when they see an error message
like this in the upgrade?

This error message is from the MariaDB server and not from the Debian
packaging scripts. You will get the exact same result on any distro if
you crash the database and then proceed to start it with another
version.

The software is open source, so if you have an idea how to avoid this
(e.g. how to tell users if their database crashed or how to do
database recovery in every possible situation), feel free to open a
pull request upstream at MariaDB Server.

- Otto

Bug#993694: missing Depends: python3-jinja2

[Drew Parsons]

Package: python3-dask
Version: 2021.08.1+dfsg-1
Severity: serious
Justification: debci
Control: affects -1 src:python-xarray

dask imports from jinja2 in
/usr/lib/python3/dist-packages/dask/widgets/widgets.py, but
Depends: python3-jinja2 has not been declared.

dask's own tests are apparently not testing widget since they're passing, but
the error is triggered by python-xarray, see
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-xarray/15028004/log.gz


I guess debian/control needs Build-Depends: python3-jinja2
and then dh_python will take care of the Depends field in the binary package.

Drew

Bug#993693: ReferenceError: options is not defined

[Julien Puydt]

Package: webpack
Version: 5.6.0+~cs6.4.0-1~exp2
Severity: grave

I was trying to update another js-team package and couldn't understand
what was wrong until I tried to just run webpack by itself in another
directory:

$ webpack 
[webpack-cli] ReferenceError: options is not defined
at Object.apply
(/usr/share/nodejs/webpack/lib/config/defaults.js:873:30)
at WebpackOptionsApply.process
(/usr/share/nodejs/webpack/lib/WebpackOptionsApply.js:453:16)
at createCompiler (/usr/share/nodejs/webpack/lib/webpack.js:78:28)
at create (/usr/share/nodejs/webpack/lib/webpack.js:115:15)
at webpack (/usr/share/nodejs/webpack/lib/webpack.js:123:46)
at f (/usr/share/nodejs/webpack/lib/index.js:35:15)
at WebpackCLI.createCompiler (/usr/share/nodejs/webpack-
cli/lib/webpack-cli.js:176:24)
at WebpackCLI.run (/usr/share/nodejs/webpack-cli/lib/webpack-
cli.js:268:25)
at async runCLI (/usr/share/nodejs/webpack-
cli/lib/bootstrap.js:59:9)

This means it's broken ; installing unstable's 4.43.0-6 made the error
go away, so it's a problem only with the new version.

Cheers,

J.Puydt

Bug#993692: docker.io: docker.service does not shutdown containers gracefullly

[tobias]

Package: docker.io
Version: 20.10.5+dfsg1-1+b5
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: hostmas...@appelo.org

Dear Maintainer,

 
install a debian fresh bullsye system. install docker.io and run
   nginx as a container. the container is forcefully killed:
"transport: Error while dialing dial unix:///run/containerd/containerd.sock: 
timeout\". Reconnecting..." module=grpc
Sep 03 18:59:53 stevie dockerd[717535]: time="2021-09-03T18:59:53.062476364Z" 
level=warning msg="grpc: addrConn.createTransport failed to connect to 
{unix:///run/containerd/containerd.sock   0 }. Err :connection error: 
desc = \"transport: Error while dialing dial 
unix:///run/containerd/containerd.sock: timeout\". Reconnecting..." module=grpc
Sep 03 18:59:54 stevie dockerd[717535]: time="2021-09-03T18:59:54.062582937Z" 
level=info msg="Container failed to stop after sending signal 3 to the process, 
force killing"
Sep 03 18:59:54 stevie dockerd[717535]: time="2021-09-03T18:59:54.062844365Z" 
level=error msg="failed to shut down container" 
container=e0ab7899bffdf32fa2b47c84a56c29fec1674bbc85749c8b7d9bead8befd1efa 
error="Failed to stop container 
e0ab7899bffdf32fa2b47c84a56c29fec1674bbc85749c8b7d9bead8befd1efa with error: 
Cannot kill container 
e0ab7899bffdf32fa2b47c84a56c29fec1674bbc85749c8b7d9bead8befd1efa: connection 
error: desc = \"transport: Error while dialing dial 
unix:///run/containerd/containerd.sock: timeout\": unavailable"

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

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

Versions of packages docker.io depends on:
ii  adduser  3.118
ii  containerd   1.4.5~ds1-2
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-13
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libsystemd0  247.3-6
ii  lsb-base 11.1.0
ii  runc 1.0.0~rc93+ds1-5+b2
ii  tini 0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 2.13.6-10
ii  ca-certificates  20210119
pn  cgroupfs-mount   
pn  git  
ii  needrestart  3.5-4
ii  xz-utils 5.2.5-2

Versions of packages docker.io suggests:
pn  aufs-tools 
pn  btrfs-progs
pn  debootstrap
pn  docker-doc 
ii  e2fsprogs  1.46.2-2
pn  rinse  
pn  rootlesskit
pn  xfsprogs   
pn  zfs-fuse | zfsutils-linux  

-- no debconf information

Bug#993568: [pkg-apparmor] Bug#993568: dh-apparmor: Allow opting-out from creating local include

[Christian Boltz]

Hello,

Am Freitag, 3. September 2021, 10:01:47 CEST schrieb 
intrig...@debian.org:
> "include if exists" is well supported in AppArmor 3.x,
> so we could stop creating /etc/apparmor.d/local/$profile
> local include files.
> 
> I don't think we can do that by default though: if we did, it would
> break loading newly installed profiles that still use #include.

Interestingly I received a similar proposal for openSUSE and will 
probably stop shipping the local/* sniplets with the 3.1 release.
(Handling / cleaning up existing local/* files without getting modified 
files moved away is an interesting[tm] packaging exercise. I'm not sure 
how much the handling of that can be shared betwen RPM and DEB packages, 
but we should at least try to avoid duplicate work.)

This also leads to the questiion if upstream AppArmor should by default 
stop generating the local/* sniplets in profiles/Makefile. Since all 
profiles shipped with the upstream tarball use "include if exists", that 
wouldn't break anything.

Anyway - back to the original topic ;-)

I see two possible options:

- add an option to dh_apparmor to not create the local/ sniplet
  (disadvantage: needs adjustments in all packages that don't want the 
  local/ file; advantage: no "surprising" behaviour change)

- make dh_apparmor a bit more intelligent and grep the profile for the 
  local include. If it finds "include " it should 
  create the local/ file, but if it finds "include if exists " it could stop creating that file. Or, to make it more 
  error-proof, create the local/ file if it doesn't find 
  "include if exists ". [Note: I don't know the current
  dh_apparmor code.]
  (advantage: no need to adjust any package; disadvantage: applying grep 
  magic to the real world is sometimes not as easy as it looks)

BTW: If you want to use grep, you can steal the grep regex from the 
upstream profiles/Makefile (in the "local:" target).


Regards,

Christian Boltz
-- 
A bug a day keeps the doctor away - ke 2006
[bugzilla.novell.com quips]

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

Bug#993691: pytest-mpi: autopkgtest regression: Building wheel for mpi4py (PEP 517): finished with status 'error'

[Paul Gevers]

Source: pytest-mpi
Version: 0.5-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of pytest-mpi the autopkgtest of pytest-mpi fails
in testing when that autopkgtest is run with the binary packages of
pytest-mpi from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
pytest-mpi from testing0.5-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems that
the test fell back to downloading all kind of stuff from the internet (I
do hope unintended otherwise: please add a needs-internet restriction)
and failed.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[1] https://qa.debian.org/excuses.php?package=pytest-mpi

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pytest-mpi/15028995/log.gz

py39-mpi-oldpt create:
/tmp/autopkgtest-lxc.54h7da0c/downtmp/build.9o5/src/.tox/py39-mpi-oldpt
py39-mpi-oldpt installdeps: pytest, pytest-cov, sybil,
-cknown_broken_constraints.txt, mpi4py, -cold_pytest.txt
ERROR: invocation failed (exit code 1), logfile:
/tmp/autopkgtest-lxc.54h7da0c/downtmp/build.9o5/src/.tox/py39-mpi-oldpt/log/py39-mpi-oldpt-1.log
== log start
===
Collecting pytest
  Downloading pytest-5.4.3-py3-none-any.whl (248 kB)
Collecting pytest-cov
  Downloading pytest_cov-2.12.1-py2.py3-none-any.whl (20 kB)
Collecting sybil
  Downloading sybil-2.0.1-py2.py3-none-any.whl (13 kB)
Collecting mpi4py
  Downloading mpi4py-3.1.1.tar.gz (2.4 MB)
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
Preparing wheel metadata: started
Preparing wheel metadata: finished with status 'done'
Collecting wcwidth
  Downloading wcwidth-0.2.5-py2.py3-none-any.whl (30 kB)
Collecting packaging
  Downloading packaging-21.0-py3-none-any.whl (40 kB)
Collecting more-itertools>=4.0.0
  Downloading more_itertools-8.9.0-py3-none-any.whl (51 kB)
Collecting attrs>=17.4.0
  Downloading attrs-21.2.0-py2.py3-none-any.whl (53 kB)
Collecting py>=1.5.0
  Downloading py-1.10.0-py2.py3-none-any.whl (97 kB)
Collecting pluggy<1.0,>=0.12
  Downloading pluggy-0.13.1-py2.py3-none-any.whl (18 kB)
Collecting toml
  Downloading toml-0.10.2-py2.py3-none-any.whl (16 kB)
Collecting coverage>=5.2.1
  Downloading coverage-5.5-cp39-cp39-manylinux2010_x86_64.whl (243 kB)
Collecting pyparsing>=2.0.2
  Downloading pyparsing-2.4.7-py2.py3-none-any.whl (67 kB)
Building wheels for collected packages: mpi4py
  Building wheel for mpi4py (PEP 517): started
  Building wheel for mpi4py (PEP 517): finished with status 'error'
  ERROR: Command errored out with exit status 1:



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993086: Please package new upstream

[Julien Puydt]

Le vendredi 03 septembre 2021 à 07:52 +0200, Martin Quinson a écrit :
> 
> Julien, if you want to proceed with packaging the next upstream
> release, please do so: the new term is rather overwhelming here.
> 

I pushed quite a few things ; I would be more at ease if someone else
had a look before any upload.

I'm a bit annoyed that "gbp import-orig --uscan" doesn't work as it
should ; I had to run uscan and call gbp import-orig on the resulting
tarball by hand. It took me a while to figure out, as I hadn't needed
this since years!

Cheers,

J.Puydt

Bug#993343: OpenLDAP 2.5 FTBFS on GNU/Hurd: MAXPATHLEN undeclared

[Joshua Branson]

Ryan Tandy  writes:

> Source: openldap
> Version: 2.5.5+dfsg-1~exp1
> Severity: important
> Tags: upstream ftbfs help
> Forwarded: https://bugs.openldap.org/show_bug.cgi?id=9658
>
> I confirmed locally that current git master is still affected.
>
> It's well-known that GNU/Hurd doesn't provide MAXPATHLEN.
> https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL
>
> I don't have the bandwidth to work on this myself. It would be great
> if someone from the Hurd community could look at it.

This is supposed to be an "easy fix".  I'd be willing to try to work
with you to help you fix this.  Bear in mind, I'm not the best C
developer.  I'm on Eastern Standard Time.  I'm usually free in the
mornings.  Does that sound good for you?

https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html

>
> thanks
> Ryan
>

--
Joshua Branson (jab in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Bug#993689: linux-image-5.10.0-0.bpo.5-amd64-unsigned: L2CAP receive buffer overflow when using PC as LDAC sink

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Sat, Sep 04, 2021 at 11:00:37PM +0300, kir wrote:
> Package: src:linux
> Version: 5.10.24-1~bpo10+1
> Severity: normal
> 
> Dear Maintainer,
>* What led up to the situation?
> I installed bluealsa with LDAC sink support according to this instruction:
> https://github.com/anonymix007/libldacdec/blob/master/README.md
> The actual problem is that playback stops after a while.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> I commented out "goto drop" line in net/bluetooth/l2cap_core.c
> 
> if (chan->imtu < skb->len) {
> BT_ERR("Dropping L2CAP data: receive buffer overflow -
> chan->imtu: %d, skb->len: %d", chan->imtu, skb->len);
> //goto drop;
> }
>* What was the outcome of this action?
> This in logs: "Bluetooth: Dropping L2CAP data: receive buffer overflow -
> chan->imtu: 672, skb->len: 673" and it finally worked
> 
>* What outcome did you expect instead?
> I expected it to work, but this is not the proper solution.

Could you plase test this against current mainline or 5.10.62 and in
case reproducible there report it upstream? (keep this bugreport in
the loop). Buest guess to report to is (use
./scripts/get_maintainer.pl):

Marcel Holtmann  (supporter:BLUETOOTH SUBSYSTEM)
Johan Hedberg  (supporter:BLUETOOTH SUBSYSTEM)
Luiz Augusto von Dentz  (supporter:BLUETOOTH SUBSYSTEM)
"David S. Miller"  (maintainer:NETWORKING [GENERAL])
Jakub Kicinski  (maintainer:NETWORKING [GENERAL])
linux-blueto...@vger.kernel.org (open list:BLUETOOTH SUBSYSTEM)
net...@vger.kernel.org (open list:NETWORKING [GENERAL])
linux-ker...@vger.kernel.org (open list)

Regards,
Salvatore

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Hideki Yamane]

On Thu, 2 Sep 2021 21:26:11 +0200
Simon Richter  wrote:
> The TLS layer is not part of the security model, so we'd be teaching 
> users to look for the wrong thing, kind of like the "encrypted with SSL" 
> badges on web pages in the 90ies.

 Is there any strong reason to use HTTP than HTTPS now?
 Should we teach all our users (including non-tech) about "Secure APT"
 mechanism?


 And I said about only deb.debian.org and security.debian.org, and
 just "default" - it means it does provide http access too.



-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#993690: goban-ss: Goban-ss binary in incorrect location

[Bill Thompson]

Package: goban-ss
Version: 1.1-6
Severity: important
Tags: a11y

Dear Maintainer,

On a new installation of Debian 11, the goban-ss package installs the binary 
file for the screensaver into the directory /usr/lib/xscreensaver/goban. The 
xscreensaver package sets the default directory for binaries as 
/usr/libexec/xscreensaver/goban. When the goban-ss package in installed the 
xscreensaver progam show the module as "Not Installed". I was able to correct 
this by creating a simlink to put the goban-ss binary in the correct location 
(sudo ln -s /usr/lib/xscreensaver/goban /usr/libexec/xscreensaver/goban).


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

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

Versions of packages goban-ss depends on:
ii  libc6 2.31-13
ii  libx11-6  2:1.7.2-1

Versions of packages goban-ss recommends:
ii  goban-original-games  1.1-6
ii  xscreensaver  5.45+dfsg1-2

goban-ss suggests no packages.

-- no debconf information

Bug#993689: linux-image-5.10.0-0.bpo.5-amd64-unsigned: L2CAP receive buffer overflow when using PC as LDAC sink

[kir]

Package: src:linux
Version: 5.10.24-1~bpo10+1
Severity: normal

Dear Maintainer,
   * What led up to the situation?
I installed bluealsa with LDAC sink support according to this instruction:
https://github.com/anonymix007/libldacdec/blob/master/README.md
The actual problem is that playback stops after a while.

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

I commented out "goto drop" line in net/bluetooth/l2cap_core.c

if (chan->imtu < skb->len) {
BT_ERR("Dropping L2CAP data: receive buffer overflow -
chan->imtu: %d, skb->len: %d", chan->imtu, skb->len);
//goto drop;
}
   * What was the outcome of this action?
This in logs: "Bluetooth: Dropping L2CAP data: receive buffer overflow -
chan->imtu: 672, skb->len: 673" and it finally worked

   * What outcome did you expect instead?
I expected it to work, but this is not the proper solution.



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: To Be Filled By O.E.M.
product_name: To Be Filled By O.E.M.
product_version: To Be Filled By O.E.M.
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: P1.80
board_vendor: ASRock
board_name: Z370 Extreme4
board_version: 

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host 
Bridge/DRAM Registers [8086:3ec2] (rev 07)
Subsystem: ASRock Incorporation 8th Gen Core Processor Host Bridge/DRAM 
Registers [1849:3ec2]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore
Kernel modules: ie31200_edac

00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller (x16) 
[8086:1901] (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 USB controller [0c03]: Intel Corporation 200 Series/Z370 Chipset Family 
USB 3.0 xHCI Controller [8086:a2af] (prog-if 30 [XHCI])
Subsystem: ASRock Incorporation 200 Series/Z370 Chipset Family USB 3.0 
xHCI Controller [1849:a2af]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 Signal processing controller [1180]: Intel Corporation 200 Series PCH 
Thermal Subsystem [8086:a2b1]
Subsystem: ASRock Incorporation 200 Series PCH Thermal Subsystem 
[1849:a2b1]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:16.0 Communication controller [0780]: Intel Corporation 200 Series PCH CSME 
HECI [8086:a2ba]
Subsystem: ASRock Incorporation 200 Series PCH CSME HECI [1849:a2ba]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:17.0 SATA controller [0106]: Intel Corporation 200 Series PCH SATA 
controller [AHCI mode] [8086:a282] (prog-if 01 [AHCI 1.0])
Subsystem: ASRock Incorporation 200 Series PCH SATA controller [AHCI 
mode] [1849:a282]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

00:1b.0 PCI bridge [0604]: Intel Corporation 200 Series PCH PCI Express Root 
Port [8086:a2e7] (rev f0) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.0 PCI bridge [0604]: Intel Corporation 200 Series PCH PCI Express Root 
Port [8086:a290] (rev f0) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-

Bug#945888: The nscd daemon use a wrong path to open cache files

[Aurelien Jarno]

On 2020-02-08 17:57, Aurelien Jarno wrote:
> On 2019-11-30 16:00, André Rodier wrote:
> > Package: nscd
> > Version: 2.28-10
> > 
> > When using AppArmor and ldap for users database, and nscd on Debian, a
> > lot of errors are visible in the AppArmor logs, when any program
> > queries nscd.
> > 
> > The nscd daemon tries to open files in "var/cache/nscd/..." instead of
> > "/var/cache/nscd/...". Note the missing slash character at the
> > beginning. AppArmor complains about the file access denied, but the
> > error is really a missing '/' character in the path of the cache files.
> 
> What makes you believe that? I have just tried with strace, and I see
> the correct path with the leading '/':
> 
> openat(AT_FDCWD, "/var/cache/nscd/passwd", O_RDWR|O_CLOEXEC) = 4
> openat(AT_FDCWD, "/var/cache/nscd/passwd", O_RDONLY|O_CLOEXEC) = 5
> openat(AT_FDCWD, "/var/cache/nscd/group", O_RDWR|O_CLOEXEC) = 6
> openat(AT_FDCWD, "/var/cache/nscd/group", O_RDONLY|O_CLOEXEC) = 7
> openat(AT_FDCWD, "/var/cache/nscd/hosts", O_RDWR|O_CLOEXEC) = 8
> openat(AT_FDCWD, "/var/cache/nscd/hosts", O_RDONLY|O_CLOEXEC) = 9
> openat(AT_FDCWD, "/var/cache/nscd/services", O_RDWR|O_CLOEXEC) = 10
> openat(AT_FDCWD, "/var/cache/nscd/services", O_RDONLY|O_CLOEXEC) = 11
> openat(AT_FDCWD, "/var/cache/nscd/netgroup", O_RDWR|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/var/cache/nscd/netgroup", O_RDONLY|O_CLOEXEC) = 13

Any news about that?

Regards,
Aurelien

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

Bug#993602: /etc/runit/nosync should not have been moved to /run

[lorenzo]

On Fri, 3 Sep 2021 16:44:09 +0200
Andras Korn  wrote:

> Package: runit
> Version: 2.1.2-42
> Severity: normal
> 
> Hi,

Hi,

> 
> I'm the guy who originally submitted the patch to support a 'nosync'
> flag file to avoid syncing on shutdown.
> 
> I noted with some amazement in the changelog for version 2.1.2-42
> that this file had been moved to /run sometime in the past, with no
> mention in the changelog.

I think it happened by mistake when runit source was converted into the
debhelper format, see

https://salsa.debian.org/runit-team/runit/-/commit/c0066204fa930f3e57eb32a4cc28beed349658b2

https://salsa.debian.org/runit-team/runit/-/commit/c966a77f0414d4eadbed2cf36de726399f01106c

(and etc was already worded as 'erc' by some other mistake
happened previously but i stop digging at commit c0066204 )


> 
> I think this change should be reverted.

I Agree, will do that in the next upload.

> 
> The use case of the nosync flag file is when running runit in a
> container like LXC or linux-vserver. When you stop one of these (or
> hundreds of these simultaneously), you don't want them to sync()
> because the host itself isn't stopping, so there is neither a need
> nor a benefit to invoking sync().
> 
> Not wanting to invoke sync() on shutdown is a permanent property of a
> system, not an ephemeral one. Thus, the flag file for this behaviour
> should be in a permanent location (like /etc/runit, where it
> originally was), not under /run, where it would need to be created on
> every boot.

The only issue with reverting to /etc is that as long as /etc is mounted
readonly it will not be possible to write this file: but as the use
case is a container I guess the file will be written during the
container setup, before runtime, right?

> 
> Best regards,
> 
> András

Best Regards,
Lorenzo

> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable
>   APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN,
> TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8,
> LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell:
> /bin/sh linked to /bin/bash Init: runit (via /run/runit.stopit)
> LSM: AppArmor: enabled
> 

Bug#993654: nobody can reply to "gregor herrmann "

[積丹尼 Dan Jacobson]

gregor herrmann: nobody can reply to
"gregor herrmann "

Bug#993552: correction

[BenTheTechGuy]

Thank you for the info, for now I'll keep it as-is until I can find
out how to properly do it.
As a side note, the correct URL for the latest upload is
https://mentors.debian.net/debian/pool/contrib/p/proton-caller/proton-caller_2.3.2-2.dsc
I was lazy and just copied the last URL and changed the version
number, forgetting the package is now in contrib.

Bug#982147: Test case for libmgba-dev

[Ryan Tandy]

Hello,

I'm working on the libmgba-dev package. Can either of you share a link 
to a project or test case that I can use to test it? or would either of 
you be willing to test the package if I push the changes (or a repo of 
built packages) somewhere?


thanks,
Ryan

Bug#969175: Are minetest problems with polish locale still current?

[Julien Puydt]

Hi,

I'm trying to go through the minetest bugs, and so I'm wondering if the
problem you reported a year ago was still current -- after all we have
much more recent versions of minetest now?

Thanks,

J.Puydt

Bug#993688: 'file' driver requires '/dev/mapper/' to be a regular file

[Marc Haber]

Package: qemu-system-x86
Version: 1:6.1+dfsg-4
Severity: normal

Hi,

this is a regression from qemu in bullseye to qemu in sid.

I am using a VM with a block device that is a crypted LV. It gets
unlocked by sudo cryptsetup --type=luks open /dev/mapper/drop-c_lv
cryptodevice, resulting in /dev/mapper/cryptodevice being a symlink to
/dev/dm-something with something being a different number every time.

The corresponding XML is

  
  
  
  
pn  vde2

-- no debconf information

Bug#993687: RFS: rumur/2021.08.28-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

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

It builds those binary packages:

  rumur - model checker for the Murphi language

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

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

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

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

Changes since the last upload:

rumur (2021.08.28-1) unstable; urgency=medium
.
   * New upstream release.
.
   * A new binary, murphi2uclid, is now included.
.
   * Python build dependency and suggests have been relaxed from 3.6 to 3.4.

Regards,
Matt

Bug#993662: lintian: Please warn for source file that have This file was autogenerated or DO NOT EDIT BY HAND

[Sean Whitton]

Hello,

On Sat 04 Sep 2021 at 12:01PM GMT, Bastien Roucariès wrote:

> Source: lintian
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: ftpmas...@debian.org
>
> Dear Maintainer,
>
> Doing some code review on mozilla I found this interesting file
> https://sources.debian.org/src/firefox-
> esr/78.13.0esr-1/js/src/frontend/BinASTEnum.h/?hl=1#L1
>
> // This file was autogenerated by binjs_generate_spidermonkey,
> // please DO NOT EDIT BY HAND.
>
> I think we should warn level pedantic when we found this 'file (was|is)
> autogenerated' and Do not edit by hand
>
> It will help work of ftpmaster BTW

Maybe higher than pedantic?  Any such file needs to be checked by the
uploader to confirm the source is in the source package, so a Lintian
warning which can be overridden when this check has been done would help
NEW.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#993686: Replace deprecated 'which' with 'command -v'

[積丹尼 Dan Jacobson]

Package: ucf
Version: 3.0043

> "gh" == gregor herrmann  writes:
gh> Control: tag -1 pending

gh> Hello,

gh> Bug #993654 in libxml-sax-perl reported by you has been fixed in the
gh> Git repository and is awaiting an upload. You can see the commit
gh> message below and you can check the diff of the fix at:

gh> 
https://salsa.debian.org/perl-team/modules/packages/libxml-sax-perl/-/commit/43330f716f58062a0fbb629054dc8e9459753cda

gh> 
gh> Replace deprecated 'which' with 'command -v' in maintainer script(s).

gh> Note that this change doesn't make the warnings on installation go away, as
gh> they actually come from ucf(1).

That sounds terrible. OK, I hereby tell them.

Bug#993083: Confirmation and journal

[Rob]

OK so I think I've got to the bottom of it.

If you:
- purge all deluge packages (i.e. rm -R /var/lib/deluged)
- reinstall all the packages
- then patch the log.py as mentioned previously

It then seems to be in a working state, so I think:

A: The Debian upgrade leaves some incompatible configuration/ssl stuff?
B: Deluge 2.0.3 is broken under python 3.9

It does look like there's a change upstream that's not released yet 
which

fixes it judging by the fact this line is different:
https://git.deluge-torrent.org/deluge/tree/deluge/log.py?h=develop#n91

-Rob

Bug#884956:

[dodo christoph]

Hallo guten Abend, ich habe Ihnen gestern eine E-Mail geschickt, aber keine
Antwort, bitte rufen Sie mich an oder antworten Sie dringend

Bug#993083: Confirmation and journal

[Rob]

Hello,

I can confirm this is happening as well, the journal output is slightly 
more informative than the deluged log:


Sep 04 18:32:06 testvm deluged[2132]: Unhandled error in Deferred:
Sep 04 18:32:06 testvm deluged[2132]: Traceback (most recent call last):
Sep 04 18:32:06 testvm deluged[2132]:   File 
"/usr/lib/python3/dist-packages/deluge/core/daemon_entry.py", line 112, 
in run_daemon

Sep 04 18:32:06 testvm deluged[2132]: daemon = Daemon(
Sep 04 18:32:06 testvm deluged[2132]:   File 
"/usr/lib/python3/dist-packages/deluge/core/daemon.py", line 94, in 
__init__
Sep 04 18:32:06 testvm deluged[2132]: log.info('Deluge daemon %s', 
get_version())
Sep 04 18:32:06 testvm deluged[2132]:   File 
"/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1613, 
in unwindGenerator
Sep 04 18:32:06 testvm deluged[2132]: return 
_cancellableInlineCallbacks(gen)
Sep 04 18:32:06 testvm deluged[2132]:   File 
"/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1529, 
in _cancellableInlineCallbacks
Sep 04 18:32:06 testvm deluged[2132]: _inlineCallbacks(None, g, 
status)

Sep 04 18:32:06 testvm deluged[2132]: ---  ---
Sep 04 18:32:06 testvm deluged[2132]:   File 
"/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1418, 
in _inlineCallbacks

Sep 04 18:32:06 testvm deluged[2132]: result = g.send(result)
Sep 04 18:32:06 testvm deluged[2132]:   File 
"/usr/lib/python3/dist-packages/deluge/log.py", line 69, in info
Sep 04 18:32:06 testvm deluged[2132]: yield 
LoggingLoggerClass.info(self, msg, *args, **kwargs)
Sep 04 18:32:06 testvm deluged[2132]:   File 
"/usr/lib/python3.9/logging/__init__.py", line 1442, in info
Sep 04 18:32:06 testvm deluged[2132]: self._log(INFO, msg, args, 
**kwargs)
Sep 04 18:32:06 testvm deluged[2132]:   File 
"/usr/lib/python3.9/logging/__init__.py", line 1573, in _log
Sep 04 18:32:06 testvm deluged[2132]: fn, lno, func, sinfo = 
self.findCaller(stack_info, stacklevel)
Sep 04 18:32:06 testvm deluged[2132]: builtins.TypeError: findCaller() 
takes from 1 to 2 positional arguments but 3 were given
Sep 04 18:32:06 testvm deluged[2132]: Temporarily disabling observer 
LegacyLogObserverWrapper(>) due to 
exception: [Failure instance: Traceback: : 
findCaller() t

akes from 1 to 2 positional arguments but 3 were given
Sep 04 18:32:06 testvm deluged[2132]: 
/usr/lib/python3/dist-packages/pkg_resources/_vendor/pyparsing.py:646:__getattr__
Sep 04 18:32:06 testvm deluged[2132]: 
/usr/lib/python3/dist-packages/twisted/internet/defer.py:962:__del__
Sep 04 18:32:06 testvm deluged[2132]: 
/usr/lib/python3/dist-packages/twisted/logger/_logger.py:190:failure
Sep 04 18:32:06 testvm deluged[2132]: 
/usr/lib/python3/dist-packages/twisted/logger/_logger.py:144:emit

Sep 04 18:32:06 testvm deluged[2132]: ---  ---
Sep 04 18:32:06 testvm deluged[2132]: 
/usr/lib/python3/dist-packages/twisted/logger/_observer.py:131:__call__
Sep 04 18:32:06 testvm deluged[2132]: 
/usr/lib/python3/dist-packages/twisted/logger/_legacy.py:93:__call__
Sep 04 18:32:06 testvm deluged[2132]: 
/usr/lib/python3/dist-packages/deluge/log.py:204:emit
Sep 04 18:32:06 testvm deluged[2132]: 
/usr/lib/python3.9/logging/__init__.py:1489:critical
Sep 04 18:32:06 testvm deluged[2132]: 
/usr/lib/python3.9/logging/__init__.py:1573:_log

Sep 04 18:32:06 testvm deluged[2132]: ]

It seems like it's bumping into something like this: 
https://stackoverflow.com/questions/60859773/flask-logging-error-typeerror-findcaller-takes-from-1-to-2-position-argument.


If you fix that error (i.e. you patch 
/usr/lib/python3/dist-packages/deluge/log.py:89 to be: `def 
findCaller(self, stack_info=False, stackLevel=1):` then that will fix 
the deluged logging which then means that /var/log/deluged/daemon.log 
will be full of actually useful information; that said I think this is 
actually an upstream issue with deluged, rather than a Debian problem.


On this test VM I have here, it looks like the error I get is:
```
9:25:43 [INFO][deluge.configmanager:52  ] Setting config directory 
to: /var/lib/deluged/config
19:25:44 [INFO][deluge.core.daemon:94  ] Deluge daemon 
2.0.3
19:25:44 [INFO][deluge.core.core  :339 ] Successfully 
loaded session.state: /var/lib/deluged/config/session.state
19:25:44 [WARNING ][deluge.core.core  :337 ] Unable to load 
/var/lib/deluged/config/session.state.bak: [Errno 2] No such file or 
directory: '/var/lib/deluged/config/session.state.bak'
19:25:44 [INFO][deluge.core.alertmanager  :148 ] Alert Queue 
Size set to 1
19:25:44 [INFO][deluge.core.rpcserver :402 ] Starting 
DelugeRPC server localhost:58846
19:25:44 [ERROR   ][deluge.core.daemon_entry  :132 ] Unable to start 
deluged: [('SSL routines', 'SSL_CTX_use_certificate', 'ee key too 
small')]

19:25:44 [INFO][deluge.core.daemon_entry  :137 ] Exiting...
```

So presumably there are 2 problems; this one may be a debian issue.

-Rob

Bug#993685: security-tracker: Transition dependencies from cve.mitre.org to cve.org

[Salvatore Bonaccorso]

Package: security-tracker
Severity: important
X-Debbugs-Cc: car...@debian.org

This is the security-tracker specific part of the more general
https://salsa.debian.org/security-team/security.debian.org/-/issues/6
. Starting end of september, and lasting approximately one year,
services from cve.mitre.org will transition to cve.org (including as
well new possiblities for fetching data).

The security-tracker will need changes as soon the details (not yet at
time of writing) are outlined.

Reference: 
https://cve.mitre.org/news/archives/2021/news.html#September022021_CVE_Website_Transitioning_to_New_Web_Address_-_CVE.ORG

Bug#993683: debhelper: dh_missing wrongly reports

[Hideki Yamane]

Package: debhelper
Version: 13.5.1
Severity: normal

Dear Maintainer,

 During build tomoyo-tools package with dh13, it fails with below.

dh_missing: warning: sbin/tomoyo-init exists in debian/tmp but is not installed 
to anywhere (related file: "sbin/tomoyo-init")
dh_missing: error: missing files, aborting

While detecting missing files, dh_missing noted some files with a 
similar name to those
that were missing.  This error /might/ be resolved by replacing 
references to the
missing files with the similarly named ones that dh_missing found - 
assuming the content
is identical.

As an example, you might want to replace:
 * sbin/tomoyo-init
with:
 * sbin/tomoyo-init
in a file in debian/ or as argument to one of the dh_* tools called 
from debian/rules.
(Note it is possible the paths are not used verbatim but instead 
directories
containing or globs matching them are used instead)

Alternatively, add the missing file to debian/not-installed if it 
cannot and should not
be used.

The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libtomoyotools3 (2), tomoyo-tools (22)
 * dh_installdocs: libtomoyotools3 (0), tomoyo-tools (1)
 * dh_installman: libtomoyotools3 (0), tomoyo-tools (19)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.

 However, sbin/tomoyo-init file was installed properly.

# find . -name tomoyo-init -print
./sbin/tomoyo-init
./debian/tomoyo-tools/sbin/tomoyo-init
./debian/tmp/sbin/tomoyo-init

 So I guess it is a bug in debhelper.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 debhelper depends on:
ii  autotools-dev20180224.1+nmu1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.12.0-1
ii  dpkg 1.20.9
ii  dpkg-dev 1.20.9
ii  dwz  0.14-1
ii  file 1:5.39-3
ii  libdebhelper-perl13.5.1
ii  libdpkg-perl 1.20.9
ii  man-db   2.9.4-2
ii  perl 5.32.1-5
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202101

-- no debconf information

Bug#993682: kio: Fix non-linux builds

[Samuel Thibault]

Package: kio
Version: 5.85.0-1
Severity: important
Tags: patch

Hello,

Version 5.85.0-1 of kio added the libmount-dev build-dep, but this is
linux-only. I have attached a patch that disables it on non-linux, thus
fixing the build.

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-debug'), (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

Kernel: Linux 5.14.0 (SMP w/8 CPU threads)
Kernel taint flags: 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

Versions of packages kio depends on:
ii  kded5 5.85.0-2
ii  libacl1   2.3.1-1
ii  libc6 2.31-17
ii  libgcc-s1 11.2.0-3
ii  libgssapi-krb5-2  1.18.3-7
ii  libkf5archive55.85.0-2
ii  libkf5authcore5   5.85.0-2
ii  libkf5codecs5 5.85.0-2
ii  libkf5configcore5 5.85.0-2
ii  libkf5configwidgets5  5.85.0-2
ii  libkf5coreaddons5 5.85.0-2
ii  libkf5dbusaddons5 5.85.0-2
ii  libkf5doctools5   5.85.0-2
ii  libkf5i18n5   5.85.0-2
ii  libkf5itemviews5  5.85.0-2
ii  libkf5kiocore55.83.0-2
ii  libkf5kiogui5 5.83.0-2
ii  libkf5kiontlm55.83.0-2
ii  libkf5kiowidgets5 5.83.0-2
ii  libkf5notifications5  5.85.0-3
ii  libkf5service-bin 5.85.0-2
ii  libkf5service55.85.0-2
ii  libkf5solid5  5.85.0-2
ii  libkf5textwidgets55.85.0-2
ii  libkf5wallet-bin  5.83.0-2
ii  libkf5wallet5 5.83.0-2
ii  libkf5widgetsaddons5  5.85.0-2
ii  libkf5windowsystem5   5.85.0-2
ii  libqt5core5a  5.15.2+dfsg-10
ii  libqt5dbus5   5.15.2+dfsg-10
ii  libqt5gui55.15.2+dfsg-10
ii  libqt5network55.15.2+dfsg-10
ii  libqt5qml55.15.2+dfsg-8
ii  libqt5widgets55.15.2+dfsg-10
ii  libqt5x11extras5  5.15.2-2
ii  libqt5xml55.15.2+dfsg-10
ii  libstdc++611.2.0-3
ii  libxml2   2.9.10+dfsg-6.7
ii  libxslt1.11.1.34-4

kio recommends no packages.

kio suggests no packages.

-- no debconf information

-- 
Samuel
 > Quelqu'un aurait-il une solution pour réinitialiser un MBR
 Si tu veux qu'il soit complètement blanc (pas souhaitable, à mon avis) :
 dd if=/dev/zero of=/dev/hda bs=512 count=1 (sous Linux)
 -+- OT in Guide du linuxien (très) pervers - "Pour les K difficiles" -+-
--- debian/control.original 2021-09-04 17:42:04.0 +
+++ debian/control  2021-09-04 17:42:09.0 +
@@ -34,7 +34,7 @@
libkf5windowsystem-dev (>= 5.85.0~),
libkf5xmlgui-dev (>= 5.85.0~),
libkrb5-dev,
-   libmount-dev,
+   libmount-dev [linux-any],
libqt5sql5-sqlite,
libqt5x11extras5-dev (>= 5.15.0~),
libxml2-dev,

Bug#993681: sphinxcontrib-programoutput: please make the build reproducible

[Simon McVittie]

Source: sphinxcontrib-programoutput
Version: 0.16-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath timezone username usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

sphinxcontrib-programoutput builds non-reproducible documentation. The
documentation contains the current username, the absolute path to grep
(which can vary depending on merged-/usr status or whether a local
/usr/local/bin/grep exists), and the date on the grep executable (which
is presented differently depending on the timezone).

Additionally, a lot of the examples use `python`, which typically doesn't
exist in a build chroot, making them less useful as examples and
introducing the current build path via error messages.

The attached patch avoids these sources of non-reproducibility.

smcv
>From ef6355cb5d4e5376bdd5e24cd38198c0d83ca6ae Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 4 Sep 2021 18:36:14 +0100
Subject: [PATCH] Make the documentation build reproducibly

These patches avoid the username, the absolute path to grep and the
build path leaking into documentation and making it non-reproducible,
as well as making some examples in the documentation more useful.
---
 ...t-variable-less-likely-to-vary-betwe.patch |  38 +++
 ...ell-command-whose-output-is-less-lik.patch |  35 ++
 ...ython3-instead-of-python-in-examples.patch | 107 ++
 debian/patches/series |   3 +
 debian/rules  |   4 +
 5 files changed, 187 insertions(+)
 create mode 100644 debian/patches/doc-Use-an-environment-variable-less-likely-to-vary-betwe.patch
 create mode 100644 debian/patches/doc-Use-an-example-shell-command-whose-output-is-less-lik.patch
 create mode 100644 debian/patches/doc-Use-python3-instead-of-python-in-examples.patch

diff --git a/debian/patches/doc-Use-an-environment-variable-less-likely-to-vary-betwe.patch b/debian/patches/doc-Use-an-environment-variable-less-likely-to-vary-betwe.patch
new file mode 100644
index 000..e4515cc
--- /dev/null
+++ b/debian/patches/doc-Use-an-environment-variable-less-likely-to-vary-betwe.patch
@@ -0,0 +1,38 @@
+From: Simon McVittie 
+Date: Sat, 4 Sep 2021 18:33:37 +0100
+Subject: doc: Use an environment variable less likely to vary between builds
+
+SHELL is less user-specific than USER, and can easily be forced to a
+known value for reproducible builds.
+
+Signed-off-by: Simon McVittie 
+---
+ doc/index.rst | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/doc/index.rst b/doc/index.rst
+index 8175499..7bffe9c 100644
+--- a/doc/index.rst
 b/doc/index.rst
+@@ -114,17 +114,17 @@ Normally the command is splitted according to the POSIX shell syntax (see
+ :py:mod:`shlex`), and executed directly.  Thus special shell features like
+ expansion of environment variables will not work::
+ 
+-   .. command-output:: echo "$USER"
++   .. command-output:: echo "$SHELL"
+ 
+-.. command-output:: echo "$USER"
++.. command-output:: echo "$SHELL"
+ 
+ To enable these features, enable the ``shell`` option.  With this option, the
+ command is literally passed to the system shell::
+ 
+-   .. command-output:: echo "$USER"
++   .. command-output:: echo "$SHELL"
+   :shell:
+ 
+-.. command-output:: echo "$USER"
++.. command-output:: echo "$SHELL"
+:shell:
+ 
+ Other shell features like process expansion consequently work, too::
diff --git a/debian/patches/doc-Use-an-example-shell-command-whose-output-is-less-lik.patch b/debian/patches/doc-Use-an-example-shell-command-whose-output-is-less-lik.patch
new file mode 100644
index 000..9cef3e7
--- /dev/null
+++ b/debian/patches/doc-Use-an-example-shell-command-whose-output-is-less-lik.patch
@@ -0,0 +1,35 @@
+From: Simon McVittie 
+Date: Sat, 4 Sep 2021 18:29:53 +0100
+Subject: doc: Use an example shell command whose output is less likely to
+ vary
+
+The path returned by $(which grep) might change depending on whether
+the system is merged-/usr or whether it has a local /usr/local/bin/grep,
+and the result of running ls can depend on factors such as the time zone.
+
+Using a different command here also helps to illustrate that shell
+syntax such as "&&" is accepted here, and using "command -v" avoids
+deprecation warnings from debianutils which(1).
+
+Signed-off-by: Simon McVittie 
+---
+ doc/index.rst | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/doc/index.rst b/doc/index.rst
+index 6b5a0cc..8175499 100644
+--- a/doc/index.rst
 b/doc/index.rst
+@@ -129,10 +129,10 @@ command is literally passed to the system shell::
+ 
+ Other shell features like process expansion consequently work, too::
+ 
+-   .. command-output:: ls -l $(which grep)
++   .. command-output:: test -x $(command -v grep) && echo yes
+   :shell:
+ 
+-.. command-output:: ls -l $(which grep)
++.. command-output:: test -x $(command -v grep) && echo yes
+:shell:
+ 
+ Remember to use ``shell`` 

Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye

[Steve McIntyre]

Hey Luca!

On Fri, Sep 03, 2021 at 03:50:52PM -0700, Don Armstrong wrote:
>Control: reassign -1 linux-signed-arm64
>Control: found -1 5.10.46+4, 5.10.46+4~bpo10+1
>Control: tag -1 moreinfo
>Control: severity -1 important
>
>
>On Fri, 03 Sep 2021, Luca Di Stefano wrote:
>> A few days ago I tried to upgrade one of the six Socionext SynQuacers
>> that we have to the latest Debian release.
>> 
>> It was running fine on Buster using the 4.19 kernel and had no previous 
>> issues.
>
>[...]
>
>> The next boot sequence would start and get to the point where it would
>> look for the rootfs without finding it and going into initramfs
>> 
>> I've then proceeded to reinstall buster on that machine and it just
>> worked fine, then also tried installing the kernel from backports
>> linux- image-5.10.0-0.bpo.8-arm64 and after reboot it caused the same
>> problem not finding the rootfs and going into initramfs.
>
>I'm not familiar with the hardware of this particular device, but I
>suspect that some necessary driver was (likely inadvertently) excluded
>from the configuration of the 5.10 kernel, but included in 4.19.
>
>Looking at the output from the boot of both kernels should give you an
>idea of what module/device is broken, and providing that to this bug
>will give one of the maintainers of the arm64 kernel a chance of helping
>fix the issue.

I have a synquacer here still and I'll take a look. I noticed on
bullseye release day that USB stuff didn't seem to work in the
installer on the synquacer either. Maybe there's been a regression in
config. :-/

I'll take a look...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Bug#993680: transition: proj

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
Control: forwarded -1 https://release.debian.org/transitions/html/auto-proj.html
Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 983345

For the Debian GIS team I'd like to transition to PROJ 8.

This release drops the deprecated proj_api.h for which not all rdeps have been 
updated yet.

Several got updated with support for proj.h since the 8.0.0 release in February 
however.


Transition: proj

 libproj19 (7.2.1-1) -> libproj22 (8.1.1-1~exp1)

The status of the most recent rebuilds is as follows.

 atlas-ecmwf (0.26.0-1) OK
 gammaray(2.11.2-2) OK
 libgeotiff  (1.7.0-2)  OK
 mshr(2019.2.0~git20200924.c27eb18+dfsg1-5) OK
 octave-octproj  (2.0.1-4)  OK
 osm2pgsql   (1.5.1+ds-1)   OK
 pdl (1:2.057-3)OK
 proj-rdnap  (2008+2018-5)  OK
 python-cartopy  (0.19.0+dfsg-2)FTBFS
   (#983222)
 python-pyproj   (3.1.0-1)  OK
 sosi2osm(1.0.0-7)  FTBFS
   (#983224)
 spatialite  (5.0.1-2)  OK
 survex  (1.2.45-1) FTBFS
   (#983229)
 xygrib  (1.2.6-2)  FTBFS
   (#983230)

 gdal(3.2.2+dfsg-3) OK
 gnudatalanguage (1.0.0-4)  OK
 librasterlite2  (1.1.0~beta1-2)OK
 magics++(4.9.0-1)  OK
 spatialite-tools(5.0.1-1)  OK
 xastir  (2.1.6-3)  OK

 cdo (2.0.0~rc5-1)  OK
 mapnik  (3.1.0+ds-1)   OK
 mapserver   (7.6.4-1)  OK
 merkaartor  (0.19.0+ds-2)  OK
 metview (5.13.0-1) OK
 mysql-workbench (8.0.26+dfsg-1)OK
 ncl (6.6.2-7)  FTBFS
   (#983253)
 openorienteering-mapper (0.9.4-2)  FTBFS
   (#983254)
 pdal(2.2.0+ds-1)   OK
 postgis (3.1.3+dfsg-1) OK
 qmapshack   (1.16.0-2) OK
 r-cran-rgdal(1.5-23+dfsg-1)OK
 r-cran-sf   (0.9-7+dfsg-5) OK
 saga(7.3.0+dfsg-5) OK
 spatialite-gui  (2.1.0~beta1-1)OK
 sumo(1.8.0+dfsg2-5)OK
 vtk7(7.1.1+dfsg2-10)   OK
 vtk9(9.0.1+dfsg1-8)FTBFS
   (#983299)

 freecad (0.19.1+dfsg1-2)   OK
 grass   (7.8.5-2)  OK
 r-cran-lwgeom   (0.2-5-2)  OK
 therion (5.5.7ds1-2)   FTBFS
   (#983345)

 qgis(3.16.10+dfsg-1)   OK


Kind Regards,

Bas

Bug#993679: [init-system-helpers] Upgrading from Jessie to Bullseye fails

[Roman Mamedov]

Package: init-system-helpers
Version: 1.60
Severity: normal

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  libcwidget3 libsigc++-2.0-0c2a
The following NEW packages will be installed:
  bsdextrautils dirmngr gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client 
gpg-wks-server gpgconf gpgsm libapparmor1 libapt-pkg6.0
  libassuan0 libboost-iostreams1.74.0 libbpf0 libcap2-bin libcwidget4 
libdns-export1110 libelf1 libfastjson4 libip4tc2 libip6tc2
  libisc-export1105 libksba8 liblognorm5 liblz4-1 libmd0 libmnl0 libncurses6 
libncursesw6 libnetfilter-conntrack3 libnftnl11 libnpth0
  libprocps8 libreadline8 libseccomp2 libsigc++-2.0-0v5 libtinfo6 libuchardet0 
libutempter0 libxapian30 libxtables12 libxxhash0 libzstd1
  ncal pinentry-curses
The following packages will be upgraded:
  apt apt-utils aptitude aptitude-common base-files base-passwd bash 
bsdmainutils bsdutils ca-certificates coreutils cpio cpufrequtils
  cron dash dbus debian-archive-keyring deborphan debsums dialog diffutils dpkg 
eatmydata ethtool findutils gettext-base gnupg gpgv grep
  groff-base gzip hostapd hostname ifupdown info init init-system-helpers 
initscripts insserv install-info iperf iproute2 iptables
  iputils-ping iputils-tracepath isc-dhcp-client isc-dhcp-common kmod 
krb5-locales less libacl1 libattr1 libbsd0 libcap2 libcpufreq0
  libdbus-1-3 libdebconfclient0 libdpkg-perl libeatmydata1 libedit2 libestr0 
libexpat1 libgnutls-openssl27 libidn11 libiw30 libkmod2
  liblzo2-2 libmount1 libncurses5 libncursesw5 libnewt0.52 libnfnetlink0 
libnl-3-200 libnl-genl-3-200 libnl-route-3-200 libopts25 libpcre3
  libpcsclite1 libpipeline1 libpopt0 libsasl2-modules libslang2 libsmartcols1 
libsqlite3-0 libss2 libstdc++6 libsystemd0 libtimedate-perl
  libtinfo5 libudev1 libusb-0.1-4 libusb-1.0-0 libustr-1.0-1 libuuid1 libwrap0 
libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 libxext6
  libxmuu1 login logrotate lzop man-db manpages mawk mount mtr-tiny nano 
ncurses-base ncurses-bin ncurses-term net-tools netbase
  netcat-traditional ntp ntpdate openssl procps readline-common rsyslog screen 
sed smartmontools ssh startpar sysv-rc sysvinit-core
  sysvinit-utils tasksel tasksel-data tcpd time traceroute tzdata ucf udev 
usbutils util-linux vlan wget whiptail wireless-tools
  wpasupplicant xauth xz-utils
148 upgraded, 46 newly installed, 2 to remove and 0 not upgraded.
Need to get 0 B/57.8 MB of archives.
After this operation, 44.2 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 17942 files and directories currently installed.)
Preparing to unpack .../init-system-helpers_1.60_all.deb ...
Unpacking init-system-helpers (1.60) over (1.22) ...
dpkg: error processing archive 
/var/cache/apt/archives/init-system-helpers_1.60_all.deb (--unpack):
 trying to overwrite '/usr/sbin/invoke-rc.d', which is also in package sysv-rc 
2.88dsf-59
Errors were encountered while processing:
 /var/cache/apt/archives/init-system-helpers_1.60_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- 
With respect,
Roman

Bug#993678: Fails to produce PDF output when using scale.by.width - produces broken lstlisting/lstcode options

[Daniel Leidert]

Package: dblatex
Version: 0.3.12py3-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

While building a PDF we stumbled upon an issue. Some of our XML files contain
screen elements with non UTF-8 characters. When we enable scaling for listing
elements:

scale.by.width

dblatex fails. The produced .tex files then contain line such as:

\begin{lstcode}[escapeinside={<:}{:>}][scale=false,firstnumber=1,escapeinside={}{},moredelim={**[is][\bfseries]{}{}},moredelim={**[is][\itshape]{}{}},]

and those lead to a failure. The problem seems to be code in

/usr/lib/python3/dist-packages/dbtexmf/dblatex/rawverb.py

which fails to detect existing options (added via
/usr/share/xml/docbook/stylesheet/dblatex/xsl/verbatim.xsl already). Thus
dblatex adds another set of options. The same happens without using
scale.by.width, but the resulting lstlisting elements just produce a warning,
that the second set of options gets dropped.

There are several issues I was able to locate. In parse_begin()

if line[0] == b"[":

doesn't seem to work (here they check for existing options). And after fixing
that, the next issue is that

e = line.find(b"]")+1

will fail to produce the desired result because

[scale=false,firstnumber=1,escapeinside={}{},moredelim={**[is][\bfseries]{}{}},moredelim={**[is][\itshape]{}{}},]

contains several closing brackets and we need to find the matching one. Maybe
one could search for ',]'? Not sure if this will break dblatex in other ways.

Next issue then is:

Error: utf_8_encode() argument 2 must be str or None, not bytes

The problem here seems to be in
/usr/lib/python3/dist-packages/dbtexmf/dblatex/rawparse.py and a change in
Python 3 related to string handling.

This problem is a show stopper for us at the moment. Any help is greatly
appreciated.

Attached is a simple testcase. Use it via:

dblatex -d -D -b xetex -p config.xsl test.xml

Regards, Daniel

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

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

Versions of packages dblatex depends on:
ii  docbook-xml   4.5-9
ii  python3   3.9.2-3
ii  python3-apt   2.2.1
ii  texlive   2020.20210202-3
ii  texlive-bibtex-extra  2020.20210202-3
ii  texlive-extra-utils   2020.20210202-3
ii  texlive-latex-extra   2020.20210202-3
ii  texlive-science   2020.20210202-3
ii  xsltproc  1.1.34-4

Versions of packages dblatex recommends:
pn  dblatex-doc
ii  libxml2-utils  2.9.12+dfsg-3

Versions of packages dblatex suggests:
pn  docbook  
ii  evince [pdf-viewer]  40.4-2
ii  fig2dev [transfig]   1:3.2.8b-1
ii  ghostscript  9.53.3~dfsg-7+b1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  inkscape 1.0.2-4
pn  latex-cjk-all
ii  lmodern  2.004.5-6.1
pn  opensp   
pn  texlive-lang-all 
ii  texlive-lang-cyrillic2020.20210202-2
ii  texlive-xetex2020.20210202-3
pn  xindy

- -- no debconf information

- -- debsums errors found:
debsums: changed file 
/usr/lib/python3/dist-packages/dbtexmf/dblatex/rawparse.py (from dblatex 
package)
debsums: changed file /usr/lib/python3/dist-packages/dbtexmf/dblatex/rawverb.py 
(from dblatex package)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmEzrtwACgkQS80FZ8KW
0F2BxQ//WYw7oaVEBsyv3OTulI7w3Ji5UYiE94bRV6CTS1u20KnCk1NSt0OXZFZD
YaIJP0LIphiXctERIH+smTf/8Earn65ypI1WJA5uvBMNPLyV4pJlKIBzHTuCvMLp
OuobH9S5sUdGYkevx8th7zfzsa84S5jgsQlzoigHxM4nQUVXT4VOf3NvEGtC2vsm
qaJx/cyId+Ly8lGZdZfEapmfUr9mSA8B3tQdxSNDDOSZi32VNFgnfF6mYZLHvrTW
kgonjRYA1DrALjTOCd5TmhzC8MaEH2bVKctT6qVGDgBLRRxbmxx05KjhdT4YRJcs
gUZ1QV807Xj9ygnXGTqJGGRMgAGm7HsRn8aeSOpJ51g3UW4xji0oqxjJH5WTnIsX
2es27wntyQJTEo01AmCL5I3KQ7zc9EN8Se64HDTTqVaIrQEoak4V+8e5SI8ydNB2
y11nGmEhmU2ELA8x5ZH5NwgbvBg5zEsMAExy09SjgN3PtIi8xh2fCQ4GAnaXARKc
01kLcKPN/O2X6t+J9ZyezktOPXygVIjlDn4M6AmrQpjvHvzqwxHrOPpwgWEhvb7O
0TljZybgSpfWA78FVAGP7OCS2aDUaPX4YnhFNwjxm0kFyubJMgrsG8vKfLlpWB+Z
C2OAH3ltk0bLeAYT04ckC3Pm0CaBdpsWw8MsZw+49nWTMoW4inI=
=RCP5
-END PGP SIGNATURE-

http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;>


Chapter
Test

Section
Test
$ ls travail/
Ic�nes  �l�ments graphiques  Textes





http://www.w3.org/1999/XSL/Transform;
xmlns:m="http://www.w3.org/1998/Math/MathML;

Bug#993677: debhelper: Add a dh_skeleton examples for boostraping debhelper development

[Bastien Roucariès]

Package: debhelper
Version: 13.5.1
Severity: wishlist

Dear Maintainer,

I will like to get a dh_skeleton in example dir in order to create my own
debhelper

Thanks

Bastien

Bug#993676: prometheus-node-exporter-collectors: btrfs_stats.py doesn't work with Python 3

[Kunal Mehta]

Package: prometheus-node-exporter-collectors
Version: 0+git20210115.7d89f19-1
Severity: normal
Tags: patch

btrfs_stats.py fails with a RuntimeException when run with Python 3
on my bullseye system.

There's a trivial upstream patch for this: 
.

I tested the patch and it does fix the issue for me.

Thanks,
-- Kunal

-- System Information:
Debian Release: 10.10
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.129-1.fc25.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#945861: closed by Guillem Jover (Bug#945861: fixed in inetutils 2:1.9.4-11)

[Guillem Jover]

On Mon, 2020-08-24 at 09:42:23 +0300, Adrian Bunk wrote:
> On Sun, Jan 26, 2020 at 02:51:05AM +, Debian Bug Tracking System wrote:
> >...
> >  inetutils (2:1.9.4-11) unstable; urgency=medium
> >  .
> >* Add patches from upstream:
> >  - telnet: Validate supplied environment variables. CVE-2019-0053.
> >Closes: #945861
> >...
> 
> Using [1] I am getting in unstable:
> 
> # python3 telnet_term_0day.py
> [+] Multiple vendor telnet.c client environment handling PoC (IAC SB 
> TELQUAL_IS)
> [-] connected, corrupting client heap
> [-] done. merry haxmas.
> # 
> 
> $ `perl -e 'print Ax"5"'` inetutils-telnet -l`perl -e 'print "A"x5000'` 
> 127.0.0.1
> Trying 127.0.0.1...
> Connected to 127.0.0.1.
> Escape character is '^]'.
> Segmentation fault (core dumped)
> $ 
> 
> I assume this means the bug is not yet completely fixed?

I've been checking this on and off, but have run out of time to track
it down in the past. A couple of days ago I sat down and traced this
to a recursive loop on one of the error exit codes, which then
proceeds to try to process the remaining input ring buffer, which goes
back to that exit return path. The crash seems to be due to stack
exhaustion, so I don't think this is really related to the original
security issue, but having a local program susceptible to be crashes
by a remote server still gives me uneasiness, and given that I've not
really checked whether it's possible to overwrite buffers controlled
by the remote side or similar, I'm not going to really contest whether
this is really a security issue too.

In any case I prepared a tentative patch fixing the issue (with the
suspicion is was not entirely correct, given the protocol and code
flow) and proposed it to Simon Josefsson, who subsequently found an
existing fix in NetBSD, which got merged now upstream. So I'll upload
a new release today including that.

Thanks,
Guillem

Bug#956718: Register intetutils-foo commands as foo in architectures where net-tools are not available

[Guillem Jover]

Hi!

On Tue, 2020-04-14 at 21:56:41 +0530, Pirate Praveen wrote:
> Package: src:inetutils
> Severity: wishlist
> Version: 2:1.9.4-11

> libnet-dev is not avilable on hurd-i386 and kfreebsd-* architectures
> https://buildd.debian.org/status/package.php?p=dnprogs=sid
> 
> So it'd be nice if commands like inetutls-ifconfig is available as ifconfig
> at least on these architectures.

The reason this is not done and has not been done in the past is
because I don't think the programs provided are command-line
compatible with the ones these would replace, which would cause
potential breakage depending on what the callers expect. And this
applies equally to all architectures.

Implementing this change would require, I think, to:

 * Check command-line and behavior compatibility with replaced tools.
   - Implement what might be missing or expected by callers.
 * Coordinate with replaced package maintainers to switch these to use
   alternatives, and add these as alternatives here.

Thanks,
Guillem

Bug#993675: opensmtpd: stores wrong path to zcat if /usr/bin/zcat or /usr/local/bin/zcat exists

[Simon McVittie]

Source: opensmtpd
Version: 6.8.0p2-3
Severity: important
Tags: patch bookworm sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

If opensmtpd is built on a merged-/usr system (as created by new
installations of Debian >= 10, debootstrap --merged-usr, or installing
the usrmerge package into an existing installation), the path to zcat
is recorded in the binary package as /usr/bin/zcat, rather than the
canonical /bin/zcat.

This can be seen on the reproducible-builds.org infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/opensmtpd.html

If you have sbuild available, an easy way to reproduce this is to build
twice, once with --add-depends=usrmerge and once without.

I suspect the same thing would happen if opensmtpd was built on a system
where /sbin and /usr/sbin had instead been unified via a symlink farm.

The problematic situation is if the package is *built* on a unified-/usr
system, but *used* on a non-unified-/usr system. In this situation,
/usr/bin/zcat exists on the build system but not on the system where
the package will be used, resulting in the features that use this
executable not working correctly.

Similarly, if there is a /usr/local/bin/zcat visible at build-time,
then that path would likely end up hard-coded into the binary,
causing the relevant feature to fail on all systems that do not have
/usr/local/bin/zcat.

Technical Committee resolution #978636 mandates heading towards a
transition to merged-/usr, and variation between merged-/usr and
non-merged-/usr builds is a problem while that transition is taking
place, because it can lead to partial upgrades behaving incorrectly. It
is likely that this class of bugs will become release-critical later in
the bookworm development cycle.

The attached patch resolves this: with it applied, the package builds
identically with and without --add-depends=usrmerge.

Some developers advocate unifying /bin with /usr/bin via a symlink farm
in /bin instead of merged-/usr, but that strategy would have a similar
practical effect on this particular package, and the same solution would
be required.

A side benefit of fixing this is that this change seems likely to be
sufficient to make the package reproducible (as recommended by Policy
§4.15).

smcv
>From 22d9dfcf49de7c577a532fc6f4450efad720d8d6 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 4 Sep 2021 17:57:06 +0100
Subject: [PATCH] d/rules: Specify canonical path to zcat

If opensmtpd is built on a unified-/usr system where both /usr/bin/zcat
and /bin/zcat exist, it will hard-code the former into configuration,
resulting in configuration that will not work correctly when used on
non-unified-/usr systems. Similarly, if there is a local zcat executable
in /usr/local/bin, the path to that local executable would be hard-coded,
resulting in binaries that won't typically work on unmodified Debian
systems.

Forcing the canonical path will make it work on any combination of
unified-/usr and non-unified-/usr build and runtime systems.

Signed-off-by: Simon McVittie 
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 22b77acc..9de18cae 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 override_dh_auto_configure:
 	./bootstrap
 	dh_auto_configure -- \
+	ZCAT=/bin/zcat \
 	--with-auth-pam \
 	--with-group-queue=opensmtpq \
 	--with-mantype=doc \
-- 
2.33.0

Bug#993343: OpenLDAP 2.5 FTBFS on GNU/Hurd: MAXPATHLEN undeclared

[Ryan Tandy]

Hi Joshua,

On Sat, Sep 04, 2021 at 12:10:30PM -0400, Joshua Branson wrote:

This is supposed to be an "easy fix".  I'd be willing to try to work
with you to help you fix this.


Thanks a lot for offering to work on a fix. Actually it was easy enough 
that the upstream developers have already fixed it themselves, so that's 
no longer necessary and the next upload to experimental should build 
fine on Hurd. Appreciate your offer though.

Bug#993646: xorriso-dd-target: unclear in long description if general-purpose

[Thomas Schmitt]

Hi,

the commits 69b1290 and 68e0410 of
  g...@salsa.debian.org:optical-media-team/libisoburn.git
should solve the issue with the next upload.

See for the new state of the description
  
https://salsa.debian.org/optical-media-team/libisoburn/-/raw/68e041060496b0f4804cdee12059df971eec25f2/debian/control


I will ponder about a home page for xorriso-dd-target.
For now it seems more important to get a link to
  https://wiki.debian.org/XorrisoDdTarget
into
  https://www.debian.org/CD/faq/#write-usb
I will ask Steve McIntyre, once the package is in testing and the wiki is
updated to reflect this. (At least i can change the current download link
from libburnia website to a https://sources.debian.org URI.)


Have a nice day :)

Thomas

Bug#942382: A living fork of dstat seems to be available

[Andras Korn]

Package: dstat
Version: 0.7.4-6.1
Followup-For: Bug #942382

Hi,

there seems to be a fork of dstat called dool, with some recent commits 
indicating that it's still being developed:

https://github.com/scottchiefbaker/dool

While unfortunately, #942382 is still present in it, maybe Debian could switch 
to this fork from the archived original dstat codebase?

Best regards,

András

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (350, 'unstable'), (350, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dstat depends on:
ii  python3  3.9.2-3
ii  python3-six  1.16.0-2

dstat recommends no packages.

dstat suggests no packages.

-- no debconf information

-- 
My cold is better this morning; I've been practising all night.

Bug#993670: linux-image-5.10.0-8-686: Screen corruption using radeon kernel driver

[Mikhail Krylov]

Forgot to add that disabling HIMEM also gets rid of that problem. But it
also leaves the system with less that 1G of RAM, which is, of course,
undesirable


signature.asc
Description: PGP signature

Bug#993674: ga: please make the build reproducible

[Simon McVittie]

Source: ga
Version: 5.7.2-2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

libglobalarrays-dev gets different -L paths in the ga-config script,
depending on whether the build happens to have been done on a system
where /usr/lib64 exists.

On Debian systems, /usr/lib64 will normally exist on 64-bit systems that
have merged-/usr (via the usrmerge package or debootstrap --merged-usr),
such as systems that were installed with debian-installer as buster or
later, but will not normally exist on traditional non-merged-/usr systems.

This can be seen on the reproducible-builds.org infra, which uses
non-merged-/usr for "build 1" and merged-/usr for "build 2":
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ga.html

If you have sbuild available, an easy way to reproduce this is to build
for amd64 twice, once with --add-depends=usrmerge and once without.

It is never necessary for Debian packages to use -L/usr/lib or -I/usr/include
explicitly, because Debian's compilers have those directories in their
default search paths. Similarly, it is never necessary for Debian packages
for "lib64" architectures like amd64 to use -L/usr/lib64 explicitly.
This means ga can be made reproducible by not specifying /usr, and instead
relying on the armci library being in the default compiler search path.

Please consider the attached patch. It does not eliminate all the unnecessary
-I/usr/include or -L/usr/lib, only the ones that can be a problem for
reproducible builds, and seems like a net simplification for the package
in general.

The changes that result in the ga-config script when applying the patch
look something like this (quoting from diffoscope output):

│ │ │ ├── ./usr/bin/ga-config
│ │ │ │ @@ -263,30 +263,30 @@
│ │ │ │  dep_libs=`$prefix/bin/armci-config --libs`
│ │ │ │  
│ │ │ │  fi
│ │ │ │  
│ │ │ │  
│ │ │ │  f77="mpif90"
│ │ │ │  cc="mpicc"
│ │ │ │ -cppflags=" -I/usr/include -I/usr/include"
│ │ │ │ -network_cppflags=" -I/usr/include"
│ │ │ │ +cppflags=" -I/usr/include"
│ │ │ │ +network_cppflags=""
│ │ │ │  cflags=""
│ │ │ │  fflags=" -fdefault-integer-8"
│ │ │ │  fint="-fdefault-integer-8"
│ │ │ │  blas_size="4"
│ │ │ │  scalapack_size="4"
│ │ │ │  use_blas="1"
│ │ │ │  use_lapack="1"
│ │ │ │  use_scalapack="1"
│ │ │ │  use_peigs="0"
│ │ │ │  use_elpa="0"
│ │ │ │  use_elpa_2015="0"
│ │ │ │  use_elpa_2016="0"
│ │ │ │ -ldflags=" -L/usr/lib64 -L/usr/lib"
│ │ │ │ -network_ldflags=" -L/usr/lib64"
│ │ │ │ +ldflags=" -L/usr/lib"
│ │ │ │ +network_ldflags=""
│ │ │ │  libs="-lga  -lscalapack-openmpi  -lopenblas  -lopenblas $dep_libs"
│ │ │ │  network_libs=" -larmci"
│ │ │ │  flibs=" -L/usr/lib/gcc/x86_64-linux-gnu/10 
-L/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/10/../../.. -lgfortran -lm -lquadmath"
│ │ │ │  enable_f77_true=""
│ │ │ │  version="5.7.1"
│ │ │ │  
│ │ │ │  if test "x$enable_f77_true" = x; then :

smcv
>From 6dda597e304c0db8172bbcf9df519db24b792413 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 4 Sep 2021 17:05:35 +0100
Subject: [PATCH] d/rules: Don't specify path to armci, for reproducible build

If we build with --with-armci=yes (or equivalently, --with-armci)
instead of --with-armci=/usr, it's assumed to be in the compiler's
default search path, which is always the case on Debian. This avoids
hard-coding unnecessary -L/usr/lib and/or -L/usr/lib64 into ga-config,
which makes the build non-reproducible because it depends on whether
/usr/lib64 happens to exist (which it does on merged-/usr 64-bit
systems, but typically does not on non-merged-/usr).
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 5bb164f..8de9aa8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,7 @@ override_dh_auto_configure:
 		--with-blas4=-lopenblas			\
 		--with-lapack=-lopenblas		\
 		--with-mpi\
-		--with-armci=/usr
+		--with-armci
 
 override_dh_auto_install:
 	dh_auto_install --destdir=$(CURDIR)/debian/tmp
-- 
2.33.0

Bug#993662: lintian: Please warn for source file that have This file was autogenerated or DO NOT EDIT BY HAND

[Bastien ROUCARIES]

control: tag -1 + patch

Le sam. 4 sept. 2021 à 15:27, Chris Lamb  a écrit :
>
> tags 993662 - patch
> thanks
>
> Hi Bastien,
>
> > Doing some code review on mozilla I found this interesting file
> > https://sources.debian.org/src/firefox-
> > esr/78.13.0esr-1/js/src/frontend/BinASTEnum.h/?hl=1#L1
> >
> > // This file was autogenerated by binjs_generate_spidermonkey,
> > // please DO NOT EDIT BY HAND.
>
> Interesting idea. But files with contents such as these aren't a
> problem in themselves. A problem only arises, at least from an
> ftpmaster point of view, when there isn't the corresponding, say,
> binjs_generate_spidermonkey script. (Imagine a long debate about
> "corresponding source code" here; better held elsewhere.)
>
> So, unless I'm missing something, I don't think this is something
> Lintian should warn about, at any severity level.
like other autogenerated a pedantic tag will help here
see for instance here
https://lintian.debian.org/tags/source-contains-prebuilt-javascript-object
or even like
https://lintian.debian.org/tags/very-long-line-length-in-source-file


I agree with your diagnostic, but in fact:
1. best packaging practice is to convince upstream to remove this file
and rebuild from source
2. good packaging pratice is to repack with a +ds suffix, in order to
be robust and rebuild all the time
3. a lintian tag will be a strong remainder to check manually this
file, repack or even add a lintian override thus a documentation why
it is not important for DFSG.

I really prefer to have a tag, ftpmaster is a bottlenet more than
maintainer time, so every little bit piece of documentation and help
is I think welcome here.

A pedantic time is just the right level for this kind of stuff...





>
> > Tags: patch
>
> (I assume this was a mistake, rather than you missing an attachment?
> Feel free to revert if necessary.)
Here
https://salsa.debian.org/lintian/lintian/-/merge_requests/366
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org  chris-lamb.co.uk
>`-

Bug#993673: clazy: please make the build reproducible

[Simon McVittie]

Source: clazy
Version: 1.10-1
Severity: normal
Tags: patch

clazy gets a different build-ID depending on the build path, which appears
to be because CMake links it with a build-path-based RPATH (which is removed
during installation, but not before it has affected the build-ID).

This can be avoided by building with -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
(which will be the default in debhelper compat level 14, but that's still
experimental at the moment) as in the attached patch.

smcv
>From a12b63efc378a914c4f5c9cda6bf01143dbbaaeb Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 4 Sep 2021 16:29:11 +0100
Subject: [PATCH] d/rules: Use -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON for
 reproducible build

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 112892f..59fcf39 100755
--- a/debian/rules
+++ b/debian/rules
@@ -27,7 +27,7 @@ DPKG_ARCHITECTURE = $(shell dpkg --print-architecture)
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- -DCLANGPP_EXECUTABLE="$(CLANGPP)" -DREADLINK_CMD:FILEPATH=/usr/bin/readlink
+	dh_auto_configure -- -DCLANGPP_EXECUTABLE="$(CLANGPP)" -DREADLINK_CMD:FILEPATH=/usr/bin/readlink -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
 
 override_dh_auto_install:
 	dh_auto_install --destdir=debian/clazy
-- 
2.33.0

Bug#993672: ITP: hjson-go -- Hjson for Go

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: hjson-go
  Version : 3.1.0-1
  Upstream Author : Hjson
* URL : https://github.com/hjson/hjson-go
* License : Expat
  Programming Lang: Go
  Description : Hjson for Go

 This package includes the hjson-cli command-line tool as well
 as the Go library for working with HJSON.  HJSON is a derivative
 of JSON designed to be more easily editable by humans.


This package is needed for the packaging of NNCP.

Bug#971734: closed by Markus Koschany (Re: webext-ublock-origin: no longer functional in firefox-esr)

[Christopher Cramer]

On Fri, Sep 03, 2021 at 11:15:08PM +, Debian Bug Tracking System wrote:
> I believe those problems were resolved by a new version of Firefox in the 
> past.
> Personally I can't reproduce them anymore hence I am going to close these bug
> reports now.

You're right, I haven't seen the problem in a while now.

Bug#993671: RFS: gcc-sh-elf/1 [ITP] -- GNU C compiler for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net, nico...@debian.org
Control: block -1 by 985563
Control: block 986778 by -1

Dear mentors,

I am looking for a sponsor for my package "gcc-sh-elf":

 * Package name    : gcc-sh-elf
   Version : 1
 * License : GPL-3+
 * Vcs : 
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf.git
   Section : devel

It builds those binary packages:

  libnewlib-sh-elf-dev - small ISO C standard library for embedded SuperH 
devices
  gcc-sh-elf - GNU C compiler for embedded SuperH devices

To access further information about this package, please visit the
following URL or check out the ITP (#986778):

  https://mentors.debian.net/package/gcc-sh-elf/

Alternatively, one can download the package with dget using this
command, or use gbp to fetch it from the VCS:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_1.dsc

A few remarks are in order about this package:

 * binutils-sh-elf needs to uploaded either in tandem or before this
package, hence the Blocks relationship, because GCC needs Binutils

 * despite the name, this source package builds not just the GNU C
compiler, but it also builds Newlib plus a simulator from the GDB
sources which gets installed as sh-elf-run. A rationale is in
README.source, but basically this avoids bootstrap problems/circular
dependencies and builds the right parts of GCC and Newlib in order, as
well as enable running the GCC test suite, which isn't normally
possible when building a cross compiler.

 * sh-elf-run is a Wine or qemu-user-style program which allows running
the bare metal binaries. Although there's a lot of functionality not
supported without the aid of an operating system, there is some
functionality that is, and this is tested by extensive DEP-8
autopkgtests.

 * The libnewlib-sh-elf-dev package intentionally does not include a
Built-Using relation on the Newlib source package, because the Newlib
binaries are subject to permissive licenses that do not require
distribution of the source (unlike other parts of the GNU toolchain),
and hence it would actually be a violation of Debian Policy to include
the relation.

 * Nicolas has previously told me that my inclusion of the copyright
information for the binaries in the as-installed copyright files is
unnecessary according to the FTP Team for GCC and GDB, but I choose to
conform to a strict reading of Debian Policy that requires distribution
of it anyway, if nothing else as a courtesy to users.

 * The Debian Electronics team has consented to me using their
namespace, but I haven't found a sponsor from them yet, so I'm seeking
outside sponsors as well.

 * This package is going to experimental because that's the only suite
that currently provides newlib-source, but in all respects I believe
this package is suitable for unstable.

 * My primary motivation for this package is to build the carl9170
libre wireless firmware. It's not ready to share yet, but I can attest
that this package is sufficient to build my draft carl9170fw package
and it works fine. I hope that if one don't have hardware to test with
that the autopkgtests can win over a sponsor's confidence in the
package's correctness.

 * The Lintian warning I: override_dh_auto_test-does-not-check-
DEB_BUILD_OPTIONS does not apply to packages using compatibility level
13. There is already a Lintian bug for this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950455


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

Bug#993539: [Pkg-zsh-devel] Bug#993539: "functions/Misc.zwc" isn't compiled from the bundled source files

[Axel Beckert]

Hi Leo,

Leo Gama wrote:
> Oh, I see it now. Maybe I even read this comment, but before understanding
> what was going on, so haven't got my attention.

No problem. :-)

> For the fix, is it possible to edit the 'configure' file that sets the
> 'runhelpdir' variable before compilation?

No need for that, I think. The configure script has an option to set
the runhelpdir variable on the commandline:

  --enable-runhelpdir=DIR the directory in which to install run-help files

Will try that first and see if we can fix the issue that way. Would be
much preferred to patching.

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

Bug#993291: apt upgrade crashes with "Assertion `I->Items->Owner->Status != pkgAcquire::Item::StatIdle' failed" when not all mirrors are reachable

[Marc Haber]

On Wed, Sep 01, 2021 at 10:44:03AM +0200, Marc Haber wrote:
> I can confirm the same issue here:

Looks like a transient issue here, today's apt update just went through.
I cannot reproduce the issue any more.

Greetings
Marc

Bug#993670: linux-image-5.10.0-8-686: Screen corruption using radeon kernel driver

[Krylov Michael]

Package: linux-image-5.10.0-8-686
Version: 5.10.46-4
Severity: important
Tags: patch

Dear maintainer,

After updating from buster to bullseye I've noticed that the image
displayed on my older computer, 32-bit Pentium 4 using ATI Radeon X1950
AGP video card is severely corrupted in the graphical (Xorg and Wayland)
mode: all kinds of black and white stripes across the screen, some
letters missing, etc.

I've checked several options (Xorg drivers, Wayland instead of Xorg and
so on), but the problem persisted. I've managed to find that the problem
was in the kernel, as everything worked well with buster's kernel with
everything else being from bullseye.

I have managed to find the culprit of that corruption, that is the
commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 on the linux kernel.
Reverting this commit and building the kernel with that commit reverted
fixes the problem, and I'm writing this bug report with the kernel I've
built with that commit reverted.

Apparently this problem is somewhat known, as I can tell after googling
for the commit id, see https://lkml.org/lkml/2020/1/9/518 this link for
example.

Mageia distro, for example, reverted this commit in the kernel they are
building: 
http://sophie.zarb.org/distrib/Mageia/7/aarch64/by-pkgid/b9193a4f85192bc57f4d770fb9bb399c/files/32
and I would like to suggest adding the reverting patch (attached) to the
debian kernel as well (at least for 32-bit x86 architecture as 64-bit is
unaffected).

This took me several days to debug, so I hope it will be included in one
of the point releases :)

Thanks in advance!


-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-8-686 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages linux-image-5.10.0-8-686 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-8-686 recommends:
pn  apparmor 
pn  firmware-linux-free  

Versions of packages linux-image-5.10.0-8-686 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
pn  linux-doc-5.10  
>From bff1b53f4ff2afcaeaadacc6e693e3939e025dd4 Mon Sep 17 00:00:00 2001
From: Mikhail Krylov 
Date: Sat, 4 Sep 2021 15:34:02 +0300
Subject: [PATCH] Revert "drm/radeon: handle PCIe root ports with addressing
 limitations"

This reverts commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713.
---
 drivers/gpu/drm/radeon/radeon.h|  1 +
 drivers/gpu/drm/radeon/radeon_device.c | 13 -
 drivers/gpu/drm/radeon/radeon_ttm.c|  2 +-
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index a6d8de01194..15d6de5dfbd 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2391,6 +2391,7 @@ struct radeon_device {
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
boolshutdown;
+   boolneed_dma32;
boolneed_swiotlb;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 266e3cbbd09..f74c74ad8b5 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1363,25 +1363,28 @@ int radeon_device_init(struct radeon_device *rdev,
else
rdev->mc.mc_mask = 0xULL; /* 32 bit MC */
 
-   /* set DMA mask.
+   /* set DMA mask + need_dma32 flags.
 * PCIE - can handle 40-bits.
 * IGP - can handle 40-bits
 * AGP - generally dma32 is safest
 * PCI - dma32 for legacy pci gart, 40 bits on newer asics
 */
-   dma_bits = 40;
+   rdev->need_dma32 = false;
if (rdev->flags & RADEON_IS_AGP)
-   dma_bits = 32;
+   rdev->need_dma32 = true;
if ((rdev->flags & RADEON_IS_PCI) &&
(rdev->family <= CHIP_RS740))
-   dma_bits = 32;
+   rdev->need_dma32 = true;
 #ifdef CONFIG_PPC64
if (rdev->family == CHIP_CEDAR)
-   dma_bits = 32;
+   rdev->need_dma32 = true;
 #endif
 
+   dma_bits = rdev->need_dma32 ? 32 : 40;
r = dma_set_mask_and_coherent(>pdev->dev, DMA_BIT_MASK(dma_bits));
if (r) {
+   rdev->need_dma32 = true;
+   dma_bits = 32;
pr_warn("radeon: No suitable DMA available\n");
return r;
}
diff --git 

Bug#993606: RFP: libnet-sftp-perl -- pure-Perl implementation of the Secure File Transfer Protocol (SFTP)

[Florian Schlichting]

> Net::SFTP is a pure-Perl implementation of the Secure File Transfer
> Protocol (SFTP) - file transfer built on top of the SSH2 protocol.
> Net::SFTP uses Net::SSH::Perl to build a secure, encrypted tunnel
> through which files can be transferred and managed. It provides a subset
> of the commands listed in the SSH File Transfer Protocol IETF draft,
> which can be found at
> http://www.openssh.com/txt/draft-ietf-secsh-filexfer-00.txt.

with regard to Jonas' question, the POD says unter "COMMAND METHODS":

Net::SFTP supports all of the commands listed in the SFTP version 3
protocol specification. Each command is available for execution as a
separate method, with a few exceptions: SSH_FXP_INIT,
SSH_FXP_VERSION, and SSH_FXP_READDIR.


Jonathan, have you looked at Net::SFTP::Foreign, which is already
packaged in Debian, and can you comment why that's not an option for
you? It has a compatibility module for Net::SFTP and it leaves all the
cryptographic and more generally security related tasks to the system's
ssh command. There's a discussion of Net::SFTP::Foreign Vs. Net::SFTP
Vs. Net::SSH2::SFTP in the POD.

Florian

Bug#976697: webext-umatrix: no longer developed upstream, remove or switch to LibreMatrix or?

[Axel Beckert]

Hi,

Paul Wise wrote:
> uMatrix is no longer developed upstream:
> 
>    https://github.com/gorhill/uMatrix
>    
>    This repository has been archived by the owner. It is now read-only.
[…]
> The upstream author has stated they no longer have time for it:
> 
>
> https://github.com/uBlockOrigin/uMatrix-issues/issues/291#issuecomment-694988696
>
>I've archived uMatrix's repo, I can't and won't be spending any more
>time on this project, and neither on all such issues.

Despite this he did two stable release (1.4.2 and 1.4.4) in July 2021
a bunch of beta releases in 2020, February and July 2021:

https://github.com/gorhill/uMatrix/releases
https://chrome.google.com/webstore/detail/empty-title/ogfcmafjalglgifnmanfmnieipoejdcf?ucbcb=1
https://addons.mozilla.org/de/firefox/addon/umatrix/

(And then archived the Github repo again as it seems. *sigh*)

So for me it looks like the author still cares about security issues,
but has no time for other support. Which IMHO would be OK for a Debian
Stable release.

> These are the options for solving this issue:
> 
> uMatrix could be removed in favour of uBlock Origin's advanced mode.

IMHO this is no real solution. It works completely different and is at
least (from an UI/UX aspect) unusable for me. IMHO no alternative.

> uMatrix could be removed and LibreMatrix packaged, I think this is a
> community fork so it should be a drop-in replacement.
> 
>    https://www.librematrix.com/

Seems to have been rather short-lived and is dead and removed already:

  This site can’t be reached
  www.librematrix.com’s server IP address could not be found.

  […]

  ERR_NAME_NOT_RESOLVED

>    https://github.com/LibreMatrix/LibreMatrix

This as well:

  404 This is not the web page you are looking for.

The same counts for the according account:
https://github.com/LibreMatrix

So IMHO continuing with the original source seems (again) the best
solution to me.

I'd also help packaging 1.4.4 (at least), but the packaging is quite
non-standard while no debian/README.source is present. And
amo-changelog throws Python errors, probably needs an update wrt.
python3-urllib:

~/uMatrix/umatrix → make -f debian/rules get-orig-changelog
amo-changelog -p rst umatrix
failed to write debian/upstream/changelog.html: module 'urllib' has no 
attribute 'error'
make: *** [debian/rules:11: get-orig-changelog] Error 1

Also it is unclear to me why the source is the Mozilla XPI while the
package works with both and upstream offers different download files
for Firefox and for Chromium/Chrome. (Then again, I haven't worked on
browser extensions since Mozilla ditched XUL…)

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

Bug#980368: geeqie: Lossless JPEG rotation does not work

[Andreas Ronnquist]

On Mon, 18 Jan 2021 09:42:14 +0100 =?utf-8?Q?=C5=81ukasz_Stelmach?=
 wrote:
> Package: geeqie
> Version: 1:1.4+git20190121-2
> Severity: normal
> 
> Dear Maintainer,
> 
> I want to losslessly rotate a JPEG file. The file is displayed
> properly.
> 
> I choose Edit -> Orientation -> Losslessly rotate JPEG image
> clockwise.
> 
> An error dialog appears saying
> 
> External command failed
> 
> Can't find matching file type. Unable to start external command.
> 
> The image orientation does not change as expected.
> 

Can you reproduce it with an up to date geeqie? There's already 1.6 in
stable now. Please try that version, and report back. It works fine for
me in both stable and unstable.

If the problem is still there, can you provide the image that gives the
problems? Preferably a link to a place where you have uploaded it.

/Andreas Rönnquist
gus...@debian.org

Bug#993539: [Pkg-zsh-devel] Bug#993539: "functions/Misc.zwc" isn't compiled from the bundled source files

[Leo Gama]

[image: image.gif][image: image.gif]Hi, Axel.

Thanks for the prompt response.

Hrm, yes, but this is caused by this sed call in debian/rules:


  # Doesn't this need to go before we zcompile stuff into .zwc files? --
Axel
sed -i -e 's,^local HELPDIR=.*,local
HELPDIR=$${HELPDIR:-/usr/share/zsh/help},;
s,:-more,:-/usr/bin/pager,;' \
debian/zsh-common/usr/share/zsh/functions/Misc/run-help
sed -i -e '1!b;s:^#!.*[ /]zsh:#!/bin/zsh:;s#/usr/local/bin#/usr/bin#;'
\
`find debian/zsh-common/usr/share/zsh/functions -type f`

Oh, I see it now. Maybe I even read this comment, but before understanding
what was going on, so haven't got my attention.

For the fix, is it possible to edit the 'configure' file that sets the
'runhelpdir' variable before compilation? The path is not hardcoded in the
'run-help' source file. Something in the lines of:

sed -i -e "s,/'\$${VERSION}'/,/," configure


or even

sed -i -e 's,/[^/]\+/\(functions\|help\),/\1,' configure



Best,
Leonardo Gama

Em qui., 2 de set. de 2021 às 23:54, Axel Beckert  escreveu:

> Control: retitle -1 zsh: Modifying HELPDIR comes too late, doesn't catch
> .zwc files
> Control: tag -1 + confirmed
>
> Hi Leo,
>
> Leo Gama wrote:
> > Subject: "functions/Misc.zwc" isn't compiled from the bundled source
> files
>
> Sorry, but that's clearly not true: Since zsh_5.8.orig.tar.xz does not
> contain any .zwc file, all .zwc files in the binary packages can't be
> anything else than compiled from the bundled source at package build
> time.
>
> > If I try to call "run-help" at a ZSH prompt, it reports:
> > > $ run-help
> > > There is no list of special help topics available at this time.
>
> Can confirm that, though.
>
> > And trying to use it to see the help text for any built-in command just
> > opens a man page for zsh...
> >
> > Turns out that the default HISTDIR (which is wrong) in the file that
> > contains the bytecode compiled version of "run-help" is different from
> the
> > default in the source code "run-help" file:
> > > $ grep 'HELPDIR:-/' /usr/share/zsh/functions/Misc/run-help
> > > local HELPDIR=${HELPDIR:-/usr/share/zsh/help}
> > > $ strings /usr/share/zsh/functions/Misc.zwc | grep 'HELPDIR:-/'
> > > HELPDIR:-/usr/share/zsh/5.8/help
> > > HELPDIR:-/usr/share/zsh/5.8/help
>
> Hrm, yes, but this is caused by this sed call in debian/rules:
>
>   # Doesn't this need to go before we zcompile stuff into .zwc files? --
> Axel
> sed -i -e 's,^local HELPDIR=.*,local
> HELPDIR=$${HELPDIR:-/usr/share/zsh/help},; s,:-more,:-/usr/bin/pager,;' \
> debian/zsh-common/usr/share/zsh/functions/Misc/run-help
> sed -i -e '1!b;s:^#!.*[
> /]zsh:#!/bin/zsh:;s#/usr/local/bin#/usr/bin#;' \
> `find debian/zsh-common/usr/share/zsh/functions -type f`
>
> Actually your issue is already mentioned in form of the question in
> the comment in front of that rule. Or in other words: Your bug report
> just answered that question with "yes". :-)
>
> Retitling the bug report accordingly.
>
> Regards, Axel
> --
>  ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
> : :' :  |  Debian Developer, ftp.ch.debian.org Admin
> `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
>   `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
>

Bug#992243: buster-pu: package psmisc/23.2-1+deb10u1

[Raphael Hertzog]

Hello,

On Sat, 04 Sep 2021, Adam D. Barratt wrote:
> On Mon, 2021-08-16 at 12:02 +0200, Raphael Hertzog wrote:
> > I would like to update "psmisc" in buster to fix a regression in
> > "killall". The bug https://bugs.debian.org/912748 was never fixed in
> > that release and "killall command-longer-than-15-char" is thus not
> > working at all in buster
> 
> Please go ahead.

Thanks, uploaded.

Cheers,
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com

Bug#993669: konsole: not honoring the -qwindowtitle option

[David Nebauer]

Package: konsole
Version: 4:21.08.1-1
Severity: normal
X-Debbugs-Cc: davidneba...@gmail.com

Dear Maintainer,

Following a package update and reboot, konsole stopped setting the
window title according to the '-qwindowtitle' command-line option.

The konsole title is now actually being set according to the format '%d:
%n' even though the tab title format and remote tab title format for the
default profile is set to '%w'.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 konsole depends on:
ii  kio5.83.0-2
ii  konsole-kpart  4:21.08.1-1
ii  libc6  2.31-17
ii  libkf5configcore5  5.85.0-2
ii  libkf5configwidgets5   5.85.0-2
ii  libkf5coreaddons5  5.85.0-2
ii  libkf5crash5   5.85.0-2
ii  libkf5dbusaddons5  5.85.0-2
ii  libkf5globalaccel-bin  5.85.0-2
ii  libkf5globalaccel5 5.85.0-2
ii  libkf5guiaddons5   5.85.0-2
ii  libkf5i18n55.85.0-2
ii  libkf5kiowidgets5  5.83.0-2
ii  libkf5notifyconfig55.83.0-2
ii  libkf5widgetsaddons5   5.85.0-2
ii  libkf5windowsystem55.85.0-2
ii  libkf5xmlgui5  5.85.0-3
ii  libqt5core5a   5.15.2+dfsg-10
ii  libqt5gui5 5.15.2+dfsg-10
ii  libqt5widgets5 5.15.2+dfsg-10
ii  libstdc++6 11.2.0-3

konsole recommends no packages.

Versions of packages konsole suggests:
pn  lrzsz  

-- no debconf information

Bug#992836: bullseye-pu: package termshark/2.2.0-1+deb11u1

[Stephen Gelman]

On Sep 4, 2021 at 10:10:55 AM, Adam D. Barratt 
wrote:

> Control: tags -1 + confirmed
>
> On Mon, 2021-08-23 at 23:16 -0500, Stephen Gelman wrote:
>
> Themes were inadvertently not built into the termshark package,
>
> causing the UI to fail to render. This was reported upstream at
>
> https://github.com/gcla/termshark/issues/114, then reported to Debian
>
> in #992831. This is a regression, and also makes the package
>
> generally unusable.
>
>
>
> Please go ahead.
>
> Regards,
>
> Adam
>

Uploaded. Thanks!

Stephen

Bug#355482: debhelper: Standard way to restart services on library upgrade.

[Niels Thykier]

Control: tags -1 wontfix

On Sun, 5 Mar 2006 23:02:07 +0100 Kurt Roeckx  wrote:
> Package: debhelper
> Severity: wishlist
> 
> Hi,
> 
> Some libraries want to restart a list of services when the
> library gets upgraded.  I currently know of only 2 such libraries
> that have code for it: libc6 and libssl0.9.8.
> 
> They both have a simular postinst script, but they also have
> differences.
> 
> For instance, libc6 has a workaround for exim4 that libssl0.9.8
> is missing, and probably should also have.  And that is my
> biggest problem.
> 
> libc6 doesn't use debconf, libssl0.9.8 does, but probably not as
> it should.  But maybe libc6 can't used debconf?
> 
> There are other problems with it like neither of them is using
> invoke-rc.d, as they probably should be doing.
> 
> I'm looking for a more standard way to restart services,
> so I don't have worry about all those special cases.  I was
> wondering if a debhelper script could help with part of this.
> 
> 
> Kurt
> 
> 
> 

Hi,

A script of that complexity would have to rely on a package providing a
script to the do the "heavy lifting".  Notably, fixing bugs in the
debhelper provided snippets requires rebuilding of all affected
packages.  This also why debhelper's autoscripts are generally as short
and simple as entirely possible.

If a package were to provide this feature, providing glue scripts in
debhelper is feasible.  Though if we are going to add that glue code in
debhelper, then we should have a number of packages where this make
sense - I feel that 2 is a bit too low for that.

For now, I am tagging this wontfix.  However, I am open to reconsidering
when there is a packaging a "restart service" script that we rely on and
if we can find more consumers of this feature.

Thanks,
~Niels

Bug#993664: Does not contain LLVMgold.so

[Sylvestre Ledru]

Le 04/09/2021 à 15:02, Yuri D'Elia a écrit :
> Package: llvm-12-linker-tools
> Version: 1:12.0.1-7
> Severity: important
>
> Got this error while linking:
>
> /usr/bin/ld: /usr/lib/llvm-12/bin/../lib/LLVMgold.so: error loading plugin: 
> /usr/lib/llvm-12/bin/../lib/LLVMgold.so: cannot open shared object file: No 
> such file or directory
>
> The current package of llvm-12-linker-tools does not seem to include
> LLVMgold.so (only LLVMPolly/libLTO)
>
> Is this expected?

No, it is my bad. I already fixed it in the repo!

Cheers

S

Bug#991393: debhelper should probably prevent zero mtime in packages

[Niels Thykier]

Control: tags -1 wontfix

Andrej Shadura:
> Source: debhelper
> Severity: wishlist
> 
> Hi,
> 
> As a maintainer and the upstream of inputplug, I ran into this conflict
> between what cargo produces and what the Debian archive expects: since
> [1], cargo publish resets mtime of all files to 0. On the contrary, if
> any of those files leak into .debs, they will be REJECTed by the
> archive [2]. While arguably this is something cargo should not do or my
> d/rules should have fixed, it would be great if debhelper could fix that
> for me.
> 
> [1]: https://github.com/rust-lang/cargo/pull/8864
> [2]: https://bugs.debian.org/991369
> 
> 

Hi,

Thanks for the report.

Given this allegedly "only" affects cargo related packages, I think this
 work around would fit better in the dh-cargo related tooling rather
than being imposed on all debhelper using packages.

~Niels

Bug#993552: RFS: proton-caller/2.3.2-1 [ITP] -- Run any Windows program through Proton

[Niels Thykier]

BenTheTechGuy:
>> [...]
>>   debian/rules is missing a lot of functionality: mandatory targets like
>>   {build,binary}-arch; passing build flags, handling cross builds, etc.
>>   All of this would be much better done with dh (like the vast majority
>>   of packages in Debian do) -- it does know how to use cargo, etc.
>>   Likewise, there's no need to run install by hand.
> 
> I can't get it to work without manually telling dh_build to run cargo.
> If someone can point me in the right direction of how to format my
> debian/rules to build with cargo then put binaries, config files, and
> such in the right place (there is nothing about that in Cargo.toml)
> that would be very helpful.
> 
> Thank you so much Adam for helping me get some things straightened
> out, the latest upload
> https://mentors.debian.net/debian/pool/main/p/proton-caller/proton-caller_2.3.2-2.dsc
> fixes all the problems you pointed out!
> 

Indeed, the core debhelper tool stack does *not* support cargo out of
the box.  There is a `dh-cargo` add-on that may (or may not) be helpful.

>From a quick look, it should be a better of "Build-Depends: dh-cargo"
and then passing --buildsystem=cargo to dh (or to each of the dh_auto_*
tools).  But I have never used it and I could not spot any obvious
"getting started" documentation for it.

I hope that was useful as a "drive-by remark".

~Niels

Bug#993035: bullseye-pu: package sabnzbdplus/3.1.1+dfsg-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-08-26 at 17:38 +0200, Jeroen Ploemen wrote:
> The sabnzbdplus package has a security vulnerability, allowing a
> directory escape in the renamer() function through malicious par2
> files.
> 
> An attacker can create new files anywhere the privileges of the
> sabnzbdplus process permit, but not overwrite or delete existing
> files.
> 

Please go ahead.

Regards,

Adam

Bug#992956: bullseye-pu: package modsecurity-crs/3.3.0-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-08-25 at 16:55 +0200, Alberto Gonzalez Iniesta wrote:
> This [1] security bug was found in modsecurity-crs.
> As stated in #992863 by the security team, a DSA won't be issued
> (security team on Cc:) so I'm targeting bullseye proposed updates
> instead.
> 

>From reading #992863 and checking the Security Tracker, it appears that
the issue is already fixed in unstable. However, that fact is not
reflected in the BTS. Assuming that I haven't missed anything, please
add an appropriate fixed version to #992863 and go ahead.

Regards,

Adam

Bug#965947: lintian: uses-dpkg-database-directly no longer detected for python3-reportbug

[Nis Martensen]

> Until recently lintian emitted a warning that python3-reportbug uses the dpkg
> database directly. The corresponding code in the reportbug source package has
> not changed, but the warning is gone. Does this mean that the warning was a
> false positive in the first place? Or is the lack of warning now a false
> negative?

The lack of warning is a false negative.

In lib/Lintian/Index/Item.pm, `mentions_in_operation` uses `is_script`
to decide whether to check the file content of non-binary files. Only
the main reportbug and querybts python scripts are identified as
scripts. The content of the python module files is not checked.

Should all .py files be considered scripts? The issue probably affects
other scripting languages as well.

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Nader Nooryani]

Package: task-gnome-desktop
Version: 3.68

As of Debian 11, Print Server is no longer included as an option in the
Debian installer if you use the defaults: Debian desktop environment, GNOME
and standard system utilities.  Ref:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950553

This leaves the user without CUPS after a default install.  This should
perhaps be included in task-gnome-desktop

Suggestion: It may be wise to include CUPS in task-gnome-desktop or
somewhere else, since there are no instructions informing the user how they
can enable support for printing.

I am using Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03)
x86_64 GNU/Linux

Bug#992843: bullseye-pu: package apr/1.7.0-6+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-08-24 at 09:25 +0200, Yadd wrote:
> An out-of-bounds array read in the apr_time_exp*() functions was
> fixed in the Apache Portable Runtime 1.6.3 release (CVE-2017-12613).
> The fix for this issue was not carried forward to the APR 1.7.x
> branch, and hence version 1.7.0 regressed compared to 1.6.3 and is
> vulnerable to the same issue.
> 

Please go ahead.

Regards,

Adam

Bug#992836: bullseye-pu: package termshark/2.2.0-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2021-08-23 at 23:16 -0500, Stephen Gelman wrote:
> Themes were inadvertently not built into the termshark package,
> causing the UI to fail to render. This was reported upstream at
> https://github.com/gcla/termshark/issues/114, then reported to Debian
> in #992831. This is a regression, and also makes the package
> generally unusable.
> 

Please go ahead.

Regards,

Adam

Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Sun, 2021-08-22 at 14:58 +0200, Aurelien Jarno wrote:
> During the upgrade from Buster to Bullseye, the SSH server is not
> restarted following the libc6 upgrade, causing new SSH connections to
> get rejected until the SSH server is restarted later in the upgrade.
> 
> It could be considered as a regression as it didn't happen during the
> upgrade from Stretch to Buster.
> 
> [ Impact ]
> Upgrade might fail or get stuck for remote upgrade using SSH if for
> some reason the SSH connection breaks. Using screen or tmux doesn't
> help here as it is not possible to connect again using SSH.
[...]
> The change consist in updating the regex getting the list of services
> in the "installed" state, to  also consider openssh-server in
> 'unpacked' state.

+glibc (2.31-13+deb11u1) unstable; urgency=medium

The distribution there should be "bullseye".

I realise that the changes don't affect the udeb, but for completeness
this wants a kibi-ack; CCed and tagging appropriately. Please feel free
to go ahead on that basis.

Regards,

Adam

Bug#993276: krb5 1.18.3-6+deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: krb5
Version: 1.18.3-6+deb11u1

Explanation: fix KDC null dereference crash on FAST request with no server 
field [CVE-2021-37750]; fix memory leak in krb5_gss_inquire_cred

Bug#992206: bullseye-pu: package ruby-rqrcode-rails3/0.1.7-1.1

[Pirate Praveen]

Control: tags -1 -moreinfo

2021, സെപ്റ്റംബർ 4 3:24:42 PM IST, Jonathan Wiltshire ൽ എഴുതി
>Control: tag -1 confirmed moreinfo
>
>On Mon, Aug 16, 2021 at 01:02:42AM +0530, Pirate Praveen wrote:
>> This rc bug was detected very late in freeze so it could not get into
>> bullseye.
>> 
>> [ Reason ]
>> This package was broken with ruby-rqrcode 1.0 update. See #992040
>
>Please go ahead, and remove this bug's moreinfo tag when uploaded.

Uploaded and tag removed. Thanks!

>Thanks,
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#992243: buster-pu: package psmisc/23.2-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2021-08-16 at 12:02 +0200, Raphael Hertzog wrote:
> I would like to update "psmisc" in buster to fix a regression in
> "killall". The bug https://bugs.debian.org/912748 was never fixed in
> that release and "killall command-longer-than-15-char" is thus not
> working at all in buster
> 

Please go ahead.

Regards,

Adam