Bug#1005981: redet: diff for NMU version 8.26-1.5

[Joao Eriberto Mota Filho]

Control: tags 1005981 + patch

Dear maintainer,

I've prepared an NMU for redet (versioned as 8.26-1.5) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

diff -Nru redet-8.26/debian/changelog redet-8.26/debian/changelog
--- redet-8.26/debian/changelog 2022-04-16 02:32:24.0 -0300
+++ redet-8.26/debian/changelog 2022-04-16 02:26:50.0 -0300
@@ -1,3 +1,12 @@
+redet (8.26-1.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Migrated to DebSrc 3.0. Consequently:
+  - Migrated the current patch from dpatch to quilt.
+  - Closes: #1005981
+
+ -- Joao Eriberto Mota Filho   Sat, 16 Apr 2022 02:26:50 
-0300
+
 redet (8.26-1.4) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru redet-8.26/debian/control redet-8.26/debian/control
--- redet-8.26/debian/control   2022-04-16 02:32:24.0 -0300
+++ redet-8.26/debian/control   2022-04-16 02:23:26.0 -0300
@@ -2,7 +2,7 @@
 Section: x11
 Priority: optional
 Maintainer: Bartosz Fenski 
-Build-Depends: debhelper (>= 10), dpatch
+Build-Depends: debhelper (>= 10), quilt (>= 0.40)
 Standards-Version: 3.9.8
 Homepage: http://www.billposer.org/Software/redet.html
 
diff -Nru redet-8.26/debian/patches/00list redet-8.26/debian/patches/00list
--- redet-8.26/debian/patches/00list2022-04-16 02:32:24.0 -0300
+++ redet-8.26/debian/patches/00list1969-12-31 21:00:00.0 -0300
@@ -1 +0,0 @@
-01_path
diff -Nru redet-8.26/debian/patches/01_path.dpatch 
redet-8.26/debian/patches/01_path.dpatch
--- redet-8.26/debian/patches/01_path.dpatch2022-04-16 02:32:24.0 
-0300
+++ redet-8.26/debian/patches/01_path.dpatch1969-12-31 21:00:00.0 
-0300
@@ -1,33 +0,0 @@
-#! /bin/sh -e
-## redet.dpatch
-## Bartosz Fenski 
-
-patch_opts="${patch_opts:--f --no-backup-if-mismatch ${2:+-d $2}}"
-
-if [ $# -ne 1 ]; then
-echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
-exit 1
-fi
-case "$1" in
-   -patch) patch $patch_opts -p1 < $0;;
-   -unpatch) patch $patch_opts -R -p1 < $0;;
-   *)
-   echo >&2 "`basename $0`: script expects -patch|-unpatch as 
argument"
-   exit 1;;
-esac
- 
-exit 0
-
-@DPATCH@
-diff -ru redet-6.13.orig/redet.tcl redet-6.13/redet.tcl
 redet-6.13.orig/redet.tcl  2005-07-28 10:53:55.0 +0200
-+++ redet-6.13/redet.tcl   2005-07-28 11:46:40.0 +0200
-@@ -51,7 +51,7 @@
- set HistoryFile  ".redethist";
- set JournalFile  ".redetlog";
- set ColorFile".redetcolors";
--set NonBinPath [file join /usr local share Redet];
-+set NonBinPath [file join /usr share doc redet-doc];
- 
- #Portability
- #Figure out what system we are running on
diff -Nru redet-8.26/debian/patches/01_path.patch 
redet-8.26/debian/patches/01_path.patch
--- redet-8.26/debian/patches/01_path.patch 1969-12-31 21:00:00.0 
-0300
+++ redet-8.26/debian/patches/01_path.patch 2022-04-16 02:26:15.0 
-0300
@@ -0,0 +1,15 @@
+Author: Bartosz Fenski 
+Description: fix the path and name of docs.
+Index: redet-8.26/redet.tcl
+===
+--- redet-8.26.orig/redet.tcl
 redet-8.26/redet.tcl
+@@ -155,7 +155,7 @@ set InitFile ".redetrc";
+ set HistoryFile  ".redethist";
+ set JournalFile  ".redetlog";
+ set ColorFile".redetcolors";
+-set NonBinPath [file join /usr local share Redet];
++set NonBinPath [file join /usr share doc redet-doc];
+ 
+ #Flags showing whether windows are editable
+ set INDEditableP 0;
diff -Nru redet-8.26/debian/patches/series redet-8.26/debian/patches/series
--- redet-8.26/debian/patches/series1969-12-31 21:00:00.0 -0300
+++ redet-8.26/debian/patches/series2022-04-16 02:23:25.0 -0300
@@ -0,0 +1 @@
+01_path.patch
diff -Nru redet-8.26/debian/rules redet-8.26/debian/rules
--- redet-8.26/debian/rules 2022-04-16 02:32:24.0 -0300
+++ redet-8.26/debian/rules 2022-04-16 02:23:26.0 -0300
@@ -8,7 +8,7 @@
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
 
-include /usr/share/dpatch/dpatch.make
+include /usr/share/quilt/quilt.make
 
 CFLAGS = -Wall -g
 
@@ -27,7 +27,7 @@
 
 build-arch:
 build-indep: build-indep-stamp
-build-indep-stamp: patch-stamp configure-stamp 
+build-indep-stamp: $(QUILT_STAMPFN) configure-stamp 
 
touch build-indep-stamp
 
diff -Nru redet-8.26/debian/source/format redet-8.26/debian/source/format
--- redet-8.26/debian/source/format 1969-12-31 21:00:00.0 -0300
+++ redet-8.26/debian/source/format 2022-04-16 02:26:50.0 -0300
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#998919: iisemulator: diff for NMU version 0.95-3.4

[Joao Eriberto Mota Filho]

Control: tags 998919 + patch
Control: tags 998919 + pending

Dear maintainer,

I've prepared an NMU for iisemulator (versioned as 0.95-3.4) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

diff -u iisemulator-0.95/debian/changelog iisemulator-0.95/debian/changelog
--- iisemulator-0.95/debian/changelog
+++ iisemulator-0.95/debian/changelog
@@ -1,3 +1,11 @@
+iisemulator (0.95-3.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: added missing targets build-arch and build-indep.
+(Closes: #998919)
+
+ -- Joao Eriberto Mota Filho   Sat, 16 Apr 2022 02:11:23 
-0300
+
 iisemulator (0.95-3.3) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u iisemulator-0.95/debian/rules iisemulator-0.95/debian/rules
--- iisemulator-0.95/debian/rules
+++ iisemulator-0.95/debian/rules
@@ -72,4 +72,6 @@
dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+build-arch: build
+build-indep: build
+.PHONY: build clean build-arch build-indep binary-indep binary-arch binary 
install configure

Bug#999268: vncsnapshot: diff for NMU version 1.2a-5.2

[Joao Eriberto Mota Filho]

Control: tags 999268 + patch
Control: tags 999268 + pending

Dear maintainer,

I've prepared an NMU for vncsnapshot (versioned as 1.2a-5.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

diff -Nru vncsnapshot-1.2a/debian/changelog vncsnapshot-1.2a/debian/changelog
--- vncsnapshot-1.2a/debian/changelog   2012-06-06 13:56:25.0 -0300
+++ vncsnapshot-1.2a/debian/changelog   2022-04-16 02:00:41.0 -0300
@@ -1,3 +1,11 @@
+vncsnapshot (1.2a-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: added missing targets build-arch and build-indep.
+(Closes: #999268)
+
+ -- Joao Eriberto Mota Filho   Sat, 16 Apr 2022 02:00:41 
-0300
+
 vncsnapshot (1.2a-5.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru vncsnapshot-1.2a/debian/rules vncsnapshot-1.2a/debian/rules
--- vncsnapshot-1.2a/debian/rules   2012-06-06 13:55:44.0 -0300
+++ vncsnapshot-1.2a/debian/rules   2022-04-16 02:00:41.0 -0300
@@ -66,4 +66,6 @@
dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+build-arch: build
+build-indep: build
+.PHONY: build clean build-arch build-indep binary-indep binary-arch binary 
install configure

Bug#668477: cadaver: diff for NMU version 0.23.3-2.2

[Joao Eriberto Mota Filho]

Control: tags 668477 + pending
Control: tags 965443 + patch
Control: tags 965443 + pending

Dear maintainer,

I've prepared an NMU for cadaver (versioned as 0.23.3-2.2) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

diff -Nru cadaver-0.23.3/debian/changelog cadaver-0.23.3/debian/changelog
--- cadaver-0.23.3/debian/changelog 2022-04-16 01:41:44.0 -0300
+++ cadaver-0.23.3/debian/changelog 2022-04-15 21:27:34.0 -0300
@@ -1,3 +1,21 @@
+cadaver (0.23.3-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Migrated to DebSrc 3.0. Consequently:
+  - debian/source/options: created to ignore changes in config.guess and
+config.sub.
+  - Migrated the current patch from dpatch to quilt.
+  - Closes: #668477
+  * Using new DH level format. Consequently:
+  - debian/compat: removed.
+  - debian/control: changed from 'debhelper' to 'debhelper-compat' in
+Build-Depends field and bumped level to 13.
+  - debian/rules: using 'dh_prep' instead of 'dh_clean -k' because the
+'-k' option is not supported since compat 12.
+  - Closes: #965443
+
+ -- Joao Eriberto Mota Filho   Fri, 15 Apr 2022 21:27:34 
-0300
+
 cadaver (0.23.3-2.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru cadaver-0.23.3/debian/compat cadaver-0.23.3/debian/compat
--- cadaver-0.23.3/debian/compat2022-04-16 01:41:44.0 -0300
+++ cadaver-0.23.3/debian/compat1969-12-31 21:00:00.0 -0300
@@ -1 +0,0 @@
-5
diff -Nru cadaver-0.23.3/debian/control cadaver-0.23.3/debian/control
--- cadaver-0.23.3/debian/control   2022-04-16 01:41:44.0 -0300
+++ cadaver-0.23.3/debian/control   2022-04-15 21:27:34.0 -0300
@@ -2,7 +2,7 @@
 Section: web
 Priority: optional
 Maintainer: Sebastian Harl 
-Build-Depends: debhelper (>= 5), dpkg-dev (>= 1.14.6), dpatch,
+Build-Depends: debhelper-compat (= 13), dpkg-dev (>= 1.14.6), quilt (>= 0.40),
  autotools-dev,
  libgcrypt20-dev,
  libncurses5-dev,
diff -Nru cadaver-0.23.3/debian/patches/00list 
cadaver-0.23.3/debian/patches/00list
--- cadaver-0.23.3/debian/patches/00list2022-04-16 01:41:44.0 
-0300
+++ cadaver-0.23.3/debian/patches/00list1969-12-31 21:00:00.0 
-0300
@@ -1,2 +0,0 @@
-manpage_hyphen.dpatch
-
diff -Nru cadaver-0.23.3/debian/patches/manpage_hyphen.dpatch 
cadaver-0.23.3/debian/patches/manpage_hyphen.dpatch
--- cadaver-0.23.3/debian/patches/manpage_hyphen.dpatch 2022-04-16 
01:41:44.0 -0300
+++ cadaver-0.23.3/debian/patches/manpage_hyphen.dpatch 1969-12-31 
21:00:00.0 -0300
@@ -1,27 +0,0 @@
-#! /bin/sh /usr/share/dpatch/dpatch-run
-## manpage_hyphen.dpatch by Sebastian Harl 
-##
-## DP: Do not use hyphens as minus signs.
-
-@DPATCH@
-
 a/doc/cadaver.1
-+++ b/doc/cadaver.1
-@@ -2,7 +2,7 @@
- .SH NAME
- cadaver \- A command\-line WebDAV client for Unix. 
- .SH SYNOPSIS
--cadaver [-trp[-r file][-p host[:port]]][-V][-h] http://hostname[:port]/path
-+cadaver [\-trp[\-r file][\-p host[:port]]][\-V][\-h] 
http://hostname[:port]/path
- .SH DESCRIPTION
- .B cadaver 
- supports file upload, download, on-screen display, namespace operations
-@@ -162,7 +162,7 @@
- .IP
- .SH FILES
- .IP "~/.cadaverrc"
--Individual user settings that can override cadaver defaults and to script 
cadaver. Can be changed by the "--rcfile" option.
-+Individual user settings that can override cadaver defaults and to script 
cadaver. Can be changed by the "\-\-rcfile" option.
- .IP "~/.netrc"
- Login and initialization information used by the auto-login process. See
- section "THE .netrc FILE" for details.
diff -Nru cadaver-0.23.3/debian/patches/manpage_hyphen.patch 
cadaver-0.23.3/debian/patches/manpage_hyphen.patch
--- cadaver-0.23.3/debian/patches/manpage_hyphen.patch  1969-12-31 
21:00:00.0 -0300
+++ cadaver-0.23.3/debian/patches/manpage_hyphen.patch  2022-04-15 
21:27:34.0 -0300
@@ -0,0 +1,22 @@
+Author: Sebastian Harl 
+Description: Do not use hyphens as minus signs.
+--- cadaver-0.23.3.orig/doc/cadaver.1
 cadaver-0.23.3/doc/cadaver.1
+@@ -2,7 +2,7 @@
+ .SH NAME
+ cadaver \- A command\-line WebDAV client for Unix. 
+ .SH SYNOPSIS
+-cadaver [-trp[-r file][-p host[:port]]][-V][-h] http://hostname[:port]/path
++cadaver [\-trp[\-r file][\-p host[:port]]][\-V][\-h] 
http://hostname[:port]/path
+ .SH DESCRIPTION
+ .B cadaver 
+ supports file upload, download, on-screen display, namespace operations
+@@ -162,7 +162,7 @@ Connects to a server called secure.examp
+ .IP
+ .SH FILES
+ .IP "~/.cadaverrc"
+-Individual user settings that can override cadaver defaults and to script 
cadaver. Can be changed by the "--rcfile" option.
++Individual user settings that can override cadaver defaults and to script 
cadaver. Can be changed by the "\-\-rcfile" option.
+ .IP "~/.netrc"
+ Login and initialization information used by the auto-login process. See
+ section "THE .netrc FILE" for 

Bug#996965: bslib and rmarkdown update

[Andreas Tille]

Hi Eric,

Am Fri, Apr 15, 2022 at 02:44:11PM -0400 schrieb Eric Brown:
> It looks like conversion to .woff from .ttf or .otf is straightforward
> with woff-tools, e.g. install fonts-roboto, then the appropriate file
> can be converted by, e.g. `sfnt2woff Roboto-Regular.ttf` which creates
> Roboto-Regular.woff.
> 
> I also found that fonts-inter is in Debian. So it appears only 3 fonts
> would need to be packaged. I've opened RFP bugs for them:

I agree that the conversion to woff format is possible. I've managed
this myself last week.  The reason why I did not reported this here and
rather decided to simply try uploading the fonts as they are is, that I
have no idea how to find out a relation between those fonts and the
cryptic (random???) font files names that are used in bslib.  So even if
we could convert existing font files - how should we maintain these
conversions to move them to the file names that are obviously used
inside the css files?
 
> Nunito Sans https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009730
> Neucha https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009729
> News Cycle  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009707

Thanks a lot for your investigation which is extremely welcome.

Kind regards
 Andreas.
 
> 
> On Wed, Apr 13, 2022 at 1:56 PM Eric Brown  wrote:
> >
> > Minor update with source:
> >
> > In Debian:
> >
> > Roboto  https://packages.debian.org/bullseye/fonts-roboto
> > Ubuntu  https://packages.debian.org/bullseye/fonts-ubuntu
> > Open Sans   https://packages.debian.org/sid/fonts-open-sans
> > Latohttps://packages.debian.org/sid/fonts-lato
> > Cabin Sketchhttps://packages.debian.org/sid/fonts-cabinsketch
> >
> > In Debian but should ideally be packaged separately due to large size
> > of texlive-fonts-extra and current policy:
> >
> > Montserrat, Nunito, Raleway, Source Sans Pro: texlive-fonts-extra
> >
> > Need Debian package (all have open licences):
> >
> > Nunito Sans https://github.com/googlefonts/NunitoSans
> > Inter   https://github.com/rsms/inter/
> > News Cycle  https://launchpad.net/newscycle
> > Neucha  https://typetype.org/wp-content/uploads/neucha.zip
> >
> > On Wed, Apr 6, 2022 at 7:13 AM Andreas Tille  wrote:
> > >
> > > Hi Eric,
> > >
> > > thanks a lot for your investigation.  This is extremely helpful.
> > >
> > > Am Tue, Apr 05, 2022 at 08:50:08PM -0400 schrieb Eric Brown:
> > > > Hi again,
> > > >
> > > > I tried to see what happens when the woff files are deleted from bslib.
> > > >
> > > > I cloned the bslib git, deleted the contents of the font folder, built
> > > > the R package locally, then tried to render an R markdown document
> > > > that uses a bslib theme (minty).
> > > > It fails with an error message (below).
> > > >
> > > > pandoc: 
> > > > /tmp/Rtmp1sYpTM/bslib-ca23be8b2c03436a7d75cedd4667b7ed/fonts/JTUSjIg1_i6t8kCHKm45xW0.woff:
> > > > openBinaryFile: does not exist (No such file or directory)
> > > > Error : pandoc document conversion failed with error 1
> > > > Error: callr subprocess failed: pandoc document conversion failed with 
> > > > error 1
> > > > Type .Last.error.trace to see where the error occurred
> > >
> > > Seems we need the Montserrat font from texlive-fonts-extra.  But there
> > > are no *.woff files.  Thus I guess we need to convert the proper font
> > > from there to woff format - but I have no idea at all how to do this.
> > >
> > > Kind regards
> > >
> > >   Andreas.
> > >
> > > >
> > > > Best,
> > > > Eric
> > > >
> > > > On Tue, Apr 5, 2022 at 11:39 AM Eric Brown  wrote:
> > > > >
> > > > > Hi Andreas,
> > > > >
> > > > > I can at least identify which .woff files correspond to which fonts,
> > > > > that is possible with grep. Here's the output:
> > > > > https://gist.github.com/eebrown/95615fc35af364bd0fae09a69273dbdf
> > > > >
> > > > > I think deleting the .woff files and seeing if the fonts render
> > > > > properly when they are installed at the system level is reasonable but
> > > > > I too am not sure exactly how to try out all the fonts.
> > > > >
> > > > > If that doesn't work, I guess it would be a matter of symlinking files
> > > > > to replace the .woff files. This might require a step to derive the
> > > > > .woff wiles in the format expected by bslib.
> > > > >
> > > > >
> > > > > On Tue, Apr 5, 2022 at 9:44 AM Andreas Tille  
> > > > > wrote:
> > > > > >
> > > > > > Hi Eric,
> > > > > >
> > > > > > Am Mon, Apr 04, 2022 at 06:42:59AM -0400 schrieb Eric Brown:
> > > > > > > To update, I found that a few more are packaged in 
> > > > > > > texlive-fonts-extra (
> > > > > > > https://packages.debian.org/buster/texlive-fonts-extra)
> > > > > > >
> > > > > > > Roboto  https://packages.debian.org/bullseye/fonts-roboto
> > > > > > > Ubuntu  https://packages.debian.org/bullseye/fonts-ubuntu
> > > > > > > Open Sans   https://packages.debian.org/sid/fonts-open-sans
> > > > > > > Lato

Bug#1009745: just to add.. since I forgot.

[Beardy Face]

Those of us on the autistic spectrum can find excessively bright windows within 
a dark screen somewhat painful too deal with.. even if the Fusion style renders 
the text readable.

Bug#1009745: virtualbox: Command-line option --style Adwaita-Dark broken by update.

[Beardy Face]

Package: virtualbox
Version: 6.1.32-dfsg-1~fto11+2
Severity: normal
Tags: a11y
X-Debbugs-Cc: bea...@mxstuff.org

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
apt-get upgrade (apparently downgrade).
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Nothing unusual, simply upgrading to remaain current.
   * What was the outcome of this action?
Error when starting the application stating the style is unavailable.
The interface consequently bacame unreadable with a dark theme selected.
   * What outcome did you expect instead?
The interface to remain useable, rathewr than white text on a white
 background.. which is obviously not possible to read.


*** End of the template - remove these template lines ***


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

Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages virtualbox depends on:
ii  adduser   3.121
iu  iproute2  5.17.0-1
ii  libc6 2.33-7
iu  libcurl3-gnutls   7.82.0-2
ii  libdevmapper1.02.12:1.02.175-2.1
ii  libgcc-s1 12-20220319-1
iu  libgl11.4.0-1
ii  libgsoap-2.8.104  2.8.104-3
ii  liblzf1   3.6-3
ii  libopus0  1.3.1-0.1
ii  libpng16-16   1.6.37-3
iu  libpython3.9  3.9.12-1
ii  libsdl1.2debian   1.2.15+dfsg2-6
ii  libssl1.1 1.1.1n-1
ii  libstdc++612-20220319-1
iu  libvncserver1 0.9.13+dfsg-3
ii  libvpx6   1.9.0-1
iu  libx11-6  2:1.7.5-1
ii  libxcursor1   1:1.2.0-2
iu  libxml2   2.9.13+dfsg-1
iu  libxt61:1.2.1-1
iu  procps2:3.3.17-7+b1
iu  python3   3.10.4-1
iu  python3.9 3.9.12-1
iu  virtualbox-dkms [virtualbox-modules]  6.1.32-dfsg-1+b3
ii  zlib1g1:1.2.11.dfsg-4

Versions of packages virtualbox recommends:
iu  libqt5core5a5.15.2+dfsg-16
iu  libqt5gui5  5.15.2+dfsg-16
iu  libqt5opengl5   5.15.2+dfsg-16
iu  libqt5widgets5  5.15.2+dfsg-16
ii  libxcb1 1.14-3
iu  libxext62:1.3.4-1
iu  virtualbox-qt   6.1.32-dfsg-1+b3

Versions of packages virtualbox suggests:
pn  vde2
iu  virtualbox-guest-additions-iso  6.1.32-1

-- no debconf information

Bug#1009743: haskell-devscripts: recent changes cause haskell-hspec-discover to FTBFS

[Felix Lechner]

Control: fixed -1 0.16.11

Hi Scott,

I believe you saw a temporary malfunction. The sources for
haskell-hspec-discover_2.7.1 built locally with haskell-devscripts
0.16.11 in unstable. The tail of the log is below.

The disruption was caused by an effort to make the current build
system compatible with Debhelper's dh sequencer.

Thank you for your patience!

Kind regards,
Felix Lechner

* * *

[start of build log omitted]
dh_gencontrol -phspec-discover
dpkg-gencontrol: warning: package hspec-discover: substitution
variable ${haskell:ghc-version} unused, but is defined
dh_md5sums -phspec-discover
dh_builddeb -phspec-discover
dpkg-deb: building package 'hspec-discover' in
'../hspec-discover_2.7.1-1_amd64.deb'.
 dpkg-genbuildinfo
 dpkg-genchanges  >../haskell-hspec-discover_2.7.1-1_amd64.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build .
dpkg-buildpackage: info: full upload (original source is included)
Now running lintian haskell-hspec-discover_2.7.1-1_amd64.changes ...
W: hspec-discover: hardening-no-pie usr/bin/hspec-discover
W: haskell-hspec-discover source:
missing-license-paragraph-in-dep5-copyright debian/copyright mit (line
12)
W: haskell-hspec-discover source:
missing-license-text-in-dep5-copyright debian/copyright MIT (line 14)
W: hspec-discover: no-manual-page usr/bin/hspec-discover
W: haskell-hspec-discover source: no-nmu-in-changelog
W: haskell-hspec-discover source:
source-nmu-has-incorrect-version-number 2.7.1-1
I: hspec-discover: hardening-no-bindnow usr/bin/hspec-discover
I: hspec-discover: hardening-no-fortify-functions usr/bin/hspec-discover
I: haskell-hspec-discover source: older-debian-watch-file-standard 3
I: haskell-hspec-discover source: out-of-date-standards-version 4.1.4
(released 2018-04-05) (current is 4.6.0.1)
I: hspec-discover: unused-override binary-or-shlib-defines-rpath
X: haskell-hspec-discover source: debian-watch-does-not-check-gpg-signature
P: haskell-hspec-discover source: package-uses-old-debhelper-compat-version 10
P: hspec-discover: renamed-tag binary-or-shlib-defines-rpath =>
custom-library-search-path in line 1
X: haskell-hspec-discover source: upstream-metadata-file-is-missing
Finished running lintian.

Bug#1006350: pidgin: crashes when typing past visible number of lines

[Richard Laager]

This has hopefully been fully fixed now (upstream). It will land in the 
2.14.9 release, which should be coming next week. However, I've uploaded 
a backport of it now.


--
Richard

Bug#1009743: haskell-devscripts: recent changes cause haskell-hspec-discover to FTBFS

[Scott Talbert]

Package: haskell-devscripts
Version: 0.16.3
Severity: important

Dear Maintainer,

While test building some haskell packages, I noticed that
haskell-hspec-discover FTBFS with haskell-devscripts 0.16.3+.  This is
the error with 0.16.10 (there were different errors before 0.16.10).

dh_installdirs -A 
mkdir -p "."
CDBS WARNING:DEB_DH_STRIP_ARGS is deprecated since 0.4.85
CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
Adding cdbs dependencies to debian/hspec-discover.substvars
dh_installdirs -phspec-discover \

make: *** No rule to make target 'debian/tmp-inst-ghc', needed by 
'install/hspec-discover'.  Stop.
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2

Rolling back to 0.16.2 resolves the problem.  I suspect this may have
something to do with the fact that seems to be a bit non-standard for a
DHG package (ie, doesn't use -dev naming).

Thanks,
Scott

Bug#1008133: Lightdm greeter has confusing prompts

[Daniel Helgason]

On Tue, 22 Mar 2022 16:51:25 -0700 Daniel Helgason
 wrote:
> Package: lightdm
> Version: 1.26.0-7
> 
> The (default?) greeter displays the prompt "Enter your password" when
the cursor is positioned in the textbox that is expecting the username.
> 
> The greeter also displays the prompt "Enter your username" when the
cursor is positioned in the textbox that is expecting the password.
This happens when the username textbox is empty.
> ...

This looks like same as #7962141 filed Aug 2015 and confirmed Aug 2017.

Bug#1009742: adcli: wrong umask leading to no keytab update

[Vincent Danjean]

Package: adcli
Version: 0.9.0-1
Severity: normal

  Hi,

  On bullseye systems in AD environment (managed with sssd),
I observed problems with krb5.conf snippet generation in sssd.log:
   *  (2022-04-14 22:36:18): [be[domain.fr]] 
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output start---
adcli: couldn't write new krb5.conf file: /tmp/adcli-krb5-f3rplr/krb5.conf: 
Permission denied
---adcli output end---

And, indeed, looking into /tmp, I find lots of
/tmp/adcli-krb5-... directories (one per day), all empty, and
all with 600 perms (not 700!).

So, I patched adcli to first print, and then change the umak.
The umask was 0x7f. Now, I force-clear the USER bits (see
the patch at the end).

The main bug probably comes from sssd (setting a wrong umask).
I'm using sssd 2.6.3-1~bpo11+1 (a local rebuild for bullseye)
I fixed the bug in adcli (easier for me to do so, and there
is no reason for adcli to be invoked with such a bogus umask)

Now, with my patch, sssd logs tell me:
(2022-04-16  0:15:39): [be[domain.fr]] 
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output start---
adcli: strange umask 7f, setting it to 3f
 * Wrote out krb5.conf snippet to 
/tmp/adcli-krb5-SQMtbL/krb5.d/adcli-krb5-conf-kcm9gK
---adcli output end---

And /tmp/adcli-krb5-SQMtbL directory is correctly removed.

  Regards,
Vincent

my patch:

--- a/tools/tools.c
+++ b/tools/tools.c
@@ -314,6 +314,15 @@
int errn = 0;
FILE *fo;
 
+   {
+   mode_t u = umask(0);
+   umask(u);
+   mode_t u2 = u & ~(S_IRUSR|S_IWUSR|S_IXUSR);
+   if (u2 != u) {
+   warnx ("strange umask %x, setting it to %x", u, u2);
+   umask(u2);
+   }
+   }
krb5_conf = getenv ("KRB5_CONFIG");
if (!krb5_conf || !krb5_conf[0])
krb5_conf = KRB5_CONFIG;



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

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages adcli depends on:
ii  libc62.33-7
ii  libcom-err2 [libcomerr2] 1.46.5-2
ii  libgssapi-krb5-2 1.19.2-2+b1
ii  libk5crypto3 1.19.2-2+b1
ii  libkrb5-31.19.2-2+b1
ii  libldap-2.4-22.4.59+dfsg-1+b1
ii  libldap-2.5-02.5.11+dfsg-1
pn  libsasl2-modules-gssapi-mit  

adcli recommends no packages.

adcli suggests no packages.

Bug#1009733: src:exempi: fails to migrate to testing for too long: FTBFS on armel and armhf

[Michael Biebl]

Dear arm porters,

can you please take a look at this?


Thanks,
Michael

Am 15.04.22 um 21:19 schrieb Paul Gevers:

Source: exempi
Version: 2.5.2-1
Severity: serious
Control: close -1 2.6.1-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:exempi has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. You package failed to build from 
source on armel and armhf where it built successfully in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=exempi





OpenPGP_signature
Description: OpenPGP digital signature

Bug#983961: advancecomp: diff for NMU version 2.1-2.2

[Marcos Talau]

Control: tags 983961 + pending

Dear maintainer,

I've prepared an NMU for advancecomp (versioned as 2.1-2.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru advancecomp-2.1/debian/changelog advancecomp-2.1/debian/changelog
--- advancecomp-2.1/debian/changelog2019-05-18 17:50:20.0 -0300
+++ advancecomp-2.1/debian/changelog2022-04-14 14:04:51.0 -0300
@@ -1,3 +1,11 @@
+advancecomp (2.1-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/Fix-build-gcc11.patch: New. Fix FTBFS with GCC-11.
+Thanks to Michał Górny . (Closes: #983961)
+
+ -- Marcos Talau   Thu, 14 Apr 2022 14:04:51 -0300
+
 advancecomp (2.1-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru advancecomp-2.1/debian/patches/Fix-build-gcc11.patch 
advancecomp-2.1/debian/patches/Fix-build-gcc11.patch
--- advancecomp-2.1/debian/patches/Fix-build-gcc11.patch1969-12-31 
21:00:00.0 -0300
+++ advancecomp-2.1/debian/patches/Fix-build-gcc11.patch2022-04-14 
14:04:51.0 -0300
@@ -0,0 +1,161 @@
+Description: Remove dynamic exception specification to fix C++17 compatibility
+Bug-Debian: https://bugs.debian.org/983961
+Origin: upstream, 
https://github.com/amadvance/advancecomp/commit/7b08f7a2af3f66ab95437e4490499cebb20e5e41
+Author: Michał Górny 
+Last-Update: 2021-04-28
+Index: advancecomp-2.1/file.cc
+===
+--- advancecomp-2.1.orig/file.cc
 advancecomp-2.1/file.cc
+@@ -98,7 +98,7 @@ void infopath::readonly_set(bool Areadon
+ /**
+  * Check if a file exists.
+  */
+-bool file_exists(const string& path) throw (error)
++bool file_exists(const string& path)
+ {
+   struct stat s;
+   if (stat(path.c_str(), ) != 0) {
+@@ -114,7 +114,7 @@ bool file_exists(const string& path) thr
+ /**
+  * Write a whole file.
+  */
+-void file_write(const string& path, const char* data, unsigned size) throw 
(error)
++void file_write(const string& path, const char* data, unsigned size)
+ {
+   FILE* f = fopen(path.c_str(), "wb");
+   if (!f)
+@@ -134,7 +134,7 @@ void file_write(const string& path, cons
+ /**
+  * Read a whole file.
+  */
+-void file_read(const string& path, char* data, unsigned size) throw (error)
++void file_read(const string& path, char* data, unsigned size)
+ {
+   file_read(path, data, 0, size);
+ }
+@@ -142,7 +142,7 @@ void file_read(const string& path, char*
+ /**
+  * Read a whole file.
+  */
+-void file_read(const string& path, char* data, unsigned offset, unsigned 
size) throw (error)
++void file_read(const string& path, char* data, unsigned offset, unsigned size)
+ {
+   FILE* f = fopen(path.c_str(), "rb");
+   if (!f)
+@@ -166,7 +166,7 @@ void file_read(const string& path, char*
+ /**
+  * Get the time of a file.
+  */
+-time_t file_time(const string& path) throw (error)
++time_t file_time(const string& path)
+ {
+   struct stat s;
+   if (stat(path.c_str(), )!=0)
+@@ -178,7 +178,7 @@ time_t file_time(const string& path) thr
+ /**
+  * Set the time of a file.
+  */
+-void file_utime(const string& path, time_t tod) throw (error)
++void file_utime(const string& path, time_t tod)
+ {
+   struct utimbuf u;
+ 
+@@ -192,7 +192,7 @@ void file_utime(const string& path, time
+ /**
+  * Get the size of a file.
+  */
+-unsigned file_size(const string& path) throw (error)
++unsigned file_size(const string& path)
+ {
+   struct stat s;
+   if (stat(path.c_str(), )!=0)
+@@ -204,7 +204,7 @@ unsigned file_size(const string& path) t
+ /**
+  * Get the crc of a file.
+  */
+-crc_t file_crc(const string& path) throw (error)
++crc_t file_crc(const string& path)
+ {
+   unsigned size = file_size(path);
+ 
+@@ -227,7 +227,7 @@ crc_t file_crc(const string& path) throw
+ /**
+  * Copy a file.
+  */
+-void file_copy(const string& path1, const string& path2) throw (error)
++void file_copy(const string& path1, const string& path2)
+ {
+   unsigned size;
+ 
+@@ -249,7 +249,7 @@ void file_copy(const string& path1, cons
+ /**
+  * Move a file.
+  */
+-void file_move(const string& path1, const string& path2) throw (error)
++void file_move(const string& path1, const string& path2)
+ {
+   if (rename(path1.c_str(), path2.c_str())!=0
+   && errno==EXDEV) {
+@@ -271,7 +271,7 @@ void file_move(const string& path1, cons
+ /**
+  * Remove a file.
+  */
+-void file_remove(const string& path1) throw (error)
++void file_remove(const string& path1)
+ {
+   if (remove(path1.c_str())!=0) {
+   throw error() << "Failed remove of " << path1;
+@@ -281,7 +281,7 @@ void file_remove(const string& path1) th
+ /**
+  * Rename a file.
+  */
+-void file_rename(const string& path1, const string& path2) throw (error)
++void file_rename(const string& path1, const string& path2)
+ {
+   if (rename(path1.c_str(), path2.c_str())!=0) {
+   throw error() << "Failed rename of " << 

Bug#979095: Legally problematic GPL-3+ readline dependency

[Bastian Germann]

On Thu, 14 Oct 2021 09:52:51 +0200 Bastian Germann wrote:

On Sat, 2 Jan 2021 18:36:38 +0100 Bastian Germann wrote:

> There is an easy solution to the problem: Replacing the build dependency 
> libreadline-dev with libeditreadline-dev links with the BSD-licensed 
> libedit library which is a readline replacement.


You will need the patch at 
https://listman.redhat.com/archives/dm-devel/2021-October/msg00144.html to build v0.8.5 
with libedit.


Just for the record: The same is still true for 0.8.8. Please apply the changes.

Bug#1009376: running foreign architecture containers hits the network every time and confuses future `podman run` invocations

[Reinhard Tartler]

Control: tag -1 upstream

Hi Antonio,

Can you please file a report upstream here:
https://github.com/containers/podman/issues -- upstream is really friendly
with reports from other Distros, in particular from Debian. I'm not sure
what value I can bring as a package maintainer here.

Thanks. Regards,
-rt

On Tue, Apr 12, 2022 at 2:27 PM Antonio Terceiro 
wrote:

> Package: podman
> Version: 3.4.4+ds1-1
> Severity: normal
>
> When running containers for a foreign architecture, podman run will hit
> the networking looking for images on every invocation:
>
> 8<8<8<-
> terceiro@host:~$ podman run --arch=arm64 debian arch
> Resolved "debian" as an alias
> (/etc/containers/registries.conf.d/shortnames.conf)
> Trying to pull docker.io/library/debian:latest...
> Getting image source signatures
> Copying blob fa223d8c149d done
> Copying config 05e8051d05 done
> Writing manifest to image destination
> Storing signatures
> aarch64
> terceiro@host:~$ podman run --arch=arm64 debian arch
> Resolved "debian" as an alias
> (/etc/containers/registries.conf.d/shortnames.conf)
> Trying to pull docker.io/library/debian:latest...
> Getting image source signatures
> Copying blob fa223d8c149d [-] 0.0b / 0.0b
> Copying config 05e8051d05 done
> Writing manifest to image destination
> Storing signatures
> aarch64
> 8<8<8<-
>
> This means that if I try run a foreign container while I'm offline, I
> can't:
>
> 8<8<8<-
> terceiro@host:~$ podman run --arch=arm64 debian arch
> Resolved "debian" as an alias
> (/etc/containers/registries.conf.d/shortnames.conf)
> Trying to pull docker.io/library/debian:latest...
> Error: initializing source docker://debian:latest: pinging container
> registry registry-1.docker.io: Get "https://registry-1.docker.io/v2/":
> dial tcp: lookup registry-1.docker.io on 10.0.2.3:53: dial udp 10.0.2.3:53:
> connect: network is unreachable
> 8<8<8<-
>
> Weirder than that, is that from this point on, a plain `podman run` will
> run the foreign container, instead of a native one (but will not hit the
> network, as I'm able to do that while still offline):
>
> 8<8<8<-
> terceiro@host:~$ podman run debian arch
> aarch64
> 8<8<8<-
>
> To "fix" this, I have to explicitly pull the same image without any
> architecture request after coming online again:
>
> 8<8<8<-
> terceiro@host:~$ podman pull debian
> Trying to pull docker.io/library/debian:latest...
> Getting image source signatures
> Copying blob dbba69284b27 done
> Copying config d69c6cd3a2 done
> Writing manifest to image destination
> Storing signatures
> d69c6cd3a20d21ec91b677c3bcd10d9975f4fe67eff81afb5a09bdef5134afeb
> terceiro@host:~$ podman run debian arch
> x86_64
> 8<8<8<-
>
> I have checked the version in experimental, and this bug still applies
> to it.
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (500,
> 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
> LANGUAGE=pt_BR:pt:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.0.25+ds1-1.1
> ii  containernetworking-plugins  1.1.0+ds1-1
> ii  crun 0.17+dfsg-1.1
> ii  golang-github-containers-common  0.47.2+ds1-1
> ii  init-system-helpers  1.62
> ii  libc62.33-7
> ii  libdevmapper1.02.1   2:1.02.175-2.1
> ii  libgpgme11   1.16.0-1.2
> ii  libseccomp2  2.5.3-2
> ii  runc 1.1.1+ds1-1
>
> Versions of packages podman recommends:
> ii  buildah   1.24.1+ds1-1
> ii  catatonit 0.1.7-1
> ii  fuse-overlayfs1.8.2-1
> ii  golang-github-containernetworking-plugin-dnsname  1.3.1+ds1-2
> ii  slirp4netns   1.0.1-2
> ii  tini  0.19.0-1
> ii  uidmap1:4.11.1+dfsg1-2
>
> Versions of packages podman suggests:
> pn  containers-storage  
> ii  docker-compose  1.29.2-1
> ii  iptables   

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Sean Whitton]

Hello,

On Fri 15 Apr 2022 at 01:14PM -07, Russ Allbery wrote:

> Sean Whitton  writes:
>
>> In this case I believe you need to formally withdraw options A and
>> then propose another ballot.
>
> Minor procedural point: the person proposing the options can also freely
> modify them, so you didn't technically have to withdraw them and could
> instead just alter the options to whatever new text you want.  6.3.2:
>
> Any member of the Technical Committee may propose additional ballot
> options or modify or withdraw a ballot option they proposed.
>
> (The underlying assumption is that the TC are sophisticated voters who can
> closely track the status of the ballot, so we can err on the side of
> convenience to let proposers rewrite the options to whatever they want.
> If that makes previously acceptable options unacceptable, other TC members
> can always propose new options or reinstate versions of the previous
> options.)

I failed to read "or modify", thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1009679: lintian: False positive for OCaml info files

[Rafael Laboissière]

* Felix Lechner  [2022-04-14 06:18]:


Hi Rafael,

On Thu, Apr 14, 2022 at 2:09 AM Rafael Laboissière  wrote:


See 
https://salsa.debian.org/ocaml-team/dh-ocaml/-/commit/eae9dc26


What is the purpose of those files, please? Are they used in the oCaml 
Lintian check?


I guess so, but I do not really know. I am adding the Debian OCaml 
Maintainers to the Cc list of this reply. I hope they will be able to 
answer your question.


Best,

Rafael

Bug#1009462: I think we can remove pyqi (Was: Bug#1009462: pyqi: FTBFS: Only Python 3.8 and 3.9 are supported.E: pybuild pybuild:369: configure: plugin distutils failed with: exit code=1: python3.10 s

[Nilesh Patra]

On Wed, Apr 13, 2022 at 09:49:35AM +0200, Andreas Tille wrote:
> Hi,
> 
> if I remember correctly pyqi was packaged for qiime 1.x.
> It has no rdepends any more and I think we should remove it.

I got a few spare minutes so I fixed the RC bug.

> Does anybody think differently?

It is always good to rm legacy stuff - but please ask
Steffen as he is familiar w/ qiime.

Best, Nilesh


signature.asc
Description: PGP signature

Bug#1009741: mercurial: flaky autopkgtest which times out on amd64 regularly

[Paul Gevers]

Source: mercurial
Version: 6.1.1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky timeout

Dear maintainer(s),

I looked at the results of the autopkgtest of you package because it was 
showing up as a regression for the upload of python3-defaults. I noticed 
that the test regularly fails on several architectures. Most peculiarly 
on amd64, the latest version seems to pass on ci-worker13 (our most 
powerful host looking at number of cores, memory and disk space) and 
fails (timeout) on the other amd64 hosts.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/packages/m/mercurial/testing/amd64/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009380: sasl2-bin: make saslpluginviewer more accessible (clearer manpage, put it in /usr/bin)

[Daniel Kahn Gillmor]

On Fri 2022-04-15 00:16:22 +0200, Bastian Germann wrote:
> On Tue, 12 Apr 2022 11:43:01 -0700 Daniel Kahn Gillmor 
>  wrote:
>>  - the manual page should also be updated as part of this rename -- it's
>>installed as saslpluginviewer.8.gz, but internally it says
>>"pluginviewer".
>
> This will be fixed with the next release.
>
>>  - it should be available in /usr/bin/, not only in /usr/sbin/.  It's
>>not uncommon for someone to want to investigate the state of
>>installed tooling without having to be root, and /usr/sbin is not
>>typically in the regular user path.
> I will not change the location to a different path from upstream.
> Please ask upstream for this change if it is important for you.

Thanks for this prompt fix and explanation, Bastian!

Regards,

   --dkg


signature.asc
Description: PGP signature

Bug#1009698: util-linux: more is less like more and more like less now :-)

[Chris Hofstaedtler]

* Andreas Schmidt  [220414 14:57]:
> since updating util-linux from 2.37.3-1+b1 to 2.38-2, I've found that 
> /bin/more
> doesn't work as it used to anymore.
> 
> Previously, when using /bin/mode on a long file, it would display one page at 
> a
> time. Hitting the  key would show the next page. When the last page was
> displayed, the program would automatically finish, so directly after the last
> line of output, there would be the prompt waiting for the next command.

The change in behaviour is, I think, caused by
https://github.com/util-linux/util-linux/commit/df6b29d3b

I could not find the original upstream discussion about this change.
Maybe it has some more info on why this was changed; the commit only
says "POSIX compliance". From a quick look at the current spec, I
think this is correct.

> Would it be possible to get back the original behaviour of /bin/more, please?

I have no intention of deviating from upstream. Maybe you can talk
to upstream directly. Karel is usually quite approachable,
especially if you have code. See
https://github.com/util-linux/util-linux/blob/master/README for
contact info.

Chris

Bug#1009740: nvidia-graphics-drivers-tesla-450: new version of dkms seems to show the package doesn't work on arm64 and ppc64el

[Paul Gevers]

Hi Andreas,

On 15-04-2022 22:24, Andreas Beckmann wrote:

It's probably the same issue for all nvidia-graphics-driver-tesla-xxx.


Hence I decided to stop after one bug report for now :).

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009740: nvidia-graphics-drivers-tesla-450: new version of dkms seems to show the package doesn't work on arm64 and ppc64el

[Andreas Beckmann]

Working on it.
It's probably the same issue for all nvidia-graphics-driver-tesla-xxx.

Andreas

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Russ Allbery]

Sean Whitton  writes:

> In this case I believe you need to formally withdraw options A and
> then propose another ballot.

Minor procedural point: the person proposing the options can also freely
modify them, so you didn't technically have to withdraw them and could
instead just alter the options to whatever new text you want.  6.3.2:

Any member of the Technical Committee may propose additional ballot
options or modify or withdraw a ballot option they proposed.

(The underlying assumption is that the TC are sophisticated voters who can
closely track the status of the ballot, so we can err on the side of
convenience to let proposers rewrite the options to whatever they want.
If that makes previously acceptable options unacceptable, other TC members
can always propose new options or reinstate versions of the previous
options.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1009740: nvidia-graphics-drivers-tesla-450: new version of dkms seems to show the package doesn't work on arm64 and ppc64el

[Paul Gevers]

Source: nvidia-graphics-drivers-tesla-450
Version: 450.172.01-2
Severity: serious
X-Debbugs-CC: d...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:dkms

Dear maintainer(s),

With a recent upload of dkms the autopkgtest of 
nvidia-graphics-drivers-tesla-450 fails in testing when that autopkgtest 
is run with the binary packages of dkms from unstable. It passes when 
run with only packages from testing. In tabular form:


   passfail
dkms   from testing3.0.3-1
nvidia-graphics-drivers-tesla-450 from testing450.172.01-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. Similar to bug 
#976901 this seems to show the package doesn't actually work on arm64 or 
ppc64el, at least not on the ci.d.n infrastructure (running the stable 
kernel).


Currently this regression is blocking the migration of dkms to testing 
[1]. Of course, dkms shouldn't just break your autopkgtest (or even 
worse, your package), but it seems to me that the change in dkms was 
intended and your package needs to update to the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from dkms should really add a 
versioned Breaks on the unfixed version of (one of your) package(s). 
Note: the Breaks is nice even if the issue is only in the autopkgtest as 
it helps the migration software to figure out the right versions to 
combine in the tests.


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=dkms

https://ci.debian.net/data/autopkgtest/testing/arm64/n/nvidia-graphics-drivers-tesla-450/20844150/log.gz

I: Trying to build nvidia-tesla-450/450.172.01 for 5.16.0-6-rt-arm64
Error! The 
/var/lib/dkms/nvidia-tesla-450/450.172.01/5.16.0-6-rt-arm64/aarch64/dkms.conf 
for module nvidia-tesla-450 includes a BUILD_EXCLUSIVE directive which 
does not match this kernel/arch.

This indicates that it should not be built.
I: nvidia-tesla-450/450.172.01 is not supported on 5.16.0-6-rt-arm64 
(BUILD_EXCLUSIVE directive), skipping

./nvidia-tesla-450/450.172.01/build/make.log


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009739: python3.10 breaks yade autopkgtest on i386: Segmentation fault

[Paul Gevers]

Source: python3.10, yade
Control: found -1 python3.10/3.10.4-3
Control: found -1 yade/2022.01a-7
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
python3.10 from testing3.10.4-3
yade   from testing2022.01a-7
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 python3.10 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=python3.10

https://ci.debian.net/data/autopkgtest/testing/i386/y/yade/20864008/log.gz


testAssignment (yade.tests.enumTest.TestEnum) ... 
[ci-105-2493316c:08193] *** Process received signal ***

[ci-105-2493316c:08193] Signal: Segmentation fault (11)
[ci-105-2493316c:08193] Signal code: Address not mapped (1)
[ci-105-2493316c:08193] Failing at address: 0x1
[ci-105-2493316c:08193] [ 0] 
linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xf7f97580]
[ci-105-2493316c:08193] [ 1] 
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(+0x17d7b)[0xf7446d7b]

[ci-105-2493316c:08193] [ 2] /usr/bin/python3.10(+0x16d816)[0x567bb816]
[ci-105-2493316c:08193] [ 3] 
/usr/lib/i386-linux-gnu/yade-double/py/yade/boot.so(_ZN5boost6python3api11object_baseD1Ev+0x39)[0xf747a7f9]
[ci-105-2493316c:08193] [ 4] 
/usr/lib/i386-linux-gnu/yade-double/libpkg_common.so(_ZN4yade25ArbitraryEnum_from_pythonINS_14OpenGLRenderer14BlinkHighlightEE16setArbitraryEnumERKN5boost6python3api6objectERS2_+0xb38)[0xf4169008]
[ci-105-2493316c:08193] [ 5] 
/usr/lib/i386-linux-gnu/yade-double/libpkg_common.so(_ZN4yade25ArbitraryEnum_from_pythonINS_14OpenGLRenderer14BlinkHighlightEE11convertibleEP7_object+0xa72)[0xf416aa12]
[ci-105-2493316c:08193] [ 6] 
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(_ZN5boost6python9converter25rvalue_from_python_stage1EP7_objectRKNS1_12registrationE+0x6d)[0xf74445bd]
[ci-105-2493316c:08193] [ 7] 
/usr/lib/i386-linux-gnu/yade-double/libpkg_common.so(_ZN5boost6python7objects23caller_py_function_implINS0_6detail6callerINS3_6memberIN4yade14OpenGLRenderer14BlinkHighlightES7_EENS0_19return_value_policyINS0_15return_by_valueENS0_21default_call_policiesEEENS_3mpl7vector3IvRS7_RKS8_EclEP7_objectSN_+0x77)[0xf415eeb7]
[ci-105-2493316c:08193] [ 8] 
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(_ZNK5boost6python7objects8function4callEP7_objectS4_+0x2c4)[0xf744d974]
[ci-105-2493316c:08193] [ 9] 
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(+0x1eb96)[0xf744db96]
[ci-105-2493316c:08193] [10] 
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(_ZN5boost6python21handle_exception_implENS_9function0IvEE+0x73)[0xf7452f73]
[ci-105-2493316c:08193] [11] 
/lib/i386-linux-gnu/libboost_python310.so.1.74.0(+0x1c180)[0xf744b180]
[ci-105-2493316c:08193] [12] 
/usr/bin/python3.10(_PyObject_MakeTpCall+0x257)[0x5679c727]

[ci-105-2493316c:08193] [13] /usr/bin/python3.10(+0x156fd8)[0x567a4fd8]
[ci-105-2493316c:08193] [14] 
/usr/bin/python3.10(PyObject_CallFunctionObjArgs+0x33)[0x567a4e03]

[ci-105-2493316c:08193] [15] /usr/bin/python3.10(+0x21f6b1)[0x5686d6b1]
[ci-105-2493316c:08193] [16] 
/usr/bin/python3.10(_PyObject_GenericSetAttrWithDict+0x616)[0x5677bed6]
[ci-105-2493316c:08193] [17] 
/usr/bin/python3.10(PyObject_SetAttr+0x61)[0x5677b751]
[ci-105-2493316c:08193] [18] 
/usr/bin/python3.10(_PyEval_EvalFrameDefault+0x1403)[0x567915e3]

[ci-105-2493316c:08193] [19] /usr/bin/python3.10(+0x163abf)[0x567b1abf]
[ci-105-2493316c:08193] [20] 
/usr/bin/python3.10(_PyEval_EvalFrameDefault+0xad1)[0x56790cb1]
[ci-105-2493316c:08193] [21] 
/usr/bin/python3.10(_PyFunction_Vectorcall+0x8f)[0x567a583f]
[ci-105-2493316c:08193] [22] 
/usr/bin/python3.10(_PyEval_EvalFrameDefault+0xc9f)[0x56790e7f]

[ci-105-2493316c:08193] [23] /usr/bin/python3.10(+0x163c00)[0x567b1c00]
[ci-105-2493316c:08193] [24] 
/usr/bin/python3.10(PyObject_Call+0x71)[0x567b2641]
[ci-105-2493316c:08193] [25] 
/usr/bin/python3.10(_PyEval_EvalFrameDefault+0x2cc2)[0x56792ea2]
[ci-105-2493316c:08193] [26] 
/usr/bin/python3.10(_PyObject_FastCallDictTstate+0xb8)[0x5679b988]
[ci-105-2493316c:08193] [27] 
/usr/bin/python3.10(_PyObject_Call_Prepend+0x54)[0x567aef54]

[ci-105-2493316c:08193] [28] /usr/bin/python3.10(+0x26182d)[0x568af82d]
[ci-105-2493316c:08193] [29] 
/usr/bin/python3.10(_PyObject_MakeTpCall+0x257)[0x5679c727]

[ci-105-2493316c:08193] *** End of error 

Bug#1009737: pillow breaks pikepdf autopkgtest: assert im.getpixel((1, 1)) == rgb fails

[Paul Gevers]

Source: pillow, pikepdf
Control: found -1 pillow/9.1.0-1
Control: found -1 pikepdf/5.0.1+dfsg-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
pillow from testing9.1.0-1
pikepdffrom testing5.0.1+dfsg-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 pillow 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=pillow

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pikepdf/20839512/log.gz

= test session starts 
==

platform linux -- Python 3.9.12, pytest-6.2.5, py-1.10.0, pluggy-1.0.0
rootdir: /tmp/autopkgtest-lxc.97u180kp/downtmp/build.9cn/src, 
configfile: pyproject.toml, testpaths: tests

plugins: xdist-2.5.0, forked-1.4.0, timeout-2.1.0, hypothesis-6.36.0
gw0 I
gw0 [510]

 
[ 14%]
x.Fss... 
[ 28%]
sss. 
[ 42%]
s... 
[ 56%]
 
[ 70%]
...s 
[ 84%]
.... 
[ 98%]
.. 
 [100%]
=== FAILURES 
===
_ test_image_palette[pal-1bit-rgb.pdf-1-rgb2] 
__

[gw0] linux -- Python 3.9.12 /usr/bin/python3

resources = 
PosixPath('/tmp/autopkgtest-lxc.97u180kp/downtmp/build.9cn/src/tests/resources')

filename = 'pal-1bit-rgb.pdf', bpc = 1, rgb = (255, 128, 0)

@pytest.mark.parametrize(
'filename,bpc,rgb',
[
('pal.pdf', 8, (0, 0, 255)),
('pal-1bit-trivial.pdf', 1, (255, 255, 255)),
('pal-1bit-rgb.pdf', 1, (255, 128, 0)),
],
)
def test_image_palette(resources, filename, bpc, rgb):
pdf = Pdf.open(resources / filename)
pim = PdfImage(next(iter(pdf.pages[0].images.values(
assert pim.palette[0] == 'RGB'
assert pim.colorspace == '/DeviceRGB'
assert not pim.is_inline
assert pim.mode == 'P'
assert pim.bits_per_component == bpc
outstream = BytesIO()
pim.extract_to(stream=outstream)
im = pim.as_pil_image().convert('RGB')

  assert im.getpixel((1, 1)) == rgb

E   assert (255, 255, 255) == (255, 128, 0)
E At index 1 diff: 255 != 128
E Use -v to get the full diff

tests/test_image_access.py:520: AssertionError
=== short test summary info 

FAILED 
tests/test_image_access.py::test_image_palette[pal-1bit-rgb.pdf-1-rgb2]
 1 failed, 493 passed, 15 skipped, 1 xfailed in 29.67s 
=

autopkgtest [16:18:04]: test test-suite



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996262: libticables: Patch to add riscv64 support

[Aurelien Jarno]

On 2022-04-15 12:55, Ileana Dumitrescu wrote:
> Hi Aurelien,
> 
> > Yes, I can upload a package. Just prepare it on salsa and tell me when it's 
> > ready. I can fetch it from there, build it and upload it.
> 
> The package is ready on salsa now. I appreciate you taking care of the 
> upload. I am getting more involved in debian packaging and porting work, so 
> please feel free to reach out if you have any tasks or bugs that you need 
> help with.

I just get got a quick look, and it appears that while the package looks
ready, the changelog still says "UNRELEASED".

Could you please change it to unstable, and create the corresponding
tag? That's basically running "dch -r", "git commit" and "git tag", but
that might be done in a single step with other tools depending on the
workflow you use (for instance debcommit or gbp).

I'll just doing the building and signing part, that way you will
correctly appear as the one who have done the job.

Aurelien

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


signature.asc
Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Matthew Vernon]

Hi,

Thanks for the feedback on my previous draft; here's a revised ballot.

I propose a ballot as follows - if no-one suggests further options in 
the mean time, I will call for a vote on this ballot on Tuesday, after 
the weekend of public holidays.


From a procedural point of view, I am formally withdrawing both ballot 
options I proposed in <9012b2bf-dd1f-afc4-7f62-75ba4116b...@debian.org> 
(thus voiding that process per constitution 6.3.1.3), and starting afresh.


===Rationale

There are two "rename" programs - the perl rename, and the util-linux 
rename. Debian and its derivatives have shipped the perl rename as 
/usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped 
the util-linux rename thus. The two implementations are incompatible. 
Users might reasonably desire both implementations to be available on 
the same system; they are designed to meet different needs.


Backwards-compatibility (and the lack of a compelling argument that 
rename from util-linux should replace perl rename) means that 
/usr/bin/rename in Debian should remain the perl rename.


Prior to bullseye, util-linux's rename was shipped as 
/usr/bin/rename.ul; Debian's users who wish to use util-linux's rename 
will expect it to be in this location.


===End Rationale

===Begin Resolution

The Technical Committee overrides the util-linux maintainer, and 
requires that util-linux's rename should be shipped in a binary package 
built from src:util-linux. If this package Conflicts with the rename 
package, then it should not contain any other binaries.


The Technical Committee further requires that this binary should be 
shipped as /usr/bin/rename.ul


===End Resolution

A: Override util-linux maintainer, approve entire resoltuion
B: Override util-linux maintainer, approve only first paragraph of 
resolution

N: None of the above

Regards,

Matthew

Bug#1009736: python-django-netfields: autopkgtest regression: No module named 'django'

[Paul Gevers]

Source: python-django-netfields
Version: 1.3.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


passfail
python-django-netfields from testing1.3.0-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 to testing [1]. Can 
you please investigate the situation and fix it?


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

Paul

[1] https://qa.debian.org/excuses.php?package=python-django-netfields

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-django-netfields/20843785/log.gz

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

from netfields.managers import NetManager
  File "/usr/lib/python3/dist-packages/netfields/managers.py", line 1, 
in 

from django.db import models
ModuleNotFoundError: No module named 'django'
autopkgtest [23:14:29]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009734: mutt: CVE-2022-1328

[Salvatore Bonaccorso]

Source: mutt
Version: 2.1.4-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.0.5-4.1
Control: found -1 1.10.1-2.1+deb10u5
Control: found -1 1.10.1-1
Control: clone -1 -2
Control: reassign -2 src:neomutt 20211029+dfsg1-1
Control: retitle -2 neomutt: CVE-2022-1328

Hi,

The following vulnerability was published for mutt, the issue
similarly has it's sister in neomutt, so cloning the bug, [3] refers
to the fix in neomutt.

CVE-2022-1328[0]:
| Buffer Overflow in uudecoder in Mutt affecting all versions starting
| from 0.94.13 before 2.2.3 allows read past end of input line


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-1328
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1328
[1] https://gitlab.com/muttmua/mutt/-/issues/404
[2] 
https://gitlab.com/muttmua/mutt/-/commit/e5ed080c00e59701ca62ef9b2a6d2612ebf765a5
[3] 
https://gitlab.com/neomutt/neomutt/-/commit/ee7cb4e461c1cdf0ac14817b03687d5908b85f84

Regards,
Salvatore

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Matthew Vernon]

On 15/04/2022 07:36, Gunnar Wolf wrote:


Matthew Vernon dijo [Thu, Apr 14, 2022 at 04:47:17PM +0100]:

Backwards-compatibility (and the lack of a compelling argument that
util-linux's rename is significantly superior to the perl rename) means that
/usr/bin/rename in Debian should remain the perl rename.


I'd prefer to read "that neither 'rename' implementation is superior
to the other", maybe even explaining that "they were designed out of
different needs and meet different criteria".


I intended to cover that in the first paragraph; my point here was that 
there would need to be some compelling reason to change our 
/usr/bin/rename implementation now (such as the util-linux one being 
much better). I'll try and draft it better.


Regards,

Matthew

Bug#1009733: src:exempi: fails to migrate to testing for too long: FTBFS on armel and armhf

[Paul Gevers]

Source: exempi
Version: 2.5.2-1
Severity: serious
Control: close -1 2.6.1-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:exempi has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. You package failed to build from 
source on armel and armhf where it built successfully in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=exempi



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009732: src:ghdl: fails to migrate to testing for too long: ftbfs on armhf

[Paul Gevers]

Source: ghdl
Version: 1.0.0+dfsg-6
Severity: serious
Control: close -1 1.0.0+dfsg-8
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ghdl has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. You package failed to build from 
source on armhf where it built successfully in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=ghdl



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009727: O: ruby-curses -- curses binding for Ruby

[Axel Beckert]

Hi Andrej,

Andrej Shadura wrote:
> > Shall I close this bug already again as you still seem to care about
> > ruby-curses in contrary to what you stated back in 2020?
> 
> No, I still don’t intend to continue maintaining it 

*g*

> I originally packaged it as a dependency of a Ruby implementation of
> git-crecord which I wanted to package. However, I quickly became
> unsatisfied with it and instead ported the Python code of hg-crecord
> to Git, so ruby-curses became useless to me.

I see, thanks for that background information.

> If your package uses ruby-curses, it would be great if you could
> maintain this package in the Ruby team.

I was already thinking about doing an NMU or QA upload, but I
currently don't intend to adopt ruby-curses for various reasons:

* I've nearly no experience with Ruby and no experience with ruby
  library packaging or the according workflow at all.

* I already maintain too many packages. :-/

* The package in question (irqtop) is just a bycatch of the source
  package's main package I'm interested in: iptables-netflow-dkms.

  It sidekick irqtop is mostly a performance analysis and debug tool
  for that kernel module despite it has more general use cases, too.

  And I don't want ruby dependencies in a kernel module package for
  high performance traffic statistics. :-)

* The future of the irqtop package is a bit unclear since util-linux
  upstream introduced a C written command of the same name recently,
  too. See https://bugs.debian.org/1009668 for that discussion.

Anyway, thanks to your upload the most annoying issue with irqtop (the
ruby-written one) is now gone. Thanks again! :-)

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

Bug#1009731: libglu1-mesa-dev: pkg-config file glu.pc depends on opengl.pc

[Tobias Hansen]

Package: libglu1-mesa-dev
Version: 9.0.2-1
Severity: serious
Control: block 1008372 by -1

Hi,

recently sludge started to FTBFS with the following error, see #1008372:

Package 'opengl', required by 'glu', not found

I believe this is because glu.pc now depends on opengl.pc which means that 
libglu1-mesa-dev should depend on libopengl-dev which contains opengl.pc.

I checked that sludge build successfully when installing libopengl-dev.

Best wishes,
Tobias

Bug#1009727: O: ruby-curses -- curses binding for Ruby

[Andrej Shadura]

Hi,

On Fri, 15 Apr 2022, at 17:55, Axel Beckert wrote:
> Andrej Shadura wrote:
>> On Fri, 15 Apr 2022, at 16:23, Axel Beckert wrote:
>> > Acoording to
>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 (also
>> > attached) the ruby-curses package in Debian is orphaned since at least
>> > April 2020 (last upload April 2018) as both the team listed in the
>> > Maintainer field as well as the person listed in the Uploaders field
>> > (all X-Debbugs-CC'ed) stated back then, that they are not maintaining
>> > this package. And there was no new upload since then either.
>> 
>> Thanks for filing this bug. I have uploaded a newer release, pushed
>> the Git changes to Salsa and will attempt to move it to the Ruby
>> team.
>
> Thanks a lot! That's really an unexpected and positive surprise!
>
> Shall I close this bug already again as you still seem to care about
> ruby-curses in contrary to what you stated back in 2020?

No, I still don’t intend to continue maintaining it 
I originally packaged it as a dependency of a Ruby implementation of 
git-crecord which I wanted to package. However, I quickly became unsatisfied 
with it and instead ported the Python code of hg-crecord to Git, so ruby-curses 
became useless to me.
If your package uses ruby-curses, it would be great if you could maintain this 
package in the Ruby team.

-- 
Cheers,
  Andrej

Bug#982784: Packaged

[Diane Trout]

Hi,

I'm not sure if anyone else worked on this but I do have some packaging
for flatseal.

I'd like to see about joining the DebianOnMobile team first and hosting
the package in that group before uploading it to new.

Diane

Bug#1009730: RFP: fonts-nunitosans -- A well-balanced Sans Serif font with rounded terminals.

[Eric Brown]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: e...@ericebrown.com

* Package name: fonts-nunitosans
  Version : 3.006.0
  Upstream Author : Vernon Adams 
* URL : https://github.com/googlefonts/NunitoSans
* License : SIL OFL 1.1
  Programming Lang: n/a
  Description : A well-balanced Sans Serif font with rounded terminals.

"Nunito is a well balanced Sans Serif with rounded terminals. Nunito has been 
designed mainly to be used as a display font but is useable as a text font too. 
Nunito has been designed to be used freely across the internet by web browsers 
on desktop computers, laptops and mobile devices.

In November 2017 Nunito has been expanded to GF Cyrillic Pro by Manvel 
Shmavonyan, and Alexei Vanyashin."

This is a Google Web Font. It is used in bootstrap themes. It is a dependency 
of r-cran-bslib. 
It would be appropriate for the Debian Font team to maintain.

Bug#1009632: The QPA plugin package contains the TLS backends

[Robert Griebl]

Hi Patrick,

On 15.04.2022 18:03, Patrick Franz wrote:

And while we're at it: the image format plugins also do not really
belong into the qpa plugin package for the same reasons: you can use
QtGui and the QImage classes perfectly fine in a headless daemon:

/usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqgif.so
/usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqico.so
/usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqjpeg.so


Which package name do you suggest ? We already have " qt6-image-formats-
plugins", but that is from the qtimageformats module.


The question is how modular we really want to be here: as gif and jpg 
are really standard image formats, I'd rather package those up in the 
libqt6gui6 package (as it was done for libqt5gui5).


If you do want to split them off, then it might be something like 
"qt6-[base|gui]-image-formats-plugins".
You'd probably have to rename the existing package 
("qt6-image-formats-plugins") to "qt6-extra-image-formats-plugins" as 
well to avoid confusion.


cu
Robert

Bug#1009729: RFP: fonts-neucha -- A sans serif font available on Google Fonts

[Eric Brown]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: e...@ericebrown.com

* Package name: fonts-neucha
  Version : 1.0.0
  Upstream Author : Jovanny Lemonad 
* URL : https://typetype.org/freefonts/
* License : SIL OFL 1.1
  Programming Lang: n/a
  Description : A sans serif font available on Google Fonts

An OTF font available as a Google Web Font 
(https://fonts.google.com/specimen/Neucha).

This open source font is used in bootstrap themes and is a dependency of e.g. 
r-cran-bslib.

The .otf file and licence are available here: 

Bug#1009728: gnome-shell 42.0-3 depends instead of recommends power-profiles-daemon, conflicts with tlp

[Gijs Hillenius]

Package: gnome-shell
Version: 42.0-2
Severity: normal

Dear Maintainer,

* What led up to the situation?

apt update ; apt upgrade

results in:

The following packages have unmet dependencies:
tlp : Conflicts: power-profiles-daemon but 0.10.1-3 is to be installed
E: Broken packages

It looks like this version depends on power-profiles-daemon, instead of 
recommending it.

This is a temporary work-around to continue the upgrade

echo "gnome-shell hold" | dpkg --set-selections


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

Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  evolution-data-server3.44.0-3
ii  gir1.2-accountsservice-1.0   22.07.5-1
ii  gir1.2-adw-1 1.1.0-1
ii  gir1.2-atk-1.0   2.38.0-1
ii  gir1.2-atspi-2.0 2.44.0-3
ii  gir1.2-freedesktop   1.72.0-1+b1
ii  gir1.2-gcr-3 3.40.0-4
ii  gir1.2-gdesktopenums-3.0 42.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.8+dfsg-1
ii  gir1.2-gdm-1.0   42.0-1
ii  gir1.2-geoclue-2.0   2.6.0-1
ii  gir1.2-glib-2.0  1.72.0-1+b1
ii  gir1.2-gnomebluetooth-3.042.0-5
ii  gir1.2-gnomedesktop-3.0  42.0-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.20.1-1
ii  gir1.2-gtk-3.0   3.24.33-1
ii  gir1.2-gtk-4.0   4.6.2+ds-1
ii  gir1.2-gweather-4.0  4.0.0-2
ii  gir1.2-ibus-1.0  1.5.26-4
ii  gir1.2-mutter-10 42.0-3
ii  gir1.2-nm-1.01.36.4-2
ii  gir1.2-nma-1.0   1.8.38-1
ii  gir1.2-pango-1.0 1.50.6+ds-2
ii  gir1.2-polkit-1.00.105-33
ii  gir1.2-rsvg-2.0  2.52.5+dfsg-3+b1
ii  gir1.2-soup-2.4  2.74.2-3
ii  gir1.2-upowerglib-1.00.99.17-1
ii  gir1.2-webkit2-4.0   2.36.0-3
ii  gnome-backgrounds42.0-1
ii  gnome-settings-daemon42.1-3
ii  gnome-shell-common   42.0-2
ii  gsettings-desktop-schemas42.0-1
ii  gstreamer1.0-pipewire0.3.50-1
ii  libatk-bridge2.0-0   2.38.0-4
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libecal-2.0-13.44.0-3
ii  libedataserver-1.2-263.44.0-3
ii  libgcr-base-3-1  3.40.0-4
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libgirepository-1.0-11.72.0-1+b1
ii  libgjs0g 1.72.0-2
ii  libgles2 1.4.0-1
ii  libglib2.0-0 2.72.1-1
ii  libglib2.0-bin   2.72.1-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-1942.0-2
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.33-1
ii  libgtk-4-1   4.6.2+ds-1
ii  libical3 3.0.14-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-10-0   42.0-3
ii  libnm0   1.36.4-2
ii  libpango-1.0-0   1.50.6+ds-2
ii  libpangocairo-1.0-0  1.50.6+ds-2
ii  libpolkit-agent-1-0  0.105-33
ii  libpolkit-gobject-1-00.105-33
ii  libpulse-mainloop-glib0  15.0+dfsg1-4
ii  libpulse015.0+dfsg1-4
ii  libsecret-1-00.20.5-2
ii  libsystemd0  250.4-1
ii  libwayland-server0   1.20.0-1
ii  libx11-6 2:1.7.5-1
ii  libxfixes3   1:6.0.0-1
ii  python3  3.10.4-1

Bug#1009632: The QPA plugin package contains the TLS backends

[Patrick Franz]

Hi Robert,

On Wed, 13 Apr 2022 12:02:36 +0200 Robert Griebl  
wrote:
> Package: qt6-qpa-plugins
> Version: 6.2.2
> 
> The new Qt6 plugins for the TLS backend (QSslSocket) got packaged with 
> the QPA plugins, which is a bit awkward if you have a headless daemon 
> that needs to download from https:// URLs, because you are now pulling 
> in a lot of X11 and OpenGL dependencies.
> 
> I think these should be in their own qt6-tls-plugins package:
> 
> /usr/lib/x86_64-linux-gnu/qt6/plugins/tls/libqcertonlybackend.so
> /usr/lib/x86_64-linux-gnu/qt6/plugins/tls/libqopensslbackend.so

We can do that when we package Qt 6.3, because we'll have new binary 
packages anyway then.


> And while we're at it: the image format plugins also do not really 
> belong into the qpa plugin package for the same reasons: you can use 
> QtGui and the QImage classes perfectly fine in a headless daemon:
> 
> /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqgif.so
> /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqico.so
> /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqjpeg.so

Which package name do you suggest ? We already have " qt6-image-formats-
plugins", but that is from the qtimageformats module.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1009668: irqtop/lsirq: missing commands in util-linux package

[Axel Beckert]

Hi Chris,

Chris Hofstaedtler wrote:
> > As far as I can see, I didn't get a reply back from you on these
> > suggestions of mine. Maybe my mail fell through the cracks. But I
> > think we should take the discussion up again, probably in this bug
> > report.
> 
> Right. I think I forgot to reply back then - sorry.

Happens…

> Experimental should have util-linux-extra 2.38-4+exp1 very soon,
> with irqtop installed. Obviously this can only be used for testing.

Thanks. That package though seems to miss the "Conflicts: irqtop". :-/
But I was aware of it and uninstalled irqtop beforehand. :-)

> Personally I think we should have only one irqtop - from my point of
> view it does not matter which one. Maybe the new version is
> superior.

H.

> In any case we should not confuse our users.

Fully agree. Nevertheless, Debian is a lot about having choice between
different implementations (compared to e.g. Ubuntu). And choice
sometimes makes things less easier to understand.

> > Another point which comes to my mind now is that it might make sense
> > to rename the current irqtop package to irqtop-nf (or irqtop-ruby)
> > just to make clear that it does not contain the irqtop tool from
> > util-linux.
> 
> Might be an idea. But lets see what the differences are, first.

Ack.

zhenwei pi wrote:
> The main difference between the two versions:
> - original irqtop shows separated interrupt information
> - new irqtop shows aggregate interrupt information

Thanks for that summary.

(I btw. just noticed that zhenwei is actually the author of
util-linux's implementation of irqtop:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d511011c
refers to https://github.com/pizhenwei/irqtop as previous place of
development. :-)

> Test env: Debian 10; 96 CPUs on a server, 230 characters per line in
> termial.
> 
> - irqtop (original version) shows uncompleted interrupts(31 / 96 CPUs).

Hrm, interesting.

> n194-087-081 - irqtop - 2022-04-15 09:42:48 +0800
>   CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   CPU6   CPU7   CPU8   
> CPU9  CPU10  CPU11  CPU12  CPU13  CPU14  CPU15  CPU16  CPU17  CPU18  CPU19  
> CPU20  CPU21  CPU22  CPU23  CPU24  CPU25  CPU26  CPU27  CPU28  CPU29  CPU30  
> […]
>   cpuUtil: 0.00.00.40.01.30.00.00.20.0
> 0.00.00.00.00.00.20.00.00.00.00.0
> 0.00.00.00.00.00.20.20.20.20.00.2
>  %irq: 0.00.00.00.00.00.00.00.00.0
> 0.00.00.00.00.00.00.00.00.00.00.0
> 0.00.00.00.00.00.00.00.00.00.00.0
> %sirq: 0.00.00.00.00.00.00.00.00.0
> 0.00.00.00.00.00.00.00.00.00.00.0
> 0.00.00.00.00.00.00.00.00.00.00.0
>  irqTotal:  32293477  5 34  7  5   1805112
>  51  3  2 28  2   1901  1 13 16  0  6 
>  1 19  2  2 67 29 51 51 42  9 34
> i   9:   .  2  0  0  0  .  .  .  .
>   .  .  .  .  .  .  .  .  .  .  . 
>  .  .  .  .  .  .  .  .  .  .  .
> i  48:   .  .  .  .  .  .  0  .  .
>   .  .  .  .  .  .  .  .  .  .  . 
>  .  .  .  .  .  .  .  .  .  .  .
> i  49:   .  .  .  .  .  .  .  .  .
>   .  .  .  .  .  .  .  .  .  .  . 
>  .  .  .  .  .  .  .  .  .  .  .
> i  50:   .  .  .  .  .  .  .  .  .
>   .  .  .  .  .  .  .  .  .  .  . 
>  .  .  .  .  .  .  .  .  .  .  .
> i  51:   .  .  .  .  .  .  .  .  .
>   .  .  .  .  .  .  .  .  .  .  . 
>  .  .  .  .  .  .  .  .  .  .  .


I currently only have access to boxes with 32 cores, but it shows all
of them and also some additional information in the last column which
seems to have been stripped from your instance due to probably the
limited terminal width. Mine looks like this and also has IRQ names
shown instead of numbers:

somehost - irqtop - 2022-04-15 15:13:12 +
  CPU0   CPU1   CPU2   CPU3   CPU4   CPU5   CPU6   CPU7   CPU8   
CPU9  CPU10  CPU11  CPU12  CPU13  CPU14  CPU15  CPU16  CPU17  CPU18  CPU19  
CPU20  CPU21  CPU22  CPU23  CPU24  CPU25  CPU26  CPU27  CPU28  CPU29  CPU30  
CPU31
  cpuUtil: 0.00.00.0

Bug#1009727: O: ruby-curses -- curses binding for Ruby

[Axel Beckert]

Hi Andrej,

Andrej Shadura wrote:
> On Fri, 15 Apr 2022, at 16:23, Axel Beckert wrote:
> > Acoording to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 (also
> > attached) the ruby-curses package in Debian is orphaned since at least
> > April 2020 (last upload April 2018) as both the team listed in the
> > Maintainer field as well as the person listed in the Uploaders field
> > (all X-Debbugs-CC'ed) stated back then, that they are not maintaining
> > this package. And there was no new upload since then either.
> 
> Thanks for filing this bug. I have uploaded a newer release, pushed
> the Git changes to Salsa and will attempt to move it to the Ruby
> team.

Thanks a lot! That's really an unexpected and positive surprise!

Shall I close this bug already again as you still seem to care about
ruby-curses in contrary to what you stated back in 2020?

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

Bug#1009421: libktoblzcheck: FTBFS: dh_missing: error: missing files, aborting

[Micha Lenk]

Control: tags -1 bookworm

This bug does not affect Debian bullseye.

Bug#1009727: O: ruby-curses -- curses binding for Ruby

[Andrej Shadura]

Hi,

On Fri, 15 Apr 2022, at 16:23, Axel Beckert wrote:
> Acoording to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 (also
> attached) the ruby-curses package in Debian is orphaned since at least
> April 2020 (last upload April 2018) as both the team listed in the
> Maintainer field as well as the person listed in the Uploaders field
> (all X-Debbugs-CC'ed) stated back then, that they are not maintaining
> this package. And there was no new upload since then either.

Thanks for filing this bug. I have uploaded a newer release, pushed the Git 
changes to Salsa and will attempt to move it to the Ruby team.

-- 
Cheers,
  Andrej

Bug#1009727: O: ruby-curses -- curses binding for Ruby

[Axel Beckert]

Package: wnpp
Severity: normal

Acoording to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959115#10 (also
attached) the ruby-curses package in Debian is orphaned since at least
April 2020 (last upload April 2018) as both the team listed in the
Maintainer field as well as the person listed in the Uploaders field
(all X-Debbugs-CC'ed) stated back then, that they are not maintaining
this package. And there was no new upload since then either.

This probably also explains why the package lacks multiple generations
of new upstream releases (currently 1.2.4 vs 1.4.4 according to
https://tracker.debian.org/pkg/ruby-curses) despite there is an
related bug report from April 2020. (https://bugs.debian.org/958973,
refering already to upstream version 1.3.2.) That bug report now has
become release-critical as the outdated version 1.2.4 in Debian
Unstable is not compatible with Ruby 3.0. And Ruby 3.0 is now is in
both Debian Unstable and Testing for more than a month, making
probably all reverse dependencies unusable

(Discovering #959115 after raising the severity of #958973 to
release-critical actually triggered this package-orphaning mail.)

Some information on the package:

Package: ruby-curses
Source: ruby-curses (1.2.4-1)
Version: 1.2.4-1+b6
Installed-Size: 89
Maintainer: Debian Ruby Extras Maintainers 

Architecture: amd64
Depends: ruby (>= 1:3.0~0), libc6 (>= 2.4), libncursesw6 (>= 6), libtinfo6 (>= 
6), libruby3.0 (>= 3.0.0~preview1), ruby (<< 1:3.1~)
Description: curses binding for Ruby
 Ruby binding for curses, ncurses, and PDCurses. curses is an
 extension library for text UI applications.
 .
 This module is built with wide character support.
Homepage: http://github.com/ruby/curses
Ruby-Versions: ruby3.0
Tag: uitoolkit::ncurses
Section: ruby
Priority: optional
Filename: pool/main/r/ruby-curses/ruby-curses_1.2.4-1+b6_amd64.deb
Size: 22176

Package: ruby-curses
Binary: ruby-curses
Version: 1.2.4-1
Maintainer: Debian Ruby Extras Maintainers 

Uploaders: Andrej Shadura 
Build-Depends: debhelper (>= 9~), gem2deb, libncursesw5-dev
Architecture: any
Standards-Version: 3.9.7
Format: 3.0 (quilt)
Files:
 75861e824ca9ea030b68b70d4fcb87c9 1752 ruby-curses_1.2.4-1.dsc
 866cd65ade499eaedbbaab7e35887b22 31399 ruby-curses_1.2.4.orig.tar.gz
 e21b2f8e218d1b13966a30f9e44c073c 2908 ruby-curses_1.2.4-1.debian.tar.xz
Vcs-Browser: https://browse.dgit.debian.org/ruby-curses.git/
Vcs-Git: https://git.dgit.debian.org/ruby-curses
Homepage: http://github.com/ruby/curses
Dgit: 4eab6fe2b7f725fc089335ad43387e234bd1bb02 debian archive/debian/1.2.4-1 
https://git.dgit.debian.org/ruby-curses
Package-List:
 ruby-curses deb ruby optional arch=any
Ruby-Versions: all
Testsuite: autopkgtest-pkg-ruby
Directory: pool/main/r/ruby-curses
Priority: optional
Section: misc

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
--- Begin Message ---
On Wed, Apr 29, 2020 at 11:20:42AM -0300, Antonio Terceiro wrote:
> This package says its maintained by the Debian Ruby team, but it's not
> in the team repositories.
> 
> Maintainer: Debian Ruby Extras Maintainers 
> 
> Uploaders: Andrej Shadura 
> [...]
> Vcs-Browser: https://browse.dgit.debian.org/ruby-curses.git/
> Vcs-Git: https://git.dgit.debian.org/ruby-curses
> 
> If it's intendent to be team-maintained, it should be added to the
> ruby-team group on salsa. Otherwise, please do not list the team in the
> Maintainer: field.

Thanks for noticing. I do not intend to use or maintain this package, feel
free to properly take it over. Since it is currently in dgit only, the
repo is missing the upstream branch (since dgit doesn’t preserve it), but
I’m sure it should be fairly easy to identify the commit the branch should
be pointing at.

-- 
Cheers,
  Andrej--- End Message ---


signature.asc
Description: PGP signature

Bug#1009726: bullseye-pu: package samba/2:4.13.13+dfsg-1+deb11u4

[Michael Tokarev]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Debian Samba Maintainers 

Here's the proposed samba package update for bullseye.
I picked up a few patches which were missing when we
did security updates: we only picked up the security-
related patches from upstream but missed bugfixes.
Evem missed a known regression caused by two of the
security fixes in there (#999876, #1001053).

[ Reason ]
The reason for this update is simple: to fix quite some
bugs accumulated in there. Including one serious data
corruption issue.  The bugs being fixed are:

 #999876, winbind fails to start with `allow trusted domains: no`
  regression after a security fix
 #1001053 MIT-kerberos auth broken after 4.13.13+dfsg-1~deb11u2
  regression after a security fix
 #1004691 CVE-2021-43566: mkdir race condition allows share escape
 #1005642 possible data corruption due to windows client
  cache poisoning
 #998423 server coredump possible with share names containing
  %-variable substitutions
 #953530 unable to install samba on non-systemd system due to missing
  /run/samba dir before running samba tools

[ Tests ]
All code changes are coming from the upstream stable releases.
I included *all* changes from actual released 4.13.17 upstream
stable series (with all the known regressions there fixed),
except of the changes for parts we do not use (to lib/ldb/ -
this is our separate ldb package). So for the tests, this
release is much closer to the the one which survived the
excellent upstream testsuite and which has been tested
worldwide (what we had in bullseye-security before is some
mix from there).

Other code changes which are from releases later than 4.13.17
(which is the last upstream stable release for the 4.13 series)
are also taken from upstream stable fixes but destined for
later series.

The whole patch set has been running at our sites for quite
a while, for one it fixed the data corruption issue which
hit us hard (#1005642). We're running this since Feb-2022.

And we already run this release on all our production systems
with all the changes included (except it is using the UNRELEASED
build) for quite some time.

There's just one non-code change in there, #953530 - mkdir
/run/samba in postinst before invoking samba. I did verify
this actually fixes the issue (inability to install samba
on a non-systemd system), but this one does not affect
systems that are upgrading samba, as this directory is
already there.

[ Risks ]
There are risks, as with any complex piece of software.
Overall this release should be less risky than current
release in bullseye-security due to the fixes it missed.

[ 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

[ Changes ]

From the d/changelog:

  * Import the left-other patches from 4.13.17 upstream stable branch:
   - s3-winbindd-fix-allow-trusted-domains-no-regression.patch
 Closes: #999876, winbind fails to start with `allow trusted domains: no`
   - IPA-DC-add-missing-checks.patch
   - CVE-2020-25717-s3-auth-fix-MIT-Realm-regression.patch
 Closes: #1001053, MIT-kerberos auth broken after 4.13.13+dfsg-1~deb11u2
   - dsdb-Use-DSDB_SEARCH_SHOW_EXTENDED_DN-when-searching.patch
   - s3-smbd-Fix-mkdir-race-condition-allows-share-escape.patch
  Closes: #1004691, CVE-2021-43566:
  mkdir race condition allows share escape

This brings us up to the upstream 4.13.17, - I verified both the result
after applying all the d/patches/ patches, and every individual patch
from there.  We are now at 4.13.17 release *except* of the version number
and the changes in lib/ldb/ which are packaged separately.

  * 4 patches from upstream to fix possible serious data corruption issue
with windows client cache poisoning, Closes: #1005642

This comes from upstream targetting later samba series, backported to
all relevant stable series. The prob has been fixed after 4.13.17
went end-of-life.

  * two patches from upstream to fix coredump when connecting to shares
with var substitutions, Closes: #998423

Ditto.

  * samba-common-bin.postinst: mkdir /run/samba before invoking samba binaries
Closes: #953530

This simple change helps new installs on systemd-less systems

  * remove file creation+deletion from previously applied combined patches
CVE-2021-23192-only-4.13-v2.patch & CVE-2021-3738-dsdb-crash-4.13-v03.patch
to make patch deapply happy (quilt does not notice this situation)

This one is kinda interesting. Previous security upload included two
cumulative .patch files (containing several git commits in single file),
with first of them adding a file, and second removing that just-added file.
This does not work right with quilt, it keeps such "phantom" file in the
source tree when deapplying patches, so subsequent apply fails due to 

Bug#1009397: dh-python: Flit plugin suddenly installs to usr/local/ causing FTBFS

[Stefano Rivera]

Hi Philip (2022.04.15_14:06:28_+)
> I think I found a way to fix it, just like you did it here 
> https://salsa.debian.org/python-team/tools/dh-python/-/commit/6137db4dc870672615c31c9d1c9535dafe5b0d2a
> I'll create a MR later.

Aha, of course. You can try to use the pyproject plugin, directly (we
should retire the flit plugin in favour of it, at some point). But yes,
fixing the flit plugin should be simple enough...

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1009725: libapache2-mod-auth-openidc: Regression related to handling of redirects

[Kamil Hipsz]

Package: libapache2-mod-auth-openidc
Version: 2.4.9-1
Severity: normal

Dear Maintainer,

While using libapache2-mod-auth-openidc (version 2.4.9-1) from bullseye with 
following configuration:

OIDCMetadataDir /var/www/apache/metadata
OIDCDiscoverURL /oidc/select_authentication_provider.php


AuthType openid-connect
Require claim groups:xxx----



OIDCUnAuthAction pass



Response is 401 Unauthorized, no redirection is made to 
/oidc/select_authentication_provider.php. Even built-in login page is not 
working after disabling OIDCDiscoverURL.
This is a known regression in the upstream project introduced in 2.4.9-1 
https://github.com/zmartzone/mod_auth_openidc/commit/ac5686495a51bc93e257e42bfdc9c9c46252feb1
 
and fixed in 2.4.9.4-1 
https://github.com/zmartzone/mod_auth_openidc/commit/d6a9361a46753f631b5e683a7e293a950da1e211.

Discussion: 
https://github.com/zmartzone/mod_auth_openidc/discussions/746#discussioncomment-1717573

After installing version 2.4.9.4-1 from github 
https://github.com/zmartzone/mod_auth_openidc/releases/tag/v2.4.9.4 or later, 
issue is fixed. 
Would it be possible to backport this change to package available in bullsyeye?

Thanks a lot.

Greetings,
Kamil

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

Kernel: Linux 5.10.0-13-amd64 (SMP w/16 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libapache2-mod-auth-openidc depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.53-1~deb11u1
ii  libc6   2.31-13+deb11u3
ii  libcjose0   0.6.1+dfsg1-1
ii  libcurl47.74.0-1.3+deb11u1
ii  libhiredis0.14  0.14.1-1
ii  libjansson4 2.13.1-1.1
ii  libpcre32:8.39-13
ii  libssl1.1   1.1.1n-0+deb11u1

libapache2-mod-auth-openidc recommends no packages.

libapache2-mod-auth-openidc suggests no packages.

-- no debconf information

Bug#1009397: dh-python: Flit plugin suddenly installs to usr/local/ causing FTBFS

[Stefano Rivera]

Hi Philip (2022.04.15_08:44:42_+)
> I'm writing to the list as I'm not sure what the source of the problem is.

It'll be something related to
https://lists.debian.org/debian-python/2022/03/msg00039.html

I'll have a more detailed look, later today.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#958973: ruby-curses: Emits warning: "rb_safe_level will be removed in Ruby 3.0", fixed upstream in 1.3.2

[Axel Beckert]

Control: severity -1 serious

Axel Beckert wrote:
> running ruby-written irqtop on Debian Unstable contantly emits this
> warning:
> 
> /usr/bin/irqtop:545: warning: rb_safe_level will be removed in Ruby 3.0
> 
> which makes it quite unusable as the curses screen looks like this after
> a few seconds:

Ruby 3.0 is now the default in Debian Unstable and Testing and due to
this error, irqtop no more works at all there:

~ → irqtop
:85:in 
`require': /usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/3.0.0/curses.so: 
undefined symbol: rb_safe_level - 
/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/3.0.0/curses.so (LoadError)
from 
:85:in 
`require'
from /usr/lib/ruby/vendor_ruby/curses.rb:18:in `rescue in '
from /usr/lib/ruby/vendor_ruby/curses.rb:14:in `'
from 
:85:in 
`require'
from 
:85:in 
`require'
from /usr/bin/irqtop:9:in `'
:85:in 
`require': cannot load such file -- 3.0/curses.so (LoadError)
from 
:85:in 
`require'
from /usr/lib/ruby/vendor_ruby/curses.rb:16:in `'
from 
:85:in 
`require'
from 
:85:in 
`require'
from /usr/bin/irqtop:9:in `'

Raising the severity to serious accordingly.

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

Bug#1008973: (no subject)

[Julien Negros]

Hi,

Same issue here, switching to linux-image-5.15.0-0.bpo.3-amd64 did the 
trick. Hope the next kernel version fixes this problem !


Cheers
--
Julien Négros

Bug#1009231: Write errors since upgrade to 9.6.7-4

[Sven Hartge]

On 15.04.22 13:29, Klaus Ethgen wrote:


I also have a nagios bacula monitor running every 5 minutes.
(/usr/lib/nagios/plugins/check_bacula) But this seems to stay green all
the time.


The log entries you see might be just from that check and not from the 
running backup, just intermingled within the logs.


The "JobId: 0" makes me think this is the case.

Can you disable the Nagios check to see if this changes anything?

Grüße,
Sven.

Bug#798462: libsasl2-2: recreate and use /etc/sasl2/ for new installations

[Bastian Germann]

Control: tags -1 wontfix

Your assumption seems that only the /usr/lib/sasl2 directory is taken into 
account.
However, the programs read also /etc/sasl2 because configdir contains both.

I do not think it is a good idea to introduce this script trickery to let them point to the same 
actual directory. What is wrong with having two differnt places to store config files?

Linking from /usr/... to /etc/ and vice versa is a very bad idea.

Bug#1009231: Write errors since upgrade to 9.6.7-4

[Klaus Ethgen]

Hi Sven,

Am Fr den 15. Apr 2022 um 10:52 schrieb Sven Hartge:
> > Since upgrade from 9.6.7-3 to 9.6.7-4 I get many of the following errors
> > in the log. However, the backup seems to work.
> > 
> > JobId 0: Security Alert: bsock.c:380 Write error sending 4 bytes to 
> > client:127.0.0.1:57050: ERR=Broken pipe
> > JobId 0: Security Alert: bsock.c:380 Write error sending 4 bytes to 
> > client:127.0.0.1:57074: ERR=Broken pipe
> > ...
> > JobId 0: Security Alert: bsock.c:380 Write error sending 4 bytes to 
> > client:127.0.0.1:57134: ERR=Connection reset by peer
> > JobId 0: Security Alert: bsock.c:380 Write error sending 4 bytes to 
> > client:127.0.0.1:57126: ERR=Connection reset by peer
> > ...
> 
> Hello Klaus,
> 
> I have not been able to reproduce this nor am I seeing this on any of my
> systems.
> 
> Please check that the version of bacula-sd matches the one from
> bacula-director and that bacula-fd is of no higher version than the Director
> and the SD.

That is the case:
   ~> dpkg -l bacula\*
   Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
   | Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
   |/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: 
GROSS=schlecht)
   ||/ Name Version  Architektur  Beschreibung
   
+++----==
   ii  bacula-bscan 9.6.7-4  amd64network backup 
service - bscan tool
   ii  bacula-common9.6.7-4  amd64network backup 
service - common support files
   ii  bacula-common-sqlite39.6.7-4  amd64network backup 
service - SQLite v3 common files
   ii  bacula-console   9.6.7-4  amd64network backup 
service - text console
   ii  bacula-console-qt9.6.7-4  amd64network backup 
service - Bacula Administration Tool
   ii  bacula-director  9.6.7-4  amd64network backup 
service - Director daemon
   ii  bacula-director-sqlite3  9.6.7-4  all  network backup 
service - SQLite 3 storage for Director
   ii  bacula-doc   9.6.7-1  all  Documentation for 
Bacula
   ii  bacula-fd9.6.7-4  amd64network backup 
service - file daemon
   ii  bacula-sd9.6.7-4  amd64network backup 
service - storage daemon

Funny fact: I also have systems with version 9.4.2 FD doing the backup
to this system and they do not trigger my problem over the network. Only
the localhost connections from the very same system does.

> Also seeing "Connection reset by peer" while connecting via localhost is
> very suspicious, IMHO. Is the FD dying during the backup?

I thought the same.

And no, the fd is not dying and the backup is completed without other
troubles.

But maybe I have some hints. About a half a year ago I added a host
living in untrusted network, so I changed the configuration to be mixed
clear communication over trusted network and encrypted for the rest.
Therefor, I have the following in director config:

   Client xxx
   {
  ...
  TLS Enable = yes
  TLS Require = yes
  TLS CA Certificate File = /etc/ssl/private/bacula-ca.pem
  TLS Certificate = /etc/ssl/private/bacula-dir.cert
  TLS Key = /etc/ssl/private/bacula-dir.key
   }

All other TLS settings are off.

I also have a nagios bacula monitor running every 5 minutes.
(/usr/lib/nagios/plugins/check_bacula) But this seems to stay green all
the time.

> What do you system logs and dmesg show during the exact time this happens?
> 
> > ii  init-system-helpers  1.62devuan1
> 
> This looks like a mixed Debian/Devuan system. Can you make sure to reproduce
> the bug in a clean Debian system, to rule out anything being affected by
> changes made for Devuan.

No, I completely migrated to devuan some years ago due to the
systemd-debakel. I do not have any debian system left.

Gruß
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#985105: kexec-tools: CVE-2021-20269

[Salvatore Bonaccorso]

Hi Khalid,

On Thu, Apr 14, 2022 at 01:32:38PM -0600, Khalid Aziz wrote:
> On 3/12/21 13:40, Salvatore Bonaccorso wrote:
> > Source: kexec-tools
> > Version: 1:2.0.20-2.1
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for kexec-tools.
> > 
> > CVE-2021-20269[0]:
> > | incorrect permissions on kdump dmesg file
> > 
> > Could you check the details here? [2] is slight short on information
> > if "known upstream" etc.
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2021-20269
> >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20269
> > [1] https://www.openwall.com/lists/oss-security/2021/03/11/2
> > 
> > Please adjust the affected versions in the BTS as needed.
> > 
> As I explained in my previous update to this bug, this security issue does
> not apply to debian package. This security issue was introduced by the
> scripts added in Fedora/Redhat packages. I will close this bug now.

Indeed, and thanks. The fix indeed which is applied to Fedora is
https://src.fedoraproject.org/rpms/kexec-tools/c/91c802ff526a0aa0618f6d5c282a9b9b8e41bff8
which is then Fedora/Red Hat specific.

Regards,
Salvatore

Bug#1009313: RFS: nginx/1.18.0-10 -- small, powerful, scalable web/proxy server

[Bastian Germann]

On Tue, 12 Apr 2022 10:18:55 +0200 Bastian Germann  wrote:
When the team is not responding, please work with Filip Chabik who uploaded a 1.20.2-1+nmu1 a while 
a go, which should really be a 1.20.2-0.1


Thomas Ward showed up and took responsibility. I do not think that you should 
invest time in this.

Bug#1009723: RFS: opencpn/5.6.0+dfsg0-1~bpo10+2 -- Open Source Chartplotter and Marine GPS Navigation Software

[Alec Leamas]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opencpn
   Version : 5.6.0+dfsg0-1~bpo10+2
   Upstream Author : Dave S. Register 
 * URL : https://opencpn.org
 * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, 
GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0

 * Vcs : https://gitlab.com/leamas/opencpn
   Section : misc

The source builds the two binary packages:

  opencpn - Open Source Chartplotter and Marine GPS Navigation Software
  opencpn-data - Open Source Chartplotter and Marine GPS Navigation 
Software (data)


More info on  https://mentors.debian.net/package/opencpn/ or using:

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.0+dfsg0-1~bpo10+2.dsc


This is a bugfix update of an existing sloppy backport. Changes since 
the last upload:


 opencpn (5.6.0+dfsg0-1~bpo10+2) buster-backports-sloppy; urgency=medium
 .
   * Link to gtk2 instead of gtk3 to match available plugins.
 Closes: #1009701
   * Add upstream patches to make it possible to define the target as
 a compile time constant.
   * Add patch to avoid getting multiple possible plugins to
 load besides the Debian version.

Regards,
--
  Alec Leamas

Bug#972678: initramfs-tools: bad error message when zstd requested but not installed

[Diederik de Haas]

On vrijdag 15 april 2022 12:58:21 CEST 積丹尼 Dan Jacobson wrote:
> update-initramfs: Generating /boot/initrd.img-5.16.0-6-amd64
> W: No zstd in /usr/bin:/sbin:/bin, using gzip

That's a different and actually correct message.
The bug is/was about an incorrect message.
 
> Shouldn't it just not remind the user?

That's a choice.
Using zstd has benefits and is (IIUC) now the default, so a warning (or an 
information) message seems useful (as long as it is correct).
It did notify me that I previously installed the 'wrong' zstd (related) 
package, so I could fix it.

If you feel that's the wrong choice, then I guess you could file a wishlist/
minor bug about that.

AFAIC this bug was fixed and appropriately closed before, but I'll leave it up 
to the maintainer to close it again.

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

Bug#1009721: gst-plugins-bad1.0 build-depends on obsolete package.

[peter green]

Package: gst-plugins-bad1.0
Version: 1.20.1-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"

gst-plugins-bad1.0 build-depends on libwpewebkit-1.0-dev which is no longer
built by the wpewebkit source package. It is still present in unstable as a
cruft package but is completely gone from testing.

Bug#1009720: nsight-compute: Add NVreg_RestrictProfilingToAdminUsers=0 by default?

[Christian Kastner]

Package: nsight-compute
Version: 2021.2.2.1~11.4.3-2
Severity: wishlist

By default, the nvidia kernel module is loaded such that profiling is
restricted to privileged users. The rationale for this in [1] was about
a local information disclosure.

However, one could argue that on systems where nsight-compute is
installed in the first place, regular developers would want to make use
of it. To this end, loading the module with

  option nvidia NVreg_RestrictProfilingToAdminUsers=0

Would do this by default.

Is this something you might consider worthwhile to add somewhere to the
nsight-compute package?

Please feel free to simply close the bug if you don't; I'd fully understand.

[1] 
https://developer.nvidia.com/nvidia-development-tools-solutions-err_nvgpuctrperm-permission-issue-performance-counters

Bug#972678: initramfs-tools: bad error message when zstd requested but not installed

[積丹尼 Dan Jacobson]

update-initramfs: Generating /boot/initrd.img-5.16.0-6-amd64
W: No zstd in /usr/bin:/sbin:/bin, using gzip

Shouldn't it just not remind the user?

Bug#1009719: ncu hard fail on stable, workaround available on bullseye+sid

[Christian Kastner]

Package: nsight-compute
Version: 2020.3.1.4~11.2.2-3+deb11u1
Severity: important

nvprof has been deprecated, and Nvidia recommends to switch to
nsight-compute and nsight-systems. This is necessary for Ampere cards,
because nvprof expressly does not support them.

However, ncu (from nsight-compute) does not work on bullseye and newer,
with a user-configurable workaround on bookworm and above.

The issue seems to be the location of the "sections" folder: the ncu
binary expects it at:

  /usr/lib/nsight-compute//sections

whereas it is installed in:

  /usr/lib/nsight-compute/sections

Adding a symlink from /usr/lib/nsight-compute//sections to the
actual install location fixes the issue.


Steps to reproduce
==

Given the attached typical example for a CUDA program and compiling it with,

  $ nvcc -o MatAdd MatAdd.cu

using ncu (as root, to avoid ERR_NVGPUCTRPERM)  on bullseye produces the
following warning:

  # ncu MatAdd
  ==ERROR== Could not deploy stock section files to 
"/home/username/Documents/NVIDIA Nsight Compute/2020.3.1/Sections".

This error is misleading, as it has nothing to do with creating the
mentioned directory.


There's an option --section-folder which can be used to specify the
location of that folder. Oddly, this is ineffective on bullseye,

  # ncu --section-folder /usr/lib/nsight-compute/sections MatAdd
  ==ERROR== Could not deploy stock section files to 
"/home/username/Documents/NVIDIA Nsight Compute/2020.3.1/Sections".

but it does work on bookworm and above, where nsight-compute is 
newer (carets are mine):

  # ncu --section-folder /usr/lib/nsight-compute/sections MatAdd
  ==WARNING== Could not deploy stock section files to 
"/home/username/Documents/NVIDIA Nsight Compute/2021.2.2/Sections".
  ==WARNING== Using 
"/usr/lib/x86_64-linux-gnu/nsight-compute/target/linux-desktop-glibc_2_11_3-x64/../../sections"
 instead.
 ^^ 
   ^^^
  ==WARNING== See 
https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html#faq.
  ==PROF== Connected to process 5861 (/home/username/MatAdd)
  ==PROF== Profiling "MatAdd" - 1: 0%50%100% - 8 passes
  ==PROF== Disconnected from process 5861


The warning in the bookworm version already points to the issue
mentioned above: "sections" is expected in the path including the
.

Adding a symlink fixes the issue on all systems, and also gets
rid of all errors/warnings:

  # ln -s /usr/lib/nsight-compute/sections 
/usr/lib/x86_64-linux-gnu/nsight-compute/sections
  # ncu MatAdd
  ==PROF== Connected to process 7292 (/home/username/MatAdd)
  ==PROF== Profiling "MatAdd" - 1: 0%50%100% - 8 passes
  ==PROF== Disconnected from process 7292
  ...

MatAdd.cu
Description: application/cu-seeme

Bug#1009682: ghostscript breaks openscad autopkgtest

[Kristian Nielsen]

Control: reassign

Thanks for the report, I will upload shortly a fixed openscad package.

 - Kristian.

Paul Gevers  writes:

> With a recent upload of ghostscript the autopkgtest of openscad fails
> in testing when that autopkgtest is run with the binary packages of 
> ghostscript from unstable. It passes when run with only packages from

Bug#972678: initramfs-tools: bad error message when zstd requested but not installed

[Diederik de Haas]

On vrijdag 15 april 2022 03:12:04 CEST Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > found 972678 0.141
> 
> Please contact me if you need assistance.

Can you specify the error message that you got? Even saying you got the exact 
same message as in OP is helpful.

I don't recall the exact message, but I got alerted that 'zstd' wasn't 
installed and therefor not used. So subsequently I installed it.

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

Bug#1009181: File suffix for message mbox links should be .eml

[Max Nikulin]

On 10/04/2022 03:54, Don Armstrong wrote:


The only real difference between a single message in an mbox and a
complete mbox is From escaping.


I had an impression that MUA may decode messages from 7-bit transfer 
encoding including quoted-printable and base64 fragments in headers 
before saving .eml files. I rarely use .eml files, so I may be wrong, 
and I do ask for such transformation from debbugs.



Frankly, using the extension to determine mime time is bad practice, but
it's a common bad practice.


In this particular case even libmagick is not a rescue, both 
application/mbox and message/rfc866 are detected as text/plain. Though 
my opinion is that thunderbird should have some option to make intention 
clear.

Bug#1009231: Write errors since upgrade to 9.6.7-4

[Sven Hartge]

On 09.04.22 12:12, Klaus Ethgen wrote:


Since upgrade from 9.6.7-3 to 9.6.7-4 I get many of the following errors
in the log. However, the backup seems to work.

JobId 0: Security Alert: bsock.c:380 Write error sending 4 bytes to 
client:127.0.0.1:57050: ERR=Broken pipe
JobId 0: Security Alert: bsock.c:380 Write error sending 4 bytes to 
client:127.0.0.1:57074: ERR=Broken pipe
...
JobId 0: Security Alert: bsock.c:380 Write error sending 4 bytes to 
client:127.0.0.1:57134: ERR=Connection reset by peer
JobId 0: Security Alert: bsock.c:380 Write error sending 4 bytes to 
client:127.0.0.1:57126: ERR=Connection reset by peer
...


Hello Klaus,

I have not been able to reproduce this nor am I seeing this on any of my 
systems.


Please check that the version of bacula-sd matches the one from 
bacula-director and that bacula-fd is of no higher version than the 
Director and the SD.


Also seeing "Connection reset by peer" while connecting via localhost is 
very suspicious, IMHO. Is the FD dying during the backup?


What do you system logs and dmesg show during the exact time this happens?


ii  init-system-helpers  1.62devuan1


This looks like a mixed Debian/Devuan system. Can you make sure to 
reproduce the bug in a clean Debian system, to rule out anything being 
affected by changes made for Devuan.


Grüße,
Sven.

Bug#1009012: [pkg-bacula-devel] Bug#1009012: bacula FTCBFS: uses the build architecture qmake

[Sven Hartge]

On 05.04.22 13:20, Helmut Grohne wrote:

Hello Helmut,

thank you for your time to not only diagnose the problem but also 
provide a solution.



bacula fails to cross build from source, because it attempts to use the
build architecture qmake while Build-Depends requested the host
architecture one. To make matters worse, this is only visible much later
in the build as the qmake failure is swallowed. Such behaviour arguably
runs afoul Debian policy section 4.6 and should likely be considered a
serious policy violation.

In any case, bacula's configure.ac uses AC_PATH_PROG to locate qmake.
Once changing that to AC_PATH_TOOL, the host architecture qmake is being
used and this part magically works. This is what this bug is about. I'm
attaching a patch for your convenience.


As you can see from the GIT repo, I have committed your fix and also 
verified it builds correctly.


But unfortunately, I am not that knowledgable about anything autotools, 
so I am at a bit of a loss about how the fix the "as the qmake failure 
is swallowed" bit. Sorry.


I will submit the change to the upstream BTS, unless you already beat me 
to it.



Beyond this, bacula uses mysql_config to discover mysql client
libraries. Cross building with mysql_config is not something we can fix.
If bacula is to support cross building, it will need to use pkg-config
(or pkgconf) instead. The relevant code is quite non-trivial and I
couldn't come up with a working version. Would you be interested in
looking into this? The following link describes a way that is
automatically compatible with cross building. The module name is
"mysqlclient". https://autotools.info/pkgconfig/pkg_check_modules.html


I tried to have a go at it, but got utterly defeated by a) my lacking 
knowledge of autotools in general and b) the convoluted mess that 
anything autotools related is to me.


I will need to defer this to someone with more insight or upstream.

Grüße,
Sven.

Bug#996464: ITP: atomic-data-rust -- graph database server to share Atomic Data on the web

[Jonas Smedegaard]

Needs embedding 209 crates; Builds in ~35 minutes; Runs but needs to 
point to external web assets until packaged

Upstream source is now repackaged to exclude embedded precompiled web 
assets.  Until these are built, a workaround (untested, but similar to 
how it was earlier done upstream as well) is to set this:

ATOMIC_ASSET_URL=https://joepio.github.io/atomic-data-browser

You can help by testing this draft package (either build it yourself or 
tell if you want me to provide you a binary package) and provide 
feedback on how well it works in your desktop environment.

You can also help by joining the Rust team in Debian and contribute to 
unbreaking, upgrading and adding crate packages, as listed here: 
https://salsa.debian.org/debian/atomic-data-rust/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#997811: unbound crashes, remote dos?

[Stephane Tranchemer]

So, I took the source from Unbound main site for version 1.15 and made a 
package out of it using the deb-source.


Guess what, it is now running for a week and we didn't see a single crash.

Just my 2 cents but I think that Debian maintainers should consider 
going for better than 1.13 now.

Bug#1009718: ndisc6: package description mentions `addrinfo` but not `addr2name` nor `name2addr`

[Yvan Masson]

Package: ndisc6
Version: 1.0.5-1
Severity: minor

Dear maintainer,

Package description of ndisc6 mentions the included command `addrinfo`, 
which I can not find in the package contents. I did not have time to 
look further, but maybe it was replaced by the included `addr2name` and 
`name2addr`?


Regards,
Yvan


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009717: hachoir: [hachoir-metadata] Wrong track duration

[Nicolas Patrois]

Package: hachoir
Version: 3.1.0+dfsg-3
Severity: normal
Tags: upstream

Dear Maintainer,

hachoir-metadata returns wrong tracks durations, for example, a track whose
real duration is 3 min 25 sec 63 ms is told running 14 min 2 sec 898 ms.


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

Kernel: Linux 5.16.0-6-686-pae (SMP w/3 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hachoir depends on:
ii  python3   3.10.4-1
ii  python3-urwid 2.1.2-2+b1
ii  python3-wxgtk4.0  4.0.7+dfsg-13

hachoir recommends no packages.

hachoir suggests no packages.

-- no debconf information

Bug#699914: python3-serial: TCP mode: data loss, timeout handling broken

[Bastian Germann]

Control: tags -1 patch

This should be resolved by https://github.com/pyserial/pyserial/pull/382

Bug#1007905: transition: icu

[Rene Engelhard]

Hi,

Am 15.04.22 um 08:57 schrieb László Böszörményi (GCS):

On Fri, Apr 15, 2022 at 8:48 AM Rene Engelhard  wrote:

Am 13.04.22 um 17:52 schrieb Rene Engelhard:

Am 13.04.22 um 17:24 schrieb László Böszörményi (GCS):

LibreOffice self-testing, especially its break iterator test fails for
the Lao language.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=263961306ede0656ebb7904034a2172615ce81d0

Nevermind, that one is already there.

But it fails because it does != 70 and 71 still is affected.

So we just need to extend it. Submitted it uptream in
https://gerrit.libreoffice.org/c/core/+/133063/1/i18npool/qa/cppunit/test_breakiterator.cxx
and will backport it to the 7.3.3 packages.

  Your patch has a glitch. The U_ICU_VERSION_MAJOR_NUM check must be
strictly lower than 70 for word boundary equal to nine. If it's ICU
version 70 or higher, the else case should be hit. Ie:
#if (U_ICU_VERSION_MAJOR_NUM < 70)
is the correct check IMHO.


Ah, right, not enough coffee yet obviously. :)


Thanks for pointing this out.


Regards,


Rene

Bug#1007905: transition: icu

[GCS]

On Fri, Apr 15, 2022 at 8:48 AM Rene Engelhard  wrote:
> Am 13.04.22 um 17:52 schrieb Rene Engelhard:
> > Am 13.04.22 um 17:24 schrieb László Böszörményi (GCS):
> >> LibreOffice self-testing, especially its break iterator test fails for
> >> the Lao language.
> >
> > https://cgit.freedesktop.org/libreoffice/core/commit/?id=263961306ede0656ebb7904034a2172615ce81d0
>
> Nevermind, that one is already there.
>
> But it fails because it does != 70 and 71 still is affected.
>
> So we just need to extend it. Submitted it uptream in
> https://gerrit.libreoffice.org/c/core/+/133063/1/i18npool/qa/cppunit/test_breakiterator.cxx
> and will backport it to the 7.3.3 packages.
 Your patch has a glitch. The U_ICU_VERSION_MAJOR_NUM check must be
strictly lower than 70 for word boundary equal to nine. If it's ICU
version 70 or higher, the else case should be hit. Ie:
#if (U_ICU_VERSION_MAJOR_NUM < 70)
is the correct check IMHO.

Regards,
Laszlo/GCS

Bug#1009716: libreoffice: FTBFS with icu >= 71; testLao fails again

[Rene Engelhard]

Package: src:libreoffice
Version: 1:7.3.2~rc2-1
Severity: important
Control: submitter -1 László Böszörményi (GCS) 
Control: blocks -1 1007905

Making a bug report out of this.

 Weitergeleitete Nachricht 
Betreff: Re: Bug#1007905: transition: icu
Datum: Wed, 13 Apr 2022 17:52:05 +0200
Von: Rene Engelhard 
Organisation: Debian Project
An: László Böszörményi (GCS) , 1007...@bugs.debian.org, 
Jeremy Bicha 
Kopie (CC): Adrian Bunk , Sebastian Ramacher 
, Jérémy Lal , 
debian-gtk-gn...@lists.debian.org, Simon McVittie 


Hi,

Am 13.04.22 um 17:24 schrieb László Böszörményi (GCS):

LibreOffice self-testing, especially its break iterator test fails for
the Lao language.

[...]

Bug#1007905: transition: icu

[Rene Engelhard]

Hi again,

Am 13.04.22 um 17:52 schrieb Rene Engelhard:

Am 13.04.22 um 17:24 schrieb László Böszörményi (GCS):

LibreOffice self-testing, especially its break iterator test fails for
the Lao language.


https://cgit.freedesktop.org/libreoffice/core/commit/?id=263961306ede0656ebb7904034a2172615ce81d0 


Nevermind, that one is already there.

But it fails because it does != 70 and 71 still is affected.

So we just need to extend it. Submitted it uptream in
https://gerrit.libreoffice.org/c/core/+/133063/1/i18npool/qa/cppunit/test_breakiterator.cxx
and will backport it to the 7.3.3 packages.

Regards,


Rene

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Gunnar Wolf]

Thanks for drafting this, Matthew!

I have a small suggestion here:

Matthew Vernon dijo [Thu, Apr 14, 2022 at 04:47:17PM +0100]:
> Backwards-compatibility (and the lack of a compelling argument that
> util-linux's rename is significantly superior to the perl rename) means that
> /usr/bin/rename in Debian should remain the perl rename.

I'd prefer to read "that neither 'rename' implementation is superior
to the other", maybe even explaining that "they were designed out of
different needs and meet different criteria".

> The Technical Committee resolves that util-linux's rename should be shipped
> in a binary package build from src:util-linux. If this package Conflicts
 ^built

> Matthew
> ps; my first TC resolution, please be gentle if I have the procedure wrong!

Thanks again!

Bug#1009715: ITP: golang-github-leonelquinteros-gotext -- Go (Golang) GNU gettext utilities package

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-leonelquinteros-gotext
  Version : 1.5.0-1
  Upstream Author : Leonel Quinteros
* URL : https://github.com/leonelquinteros/gotext
* License : Expat
  Programming Lang: Go
  Description : Go (Golang) GNU gettext utilities package

 GNU gettext utilities (https://www.gnu.org/software/gettext) for Go.
 .
 Features
 .
  * Implements GNU gettext support in native Go.
  * Complete support for PO files 
(https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html) including:
* Support for multiline strings and headers.
* Support for variables inside translation strings using Go's fmt 
syntax (https://golang.org/pkg/fmt/).
* Support for pluralization rules

(https://www.gnu.org/software/gettext/manual/html_node/Translating-plural-forms.html).
* Support for message contexts 
(https://www.gnu.org/software/gettext/manual/html_node/Contexts.html).
  * Support for MO files.
  * Thread-safe: This package is safe for concurrent use across multiple 
goroutines.
  * It works with UTF-8 encoding as it's the default for Go language.
  * Unit tests available.
  * Language codes are automatically simplified from the form en_UK to en if 
the first isn't available.
  * Ready to use inside Go templates.
  * Objects are serializable to []byte to store them in cache.
  * Support for Go Modules.

This is a dependency of git-lfs and will be maintained by the go packaging
team.