Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1

[Salvatore Bonaccorso]

Hi Shengjing,

On Sat, Dec 04, 2021 at 01:12:04AM +0800, Shengjing Zhu wrote:
> On Sat, Dec 4, 2021 at 12:30 AM Julien Cristau  wrote:
> >
> > On Sat, Dec 04, 2021 at 12:28:27AM +0800, Shengjing Zhu wrote:
> > > On Fri, Dec 03, 2021 at 04:32:16PM +0100, Julien Cristau wrote:
> > > > Control: tag -1 confirmed
> > > >
> > > > On Sat, Sep 11, 2021 at 06:04:13PM +0800, Shengjing Zhu wrote:
> > > > > +golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
> > > >
> > > > This looks fine to me, go ahead.
> > >
> > > Thanks for the review. I'm not sure if it's too late to amend this
> > > update.
> > >
> > Might be best to go with the original one first, and file a new bug for
> > the new changes, because I don't know when I can get to reviewing more.
> >
> 
> Uploaded with the original one.

Given the upload and the window closing next weekend for bullseye
point release might be worth doing a ~deb11u2 including now those two
patches as well so we can cover the other CVEs for golang-1.15.

Thanks for your work on this update!

Regards,
Salvatore

Bug#978500: Version 4 ships a gemspec file

[Daniel Leidert]

In Version 4 there is a gemspec file.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#931965: squashfs-tools-ng: new package is available

[GCS]

Control: fixed -1 squashfs-tools-ng/0.5-1

On Sat, Dec 4, 2021 at 8:31 AM László Böszörményi (GCS)  wrote:
> Control: fixed -1 src:squashfs-tools-ng/0.5-1
 Sure, source doesn't have a dash Debian version.

Bug#1000339: r-cran-raster breaks r-cran-satellite autopkgtest: unable to find an inherited method for function 'extend'

[Andreas Tille]

Hi Robert,

thanks a lot for your analysis.

Am Fri, Dec 03, 2021 at 03:36:40PM -0800 schrieb Robert J. Hijmans:
> Andreas,
> 
> The background of this problem is the change in dependency between "raster"
> and "terra". "terra" was dependent on "raster"; now it is the other way
> around. This change was made in terra 1.4-07, 1.4-09 and 1.4-11 that were
> released between 2021-10-05 and 2021-10-11, and in raster 3.5-2
> (2021-10-11).
> 
> In the attachment I show the behavior of  `library(satellite)` with the
> raster package prior to 2021-10-11, with the current versions, and for
> possible intermediate steps. It shows that you can get the warnings you see
> if you have current versions of terra/raster but an old version of
> satellite.
> 
> From what I can tell from this log:
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-satellite/16823806/log.gz
> you are using satellite_1.0.4 and raster_3.5-2 (current versions), and
> terra_1.4-11 (the current version is 1.4-22; but 1.4-11 should be OK).
> 
> Is it possible that your session is actually loading satellite_1.0.2?

I do not think so since you see:

Get:1 http://deb.debian.org/debian testing/main r-cran-satellite 1.0.4-1 (dsc) 
[2,198 B]

so this is the version that is testet.

Kind regards

 Andreas.
 
> On Tue, Nov 30, 2021 at 12:48 AM Andreas Tille  wrote:
> 
> > Control: forwarded -1 Robert J. Hijmans , Florian
> > Detsch 
> > Control: tags -1 upstream
> > Control: tags -1 help
> >
> > Hi Robert and Florian,
> >
> > I'm contacting you as the maintainers or raster and satellite.  As you
> > can see below in the Debian packaged versions of these packages some
> > conflict was raised in the test of satellite after the latest version of
> > raster was uploaded.
> >
> > I'm perfectly aware that the packages are tested on CRAN and thus I
> > assume that possibly some special circumstances in the Debian packaged
> > version might lead to the issue that is reported in the bug below.  I
> > wonder whether you can give some hints how to solve the conflict in the
> > test (at the very end of this mail).
> >
> > Thanks a lot for your help
> >
> >   Andreas.
> >
> > Am Sun, Nov 21, 2021 at 09:24:52PM +0100 schrieb Paul Gevers:
> > > Source: r-cran-raster, r-cran-satellite
> > > Control: found -1 r-cran-raster/3.5-2-1
> > > Control: found -1 r-cran-satellite/1.0.4-1
> > > Severity: serious
> > > Tags: sid bookworm
> > > X-Debbugs-CC: debian...@lists.debian.org
> > > User: debian...@lists.debian.org
> > > Usertags: breaks needs-update
> > >
> > > Dear maintainer(s),
> > >
> > > With a recent upload of r-cran-raster the autopkgtest of r-cran-satellite
> > > fails in testing when that autopkgtest is run with the binary packages of
> > > r-cran-raster from unstable. It passes when run with only packages from
> > > testing. In tabular form:
> > >
> > >passfail
> > > r-cran-raster  from testing3.5-2-1
> > > r-cran-satellite   from testing1.0.4-1
> > > all others from testingfrom testing
> > >
> > > I copied some of the output at the bottom of this report.
> > >
> > > Currently this regression is blocking the migration of r-cran-raster to
> > > testing [1]. Due to the nature of this issue, I filed this bug report
> > > against both packages. Can you please investigate the situation and
> > reassign
> > > the bug to the right package?
> > >
> > > 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=r-cran-raster
> > >
> > >
> > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-satellite/16823806/log.gz
> > >
> > > BEGIN TEST testthat.R
> > >
> > > R version 4.1.2 (2021-11-01) -- "Bird Hippie"
> > > Copyright (C) 2021 The R Foundation for Statistical Computing
> > > Platform: x86_64-pc-linux-gnu (64-bit)
> > >
> > > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > > You are welcome to redistribute it under certain conditions.
> > > Type 'license()' or 'licence()' for distribution details.
> > >
> > > R is a collaborative project with many contributors.
> > > Type 'contributors()' for more information and
> > > 'citation()' on how to cite R or R packages in publications.
> > >
> > > Type 'demo()' for some demos, 'help()' for on-line help, or
> > > 'help.start()' for an HTML browser interface to help.
> > > Type 'q()' to quit R.
> > >
> > > > library(testthat)
> > > > library(satellite)
> > > Loading required package: raster
> > > Loading required package: sp
> > > code for methods in class "Rcpp_SpatCategories" was not checked for
> > > suspicious field assignments (recommended package 'codetools' not
> > > available?)
> > > code for methods in class "Rcpp_SpatCategories" was not checked for
> > > suspicious field assignments (recommended package 'codetools' not
> > > 

Bug#931965: squashfs-tools-ng: new package is available

[GCS]

Control: reassign -1 src:squashfs-tools-ng
Control: fixed -1 src:squashfs-tools-ng/0.5-1

On Mon, Jul 22, 2019 at 8:21 AM David Oberhollenzer
 wrote:
> In short, if people want it, I would also recommend adding it as a
> new, different package.
 Yup, it's been packaged since then and in the archives as its own package.

Cheers,
Laszlo/GCS

Bug#997363: libtorrent-rasterbar: FTBFS: configure: error: *** A compiler with support for C++17 language features is required.

[Petter Reinholdtsen]

Control: tags -1 + patch

[Stefano Rivera]
> Presumably resolved in 2.0.0 in NEW, that doesn't use autoconf any more.

Perhaps, but as NEW processing these days take a long time, as a user of
the library I would prefer a fix for 1.2.14-1 in the mean time.

The easiest fix seem to be to bypass the c++ standard detector which
fail in configure.ac, causing the problematic test for C++17, while both
C++11 and C++14 would work, by adding --with-cxx-standard=14 like this:

--- rules.orig  2021-12-04 07:42:25.578757615 +0100
+++ rules   2021-12-04 07:37:18.662074573 +0100
@@ -13,7 +13,8 @@
 PYTHON3=$(shell py3versions -vr)
 ALLPY=$(PYTHON3)
 
-CONFIGURE_ARGS = --with-libiconv 
--with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
+CONFIGURE_ARGS = --with-libiconv 
--with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
+  --with-cxx-standard=14
 
 %:
dh $@ --with python3

It would also help a lot if the next upload is a source only upload.
-- 
Happy hacking
Petter Reinholdtsen

Bug#903373: "not a valid UTF-8 string" errors creating compose table in en_IN locale

[Avinash Sonawane]

I'm getting these exact errors on weston.

```
$ weston
...
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:39:34:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:40:29:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:41:29:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:42:29:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:43:29:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:44:27:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:45:27:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:46:27:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:47:27:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:48:29:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:49:29:
string literal is not a valid UTF-8 string
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:49:29: too many errors
xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:49:29:
failed to parse file
could not create XKB compose table for locale 'en_IN'.  Disabiling compose
```

Thanks!

Bug#999769: bullseye-pu: package calibre/5.12.0+dfsg-1

[yokota]

> If it is, then unstable needs to be fixed first. If not, then please
> add an appropriate fixed version to that bug, so that the situation is
> clearer.

Thanks, I add fixed version info to bug #998744 .

--
YOKOTA Hiroshi

Bug#1000458: bullseye-pu: package wget/1.21-1+deb11u1

[Cyril Brulebois]

Adam D. Barratt  (2021-12-03):
> This looks OK to me, but will need a di-ack, as wget builds a udeb.
> Tagging and CCing appropriately.

LGTM, ta.


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


signature.asc
Description: PGP signature

Bug#1001091: rush: Upgrade to version 2.x of rush

[Richard Landster]

Package: rush
Version: 1.8+dfsg-1.1
Severity: normal

Dear Maintainer,

The current version of rush packaged for Debian is version 1.8. This version
is over 5 years old. Version 2.1 offers significant improvements in
access control configuration and has been available for over 2.5 years.

Please release version 2.1 of rush as a Debian package.

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages rush depends on:
ii  libc6  2.28-10

rush recommends no packages.

Versions of packages rush suggests:
ii  xinetd  1:2.3.15.3-1

-- no debconf information

Bug#1001090: latex-beamer: backport bugfix for bibliographies to Bullseye

[Nils König]

Package: texlive-latex-recommended
Version: 2020.20210202-3
Severity: wishlist

Dear Maintainer,

the version of beamer shipped in Bullseye's texlive-latex-recommended contains 
a 
bug preventing beamer files with multiple \printbibliography calls from being 
processed successfully. This can happen if e.g. the bibliography is split in 
literature sources for the content and another section for the images used in 
the presentation.
The bug was already fixed upstream and modifying my installed files to apply 
this patch was successfull in resolving the problem:

https://github.com/josephwright/beamer/commit/a41c6a779ca1f921d536ea9d9a2785ff6d5df615

>From the datetags of Bookworm's and Sid's packages I'm assuming they already 
include the fix, but imho it would be a very good idea to backport it to 
Bullseye too — if my local modification is something to go by it should apply 
without conflicts.

A minimal sample failing to be processed in unpatched Bullseye,
but working with the patch, can be found further below.

Cheers,
Nils König


minimal input file
##

\begin{filecontents}{\jobname.bib}
@misc{beamer,
  url = {https://ctan.org/pkg/beamer},
}
\end{filecontents}

\documentclass{beamer}

\usepackage[style=authoryear]{biblatex}

\addbibresource{\jobname.bib}

\begin{document}

\nocite{*}

\begin{frame}
\printbibliography
\end{frame}

\begin{frame}
\printbibliography
\end{frame}

\end{document}

##


other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2234 Dec  4 02:30 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 12  2021 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Feb 17  2021 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Feb 17  2021 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug 22 20:46 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Feb 17  2021 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Feb 17  2021 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3865 Oct 31 17:34 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Feb 28  2019 mktex.cnf
-rw-r--r-- 1 root root 475 Aug 22 20:46 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable'), (10, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads)
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: OpenRC (via /run/openrc), PID 1: openrc-init
LSM: AppArmor: enabled

Versions of packages texlive-latex-recommended depends on:
ii  tex-common  6.16
ii  texlive-base2020.20210202-3
ii  texlive-binaries2020.20200327.54578-7
ii  texlive-latex-base  2020.20210202-3

texlive-latex-recommended recommends no packages.

Versions of packages texlive-latex-recommended suggests:
pn  texlive-latex-recommended-doc  
ii  texlive-luatex 2020.20210202-3
ii  texlive-pstricks   2020.20210202-3

Versions of packages tex-common depends on:
ii  dpkg  1.20.9
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.3.4

Versions of packages texlive-latex-recommended is related to:
ii  tex-common6.16
ii  texlive-binaries  2020.20200327.54578-7

-- no debconf information

Bug#1001089: ITP: golang-github-clbanning-mxj -- mxj - to/from maps, XML and JSON (Go library)

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-clbanning-mxj
  Version : 2.5.5-1
  Upstream Author : Charles Banning
* URL : https://github.com/clbanning/mxj
* License : Expat
  Programming Lang: Go
  Description : mxj - to/from maps, XML and JSON (Go library)
 Decode/encode XML to/from map[string]interface{} (or JSON) values,
 and extract/modify values from maps by key or key-path, including wildcards.
 .
 mxj supplants the legacy x2j and j2x packages.
 If you want the old syntax, use mxj/x2j and mxj/j2x packages.

Reason for packaging: Needed by the upcoming Hugo 0.90.0 and up

Bug#1001088: asciidoc will be deprecated

[Osamu Aoki]

Source: debmake-doc
Version: 1.17-4
Severity: normal

asciidoc will be deprecated.  Although asciidoctor should be a plug-in
replacement, it is written in ruby and I have no idea how long it will
be around.

So I will reformat source for bookworm.

Action plan:

Step 1: Make XML as the source and drop asciidoc dependency
Skip manpage generation issue with static file (probably
generated off-line with asciidoc)
Step 2: Replace numerical entity references with the REAL UTF-8
characters (decide what to do with ' " variants in UTF-8)
Step 3: Convert XML to reST using pandoc and make it sphinx based document
Step 4: Split into smaller files for ease of editing
Step 5: Create manpage with rst2man
Step 6: Create po translation

Minimum is Step 1 and step 2.

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

Kernel: Linux 5.15.0-2-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1001087: ifupdown2 not set ip address of tincvpn interface

[Liang Guo]

Package: ifupdown2
Version: 3.0.0-1
Severity: normal
X-Debbugs-Cc: bluestonech...@gmail.com

Dear Maintainer,

I configure tincvpn interface as follow:

auto tincvpn
iface tincvpn inet static
address 10.100.6.5/24
tinc-net do
tinc-debug 1
tinc-user nobody
tinc-pidfile /tmp/tinc.pid
tinc-logfile /tmp/tinc.log

When I use ifup from ifupdown2 to bringup this interface, the interface is 
bringed up, but the address is not assigned. 

If I switchback to ifupdown, the tincvpn interface can be bringed up and the ip 
address is assigned too.

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

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

Versions of packages ifupdown2 depends on:
ii  iproute2  5.10.0-4
ii  python3   3.9.2-3

ifupdown2 recommends no packages.

Versions of packages ifupdown2 suggests:
pn  bridge-utils 
pn  ethtool  
ii  isc-dhcp-client  4.4.1-2.3
pn  python3-gvgen
pn  python3-mako 

Bug#877487: Fixed in testing+unstable - not worth acting on stable

[Paul Wise]

Control: fixed -1 2.1.0-1

On Fri, 2021-12-03 at 11:03 +0100, Julien Puydt wrote:

> I just checked that the problem isn't present in the version in testing
> and unstable, and it doesn't make the package unusable in stable, so
> it's not worth trying anything there.

Confirmed that the warnings are no longer present.

> I'm hence closing this report.

Next time please use a versioned -done message:

https://www.debian.org/Bugs/Developer#closing

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1000700: Debian 11 - Cinnamon 4.8.6-2 dont work correctly

[pham...@bluewin.ch]

Hello,
I don't speak English well either :)
- Yes, it is the folders on the desktop which change place after reboot and 
which do not align correctly and if I put a file on the desktop it overlaps the 
folders ;-(
- At this URL you can see the Mint configuration tool offering a traditional or 
modern desktop design. If we could have this module available under Debian that 
would be great. Ideally, this tool should be present in all distributions using 
Cinnamon...
https://sospc.name/wp-content/uploads/2019/02/L%E2%80%99%C3%A9cran-d%E2%80%99accueil-de-Linux-Mint-sospc.name-8.png
- I regret that there are not many people working on the project with you, I 
hope you will find some help.
Do what you can ... and close the ticket if you don't think you can do more.
Happy end of Year celebrations.
Philippe

Bug#1000339: r-cran-raster breaks r-cran-satellite autopkgtest: unable to find an inherited method for function 'extend'

[Robert J. Hijmans]

Andreas,

The background of this problem is the change in dependency between "raster"
and "terra". "terra" was dependent on "raster"; now it is the other way
around. This change was made in terra 1.4-07, 1.4-09 and 1.4-11 that were
released between 2021-10-05 and 2021-10-11, and in raster 3.5-2
(2021-10-11).

In the attachment I show the behavior of  `library(satellite)` with the
raster package prior to 2021-10-11, with the current versions, and for
possible intermediate steps. It shows that you can get the warnings you see
if you have current versions of terra/raster but an old version of
satellite.

>From what I can tell from this log:
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-satellite/16823806/log.gz
you are using satellite_1.0.4 and raster_3.5-2 (current versions), and
terra_1.4-11 (the current version is 1.4-22; but 1.4-11 should be OK).

Is it possible that your session is actually loading satellite_1.0.2?

Hope this helps,
Robert


On Tue, Nov 30, 2021 at 12:48 AM Andreas Tille  wrote:

> Control: forwarded -1 Robert J. Hijmans , Florian
> Detsch 
> Control: tags -1 upstream
> Control: tags -1 help
>
> Hi Robert and Florian,
>
> I'm contacting you as the maintainers or raster and satellite.  As you
> can see below in the Debian packaged versions of these packages some
> conflict was raised in the test of satellite after the latest version of
> raster was uploaded.
>
> I'm perfectly aware that the packages are tested on CRAN and thus I
> assume that possibly some special circumstances in the Debian packaged
> version might lead to the issue that is reported in the bug below.  I
> wonder whether you can give some hints how to solve the conflict in the
> test (at the very end of this mail).
>
> Thanks a lot for your help
>
>   Andreas.
>
> Am Sun, Nov 21, 2021 at 09:24:52PM +0100 schrieb Paul Gevers:
> > Source: r-cran-raster, r-cran-satellite
> > Control: found -1 r-cran-raster/3.5-2-1
> > Control: found -1 r-cran-satellite/1.0.4-1
> > Severity: serious
> > Tags: sid bookworm
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: breaks needs-update
> >
> > Dear maintainer(s),
> >
> > With a recent upload of r-cran-raster the autopkgtest of r-cran-satellite
> > fails in testing when that autopkgtest is run with the binary packages of
> > r-cran-raster from unstable. It passes when run with only packages from
> > testing. In tabular form:
> >
> >passfail
> > r-cran-raster  from testing3.5-2-1
> > r-cran-satellite   from testing1.0.4-1
> > all others from testingfrom testing
> >
> > I copied some of the output at the bottom of this report.
> >
> > Currently this regression is blocking the migration of r-cran-raster to
> > testing [1]. Due to the nature of this issue, I filed this bug report
> > against both packages. Can you please investigate the situation and
> reassign
> > the bug to the right package?
> >
> > 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=r-cran-raster
> >
> >
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-satellite/16823806/log.gz
> >
> > BEGIN TEST testthat.R
> >
> > R version 4.1.2 (2021-11-01) -- "Bird Hippie"
> > Copyright (C) 2021 The R Foundation for Statistical Computing
> > Platform: x86_64-pc-linux-gnu (64-bit)
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under certain conditions.
> > Type 'license()' or 'licence()' for distribution details.
> >
> > R is a collaborative project with many contributors.
> > Type 'contributors()' for more information and
> > 'citation()' on how to cite R or R packages in publications.
> >
> > Type 'demo()' for some demos, 'help()' for on-line help, or
> > 'help.start()' for an HTML browser interface to help.
> > Type 'q()' to quit R.
> >
> > > library(testthat)
> > > library(satellite)
> > Loading required package: raster
> > Loading required package: sp
> > code for methods in class "Rcpp_SpatCategories" was not checked for
> > suspicious field assignments (recommended package 'codetools' not
> > available?)
> > code for methods in class "Rcpp_SpatCategories" was not checked for
> > suspicious field assignments (recommended package 'codetools' not
> > available?)
> > code for methods in class "Rcpp_SpatDataFrame" was not checked for
> > suspicious field assignments (recommended package 'codetools' not
> > available?)
> > code for methods in class "Rcpp_SpatDataFrame" was not checked for
> > suspicious field assignments (recommended package 'codetools' not
> > available?)
> > code for methods in class "Rcpp_SpatExtent" was not checked for
> suspicious
> > field assignments (recommended package 'codetools' not available?)
> > code for methods in class 

Bug#1001016: Sadly 2.9.2 is also too old...

[Ralf Neubauer]

Hi,

sadly I still get the messages with 2.9.2. I upgraded all my machines to
this version to be sure I don't get warnings about an old client on one
machine on another newer client. The message box appeared promptly on
start of telegram-desktop and reappears every couple of minutes. This
clearly signals urgentness :-(.

Apparently something fresher is needed, like e.g. the aforementioned 3.1.1 .

Thank you in advance!

Ralf

-- 
  72 61 6c 66 40 73 74 72 : 63 6d 70 2e 64 65 0a r...@strcmp.de. 

Bug#1001086: RM: qemu-web-desktop [armel armhf i386 mips64el mipsel s390x] -- ROM; Architectures no longer supported

[Roland Mas]

Package: ftp.debian.org
Severity: normal

qemu-web-desktop is now restricted to a specific set of architectures
where it used to be "Architecture: any". This confuses Britney and
prevents migration to testing. Accordingly, I'd like to request the
removal of the binary package from unstable for the armel, armhf,
i386, mips64el, mipsel and s390x architectures.

Thanks,

Roland.

Bug#656728: THE AMOUNT IS 27.5 MILLIOMS USD

[Mrmohammed shamekh]

Dear Friend,

Greetings.

How are you doing today i hope fine?

I came across your e-mail contact prior a private search while in need
of your assistance. My name  Mr  mohammed   shamekh  ’ I work with the
department of Audit and accounting manager here in UBA Bank of Africa,
There is this fund that was keep in my custody years ago and I need
your assistance for the transferring of this fund to your bank account
for both of us benefit for life time investment and the amount is (US
$27,500. Million Dollars).

I have every inquiry details to make the bank believe you and release
the fund to your bank account in within 7 banking working days with
your full co-operation with me after success Note 50% for you while
50% for me after success of the transfer of the funds to your bank
account okay.

WAITING TO HEAR FROM YOU.
THANKS.

 Mr  mohammed   shamekh ,

Bug#1001085: ITP: ruby-thread-local -- provide a class-level mixin to make thread local state easy

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-r...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-thread-local
  Version : 1.1.0
  Upstream Author : Samuel Williams
* URL : https://github.com/socketry/thread-local
* License : MIT/X
  Programming Lang: Ruby
  Description : provide a class-level mixin to make thread local state easy

This gem provides a simple high level interface for per-class thread locals,
and it implements a standard interface for "shared global state". Using this
implementation avoids reinventing thread-local semantics in your own code.
.
Global variables are often not thread-safe and encourage poor programming
style. In many cases it is desirable to have thread-local state, but
implementing this directly in Ruby is unpleasant. This gem provides a
best-practice wrapper which can extend existing classes to provide per-thread
instances.
.
Conceptually, a thread is a container for application state. This works well
when servers consider applications to be isolated on a per-thread basis, but
this isn't always the case:


This is a new dependency of ruby-async-http and necessary to update this
package to fix #995354.


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmGqlgoACgkQS80FZ8KW
0F0vvxAAgy1bTR4g7pHBb8KqIwGRcouUYzFfSakiEqflJkxxHBOtbq4iHBOfWx/c
RKAl0CnFeEd+XVAMCvPIOziTlYLUJOubzIPRIRkHQYEas19mX5/LbT1SFgeQPuL5
iRaaW45oGiUOCLdGWniuQTE4wP6VjJjowU23YWqwdLCk+hQSUZmBrpJtA+IZmVSR
2tOL7vkGAIR1FhRxppy85D+Q1U/kgNUh8LYRaNHWvgQoie4u2dyWro6+UuYpvNRN
fTNF+oLqPUqcYYVq7l5rbWUDW+E2VgWyRE9aUKomJwVSgK+N8Yyc25aPhppuzapK
MjLpuRNgAo0fpAw+J0Bh4Bu+Ly75FUvhqPJkxpgquYJxtJIQVkwpPf4Td1hDI+Ht
0k56r+GJ55BPCofUkwecbXNPt5bek4s881Pz1TNsXjd9R6omgNQFp3eXb/frAhMv
TbtTyONoNGSruLtXT/4yr5d4Ks0HkfEy+vtVYKxsmsChkLnagEsF8OSbi/cpfRd0
1uG40RQGq+heLzjnpOS/1llrw3OlpqvglMCQz6KFooK+LQh83WuHl37j/zcJVYDe
x+6f/rc8Hl62gTaEhnrD1yblfxHOQa5ebaT3nsU1Hz5VoI+pf5D3CpTX4F0uYypk
vXR4xHifz6NGN0+Bo8Sw5NbqWnpD+zPoVj7XT7t0+BzLkB688ng=
=PCUC
-END PGP SIGNATURE-

Bug#1000239: Rescue system won't find root partition, but insists on /usr

[Bastian Blank]

Control: severity -1 normal

On Fri, Dec 03, 2021 at 04:08:24PM -0500, Nicholas D Steeves wrote:
> Steps I used to try to reproduce:
> 
> 1. Downloaded debian-testing-amd64-netinst.iso2021-12-03 16:21 408M
> 2. Installed to EFI-enabled qemu eg:
>kvm -bios /usr/share/ovmf/bios.bin -m 2G \
>-hda debian-separate-usr-sda.raw \
>-cdrom debian-testing-amd64-netinst.iso
> 3. Guided partitioning with separate /home, then changed the mount point
>to /usr.  Partition layout is:
>   sda1: ESP  fat32
>   sda2: /ext4
>   sda3: swap swap
>   sda4: /usr ext4

/usr as separate partition is not provided as option.  So, why do you
select it?  Sorry, but pointing the gun at your foot and firing is not
the smartest idea.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0

Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1

[Sergio Durigan Junior]

On Friday, December 03 2021, Helmut Grohne wrote:

> Dear curl maintainers,
>
> Adam has acked my stable upload. Consequently, I've uploaded my proposed
> NMU. In accordance with devrev, it went to delayed/5. Please let me know
> if that doesn't work for you. The diff is exactly the one I sent
> previously.

Thanks, Helmet.

Sorry for the delay in replying.  I looked at your patch and it seems
like a sensible approach to me.  Thanks for taking care of it.

Cheers,

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


signature.asc
Description: PGP signature

Bug#1001082:

[Mesmer, Garrett T]

To give an example of a program showing this issue, the MultiMC5 launcher shows this when closing an instance.The dev believes that this bug report is relevant and should be backported to QT 5.11 on buster: https://bugreports.qt.io/browse/QTBUG-68393 

Bug#1000572: fai-cd: Support TMPDIR being redirected

[Thomas Lange]

Hi Mike,

instead of using "chroot $NFSROOT bash -c TMPDIR=/tmp ..."
in your code I propose to use

TMPDIR=/tmp chroot 

IMO this is better, because we do not use another subshell. It also
set TMPDIR for the command inside the chroot.

What do you think? Any comments?
-- 
viele Grüße Thomas

Bug#998108: firefox freezes shortly after start

[Christoph Anton Mitterer]

I just had one occasion of the "freezing" problem... but it was the
first time since we got 94.0-2.

Also it didn't occur short after start, but quite some time after
browsing the very same websites.

But the symptoms were as described in message #15 (i.e. that loading
wheel).


So there may be still some issue left (or it might be something
new/unrelated).


Cheers,
Chris.

Bug#981387: closed by Debian FTP Masters (reply to Stefan Hornburg (Racke) ) (Bug#981387: fixed in pure-ftpd 1.0.50-1)

[Helmut Grohne]

On Fri, Dec 03, 2021 at 07:43:49PM +0100, Stefan Hornburg (Racke) wrote:
> are you going to create a patch that fixes the problem for good?

I don't think that would make sense. Suppose I were to regenerate
configure and diff the present configure with the new one. You'd get a
giant diff that essentially replaces configure. How would you review
tens of thousands of lines changed?

Instead, you should locally regenerate configure before uploading.

The alternative chosen by most maintainers (due to being automatically
enabled in debhelper compat level >= 10) is using dh_autoreconf. It will
ignore the shipped configure and regenerate it during build. You're
presently using compat level 9, which happens to be deprecated.

Helmut

Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1

[Helmut Grohne]

Dear curl maintainers,

Adam has acked my stable upload. Consequently, I've uploaded my proposed
NMU. In accordance with devrev, it went to delayed/5. Please let me know
if that doesn't work for you. The diff is exactly the one I sent
previously.

Helmut

Bug#1000239: Rescue system won't find root partition, but insists on /usr

[Nicholas D Steeves]

Control: severity -1 serious
Control: tags = confirmed

CCing the release team, and CTTE because I don't know who else is
tracking issues related to the usrmerge effort.  I've consciously chosen
not to pour gasoline on the flame war by CCing anyone else (nor will I
contact anyone else about the existence of this bug).

Steps I used to try to reproduce:

1. Downloaded debian-testing-amd64-netinst.iso  2021-12-03 16:21 408M
2. Installed to EFI-enabled qemu eg:
   kvm -bios /usr/share/ovmf/bios.bin -m 2G \
   -hda debian-separate-usr-sda.raw \
   -cdrom debian-testing-amd64-netinst.iso
3. Guided partitioning with separate /home, then changed the mount point
   to /usr.  Partition layout is:
  sda1: ESP  fat32
  sda2: /ext4
  sda3: swap swap
  sda4: /usr ext4
4. Selected only "Standard System Utilities"
5. Rebooted

Result: SUCCESS

Then, to test the rescue functionality:

1. I discovered qemu+OVMF boot order is broken without changing the
   command to: kvm -L /usr/share/ovmf/ -m 2G -boot menu=on \
   -hda /scratch/debian-separate-usr-sda.raw \
   -cdrom /scratch/debian-testing-amd64-netinst.iso
2. Selected sda2
3. Yes, mount /boot/efi
4. Execute a shell in /dev/sda2
5. No usable shell was found on your root file system (/dev/sda2)
6. Changed virtual terminal
7. cd /target && ls bin
   ls: bin: No such file or directory

Result: FAILED
Conclusion: This is a usrmerged system, and the rescue system does not
support usermerged systems.

The options are, as I see them, ranked from least to most work-hours:

1. Debian isn't yet ready for usrmerge.  Revert to normal system installation.
2. Reassign to src:rescue, and fix the rescue system.
   a) before chrooting, test for the presence of /target/bin/sh
   b) if /bin/sh is not found, either emit error to the user and present a
  dialogue for selecting /usr partition, or
   c) parse /target/etc/fstab, and attempt to mount other partitions
   d) b & c will be difficult to implement when attempting to accommodate
  the heterogeneity of possible MD, LUKS, and LVM layouts, not to mention
  the complications introduced by the possibility of a user-configured
  btrfs subvolume name "@usr" on any valid device.  Fstab parsing might
  make the btrfs case easier with:
i)   Display a dialogue selector if a btrfs partition is detected
 The dialogue will list all detected subvolumes
ii)  If the user cannot find a subvolume for "@usr", then
iii) Allow the user to escape to the partition selection screen, and
iv)  Unmount the partition
3. Disallow configuring of a mount for "/usr", and *Prominently* declare that
   Debian no longer supports separating /usr from /, declare this in *many
   places*, and reply to bugs on this topic for many years.  I put this one
   last because I believe the cost to work-hours is unbounded, and
   because I believe there may be a negative social cost associated with
   this action.  Also, if Fedora/RHEL/SUSE/Ubuntu support a separate /usr
   partition, then this action could make Debian look inferior.


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1001084: ITP: meli -- terminal mail client

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: meli
  Version : 0.7.2
  Upstream Author : Manos Pitsidianakis 
* URL : https://meli.delivery/
* License : GPL-3+
  Programming Lang: Rust
  Description : terminal mail client

 meli is a terminal email client with support for multiple accounts
 and Maildir, mbox, notmuch, IMAP, and JMAP.

The packaging will be maintained at https://salsa.debian.org/debian/meli


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGqp2cACgkQLHwxRsGg
ASFHQg//bAr3xKyoXD6Ff9iItiozdSi+sGkjLWIWPqeIp9CsBUcnU7SRZGqgNQSG
iZRSmDwWhOp7rDs3QyBxM61l5atAwB8s51LBawmJIqKW1f1YSTtQaGB1y4f1/jOT
fKdwAcEVQl4MyZ7EybDAnzOrDaD1N/4/2u1vwhkvRMxTRQqXCCVH7R3yUijWyg5x
H3XXLnWBJViU9bVH5ZpiZBqx4V4pqNPJiDg9+9FLozTXbtSB82BN6/SCEIiVtwa9
nPtHN0Xlyq6FzLTQ44vhTvde/pQl3uT5G8f4Tsh1DwkpmD9WbQz3dWFEQUQMzJ5v
lDZxMkv2eBZs0Ft/NpCOOvs4FrH7f+xeIEHvPcwQkCFyx9ToPvU9O0dFZ1FZnxbF
Qi4nInZfuQZJae83Y+cC7Sq9DvS1cnuqv74schlEl2iot7lyhgHWiGfYU9HGqbRZ
CMFEdm0e3/L0HO3/uDpFX8CNIult1LPCF6g9kiZtOo2xpdAkqw1gWCNRk3czqR7q
Ywqui7rpltm0FDROOIwqjUzu8A5Wn7OKrHQMrjbD7tJVP8bcS6S1FfurPiTqjY+r
+8/SuSXU8XjBr08z/SshnDjBOX5DfM7My4H23svysGLXSj73o8sy6kH+ULtK2c1n
DIOYBu/p38o4hDiQOJvRr2WsqIWCbMM0roiC7+6I9w1dsaZqbaw=
=tu33
-END PGP SIGNATURE-

Bug#1001083: linux-headers-5.16.0-rc3-common: KBUILD_CFLAGS contains quoted string "-Wimplicit-fallthrough=5"

[Andreas Beckmann]

Source: linux
Version: 5.16~rc3-1~exp1
Severity: important
Control: block 1001007 with -1

KBUILD_CFLAGS in 5.16 contains a quoted string, and at some point of
passing the flags through the build system of the kernel and third
party modules, the quotes get "protected" and finally passed as part of
an argument to gcc, which fails with

gcc-11: error: "-Wimplicit-fallthrough=5": linker input file not found: No such 
file or directory

This has so far been reported for the nvidia kernel module (#1001007),
but I would expect that it can happen for other modules as well.

The origin of this quoted value: it's a quoted string in .config:

/usr/src/linux-headers-5.16.0-rc3-amd64/.config:CONFIG_CC_IMPLICIT_FALLTHROUGH="-Wimplicit-fallthrough=5"
/usr/src/linux-headers-5.16.0-rc3-common/Makefile:KBUILD_CFLAGS += 
$(KBUILD_CFLAGS-y) $(CONFIG_CC_IMPLICIT_FALLTHROUGH)

Probably
KBUILD_CFLAGS += $(KBUILD_CFLAGS-y) $(patsubst 
"%",%,$(CONFIG_CC_IMPLICIT_FALLTHROUGH))
would be sufficient to fix this.


Andreas

Bug#1001082: qtbase-opensource-src: segfault when closing one windows in a multi window QT application

[theofficialgman]

Package: qtbase-opensource-src
Severity: important
Tags: newcomer

Dear Maintainer,

In both debian buster and raspbian buster, closing an application window in a 
multi window QT application causes a segfault and the entire program to crash.
This might have been fixed upstream in one of these commits: 
https://github.com/qt/qtbase/commit/ca991ee22d3509f8f54ee26d4c30d45319428c8f or 
https://github.com/qt/qtbase/commit/e9e8d67e31b8b6a8348b5dae3225be2dbd87ffd2
QT 5.15 from debian bullseye does not have this issue, so it has been fixed 
upstream somewhere inbetween 5.12 and 5.15 release

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: aarch64

Kernel: Linux 4.9.140+ (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#976014: firehol: Role of /etc/default/firehol and START_FIREHOL variable

[François Poulain]

In bullseye, the behavior appears to be consistant: START_FIREHOL=No
makes it not working.

-- 
François Poulain 

Bug#1001081: sbcl: `sbcl --load quicklisp.lisp` fails with `internal error 222` since 2.1.11-1

[David Loyall]

Package: sbcl
Version: 2:2.1.11-1
Severity: important

Dear Sébastien Villemot,

Here is some output from a terminal:

sebboh@debian:~/prj$ sbcl --load quicklisp.lisp
This is SBCL 2.1.11.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
While evaluating the form starting at line 1154, column 0
  of #P"/home/sebboh/prj/quicklisp.lisp":

debugger invoked on a SIMPLE-ERROR @52CF6451 in thread
#:
  internal error 222: NIL; args=NIL

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY   ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file
"/home/sebboh/prj/quicklisp.lisp".
  2: [ABORT   ] Abort loading file "/home/sebboh/prj/quicklisp.lisp".
  3:Ignore runtime option --load "quicklisp.lisp".
  4:Skip rest of --eval and --load options.
  5:Skip to toplevel READ/EVAL/PRINT loop.
  6: [EXIT] Exit SBCL (calling #'EXIT, killing the process).

(SB-C:MAKE-TN-REF # NIL)
0] 6
;
; compilation unit aborted
;   caught 1 fatal ERROR condition

debugger invoked on a SIMPLE-ERROR @52A4A930 in thread
#:
  internal error 222: NIL; args=NIL

The current thread is not at the foreground,
SB-THREAD:RELEASE-FOREGROUND has to be called in
#
for this thread to enter the debugger.
Killed

FYI, `quicklisp.lisp` is the 2010-10-09 Quicklisp beta.

I tried a few things, then I noticed that my installed version of sbcl
is only two days old..  So, I searched /var/cache/apt/archives and
found an older one..  Then, I did this:

sebboh@debian:~/prj$ dpkg -i
/var/cache/apt/archives/sbcl_2%3a2.1.8-1_amd64.deb
dpkg: error: requested operation requires superuser privilege
sebboh@debian:~/prj$ sudo !!
sudo dpkg -i /var/cache/apt/archives/sbcl_2%3a2.1.8-1_amd64.deb
dpkg: warning: downgrading sbcl from 2:2.1.11-1 to 2:2.1.8-1
(Reading database ... 61703 files and directories currently installed.)
Preparing to unpack .../sbcl_2%3a2.1.8-1_amd64.deb ...
Unpacking sbcl (2:2.1.8-1) over (2:2.1.11-1) ...
Setting up sbcl (2:2.1.8-1) ...
Processing triggers for man-db (2.9.4-2) ...

After that, `sbcl --load quicklisp.lisp` worked as expected!

I hope this information is helpful.  I have exhausted my
troubleshooting capability here, but if you tell me some commands to
run, I will share the output with you.

Some information from `reportbug` is below my sig.

Cheers,
--david "sebboh" loyall

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

Kernel: Linux 5.15.0-2-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 sbcl depends on:
ii  libc6   2.32-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages sbcl recommends:
ii  binfmt-support  2.2.1-1

Versions of packages sbcl suggests:
pn  sbcl-doc 
pn  sbcl-source  
pn  slime

Bug#1001080: linux: Previously enabled IIO ADC drivers are no longer enabled

[Diederik de Haas]

Source: linux
Version: 5.10.1-1_exp1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In commit aa87da1f902dba04f3b15680e178ad336e985f4f titled "Enable all
Industrial I/O ADC" various IIO ADC drivers which were enabled for armhf
and arm64 got disabled, while a whole bunch of other got enabled in 
debian/config/config, but I couldn't find a reason why those others were
disabled. Below I'll mention which drivers got disabled.

- From debian/config/arm64/config:
CONFIG_QCOM_SPMI_IADC=m
CONFIG_QCOM_SPMI_VADC=m
CONFIG_ROCKCHIP_SARADC=m

- From debian/config/armhf/config:
CONFIG_ASPEED_ADC=m
CONFIG_EXYNOS_ADC=m
CONFIG_ROCKCHIP_SARADC=m
CONFIG_TI_AM335X_ADC=m
CONFIG_TWL4030_MADC=m

Should those driver get re-enabled again?

Cheers,
  Diederik

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)
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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYap6UQAKCRDXblvOeH7b
boc9AP4kNw+DQy3raD1lEYUqOjHEJzGtf+E8DA0G3sjkidevOgEArnrp2D9S2UZf
VwFPsU5sjsBhB2323zfNMAG8m/3rPA0=
=jD9d
-END PGP SIGNATURE-

Bug#992330: bullseye-pu: package nova/22.2.2-1+deb11u1 (CVE-2021-3654)

[Thomas Goirand]

Hi Julien,

Thanks for your (unfortunately late) answer.

On 12/3/21 3:11 PM, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> Hi Thomas,
> 
> On Tue, Aug 17, 2021 at 12:57:50PM +0200, Thomas Goirand wrote:
>> Also, I would like to get Nova upgraded to the latest point
>> release, to fix numerous small issues. The release notes for
>> Nova are there:
>>
>> https://docs.openstack.org/releasenotes/nova/victoria.html
>>
> That looks incomplete?  Please include a complete description of the
> changes you want approved.

What do you need exactly that isn't available publicly? The full commit
history for Nova Victoria stable branch is here:

https://opendev.org/openstack/nova/commits/branch/stable/victoria

Here are the commits sum-ups:

Changes in nova 22.2.0..22.2.1
--
210abc09b8 guestfs: With libguestfs >= v1.41.1 decode returned bytes to
string
7b4f479647 Dynamically archive FK related records in archive_deleted_rows
21241b38dd Add functional test for bug 1837995
382d64ea36 Centralize sqlite FK constraint enforcement
c7d9d6d9dd Fix the vGPU dynamic options race
276b8db5af Add config parameter 'live_migration_scheme' to live
migration with tls guide
5d1adb2604 libvirt: Use specific user when probing encrypted rbd disks
during extend
3d84097eab api: Log os-resetState as an instance action
831abc9f83 Use absolute path during qemu img rebase
eda11a4875 libvirt: Skip encryption metadata lookups if secret already
exists on host

Changes in nova 22.1.0..22.2.0
--

35112d7667 Handle instance = None in _local_delete_cleanup
4f17ea2f7d Add regression test for bug 1914777
3d86df068a tools: Allow check-cherry-picks.sh to be disabled by an env var
ef348c4eb3 only wait for plugtime events in pre-live-migration
8e12b81839 Disallow CONF.compute.max_disk_devices_to_attach = 0
09784db62f Prevent archiving of pci_devices records because of
'instance_uuid'

Changes in nova 22.0.1..22.1.0
--

eebf94b654 compute: Lock by instance.uuid lock during swap_volume
63d2e62c3a Use subqueryload() instead of joinedload() for (system_)metadata
6b57575092 Fallback to same-cell resize with qos ports
7366e3c375 Reproduce bug 1907522 in functional test
4e5b92545d Add upgrade check about old computes
0c5ca351e2 Warn when starting services with older than N-1 computes
e3da2ca7be lower-constraints: Bump packaging to 20.4
c3a0969329 Omit resource inventories from placement update if zero
eda458828b compute: Don't detach volumes when RescheduledException
raised without retry
95fc161334 Add regression test for bug #1899649
478be6f4fb zuul: Replace nova-live-migration with zuulv3 jobs
f4d62e1a0b Fix a hacking test
82d415d200 Add missing exception
3ecc098d28 Set instance host and drop migration under lock
d768cdbb88 Reproduce bug 1896463 in func env
9a5b6249d6 Use cell targeted context to query BDMs for metadata

Do you insist on reviewing *ALL* of the commits, one by one? As you can
read above, *all* is bugfix only.

Why don't you trust upstream bugfix releases, which contains only
targeted bugfixes only, and that goes through extensive unit and
functional testing? I also tested the point release, and I have it in
production... Products like Firefox ESR get updated this way, and it
doesn't seem to be a problem. Should OpenStack be treated differently?
If so, why?

>> [ Risks ]
>> No risk during upgrade that I know of.
>>
> That is.. not reassuring.

What do you need to re reassured?

>>* Tune nova-api-{,metadata-}uwsgi.ini for performance.
>>
>> This is a minor tweak to the uwsgi.ini default configuration,
>> which I've started pushing on all OpenStack packages in Debian.
>> It's only better with it...
>
> I don't think this is appropriate for stable.  There's no information on
> what environment(s) this is tuned for, or benchmarked in.

This simply increases the number of processes.

https://salsa.debian.org/openstack-team/services/nova/-/commit/46a908d772c542eb63d9013ee71d70f820f32e4e

Note that right now, the number of threads is back to "1" (in a later
commit) because otherwise nova-api fails to work properly in some cases,
because of Eventlet threading thing.

The number of process set to 8 is only a better default because without
it, uwsgi starts with the same amount of process as core. With modern
servers, that's a way too much (imagine 32 processes on a 64 core
machine...) and may eat-up too much memory.

What's also very important is the "listen 100" which is comparable to
the same kind of directive in Apache (ie: to accept maximum 100 waiting
connections). Our bench (which I do not have handy, sorry) showed it
helps a lot with performances (approximately x2 faster).

>>* New upstream release.
>>
>> See above.
>
> I'll reserve my opinion on that until we have a better description of
> the changes.  It seems plausible, broadly.
> 
>>* CVE-2021-3654: novnc allows open redirection. Added upstream patch:
>>  

Bug#1001073: [Pkg-utopia-maintainers] Bug#1001073: network-manager-openvpn: [bullseye] importing ovpn file using GUI results in non-functional VPN (fails due to auth timeout)

[Nicholas D Steeves]

Control: tags -1 bullseye upstream fixed-upstream

Michael Biebl  writes:
> On 03.12.21 19:07, Nicholas D Steeves wrote:
>
[snip]
>> The fix for bullseye should cherry-picked from upstream VCS to make
>> this package usable on Debian stable, because "The Debian Desktop
>> doesn't work with commercial VPNs" harms Debian's reputation IMHO.
>
> Right. Could you run a git bisect to find the commit which we need to 
> cherry-pick=
> Uploading a new upstream release 1.8.16 is probably not something the 
> stable release managers will ack but a targetted fix is more likely to 
> be accepted.
>

Of course, that's why I suggested cherry-picking ;-)

Looking at the commit history, bisecting will be a waste of time,
because d1942fd from 1.8.16's HEAD^10 (very recent recent) is required
for bullseye's OpenVPN 2.5.x...honestly, without ovpn 2.5.x support,
this package looks RC buggy for bullseye and maybe it just doesn't have
many users?  Ie: Maybe most of its more technical users are tracking
sid?  My experience is that all less technical users who use a
commercial VPN use the proprietary application furnished by the provider
when they can't get our (and derivatives) network-manager-openvpn to
work properly.

Since 1.8.12, there are 20 relevant commits: 2 security related, 1
definitely needed, 1 needed for at least one well-known commercial VPN
provider, 1 likely needed, 1 nice to have, 1 for being a good netizen,
and the rest I either don't know how to test, or don't have the OpenVPN
knowledge to assess.  I've added my annotations with the following
pattern "** ".

commit ab8ad62f0865d98210265327d8274a55c58e8db5
Author: Santiago Gala 
Date:   Fri Sep 24 19:57:48 2021 +0200

helper: set the can-persist flag

OpenVPN is able to persist the connection across link changes and
outages. Set the can-persist flag in the configuration returned to
NetworkManager.

[bgalv...@redhat.com: rewrote commit message]

https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/40
** this one solves several outstanding bugs in the BTS.  I think we want
this one, because users have been asking for it for years, and because
if a laptop loses an unreliable wifi link, the VPN will disconnect, and
then won't reconnect when the link is restored.  I think the security
team would support this one.

commit f9286da94dbfa1d585f0dc8d2f57640d467e2193
Author: Beniamino Galvani 
Date:   Thu Jun 3 18:19:39 2021 +0200

helper: fix parsing of IPv6 configuration

If the server pushes, for example:

  ifconfig-ipv6 2001:db8:f00:bebe::1003/64 2001:db8:f00:bebe::1

NetworkManager considers the first argument as the subnet and the
second as the peer, and so it does something equivalent to:

  ip addr add dev tun0 2001:db8:f00:bebe::1003/64 peer 2001:db8:f00:bebe::1

which appears in the "ip -6 addr" output as:

inet6 2001:db8:f00:bebe::1003 peer 2001:db8:f00:bebe::1/128 scope global
   valid_lft forever preferred_lft forever

Instead, according to 'man openvpn', NM should simply add address
2001:db8:f00:bebe::1003/64 and use the second argument as a fallback
gateway for the routes specified by '--route-ipv6'
** solves other bugs reported in the BTS

commit 3c47520e999d5301eec69838e11ad4053bef4f20
Author: Thomas Haller 
Date:   Mon Jun 7 19:00:45 2021 +0200

service: assume that we run openvpn 2.4 or newer by default

Our version detection might fail or give the wrong result. So change
the code to assume (in case of unknown version) that we run version 2.4
or newer. By now, that should be the common case and we should only assume
to run 2.3 or older if we successfully detected it.
** the absence of this one might cause my bug, but I suspect this one isn't 
needed, because if it was someone would have filed a grave bug against 
network-manager-openvpn.  Sorry, I'm not sure.

commit d1942fdc94786ea412aadda2bec8f6b9b9005c85
Author: Thomas Haller 
Date:   Mon Jun 7 18:47:56 2021 +0200

service: fix detection of openvpn version

Since 2.5.0, `openvpn --version` no longer exits with
code 1. That broke the version detection.


https://github.com/OpenVPN/openvpn/commit/96ae327add16f06ac8bc28cfbf9ba0abfcc7129c
** This one must be backported

commit 353a521bc08e2c762e7c63d10f8e3233e9442b08
Author: Beniamino Galvani 
Date:   Fri Feb 19 10:03:41 2021 +0100

helper: ignore IPv4 configuration without an address

This is the same as commit 56bb08f2956e ("helper: ignore IPv6
configuration without an address") but for IPv4.

NetworkManager always rejects configurations without an address, so
ignore them. A configuration without address can be created, for
example, if the server advertises IPv4 routes or domains without an
address.

https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/35

Bug#1001079: cue2toc: Bad output when writing a track with 99 indexes

[Brendon]

Package: cue2toc
Version: 0.4-5+b2
Severity: important
Tags: patch
X-Debbugs-Cc: ed7-aspire4...@hotmail.com

For patch and test files, see #1001076.

To reproduce:

1. In `198-indexes.cue`, remove INDEX 99 in TRACK 01,

2. $ cue2toc -o 198-indexes.toc 198-indexes.cue

3. Inspect the second track in the output file.


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

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

Versions of packages cue2toc depends on:
ii  libc6  2.32-4

cue2toc recommends no packages.

cue2toc suggests no packages.

-- no debconf information

Bug#1001078: sqlalchemy: setup.cfg defines extra pg8000>=1.16.6

[Corey Bryant]

Package: sqlalchemy
Version: sqlalchemy-1.4.23+ds1
Severity: normal

Dear Maintainer,

When attempting to re-enable autopkgtests for sqlalchemy-utils [1] tests fail 
due to pg8000
not being 1.16.6 or greater:

/usr/lib/python3/dist-packages/sqlalchemy/engine/create.py:561: in create_engine
dialect = dialect_cls(**dialect_args)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = , client_encoding = None, kwargs = {'compiler_linting': 1, 
'dbapi': }
def __init__(self, client_encoding=None, **kwargs):
PGDialect.__init__(self, **kwargs)
self.client_encoding = client_encoding

if self._dbapi_version < (1, 16, 6):
>   raise NotImplementedError("pg8000 1.16.6 or greater is required")
>   E   NotImplementedError: pg8000 1.16.6 or greater is 
> required
>
>   *** Reporter, please consider answering these questions, where 
> appropriate ***

[1] requires addition of:
psql -c "ALTER USER postgres PASSWORD 'password';" -U postgres
and
export SQLALCHEMY_UTILS_TEST_POSTGRESQL_PASSWORD="password"

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

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

Bug#1000881: firmware-iwlwifi: No Bluetooth controller detected with kernel 5.15

[Léo Girardin]

Le 30/11/2021 à 22:53, Salvatore Bonaccorso a écrit :
> I suspect this is the same as #1000403, please can you retest with
> 5.15.5-1 in unstable (and 5.16~rc3-1~exp1 from experimental)?

Sorry for the late reply and thank you. I can confirm that with 
the new kernel 5.15.0-2 in testing, Bluetooth is back and working. 

It must be the same as #1000403 indeed.

Bug#1001077: chkservice: Is it abandoned upstream?

[Jonathan Rubenstein]

Package: src:chkservice
Version: 0.3-1
Severity: important
X-Debbugs-CC: linuxe...@gmail.com

The project at https://github.com/linuxenko/chkservice has numerous
unresolved open issues and pull requests, and has not seen any activity for
some time.

According to GitHub, linuxenko herself has no recent activity, her twitter
says the samr thing.

I am not sure what the process is for this situation, but the project has 2
open RC bugs right now that kept it from entering bullseye, and due to this
information I doubt they will ever be fixed upstream.

What is next for this package?


Jonathan Rubenstein

Bug#993809: bullseye-pu: package segemehl/0.3.4-3+deb11u1 (Pre-approval)

[Nilesh Patra]

On 3 December 2021 9:41:48 pm IST, Julien Cristau  wrote:
>On Tue, Sep 07, 2021 at 12:27:05AM +0530, Nilesh Patra wrote:
>> diff -Nru segemehl-0.3.4/debian/patches/arm64.patch 
>> segemehl-0.3.4/debian/patches/arm64.patch
>> --- segemehl-0.3.4/debian/patches/arm64.patch1970-01-01 
>> 05:30:00.0 +0530
>> +++ segemehl-0.3.4/debian/patches/arm64.patch2021-09-06 
>> 23:43:50.0 +0530
>> @@ -0,0 +1,75 @@
>> +Description: Change the signed-ness for several chars to fix segfault
>> +Author: Nilesh Patra 
>> +Last-Update: 2021-08-24
>> +--- a/libs/biofiles.c
>>  b/libs/biofiles.c
>> +@@ -1916,7 +1916,7 @@
>> + Uint max, Uint *minlen, Uint *maxlen, unsigned char *minq, unsigned 
>> char *maxq) 
>> + {
>> + 
>> +-  char ch;
>> ++  signed char ch;
>> +   char idchar=0;
>> +   int ret=0;
>> +   off_t curseqoffset, lastindexoffset=0;
>
>Shouldn't `ch` be an `int` instead, to match the return value of getc,
>and type of EOF?
>
>Anyway, I guess this is fine if it works...

Should I upload this to p-u?

Bug#992010: This might help

[Sebastian Spaeth]

Try the solution in 
https://forum.manjaro.org/t/howto-troubleshoot-crackling-in-pipewire/82442


Specifically setting

default.clock.allowed-rates = [ 44100 48000 ]

in /etc/pipewire/pipewire.conf was enough to solve my crackling in a 
Laptop with a AMD FCH Azalia Controller (rev 02)

Bug#981387: closed by Debian FTP Masters (reply to Stefan Hornburg (Racke) ) (Bug#981387: fixed in pure-ftpd 1.0.50-1)

[Stefan Hornburg (Racke)]

On 03/12/2021 19:29, Helmut Grohne wrote:

Control: reopen -1

On Wed, Dec 01, 2021 at 09:36:10AM +, Debian Bug Tracking System wrote:

It has been closed by Debian FTP Masters  (reply to 
Stefan Hornburg (Racke) ).


I think the bug is only partially fixed. While configure.ac has been
patched, configure wasn't updated and since it isn't regenerated during
build, the unfixed version is actually being used.

Helmut



Hello Helmut,

are you going to create a patch that fixes the problem for good?

Regards
  Racke

--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001076: cue2toc: Absolute index timestamps don't work with cdrdao (1.2.4)

[Brendon]

Package: cue2toc
Version: 0.4-5+b2
Severity: important
X-Debbugs-Cc: ed7-aspire4...@hotmail.com

They have to be relative to the start of their track.

Patch and test files will be uploaded soon.


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

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

Versions of packages cue2toc depends on:
ii  libc6  2.32-4

cue2toc recommends no packages.

cue2toc suggests no packages.

-- no debconf information

Bug#1001075: openscap-common: missing Breaks+Replaces: libopenscap8 (<< 1.3.5)

[Andreas Beckmann]

Package: openscap-common
Version: 1.3.5-0.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../openscap-common_1.3.5-0.1_all.deb ...
  Unpacking openscap-common (1.3.5-0.1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/openscap-common_1.3.5-0.1_all.deb (--unpack):
   trying to overwrite '/usr/share/openscap/cpe/README', which is also in 
package libopenscap8 1.3.4-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/openscap-common_1.3.5-0.1_all.deb


cheers,

Andreas


libopenscap8=1.3.4-1_openscap-common=1.3.5-0.1.log.gz
Description: application/gzip

Bug#981387: closed by Debian FTP Masters (reply to Stefan Hornburg (Racke) ) (Bug#981387: fixed in pure-ftpd 1.0.50-1)

[Helmut Grohne]

Control: reopen -1

On Wed, Dec 01, 2021 at 09:36:10AM +, Debian Bug Tracking System wrote:
> It has been closed by Debian FTP Masters  
> (reply to Stefan Hornburg (Racke) ).

I think the bug is only partially fixed. While configure.ac has been
patched, configure wasn't updated and since it isn't regenerated during
build, the unfixed version is actually being used.

Helmut

Bug#1001074: ldns FTCBFS: python uses the build architecture library

[Helmut Grohne]

Source: ldns
Version: 1.7.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ldns fails to cross build from source, because the python build
misdetects the python libraries and attempts to use the build
architecture ones. To fix this, one has to export
_PYTHON_SYSCONFIGDATA_NAME. When building a python extension with
pybuild, this is handled by pybuild, but we don't have automation for
this case. Please consider applying the attached patch.

Helmut
diff --minimal -Nru ldns-1.7.1/debian/changelog ldns-1.7.1/debian/changelog
--- ldns-1.7.1/debian/changelog 2020-06-24 14:08:14.0 +0200
+++ ldns-1.7.1/debian/changelog 2021-12-03 16:58:34.0 +0100
@@ -1,3 +1,10 @@
+ldns (1.7.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Set _PYTHON_SYSCONFIGDATA_NAME for python builds. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 03 Dec 2021 16:58:34 +0100
+
 ldns (1.7.1-2) unstable; urgency=low
 
   * Team upload.
diff --minimal -Nru ldns-1.7.1/debian/rules ldns-1.7.1/debian/rules
--- ldns-1.7.1/debian/rules 2020-06-03 22:55:03.0 +0200
+++ ldns-1.7.1/debian/rules 2021-12-03 16:58:28.0 +0100
@@ -21,6 +21,7 @@
 override_dh_auto_configure:
dh_auto_configure -- $(CONFIGFLAGS) --with-examples --with-drill
for pyvers in $(PYVERS); do \
+   
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH)
 \
PYTHON_VERSION=$$pyvers dh_auto_configure -B 
build/python-$$pyvers -- $(CONFIGFLAGS) --with-pyldns; \
done
 

Bug#1000976: plasma-systemmonitor: doesnt start - QQmlApplicationEngine failed to load component

[Patrick Franz]

Hi,

On Fri, 3 Dec 2021 19:00:14 +0100 Emilian Nowak  
wrote:
> I didn't have that one, but after installing it fails with the 
following
> message:
> 
> QQmlApplicationEngine failed to load component
> file::/main.qml:89:21: Type NewStuff.Action unavailable
> file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/newstuff/qml/
Action.qml:181:13: Type NewStuff.Page unavailable
> file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/newstuff/qml/Page.qml:
20:1: module "org.kde.kcm" is not installed

In this case, "qml-module-org-kde-kcm" seems to be missing.


> If this are all some dependencies why aren't they in package 
dependecny ? 

Probably because none of us has ever tested running the systemmonitor 
without Plasma being installed.
qml-module-qtquick-dialogs is installed automatically when you install 
plasma-workspace or plasma-desktop.
qml-module-org-kde-kcm is installed automatically when you install 
systemsettings.

If you find further missing QML modules, please post them so that I can 
add them explicitly as dependencies.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1001073: [Pkg-utopia-maintainers] Bug#1001073: network-manager-openvpn: [bullseye] importing ovpn file using GUI results in non-functional VPN (fails due to auth timeout)

[Michael Biebl]

On 03.12.21 19:07, Nicholas D Steeves wrote:


I then created a local bpo of network-manager-openvpn_1.8.16-1, and
installed it, to see if this would solve the problem.  It solved the
problem.

The fix for bullseye should cherry-picked from upstream VCS to make
this package usable on Debian stable, because "The Debian Desktop
doesn't work with commercial VPNs" harms Debian's reputation IMHO.


Right. Could you run a git bisect to find the commit which we need to 
cherry-pick=
Uploading a new upstream release 1.8.16 is probably not something the 
stable release managers will ack but a targetted fix is more likely to 
be accepted.


Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#968417: netkit-ftp-ssl: Please backport ftp-ssl to buster

[Bastian Germann]

Control: tags -1 wontfix

On Mon, 4 Oct 2021 14:20:42 +0200 Bastian Germann  wrote:

On Fri, 14 Aug 2020 20:32:03 -0400 William Blough  wrote:
> Since ftp-ssl did not make it into buster, there do not appear to be any
> command line ftp clients in buster that support ssl/tls.

There are at least tnftp, curl, and lftp. Please use one of them.


Actually, tnftp can only use TLS for HTTPS, not for FTPS.
As the backport will probably not happen on an orphaned package, I am tagging 
this wontfix.
Still, you can do the backport yourself.

Bug#1001073: network-manager-openvpn: [bullseye] importing ovpn file using GUI results in non-functional VPN (fails due to auth timeout)

[Nicholas D Steeves]

Package: network-manager-openvpn
Version: 1.8.12-2
Severity: important
X-Debbugs-Cc: Michael Biebl , Mike Gabriel 

Control: tags bullseye upstream fixed-upstream

Dear Michael and Mike,

I'm CCing you because I suspect the Utopia team might not read bugs
sent to pkg-utopia-maintain...@alioth-lists.debian.net...I'm sorry if
that's an unfair assessment, it just feels that way looking at the
bugs for network-manager-openvpn.  Mike, apologies if you're not part
of the team--I seem to remember that you were involved in a
Utopia-related tray applet, but maybe not?

I discovered this bug when I upgraded to testing before bullseye's
release, and I'm sorry that I did not report it until now.

With KDE/Plasma, after importing an OpenVPN configuration from an ovpn
config file, using the KDE/Plasma NM gui, the OpenVPN connection fails
after timing out during authentication.  Beyond that, there was
nothing useful in the log.  A manual CLI OpenVPN connection worked
100% fine.  I initially thought that the bug was in the config import
function, so after importing, I manually configured the connection to
the settings that are specified in the ovpn file, and the ones that I
knew would work.  Same problem...

The nature of this bug appears to be that network-manager-openvpn does
not pass the configuration defined in the GUI to OpenVPN daemon, thus
the OpenVPN connection fails.

I then created a local bpo of network-manager-openvpn_1.8.16-1, and
installed it, to see if this would solve the problem.  It solved the
problem.

The fix for bullseye should cherry-picked from upstream VCS to make
this package usable on Debian stable, because "The Debian Desktop
doesn't work with commercial VPNs" harms Debian's reputation IMHO.

Regards,
Nicholas

Bug#1000976: plasma-systemmonitor: doesnt start - QQmlApplicationEngine failed to load component

[Emilian Nowak]

I didn't have that one, but after installing it fails with the following
message:

QQmlApplicationEngine failed to load component
file::/main.qml:89:21: Type NewStuff.Action unavailable
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/newstuff/qml/Action.qml:181:13:
 Type NewStuff.Page unavailable
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/newstuff/qml/Page.qml:20:1: 
module "org.kde.kcm" is not installed

If this are all some dependencies why aren't they in package dependecny ? 

 On 2021-12-02, at 09:19:51 Patrick Franz wrote:

> Hi Emilian,
> 
> do you have "qml-module-qtquick-dialogs" installed ? That seems to be 
> missing.
> 
> -- 
> Med vänliga hälsningar
> 
> Patrick Franz

Bug#1001072: O: netkit-ftp-ssl -- FTP client with TLS support

[Bastian Germann]

Package: wnpp

netkit-ftp-ssl is unmaintained/non-existing upstream and the package seems to 
be unmaintained as well
(see related #986997).

The current maintainer of netkit-ftp-ssl, Mats Erik Andersson,
is apparently not active anymore. Therefore, this package has been orphaned.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o
for detailed instructions how to adopt a package properly.

Bug#995494: bullseye-pu: package vim/2:8.2.2434-3+deb11u1

[James McCoy]

On Fri, Dec 03, 2021 at 04:45:57PM +, Adam D. Barratt wrote:
> It might be clearer for the alternatives bug to have a fixed version to
> indicate that it doesn't affect the package in testing/unstable in
> practice, although I'm not quite sure what it should be - maybe the
> first upload after buster's version?

Would applying the "bullseye" tag to the bug achieve be enough?

> Please go ahead, thanks.

Will do, thanks.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1001016: telegram-desktop: Version in stable (2.6.1) becoming unusable

[Ralf Neubauer]

Hi,

ok, your mail arrived while I wrote my last one and I only saw it after
sending.

I am upgrading to 2.9.2+ds-1~bpo11+1 now -- one machine is done, the
others will follow (the messages in the 'Telegram' channel confusingly
also appear in the up-to-date iOS app so I will have to update all
clients). I think I will see tomorrow or in the next couple of days if I
still get these messages. Or faster -- the message box appeared again,
maybe it is set every couple of minutes?

Wasn't there a similar problem with firefox where a solution was worked
out to follow upstream more closely?

Thank you so far!

Ralf

On Fri, Dec 03, 2021 at 08:11:10PM +0300, Nicholas Guriev wrote:
> Hello!
> 
> Could you test version 2.9.2 from backports? Does the message appear
> there?
> For a backports guide see: https://backports.debian.org/Instructions/
> 
> If even this version is considered ancient, I could backport 3.1.1 from
> testing. I am sure it still is working.
> 
> From what I know, versions older that 3.1.1 are unable to operate for
> newly registered users whose UIDs do not fit signed 32bit. However, the
> older versions continue to work for already existing users.
> 
> As a maintainer I can only offer you to switch to backports repository.
> Release managers do not happy with huge updates after Debian freeze.
> Telegram team in their turn is primarily focused on implementing new
> features. The goals seem contradictory, and users stuck between a rock
> and a hard place.
> 



-- 
  72 61 6c 66 40 73 74 72 : 63 6d 70 2e 64 65 0a r...@strcmp.de. 

Bug#1001016: More messages -- seems to be urgent

[Ralf Neubauer]

Hi,

I got the message "Please update your app to the latest version. The
version you are using is out of date and will stop working soon." again.

Twice.

First in the 'Telegram' channel, than in a message box.

Obviously it is very urgent and the package will stop working completely
for all users in a couple of days.

I ask again if this is fully thought through. The Telegram people know
the version in Debian 11.1 is 2.6.1 and 11.1 is relatively fresh -- this
is public knowledge, after all. Don't they care about their users? How
can they kick out users of stable distros and not at least offer a
workaround? Why do they say 'please upgrade' (in an annoying way) if
they know I have no upgrading options? For me the desktop version is why
I use Telegram and not Signal or Threema.

Asked from the other perspective, what are the Debian plans to follow
Telegram's forced client upgrades?

Ralf

-- 
  72 61 6c 66 40 73 74 72 : 63 6d 70 2e 64 65 0a r...@strcmp.de. 

Bug#996668: cinnamon-settings-daemon: cinnamon shutdown hang

[Fabio Fantoni]

Il 03/12/2021 09:50, Nikos K ha scritto:

Dear Maintainer,

i have exactly the same problem on a fresh install of debian sid on a 
new laptop.


I could even reproduce the issue on an install on a KVM virtual machine.

On both I used the dailynetiboot image 
[https://d-i.debian.org/daily-images/amd64/20211202-00:16/netboot/mini.iso]



Occurred on both on the first reboot after Installation. No other 
software installed. Only the desktop and cinnamon-desktop tasks from 
tasksel during the installation process (and laptop for the laptop).



On the laptop it occurs on each reboot. On the VM it does not always 
happen. Seems random.


The log entries are similar as above.


/If you need anything else, please let me know./

Thanks for replay, today I found the vm of clean Sid I used for testing 
cinnamon 4.8 packages before upload and was unable to reproduce, on 
updated clean Sid done today I finally reproduced it, I did some check 
and tests but I wasn't able to solves it for now.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001060: jool-tools: joold state syncer fails on linux >= 5.10

[Alberto Leiva]

Ok. You're right; I should release 4.1.6 already.

I've scheduled to do it next week. It should be out by next Friday.

(But 4.1.6-1 will migrate to testing later, of course.)

On Fri, Dec 3, 2021 at 6:15 AM Philipp S. Tiesel  <
ph...@in-panik.de> wrote:

> Package: jool-tools
> Version: 4.1.5-1
> Severity: normal
> Tags: patch upstream
>
> Dear Maintainer,
>
> jool uses a state syncer called joold, which stopped to work on
> linux > 5.10. The bug has been fixt in the upstream repository,
> but no new version has been release.
>
> Bug on Github: https://github.com/NICMx/Jool/issues/362
> Patch on Github:
> https://github.com/NICMx/Jool/commit/6f3ad879fe567713e092e6b024349b519cb247bf
>
> -- System Information:
> Debian Release: 11.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'oldstable-updates'), (500, 'stable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set
> LC_ALL to default locale: No such file or directory
> UTF-8), LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages jool-tools depends on:
> ii  init-system-helpers  1.60
> ii  libc62.31-13+deb11u2
> ii  libnl-3-200  3.4.0-1+b1
> ii  libnl-genl-3-200 3.4.0-1+b1
>
> Versions of packages jool-tools recommends:
> ii  jool-dkms  4.1.5-1
>
> jool-tools suggests no packages.
>
> -- debconf information excluded
>

Bug#1001016: telegram-desktop: Version in stable (2.6.1) becoming unusable

[Nicholas Guriev]

Hello!

Could you test version 2.9.2 from backports? Does the message appear
there?
For a backports guide see: https://backports.debian.org/Instructions/

If even this version is considered ancient, I could backport 3.1.1 from
testing. I am sure it still is working.

From what I know, versions older that 3.1.1 are unable to operate for
newly registered users whose UIDs do not fit signed 32bit. However, the
older versions continue to work for already existing users.

As a maintainer I can only offer you to switch to backports repository.
Release managers do not happy with huge updates after Debian freeze.
Telegram team in their turn is primarily focused on implementing new
features. The goals seem contradictory, and users stuck between a rock
and a hard place.



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

Bug#1000811: bullseye-pu: package debian-edu-doc/2.11.26+deb11u1

[Holger Levsen]

On Mon, Nov 29, 2021 at 01:38:19PM +0100, Wolfgang Schweer wrote:
> Holger Levsen will do the upload.

this has been done now.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

:wq


signature.asc
Description: PGP signature

Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1

[Shengjing Zhu]

On Sat, Dec 4, 2021 at 12:30 AM Julien Cristau  wrote:
>
> On Sat, Dec 04, 2021 at 12:28:27AM +0800, Shengjing Zhu wrote:
> > On Fri, Dec 03, 2021 at 04:32:16PM +0100, Julien Cristau wrote:
> > > Control: tag -1 confirmed
> > >
> > > On Sat, Sep 11, 2021 at 06:04:13PM +0800, Shengjing Zhu wrote:
> > > > +golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
> > >
> > > This looks fine to me, go ahead.
> >
> > Thanks for the review. I'm not sure if it's too late to amend this
> > update.
> >
> Might be best to go with the original one first, and file a new bug for
> the new changes, because I don't know when I can get to reviewing more.
>

Uploaded with the original one.

-- 
Shengjing Zhu

Bug#951113: ITP: webp-pixbuf-loader -- WebP Image format GdkPixbuf loader.

[Vieno Hakkerinen]

Any news about this issue?

I stumbled over this while searching why eyeOfGnome does not show WebP 
images. I would be happy to view WebP images with eog.


kind regards
txt.file

On Thu, 29 Oct 2020 16:05:45 +0100 David Heidelberg  wrote:

Current debian packaging can be found here:
https://salsa.debian.org/okias-guest/webp-pixbuf-loader
Best regards
David Heidelberg

Bug#1001071: RFS: opendmarc/1.4.0~beta1+dfsg-6+deb11u1 -- Milter implementation of DMARC

[David Bürgin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opendmarc
   Version : 1.4.0~beta1+dfsg-6+deb11u1
   Upstream Author : The Trusted Domain Project
 * URL : http://www.trusteddomain.org/opendmarc
 * License : GPL-3+ with AutoConf exception, BSD-3-clause and SOSL, 
BSD-2-clause
 * Vcs : https://salsa.debian.org/kitterman/opendmarc
   Section : mail

It builds those binary packages:

  opendmarc - Milter implementation of DMARC
  libopendmarc2 - Library for DMARC validation and reporting
  libopendmarc-dev - Headers and development libraries for the OpenDMARC library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opendmarc/opendmarc_1.4.0~beta1+dfsg-6+deb11u1.dsc

Changes since the last upload:

 opendmarc (1.4.0~beta1+dfsg-6+deb11u1) stable; urgency=medium
 .
   * Amend patch "ticket193.patch" (Closes: #995694):
 - Remove unexplained diff that breaks opendmarc-import
   * Add patch "arcseal-segfaults.patch" (Closes: #995703):
 - Fix segfaults, increase token max lengths in ARC-Seal headers

NOTE: The stable update was approved by the release team, see #998436.

Thank you!


-- 
David

Bug#1000448: bullseye-pu: package containerd/1.4.12~ds1-1~deb11u1

[Shengjing Zhu]

On Sat, Dec 4, 2021 at 12:11 AM Adam D. Barratt
 wrote:
>
> Control: tags -1 + confirmed
>
> On Tue, 2021-11-23 at 19:27 +0800, Shengjing Zhu wrote:
> > I'd like to update containerd in bullseye to latest upstream
> > patch version. Upstream does maintain a stable release branch
> > 1.4.x with only backporting important bugfix.
> >
> > Notably:
> > 1.4.12~ds1-1~deb11u1 will have:
> >
> > + Workaround for "clone3" syscall. So users can run images like
> >   fedora:rawhide, ubuntu:impish, which has enabled clone3 syscall
> >   in glibc.
> >   See also https://bugs.launchpad.net/cloud-images/+bug/1943049
> > + Mitigate CVE-2021-41190: Handle ambiguous OCI manifest parsing
> > + Backport RPi1/RPi0 workaround #998909
> >
>
> Please go ahead.
>

Uploaded.

-- 
Shengjing Zhu

Bug#999533: matplotlib: python3-pil.imagetk should be Depends

[Sandro Tosi]

control: severity -1 normal

> > This is not a bug in cartopy, matplotlib tries to use ImageTk but the
> > package is not installed.
> >
> > python3-matplotlib only Recommends python3-pil.imagetk, this should be a
> > Depends.
>
> This issue is still present in matplotlib (3.5.0-2) and affects several
> packages. These should not have to add python3-pil.imagetk to their
> build dependencies because matplotlib does not pull it in.

this is done on purpose, so that people can switch backend and remove
the underlying package without causing apt to want to remove also
python3-matplotlib.

All the backend packages are in Recommends for a reason.

If you need a different backend during build, please set the backend
rcparams accordingly during your package build.

Bug#995394: bullseye-pu: package horizon/3:18.6.2-5

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-09-30 at 17:03 +0200, Thomas Goirand wrote:
> For some reasons, the compiled .mo translations were
> disabled in the package. This update will re-activate them.
> 
> [ Reason ]
> I'm really not sure why this was desactivated (I don't remember).
> 
> [ Impact ]
> No translations available in the OpenStack Dashboard.
> 

Please go ahead.

Regards,

Adam

Bug#996772: luakit: Provide www-browser

[Bastian Germann]

On Tue, 19 Oct 2021 11:59:53 +0200 Markus Demleitner  wrote:

On Mon, Oct 18, 2021 at 02:55:37PM +0200, Bastian Germann wrote:
> Package: luakit
> Severity: wishlist
> 
> luakit should provide the virtual package www-browser to help finding it

> when searching for a browser.

Good point.  I've added a corresponding line in commit edfd18d8, so
this should come with the next release.


When will 1:2.3-1 be released?
Note that you have referenced the change in a new -1.1 changelog entry even 
though -1 is not released yet.
I can offer sponsoring the release if you lack a sponsor.

Bug#995494: bullseye-pu: package vim/2:8.2.2434-3+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-10-01 at 22:30 -0400, James McCoy wrote:
> * Vim has some recent "no DSA" CVEs which, although unlikely to hit,
>   would be good to fix (#994497, #994498, #994076)
> 
> * In the buster -> bullseye upgrade, vim-gtk becomes a transitional
>   package, switching to vim-gtk3.  The vim-gtk alternatives weren't
>   cleaned up, so there's a lot of noise during the upgrade about
>   dangling links for alternatives and a window where the symlinks may
>   not exist (#993766).

It might be clearer for the alternatives bug to have a fixed version to
indicate that it doesn't affect the package in testing/unstable in
practice, although I'm not quite sure what it should be - maybe the
first upload after buster's version?

Please go ahead, thanks.

Regards,

Adam

Bug#996025: bullseye-pu: package libseccomp/2.5.1-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-11-25 at 19:29 +0100, Felix Geyer wrote:
> On Sun, 10 Oct 2021 14:34:30 +0200 Felix Geyer 
> wrote:
> > libseccomp 2.5.1 only knows about syscall up to Linux 5.8.
> > The proposed changes add the syscalls up to Linux 5.14.
> 
[...]
> I've updated the debdiff to include two more cherry-picked patches
> that add
> a new syscalls from Linux 5.15 and missing syscall defines.
> 

Please go ahead.

Regards,

Adam

Bug#996026: bullseye-pu: package ruby-httpclient/2.8.3-3+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2021-10-10 at 09:40 -0300, Antonio Terceiro wrote:
> ruby-httpclient uses a vendored copy of a CA certificate bundle, and
> that is a ticking time bomb. This update fixes that by removing that
> vendored copy and making it use the system CA certificate bundle by
> default.
> 
> [ Impact ]
> The main package affected by this is apt-listbugs, which stopped
> being
> able to download bug data information from bugs.debian.org due to the
> recent expiration of the old Let's Encrypt root certificate.
> 

Please go ahead, thanks.

Regards,

Adam

Bug#1001070: command-not-found: crashes when entering an unknown command

[Frank Heckenbach]

Package: command-not-found
Version: 20.10.1-1
Severity: grave
Justification: renders package unusable

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917455

Bug #917455 was closed with:

  Marked as fixed in versions 20.10.1-1

This is *NOT* the case!

After upgrading to bullseye, which includes
command-not-found 20.10.1-1, the bug is there again!

% foo
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.9.2 final 0
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Exception information:

unable to open database file
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 90, in main
cnf = CommandNotFound.CommandNotFound(options.data_dir)
  File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 
79, in __init__
self.db = SqliteDatabase(dbpath)
  File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in 
__init__
self.con = sqlite3.connect(filename)
sqlite3.OperationalError: unable to open database file

The temporary fix still works:

  sudo chmod 644 /var/lib/command-not-found/commands.db

But after the next update, the permissions are set wrong again.

The actual fix is (and probably always has been) to set in
/sbin/update-command-not-found:

  os.umask (0o022)

I see no trace of this having been done. In fact, there's no
occurrence of "umask" anywhere in the sources (including Debian
patches) -- except for debian/changelog!??? (And a much older
changelog entry anyway.)

So it doesn't seem this bug was actually ever fixed.

Bug#997597: bullseye-pu: package chrony/4.0-8+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-10-23 at 23:14 +0200, Vincent Blut wrote:
> chrony 4.0 allows binding the NTP, NTS-KE, client and UDP command
> sockets 
> to a specific network device using the 'binddevice', 'bindacqdevice'
> and
> 'bindcmddevice' directives.
> In Bullseye, using these directives with a network interface name
> longer
> than 3 characters (e.g. binddevice eth0) will cause chronyd to crash
> because
> of the way the system call filter handles the SO_BINDTODEVICE socket
> option.
> 
> [ Impact ]
> To bind sockets to a network interface with a "long" name, users have
> to
> disable chronyd's system call filter which is certainly not ideal.
> 

Please go ahead, thanks.

Regards,

Adam

Bug#996728: bullseye-pu: package mrtg/2.17.7-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2021-10-17 at 16:27 -0300, Joao Eriberto Mota Filho wrote:
> This update is not for a regression. I am the new maintainer of the
> mrtg. When
> checking for spelling errors, I found two spelling errors in
> variables names in
> the source code. These errors generated the bugs #995950 and #996090.
> 

Please go ahead, thanks.

Regards,

Adam

Bug#996623: bullseye-pu: package node-getobject/0.1.0-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2021-10-16 at 14:00 +0200, Yadd wrote:
> Another prototype pollution (CVE-2020-28282)
> 

Please go ahead, thanks.

Regards,

Adam

Bug#998436: bullseye-pu: package opendmarc/1.4.0~beta1+dfsg-6+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-11-04 at 10:01 +0100, David Bürgin wrote:
> Since releasing the opendmarc version in Debian bullseye, two
> important
> issues affecting it have been reported upstream.
> 
> [ Impact ]
> 1) opendmarc-import is broken in Debian bullseye (regression).
>https://github.com/trusteddomainproject/OpenDMARC/issues/189
> 2) opendmarc crashes when receiving certain ARC-Seal headers.
>https://github.com/trusteddomainproject/OpenDMARC/issues/183
> 

Please go ahead.

Regards,

Adam

Bug#998832: bullseye-pu: package jqueryui/1.12.1+dfsg-8+deb11u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2021-11-09 at 08:25 +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Mon, Nov 08, 2021 at 12:27:03PM +0100, Yadd wrote:
[...]
> > Jquery-UI is the official jQuery user interface library. Prior to
> > version
> > 1.13.0, accepting the value of the `of` option of the `.position()`
> > util
> > from untrusted sources may execute untrusted code. The issue is
> > fixed in
> > jQuery UI 1.13.0. Any string value passed to the `of` option is now
> > treated
> > as a CSS selector. A workaround is to not accept the value of the
> > `of`
> > option from untrusted sources. (CVE-2021-41184)
> 
> AFAICS there are two more CVEs for jqueryui which wree fixed in
> 1.13.0
> and so covered in unstable already. Can those be backported as well
> or
> are they too intrusive?
> 

Quick ping on this.

Regards,

Adam

Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1

[Julien Cristau]

On Sat, Dec 04, 2021 at 12:28:27AM +0800, Shengjing Zhu wrote:
> On Fri, Dec 03, 2021 at 04:32:16PM +0100, Julien Cristau wrote:
> > Control: tag -1 confirmed
> > 
> > On Sat, Sep 11, 2021 at 06:04:13PM +0800, Shengjing Zhu wrote:
> > > +golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
> > 
> > This looks fine to me, go ahead.
> 
> Thanks for the review. I'm not sure if it's too late to amend this
> update.
> 
Might be best to go with the original one first, and file a new bug for
the new changes, because I don't know when I can get to reviewing more.

Cheers,
Julien

Bug#998902: Reopening: bullseye-pu: package htmldoc/1.9.11-4

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2021-11-15 at 17:56 +0100, Håvard Flaget Aasen wrote:
> Control: reopen 998902
> 
> On Sat, 13 Nov 2021 00:17:02 +0100
> =?UTF-8?Q?H=C3=A5vard_Flaget_Aasen?=  wrote:
> > CVE-2021-40985 has now been marked as unimportant, I'm therefore
> > closing this bug, since the CVE was the sole purpose of the update.
> > 
> > Regards,
> > Håvard
> > 
> > 
> After some information in [1] I'm reopening this.
> 
> All the previous information still holds true, but the proposed
> update
> has been expanded to include a fix for both CVE-2021-40985 and
> CVE-2021-43579.
> The upstream release fixing these issues has migrated to testing
> (1.9.13) and I have verified that the patches indeed prevent
> buffer-overflow in bullseye.
> 

Please go ahead.

Regards,

Adam

Bug#1000454: bullseye-pu: package gdal/3.2.2+dfsg-2+deb11u1

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo

On 12/3/21 17:16, Adam D. Barratt wrote:

On Tue, 2021-11-23 at 14:34 +0100, Bas Couwenberg wrote:

The LVBAG driver in GDAL 3.2.2 is unable to process BAG 2.0 Extract
files
correctly. Since October 2021 BAG 1.0 Extract files are no longer
updated,
so users are expected to switch their processing to BAG 2.0.

GDAL 3.3.0 and 3.4.0 contain changes required to process BAG 2.0
Extract
files correctly.



diff -Nru 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
--- 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
  1970-01-01 01:00:00.0 +0100
+++ 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
  2021-11-23 10:11:54.0 +0100
@@ -0,0 +1,170 @@
+Description: Add a cppcheck_2004 CI target, and fix related issues
+Author: Even Rouault 
+Origin: 
https://github.com/OSGeo/gdal/commit/6ff924dfc704776cbdeff1e0e23da6452cf06933
+Bug: https://github.com/OSGeo/gdal/pull/3516
+
+--- a/ogr/ogrsf_frmts/lvbag/ogrlvbaglayer.cpp
 b/ogr/ogrsf_frmts/lvbag/ogrlvbaglayer.cpp

This is a little confusing. The upstream commit in question touches 24
files, but this patch only changes one. Is that intentional? If so, the
patch header could do with some more information, because it doesn't
appear that the patch actually includes the change mentioned in the
description.


The description comes from the commit message.

The patch only includes the cppcheck fixes for the LVBAG driver.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1

[Shengjing Zhu]

On Fri, Dec 03, 2021 at 04:32:16PM +0100, Julien Cristau wrote:
> Control: tag -1 confirmed
> 
> On Sat, Sep 11, 2021 at 06:04:13PM +0800, Shengjing Zhu wrote:
> > +golang-1.15 (1.15.15-1~deb11u1) bullseye; urgency=medium
> 
> This looks fine to me, go ahead.

Thanks for the review. I'm not sure if it's too late to amend this
update.

I'd like to add two patches.

Amend for d/changelog:

  * Backport patch for CVE-2021-38297
When invoking functions from WASM modules, built using GOARCH=wasm GOOS=js,
passing very large arguments can cause portions of the module to be 
overwritten
with data from the arguments.
  * Backport patch for CVE-2021-41771
debug/macho: invalid dynamic symbol table command can cause panic

Amend two files in d/patches (attached)

+ debian/patches/0008-CVE-2021-38297.patch
  This patch is small. Backport from upstream 1.16 branch directly without 
modification.
+ debian/patches/0009-CVE-2021-41771.patch
  This is patch contains a large base64 testdata file, just for testing. 
Otherwise it's
  small as well.
  And it's also backport from upstream 1.16 branch directly with modification.

Other info:

The debian security tracker says golang-1.15 also affects CVE-2021-41772, but 
after checking
myself I think the affected code is introduced in golang 1.16

The debian security tracker also doesn't mention CVE-2021-38297

I will talk to security team to update the status on tracker.
From: Michael Knyszek 
Date: Thu, 2 Sep 2021 16:51:59 -0400
Subject: CVE-2021-38297

Origin: backport, https://github.com/golang/go/commit/4548fcc8
---
 misc/wasm/wasm_exec.js   |  7 +++
 src/cmd/link/internal/ld/data.go | 11 ++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/misc/wasm/wasm_exec.js b/misc/wasm/wasm_exec.js
index 8501ae7..b56f3f1 100644
--- a/misc/wasm/wasm_exec.js
+++ b/misc/wasm/wasm_exec.js
@@ -527,6 +527,13 @@
 offset += 8;
 			});
 
+			// The linker guarantees global data starts from at least wasmMinDataAddr.
+			// Keep in sync with cmd/link/internal/ld/data.go:wasmMinDataAddr.
+			const wasmMinDataAddr = 4096 + 4096;
+			if (offset >= wasmMinDataAddr) {
+throw new Error("command line too long");
+			}
+
 			this._inst.exports.run(argc, argv);
 			if (this.exited) {
 this._resolveExitPromise();
diff --git a/src/cmd/link/internal/ld/data.go b/src/cmd/link/internal/ld/data.go
index 2b55a5f..ee5c794 100644
--- a/src/cmd/link/internal/ld/data.go
+++ b/src/cmd/link/internal/ld/data.go
@@ -2268,6 +2268,11 @@ func assignAddress(ctxt *Link, sect *sym.Section, n int, s loader.Sym, va uint64
 	return sect, n, va
 }
 
+// On Wasm, we reserve 4096 bytes for zero page, then 4096 bytes for wasm_exec.js
+// to store command line args. Data sections starts from at least address 8192.
+// Keep in sync with wasm_exec.js.
+const wasmMinDataAddr = 4096 + 4096
+
 // address assigns virtual addresses to all segments and sections and
 // returns all segments in file order.
 func (ctxt *Link) address() []*sym.Segment {
@@ -2277,10 +2282,14 @@ func (ctxt *Link) address() []*sym.Segment {
 	order = append(order, )
 	Segtext.Rwx = 05
 	Segtext.Vaddr = va
-	for _, s := range Segtext.Sections {
+	for i, s := range Segtext.Sections {
 		va = uint64(Rnd(int64(va), int64(s.Align)))
 		s.Vaddr = va
 		va += s.Length
+
+		if ctxt.IsWasm() && i == 0 && va < wasmMinDataAddr {
+			va = wasmMinDataAddr
+		}
 	}
 
 	Segtext.Length = va - uint64(*FlagTextAddr)
From: Roland Shoemaker 
Date: Thu, 14 Oct 2021 13:02:01 -0700
Subject: CVE-2021-41771

Origin: backport, https://github.com/golang/go/commit/d19c5bdb
---
 src/debug/macho/file.go  | 9 +
 src/debug/macho/file_test.go | 7 +++
 .../macho/testdata/gcc-amd64-darwin-exec-with-bad-dysym.base64   | 1 +
 3 files changed, 17 insertions(+)
 create mode 100644 src/debug/macho/testdata/gcc-amd64-darwin-exec-with-bad-dysym.base64

diff --git a/src/debug/macho/file.go b/src/debug/macho/file.go
index 085b0c8..73cfce3 100644
--- a/src/debug/macho/file.go
+++ b/src/debug/macho/file.go
@@ -345,6 +345,15 @@ func NewFile(r io.ReaderAt) (*File, error) {
 			if err := binary.Read(b, bo, ); err != nil {
 return nil, err
 			}
+			if hdr.Iundefsym > uint32(len(f.Symtab.Syms)) {
+return nil, {offset, fmt.Sprintf(
+	"undefined symbols index in dynamic symbol table command is greater than symbol table length (%d > %d)",
+	hdr.Iundefsym, len(f.Symtab.Syms)), nil}
+			} else if hdr.Iundefsym+hdr.Nundefsym > uint32(len(f.Symtab.Syms)) {
+return nil, {offset, fmt.Sprintf(
+	"number of undefined symbols after index in dynamic symbol table command is greater than symbol table length (%d > %d)",
+	hdr.Iundefsym+hdr.Nundefsym, len(f.Symtab.Syms)), nil}
+			}
 			dat := make([]byte, hdr.Nindirectsyms*4)
 			if _, err := r.ReadAt(dat, int64(hdr.Indirectsymoff)); err != nil {
 return nil, err
diff --git 

Bug#994064: bullseye-pu: package python-eventlet/0.26.1-7

[Julien Cristau]

Control: tag -1 confirmed

Hi Thomas,

A couple of comments on the diff below, otherwise fine to go ahead.

On Fri, Sep 10, 2021 at 09:50:25PM +0200, Thomas Goirand wrote:
> diff -Nru python-eventlet-0.26.1/debian/greendns.orig.py 
> python-eventlet-0.26.1/debian/greendns.orig.py
> --- python-eventlet-0.26.1/debian/greendns.orig.py2021-05-11 
> 08:03:43.0 +0200
> +++ python-eventlet-0.26.1/debian/greendns.orig.py2021-09-10 
> 21:42:12.0 +0200

That looks odd, this file probably shouldn't be there?

[...]
> diff -Nru python-eventlet-0.26.1/debian/greendns.py 
> python-eventlet-0.26.1/debian/greendns.py
> --- python-eventlet-0.26.1/debian/greendns.py 2021-05-11 08:03:43.0 
> +0200
> +++ python-eventlet-0.26.1/debian/greendns.py 2021-09-10 21:42:12.0 
> +0200
[...]
>  def tcp(q, where, timeout=DNS_QUERY_TIMEOUT, port=53,
> @@ -794,7 +834,19 @@
>  @type source: string
>  @param source_port: The port from which to send the message.
>  The default is 0.
> -@type source_port: int"""
> +@type source_port: int
> +@type ignore_unexpected: bool
> +@param one_rr_per_rrset: If True, put each RR into its own
> +RRset.
> +@type one_rr_per_rrset: bool
> +@param ignore_trailing: If True, ignore trailing
> +junk at end of the received message.
> +@type ignore_trailing: bool
> +@param sock: the socket to use for the
> +query.  If None, the default, a socket is created.  Note that
> +if a socket is provided, it must be a nonblocking datagram socket,
> +and the source and source_port are ignored.
> +@type sock: socket.socket | None"""
>  
>  wire = q.to_wire()
>  if af is None:

The doc for sock here looks like a copy/paste error from the udp case,
and should be a TCP socket instead.

Looks like
https://github.com/eventlet/eventlet/blob/master/eventlet/support/greendns.py#L861
still has it wrong.

> @@ -810,7 +862,10 @@
>  destination = (where, port, 0, 0)
>  if source is not None:
>  source = (source, source_port, 0, 0)
> -s = socket.socket(af, socket.SOCK_STREAM)
> +if sock:
> +s = sock
> +else:
> +s = socket.socket(af, socket.SOCK_STREAM)
>  s.settimeout(timeout)
>  try:
>  expiration = compute_expiration(dns.query, timeout)

Cheers,
Julien

Bug#1000485: bullseye-pu: package btrbk/0.27.1-1.1+deb11u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-11-23 at 23:22 +, Thorsten Alteholz wrote:
> The attached debdiff for btrbk fixes a regression of CVE-2021-38173
> in
> Bullseye.
> 
> The regression was reported in #996260 [1] and a pointer to the fix
> was
> provided. There was at least one report about a now working version 
> +deb10u2 in Buster, which is based on the same version as Bullseye.
> 
>Thorsten
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996260

++# NOTE: subvolume queries no NOT affected by "--restrict-path":

s/no NOT/are NOT/

Please go ahead.

Regards,

Adam

Bug#1000458: bullseye-pu: package wget/1.21-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Tue, 2021-11-23 at 15:43 +, plugwash wrote:
> When downloading a file greater than 2GB on a 32-bit system wget on
> bullseye
> will truncate it to 2GB. No error is reported, the length of the file
> is simply
> reported as less than it's true length. This was reported to me by
> raspberry pi
> staff, but I can reproduce it in a Debian i386 environment, so it's
> not
> raspberry pi, raspbian or arm specific.

+wget (1.21-1+deb11u1) bullseye-staging; urgency=medium

The distribution should simply by "bullseye".

This looks OK to me, but will need a di-ack, as wget builds a udeb.
Tagging and CCing appropriately.

Regards,

Adam

Bug#1000454: bullseye-pu: package gdal/3.2.2+dfsg-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2021-11-23 at 14:34 +0100, Bas Couwenberg wrote:
> The LVBAG driver in GDAL 3.2.2 is unable to process BAG 2.0 Extract
> files
> correctly. Since October 2021 BAG 1.0 Extract files are no longer
> updated,
> so users are expected to switch their processing to BAG 2.0.
> 
> GDAL 3.3.0 and 3.4.0 contain changes required to process BAG 2.0
> Extract
> files correctly.
> 

diff -Nru 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
--- 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
  1970-01-01 01:00:00.0 +0100
+++ 
gdal-3.2.2+dfsg/debian/patches/0001-Add-a-cppcheck_2004-CI-target-and-fix-related-issues.patch
  2021-11-23 10:11:54.0 +0100
@@ -0,0 +1,170 @@
+Description: Add a cppcheck_2004 CI target, and fix related issues
+Author: Even Rouault 
+Origin: 
https://github.com/OSGeo/gdal/commit/6ff924dfc704776cbdeff1e0e23da6452cf06933
+Bug: https://github.com/OSGeo/gdal/pull/3516
+
+--- a/ogr/ogrsf_frmts/lvbag/ogrlvbaglayer.cpp
 b/ogr/ogrsf_frmts/lvbag/ogrlvbaglayer.cpp

This is a little confusing. The upstream commit in question touches 24
files, but this patch only changes one. Is that intentional? If so, the
patch header could do with some more information, because it doesn't
appear that the patch actually includes the change mentioned in the
description.

Regards,

Adam

Bug#993809: bullseye-pu: package segemehl/0.3.4-3+deb11u1 (Pre-approval)

[Julien Cristau]

On Tue, Sep 07, 2021 at 12:27:05AM +0530, Nilesh Patra wrote:
> diff -Nru segemehl-0.3.4/debian/patches/arm64.patch 
> segemehl-0.3.4/debian/patches/arm64.patch
> --- segemehl-0.3.4/debian/patches/arm64.patch 1970-01-01 05:30:00.0 
> +0530
> +++ segemehl-0.3.4/debian/patches/arm64.patch 2021-09-06 23:43:50.0 
> +0530
> @@ -0,0 +1,75 @@
> +Description: Change the signed-ness for several chars to fix segfault
> +Author: Nilesh Patra 
> +Last-Update: 2021-08-24
> +--- a/libs/biofiles.c
>  b/libs/biofiles.c
> +@@ -1916,7 +1916,7 @@
> + Uint max, Uint *minlen, Uint *maxlen, unsigned char *minq, unsigned 
> char *maxq) 
> + {
> + 
> +-  char ch;
> ++  signed char ch;
> +   char idchar=0;
> +   int ret=0;
> +   off_t curseqoffset, lastindexoffset=0;

Shouldn't `ch` be an `int` instead, to match the return value of getc,
and type of EOF?

Anyway, I guess this is fine if it works...

Cheers,
Julien

Bug#1000448: bullseye-pu: package containerd/1.4.12~ds1-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-11-23 at 19:27 +0800, Shengjing Zhu wrote:
> I'd like to update containerd in bullseye to latest upstream
> patch version. Upstream does maintain a stable release branch
> 1.4.x with only backporting important bugfix.
> 
> Notably:
> 1.4.12~ds1-1~deb11u1 will have:
> 
> + Workaround for "clone3" syscall. So users can run images like
>   fedora:rawhide, ubuntu:impish, which has enabled clone3 syscall
>   in glibc.
>   See also https://bugs.launchpad.net/cloud-images/+bug/1943049
> + Mitigate CVE-2021-41190: Handle ambiguous OCI manifest parsing
> + Backport RPi1/RPi0 workaround #998909
> 

Please go ahead.

Regards,

Adam

Bug#1000377: bullseye-pu: package node-json-schema/0.3.0+_7.0.6-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2021-11-22 at 10:50 +0100, Yadd wrote:
> node-json-schema is vulnerable to prototype pollution
> 

Please go ahead.

Regards,

Adam

Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-11-26 at 22:32 -0800, Otto Kekäläinen wrote:
> Thanks Paul for the schedule update. Maybe link those emails from
> release.debian.org so that they are easy to find in the future..?
> 

The mail in question is about finding dates when people are available,
so linking to them from the homepage would be premature. Once a date is
set, it is then added to the homepage and the ICS.

> Final changelog:
> 
> mariadb-10.5 (1:10.5.13-0+deb11u1) bullseye; urgency=medium
> 
>   [ Otto Kekäläinen ]
>   * New upstream version 10.5.13. Includes security fixes for:
> - CVE-2021-35604
>   * Drop MIPS and libatomic patches applied now upstream
> 
>   [ Bas Couwenberg ]
>   * Don't require debian.cnf to be executable in logrotate (Closes:
> #994284)
> 

Please go ahead.

Regards,

Adam

Bug#993796: bullseye-pu: package knot-resolver/5.3.1-1

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Sep 06, 2021 at 04:21:15PM +, Jakub Ružička wrote:
> [ Reason ]
> Fixing bug #991463 (CVE-2021-40083) - potential DoS.
> 
> [ Impact ]
> Vulnerability to DoS attack.
> 
> [ Tests ]
> I've tested the fix manually by running the deckard (DNS test harness)
> test sets/resolver/val_iter_high.rpl supplied with the upstream fix.
> 
> It's not trivial to setup system for deckard so I've used upstream
> Debian bullseye docker image from Knot CI:
> 
> docker run -it --privileged 
> registry.nic.cz/knot/knot-resolver/ci/debian-11:knot-3.0
> 
> With current knot-resolver-5.3.1-1 the test failed.
> With suggested knot-resolver-5.3.1-1+deb11u1 the test passed.
> 
> [ Risks ]
> This is a simple backport of upstream fix.
> 
> Upstream tests run during package build so chances of something
> breaking are small.
> 
> [ Checklist ]
>   [*] *all* changes are documented in the d/changelog
>   [*] I reviewed all changes and I approve them
>   [*] attach debdiff against the package in (old)stable
>   [*] the issue is verified as fixed in unstable
> 
Feel free to go ahead and upload, thank you.

Cheers,
Julien

Bug#999838: bullseye-pu: package grass/7.8.5-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

 On Wed, 2021-11-17 at 14:12 +0100, Bas Couwenberg wrote:
> [ Reason ]
> GDAL based GRASS utilities fail as reported in #999828. This is fixed
> in 7.8.6, but still affects 7.8.5 bullseye. Cherry-picking the fix
> from 7.8.6 resolves the issue.
> 

Please go ahead.

Regards,

Adam

Bug#999769: bullseye-pu: package calibre/5.12.0+dfsg-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2021-11-16 at 21:44 +0900, yokota wrote:
> Fix bug #998744 (calibre: Python byte-compile error when installing
> calibre).
> 

The metadata for the bug suggests that it affects unstable and is not
yet fixed there. Is that correct?

If it is, then unstable needs to be fixed first. If not, then please
add an appropriate fixed version to that bug, so that the situation is
clearer.

Regards,

Adam

Bug#998178: ITP: martchus-cpp-utilities -- C++ utility classes for Syncthing Tray

[Nicholas D Steeves]

Hi Hannah,

Please prioritise this package, since it's a build dependency of
martchus-qtutilities.  I'm sorry for having treated them as coequal when
they're not--this was my faulty assumption/oversight.

Hannah Rittich  writes:

> Hi Nicholas,
>
> On 21/11/2021 22:12, Nicholas D Steeves wrote
>> I've fixed all of these issues on my local branch, so if you find
>> this stuff boring I can take care of it.  If you're considering
>> pursuing Debian Maintainer (uploading) status it's important to learn
>> why these are significant.
>
> I do not mind doing these changes. If you, however, have already made
> them, it is rather pointless for me to do them again. But thanks for the
> heads-up.
>

Well, I didn't commit anything, having 'just made corrections when I
could find the time to, and then consulted the diff when I finally found
time to write a review email.  It's totally up to you whether or not you
want to participate in the didactic review/revise process.

>> Is there any reason you've chosen debhelper-compat 12 rather than
>> 13? If not, please use 13.
>
> No. I just copied that from some tutorial. ;)
>

I totally understand and did this too back in the day ;)

> On 22/11/2021 00:57, Nicholas D Steeves wrote:
>>> * source:Description does not yet appear to be supported by Policy
>>> (see bug #998165).  I think you're prioritising uploading this
>>> package rather than evolving Debian Policy, so I'd recommend
>> 
>> ... using the old copy & paste method for now, and reintroducing 
>> substvars once that Policy bug is resolved.
>
> You could just revert my last commit. Using the X-Description variable
> is accepted by lintian.
>

This isn't the nature of the issue.  Please see today's reply to the
martchus-qtutilities bug.

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#810149: There is a SVN repository available with a bugfixes dated 2012

[Mathieu Malaterre]

Control: found -1 0.4-1
Control: fixed -1 0.5~git20120106.409eb16-1

Integrated all changes from the latest git.

Bug#999673: lldpd 1.0.11-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 999673 = 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: lldpd
Version: 1.0.11-1+deb11u1

Explanation: fix heap overflow issue [CVE-2021-43612]; do not set VLAN tag if 
client did not set it

Bug#1000953: c-blosc: FTBFS on mips64el

[Håvard Flaget Aasen]

ons. 1. des. 2021 kl. 11:39 skrev Bastian Germann :
>
> Source: c-blosc
> Severity: serious
> Version: 1.21.1+ds2-1
>
> The build fails on mips64el with:
>
> 98% tests passed, 35 tests failed out of 1651
>
> Total Test time (real) = 452.24 sec
>
> The following tests FAILED:
>   1 - test_api (Failed)
>   2 - test_bitshuffle_leftovers (Failed)
> 270 - test_compressor (Failed)
> 672 - test_noinit (Failed)
> 673 - test_nolock (Failed)
> 674 - test_nthreads (Failed)
> 1606 - test_compat_blosc-1.11.1-blosclz.cdata (Failed)
> 1607 - test_compat_blosc-1.11.1-lz4.cdata (Failed)
> 1608 - test_compat_blosc-1.11.1-lz4hc.cdata (Failed)
> 1609 - test_compat_blosc-1.11.1-snappy.cdata (Failed)
> 1610 - test_compat_blosc-1.11.1-zlib.cdata (Failed)
> 1611 - test_compat_blosc-1.11.1-zstd.cdata (Failed)
> 1612 - test_compat_blosc-1.14.0-blosclz.cdata (Failed)
> 1613 - test_compat_blosc-1.14.0-lz4.cdata (Failed)
> 1614 - test_compat_blosc-1.14.0-lz4hc.cdata (Failed)
> 1615 - test_compat_blosc-1.14.0-snappy.cdata (Failed)
> 1616 - test_compat_blosc-1.14.0-zlib.cdata (Failed)
> 1617 - test_compat_blosc-1.14.0-zstd.cdata (Failed)
> 1618 - test_compat_blosc-1.18.0-blosclz-bitshuffle.cdata (Failed)
> 1619 - test_compat_blosc-1.18.0-blosclz.cdata (Failed)
> 1620 - test_compat_blosc-1.18.0-lz4-bitshuffle.cdata (Failed)
> 1621 - test_compat_blosc-1.18.0-lz4.cdata (Failed)
> 1622 - test_compat_blosc-1.18.0-lz4hc.cdata (Failed)
> 1623 - test_compat_blosc-1.18.0-zlib.cdata (Failed)
> 1624 - test_compat_blosc-1.18.0-zstd.cdata (Failed)
> 1625 - test_compat_blosc-1.3.0-blosclz.cdata (Failed)
> 1626 - test_compat_blosc-1.3.0-lz4.cdata (Failed)
> 1627 - test_compat_blosc-1.3.0-lz4hc.cdata (Failed)
> 1628 - test_compat_blosc-1.3.0-snappy.cdata (Failed)
> 1629 - test_compat_blosc-1.3.0-zlib.cdata (Failed)
> 1630 - test_compat_blosc-1.7.0-blosclz.cdata (Failed)
> 1631 - test_compat_blosc-1.7.0-lz4.cdata (Failed)
> 1632 - test_compat_blosc-1.7.0-lz4hc.cdata (Failed)
> 1633 - test_compat_blosc-1.7.0-snappy.cdata (Failed)
> 1634 - test_compat_blosc-1.7.0-zlib.cdata (Failed)
> Errors while running CTest
> make[1]: *** [Makefile:94: test] Error 8
> make[1]: Leaving directory '/<>/obj-mips64el-linux-gnuabi64'
> dh_auto_test: error: cd obj-mips64el-linux-gnuabi64 && make -j4 test 
> ARGS\+=--verbose ARGS\+=-j4 returned exit code 2
>

I believe it's related to cmake and the recently updated package.
The previous version of c-blosc (1.21.1+ds1-1) uploaded 2021-10-08
used cmake with version 3.21.3-4, it built successfully. Building
c-blosc with the current version of cmake fails, as does the earlier
versions of c-blosc, I tested 1.17.1+ds1-1, 1.20.1+ds1-2 and
1.21.1+ds1-1. What's strange is that it's only on mips64el the
testsuite fails, none of the other architectures seems to be affected.
I have yet to discover where the fault lies, if it's cmake itself or
the CMakeLists.txt in c-blosc.

The solution to make the testsuite succeed is to override the cmake
flag provided by debhelper '-DCMAKE_BUILD_TYPE=None' Changing this to
'Release' is enough to make the testsuite succeed.


Regards,
Håvard

Bug#998252: authheaders 0.13.1-1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 998252 = 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: authheaders
Version: 0.13.1-1

Explanation: new upstream bug-fix release

Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2021-12-01 at 11:06 +0100, Helmut Grohne wrote:
> Control: tags -1 - moreinfo
> 
> Hi Adam,
> 
> On Tue, Nov 30, 2021 at 08:25:57PM +, Adam D. Barratt wrote:
> > What's the potential impact of the change? Is "curl-config --
> > configure" 
> > consumed by anything, other than human eyeballs?
> 
> curl-config is mainly meant for machine consumption. It kinda is a
> predecessor of pkg-config.
> 
> Preconditions to be affected:
>  * You must perform a build of a software using one of the
>libcurl*-*-dev packages.
>  * Your build must not use pkg-config (very uncommon), but rather use
>curl-config.
>  * Your build consumes curl-config --cflags (roughly equivalent to
>pkg-config --cflags libcurl).
> 
> As such I think that the number of affected users is fairly small
> (due to the requirement of not using pkg-config).
> 

Thanks for the detailed explanation. Please go ahead.

Regards,

Adam

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

[Julien Cristau]

Control: tag -1 confirmed

On Wed, Dec 01, 2021 at 07:38:23PM +0100, Christoph Biedl wrote:
> Christoph Biedl wrote...
> 
> > About next steps, I would do the upload in the next days. Let me know if
> > you prefer other things to happen first or instead.
> 
> To avoid this gets lost I've just uploaded http-parser 2.8.1-1+deb10u2.
> Updated debiff attached, only editorial changes since the previous mail.
> 
Thanks.  My only question is has anyone double checked none of the
reverse deps access content_length (the patch comment suggests you have,
but...)?

Cheers,
Julien

Bug#998179: ITP: martchus-qtutilities -- Qt utility for Syncthing Tray

[Nicholas D Steeves]

Hi Hannah,

Thank you the fixes; I've elided everything that's been resolved.

Hannah Rittich  writes:
> On 01/12/2021 18:09, Nicholas D Steeves wrote:
>
>> control:
>> 
>>   * source:Description does not yet appear to be supported by Policy
>> (see bug #998165).  I'm guessing you would prefer to prioritise
>> uploading this package rather than waiting for (or working towards)
>> evolving Debian Policy, so I'd recommend just copy and pasting for now. 
>> For the record, yes, I absolutely agree that the way you chose is better
>> :-)  I look forward to the day when we can upload this more elegant
>> packaging style.
>
> So lintian has been updated already. If you insist, I change back to
> using the X-Description variable (which is allowed by the policy).
>

Declaring Standards-Version: 4.6.0 means that the package is compliant
with Policy 4.6.0 (and in this case also 4.6.0.1), which does not permit
source:Description at L12.  See the bug from my last email (noted above)
for a practical implication of the proposal that may be objected to, and
also see §5.2 of Policy for how this is not yet permitted:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#source-package-control-files-debian-control

I believe ftpmasters will reject this the current state of this package
because of this.  If you're interested in reading about other things
they'll reject for, here is some optional reading:

  https://ftp-master.debian.org/#rejections
  https://ftp-master.debian.org/REJECT-FAQ.html
  https://ftp-master.debian.org/NEW-checklist.html

I think it's likely that they'll ask us to add "Martchus" to both the
long and short description, and also to enhance the long description to
be less generic and more informative; they won't reject the package on
these grounds though, and I won't hassle you about any of these things
unless it seems like there are enough of them that I worry that
ftpmasters will reject the package.  Debian is the strictest
distribution that I know of ;-)

Regards,
Nicholas


signature.asc
Description: PGP signature