Bug#839961: libjs-d3: please package new upstream release

[Paul Gevers]

Hi László,

On Mon, 10 Feb 2020 22:39:25 +0100 
=?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?=  wrote:

On Wed, Jan 15, 2020 at 3:51 PM Balint Reczey
 wrote:
> On Wed, 23 Jan 2019 20:12:56 +0100 Paul Gevers  wrote:
> > On Thu, 06 Oct 2016 22:03:43 +0200 Paul Gevers  wrote:
> > > Upstream d3 is very active and currently runs at 4.2.6. Please consider
> > > updating the libjs-d3 package.
> >
> > Any progress on this? I'd love to have the new version in Buster. I
> > offer help if you need or want it.
 There's definitely need for help, please read on.


I just spotted the node-d3 package. Has that solved all the issues and 
can that be considered the replacement of this package?


If so, should libjs-d3 be removed from Debian?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008323: bpftrace: fix FTBFS

[Vincent Bernat]

 ❦ 11 April 2022 21:14 +02, Hector Oron:

>   According to https://github.com/iovisor/bpftrace/issues/2068
>
>   I applied the following patch to make the package build:

Thanks! I will use the more minimal patch found here instead:
https://github.com/iovisor/bpftrace/pull/2174
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#998739:

[Ievgen Popovych]

On Mon, 11 Apr 2022 22:18:26 +0300 Ievgen Popovych  wrote:
> Hello,
>
> I had the same issue when building a package with a system interpreter:
> sysconfig module reports incorrect paths (pointing to `site-packages`
> instead of `dist-packages`).
> The culprit seems to be that it thinks that
> > Current installation scheme: "posix_prefix"
> instead of `deb_system`.
> That, in turn, looks to be an issue with `_get_default_scheme()`
> implementation in `patches/sysconfig-debian-schemes.diff` which
> depends on environment variable `DEB_PYTHON_INSTALL_LAYOUT`.
> The only reference I found is a changelog entry stating that this is
> indeed a desired behavior.
>
> But I wonder why?
> It is inconsistent with distutils behavior.
> It does not refer to (quoting sysconfig module docstring)
> > Python’s configuration information like the list of installation paths and 
> > the configuration variables relevant for the current platform
> In current form it is essentially irrelevant.
>

I was just playing a bit more and it turns out that
`/usr/lib/python3.9/sysconfig.py` does not include changes from
`patches/sysconfig-debian-schemes.diff` at all!
I've verified I do have Debian Bullseye :), file is proided by
`libpython3.9-minimal:amd64:`. sysconfig-debian-schemes.diff is also
in `patches/series`.
I do not know what to think at this point..

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

[Bastian Germann]

Control: tags -1 moreinfo

Hi Miao,

Please do not skip a version (or leave it UNRELEASED). If this is a team upload (not in changelog...) and the team has 
confirmed splitting the package, please reference the okay statement. Else, nobody will touch this massive change.


I am tagging moreinfo. When you have provided the requested info, please untag.

Thanks,
Bastian

Bug#1009331: ITP: node-gitlab-favicon-overlay -- Combine images for a favicon with the help of canvas

[Michael Ikwuegbu]

Package: wnpp
Severity: wishlist
Owner: Michael Ikwuegbu 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-gitlab-favicon-overlay
  Version : 2.0.0
  Upstream Author  : GitLab Frontend Team 
* URL  :
https://gitlab.com/gitlab-org/frontend/favicon-overlay#read>
* License : Expat
  Programming Lang: JavaScript
  Description : Combine images for a favicon with the help of
canvas
.
 Node.js is an event-based server-side JavaScript engine.

Bug#998147: fonts-fork-awesome: The file icons.yml is not included in the binary package

[Nicholas D Steeves]

Control: severity -1 important
Control: tag -1 patch
Control: block 1008958 by -1

Hi Alexandre!

On Sun, 31 Oct 2021 00:56:15 +0200 Hannah Rittich  wrote:
> Source: fonts-fork-awesome
> Version: 1.1.5+ds1-2
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: v...@rittich.net
> 
> Building Qt ForkAwesome (which is a dependency for Syncthing Tray, which
> I am currently packaging) requires the icons.yml from the src folder.
> Please include this file into the binary package. A patch file is attached.
> 
> [1] https://github.com/Martchus/qtforkawesome#providing-the-font-file
> 
> Regards,
> 
> Hannah

I'm not sure if you received Hannah's email, but this bug is
transitively blocking progress towards the initial upload of Syncthing
Tray, thus I'm about to do an NMU of fonts-fork-awesome by uploading to
DELAYED 10.

Please let me know if you'd prefer that I cancel it.  In addition to the
attached nmudiff, I've created an MR (for your convenience) at:

  https://salsa.debian.org/fonts-team/fonts-fork-awesome/-/merge_requests/2

Regards,
Nicholas
From: Nicholas D Steeves 
Date: Mon, 11 Apr 2022 16:07:12 -0400
Subject: [PATCH 1/2] Install icons.yml, which is needed to build
 qtforkawesome.

---
 debian/changelog | 10 ++
 debian/install   |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index b4cf782..0e5afc6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+fonts-fork-awesome (1.1.5+ds1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Hannah Rittich ]
+  * Install icons.yml, which is needed to build qtforkawesome (Closes:
+#998147).
+
+ -- Nicholas D Steeves   Mon, 11 Apr 2022 16:05:39 -0400
+
 fonts-fork-awesome (1.1.5+ds1-2) unstable; urgency=medium
 
   * Build from the icons folder.
diff --git a/debian/install b/debian/install
index fe74209..9ee6380 100644
--- a/debian/install
+++ b/debian/install
@@ -7,3 +7,5 @@ fonts/forkawesome-webfont.woff2  usr/share/fonts/woff/fork-awesome/
 less/	 usr/share/fonts-fork-awesome/
 css/	 usr/share/fonts-fork-awesome/
 scss/	 usr/share/fonts-fork-awesome/
+
+src/icons/icons.yml  /usr/share/fonts-fork-awesome/
-- 
2.30.2

From: Nicholas D Steeves 
Date: Mon, 11 Apr 2022 16:46:13 -0400
Subject: [PATCH 2/2] Release 1.1.5+ds1-2.1 to unstable

---
 debian/changelog | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 0e5afc6..b117d7b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-fonts-fork-awesome (1.1.5+ds1-2.1) UNRELEASED; urgency=medium
+fonts-fork-awesome (1.1.5+ds1-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
 
@@ -6,7 +6,7 @@ fonts-fork-awesome (1.1.5+ds1-2.1) UNRELEASED; urgency=medium
   * Install icons.yml, which is needed to build qtforkawesome (Closes:
 #998147).
 
- -- Nicholas D Steeves   Mon, 11 Apr 2022 16:05:39 -0400
+ -- Nicholas D Steeves   Mon, 11 Apr 2022 16:45:34 -0400
 
 fonts-fork-awesome (1.1.5+ds1-2) unstable; urgency=medium
 
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1009332: maxima-emacs: Imaxima fails to render latex

[Balbir Thomas]

Package: maxima-emacs
Version: 5.44.0-3
Severity: normal

Dear Maintainer,

Running imaxima in Emacs does not result in pretty latex output. Instead
an error message is show. 

Steps to reproduce

1) Launch Emacs and run M-x imaxima

2) At the maxima prompt type say

diff(x**2, x) ;

and press enter

3) An LaTeX pretty printed result should be show but instead the
following error message is produced : "LaTeX error in: 2\,x"


-- 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/6 CPU threads)
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages maxima-emacs depends on:
ii  emacs-gtk [emacsen]  1:27.1+1-3.1
ii  emacsen-common   3.0.4
ii  maxima   5.44.0-3
ii  maxima-doc   5.44.0-3
ii  tex-common   6.16
ii  texlive-binaries [texlive-base-bin]  2020.20200327.54578-7
ii  texlive-latex-recommended2020.20210202-3

Versions of packages maxima-emacs recommends:
ii  evince [postscript-viewer]   3.38.2-1
ii  ghostscript [postscript-viewer]  9.53.3~dfsg-7+deb11u2
ii  gv [postscript-viewer]   1:3.7.4-2+b1
ii  mime-support 3.66
ii  mupdf [pdf-viewer]   1.17.0+ds1-2
ii  xpdf [pdf-viewer]3.04+git20210103-3

maxima-emacs suggests no packages.

-- no debconf information

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

[Dominic Hargreaves]

On Sun, Apr 10, 2022 at 07:37:05PM +0200, Helmut Grohne wrote:
> Hi Dom and gregor,
> 
> On Sun, Apr 10, 2022 at 03:06:56PM +0100, Dominic Hargreaves wrote:
> > +1 to all of this.
> 
> Thank you for your replies. They're not unexpected, but we (or at least
> I) weren't entirely sure.
> 
> > Furthermore I'm troubled that this discussion rolled on for two months
> > having dropped the perl folk, in a circular fashion. That doesn't seem
> > to be in the spirit of cooperation alluded to in
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003653#122
> 
> At that time, we (ctte) didn't really consider changing the
> /usr/bin/rename API to be a viable option, but apparently Chris did and
> that only became fully clear much later. Thus the question popped up
> now.
> 
> In any case, we now have three relevant opinions that form a
> contradiction when combined:
> 
>  * Submitter: The util-linux rename implementation should be included in
>Debian
>  * Chris: The util-linux rename should be either /usr/bin/rename or
>absent.
>  * Dom/gregor: /usr/bin/rename should be perl rename.
> 
> In all of this discussion, I think we didn't have such a clear
> understanding of the disagreement. It always looked solvable in a
> consensual way to me. That has somewhat changed now.
> 
> The next step is checking back with Chris on whether his position could
> be adjusted. I would still prefer resolving this without using special
> ctte powers.

Thanks for the clarification.

By the way, it's possible that this discussion has taken place without
reference to the original bug where these issues were discussed at length:

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

I should have provided this link back in February when we were first
asked about it; mea culpa. I hope this is helpful.

Dominic

Bug#1008573: gpg-agent -managed SSH keys stored in Yubikeys cannot be used with OpenSSH 8.9

[Vagrant Cascadian]

On 2022-04-11, Vagrant Cascadian wrote:
> On 2022-03-28, Philippe Grégoire wrote:
>> After upgrading openssh-client to 8.9p1, Yubikey-managed SSH keys
>> can no longer be used. After downgrading to 1:8.4p1-5, it works.
>> I believe this is due to recent changes in OpenSSH 8.9 regarding
>> ssh-agent communication protocol which GnuPG hasn't yet picked up,
>> but haven't found anything on GnuPG's bug tracker.
>
>> $ ssh example.com
>> sign_and_send_pubkey: signing failed for ED25519 "cardno:" from 
>> agent: agent refused operation
>> usern...@example.com's password:
>
> Same problem with Gnuk, presumably multiple or all smartcards are
> affected?

According to some folks on irc.oftc.net #debian-devel, not all
smartcards are affected, we're the lucky ones!

I am using a fairly old build of gnuk, maybe newer firmware versions
have been made compatible somehow... ?


> Although I was until today using openssh 8.9 just fine, it wasn't until
> the openssh 9.0 upgrade that it stopped working for me...

For me, downgrading to openssh 1:8.9p1-3 seems to work fine.

I've marked that version of openssh as hold for now, but that feels very
wrong. :/


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1009333: amd64-microcode: Update microcode for VCN video bug

[Tobias Koeck]

Package: amd64-microcode
Version: 3.20191218.1
Severity: normal

Dear Maintainer,

there seems to be a bug

https://www.phoronix.com/scan.php?page=news_item&px=Zen-1-To-Zen-3-2022-AMD-ucode

which AMD fixed today. I think I got the same 'hang problems'.

Any plans to implement it?

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

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

amd64-microcode depends on no packages.

Versions of packages amd64-microcode recommends:
ii  initramfs-tools  0.140

amd64-microcode suggests no packages.

-- no debconf information

Bug#998147: fonts-fork-awesome: The file icons.yml is not included in the binary package

[Nicholas D Steeves]

Oops, sorry about the leading slash.  Fixed in DELAYED 10, in my MR, and
here is the updated nmudiff.

From: Nicholas D Steeves 
Date: Mon, 11 Apr 2022 16:07:12 -0400
Subject: [PATCH 1/2] Install icons.yml, which is needed to build
 qtforkawesome.

---
 debian/changelog | 10 ++
 debian/install   |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index b4cf782..0e5afc6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+fonts-fork-awesome (1.1.5+ds1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Hannah Rittich ]
+  * Install icons.yml, which is needed to build qtforkawesome (Closes:
+#998147).
+
+ -- Nicholas D Steeves   Mon, 11 Apr 2022 16:05:39 -0400
+
 fonts-fork-awesome (1.1.5+ds1-2) unstable; urgency=medium
 
   * Build from the icons folder.
diff --git a/debian/install b/debian/install
index fe74209..c9e44fb 100644
--- a/debian/install
+++ b/debian/install
@@ -7,3 +7,5 @@ fonts/forkawesome-webfont.woff2  usr/share/fonts/woff/fork-awesome/
 less/	 usr/share/fonts-fork-awesome/
 css/	 usr/share/fonts-fork-awesome/
 scss/	 usr/share/fonts-fork-awesome/
+
+src/icons/icons.yml  usr/share/fonts-fork-awesome/
-- 
2.30.2

From: Nicholas D Steeves 
Date: Mon, 11 Apr 2022 16:46:13 -0400
Subject: [PATCH 2/2] Release 1.1.5+ds1-2.1 to unstable

---
 debian/changelog | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 0e5afc6..b117d7b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-fonts-fork-awesome (1.1.5+ds1-2.1) UNRELEASED; urgency=medium
+fonts-fork-awesome (1.1.5+ds1-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
 
@@ -6,7 +6,7 @@ fonts-fork-awesome (1.1.5+ds1-2.1) UNRELEASED; urgency=medium
   * Install icons.yml, which is needed to build qtforkawesome (Closes:
 #998147).
 
- -- Nicholas D Steeves   Mon, 11 Apr 2022 16:05:39 -0400
+ -- Nicholas D Steeves   Mon, 11 Apr 2022 16:45:34 -0400
 
 fonts-fork-awesome (1.1.5+ds1-2) unstable; urgency=medium
 
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1009334: firmware-amd-graphics: Freeze for VCN videos

[Tobias Koeck]

Package: firmware-amd-graphics
Version: 20210818-1
Severity: normal

Dear Maintainer,

I was affected by a freeze by this bug

https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-FW-Avoid-VCN-Multi-Hang

Can you add the firmware files AMD added today?

Greetings and thanks,
Tobias

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

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

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.140

-- no debconf information

Bug#1008787: (no subject)

[Thomas Ward]

Control: tags -1 pending

This will be fixed in -9 when updated packaging is uploaded.

A merge request [1] included a downgrade of the Lua module to the last 
known functional version, which solves the FTBFS problem as that version 
of the Lua module can still build on s390x due to the older liblua 
libraries still being usable for that version.  Later versions of the 
Lua module at some point as indicated earlier in this bug will need 
libluajit as that is the ONLY supported way for the Lua module in nginx 
to work; this will break s390x unless LuaJIT adds s390x support.



Thomas

[1]: https://salsa.debian.org/nginx-team/nginx/-/merge_requests/16

Bug#1009313: (no subject)

[Thomas Ward]

Can I suggest that this be rejected as it has no review from the Debian 
Maintainers Team (on git or otherwise)? (I've recently been added as a 
maintainer on the Git side of this for the Salsa repo, though not an 
uploader *yet* with my DM rights, but as we manage this on Git VCS... 
this should be a merge into the existing repo.  And as long as I get no 
objections, I'm going to be working on getting 1.18.0-9 uploaded soon 
because it fixes the pending serious FTBFS bug thanks to a merged pull 
request on Salsa which I went through, tested, and approved for the 
master branch.)


There has been zero review of any such split requests, and this really 
should go via Git and merge requests and stuff.



Question to the original poster of the RFS: *why*?  NGINX packaging has 
not yet adapted to things.



And to MIA/mentors: the package is not yet 'abandoned', I'm going to get 
mentors sponsoring until a DD adds nginx to my uploads. (see my commits 
on https://salsa.debian.org/nginx-team/nginx - i'm rapidly working on an 
RC fix for the RC bug that prevents nginx from migrating to testing as 
of now, since we have a rollback of the Lua module version now in Salsa)



Thomas

Bug#1009335: RM: python-keepkey -- RoQA; Depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: ri...@paraeasy.ch

Please remove python-keepkey. The version currently in the archive
is very old and still depends on Python 2. Removal acked by the
maintainer in #1009273

Cheers,
Moritz

Bug#1009273: Should python-keepkey be removed?

[Moritz Mühlenhoff]

Am Mon, Apr 11, 2022 at 10:50:05AM +0200 schrieb 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.

Fair enough, I've just filed a removal bug for it.

Cheers,
Moritz

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Francesco C]

Damien Le Moal wrote :

> I posted another patch which disables the read log command for the adapter
> instead of just for your disk. Can you try that one too ?

It did not work in my case ... and neither blacklisting the entire
ICH4 class of pci adapters worked.

Blacklisting components and/or adding exceptions is not a good
practice to solve problems. In my opinion in the first post when the
log says :

[  4.xx] ata1.00: Read log 0x00 page 0x00 failed  Emask 0x1

maybe indicates that it has nothing to read since it still has not any
access to disk ...

Anyway this reminds me of another kernel version starting from which
most of the x86 32 bit systems did not shutdown correctly. You could
have seen the screen becoming black , heard disks positioning their
heads and stopping but the POWER ON light or the fan still running
said the opposite.

This was true for every kernel ( debian-flavoured, vanilla , RT ...)

Then it appears a patch in the lkml :

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 7aa3dcad2175..f88bf3c77fc0 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2605,4 +2605,4 @@ static int __init cpufreq_core_init(void)
return 0;
 }
 module_param(off, int, 0444);
-core_initcall(cpufreq_core_init);
+late_initcall(cpufreq_core_init);

When applied , the systems came back to shutdown with every kernel (
vanilla , deb , RT ) but a subsequent kernel version seemed to
have restored the shutdown without the necessity of applying that
patch.

Problem solved ?

Partially , because RT kernels ( debian-flavoured RT , vanilla + RT ,
custom-RT ) still do not correctly shutdown , neither with that patch
while it was so before "they have solved the problem".

Why a RT kernel on a 2003 pentium-m machine ? Because it is able in a
non professional mode ( read : CHEAP way ) to record real time audio
at 48 kHz without crackling while a newer , 64 bit multicore and more
expensive ( but still not professional ) machine doesn't.

I am very sorry for ranting , but  thank you for your patience to read this.

Bug#1009336: grub-pc: no GRUB_DISABLE_OS_PROBER Documentation entry

[Yan Hetges]

Package: grub-pc
Version: 2.06-2
Severity: wishlist
Tags: patch

Dear Maintainer,

I just finished a fresh install (bullseye) on a thinkpad x260 that also has a 
windoze partition.

When I upgraded to sid:
[...]
Preparing to unpack .../grub-pc_2.06-2_amd64.deb ...
Unpacking grub-pc (2.06-2) over (2.04-20) ...
Preparing to unpack .../grub2-common_2.06-2_amd64.deb ...
Unpacking grub2-common (2.06-2) over (2.04-20) ...
Preparing to unpack .../grub-pc-bin_2.06-2_amd64.deb ...
Unpacking grub-pc-bin (2.06-2) over (2.04-20) ...
Preparing to unpack .../grub-common_2.06-2_amd64.deb ...
Unpacking grub-common (2.06-2) over (2.04-20) ...
Setting up grub-common (2.06-2) ...
Installing new version of config file /etc/grub.d/10_linux ...
Installing new version of config file /etc/grub.d/20_linux_xen ...
Installing new version of config file /etc/grub.d/30_os-prober ...
Installing new version of config file /etc/grub.d/30_uefi-firmware ...
Installing new version of config file /etc/grub.d/41_custom ...
Setting up grub2-common (2.06-2) ...
Setting up grub-pc-bin (2.06-2) ...
Setting up grub-pc (2.06-2) ...
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.16.0-6-amd64
Found initrd image: /boot/initrd.img-5.16.0-6-amd64
Found linux image: /boot/vmlinuz-5.10.0-13-amd64
Found initrd image: /boot/initrd.img-5.10.0-13-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
done
[...] 

The Windows 10 entry was removed.

Please consider adding something like:

# Uncomment to enable os-prober
#GRUB_DISABLE_OS_PROBER=false

to /etc/default/grub

Thank you

  --Yan



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

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

Versions of packages grub-pc depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  grub-common2.06-2
ii  grub-pc-bin2.06-2
ii  grub2-common   2.06-2
ii  ucf3.0043

grub-pc recommends no packages.

grub-pc suggests no packages.

-- debconf information:
  grub-pc/partition_description:
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/hidden_timeout: false
  grub-pc/install_devices_failed: false
  grub2/kfreebsd_cmdline:
* grub2/linux_cmdline_default: quiet
  grub-pc/install_devices_empty: false
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/chainload_from_menu.lst: true
  grub-pc/postrm_purge_boot_grub: false
* grub2/linux_cmdline:
  grub2/force_efi_extra_removable: false
  grub-pc/kopt_extracted: false
  grub-pc/timeout: 2
  grub-pc/install_devices_disks_changed:
  grub2/update_nvram: true
  grub-pc/disk_description:
* grub-pc/install_devices: /dev/disk/by-id/ata-CT240BX500SSD1_2023E401C05E

Bug#1009337: python-public: reproducible builds: ships .coverage file

[Vagrant Cascadian]

Source: python-public
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

With the update to python 3.10, the rule in debian/rules no longer
successfully removes the .coverage file, resulting in reproducibility
issues:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/python-public.html

  /usr/lib/python3.10/dist-packages/.coverage

  INSERT·INTO·meta·VALUES('when','2022-03-20·08:16:32');
  vs.
  INSERT·INTO·meta·VALUES('when','2023-04-23·16:43:09');

The attached patch updates the rule removing the .coverage file to catch
the new versioned directory, as well as hopefully future versions...


With this patch applied, python-public should build reproducibly on
tests.reproducible-builds.org again!


Thanks for maintaining python-public!


live well,
  vagrant
From 47e7a7d7d21775de2acaaef97bc808553bbecd61 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 11 Apr 2022 23:00:45 +
Subject: [PATCH] debian/rules: Update rule to remove .coverage file.

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

diff --git a/debian/rules b/debian/rules
index ffaf6c8..9431fbd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,4 +15,4 @@ override_dh_installdocs:
 	dh_installdocs build/sphinx/html
 
 execute_after_dh_python3:
-	rm -f $(CURDIR)/debian/*/usr/lib/python3/dist-packages/.coverage
+	rm -f $(CURDIR)/debian/*/usr/lib/python*/dist-packages/.coverage
-- 
2.35.1



signature.asc
Description: PGP signature

Bug#1006638: firmware-misc-nonfree: /lib/firmware/i915/adlp_dmc_ver2_12.bin missing

[Gabriel Filion]

On Tue, 01 Mar 2022 06:58:36 +0100 =?utf-8?q?Stefan_R=C3=BCcker?= 
 wrote:

root@mars:/lib/firmware/i915# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.16.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/adlp_dmc_ver2_12.bin for module
i915


I'm also seeing this warning on a lenovo x230 with: Intel Corporation 
3rd Gen Core processor Graphics Controller



It can be found here:
https://anduin.linuxfromscratch.org/sources/linux-firmware/i915/


From what I can see, upstream has merged the addition of version 2.12 
of the firmware (and later also 2.14, 2.15 and 2.16)


https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=0268c1b8a06798f5167cbef8fb16241298b3eba9

so this package would have the firmware available on the next version bump.

Bug#1009338: PowerPC and Package 'b43-fwcutter' has no installation candidate

[Jeffrey Walton]

Package: b43-fwcutter
Version: 1:019-7
X-Debbugs-CC: glaub...@physik.fu-berlin.de
Tags: sid

I am working on an old PowerMac G5 running Debian Sid. I am trying to
install firmware-b43-installer. It is having some trouble. I'm not
sure how to fix it. I'm going to report it and then ask some questions
over at the kernel's b43 mailing list
(http://lists.infradead.org/mailman/listinfo/b43-dev).

# apt-get install firmware-b43-installer
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 firmware-b43-installer : Depends: b43-fwcutter (>= 1:019-7) but it is
not installable
E: Unable to correct problems, you have held broken packages.

And then

# apt-get install b43-fwcutter
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package b43-fwcutter is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'b43-fwcutter' has no installation candidate

$ apt-cache show b43-fwcutter
N: Can't select versions from package 'b43-fwcutter' as it is purely virtual
N: No packages found

$ apt-cache search b43-fwcutter
$

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:unreleased
Codename:   sid

$ uname -a
Linux PowerMac 5.16.0-6-powerpc64 #1 SMP Debian 5.16.18-1 (2022-03-29)
ppc64 GNU/Linux

Bug#1009339: python-gitlab: reproducible builds: build year embedded in documentation

[Vagrant Cascadian]

Source: python-gitlab
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The year of the build is embedded in various documentation:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-gitlab.html

  /usr/share/doc/python-gitlab-doc/html/api/gitlab.v4.html

  2018-2023,·python-gitlab·team.
  vs.
  2018-2022,·python-gitlab·team.


The attached patch fixes this by adjusting doc/conf.py to use the
SOURCE_DATE_EPOCH environment variable to determine the date to use for
the year.


With this patch applied, python-gitlab should build reproducibly on
tests.reproducible-builds.org again!


Thanks for maintaining python-gitlab!


live well,
  vagrant
From 89eea6707eb16e4a5403419ac105f94a992abb64 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 11 Apr 2022 23:57:38 +
Subject: [PATCH] doc/conf.py: Support SOURCE_DATE_EPOCH to set year.

Without this, the documentation may contain a different copyright year
depending on when it was built.

https://reproducible-builds.org/docs/source-date-epoch/
---
 docs/conf.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/conf.py b/docs/conf.py
index 490f16f..c04d871 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -18,13 +18,14 @@ from __future__ import unicode_literals
 import os
 import sys
 from datetime import datetime
+from time import time
 
 sys.path.append("../")
 sys.path.append(os.path.dirname(__file__))
 import gitlab  # noqa: E402. Needed purely for readthedocs' build
 
 on_rtd = os.environ.get("READTHEDOCS", None) == "True"
-year = datetime.now().year
+year = datetime.utcfromtimestamp(int(os.environ.get('SOURCE_DATE_EPOCH', time(.year
 
 # If extensions (or modules to document with autodoc) are in another directory,
 # add these directories to sys.path here. If the directory is relative to the
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#541688: groff: Patch for unicode box drawing characters in groff_char

[G. Branden Robinson]

package groff groff-base
retitle 541688 groff-base: want Unicode box drawing characters in groff_char(7)
tag 541688 + patch upstream
forwarded 541688 https://savannah.gnu.org/bugs/?62296
thanks

I recommend closing this 12 year-old bug.

1. If it wants to add groff special character identifiers of the form
   "U2500" to the predefined groff glyph list, it's "wontfix".
2. If it wants to document glyphs that are not accessible via a groff
   special character identifier _apart_ from those selecting Unicode
   character by code point, it's "wontfix".
3. If it is addressing deficiencies in the erstwhile page-local `C2`
   macro used by the groff_char(7) page, it is invalid, and has been
   since since 2012.

I don't think it would benefit Debian any to deviate from upstream
practice as regards points 1 and 2.

Further details are available at the forwarded-to- URL.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1009330: pv is out of date

[Antoine Beaupré]

On 2022-04-11 19:16:41, Bjarni Ingi Gislason wrote:
> Package: pv
> Severity: wishlist
>
> Dear Maintainer,
>
>   The version of package "pv" is out of date.

You are correct in stating that (a) the package is out of date and (b)
the watch file fails to find the new release...

>   The watch file has a wrong website to search, should be
> .../programs/sources/pv...
>
>   The search for the VCS repository has a wrong website. 

... but that's not the reason. The reason is the website uses an antique
diffie-hellman key:

anarcat@angela:pkg-pv$ uscan
uscan warn: In watchfile debian/watch, reading webpage
  https://www.ivarch.com/programs/pv.shtml failed: 500 Can't connect to 
www.ivarch.com:443 (SSL connect attempt failed error:141A318A:SSL 
routines:tls_process_ske_dhe:dh key too small)

Paradoxically, disabling security on that one (ie. using HTTP) fixes the
problem. I'll warn upstream and carry on with updating to the latest for
now.

Thanks for the heads up!

-- 
Our scientific power has outrun our spiritual power. We have guided
missiles and misguided men.
- Martin Luther King, Jr.

Bug#1009330: ivarch.com using invalid DH key size

[Antoine Beaupré]

Hi Andrew,

Here is some news from the Debian package! :) I know you sometimes
follow the updates in the bugtracker so I am sorry if this is a
duplicate for you, but I wanted to let you know that our "new upstream
release" scanner has failed to find the latest and greatest pv recently.

That was filed as bug 1009330 in Debian (a copy of which follows). I
tracked down the problem to an HTTPS configuration. Both curl and Perl's
LWP fail to download the homepage to parse for new releases:

$ curl -I https://www.ivarch.com/programs/pv.shtml
curl: (35) error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small

LWP is used by uscan, the software which powers this scanner, and makes
this impossible to use.

I strongly recommend updating the diffie-hellman key in your web browser
configuration.

Failing that, I have managed to download the package over cleartext
(plain HTTP!) but I would rather avoid that if possible (although the
OpenPGP signature checks out, so the risk is small there).

Another option I considered would be to parse the GitHub releases
instead, but since the tar.gz you provide is different from the one
generated from the git-archive command, this is quite error-prone...

Thank you for maintaining pv! :)

a.

On 2022-04-11 19:16:41, Bjarni Ingi Gislason wrote:
> Package: pv
> Severity: wishlist
>
> Dear Maintainer,
>
>   The version of package "pv" is out of date.
>
>   The watch file has a wrong website to search, should be
> .../programs/sources/pv...
>
>   The search for the VCS repository has a wrong website. 

Bug#1009330: pv is out of date

[Antoine Beaupré]

clone 1009330 -1 -2
retitle -1 HTTPS error in watch file
severity -1 normal

making a new bug for the outdated release, which i'll close soon with an
upload (whoohoo!)

Bug#1009342: xfce4-panel-profiles: reproducible builds: demo tarballs include user, group and file mode of build user

[Vagrant Cascadian]

Source: xfce4-panel-profiles
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask username
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Several of the tarballs shipped in
/usr/share/xfce4-panel-profiles/layouts/ embed the username, userid,
groupname, groupid and umask of the build user:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/xfce4-panel-profiles.html

  /usr/share/xfce4-panel-profiles/layouts/Cupertino.tar.bz2

  
-rw-r--r--···0·pbuilder1··()·pbuilder1··()·4925·2021-02-21·22:44:32.00·config.txt
  vs.
  
-rw-rw-r--···0·pbuilder2··()·pbuilder2··()·4925·2021-02-21·22:44:32.00·config.txt


The attached patch fixes this by passing arguments to tar in
Makefile.in.in to ensure consistent user, group, uid, gid and file
permissions in the generated tarballs.


I have not verified that these changes work correctly in the resulting
packages, only that it builds reproducibly; please be sure to verify
before uploading.


With this patch applied, xfce4-panel-profiles should become reproducible
on tests.reproducible-builds.org!


Thanks for maintaining xfce4-panel-profiles!


live well,
  vagrant
From 8cf9f8941c20e1527ac73829687c0ea5f2f4b608 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 12 Apr 2022 01:28:32 +
Subject: [PATCH 1/3] Makefile.in.in: Pass arguments to tar to make build
 reproducible regardless of user or umask.

https://reproducible-builds.org/docs/archives/

---
 Makefile.in.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile.in.in b/Makefile.in.in
index a34e177..180da38 100644
--- a/Makefile.in.in
+++ b/Makefile.in.in
@@ -31,6 +31,8 @@ pot:
 
 ifeq ($(shell tar --help|grep -o sort=),sort=)
   TAROPTS := --sort=name --format ustar
+  TAROPTS += --owner=0 --group=0 --numeric-owner
+  TAROPTS += --mode=u=wrX,og=
 endif
 layouts:
 	cd data/layouts/cupertino; tar $(TAROPTS) -cvjf "../Cupertino.tar.bz2" *
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#192144: groff-base: eqn formats complex matrices badly on nroff devices

[G. Branden Robinson]

package groff groff-base
forwarded 192144 https://savannah.gnu.org/bugs/?62298
thanks

I've opened a ticket for this upstream.  In reproducing it, I found
diagnostics that no one ever commented on before which suggest that eqn
could be improved, even if it doesn't ultimately make the input
useful in this case (that remains to be seen).

Thanks for Colin for the simple reproducer.

Regards,
Branden


signature.asc
Description: PGP signature

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

[Miao Wang]

Hi,

Thanks for your time on this package. I fully understand splitting the source 
package is a major change on the package scheme. I intended to leave it 
UNRELEASED so it can serve as a request for comment. However, every time I 
upload an UNRELEASED package, it gets deleted automatically. As a result, I 
have to set the codename to unstable for successful uploading.

Cheers,

Miao Wang

> 2022年04月12日 04:24，Bastian Germann  写道：
> 
> Control: tags -1 moreinfo
> 
> Hi Miao,
> 
> Please do not skip a version (or leave it UNRELEASED). If this is a team 
> upload (not in changelog...) and the team has confirmed splitting the 
> package, please reference the okay statement. Else, nobody will touch this 
> massive change.
> 
> I am tagging moreinfo. When you have provided the requested info, please 
> untag.
> 
> Thanks,
> Bastian

Bug#1009343: please consider adding Boost-1.0 and Expat to /usr/share/common-licenses

[Daniel Kahn Gillmor]

Package: base-files
Severity: wishlist
Version: 12.2

Expat and Boost-1.0 are both fairly common licenses in debian.  I
believe they are both well-defined, stable, and reasonably
well-understood variants of the MIT family of licenses.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ even
explicitly recommends that software with an "MIT" license that matches
the Expat terms should instead refer to Expat.

It would seem reasonable to include both of these licenses in
/usr/share/common-licenses/ to discourage adoption of other
less-well-known variants in the MIT family.

Boost has the advantage over "Expat" of being explicitly included in the
SPDX listing with a short name of "BSL-1.0":

https://spdx.org/licenses/

while Expat doesn't get its own identifier in that list, but instead has
the discouraged "MIT".

For reference, here's Boost 1.0:


from https://www.boost.org/users/license.html and 
https://www.boost.org/LICENSE_1_0.txt

--
Boost Software License - Version 1.0 - August 17th, 2003

Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:

The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
--


And here's Expat:

  from http://www.jclark.com/xml/copying.txt

--
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
--


Thanks for maintaining base-files in debian!

   --dkg


signature.asc
Description: PGP signature

Bug#1009331: ITP: node-gitlab-favicon-overlay -- Combine images for a favicon with the help of canvas

[Yadd]

On 11/04/2022 22:47, Michael Ikwuegbu wrote:

Package: wnpp
Severity: wishlist
Owner: Michael Ikwuegbu >
X-Debbugs-CC: debian-de...@lists.debian.org 



* Package name    : node-gitlab-favicon-overlay
   Version         : 2.0.0
   Upstream Author  : GitLab Frontend Team >
* URL              : 
https://gitlab.com/gitlab-org/frontend/favicon-overlay#read 
>

* License         : Expat
   Programming Lang: JavaScript
   Description     : Combine images for a favicon with the help 
of canvas

.
  Node.js is an event-based server-side JavaScript engine.


You should provide a better description

Bug#1009344: RFP: cathy -- a xmms2 client

[программист некто]

Package: wnpp
Severity: wishlist

Package name : cathy
Version : 3.6.8-1
URL : https://github.com/grizzlysmit/cathy
License : GPL-3

An xmms2 client written in C++ version 20 it also uses fmt::format and 
Gtkmm-3.0.

Bug#1009345: bullseye-pu: package node-moment/2.29.1+ds-2+deb11u1

[Yadd]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
node-moment is vulnerable to path traversal (#1009327, CVE-2022-24785)

[ Impact ]
Medium vulnerability

[ Tests ]
No changes in test

[ Risks ]
Low risk, patch is trivial

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

[ Changes ]
Just a new check to prevent names that look like filesystem paths

Cheers,
Yadd

Bug#1009321: thunderbird: OpenPGP integration refusing BrainpoolP512r1 ECC key after 91.8 upgrade

[Carsten Schoenert]

Hello Peter,

Am 11.04.22 um 20:31 schrieb Peter Gerber:


Dear Maintainer,

After updating from 1:91.7.0-2~deb11u1 to 1:91.8.0-1~deb11u1 my PGP key
disappeared from the OpenPGP Key Manager and can no longer be imported.
I verified this on a second machine and the key was still there before
the upgrade and could also be imported properly. This changed after
upgrading.

Steps to reproduce:

1. In menu, select "Tools" → "OpenPGP Key Manager"
2. "edit" → "Import Key from URL" [1]
3. An error is shown

[1]: 
https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xe6bfd964aa7cebd360537ddb4a72372baf48dade

I suspect it's related to it being an BrainpoolP512r1 ECC key which
happens to be rather uncommon. I've not checked if any other keys are
affected.


this seems to be clearly an upstream issue and not by a Debian change 
related introduced problem. In fact the packaging of Thunderbird hasn't 
changed at all since 91.7.0.


The modifications since 91.7.0 done by MZLNA can be found here in this URL:

https://bugzilla.mozilla.org/buglist.cgi?bug_id=1634524%2C1753887%2C1713621%2C1739498%2C1752069%2C1753214%2C1750969%2C1753984%2C1754682%2C1754985%2C1761099%2C1750966%2C1758399%2C1757185%2C1751086%2C1754423%2C1754186%2C1752059%2C1753824%2C1757713%2C1752741

Could you please submit an upstream bug report and give back the URL to 
the bug report so we can link the issues together.
In my opinion it's not helpful if I would work as man in the middle, 
especially once upstream will ask some questions I can't really answering.


The issue tracker from Mozilla can be found here

https://bugzilla.mozilla.org/home

Thanks.

--
Regards
Carsten

Bug#1009118: python3-biopython: incompatible with muscle >= 5

[Andrius Merkys]

Hi Étienne,

On Sat, 9 Apr 2022 11:32:03 +0200 =?utf-8?Q?=C3=89tienne?= Mollier
 wrote:
> Control: tags -1 + confirmed
> Control: forwarded -1 https://github.com/biopython/biopython/issues/3902

Thanks for forwarding the issue upstream.

> There seems to be enough changes between the two versions that a
> rather extensive rewrite of the muscle wrapper might be needed.
> But I may miss easier approaches, we'll see what upstream will
> come up with.

If upstream wants to support both muscle 3 and muscle 5, then surely
yes. If only muscle 5 support is needed, maybe simple adjustments to
accommodate muscle's CLI changes would be enough. Nevertheless let us
wait for upstream response, there is quite some time before the bookworm
freeze.

Best,
Andrius

Bug#1009345: bullseye-pu: package node-moment/2.29.1+ds-2+deb11u1

[Yadd]

On 12/04/2022 07:42, Salvatore Bonaccorso wrote:

Hi,

On Tue, Apr 12, 2022 at 06:39:35AM +0200, Yadd wrote:

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
node-moment is vulnerable to path traversal (#1009327, CVE-2022-24785)

[ Impact ]
Medium vulnerability

[ Tests ]
No changes in test

[ Risks ]
Low risk, patch is trivial

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

[ Changes ]
Just a new check to prevent names that look like filesystem paths


Looks that the debdiff was missing to the mail.

Regards,
Salvatore


Sorry, here it is.

Cheers,
Yadddiff --git a/debian/changelog b/debian/changelog
index c94c6c1c..d0566a3b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-moment (2.29.1+ds-2+deb11u1) bullseye; urgency=medium
+
+  * Avoid loading path-looking locales from fs (Closes: #1009327,
+CVE-2022-24785)
+
+ -- Yadd   Tue, 12 Apr 2022 06:35:01 +0200
+
 node-moment (2.29.1+ds-2) unstable; urgency=medium
 
   * Install TypeScript typings more correctly.
diff --git a/debian/patches/CVE-2022-24785.patch 
b/debian/patches/CVE-2022-24785.patch
new file mode 100644
index ..84247f69
--- /dev/null
+++ b/debian/patches/CVE-2022-24785.patch
@@ -0,0 +1,33 @@
+Description: Avoid loading path-looking locales from fs
+Author: Iskren Chernev 
+Origin: upstream, https://github.com/moment/moment/commit/4211bfc8
+Bug: https://github.com/moment/moment/security/advisories/GHSA-8hfj-j24r-96c4
+Bug-Debian: https://bugs.debian.org/1009327
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-04-12
+
+--- a/src/lib/locale/locales.js
 b/src/lib/locale/locales.js
+@@ -62,6 +62,11 @@
+ return globalLocale;
+ }
+ 
++function isLocaleNameSane(name) {
++// Prevent names that look like filesystem paths, i.e contain '/' or '\'
++return name.match('^[^/]*$') != null;
++}
++
+ function loadLocale(name) {
+ var oldLocale = null,
+ aliasedRequire;
+@@ -70,7 +75,8 @@
+ locales[name] === undefined &&
+ typeof module !== 'undefined' &&
+ module &&
+-module.exports
++module.exports &&
++isLocaleNameSane(name)
+ ) {
+ try {
+ oldLocale = globalLocale._abbr;
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index ..b59ca1ed
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2022-24785.patch

Bug#1009346: conky: Please drop support for xmms2

[Arnaud Rebillout]

Source: conky
Version: 1.12.2-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

xmms2 was removed from Debian bookworm, cf.
https://bugs.debian.org/1005902.

Consequently conky was also removed from bookworm, cf.
https://tracker.debian.org/news/1315731/conky-removed-from-testing/

Please consider dropping support for xmms2, so that conky
can re-enter Debian bookworm. I opened a merge request at:
https://salsa.debian.org/debian/conky/-/merge_requests/2

Thanks,

  Arnaud

Bug#1009321: thunderbird: OpenPGP integration refusing BrainpoolP512r1 ECC key after 91.8 upgrade

[Peter Gerber]

Hello Carsten,

On 4/12/22 07:03, Carsten Schoenert wrote:
Could you please submit an upstream bug report and give back the URL to 
the bug report so we can link the issues together.
In my opinion it's not helpful if I would work as man in the middle, 
especially once upstream will ask some questions I can't really answering.


Bug filed upstream as 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009321.


Thanks for the quick response.

Regards,

Peter

Bug#1009347: xrdp: FTBFS on armhf

[Arnaud Rebillout]

Source: xrdp
Version: 0.9.17-2.1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

the latest upload of xrdp (0.9.19-1) failed on some architectures (armhf
and alpha). The issues are tests that timed out:

https://buildd.debian.org/status/fetch.php?pkg=xrdp&arch=armhf&ver=0.9.19-1&stamp=1648811785&raw=0
https://buildd.debian.org/status/fetch.php?pkg=xrdp&arch=alpha&ver=0.9.19-1&stamp=1648818829&raw=0

Upstream introduced a lot of new tests between 0.9.17 and 0.9.19, so
it's not surprising if some tests fail. Since those are only timeouts, I
propose to increase the test timeouts. I opened a merge request to this
effect: https://salsa.debian.org/debian-remote-team/xrdp/-/merge_requests/8

The issue was also discussed upstream at
https://github.com/neutrinolabs/xrdp/issues/2213.

Thanks,

  Arnaud