Bug#1009302: linux-image-5.17.0-trunk-amd64: Missing CONFIG_X86_AMD_PSTATE=m module

[Tobias Köck]

Sounds great. Thanks. :)

On 4/11/22 11:07, Vincent Blut wrote:

Control: tags -1 pending

Hi,

Le 2022-04-11 10:52, Tobias Koeck a écrit :

Package: src:linux
Version: 5.17.1-1~exp1
Severity: important

Dear Maintainer,

the

CONFIG_X86_AMD_PSTATE

module is not set.

https://www.phoronix.com/scan.php?page=news_item=AMD-P-State-How-To

Can you add it to the kernel so that it is possible to use AMD's power
management?


This is pending.

https://salsa.debian.org/kernel-team/linux/-/commit/2ee8b17f8d9cf15a02bf373b7eca5bade354abaf


Greetings and thanks,
Tobias


Cheers,
Vincent

Bug#1003095: /usr/bin/script: hangs when child doesn't read input fast enough

[Karel Zak]

On Fri, Jan 14, 2022 at 12:28:11AM +0100, наб wrote:
> -static int write_to_child(struct ul_pty *pty, char *buf, size_t bufsz)
> +static int schedule_child_write(struct ul_pty *pty, char *buf, size_t bufsz, 
> int final)
>  {
> - return write_all(pty->master, buf, bufsz);
> + struct ul_pty_child_buffer *stash = calloc(1, sizeof(*stash));

It means that for each activity on the file descriptor it will
allocate a new buffer (in BUFSIZ). It seems pretty expensive.

Cannot we reuse the buffers? 

Maybe use include/list.h, define two lists, one for not-yet-written 
buffers and another for ready-to-use buffers and move from one list to
another in schedule_child_write() and flush_child_buffers().

> + if (!stash)
> + return -1;
> +
> + memcpy(stash->buf, buf, bufsz);
> + stash->size = bufsz;
> + stash->final_input = final ? 1 : 0;
> +
> + if (pty->child_buffer_head)
> + pty->child_buffer_tail = pty->child_buffer_tail->next = stash;
> + else
> + pty->child_buffer_head = pty->child_buffer_tail = stash;
> + return 0;
>  }
>  
>  /*
> @@ -311,16 +329,13 @@ static int write_to_child(struct ul_pty
>   * maintains master+slave tty stuff within the session. Use pipe to write to
>   * pty and assume non-interactive (tee-like) behavior is NOT well supported.
>   */
> -void ul_pty_write_eof_to_child(struct ul_pty *pty)
> +static void drain(struct ul_pty *pty)

drain_child_buffers() :-)


Anyway, it looks good.

Karel



-- 
 Karel Zak  
 http://karelzak.blogspot.com

Bug#1009306: ppp: NMU 2.4.9-1+1.1

[Bastian Germann]

Source: ppp
Version: 2.4.9-1+1.1

As preparation for #1006705 and according to the LowNMU, I am uploading a NMU 
for ppp.
Please find the debdiff attached.diff -Nru ppp-2.4.9/debian/changelog ppp-2.4.9/debian/changelog
--- ppp-2.4.9/debian/changelog  2021-01-07 01:10:29.0 +0100
+++ ppp-2.4.9/debian/changelog  2022-04-11 11:11:33.0 +0200
@@ -1,3 +1,19 @@
+ppp (2.4.9-1+1.1) unstable; urgency=high
+
+  * Non-maintainer upload
+
+  [ Paul Wise ]
+  * Compile for host architecture (Closes: #990021)
+
+  [ Till Kamppeter ]
+  * Let usepeerdns exit when NetworkManager is in use (LP: #1778946)
+
+  [ Eivind Næss ]
+  * d/p/eap-mschap-v2-namelen.patch: fix the length of the username when
+responding to an EAP MSCHAPv2 challenge (LP: #1958196)
+
+ -- Bastian Germann   Mon, 11 Apr 2022 11:11:33 +0200
+
 ppp (2.4.9-1+1) unstable; urgency=medium
 
   [ Samuel Thibault ]
diff -Nru ppp-2.4.9/debian/extra/ip-up.d/usepeerdns 
ppp-2.4.9/debian/extra/ip-up.d/usepeerdns
--- ppp-2.4.9/debian/extra/ip-up.d/usepeerdns   2021-01-07 
01:10:29.0 +0100
+++ ppp-2.4.9/debian/extra/ip-up.d/usepeerdns   2022-04-11 
10:28:56.0 +0200
@@ -11,6 +11,13 @@
   systemctl is-active --quiet systemd-resolved.service &&
   exit 0
 
+case "$6" in
+  nm-*-service-*|/org/freedesktop/NetworkManager/PPP/*)
+# NetworkManager handles it
+exit 0
+;;
+esac
+
 # create the file if it does not exist
 if [ ! -e /etc/resolv.conf ]; then
   : > /etc/resolv.conf
diff -Nru ppp-2.4.9/debian/.gitignore ppp-2.4.9/debian/.gitignore
--- ppp-2.4.9/debian/.gitignore 2021-01-07 01:10:29.0 +0100
+++ ppp-2.4.9/debian/.gitignore 1970-01-01 01:00:00.0 +0100
@@ -1,15 +0,0 @@
-/.debhelper/
-/ppp/
-/ppp-dev/
-/ppp-udeb/
-/tmp-ppp/
-/tmp-udeb/
-
-/changelog-from-README
-/debhelper-build-stamp
-/extra/dh_ppp.1p
-/files
-
-*.debhelper
-*.debhelper.log
-*.substvars
diff -Nru ppp-2.4.9/debian/patches/eap-mschap-v2-namelen.patch 
ppp-2.4.9/debian/patches/eap-mschap-v2-namelen.patch
--- ppp-2.4.9/debian/patches/eap-mschap-v2-namelen.patch1970-01-01 
01:00:00.0 +0100
+++ ppp-2.4.9/debian/patches/eap-mschap-v2-namelen.patch2022-04-11 
10:54:12.0 +0200
@@ -0,0 +1,22 @@
+Description: This fixes the length of the username when responding to an EAP
+ MSCHAPv2 challenge.
+ .
+ [rbasak]
+ Also see the discussion in the MP:
+ https://code.launchpad.net/~eivnaes/ubuntu/+source/ppp/+git/ppp/+merge/415397
+Author: Eivind Næss 
+Acked-By: Robie Basak 
+Origin: upstream, 
https://github.com/ppp-project/ppp/commit/d7e62a8499c4032d79e05afbd8fd3efd51c5b148
+Bug-Ubuntu: https://launchpad.net/bugs/1958196
+Last-Update: 2022-02-24
+
+--- a/pppd/eap.c
 b/pppd/eap.c
+@@ -2261,6 +2261,7 @@
+   eap_send_nak(esp, id, EAPT_SRP);
+   break;
+   }
++  esp->es_client.ea_namelen = strlen(esp->es_client.ea_name);
+ 
+   /* Create the MSCHAPv2 response (and add to cache) */
+   unsigned char response[MS_CHAP2_RESPONSE_LEN+1]; // VLEN + VALUE
diff -Nru ppp-2.4.9/debian/patches/series ppp-2.4.9/debian/patches/series
--- ppp-2.4.9/debian/patches/series 2021-01-07 01:10:29.0 +0100
+++ ppp-2.4.9/debian/patches/series 2022-04-11 10:55:48.0 +0200
@@ -15,3 +15,6 @@
 zzz_config
 pppd-soname-hack.patch
 replace-vendored-hash-functions.patch
+
+# upstream backports
+eap-mschap-v2-namelen.patch
diff -Nru ppp-2.4.9/debian/rules ppp-2.4.9/debian/rules
--- ppp-2.4.9/debian/rules  2021-01-07 01:10:29.0 +0100
+++ ppp-2.4.9/debian/rules  2022-04-11 10:24:10.0 +0200
@@ -60,7 +60,7 @@
[ ! -f Makefile ] || $(MAKE) dist-clean
 
 override_dh_auto_configure:
-   ./configure --prefix=/usr
+   ./configure --prefix=/usr --cc=gcc 
--cross_compile="$(DEB_HOST_GNU_TYPE)-"
if [ ! -d pppd-udeb/ ]; then \
mkdir pppd-udeb/ && \
cp -ldpR pppd/* pppd-udeb/; \

Bug#1009241: sagemath: autokgtest regression on armhf

[Sebastian Ramacher]

Hi

On 2022-04-11 09:03:03, Tobias Hansen wrote:
> Hi,
> 
> this is not a regression, as the armhf and mips64el tests never passed, see 
> #1004872 and #920147. There was a bug in the package that caused the tests 
> not to be run when building with python 3.10, so the armhf and mips64el 
> package builds succeeded. The packages for these architectures should be 
> removed from testing. I fixed this in sagemath 9.5-3.

For britney it's a regression. There was no autopkgtest failure for
armhf in testing, but now there is one in unstable. In that case the
package won't qualify for migration.

If the package should not be built on armhf: please remove the
architecture from the package's Architecture field and then request
removal from unstable via a bug ftp.debian.org.

Cheers

> 
> Best,
> Tobias
> 
> On 4/9/22 16:56, Sebastian Ramacher wrote:
> > Source: sagemath
> > Version: 9.5-2
> > Severity: serious
> > X-Debbugs-Cc: sramac...@debian.org
> >
> > sagemath's autopkgtests fail on armhf:

-- 
Sebastian Ramacher

Bug#1009305: zutils: Missing package relation with zstd

[Axel Beckert]

Package: zutils
Version: 1.11-1
Version: 1.11-3
Severity: serious

Hi,

zutils version 1.11 added zstd support:

  2022-01-25  Antonio Diaz Diaz  

* Version 1.11 released.
[…]
* Add support for zstd format to all tools.
[…]

And Debian's zutils package seems to have zstd support:

  ~ → dfgrep zstd zutils
  grep: /bin/zcat: binary file matches
  grep: /bin/zcmp: binary file matches
  grep: /bin/zdiff: binary file matches
  grep: /bin/zgrep: binary file matches
  grep: /bin/ztest: binary file matches
  grep: /bin/zupdate: binary file matches
  /etc/zutilsrc:# zst = zstd -T2
  /usr/share/doc/zutils/README:The formats supported are bzip2, gzip, lzip, xz, 
and zstd.

But the packaging (citing from zutils/1.11-3) does not reflect this:

  Depends: libc6 (>= 2.33), libgcc-s1 (>= 3.0), libstdc++6 (>= 5.2)
  Recommends: bzip2, lzip, xz-utils
  […]
  Description: utilities for dealing with compressed files transparently
   Zutils is a collection of utilities for dealing with any combination of
   compressed and non-compressed files transparently. Currently the supported
   compressors are gzip, bzip2, lzip, and xz.

The package needs zstd to be added to Recommends as zstd is only of
priority "optional" as of now.

Additionally the long package description should be updated to list zstd
as well.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages zutils depends on:
ii  libc6   2.33-7
ii  libgcc-s1   12-20220319-1
ii  libstdc++6  12-20220319-1

Versions of packages zutils recommends:
ii  bzip2 1.0.8-5
ii  lzip  1.23-3
ii  xz-utils  5.2.5-2.1

zutils suggests no packages.

-- no debconf information

Bug#996965: bslib and rmarkdown update

[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

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
> > > Latohttps://packages.debian.org/sid/fonts-lato
> > > Cabin Sketchhttps://packages.debian.org/sid/fonts-cabinsketch
> > > Montserrat, Nunito, Raleway, Source Sans Pro: texlive-fonts-extra
> > >
> > > This leaves 4 which I could not find in Debian:
> > >
> > > Nunito Sans https://github.com/googlefonts/NunitoSans
> > > Inter   https://github.com/rsms/inter/
> > > News Cycle  https://bazaar.launchpad.net/~n8/newscycle/
> > > Neucha  ?
> >
> > Thanks a lot for this very helpful investigation.  The problem now is
> > how to know which of the 60 inst/fonts/*.woff files we can remove from
> > the source package since these are not needed and whether the fonts
> > you said are found by bslib if we simply set the dependencies you
> > mentioned above (and how to test this).  The names of these *.woff
> > files are absolutely cryptic and I need to admit I have no idea about
> > all this fonts stuff.
> >
> > Kind regards
> >
> >   Andreas.
> >
> > > Best,
> > > Eric
> > >
> > > On Sun, Apr 3, 2022 at 14:34 Eric Brown  wrote:
> > >
> > > > Hi,
> > > >
> > > > Since this is a pretty important package, I grep'd the package to see
> > > > what fonts are included. It looks like some of them are already 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
> > > >
> > > > The rest are all SIL OFL licence (Debian compatible). I was able to find
> > > > sources for all but two:
> > > >
> > > > Montserrat  https://github.com/JulietaUla/Montserrat
> > > > Nunito Sans https://github.com/googlefonts/NunitoSans
> > > > Nunito  https://github.com/googlefonts/nunito
> > > > Inter   https://github.com/rsms/inter/
> > > > News Cycle  https://bazaar.launchpad.net/~n8/newscycle/
> > > > Raleway https://github.com/impallari/Raleway/
> > > > Neucha  ?
> > > > Source Sans Pro ?
> > > >
> > > > Best,
> > > > Eric
> > > >
> > > --
> > > Eric Brown MD MSc FRCPC
> > > For encryption, OpenPGP public key available on request.
> >
> > --
> > http://fam-tille.de
>
>
>
> --
> Eric Brown MD MSc FRCPC
> For encryption, OpenPGP public key available on request.



-- 
Eric Brown MD MSc FRCPC
For encryption, OpenPGP public key available on request.

Bug#996965: bslib and rmarkdown update

[Andreas Tille]

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
> > > > Latohttps://packages.debian.org/sid/fonts-lato
> > > > Cabin Sketchhttps://packages.debian.org/sid/fonts-cabinsketch
> > > > Montserrat, Nunito, Raleway, Source Sans Pro: texlive-fonts-extra
> > > >
> > > > This leaves 4 which I could not find in Debian:
> > > >
> > > > Nunito Sans https://github.com/googlefonts/NunitoSans
> > > > Inter   https://github.com/rsms/inter/
> > > > News Cycle  https://bazaar.launchpad.net/~n8/newscycle/
> > > > Neucha  ?
> > >
> > > Thanks a lot for this very helpful investigation.  The problem now is
> > > how to know which of the 60 inst/fonts/*.woff files we can remove from
> > > the source package since these are not needed and whether the fonts
> > > you said are found by bslib if we simply set the dependencies you
> > > mentioned above (and how to test this).  The names of these *.woff
> > > files are absolutely cryptic and I need to admit I have no idea about
> > > all this fonts stuff.
> > >
> > > Kind regards
> > >
> > >   Andreas.
> > >
> > > > Best,
> > > > Eric
> > > >
> > > > On Sun, Apr 3, 2022 at 14:34 Eric Brown  wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Since this is a pretty important package, I grep'd the package to see
> > > > > what fonts are included. It looks like some of them are already 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
> > > > >
> > > > > The rest are all SIL OFL licence (Debian compatible). I was able to 
> > > > > find
> > > > > sources for all but two:
> > > > >
> > > > > Montserrat  https://github.com/JulietaUla/Montserrat
> > > > > Nunito Sans https://github.com/googlefonts/NunitoSans
> > > > > Nunito  https://github.com/googlefonts/nunito
> > > > > Inter   https://github.com/rsms/inter/
> > > > > News Cycle  https://bazaar.launchpad.net/~n8/newscycle/
> > > > > Raleway https://github.com/impallari/Raleway/
> > > > > Neucha  ?
> > > > > Source Sans Pro ?
> > > > >
> > > > > Best,
> > > > > Eric
> > > > >
> > > > --
> > > > Eric Brown MD MSc FRCPC
> > > > For encryption, OpenPGP public key available on request.
> > >
> > > --
> > > http://fam-tille.de
> >
> >
> >
> > --
> > Eric Brown MD MSc FRCPC
> > For encryption, OpenPGP public key available on request.
> 
> 
> 
> -- 
> Eric Brown MD MSc FRCPC
> For encryption, OpenPGP public key available on 

Bug#996965: bslib and rmarkdown update

[Andreas Tille]

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
> Latohttps://packages.debian.org/sid/fonts-lato
> Cabin Sketchhttps://packages.debian.org/sid/fonts-cabinsketch
> Montserrat, Nunito, Raleway, Source Sans Pro: texlive-fonts-extra
> 
> This leaves 4 which I could not find in Debian:
> 
> Nunito Sans https://github.com/googlefonts/NunitoSans
> Inter   https://github.com/rsms/inter/
> News Cycle  https://bazaar.launchpad.net/~n8/newscycle/
> Neucha  ?

Thanks a lot for this very helpful investigation.  The problem now is
how to know which of the 60 inst/fonts/*.woff files we can remove from
the source package since these are not needed and whether the fonts
you said are found by bslib if we simply set the dependencies you
mentioned above (and how to test this).  The names of these *.woff
files are absolutely cryptic and I need to admit I have no idea about
all this fonts stuff.

Kind regards

  Andreas.

> Best,
> Eric
> 
> On Sun, Apr 3, 2022 at 14:34 Eric Brown  wrote:
> 
> > Hi,
> >
> > Since this is a pretty important package, I grep'd the package to see
> > what fonts are included. It looks like some of them are already 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
> >
> > The rest are all SIL OFL licence (Debian compatible). I was able to find
> > sources for all but two:
> >
> > Montserrat  https://github.com/JulietaUla/Montserrat
> > Nunito Sans https://github.com/googlefonts/NunitoSans
> > Nunito  https://github.com/googlefonts/nunito
> > Inter   https://github.com/rsms/inter/
> > News Cycle  https://bazaar.launchpad.net/~n8/newscycle/
> > Raleway https://github.com/impallari/Raleway/
> > Neucha  ?
> > Source Sans Pro ?
> >
> > Best,
> > Eric
> >
> -- 
> Eric Brown MD MSc FRCPC
> For encryption, OpenPGP public key available on request.

-- 
http://fam-tille.de

Bug#996965: bslib and rmarkdown update

[Eric Brown]

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
> > Latohttps://packages.debian.org/sid/fonts-lato
> > Cabin Sketchhttps://packages.debian.org/sid/fonts-cabinsketch
> > Montserrat, Nunito, Raleway, Source Sans Pro: texlive-fonts-extra
> >
> > This leaves 4 which I could not find in Debian:
> >
> > Nunito Sans https://github.com/googlefonts/NunitoSans
> > Inter   https://github.com/rsms/inter/
> > News Cycle  https://bazaar.launchpad.net/~n8/newscycle/
> > Neucha  ?
>
> Thanks a lot for this very helpful investigation.  The problem now is
> how to know which of the 60 inst/fonts/*.woff files we can remove from
> the source package since these are not needed and whether the fonts
> you said are found by bslib if we simply set the dependencies you
> mentioned above (and how to test this).  The names of these *.woff
> files are absolutely cryptic and I need to admit I have no idea about
> all this fonts stuff.
>
> Kind regards
>
>   Andreas.
>
> > Best,
> > Eric
> >
> > On Sun, Apr 3, 2022 at 14:34 Eric Brown  wrote:
> >
> > > Hi,
> > >
> > > Since this is a pretty important package, I grep'd the package to see
> > > what fonts are included. It looks like some of them are already 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
> > >
> > > The rest are all SIL OFL licence (Debian compatible). I was able to find
> > > sources for all but two:
> > >
> > > Montserrat  https://github.com/JulietaUla/Montserrat
> > > Nunito Sans https://github.com/googlefonts/NunitoSans
> > > Nunito  https://github.com/googlefonts/nunito
> > > Inter   https://github.com/rsms/inter/
> > > News Cycle  https://bazaar.launchpad.net/~n8/newscycle/
> > > Raleway https://github.com/impallari/Raleway/
> > > Neucha  ?
> > > Source Sans Pro ?
> > >
> > > Best,
> > > Eric
> > >
> > --
> > Eric Brown MD MSc FRCPC
> > For encryption, OpenPGP public key available on request.
>
> --
> http://fam-tille.de



-- 
Eric Brown MD MSc FRCPC
For encryption, OpenPGP public key available on request.

Bug#991566: r-cran-bookdown is so old that it fails to even start

[Andreas Tille]

Control: tags -1 confirmed
Control: block -1 by 996965
 
> I reported this bug upstream, but they closed it saying that the bookdown 
> package is ways too old to be of any use, and that I should install the 
> package directly instead. They are right in some sense, but I'd prefer to use 
> the Debian packages if possible.
> https://github.com/rstudio/bookdown-demo/issues/67
> 
> Could you please update the package? I'm tagging the bug as grave since the 
> package seems unusable as is.

We would love to fix this bug but unfortunately it depends
from r-cran-bslib (#996965) which is extremely hard to
package due to usage lots of fonts which are hard to find
the source for and different versions of bootstrap.js.

Any help for getting r-cran-bslib packaged would be extremely
welcome.

Kind regards

   Andreas. 

-- 
http://fam-tille.de

Bug#1009304: ITP: libjxl-testdata -- Data test suite for libjxl

[Mathieu Malaterre]

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

* Package name: libjxl-testdata
  Version : 0.1
  Upstream Author : libjxl authors
* URL : https://github.com/libjxl/testdata
* License : BSD
  Programming Lang: None
  Description : Data test suite for libjxl

Description: JPEG XL Image Coding System - "JXL" (testdata)
 The JPEG XL Image Coding System (ISO/IEC 18181) is a lossy and
 lossless image compression format. It has a rich feature set and is
 particularly optimized for responsive web environments, so that
 content renders well on a wide range of devices. Moreover, it includes
 several features that help transition from the legacy JPEG format.
 .
 This package installs the testdata files for libjxl.

--

Upstream has recently remove the testdata from the main repo. Replicate
the split at Debian package level. This will allow distributing updated
libjxl release without updating at the same time libjxl-testdata (~19M).

This will be team maintained: Debian PhotoTools Maintainers

Bug#1008687: FTBFS: as-test_pool FAIL killed by signal 6 SIGABRT

[Matthias Klumpp]

Hi Florian!

Am Mo., 11. Apr. 2022 um 09:30 Uhr schrieb Florian Ernst
:
>
> Hello Matthias,
>
> thank you for your reply and for the appstream update.
>
> On Sun, Apr 10, 2022 at 11:08:40PM +0200, Matthias Klumpp wrote:
> > Am Mi., 30. März 2022 um 20:21 Uhr schrieb Florian Ernst 
> > :
> > > during a rebuild of the reverse b-d of libyaml I found that this package
> > > failed to build on my amd64.
> > >
> > > In addition, the build also failed on amd64, i386, arm64, and armhf,
> > > each both in unstable and in bookworm, cf.
> > > 
> > > where you will also find full logs.
> >
> > I can't reproduce this issue at all, and a recent upload of AppStream
> > is building fine on all architectures...
> > Does this issue still exist? Maybe it was a fluke or fixed in some
> > other component meanwhile...
>
> I agree that the new upload appears to be building just fine on the
> official buildd, so thanks for that.
>
> Unfortunately, for me both the previous version and the current version
> still FTBFS on my local setup, with exactly the same error message. Of
> course, that by itself could all too easily be a local fluke that I'd
> have to investigate and that you could safely ignore, if it weren't for
> reproducible-builds indicating the very same FTBFS as well.
> [...]
> All in all this hints at some issue still lingering around, but I cannot
> exactly pinpoint what it might be.
>
> I'd say let's wait until reproducible-builds attempts to build 0.15.3-1
> and see what the results are. Or feel free to downgrade this issue here
> as you deem fit, for on the official buildd and on your machine
> everything seems to be working juts fine.

I'll likely downgrade this bug, but this is fairly odd! If the tests
fail on some building machines, there is a chance that the actual
application also doesn't work everywhere. I can say though that this
works on the buildds, on my local machine and on GitLab. Is there
anything that's different in the reproducible build machines compared
to the buildds? Is there anything special about your local machine?

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1009303: imv: Upstream homepage has moved, and incorrect watch file

[Gard Spreemann]

Package: imv
Version: 4.3.0-1
Severity: minor
X-Debbugs-Cc: g...@nonempty.org

Dear Maintainer,

The package currently has

 Homepage: https://github.com/eXeC64/imv

while upstream has moved to

 https://sr.ht/~exec64/imv/

This also causes d/watch to monitor stale sources for new releases.


 -- Gard


signature.asc
Description: PGP signature

Bug#1009241: sagemath: autokgtest regression on armhf

[Tobias Hansen]

Hi,

this is not a regression, as the armhf and mips64el tests never passed, see 
#1004872 and #920147. There was a bug in the package that caused the tests not 
to be run when building with python 3.10, so the armhf and mips64el package 
builds succeeded. The packages for these architectures should be removed from 
testing. I fixed this in sagemath 9.5-3.

Best,
Tobias

On 4/9/22 16:56, Sebastian Ramacher wrote:
> Source: sagemath
> Version: 9.5-2
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
>
> sagemath's autopkgtests fail on armhf:

Bug#1009302: linux-image-5.17.0-trunk-amd64: Missing CONFIG_X86_AMD_PSTATE=m module

[Vincent Blut]

Control: tags -1 pending

Hi,

Le 2022-04-11 10:52, Tobias Koeck a écrit :
> Package: src:linux
> Version: 5.17.1-1~exp1
> Severity: important
> 
> Dear Maintainer,
> 
> the
> 
> CONFIG_X86_AMD_PSTATE
> 
> module is not set.
> 
> https://www.phoronix.com/scan.php?page=news_item=AMD-P-State-How-To
> 
> Can you add it to the kernel so that it is possible to use AMD's power
> management?

This is pending.

https://salsa.debian.org/kernel-team/linux/-/commit/2ee8b17f8d9cf15a02bf373b7eca5bade354abaf

> Greetings and thanks,
> Tobias

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1009273: Should python-keepkey be removed?

[Richard Ulrich]

Hi Moritz,

If it all worked and was in sync with electrum, that would be great.

But I stopped updating it back then because in the end most of the time
I still had to install electrum and those plugins manually.

So, feel free to remove it. In case I find the time and motivation to
package a new version, I can still re-add it.

Rgds
Richard

Am Sonntag, dem 10.04.2022 um 22:08 +0200 schrieb Moritz Muehlenhoff:
> Source: python-keepkey
> Version: 0.7.3-1
> Severity: serious
> 
> Your package came up as a candidate for removal from Debian:
> 
> - Still depends on Python 2 and thus removed from testing since 2019
> - Last upload back in 2016
> 
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
> 
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:
> 
> --
> severity $BUGNUM normal
> reassign $BUGNUM ftp.debian.org
> retitle $BUGNUM RM:  -- RoM; 
> thx
> --
> 
> Otherwise I'll move forward and request it's removal in a month.
> 
> Cheers,
>     Moritz

-- 
Namecoin: id/ulrichard 
Bitte schicken Sie mir wenn möglich PGP/GPG verschlüsselte Nachrichten.



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

Bug#1009302: linux-image-5.17.0-trunk-amd64: Missing CONFIG_X86_AMD_PSTATE=m module

[Tobias Koeck]

Package: src:linux
Version: 5.17.1-1~exp1
Severity: important

Dear Maintainer,

the

CONFIG_X86_AMD_PSTATE

module is not set.

https://www.phoronix.com/scan.php?page=news_item=AMD-P-State-How-To

Can you add it to the kernel so that it is possible to use AMD's power
management?

Greetings and thanks,
Tobias
-- Package-specific info:
** Version:
Linux version 5.17.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc-11 
(Debian 11.2.0-19) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP 
PREEMPT Debian 5.17.1-1~exp1 (2022-03-29)

** Command line:
BOOT_IMAGE=/@rootfs/boot/vmlinuz-5.17.0-trunk-amd64 
root=UUID=39ac90d8-90c7-498c-aeea-e8ee37c76497 ro rootflags=subvol=@rootfs 
quiet fsck.mode=force fsck.repair=yes clocksource=tsc tsc=reliable

** Not tainted

** Kernel log:
[7.541793] iwlwifi :03:00.0: Direct firmware load for 
iwlwifi-cc-a0-64.ucode failed with error -2
[7.541803] iwlwifi :03:00.0: firmware: failed to load 
iwlwifi-cc-a0-63.ucode (-2)
[7.541804] iwlwifi :03:00.0: Direct firmware load for 
iwlwifi-cc-a0-63.ucode failed with error -2
[7.544765] iwlwifi :03:00.0: firmware: direct-loading firmware 
iwlwifi-cc-a0-62.ucode
[7.544798] iwlwifi :03:00.0: api flags index 2 larger than supported by 
driver
[7.544831] iwlwifi :03:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 
89.3.35.37
[7.545604] iwlwifi :03:00.0: loaded firmware version 62.49eeb572.0 
cc-a0-62.ucode op_mode iwlmvm
[7.545630] iwlwifi :03:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[7.566234] loop10: detected capacity change from 0 to 126760
[7.566530] loop11: detected capacity change from 0 to 226664
[7.567016] loop12: detected capacity change from 0 to 448512
[7.590143] loop15: detected capacity change from 0 to 104360
[7.590143] loop14: detected capacity change from 0 to 210792
[7.590144] loop16: detected capacity change from 0 to 89352
[7.590287] loop13: detected capacity change from 0 to 509456
[7.634354] input: HDA Digital PCBeep as 
/devices/pci:00/:00:08.1/:07:00.6/sound/card1/input35
[7.634449] input: HD-Audio Generic Mic as 
/devices/pci:00/:00:08.1/:07:00.6/sound/card1/input36
[7.634526] input: HD-Audio Generic Headphone as 
/devices/pci:00/:00:08.1/:07:00.6/sound/card1/input37
[7.643899] Bluetooth: Core ver 2.22
[7.643935] NET: Registered PF_BLUETOOTH protocol family
[7.643936] Bluetooth: HCI device and connection manager initialized
[7.643940] Bluetooth: HCI socket layer initialized
[7.643942] Bluetooth: L2CAP socket layer initialized
[7.643946] Bluetooth: SCO socket layer initialized
[7.656437] SVM: TSC scaling supported
[7.656441] kvm: Nested Virtualization enabled
[7.656442] SVM: kvm: Nested Paging enabled
[7.656449] SVM: Virtual VMLOAD VMSAVE supported
[7.656450] SVM: Virtual GIF supported
[7.656450] SVM: LBR virtualization supported
[7.706399] MCE: In-kernel MCE decoding enabled.
[7.710084] iwlwifi :03:00.0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, 
REV=0x340
[7.710139] thermal thermal_zone1: failed to read out thermal zone (-61)
[7.712162] usbcore: registered new interface driver btusb
[7.713425] Bluetooth: hci0: Bootloader revision 0.3 build 0 week 24 2017
[7.715450] Bluetooth: hci0: Device revision is 1
[7.715455] Bluetooth: hci0: Secure boot is enabled
[7.715456] Bluetooth: hci0: OTP lock is enabled
[7.715457] Bluetooth: hci0: API lock is enabled
[7.715457] Bluetooth: hci0: Debug lock is disabled
[7.715458] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[7.717916] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-20-1-3.sfi
[7.717929] Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi
[7.717965] Bluetooth: hci0: Boot Address: 0x24800
[7.717967] Bluetooth: hci0: Firmware Version: 255-255.255
[7.840807] intel_rapl_common: Found RAPL domain package
[7.840810] intel_rapl_common: Found RAPL domain core
[7.875094] iwlwifi :03:00.0: Detected RF HR B3, rfid=0x10a100
[7.947650] iwlwifi :03:00.0: base HW address: a8:7e:ea:6d:78:e2
[7.965839] iwlwifi :03:00.0 wlp3s0: renamed from wlan0
[8.311898] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[8.311902] Bluetooth: BNEP filters: protocol multicast
[8.311907] Bluetooth: BNEP socket layer initialized
[8.328200] usbcore: registered new interface driver snd-usb-audio
[8.456964] audit: type=1400 audit(1649664576.847:2): apparmor="DENIED" 
operation="change_onexec" info="label not found" error=-2 profile="unconfined" 
name="system_tor" pid=1118 comm="(tor)"
[8.524493] Generic FE-GE Realtek PHY r8169-0-200:00: attached PHY driver 
(mii_bus:phy_addr=r8169-0-200:00, irq=MAC)
[8.651006] r8169 :02:00.0 enp2s0f0: Link is Down
[8.655510] r8169 :05:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168h-2.fw
[8.680486] Generic 

Bug#987360: swaylock: Occassional unlock without password entered

[Gard Spreemann]

X-Debbugs-CC: d...@jones.dk,pe...@riseup.net

Hi all.

Jonas Smedegaard  writes:

> Hi Pelle,
>
> You reported this issue for swaylock 1.5-2.
>
> Do you still experience same isue with swaylock 1.6-1 now in Debian 
> unstable?

I cannot answer for Pelle, but I was also experiencing this bug back
when it was reported. FWIW: I'm unable to reproduce it with 1.6-1. That
being said, triggering the bug does seem somewhat stochastic, so I can't
rule out that a bunch more suspend/resume cycles would trigger it. But
so far, so good!

> Perhaps sensible to lower severity of this issue, to allow more exposure 
> to it in Debian testing - and then hopefully close it for good soon, 
> when work on ext-session-lock-v1 is finalized: 
> https://github.com/swaywm/sway/pull/6879

I agree; I think we can lower the severity and let swaylock back into
testing, and just raise the severity back up if anyone is able to
reproduce on 1.6-1.


 Best,
 Gard


signature.asc
Description: PGP signature

Bug#1009066: pcre2: FTBFS on hurd-i386: error: ‘PATH_MAX’ undeclared

[Matthew Vernon]

Hi,

Upstream already have a Hurd build fix ( 
https://github.com/PhilipHazel/pcre2/commit/adf76faace83d2b926b9136821daa02a78266b95 
), which I've applied to my tree, and uploaded as 10.39-4.


Regards,

Matthew

Bug#982302: groff: bad ghostscript version in the font path

[G. Branden Robinson]

package groff
forcemerge 982302 952922
thanks

Hi Marc,

Your bug report #952922 appears to have been resolved by the closure of
bug #982302.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1009301: acpid: acpi.path in container generates - systemd[1]: Condition check resulted in ACPI event daemon being skipped.

[Frank Dornheim]

Package: acpi
Version:1:2.0.32 Severity: normal

Dear Maintainer,

The package is also installed in containers for example lxc/lxd through 
dependencies. Systemd deactivates acpid with the line: 
'ConditionVirtualization=!container' in the section [Unit] in the file: 
'acpid.service'. The file watcher acpi.path does not have this setting, 
which leads to permanent errors in the log: systemd[1]: Condition check 
resulted in ACPI event daemon being skipped. Therefore, I suggest to 
also insert the line: 'ConditionVirtualization=!container' in the 
section: 'Unit' in the acpid.path file. I tested the solution.


Thanks Frank

-- System Information:
Debian Release: bullseye
  APT prefers testing
  APT policy: (950, 'testing'), (54, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux5.13.0-39-generic
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages acpi depends on:
ii  libc6  2.27

acpi recommends no packages.

acpi suggests no packages.

-- no debconf information

Bug#1009300: dpkg: allow symbol files to be excluded from install

[Ansgar]

Package: dpkg
Version: 1.21.7
Severity: wishlist

Someone wondered on IRC why we ship symbols files in shared library
packages instead of the associated -dev packages and noted that they
take 1% of disk space for a fresh debian:sid docker container (and
probably more on the -slim variant of the container).

It would be nice if it was possible to exclude symbol files from such
environments. This could mean:

 - Ship them in the -dev package instead.

 - Ship them in a well-known location in /usr (they are not variable
   state data after all); this would allow the regular exclusion
   mechanism already used by -slim images to be used here as well.

 - Or both.

Ansgar

Bug#488213: groff-base: Escaped version of apostroph (\') does not display in ISO-8859-15 locale

[G. Branden Robinson]

I reiterate (after ~17 months) that the suggestion in this bug report is
ill-advised.

ISO 8859-15 (Latin-9) simple _has_ no code point for the acute accent,
any more than ASCII does.

Further, as Jakub Wilk pointed out, it's just plain wrong semantics to
use the \' escape sequence to obtain any form of quotation mark.  All
known *roffs going back to Osanna's 1973 troff define this escape
sequence as representing an acute accent.

Any man page that uses \' to attempt to obtain a quotation mark is in
error.

I suggesting tagging this bug "wontfix" and closing it.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1008700: [Pkg-electronics-devel] Bug#1008700: Should geda-gaf be removed?

[Bdale Garbee]

Moritz Mühlenhoff  writes:

> If lepton-eda is a sufficient drop-in replacement for existing geda-gaf
> users, lepton could provide a geda-gaf transition package for the bookworm
> release? I can file a bug against lepton-eda when geda-gaf has been
> removed.

Yes, we could certainly do that.

Bdale


signature.asc
Description: PGP signature

Bug#1009299: linux-image-5.16.0-6-amd64: 5.16 breaks buttons below touchpad on Dell Precision 7550

[Marc Glisse]

Package: src:linux
Version: 5.16.18-1
Severity: normal

Dear Maintainer,

the Dell Precision 7550 is a laptop which has a touchpad, and below it 3
physical buttons. If I boot with linux-image-5.15.0-3-amd64, these
buttons work perfectly well. However, with linux-image-5.16.0-6-amd64,
the right button does not work. Running xev, it prints nothing when I
click that button. evemu-record does see something when I click on the
right button, here are some random parts of its log

# DMI: 
dmi:bvnDellInc.:bvr1.12.0:bd12/12/2021:br1.12:svnDellInc.:pnPrecision7550:pvr:rvnDellInc.:rn01PXFR:rvrA00:cvnDellInc.:ct10:cvr:sku09C3:
# Input device name: "DELL09C3:00 0488:120A Touchpad"
# Input device ID: bus 0x18 vendor 0x488 product 0x120a version 0x100

#   Event type 1 (EV_KEY)
# Event code 272 (BTN_LEFT)
# Event code 325 (BTN_TOOL_FINGER)
# Event code 328 (BTN_TOOL_QUINTTAP)
# Event code 330 (BTN_TOUCH)
# Event code 333 (BTN_TOOL_DOUBLETAP)
# Event code 334 (BTN_TOOL_TRIPLETAP)
# Event code 335 (BTN_TOOL_QUADTAP)

# Properties:
#   Property  type 0 (INPUT_PROP_POINTER)
#   Property  type 2 (INPUT_PROP_BUTTONPAD)

E: 0.01 0004 0005   # EV_MSC / MSC_TIMESTAMP0
E: 0.01     #  SYN_REPORT (0) -- +0ms
E: 0.001257 0004 0005 4400  # EV_MSC / MSC_TIMESTAMP4400
E: 0.001257     #  SYN_REPORT (0) -- +1ms
E: 0.002600 0004 0005 8900  # EV_MSC / MSC_TIMESTAMP8900
E: 0.002600     #  SYN_REPORT (0) -- +1ms
E: 0.004029 0004 0005 13300 # EV_MSC / MSC_TIMESTAMP13300
[...]

The buttons were always a bit strange (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980376).

syslog (or Xorg.0.log) has, among other things

Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (II) event23 - 
DELL09C3:00 0488:120A Touchpad: is tagged by udev as: Touchpad
Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (EE) event23 - 
DELL09C3:00 0488:120A Touchpad: kernel bug: missing right button, assuming it 
is a clickpad.
Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (II) event23 - 
DELL09C3:00 0488:120A Touchpad: device is a touchpad

Please let me know any logs I should attach to help.

-- Package-specific info:
** Version:
Linux version 5.16.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.2.0-19) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 
5.16.18-1 (2022-03-29)

** Command line:
BOOT_IMAGE=/vmlinuz-5.16.0-6-amd64 root=/dev/mapper/hippo--vg-root ro quiet

** Tainted: PO (4097)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded

** Kernel log:
[  294.309266] leds dell::kbd_backlight: Setting an LED's brightness failed (-5)
[  294.317480] input: HDA Intel PCH Headphone Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input29
[  294.318288] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [WAR2] at bit 
offset/length 64/32 exceeds size of target Buffer (64 bits) 
(20210930/dsopcode-198)
[  294.318327] ACPI Error: Aborting method \_SB.AMW0.WMBA due to previous error 
(AE_AML_BUFFER_LIMIT) (20210930/psparse-529)
[  294.319617] Bluetooth: hci0: Failed to read codec capabilities (-56)
[  294.320650] Bluetooth: hci0: Failed to read codec capabilities (-56)
[  294.321568] iwlwifi :00:14.3 wlo1: renamed from wlan0
[  294.321603] Bluetooth: hci0: Failed to read codec capabilities (-56)
[  294.322628] Bluetooth: hci0: Failed to read codec capabilities (-56)
[  294.322716] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [WAR2] at bit 
offset/length 64/32 exceeds size of target Buffer (64 bits) 
(20210930/dsopcode-198)
[  294.322751] ACPI Error: Aborting method \_SB.AMW0.WMBA due to previous error 
(AE_AML_BUFFER_LIMIT) (20210930/psparse-529)
[  294.322805] usbcore: registered new interface driver snd-usb-audio
[  294.323626] Bluetooth: hci0: Failed to read codec capabilities (-56)
[  294.324692] Bluetooth: hci0: Failed to read codec capabilities (-56)
[  294.381074] audit: type=1400 audit(1649659457.376:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="firejail-default" pid=972 
comm="apparmor_parser"
[  294.381542] audit: type=1400 audit(1649659457.376:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=986 comm="apparmor_parser"
[  294.381842] audit: type=1400 audit(1649659457.376:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oosplash" 
pid=983 comm="apparmor_parser"
[  294.381982] audit: type=1400 audit(1649659457.376:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=973 
comm="apparmor_parser"
[  294.382340] audit: type=1400 audit(1649659457.376:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=976 
comm="apparmor_parser"
[  294.382344] audit: type=1400 

Bug#1008653: backintime-qt: fix upstream

[Leonardo Canducci]

Package: backintime-qt
Version: 1.2.1-3
Followup-For: Bug #1008653

Dear Maintainer,
this is a known bug due to the python 3.10 transition and is fixed upstream:

https://github.com/bit-team/backintime/issues/1210
https://github.com/bit-team/backintime/pull/1174

Please update the package.

Regards,
Leonardo

Bug#1009298: transition: biojava-live

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-biojava-live.html

On 2022-04-11 09:34:08, Pierre Gruet wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release team,
> 
> I would like to request a transition slot for biojava-live. This would be a
> small transition with 4 reverse-dependencies. The reason is upstream changed
> the interface quite a lot between versions 1.7.* and 1.9.5, which has just 
> been
> accepted in experimental through NEW.
> 
> The automatic ben file at
> https://release.debian.org/transitions/html/auto-biojava-live.html
> should be changed to the below one, as it fails to track two packages.
> 
> The four reverse dependencies:
> * alien-hunter
> * artemis
> * logol
> * mauve-aligner
> ftbfs with the new library, but (as they are team-maintained by Debian med
> team, of which I am a member) I have uploaded fixed versions of all of them to
> experimental, and they build fine. Bugs with severity important have been 
> filed
> for the four of them. I am ready to start transitioning all the packages when
> you tell me.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#988945: [Pkg-rust-maintainers] Bug#988945: rust-http: diff for NMU version 0.1.21-0.1

[Sylvestre Ledru]

Le 11/04/2022 à 01:14, Jonas Smedegaard a écrit :

Hi Sylvestre,

Quoting Sylvestre Ledru (2022-04-10 22:15:47)

Maybe you should join the team, commit there and follow the process
for our packages?  :)


Thanks for the suggestion, but I decline the offer:

I am not interested in joining a team where packages should be tracked
in one giant git repo.

If I am mistaken and that's not a policy in the Rust team - or if the
team might consider changing that policy, then I would gladly join.

It is and it probably won't change (too hard))

I will then have to ask you to stop doing NMU without delays as it will make our
life harder. :(

Sorry,
Sylvestre

Bug#1009298: transition: biojava-live

[Pierre Gruet]

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

Dear Release team,

I would like to request a transition slot for biojava-live. This would be a
small transition with 4 reverse-dependencies. The reason is upstream changed
the interface quite a lot between versions 1.7.* and 1.9.5, which has just been
accepted in experimental through NEW.

The automatic ben file at
https://release.debian.org/transitions/html/auto-biojava-live.html
should be changed to the below one, as it fails to track two packages.

The four reverse dependencies:
* alien-hunter
* artemis
* logol
* mauve-aligner
ftbfs with the new library, but (as they are team-maintained by Debian med
team, of which I am a member) I have uploaded fixed versions of all of them to
experimental, and they build fine. Bugs with severity important have been filed
for the four of them. I am ready to start transitioning all the packages when
you tell me.

Ben file:

title = "biojava-live";
is_affected = .depends ~ "libbiojava1.7-java" | .depends ~ "libbiojava1.9-java" 
| .depends ~ "libbiojava-java";
is_good = .depends ~ "libbiojava1.9-java";
is_bad = .depends ~ "libbiojava1.7-java";

Best regards,

-- 
Pierre

Bug#1008687: FTBFS: as-test_pool FAIL killed by signal 6 SIGABRT

[Florian Ernst]

Hello Matthias,

thank you for your reply and for the appstream update.

On Sun, Apr 10, 2022 at 11:08:40PM +0200, Matthias Klumpp wrote:
> Am Mi., 30. März 2022 um 20:21 Uhr schrieb Florian Ernst 
> :
> > during a rebuild of the reverse b-d of libyaml I found that this package
> > failed to build on my amd64.
> >
> > In addition, the build also failed on amd64, i386, arm64, and armhf,
> > each both in unstable and in bookworm, cf.
> > 
> > where you will also find full logs.
> 
> I can't reproduce this issue at all, and a recent upload of AppStream
> is building fine on all architectures...
> Does this issue still exist? Maybe it was a fluke or fixed in some
> other component meanwhile...

I agree that the new upload appears to be building just fine on the
official buildd, so thanks for that.

Unfortunately, for me both the previous version and the current version
still FTBFS on my local setup, with exactly the same error message. Of
course, that by itself could all too easily be a local fluke that I'd
have to investigate and that you could safely ignore, if it weren't for
reproducible-builds indicating the very same FTBFS as well.

Looking at the reproducible-builds history of appstream it seems it has
been FTBFS'ing in their setup for quite a while, cf.

https://tests.reproducible-builds.org/debian/history/appstream.html

as well as the individual logs at

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/bookworm/amd64/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/bookworm/i386/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/bookworm/arm64/appstream_0.15.2-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/bookworm/armhf/appstream_0.15.2-2.rbuild.log.gz

All in all this hints at some issue still lingering around, but I cannot
exactly pinpoint what it might be.

I'd say let's wait until reproducible-builds attempts to build 0.15.3-1
and see what the results are. Or feel free to downgrade this issue here
as you deem fit, for on the official buildd and on your machine
everything seems to be working juts fine.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1009281: [Debichem-devel] Bug#1009281: Bug#1009281: Should cinfony be removed?

[Michael Banck]

Hi,

On Mon, Apr 11, 2022 at 08:38:21AM +0300, Andrius Merkys wrote:
> Hi,
> 
> On 2022-04-11 01:35, Moritz Muehlenhoff wrote:
> > Source: cinfony
> > Version: 1.2-4
> > Severity: serious
> > 
> > Your package came up as a candidate for removal from Debian:
> > 
> > - Still depends on Python 2 and thus removed from testing since 2019
> > - Dead upstream
> > - No reverse dependencies
> 
> Incidentally, I was the last to upload this package. Since 2019 there
> were no uploads, due to aforementioned reasons. I have contemplated
> filing for RM ever since, but did not get to it. I think it is fine to
> remove. If Python 3 port ever happens, we can reintroduce the package then.

I contacted the author and asked him about it - it seems the master
branch on Github has python3 support, but I didn't look very closely.


Michael

Bug#1009196: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files

[Hans Hagen]

On 4/11/2022 6:56 AM, Norbert Preining wrote:

Hi Luigi, hi all luatex devs,

here at Debian we got a bug report about reproducability of luatex
format dumps. It contains a patch to make the hyphenation exception list
sorted. (I attach the patch)

Could you please take a look whether this is still relevant for the
latest release of luatex.
it actually defeats one of the security properties of lua (which was 
explicitly introduced at some point: make sure that hashes have random 
order each run so that it's harder to retrieve sensitive data from mem)


that said, it means that as soon as something gets stored in the format 
otherwise (than exceptions) one can face the same issue (although one 
can work around that by sorting etc)


if you want reproducibility for some testing, mess with this instead:

#if !defined(luai_makeseed)
#include 
#define luai_makeseed() cast(unsigned int, time(NULL))
#endif

anyway, formats with embedded lua data (serialized or bytecode is never 
guaranteed the same unless one does soem effort)


fwiw: the easiest solution is to not store patterns and exceptions in 
the format and just load them runtime which is just as fast (in 
retrospect not a good idea to store it but it was needed for some plain 
compatibility testing)


Hans

(who in the past has been bitten by this 'random feature' when we made 
the switch to 5.3, or maybe it was even 5.2; it used to be 'random per 
binary' and became 'random per run' but we decided to stick with 
official lua)


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-

Bug#1009297: Upcoming biojava-live transition

[Pierre Gruet]

Source: mauve-aligner
Version: 2.4.0+4736-4
Severity: important
Tags: fixed-in-experimental

Hi,

This is to inform you that the auto-biojava-live transition will start
soon, as biojava-live 1:1.9.5+dfsg will enter unstable.

Currently your package would ftbfs with this new biojava-live, yet I
worked on it and uploaded it to experimental, where it builds fine
against the transitioning package.

I offer to take care of the whole transition, including your package,
which is team-maintained by Debian med team.

Best,

--
Pierre

Bug#1009296: Upcoming biojava-live transition

[Pierre Gruet]

Source: alien-hunter
Version: 1.7-8
Severity: important
Tags: fixed-in-experimental

Hi,

This is to inform you that the auto-biojava-live transition will start
soon, as biojava-live 1:1.9.5+dfsg will enter unstable.

Currently your package would ftbfs with this new biojava-live, yet I
worked on it and uploaded it to experimental, where it builds fine
against the transitioning package.

I offer to take care of the whole transition, including your package,
which is team-maintained by Debian med team.

Best,

--
Pierre

Bug#1009295: Upcoming biojava-live transition

[Pierre Gruet]

Source: logol
Version: 1.7.9+dfsg-3
Severity: important
Tags: fixed-in-experimental

Hi,

This is to inform you that the auto-biojava-live transition will start
soon, as biojava-live 1:1.9.5+dfsg will enter unstable.

Currently your package would ftbfs with this new biojava-live, yet I
worked on it and uploaded it to experimental, where it builds fine
against the transitioning package.

I offer to take care of the whole transition, including your package,
which is team-maintained by Debian med team.

Best,

--
Pierre

Bug#1009294: Upcoming biojava-live transition

[Pierre Gruet]

Source: artemis
Version: 18.1.0+dfsg-6
Severity: important
Tags: fixed-in-experimental

Hi,

This is to inform you that the auto-biojava-live transition will start 
soon, as biojava-live 1:1.9.5+dfsg will enter unstable.


Currently your package would ftbfs with this new biojava-live, yet I 
worked on it and uploaded it to experimental, where it builds fine 
against the transitioning package.


I offer to take care of the whole transition, including your package, 
which is team-maintained by Debian med team.


Best,

--
Pierre

Bug#1008722: Possible bugfix

[Moessbauer, Felix]

Hi Sudip,

> -Original Message-
> From: Sudip Mukherjee 
> Sent: Sunday, April 10, 2022 9:10 PM
> 
> Hi Felix,
> 
> On Wed, Apr 6, 2022 at 1:27 PM Moessbauer, Felix
>  wrote:
> >
> > Hi Sudip,
> >
> > Unfortunately I found more races in the build.
> 
> I am thinking  of disabling parallel jobs while building. That should fix the
> problem for now. Your thoughts ?

That's probably the best strategy, until these issues are fixed upstream.
We locally already use DEB_BUILD_PROFILES="parallel=1" to mitigate it.

While we are at it: Please also add the missing build deps "flex" and "bison".

Regards,
Felix

> 
> 
> --
> Regards
> Sudip

Bug#1009291: RFS: git-multimail/1.5.0-1 [ITP] -- git-multimail is a tool for sending notification emails on pushes

[Bo YU]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "git-multimail":

 * Package name: git-multimail
   Version : 1.5.0-1
   Upstream Author : Matthieu Moy 
 * URL : https://github.com/git-multimail/git-multimail
 * License : GPL-2.0+, GPL-2.0
 * Vcs : https://salsa.debian.org/python-team/packages/git-multimail
   Section : python

The source builds the following binary packages:

  python3-git-multimail - git-multimail is a tool for sending
notification emails on pushes

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

  https://mentors.debian.net/package/git-multimail/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-multimail/git-multimail_1.5.0-1.dsc

Changes for the initial release:

 git-multimail (1.5.0-1) unstable; urgency=medium
 .
   * Initial release of git-multimail to Debian. (Closes: #1007025)
 .
   * Start from upstream's packaging. With some refreshing:
 .
 -- Add myself as Maintainer.

Regards,
-- 
  Bo YU

Bug#1009267: zfsnap fail to delete snapshorts if left without removal for three years

[Petter Reinholdtsen]

For the record, I had around 170 000 snapshots when I started.

I am currently trying to reduce it by running variations of this
oneliner to get rid of them, to allow zfSnap -d to work again.

  for v in $(zfs list -t snapshot zfstank/volume | \
 awk '/2019.*--5d/ {print $1}'); do zfs destroy $v; done

-- 
Happy hacking
Petter Reinholdtsen

Bug#1009257: Option to convert white to transparency

[Jeff]

On 10/04/2022 20:36, martin f krafft wrote:

Regarding the following, written by "Jeff" on 2022-04-10 at 12:52 Uhr +:

Can't this be achieved with a user defined tool?

Sure thing, for instance:

|convert -size 2480x3508 -depth 300x300 -transparent white in.pdf out.pdf |

I see four problems with this though:

 1.

This operation would be a lot faster on the PNM files, rather than
first writing the PDF, and then basically accessing the PDF bitmaps
page-wise for this operation;


The user-defined tools operate on the source images, not the resulting 
PDF. I think you might be mixing them up with the post-save hook, which 
does operate on the PDF.



 3.

A user-defined tool does not have access to the resolution to be
used, unlike gscan2pdf. I can calculate the dimensions, but only if
I have the resolution;


The user-defined tools currently offer 3 variables, %i for input 
filename, %o for output filename, and %r for resolution.


I understand your point, but the argument can be made about all of the 
post-processing tools built-in, and the question becomes which one of 
those are so commonly used that they should be built-in. I never use 
unsharp mask, negation, brigthness/contrast, or even OCR, but they are 
built-in.


Absolutely. I was not suggesting it shouldn't be added, only provide a 
workaround until I found time to do so.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008028: closed by Debian FTP Masters (reply to Daniel Echeverri ) (Bug#1008028: fixed in hydra 9.3-2)

[Helmut Grohne]

Control: reopen -1

On Sat, Apr 02, 2022 at 07:06:04PM +, Debian Bug Tracking System wrote:
> It has been closed by Debian FTP Masters  
> (reply to Daniel Echeverri ).

Thank you for addressing the error propagation. Unfortunately, the
symptom fully persists. The gtk check that you patched didn't actually
fail, so the patched code path is not exercised. Instead, the inner
configure for xhydra itself fails. The exit code of this secondary
configure invocation is ignored. I hope this makes the issue more clear.
In any case, you can use cross builds to trigger the faulty behaviour.
Full logs are available at https://crossqa.debian.net/src/hydra.

Helmut

PS: While the cross build failure also is a (normal) failure, that's not
the issue of this bug.