date:20220428


Source: vkd3d
Version: 1.1-5
Severity: serious
Control: close -1 1.2-11
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010230: nvidia-graphics-drivers-legacy-390xx: autopkgtest needs update for new version of dkms: includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch


Hi Andreas,

On 29-04-2022 02:03, Andreas Beckmann wrote:

Control: tag -1 unreproducible

I cannot reproduce that in a (qemu) chroot - the module build fine.
bluca can't reproduce it either.
AFAIK non-free packages cannot be installed in the porterbox chroots, so 
testing it on some real hardware is difficult ...


Do you think it matters that armhf is tested in lxc (like all ci.d.n 
workers) on an arm64 host with an arm64 kernel?


If you're otherwise stuck, I can temporarily give you access to our 
host, but if you know what you'd want to try out you can also just pass 
detailed instructions to me and I'll execute them in the container.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008569: unar: diff for NMU version 1.10.1-3


Dear Boyuan,

On 25-04-2022 20:44, Sudip Mukherjee wrote:

+unar (1.10.1-3) unstable; urgency=medium
+
+  * QA upload.
+  * Orphan the package (take over package maintenance) via
+ITS process. (Closes: #1008569)


I maybe wrong but I was wondering if this is correct.

Section 5.12 in Debian's Developers Reference [1] clearly says:
Note that the process is only intended for actively taking over
maintainership. Do not start a package salvaging process when you
do not intend to maintain the package for a prolonged time. If you
only want to fix certain things, but not take over the package, you
must use the NMU process, even if the package would be eligible for
salvaging.

And, in this case you salavaged the package with the intention to
orphan it not to maintain it.


Today I received the 'Work-needing packages report' [1] that notified me 
that there are three reverse dependencies of unar. Two are maintained by 
me and the a11y team (I didn't realize that when I say the message by 
Sudip). The third is maintained by you. It appears to me that you 
"salvaged" unar because of that (I could be wrong, please let me know). 
I think it would have helped (at least I would have read the message 
from Sudip with more sympathy for you) if you would have made that clear 
in your original ITS message and/or in a follow-up message to Sudip.


Do you think it would be a good idea if you co-maintain this package 
with the a11y team? That way, you don't need to take the sole ownership 
(which you apparently didn't want) but can still easily keep an eye on 
it (and continue the work to package 1.10.7).


Paul

[1] 
https://lists.debian.org/msgid-search/e1nkesg-00066x...@quantz.debian.org


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008668: bug #1008668: tomcat9: logrotated is not able to truncate catalina.out

2022-04-28 Thread Evren Yurtesen

Hi,

I am not sure if anybody received my previous e-mails as I do not see them in 
the mailing list thread. :(

>  What is the problem with logrotate? It happily rotates files owned by anyone 
> in Debian.

Because in Ubuntu rsyslog drops privileges to `syslog` user. Therefore, the log 
files generated by rsyslog are owned by the `syslog` user. But tomcat9 
logrotate configuration forces logrotate to become `tomcat` user, during 
rotation. Rsyslog fails to truncate the catalina.out file which has read/write 
permissions only for `syslog` user.

One solution would be undoing 
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/388608 at Ubuntu. But I 
do not know how to reach to correct people at Ubuntu side. I also do not think 
I could convince them that this is creating problems.

It is really sad to see that a simple problem related to a single file's 
permissions can take so long to resolve. Any help you can provide is welcome. 

Thanks,
Evren

Bug#1010110: ncbi-blast+: terminate called after throwing an instance of 'ncbi::CIO_Exception'

2022-04-28 Thread Andreas Tille

Am Thu, Apr 28, 2022 at 08:28:11PM +0200 schrieb Patrice Duroux:
> Finally I also checked with the x64-linux binary package available here:
> https://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/2.11.0/
> 
> and got the same problem that confirms that this is an upstream
> issue with this version.
> A not so stable version for the current Debian stable then. ;-)

Would it be helpful for you if we would provide version 2.12.0+ds-3 in
stable-backports?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1001639: bullseye-pu: package python-hbmqtt/0.9.6-1+deb11u1

Hi Adam,

On Tue, Mar 15, 2022 at 09:15:16PM +, Adam D. Barratt wrote:
> Please go ahead; sorry for the delay.

In the mean time, hbmqtt has been deleted from unstable as unmaintained.
As such, I now prefer spending my time on migrating stuff away from
hbmqtt and propose removing the (dysfunctional) package from stable. The
sooner we get rid of it, the fewer people will try using something that
isn't sustainable. Do you concur?

If yes, can you directly turn this bug into an appropriate RM request?

Sorry for the delay.

Helmut

Bug#1010330: gcc-12 fails to build a cross compiler: cross-fixes.diff no longer applies

Source: gcc-12
Version: 12-20220428-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

cross-fixes.diff no longer applies and that happens to break cross
compiler builds. Please find a patch attached for your convenience.

Helmut
diff --minimal -Nru gcc-12-12-20220428/debian/changelog 
gcc-12-12-20220428/debian/changelog
--- gcc-12-12-20220428/debian/changelog 2022-04-28 20:10:12.0 +0200
+++ gcc-12-12-20220428/debian/changelog 2022-04-29 06:54:13.0 +0200
@@ -1,3 +1,10 @@
+gcc-12 (12-20220428-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix application of cross-fixes.diff. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 29 Apr 2022 06:54:13 +0200
+
 gcc-12 (12-20220428-1) unstable; urgency=medium
 
   * New upstream snapshot, taken from the gcc-12 branch.
diff --minimal -Nru gcc-12-12-20220428/debian/patches/cross-fixes.diff 
gcc-12-12-20220428/debian/patches/cross-fixes.diff
--- gcc-12-12-20220428/debian/patches/cross-fixes.diff  2021-07-28 
17:26:48.0 +0200
+++ gcc-12-12-20220428/debian/patches/cross-fixes.diff  2022-04-29 
06:54:04.0 +0200
@@ -9,20 +9,16 @@
 
 --- a/src/libgcc/config/ia64/fde-glibc.c
 +++ b/src/libgcc/config/ia64/fde-glibc.c
-@@ -28,6 +28,7 @@
+@@ -28,8 +28,8 @@
  #ifndef _GNU_SOURCE
  #define _GNU_SOURCE 1
  #endif
 +#ifndef inhibit_libc
  #include "config.h"
+-ifndef inhibit_libc
  #include 
  #include 
-@@ -159,3 +160,5 @@ _Unwind_FindTableEntry (void *pc, unw_wo
- 
-   return data.ret;
- }
-+
-+#endif
+ #include 
 --- a/src/libgcc/config/ia64/unwind-ia64.c
 +++ b/src/libgcc/config/ia64/unwind-ia64.c
 @@ -26,6 +26,7 @@

Bug#1010265: [pkg-lua-devel] Bug#1010265: CVE-2022-28805

2022-04-28 Thread Sergei Golovan

found 1010265 5.4.2-1
thanks

Hi Moritz,

On Wed, Apr 27, 2022 at 2:57 PM Moritz Muehlenhoff  wrote:
>
> This was assigned CVE-2022-28805:
> https://github.com/lua/lua/commit/1f3c6f4534c6411313361697d98d1145a1f030fa
> http://lua-users.org/lists/lua-l/2022-02/msg1.html
> http://lua-users.org/lists/lua-l/2022-02/msg00070.html
>
> Can you please check whether this also affects the older Lua versions
> in the archive?

This bug is related to the  variables which have been introduced in
Lua 5.4, so it doesn't affect the earlier versions.

It does affect Lua 5.4.2 in stable though.

I'll fix it in unstable shortly. Do I need to prepare a fix for stable?

Cheers!
-- 
Sergei Golovan

Bug#1010328: mldonkey-server: Please replace mime-support with media-types in Depends

Package: mldonkey-server
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear OCaml team,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in
mldonkey-server's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#797965: ffmpeg destroys gapless playback on (at least) MP3s

2022-04-28 Thread Christoph Anton Mitterer

Control: reopen -1

Sorry... I had taken other files in my tests before, than what I've
used back then.


I dug out those now and re-checked again with them.. and while it does
work for them with Opus.. it doesn't with MP3.

So there's still something in ffmpeg, which destroys the gappless
playback, on some files at least, when these are just copied.

Cheers,
Chris.

Bug#1010327: Please replace or remove mime-support in the Recommends section of xmaxima and maxima-emacs

Source: maxima
Version: Please replace or remove mime-support in the Recommends section of 
xmaxima and maxima-emacs
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Camm,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

xmaxima and maxima-emacs recommend the mime-support package.  Can you
replace it with either media-types or mailcap according to your needs?
Alternatively, if it appears that you do not directly need the presence
of the /etc/mime.types file or the availability of the mailcap system,
you can just drop the recommends entirely.  I searched for keywords such
as mime.types and mailcap via codesearch.debian.net and could not find
evidence of use.

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010326: live-task-standard: Please replace mime-support with media-types in Depends

Package: live-task-standard
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Live Systems Maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in
live-task-standard's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010324: golang-github-google-martian-dev: Please replace mime-support with media-types in Depends

Package: golang-github-google-martian-dev
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Debian Go maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in
golang-github-google-martian-dev's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010325: golang-github-google-go-github: Please replace mime-support with media-types in Depends

Source: golang-github-google-go-github
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Debian Go maintainers,

hello again :)

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in
golang-github-google-go-github's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010323: exmh: Please replace mime-support with media-types in Depends

Package: exmh
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Alexander,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in exmh's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1010322: rust-core-arch: should this package be removed.

2022-04-28 Thread Peter Green


Package: rust-core-arch

As far as I can tell the core_arch crate on crates.io was a testing ground for 
what became
core::arch in the standard library and is now abandoned. The package relies on 
"nightly"
compiler features and has FTBFS for over a year without anyone caring enough to 
fix it.
IMO it's time for it to go.

If noone objects I will turn this bug into a removal request in a week or two.

Bug#1010230: nvidia-graphics-drivers-legacy-390xx: autopkgtest needs update for new version of dkms: includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch

2022-04-28 Thread Andreas Beckmann


Control: tag -1 unreproducible

I cannot reproduce that in a (qemu) chroot - the module build fine.
bluca can't reproduce it either.
AFAIK non-free packages cannot be installed in the porterbox chroots, so 
testing it on some real hardware is difficult ...


Andreas

Bug#1006962: nvidia-cuda-toolkit: nvcc chokes on g++ 11.2's bits/std_function.h

2022-04-28 Thread Andreas Beckmann


I'll probaby go back to gcc 10 for now ...

Bug#1010316: python-cai-doc: documentation contains error message instead of documentation

2022-04-28 Thread Vagrant Cascadian

Control: tags 1010316 +patch

On 2022-04-28, Chris Lamb wrote:
> The cli.html documentation file contains the following:
>
>   System Message: ERROR/6 
> (/build/python-cai-AL0f0J/python-cai-1.0.2/docs/cli.rst, line 4)
>
>   Command ['CAI', '--help'] failed: [Errno 2] No such file or directory: 'CAI'
>
> ... instead of, presumably, the output of calling --help. This is
> actually affecting reproducibility. I can't quite find the right
> combination of setting PYTHONPATH and PATH to get this to work,
> unfortunately...

By coincidence, I happened to be working on this about the same time,
and eventually figured out that "CAI" did not exist after dh_auto_build,
but noticed it did exist during the dh_installman phase, as it was used
with help2man to generate manpages.

Through a lot of trial and error, I eventually moved it just before
dh_installdocs and specified PATH and PYTHONPATH and it appears to
work. There may be a better place to put it, but this appears to
work. Patch attached!

I also had success with PYTHONPATH=$(CURDIR) instead of PYTHONPATH=.. if
that is somehow more ideal.

live well,
  vagrant
From 7a6e146bdf6472a17ffa8d82348f6633fc750171 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 28 Apr 2022 23:03:04 +
Subject: [PATCH] debian/rules: Move documentation building phase before
 running dh_installdocs, and specify PATH and PYTHONPATH.

The "CAI" binary is not available after dh_auto_build, so run in the
dh_installdocs target instead.

Specify PYTHONPATH=.. as sphinx is run from the docs subdir.
---
 debian/rules | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/debian/rules b/debian/rules
index 93b614c..57ded76 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,15 +10,13 @@ export https_proxy = 127.0.0.1:9
 %:
 	dh $@ --buildsystem pybuild --with python3,sphinxdoc

-override_dh_auto_build:
-	dh_auto_build
-	PYTHONPATH=. python3 -m sphinx -N -bhtml docs build/html
-	find build/html -name .doctrees | xargs --no-run-if-empty rm -rf
-
 override_dh_auto_test:
 	dh_auto_test -- --test-pytest

 override_dh_installdocs:
+	PATH=$(CURDIR)/debian/python3-cai/usr/bin:$(PATH) PYTHONPATH=.. python3 -m sphinx -N -bhtml docs build/html
+	find build/html -name .doctrees | xargs --no-run-if-empty rm -rf
+
 	dh_installdocs
 	dh_installdocs -p python-cai-doc --doc-main-package python3-cai build/html

-- 
2.36.0

signature.asc
Description: PGP signature

Bug#1010262: RFS: wifi-qr/0.2-2 -- WiFi Share and Connect with QR

2022-04-28 Thread Ko Ko Ye`

Updated

d-changelog
---
wifi-qr (0.2-2) unstable; urgency=medium

  * Package description update. (Closes: #989034)
  * QR Code File Scan
---

patch
01-QRScanFromFile
---
Description: QR Code Scan from File
 QR Code Scan from File with CLI and GUI.
 .
Forwarded: not-needed
Reviewed-By: kokoye2...@gmail.com
Last-Update: 2022-04-28
---


On Fri, Apr 29, 2022 at 2:34 AM Bastian Germann  wrote:

> In the changelog, please use some description for the package description
> change additionally to the Closes: tag.
>
> Please name the patch filename with some descriptive name, not just the
> version number which introduced it.
>
> When you have provided a version that fixes those, I am inclined to
> sponsor the package.
>


-- 

with regards *Ko Ko Ye` *


kokoye2...@gmail.com
kokoye2...@ubuntu.com

https://www.linkedin.com/in/kokoye2007
https://ubuntu-mm.net
https://kokoye2007.github.io

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

2022-04-28 Thread Francesco C

Hi ,

reverting d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in
C3 state") made kernel version 5.15.35 booting , but still not kernel
version 5.17.5 in my case.

The last one has changed behaviour : now the kernel seems to boot - at
least it is not freezing and key combination works to reboot the
machine - but it does not detect ata controller at all and after
trying without success to wait for root partition to be detected , it
finishes prompting at initramfs emergency console.

I'd like to do some more tests to be sure that it is really a kernel
boot failure and not an error I've made by messing up something else :
anyway config includes ata_generic and ata_pii modules.

Just a note about d6b88ce2eb9d : while reading the message of the
commit you can see it regards amd cpu _only_ ; it was introduced
without inserting neither a conditional check , at least !!

Bug#992415: [pkg-gnupg-maint] Bug#992415: pinentry-tty: Segfault as host is entering S3/S0ix

Control: tags 992415 + moreinfo unreproducible

Hi Andrew--

On Wed 2021-08-18 19:15:22 +0930, Andrew Savchenko wrote:
> After issuing `systemctl suspend`, pinentry segfaults with the following
> output in the dmesg:
>
> ```
> kern  :info  : [Aug18 21:14] pinentry-tty[140518]: segfault at 0 ip
> 7f395bd5a217 sp 7ffe29e70310 error 4 in
>
> libc-2.31.so[7f395bd0b000+14b000] kern  :info  : [  +0.11] Code: 89
> 23 85 c0 75 d4 e9 2b ff ff ff 0f 1f 84 00 00 00 00 00 e8 3b ad 00 00 e9
> f9 fe ff ff e8 11 94 09 00 90 41 54 55 48 89 fd 53 <8b> 07 f6 c4 20 0f
> 85 ee 00 00 00 89 c2 81 e2 00 80 00 00 0f 84 ed
> ```

I tried to replicate this under qemu on debian unstable with pinentry
1.1.0-4 and did not see the behavior you're describing.

Here's what I did:

 - launch a debian x86_64 qemu/kvm-based guest 

 - as a non-privileged user, connected to it via ssh, ran "pinentry-tty"
   -- in that console, i typed "getpin" (got a prompt "PIN: ")

 - while waiting on that prompt, as the superuser, i did "systemctl
   suspend"

 - the qemu guest froze, and from its monitor port, i ran
   "system_wakeup"

 - the system unfroze, and i was able to continue entering my PIN, and
   pinentry-tty behaved as expected.

 - there was nothing in the dmesg to indicate any problem.

Are you able to help replicate this?

--dkg


signature.asc
Description: PGP signature

Bug#1007905: transition: icu

2022-04-28 Thread Sebastian Ramacher

On 2022-04-27 15:18:16 +0300, Adrian Bunk wrote:
> On Fri, Apr 22, 2022 at 07:30:56PM +0200, Sebastian Ramacher wrote:
> > Control: tags -1 = confirmed
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/auto-icu.html
> > 
> > Hi
> > 
> > On 2022-04-13 17:24:20 +0200, László Böszörményi wrote:
> > > On Wed, Apr 13, 2022 at 2:36 PM Jeremy Bicha  
> > > wrote:
> > > > mozjs78 and mozjs91 now no longer have an ICU dependency in Unstable.
> > > >
> > > > 0ad was fixed also.
> > >  Thanks. Did the rebuild locally on i386 and amd64; started with the
> > > ICU 71.1 RC release and finished with the final release if that
> > > matters. Only used Sid versions, didn't try the ones in experimental.
> > > The following is the result.
> > > icu-le-hb is outdated, need to be removed; pyicu needs an update that
> > > I've locally. gnucash self-testing fails with its C and Golang tests.
> > > The former can be fixed by adding tzdata build dependency and not yet
> > > checked the latter.
> > > LibreOffice self-testing, especially its break iterator test fails for
> > > the Lao language. Otherwise everything was fine. But I think I might
> > > redo the rebuilds (only on amd64 now) to test everything with the
> > > final release of ICU. If that's not mandatory, I think ICU is quite OK
> > > for a transition soon.
> > 
> > Please go ahead
> 
> For the ICU transition also in experimental, please do:
> 
> # Level 1
> 
> wb nmu dino-im_0.3.0-3+handy . ANY . experimental . -m "Rebuild against 
> libicu71"
> wb nmu matrix-construct_0.6.103~dfsg1+~6.11.4-2 . amd64 . experimental . -m 
> "Rebuild against libicu71"
> wb nmu performous_1.1+git20190701.9928c27-4 . ANY . experimental . -m 
> "Rebuild against libicu71"
> wb nmu qtbase-opensource-src_5.15.3+dfsg-2 . ANY . experimental . -m "Rebuild 
> against libicu71"
> wb nmu slic3r-prusa_2.4.2~rc2+dfsg-1 . amd64 arm64 armhf i386 mips64el mipsel 
> ppc64el s390x . experimental . -m "Rebuild against libicu71"
> wb nmu tracker_3.3.0-1 . ANY . experimental . -m "Rebuild against libicu71"
> 
> # Level 2
> 
> wb nmu gazebo_11.10.2+dfsg-1 . amd64 . experimental . -m "Rebuild against 
> libicu71"
> # no packages from experimental installed during the build
> 
> wb nmu qtlocation-opensource-src_5.15.3+dfsg-3 . ANY . experimental . -m 
> "Rebuild against libicu71"
> wb dw qtlocation-opensource-src . ANY . experimental . -m "libqt5opengl5-dev 
> (>= 5.15.3+dfsg-2+b1)"
> 
> wb nmu tracker-miners_3.3.0-1 . ANY . experimental . -m "Rebuild against 
> libicu71"
> wb dw tracker-miners . ANY . experimental . -m "libtracker-sparql-3.0-dev (>= 
> 3.3.0-1+b1)"
> 
> # Level 3
> 
> wb nmu 1 qtwebengine-opensource-src_5.15.9+dfsg-1 . amd64 arm64 armhf i386 
> mips64el mipsel . experimental . -m "Rebuild against libicu71"
> wb dw qtwebengine-opensource-src . amd64 arm64 armhf i386 . experimental . -m 
> "qtbase5-dev (>= 5.15.3+dfsg-2+b1)"
> # nodejs 14 sometimes hangs on mips{,64}el
> wb gb qtwebengine-opensource-src . mipsel mips64el . experimental . 
> --extra-depends "nodejs (>= 16.14), qtbase5-dev (>= 5.15.3+dfsg-2+b1)"

Thanks, scheduled

Cheers
-- 
Sebastian Ramacher

Bug#970378: [pkg-gnupg-maint] Bug#970378: pinentry: Add pinentry-efl package

Hi Efraim--

On Tue 2020-09-15 12:17:51 +0300, Efraim Flashner wrote:
> In upstream there is now merged support for pinentry with using EFL as the
> graphical toolkit. I have been using it on my Debian machine for several
> days now and on other machines for months. The attached patch to the
> source comes straight from upstream and I put together the Debian bits
> based on the other files in the debian/ directory.

A very belated thank you for offering these changes to the debian
packaging to enable the pinentry-efl package. (in
https://bugs.debian.org/970378)

Now that pinentry-efl is actually part of upstream directly, and debian
unstable has pinentry 1.2.0, i'm looking into enabling this (when we do
eventually enable it, it'll have to go through the NEW queue because of
the additional binary package created).

You can see my merge of your patch on the debian/WIP-pinentry-efl branch
on https://salsa.debian.org/debian/pinentry.

However, i'm not prepared to release it into debian now, because it's
not behaving the way i'd expect -- i've opened
https://dev.gnupg.org/T5955 upstream to report the issue.  If you have a
chance to review that issue and give feedback (either on the upstream
bugtracker, or here in this issue), i'd appreciate any suggestions on
how to bring this up to parity with the other pinentries so we can
include it in debian.

Regards,

--dkg

signature.asc
Description: PGP signature

Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)

2022-04-28 Thread rapier


Bastian,

On 4/28/22 3:22 PM, Bastian Germann wrote:

Control: tags -1 reopen

Am 28.04.22 um 20:53 schrieb rapier:
I guess the uploads needs some processing time because I do not see a 
new version yet.


Ugh. I made a mistake because I wasn't paying attention to what I was 
doing (see the above lame excuse). I've deleted the prior package and 
have just reuploaded a new one. I'm starting to look through the 
lintian errors. As I fix those errors should I delete the prior 
package and just load a new one to avoid incrementing the version number?


You can just upload a package with the same version number without 
deleting the previous upload.
Your RFS was closed because of an automation that checks for packages' 
existence on mentors:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006287;msg=53
I am reopening this RFS. So please only remove old package versions 
after the new upload has been processed. But you can also just leave the 
old uploads; they are overridden then.


Okay, that makes a lot of sense.

Thanks for the pointers,

Chris

Bug#927747: bind9_dlz backend is entirely broken in Debian


Control: severity -1 normal

On Wed, 8 May 2019 22:35:53 +0200 "Steinar H. Gunderson"  
wrote:

On Wed, May 08, 2019 at 10:02:46PM +0200, Mathieu Parent wrote:
> Downgrading the severity as the AppArmor side is already fixed it seems in 
sid.

serious and grave are of equal severity; serious is for Policy violations
(e.g. package doesn't install), grave is for functionality issues
(e.g. program segfaults on start).


For some reason it is common to misuse severity. A "package is unusable in
almost all configurations" or at least "unusable in default configuration"
isn't always equal to "package is unusable *for me*".

In this case, if dlz_backend is broken, it does not mean samba is entirely
broken. A particular configuration of it - sure.  For one, we run a samba
AD without dlz_backend and without bind to begin with, and it works just
fine..

Thanks,

/mjt

Bug#817943: strip-nondeterminism damages .zip files with bzipped members

2022-04-28 Thread Sebastian Andrzej Siewior

On 2022-04-27 10:15:58 [-0700], Chris Lamb wrote:
> Hey Sebastian,
Hi Chris,

> > strip-nondeterminism damages .zip files with bzipped members
> 
> According to:
> 
>   
> https://github.com/redhotpenguin/perl-Archive-Zip/issues/26#issuecomment-529170764
> 
> ... this has now been fixed. Can you confirm? :)

I can confirm, yes.

> 
> Regards,

Sebastian

Bug#1010320: davix FTCBFS: unsatisfiable python3-sphinx dependency

Source: davix
Version: 0.8.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

davix fails to cross build from source, because its sphinx dependencies
are unsatisfiable. sphinx is being a little difficult here as it can be
architecture-dependent, but often isn't. However that may be, davix only
uses sphinx (and doxygen) for building its documentation, which resides
in an Arch: all package. Since cross builds generally are arch-only,
moving those dependencies to Build-Depends-Indep would easily improve
cross building. At the same time, it would speed up arch-only builds
(such as those performed on buildds). I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru davix-0.8.1/debian/changelog davix-0.8.1/debian/changelog
--- davix-0.8.1/debian/changelog2022-04-20 10:20:18.0 +0200
+++ davix-0.8.1/debian/changelog2022-04-28 20:04:23.0 +0200
@@ -1,3 +1,10 @@
+davix (0.8.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move documentation dependencies to Build-Depends-Indep. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 28 Apr 2022 20:04:23 +0200
+
 davix (0.8.1-1) unstable; urgency=medium
 
   * Update to version 0.8.1
diff --minimal -Nru davix-0.8.1/debian/control davix-0.8.1/debian/control
--- davix-0.8.1/debian/control  2021-09-28 13:01:27.0 +0200
+++ davix-0.8.1/debian/control  2022-04-28 20:04:23.0 +0200
@@ -11,12 +11,15 @@
  libgtest-dev (>= 1.8.0-7),
  libcurl4-openssl-dev,
  pkg-config,
- doxygen,
- python3-sphinx,
- python3-sphinx-rtd-theme,
+ python3:native,
  zlib1g-dev,
  uuid-dev,
  rapidjson-dev
+Build-Depends-Indep:
+ dh-sequence-sphinxdoc,
+ doxygen,
+ python3-sphinx,
+ python3-sphinx-rtd-theme,
 Standards-Version: 4.6.0
 Section: net
 Vcs-Browser: https://salsa.debian.org/ellert/davix
diff --minimal -Nru davix-0.8.1/debian/rules davix-0.8.1/debian/rules
--- davix-0.8.1/debian/rules2021-09-29 22:49:08.0 +0200
+++ davix-0.8.1/debian/rules2022-04-28 20:04:23.0 +0200
@@ -1,8 +1,10 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
+DO_PACKAGES := $(shell dh_listpackages)
+
 %:
-   dh $@ --with sphinxdoc
+   dh $@
 
 override_dh_auto_configure:
# Remove bundled stuff
@@ -17,13 +19,15 @@
ln -s /usr/include/rapidjson src/libs/rapidjson
dh_auto_configure -- -DLIB_SUFFIX:PATH="/$(DEB_HOST_MULTIARCH)" \
-DEMBEDDED_LIBCURL:BOOL=FALSE \
-   -DENABLE_HTML_DOCS:BOOL=TRUE \
+   -DENABLE_HTML_DOCS:BOOL=$(if $(filter 
davix-doc,$(DO_PACKAGES)),TRUE,FALSE) \
-DENABLE_THIRD_PARTY_COPY:BOOL=TRUE
 
 override_dh_auto_build:
dh_auto_build -- all doc
+ifneq (,$(filter davix-doc,$(DO_PACKAGES)))
( cd obj-$(DEB_HOST_GNU_TYPE)/doc ; \
  sphinx-build -q -b html ../../doc/sphinx build/html )
+endif
 
 override_dh_auto_install:
dh_auto_install

Bug#969330: libpam-ssh-agent-auth: Authentication fails a random number of times before succeeding when ED25519 keys are used.

Control: forwarded 969330 https://dev.gnupg.org/T5682
Control: close 969330 2.2.34-1

On Wed 2022-02-02 23:40:28 +, Chris Boot wrote:
> This bug actually appears to be in GnuPG itself, not 
> libpam-ssh-agent-auth. Please see my comments at the end of 
> https://github.com/jbeverly/pam_ssh_agent_auth/issues/28.
>
> The bug is fixed in GnuPG 2.3.4 and 2.2.33 with the following changelog 
> entry for both:
>
>* scd: Support longer data for ssh-agent authentication with openpgp
>  cards.  [T5682]
>
> This corresponds to the following GnuPG bug:
>
> https://dev.gnupg.org/T5682
>
> Please update GnuPG to 2.2.33 or 2.3.4.

Thanks for reporting this, Alexander, and for tracking it down, Chris.
Should be resolved with the recent uploads of 2.2.34 and 2.2.35 to
debian unstable.

   --dkg


signature.asc
Description: PGP signature

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

2022-04-28 Thread Kevin J. McCarthy


On Wed, 27 Apr 2022 15:10:09 -0700 "Kevin J. McCarthy"  wrote:
One change in 2.2.x was normalizing Maildir paths when opening them 
(as IMAP does) - removing a trailing delimiter.  This might cause the 
behavior you are describing.


Until I hear otherwise, I've been assuming the problem is because of 
this change.  Nothing of substance changed in the buffy routines that I 
can see.


I've pushed a couple possible commits up to branch 
'kevin/buffy-check-fixes' in the Mutt git repository: 
. 
The second commit is a bit more aggressive/dangerous, but may be more 
thorough at fixing other related issues.


I don't know if you've compiled Mutt from git before, but if you are 
able and willing to try, I would appreciate hearing it that helped with 
your problem.


Thank you,

-Kevin

Bug#1010309: ITP: node-ws-iconv -- A set of filesystem-related functions for NodeJS

2022-04-28 Thread Roland Mas


Le 28/04/2022 à 17:30, Yadd a écrit :

On 28/04/2022 17:07, Roland Mas wrote:


This is a set of small NodeJS packages, poorly documented [1], with
functions seemingly related to filesystem and path operations.

It is required (indirectly) by jupyterlab, via node-react-json-tree
(redux-devtools) and node-yarn-tool-resolve-package.


Hi,

how can this be a dependency as it isn't published in npmjs.org, 
neither in yarnpkg.com?


The dependency is actually on upath2, which in turn depends on 
path-is-network-drive and path-strip-sep; all three of these modules are 
part of ws-iconv, and I'm trying not to upload too many "less than 50 
lines of actual code" packages. So node-ws-iconv will provide them.


Roland.

Bug#1010262: RFS: wifi-qr/0.2-2 -- WiFi Share and Connect with QR


In the changelog, please use some description for the package description 
change additionally to the Closes: tag.

Please name the patch filename with some descriptive name, not just the version 
number which introduced it.

When you have provided a version that fixes those, I am inclined to sponsor the 
package.

Bug#1010319: RM: gnome-documents -- RoM; unmaintained

2022-04-28 Thread Jeremy Bicha

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: gnome-docume...@packages.debian.org

gnome-documents is no longer maintained upstream. It has been archived
which means GNOME is no longer accepting any code fixes, translations,
or even bug reports for it any more.

https://gitlab.gnome.org/Archive/gnome-documents

Its most recent release was in October of 2019.

Therefore, please remove gnome-documents from Debian.

Its popcorn is rather high because it was installed by default by
meta-gnome3 and task-gnome-flashback-desktop until recently, but it
wasn't a "popular" (well-loved) app. It is recommended that you use
your favorite PDF viewer instead (evince, firefox, etc.).

A fork (more or less), gnome-books, is still maintained and is a
reader for comic books and ePub books.

Thank you,
Jeremy Bicha

Bug#1009311: [pkg-gnupg-maint] Bug#1009311: dirmngr: should no longer use keys.openpgp.org by default

Control: tags 1009311 + wontfix

Hi Vincent--

On Mon 2022-04-11 16:18:45 +0200, Vincent Lefevre wrote:
> The default https://keys.openpgp.org:443 key server is no longer working:
>
> $ gpg -v --recv-keys 7CA7ECAAF06216B90F894146ACF8146CAE8CBBC4
> gpg: data source: https://keys.openpgp.org:443
> gpg: pub  rsa2048/ACF8146CAE8CBBC4 2019-01-02  
> gpg: key ACF8146CAE8CBBC4: new key but contains no user ID - skipped
> gpg: Total number processed: 1
> gpg:   w/o user IDs: 1
>
> https://superuser.com/questions/1485213/gpg-cant-import-key-new-key-but-contains-no-user-id-skipped
> says: "You are probably using the keys.openpgp.org keyserver, which
> has an owner approval system – it will strip all user IDs unless
> the owner of the corresponding email address has allowed them to be
> published. Try to download the key from elsewhere [...]"
>
> The consequence is that when I want to check a signature made with
> this key, I get:
>
> gpg: Signature made 2022-04-09T21:49:20 CEST
> gpg:using RSA key 7CA7ECAAF06216B90F894146ACF8146CAE8CBBC4
> gpg: Can't check signature: No public key

Upstream's preferred default keyserver, hkps://keyserver.ubuntu.com runs
a hockeypuck installation, which distributes arbitrarily large OpenPGP
certificates.  That keyserver is vulnerable to flooding attacks (see
https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-keystore/
for more detail)

For example, consider trying to fetch GnuPG upstream (Werner Koch)'s old
OpenPGP certificate from the upstream-preferred default keyserver:
0x80615870F5BAD690333686D0F2AD85AC1E42B367 (or try fetching my own
expired key 0xC4BC2DDB38CCE96485EBE9C2F20691179038E5C6 for that matter).
The upstream preferred keyserver will push tens of megabytes to you of
flooded key material.  Recent versions of GnuPG will discard almost all
of that data (gpg's dirmngr defaults to importing self-sigs only so that
a flooded certificate doesn't make your local keyring unusable as well),
but the transmission alone will still cost the user in terms of
bandwidth, latency, and battery life.

Anyone who wants to can flood any key on the upstream-preferred default
keyserver, just by pushing additional third-party certifications.

keys.openpgp.org is significantly more conservative: public key material
will show up there, as will revocations and subkey material.  but user
id information is only distributed if the user has responded to an
e-mail feedback request from the operators of keys.openpgp.org
confirming their intent to publish the User ID that contains that e-mail
address.

So we have two choices to compare between:

a) a default keyserver that is willing to publish any user ID
   information, but also permits arbitrarily flooded certificates.

b) a default keyserver that only publishes self-signed material, but
   won't distribute User IDs unless the e-mail account holder has
   explicitly signalled their intent to publish to that keyserver.

Given the bandwidth costs and potential for severe DoS on any user
associated with (a), (b) appears to be a more stable and responsible
default.

If another keyserver operator offers a different value proposition that
is better than either (a) or (b), i'm willing to consider it as a default
for debian.  Or, if someone else wants to take over the packaging of
GnuPG in debian, and they see the comparative advantage differently, i'd
be happy to let them make the decision.

   --dkg

signature.asc
Description: PGP signature

Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)


Control: reopen -1

Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)


Control: tags -1 reopen

Am 28.04.22 um 20:53 schrieb rapier:

I guess the uploads needs some processing time because I do not see a new 
version yet.


Ugh. I made a mistake because I wasn't paying attention to what I was doing (see the above lame excuse). I've deleted 
the prior package and have just reuploaded a new one. I'm starting to look through the lintian errors. As I fix those 
errors should I delete the prior package and just load a new one to avoid incrementing the version number?


You can just upload a package with the same version number without deleting the 
previous upload.
Your RFS was closed because of an automation that checks for packages' 
existence on mentors:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006287;msg=53
I am reopening this RFS. So please only remove old package versions after the new upload has been processed. But you can 
also just leave the old uploads; they are overridden then.

Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)

2022-04-28 Thread rapier


Bastian,

On 4/28/22 11:51 AM, Bastian Germann wrote:

Control: tags -1 - moreinfo

Am 28.04.22 um 17:38 schrieb rapier:

Control: tags - moreinfo

Bastian,

I've replaced the exitsing PPA with a new one containing a build that 
I believe addresses the problems. If you have time to review it I 
would appreciate that.


I do not get why you use the word "PPA" all the time. That is an Unbuntu 
term. Please just say mentors if you mean you uploaded to 
mentors.debian.net. If you mean something else, please hand a link to 
the dsc file.


My apologies. I work across a lot of different unix and linux 
distributions and my language gets sloppy at times.


I guess the uploads needs some processing time because I do not see a 
new version yet.


Ugh. I made a mistake because I wasn't paying attention to what I was 
doing (see the above lame excuse). I've deleted the prior package and 
have just reuploaded a new one. I'm starting to look through the lintian 
errors. As I fix those errors should I delete the prior package and just 
load a new one to avoid incrementing the version number?


Hopefully I have the right command to uuntag moreinfo. I'm referencing 
the docs at https://www.debian.org/Bugs/server-control


You were missing the bug number. In Control: stanzas you can just use -1.


Thanks, I wasn't entirely clear on that.

Chris

Bug#1010318: datalad: please make the build reproducible

Source: datalad
Version: 0.16.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
datalad could not be built reproducibly.

This is because the generated manpages include the current build date.
A patch is attached that uses SOURCE_DATE_EPOCH if it is available.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible-build.patch   2022-04-28 11:45:44.965548810 
-0700
@@ -0,0 +1,27 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2022-04-28
+
+--- datalad-0.16.1.orig/_datalad_build_support/formatters.py
 datalad-0.16.1/_datalad_build_support/formatters.py
+@@ -7,7 +7,9 @@
+ 
+ import argparse
+ import datetime
++import os
+ import re
++import time
+ from textwrap import wrap
+ 
+ 
+@@ -34,7 +36,9 @@ class ManPageFormatter(argparse.HelpForm
+ 
+ self._prog = prog
+ self._section = 1
+-self._today = datetime.date.today().strftime('%Y\\-%m\\-%d')
++self._today = datetime.datetime.utcfromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++).strftime('%Y\\-%m\\-%d')
+ self._ext_sections = ext_sections
+ self._version = version
+ 
--- a/debian/patches/series 2022-04-28 11:05:26.121641535 -0700
--- b/debian/patches/series 2022-04-28 11:45:43.945545461 -0700
@@ -2,3 +2,4 @@
 deb_setup_no_msgpack_and_duecredit
 deb_no_utf8
 python3.patch
+reproducible-build.patch

Bug#1010317: raspi-firmware: broken support for CM3 and CM4 devices

2022-04-28 Thread Cyril Brulebois

Package: raspi-firmware
Version: 1.20210303+ds-2
Severity: important

Hi,

Back when I worked on CM3 support for buster[1], the postinst script was
still deploying DTB files under the Raspberry names[2], so I didn't
spot the regression until a few months ago:

- a Pi CM3, mounted on the official Compute Module IO Board V3,
wouldn't boot at all (stuck on the rainbow);

- a Pi CM4, mounted on the official Compute Module 4 IO Board, would
boot but would believe it's a Pi 4 B; side effects would include
non-functional on-board Ethernet and on-board USB.

1.
https://debamax.com/blog/2019/09/09/adding-raspberry-pi-cm3-support-to-debian-buster/
2. https://github.com/raspberrypi/linux/

Those names are slightly different compared to what got merged into
mainline (DTS files are added there by individuals, Raspberry people
don't upstream support for their own hardware…), and the bootloader we
have in bullseye only knows about the Raspberry names for the compute
modules, not the mainline ones[3].

3. https://github.com/raspberrypi/firmware/issues/1660

Ever since we moved away from copying each file individually from the
mainline name to the Raspberry name in [4], support for compute modules
was broken. It first shipped in debian/1.20200114-2 (and only broke CM3
support at the time, CM4 hadn't been added yet).

4.
https://salsa.debian.org/debian/raspi-firmware/-/commit/165f43a6ca14d240f199e8ab8924e503ca5f427d

At some point I was hoping it might be feasible to consider backporting
the bootloader to bullseye, but it has become increasingly obvious that
the balance between bugfixes/new features and regressions isn't really
going the way we'd like. Of course, we don't have access to the source
files, and it's not even directly possible to decompile the binaries
to see what they're doing. As far as I know, one would need Ghidra plus
a pull request that hasn't been merged yet[5]. Whether this could be
used to actually patch the binaries (in a more targeted way than just
shipping some newer upstream releases wholesale), and whether this would
even be legal is anyone's guess.

5. https://github.com/NationalSecurityAgency/ghidra/pull/1147

Since the issue has been fixed upstream and released to unstable and
testing, I'd like to suggest moving to my plan B, which would be to
restore copying files under Raspberry names, but only the 2 required
ones. Of course, the partition is FAT so we can't use symlinks, so that
means wasting a little space. But that seems to outweigh the drawbacks
outlined in introduction!

Alternatively, one can force a specific device_tree via config.txt:

device_tree=bcm2837-rpi-cm3-io3.dtb # CM3
device_tree=bcm2711-rpi-cm4-io.dtb # CM4

or even try and use model filters to do that automatically:

[cm3]
device_tree=bcm2837-rpi-cm3-io3.dtb

[cm4]
device_tree=bcm2711-rpi-cm4-io.dtb

but using that would inevitably confuse users, who might need to learn
about model filters[6].

6.
https://www.raspberrypi.com/documentation/computers/config_txt.html#model-filters

I'll be working on a patch for my proposed approach (duplicating two DTB
files), combining it with a fix for #996937, and opening up a p-u
request once everything has been tested (in unstable for #996937, and in
bullseye for this issue and #996937).

Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#974972: Reopening Debian bug 974972

2022-04-28 Thread Boyuan Yang

reopen 974972
tags 972972 +sid
found 974972 1.10.1-4
thanks

With recent autopkgtest regression of unar/1.10.7+ds1-1 on armhf and s390x,
I believe more work is needed to have the new version correctly packaged in
Debian. Reopening this bug for now to provide unar/1.10.1 in Debian Testing
and Debian Sid again before further regression investigation.

Thanks,
Boyuan Yang


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

Bug#1010110: ncbi-blast+: terminate called after throwing an instance of 'ncbi::CIO_Exception'

2022-04-28 Thread Patrice Duroux

Finally I also checked with the x64-linux binary package available here:
https://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/2.11.0/

and got the same problem that confirms that this is an upstream
issue with this version.
A not so stable version for the current Debian stable then. ;-)

Thanks!

Bug#1010316: python-cai-doc: documentation contains error message instead of documentation

Package: python-cai-doc
Version: 1.0.2-2
Severity: minor
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

The cli.html documentation file contains the following:

  System Message: ERROR/6 
(/build/python-cai-AL0f0J/python-cai-1.0.2/docs/cli.rst, line 4)

  Command ['CAI', '--help'] failed: [Errno 2] No such file or directory: 'CAI'

... instead of, presumably, the output of calling --help. This is
actually affecting reproducibility. I can't quite find the right
combination of setting PYTHONPATH and PATH to get this to work,
unfortunately...


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#826241: fixed in unbound 1.5.9-2


Replying to an old bugreport which is marked as fixed since 1.5.9-2 version.

This is, in fact, a context of resolvconf, for which we have
several other bugreports.

This one has a lenghtly discussion and debugging.

But I can't understand the main thing there:  why on the Earth one
needs to reload postfix (or other similar software) due to changes
of DNS forwarders, provided there's a caching nameserver running on
127.0.0.1?

In this case, all local programs just use the default 127.0.0.1 as
nameserver and need no reload whatsoever, /etc/resolv.conf does not
change (well, unless a search path is also changing), all the
complexity is handled by the caching nameserver internally,
without clients even disconnecting.  Is it not the case?

Having said that, I'm aware of /etc/resolvconf/update.d/unbound being
disabled for quite some time (#1003135).  Maybe that's the whole
reason of all this long debugging in this bug report, and the only
thing actually needed was to enable this resolvconf integration?

This whole unbound-resolvconf.service seems to be quite messy and
it is unclear to me how it works to begin with. There are several
pieces of this puzzle.

Now we also have #1009928 which needs to be fixed but I don't
understand the machinery behind this unbound-resolvconf.service.

Also, lintian gives warnings about this:

W: unbound: systemd-service-file-refers-to-unusual-wantedby-target 
unbound.service [lib/systemd/system/unbound-resolvconf.service]
I: unbound: package-supports-alternative-init-but-no-init.d-script 
lib/systemd/system/unbound-resolvconf.service
I: unbound: systemd-service-file-missing-documentation-key 
[lib/systemd/system/unbound-resolvconf.service]

The first one is just that: it is _unusual_ to be wanted by
anything but multi-user.target or the like.

Robert, can you please give some summary of that's going on
there if you still remember the context? I'm trying to understand
the context provided in this bugreport (which lead to the
current unbound-resolvconf.service) but it is a bit difficult
to follow.

Thank you!

/mjt

Bug#743228: ifupdown: IPv6 Address doesn't get configured at/after boot

2022-04-28 Thread Jan Christoph Uhde


Hi,

I have the same problem with vlan interfaces:

```
» cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

# loopback 
auto lo
iface lo inet loopback
iface lo inet6 loopback

# physical adapter 
auto eth0
iface eth0 inet manual
iface eth0 inet6 manual


# internal ethernet (vlan) #
auto eth0.1
iface eth0.1 inet static
address 10.xx.xx.xx
netmask 255.255.255.0


#will use the requested prefix
iface eth0.1 inet6 manual


# fritx.box ethernet (vlan) 
auto eth0.2
iface eth0.2 inet static
address 192.xx.xx.xx
netmask 255.255.255.0
network 192.xx.xx.xx
broadcast 192.xx.xx.255
gateway 192.xx.xx.xx
  
iface eth0.2 inet6 auto

request_prefix 1
mtu 1492
dhcp 1
accept_ra 2
```

Can you give me some what to do to not get the link local addresses only.



Thank You

Jan

Bug#900241: no root.key provided by libunbound2


Control: tag -1 + moreinfo

So, will adding a Recommends: dns-root-data either to libunbound
or to various software packages (eg unbound-host) fix this?

I don't think adding this to libunbound is a good idea since software
using it isn't necessary being used the root key, but adding it to
the binary packages which actually uses that data seems reasonable.

How do you think?

/mjt

Bug#851809: mono: please make the output of dh_makeclilibs reproducible

Hey,

>> Interesting. I don't see this commit SHA in the cli-common.git
>> repository, nor some associated change in dh_makeclilibs under a
>> different SHA.
>
> https://salsa.debian.org/dotnet-team/mono/-/commit/84aa977e3d2275a8cc43e21398dc90d01fb21b04
>
> Was this functionality moved to cli-common somehow?

Ah yes, or the issue is the other way around — the dh_makeclilibs in
the Mono repository (linked by you above) could originally have been a
code copy of the version in cli-common and has now diverged. The
history of the version in the Mono repository suggests this
interpretation, or the use of "re-synced" suggests that direction
anyway:

  
https://salsa.debian.org/dotnet-team/mono/-/commits/master/debian/dh_makeclilibs

The underlying direction doesn't really matter to me though, as the
version in cli-common does not sort. :)

>>   -open(FIND, "find $tmp -type f \\( -name '*.dll' \\) $exclude |");
>>   +open(FIND, "find $tmp -type f \\( -name '*.dll' \\) $exclude | 
>> sort |");

> I wonder if you wouldn't also want to specify the locale to sort here?

Ah, of course! More importantly, though, the change should be the same
in both versions, so I'd be minded to go with the explicit complex_doit
call. Hah, I think my "if it helps" extra patch didn't actually "help"
at all.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#1010315: mark latex2html Multi-Arch: foreign

Package: latex2html
Version: 2022-debian1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:cddlib src:chktex src:coinor-symphony src:condor 
src:espresso src:flann src:freefem src:gm-assistant src:pasdoc src:systemtap

The affected packages cannot satisfy their cross Build-Depends, because
their dependency on latex2html is not satisfiable. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign or annotated :native. In this case, the
foreign marking is more appropriate as latex2html exclusively deals with
architecture-independent file formats. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru latex2html-2022-debian1/debian/changelog 
latex2html-2022-debian1/debian/changelog
--- latex2html-2022-debian1/debian/changelog2022-03-11 14:08:12.0 
+0100
+++ latex2html-2022-debian1/debian/changelog2022-04-28 18:11:01.0 
+0200
@@ -1,3 +1,10 @@
+latex2html (2022-debian1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark latex2html Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 28 Apr 2022 18:11:01 +0200
+
 latex2html (2022-debian1-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru latex2html-2022-debian1/debian/control 
latex2html-2022-debian1/debian/control
--- latex2html-2022-debian1/debian/control  2022-03-11 14:08:12.0 
+0100
+++ latex2html-2022-debian1/debian/control  2022-04-28 18:10:57.0 
+0200
@@ -22,6 +22,7 @@
 
 Package: latex2html
 Architecture: all
+Multi-Arch: foreign
 Depends: ghostscript-x,
  netpbm,
  perl,

Bug#1000837: krb5: differing build paths trigger different documentation

Hey folks,

> I've looked over your report and baffling patch.
> This is really strange, and I don't have much to add.
>
> It seems like it might be related to the pathsubst rules in
> src/doc/Makefile.in.
> But I don't see the build directory getting used there.

Oh ho ho, this is fun! So, curiously, I can't reproduce this outside of
reprotest (with a build path variation). 

Hm yes I don't immediately see how the pathsubst rules might be doing
this in practice either. Another interesting candidate might be the
doxy.py apparatus:

  103 # Use doxygen to generate API documentation, translate it into RST
  104 # format, and then create a composite of $(docsrc)'s RST and the
  105 # generated files in rst_composite.  Used by the html and substhtml 
targets.
  106 composite: Doxyfile $(docsrc)/version.py
  107 rm -rf doxy rst_apiref rst_composite
  108 $(DOXYGEN)
  109 (cwd=`pwd`; cd $(docsrc)/tools && \
  110 $(PYTHON) doxy.py -i $$cwd/doxy/xml -o $$cwd/rst_apiref)

It is of course feasible that this parser (or one of its dependencies)
has a bug.

Two other drive-thru suggestions:

 * configgen.py has a bunch of global search-replaces that might be
   misfiring. There's also a potentially suspicious newline snarfing
   code that could conceivably be buggy as well:

# replace \ by \\, replace " by \", and '  ' by a newline with end string
# and start string at next line
docC = []
for line in split_doc:
  if (line.strip() != ""):
docC.append(line.strip().replace('\\', '').
replace('"', '\\"').replace("", ""))

 * Memory corruption due to undefined behaviour somewhere in some
   parser. (Sam, we often call this a "docbook-to-man issue", not
   because the problem lies there, but due to the classic/notorious
   reproducible bug #842635 in that package.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1010314: ca-certificates: Executable search ordering for OpenSSL?

2022-04-28 Thread S. Egbert

Package: ca-certificates
Version: 20210119
Severity: normal
X-Debbugs-Cc: s.egb...@sbcglobal.net

Dear Maintainer,

A group of auditors were reviewing the CA inclusion process
and have examined the `update-ca-certificates` and its code.

This issue is not about the PKI nor its certificate handling.

One auditor noticed that the ordering of looking for OpenSSL
executable file (`openssl`) seems ... counterintuitive?

I would imagine that the correct ordering for searching this `openssl`
executable file be something like:

1.  /usr/local/sbin/openssl
2.  /usr/local/bin/openssl
3.  /usr/sbin/openssl
4.  /usr/bin/openssl


The actually and current order by the latest `update-ca-certificates`
in looking for this `openssl` exectuable is currently:

1.  $CWD/openssl 
2.  /usr/local/bin/openssl
3.  /usr/local/sbin/openssl
4.  /usr/bin/openssl
5.  /usr/sbin/openssl

Please note the inversal of `sbin` and `bin`.  (The ordering of
`/usr`/`/usr/local` complies with FSSTD v2.3).

ANALYSIS

If a single-user binary (such as `openssl`) is the official and resides
within the `sbin` as a single-user file, why is `update-ca-certificates` 
looking to 
circumvent this official binary with something outside of `sbin`?

Please note that I did not say 'system binary' here that is often
mistaken for `sbin`.

In these transitory age (of Fedora squeezing `/sbin` into `/usr/bin`)
why would an auditor want to use the `bin` firstly before the `sbin`
for finding the 'official' executable?

What gain of system integrity can be had by evoking the non-single-user
`bin`-variant before the single-user `sbin`-variant?


AUDITOR ALERT: As an unrelated note but for auditors especially in area
of CA certificates, auditors should be forewarned that the 
current (`$CWD`) directory should be empty before conducting their 
examination effort using `openssl` 
executable by others (most notably and currently the `update-ca-certificates`).


Of course, I am not the UNIX expert here but merely a multi-decade 
user of UNIX.  This bug report is merely to point out if this 
inversal of `sbin`/`bin` executable lookup is
the standard expected way of doing searches for a specific executable file.


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

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

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  openssl1.1.1n-0+deb11u1

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information:
  ca-certificates/trust_new_crts: yes
  ca-certificates/title:
  ca-certificates/new_crts:
  ca-certificates/enable_crts: mozilla/ACCVRAIZ1.crt, 
mozilla/AC_RAIZ_FNMT-RCM.crt, mozilla/Actalis_Authentication_Root_CA.crt, 
mozilla/AffirmTrust_Commercial.crt, mozilla/AffirmTrust_Networking.crt, 
mozilla/AffirmTrust_Premium.crt, mozilla/AffirmTrust_Premium_ECC.crt, 
mozilla/Amazon_Root_CA_1.crt, mozilla/Amazon_Root_CA_2.crt, 
mozilla/Amazon_Root_CA_3.crt, mozilla/Amazon_Root_CA_4.crt, 
mozilla/Atos_TrustedRoot_2011.crt, 
mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, 
mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_Root_CA.crt, 
mozilla/Buypass_Class_3_Root_CA.crt, mozilla/CA_Disig_Root_R2.crt, 
mozilla/Certigna.crt, mozilla/Certigna_Root_CA.crt, 
mozilla/certSIGN_ROOT_CA.crt, mozilla/certSIGN_Root_CA_G2.crt, 
mozilla/Certum_Trusted_Network_CA_2.crt, mozilla/Certum_Trusted_Network_CA.crt, 
mozilla/CFCA_EV_ROOT.crt, mozilla/Chambers_of_Commerce_Root_-_2008.crt, 
mozilla/Comodo_AAA_Services_root.crt, 
mozilla/COMODO_Certification_Authority.crt, 
mozilla/COMODO_ECC_Certification_Authority.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/Cybertrust_Global_Root.crt, mozilla/DigiCert_Assured_ID_Root_CA.crt, 
mozilla/DigiCert_Assured_ID_Root_G2.crt, 
mozilla/DigiCert_Assured_ID_Root_G3.crt, mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_Global_Root_G2.crt, mozilla/DigiCert_Global_Root_G3.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, 
mozilla/DigiCert_Trusted_Root_G4.crt, mozilla/DST_Root_CA_X3.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_2009.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_EV_2009.crt, mozilla/EC-ACC.crt, 
mozilla/emSign_ECC_Root_CA_-_C3.crt, mozilla/emSign_ECC_Root_CA_-_G3.crt, 
mozilla/emSign_Root_CA_-_C1.crt, mozilla/emSign_Root_CA_-_G1.crt, 
mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, 
mozilla/Entrust_Root_Certification_Authority.crt, 
mozilla/Entrust_Root_Certification_Authority_-_EC1.crt, 
mozilla/Entrust_Root_Certification_A

Bug#851809: mono: please make the output of dh_makeclilibs reproducible

2022-04-28 Thread Vagrant Cascadian

On 2022-04-28, Chris Lamb wrote:
>> Version: 4.6.2.7+dfsg-2
>>
>> It looks like this was fixed some time ago:
>>
>>   84aa977e3d2275a8cc43e21398dc90d01fb21b04
>>   Sort dh_makeclilibs output so it's deterministic. Thanks to Chris Lamb
>
> Interesting. I don't see this commit SHA in the cli-common.git
> repository, nor some associated change in dh_makeclilibs under a
> different SHA.

https://salsa.debian.org/dotnet-team/mono/-/commit/84aa977e3d2275a8cc43e21398dc90d01fb21b04

Was this functionality moved to cli-common somehow?


> But whatever the historical Git archaeology, the bug is still
> affecting packages — de4dot, for example.

Looking at the history of de4dot, it seems consistantly reproducible on
amd64 and arm64, but consistantly unreproducible on i386 and armhf:

  https://tests.reproducible-builds.org/debian/history/amd64/de4dot.html
  https://tests.reproducible-builds.org/debian/history/i386/de4dot.html

So the obvious difference here is 32-bit vs. 64-bit... a non-obvious
difference is choice of locale for each architecture for
tests.reproducible-builds.org infrastructure differs.

Looking at the history for the originally referenced gtk-sharp-beans is
a little less consistant, but still more frequently unreproducible on
i386/armhf:

  
https://tests.reproducible-builds.org/debian/history/amd64/gtk-sharp-beans.html
  https://tests.reproducible-builds.org/debian/history/i386/gtk-sharp-beans.html


> Hope we can get this resolved soon. If it helps, a simpler patch might
> even be:
>
>   @@ -187,7 +187,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
>if (defined($dh{EXCLUDE_FIND}) && $dh{EXCLUDE_FIND} ne '') {
>$exclude = "! \\( $dh{EXCLUDE_FIND} \\) ";
>}
>   -open(FIND, "find $tmp -type f \\( -name '*.dll' \\) $exclude |");
>   +open(FIND, "find $tmp -type f \\( -name '*.dll' \\) $exclude | 
> sort |");
>
>dll:
>while () {


I wonder if you wouldn't also want to specify the locale to sort here?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#862207: error: libcrypto does not provide GOST


28.04.2022 19:22, Ondřej Surý wrote:

On 28. 4. 2022, at 15:23, Michael Tokarev  wrote:

Yeah. Formally we should do either one or another.
In practice I *highly* doubt anyone is using these 4
symbols, so maybe we can just disable the thing without
doing anything. I'm too lazy now to provide the stubs :)


Yeah, I concur.

I would recommend doing such upload to experimental first and
then we can add couple of versioned Breaks if we find any problems.


I see no reason to go to experimental here. I checked all rdepends
of libldns3, - none are using any gost symbols.  -exp wont do
anything useful there I think.

It is not the first time I see people suggesting uploading stuff
in experimental. Sometimes I do that too (not counting the case
like we had with the python transition, and a risk to delay the
transition further in case of a problematic upload to unstable) -
when I'm not sure if the changes I did are okay and I want to give
it some wider testing and when I *know* someone can help me by
explicitly install the experimental stuff.

But for things like this, I *think* -exp is useless, it wont show
anything which we don't know already.

Did I miss something?

Thank you!

/mjt

Bug#862207: error: libcrypto does not provide GOST

2022-04-28 Thread Ondřej Surý


> On 28. 4. 2022, at 18:34, Michael Tokarev  wrote:
> 
> I see no reason to go to experimental here. I checked all rdepends
> of libldns3, - none are using any gost symbols. -exp wont do
> anything useful there I think.

Ok, then.

> But for things like this, I *think* -exp is useless, it wont show
> anything which we don't know already.

It’s just easier to test this “in place”, that’s all.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org



signature.asc
Description: Message signed with OpenPGP

Bug#1010313: python3-stem: Fix for Python 3.10

2022-04-28 Thread ju xor


Package: python3-stem
X-Debbugs-Cc: j...@riseup.net
Version: 1.8.0-3
Severity: normal

Dear Maintainer,

attached you can find a patch to fix a bug with Python 3.10, which is 
now the default in unstable and testing.


Thanks!,

juxorFrom 8da5611471c2dfbfd93e93a0113e8276914a16a9 Mon Sep 17 00:00:00 2001
From: juxor 
Date: Thu, 28 Apr 2022 16:10:46 +
Subject: [PATCH] d/patches: Fix for Python 3.10

---
 debian/patches/fix-python3.10.patch | 14 ++
 debian/patches/series   |  1 +
 2 files changed, 15 insertions(+)
 create mode 100644 debian/patches/fix-python3.10.patch

diff --git a/debian/patches/fix-python3.10.patch b/debian/patches/fix-python3.10.patch
new file mode 100644
index 000..95cf653
--- /dev/null
+++ b/debian/patches/fix-python3.10.patch
@@ -0,0 +1,14 @@
+Description: Fix for Python 3.10
+Author: ju xor 
+Last-Update: 2022-04-28
+--- a/stem/control.py
 b/stem/control.py
+@@ -2532,7 +2532,7 @@
+ for param, value in params:
+   if isinstance(value, str):
+ query_comp.append('%s="%s"' % (param, value.strip()))
+-  elif isinstance(value, collections.Iterable):
++  elif isinstance(value, collections.abc.Iterable):
+ query_comp.extend(['%s="%s"' % (param, val.strip()) for val in value])
+   elif not value:
+ query_comp.append(param)
diff --git a/debian/patches/series b/debian/patches/series
index 55077d0..bb84a5f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 reproducible-build.patch
+fix-python3.10.patch
-- 
2.30.2

Bug#862207: error: libcrypto does not provide GOST

2022-04-28 Thread Ondřej Surý

> On 28. 4. 2022, at 15:23, Michael Tokarev  wrote:
> 
> Yeah. Formally we should do either one or another.
> In practice I *highly* doubt anyone is using these 4
> symbols, so maybe we can just disable the thing without
> doing anything. I'm too lazy now to provide the stubs :)

Yeah, I concur.

I would recommend doing such upload to experimental first and
then we can add couple of versioned Breaks if we find any problems.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org



signature.asc
Description: Message signed with OpenPGP

Bug#1010312: conky FTCBFS: toluapp not found

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

conky fails to cross build from source, because it does not find
toluapp. What's happening here is actually a little more involved.
toluapp is actually vendored. It is packaged spearately as
libtolua++5.1-dev albeit for a different (deprecated) lua version. If
conky were using the packaged tolua++ instead of vendoring it, this bug
would fully go away (while leaving #1010294, but that's not your issue).
Unfortunately, tolua++ would have to be upgraded from 5.1 to 5.3 first.
I'm not sure whether that's going to happen. In any case, please do one
of the following:
 * Use a separately packaged tolua++
 * Register your vendored tolua++ with the security tracker at
   
https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies

Now, I'm going to assume that you register your copy. If you want to
remove the copy, please close this bug with the removal and stop reading
here.

Now conky uses cmake as a build system and cmake is notoriously bad at
distinguishing "build architecture" from "host architecture". Basically,
if you want to build a build tool like tolua++, you need to run cmake
twice somehow (e.g. via an ExternalProject). That doesn't happen here
and it is non-trivial to do. As a consequence, cmake does not consider
the built toluapp relevant and searches for one in $PATH instead where
none is found. Therefore, I'm proposing to extend $PATH with a directory
that contains a separately built toluapp. In essence, that's what the
attached patch does. Please consider applying it. Note that once you do,
conky will continue to fail cross builds until we also fix #1006570, but
again, that's not your issue.

Helmut
diff --minimal -Nru conky-1.12.2/debian/changelog conky-1.12.2/debian/changelog
--- conky-1.12.2/debian/changelog   2022-04-15 11:06:37.0 +0200
+++ conky-1.12.2/debian/changelog   2022-04-28 07:19:04.0 +0200
@@ -1,3 +1,11 @@
+conky (1.12.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Separately build toluapp for the build architecture.
+(Closes: #-1)
+
+ -- Helmut Grohne   Thu, 28 Apr 2022 07:19:04 +0200
+
 conky (1.12.2-2) unstable; urgency=medium
 
   [ Arnaud Rebillout ]
diff --minimal -Nru conky-1.12.2/debian/control conky-1.12.2/debian/control
--- conky-1.12.2/debian/control 2022-04-15 10:58:58.0 +0200
+++ conky-1.12.2/debian/control 2022-04-28 07:19:04.0 +0200
@@ -23,6 +23,7 @@
  libiw-dev [linux-any],
  libkvm-dev [kfreebsd-any],
  liblua5.3-dev,
+ liblua5.3-dev:native,
  libncurses5-dev,
  libpulse-dev,
  librsvg2-dev,
diff --minimal -Nru conky-1.12.2/debian/rules conky-1.12.2/debian/rules
--- conky-1.12.2/debian/rules   2022-04-15 10:58:58.0 +0200
+++ conky-1.12.2/debian/rules   2022-04-28 07:19:04.0 +0200
@@ -6,8 +6,8 @@
 DEB_CPPFLAGS?= $(shell dpkg-buildflags --get CPPFLAGS)
 DEB_CXXFLAGS?= $(shell dpkg-buildflags --get CXXFLAGS)
 
-DEB_HOST_ARCH_OS?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
-DEB_HOST_ARCH   ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
+include /usr/share/dpkg/architecture.mk
+include /usr/share/dpkg/buildtools.mk
 
 COMMON_CONF_ARGS=-DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DCMAKE_INSTALL_PREFIX=/usr \
@@ -32,11 +32,15 @@
 endif
 endif
 
+ifneq ($(DEB_HOST_ARCH),$(DEB_BUILD_ARCH))
+export PATH:=$(CURDIR)/debian/bin:$(PATH)
+endif
+
 %:
dh $@ --buildsystem=cmake
 
 override_dh_auto_clean:
-   rm -rf $(CURDIR)/README $(CURDIR)/doc/*.html $(CURDIR)/doc/*.1
+   rm -rf $(CURDIR)/README $(CURDIR)/doc/*.html $(CURDIR)/doc/*.1 
$(CURDIR)/debian/bin
dh_auto_clean --builddirectory build-std
dh_auto_clean --builddirectory build-cli
dh_auto_clean --builddirectory build-all
@@ -71,7 +75,11 @@
-DBUILD_WEATHER_XOAP=ON \
-DBUILD_XDBE=ON
 
-override_dh_auto_build:
+debian/bin/toluapp: 3rdparty/toluapp/src/bin/toluabind.c 
3rdparty/toluapp/src/bin/tolua.c $(wildcard 3rdparty/toluapp/src/lib/*.c)
+   mkdir -p debian/bin
+   $(CC_FOR_BUILD) -I3rdparty/toluapp/include -o $@ $^ 
`$(PKG_CONFIG_FOR_BUILD) --cflags --libs lua-5.3`
+
+override_dh_auto_build: $(if $(filter 
$(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)),,debian/bin/toluapp)
dh_auto_build --builddirectory build-std
dh_auto_build --builddirectory build-cli
dh_auto_build --builddirectory build-all

Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)


Control: tags -1 - moreinfo

Am 28.04.22 um 17:38 schrieb rapier:

Control: tags - moreinfo

Bastian,

I've replaced the exitsing PPA with a new one containing a build that I believe addresses the problems. If you have time 
to review it I would appreciate that.


I do not get why you use the word "PPA" all the time. That is an Unbuntu term. Please just say mentors if you mean you 
uploaded to mentors.debian.net. If you mean something else, please hand a link to the dsc file.


I guess the uploads needs some processing time because I do not see a new 
version yet.

Hopefully I have the right command to uuntag moreinfo. I'm referencing the docs at 
https://www.debian.org/Bugs/server-control


You were missing the bug number. In Control: stanzas you can just use -1.

Bug#851809: mono: please make the output of dh_makeclilibs reproducible

reopen 851809
thanks

Hi Vagrant,

> Version: 4.6.2.7+dfsg-2
>
> It looks like this was fixed some time ago:
>
>   84aa977e3d2275a8cc43e21398dc90d01fb21b04
>   Sort dh_makeclilibs output so it's deterministic. Thanks to Chris Lamb

Interesting. I don't see this commit SHA in the cli-common.git
repository, nor some associated change in dh_makeclilibs under a
different SHA.

But whatever the historical Git archaeology, the bug is still
affecting packages — de4dot, for example.

Hope we can get this resolved soon. If it helps, a simpler patch might
even be:

  @@ -187,7 +187,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
   if (defined($dh{EXCLUDE_FIND}) && $dh{EXCLUDE_FIND} ne '') {
   $exclude = "! \\( $dh{EXCLUDE_FIND} \\) ";
   }
  -open(FIND, "find $tmp -type f \\( -name '*.dll' \\) $exclude |");
  +open(FIND, "find $tmp -type f \\( -name '*.dll' \\) $exclude | sort 
|");
   
   dll:
   while () {


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)

2022-04-28 Thread rapier


Control: tags - moreinfo

Bastian,

I've replaced the exitsing PPA with a new one containing a build that I 
believe addresses the problems. If you have time to review it I would 
appreciate that.


Hopefully I have the right command to uuntag moreinfo. I'm referencing 
the docs at https://www.debian.org/Bugs/server-control


Chris

On 4/26/22 3:17 PM, Bastian Germann wrote:

Am 26.04.22 um 21:04 schrieb rapier:

Bastian,

On 4/26/22 2:17 PM, Bastian Germann wrote:

Control: tags -1 moreinfo

On Tue, 22 Feb 2022 15:24:48 -0500 rapier  wrote:

Changes for the initial release:

  hpnssh (1:8.8p1-hpn16v1-9) sid; urgency=medium
  .
    * Updated copyright.


Please replace your massive changelog just with one entry that closes 
your ITP.

The Debian revision has to be -1 and the epoch (1:) has to be removed.
Please target "unstable". When you have provided a new revision, 
please untag moreinfo.



This is my first submission to Debian so I apologize for the stupid 
questions. When you say the Debian revision needs to be -1 do you mean 
making the 1:8.8p1-hpn16v1-9 into 8.8p1-hpn16v1-1 or something else? 
Would that take care of the epoch as well?


That version number is fine if the upstream version 8.8p1-hpn16v1 exists 
(I did not check for it).

Epoch and revision are okay with 8.8p1-hpn16v1-1.

Also, what should be in the changelog? Just an update that says 
closing the ITP?


I apologize if this is documented somewhere. I've spent time looking 
for a submission guide but I couldn't find one that seemed up to date.


https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#changelog

The New Maintainer's Guide is generally a good read.

Bug#1010309: ITP: node-ws-iconv -- A set of filesystem-related functions for NodeJS

2022-04-28 Thread Yadd


On 28/04/2022 17:07, Roland Mas wrote:

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

* Package name: node-ws-iconv
   Version : 0.0~git20220306210217.c039e94 (from Git)
   Upstream Author : "bluelovers" (https://github.com/bluelovers)
* URL : https://github.com/bluelovers/ws-iconv
* License : MIT/ISC/BSD-3-Clause
   Programming Lang: Javascript/Typescript
   Description : A set of filesystem-related functions for NodeJS

This is a set of small NodeJS packages, poorly documented [1], with
functions seemingly related to filesystem and path operations.

It is required (indirectly) by jupyterlab, via node-react-json-tree
(redux-devtools) and node-yarn-tool-resolve-package.

It will be maintained under the js-team umbrella.

[1] No author name, README files are boilerplate-only, git commit logs
are mostly ".", and changelog files are generated from these commit
logs so they also lack useful information.


Hi,

how can this be a dependency as it isn't published in npmjs.org, neither 
in yarnpkg.com?

Bug#1010311: python-duniterpy breaks silkaj autopkgtest: cannot import name 'BlockUID' from 'duniterpy.documents'


Source: python-duniterpy, silkaj
Control: found -1 python-duniterpy/1.1.0-2
Control: found -1 silkaj/0.9.0-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
python-duniterpy   from testing1.1.0-2
silkaj from testing0.9.0-4
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python-duniterpy 
to testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/s/silkaj/21208153/log.gz


#   Failed test 'Check return from 'silkaj' is 0'
#   at debian/tests/silkaj.t line 9.
#  got: '1'
# expected: '0'

#   Failed test 'bare command, stdout'
#   at debian/tests/silkaj.t line 10.
#   ''
# doesn't match '(?^:^Usage: silkaj)'

#   Failed test 'bare command, stderr'
#   at debian/tests/silkaj.t line 11.
#  got: 'Traceback (most recent call last):
#   File "/usr/bin/silkaj", line 5, in 
# from silkaj.cli import cli
#   File "/usr/lib/python3/dist-packages/silkaj/cli.py", line 23, in 


# from silkaj.tx import send_transaction
#   File "/usr/lib/python3/dist-packages/silkaj/tx.py", line 40, in 
# from duniterpy.documents import BlockUID, Transaction
# ImportError: cannot import name 'BlockUID' from 'duniterpy.documents' 
(/usr/lib/python3/dist-packages/duniterpy/documents/__init__.py)

# '
# expected: ''

#   Failed test 'Check return from 'silkaj --version' is 0'
#   at debian/tests/silkaj.t line 13.
#  got: '1'
# expected: '0'

#   Failed test 'version, stdout'
#   at debian/tests/silkaj.t line 14.
#   ''
# doesn't match '(?^:^silkaj, version)'

#   Failed test 'version, stderr'
#   at debian/tests/silkaj.t line 15.
#  got: 'Traceback (most recent call last):
#   File "/usr/bin/silkaj", line 5, in 
# from silkaj.cli import cli
#   File "/usr/lib/python3/dist-packages/silkaj/cli.py", line 23, in 


# from silkaj.tx import send_transaction
#   File "/usr/lib/python3/dist-packages/silkaj/tx.py", line 40, in 
# from duniterpy.documents import BlockUID, Transaction
# ImportError: cannot import name 'BlockUID' from 'duniterpy.documents' 
(/usr/lib/python3/dist-packages/duniterpy/documents/__init__.py)

# '
# expected: ''

#   Failed test 'Check return from 'silkaj --help' is 0'
#   at debian/tests/silkaj.t line 17.
#  got: '1'
# expected: '0'

#   Failed test 'help, stdout'
#   at debian/tests/silkaj.t line 18.
#   ''
# doesn't match '(?^:^Usage: silkaj)'

#   Failed test 'help, stderr'
#   at debian/tests/silkaj.t line 19.
#  got: 'Traceback (most recent call last):
#   File "/usr/bin/silkaj", line 5, in 
# from silkaj.cli import cli
#   File "/usr/lib/python3/dist-packages/silkaj/cli.py", line 23, in 


# from silkaj.tx import send_transaction
#   File "/usr/lib/python3/dist-packages/silkaj/tx.py", line 40, in 
# from duniterpy.documents import BlockUID, Transaction
# ImportError: cannot import name 'BlockUID' from 'duniterpy.documents' 
(/usr/lib/python3/dist-packages/duniterpy/documents/__init__.py)

# '
# expected: ''

#   Failed test 'Check return from 'silkaj about' is 0'
#   at debian/tests/silkaj.t line 21.
#  got: '1'
# expected: '0'

#   Failed test 'about, stdout'
#   at debian/tests/silkaj.t line 22.
#   ''
# doesn't match '(?^:\bRepository:)'

#   Failed test 'about, stderr'
#   at debian/tests/silkaj.t line 23.
#  got: 'Traceback (most recent call last):
#   File "/usr/bin/silkaj", line 5, in 
# from silkaj.cli import cli
#   File "/usr/lib/python3/dist-packages/silkaj/cli.py", line 23, in 


# from silkaj.tx import send_transaction
#   File "/usr/lib/python3/dist-packages/silkaj/tx.py", line 40, in 
# from duniterpy.documents import BlockUID, Transaction
# ImportError: cannot import name 'BlockUID' from 'duniterpy.documents' 
(/usr/lib/python3/dist-packages/duniterpy/documents/__init__.py)

# '
# expected: ''
# Looks like you failed 12 tests of 20.
debian/tests/silkaj.t .. Dubious, test returned 12 (wstat 3072, 0xc00)
Failed 12/20 subtests
Test Summary Report
---
debian/tests/silkaj.t (Ws

Bug#1004837: XFCE Window Buttons not visible after Debian upgrade

2022-04-28 Thread Tomas Tintera

Hi,

Apologies, the debdiff I just sent have wrong date info in a patch tag.
The patch currently attached should be ok.

With regards,
Tomas "trosos" Tinteradiff -Nru xfce4-panel-4.16.2/debian/changelog xfce4-panel-4.16.2/debian/changelog
--- xfce4-panel-4.16.2/debian/changelog	2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/changelog	2022-04-28 16:20:27.0 +0200
@@ -1,3 +1,10 @@
+xfce4-panel (4.16.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix upstream bug #188: some windows do not appear in the panel.
+
+ -- Tomas Tintera   Thu, 28 Apr 2022 16:20:27 +0200
+
 xfce4-panel (4.16.2-1) unstable; urgency=medium
 
   * New upstream version 4.16.2
diff -Nru xfce4-panel-4.16.2/debian/patches/series xfce4-panel-4.16.2/debian/patches/series
--- xfce4-panel-4.16.2/debian/patches/series	2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/series	2022-04-28 16:20:27.0 +0200
@@ -1,2 +1,3 @@
 01_support-non-multiarch-modules.patch
 02_pager-size-for-viewport.patch
+03_disconnect-size-allocate.patch
diff -Nru xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch
--- xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch	1970-01-01 01:00:00.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch	2022-04-28 16:20:27.0 +0200
@@ -0,0 +1,46 @@
+Origin: upstream, https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/66/diffs
+Date: Thu, 28 Apr 2022 16:20:27 +0200
+Subject: Fix some window buttons not appearing in the panel
+
+This is a backport of an upstream fix to odd behavior of the tasklist widget
+where closing a window would not reposition remaining window buttons and/or
+where new window buttons would not appear.
+
+Bug-Debian: https://bugs.debian.org/1004837
+Bug: https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/188
+Applied-Upstream: https://gitlab.xfce.org/xfce/xfce4-panel/-/commit/9881894b9588d36da69901f15215009c8debf1ac
+
+---
+
+--- xfce4-panel-4.16.2.orig/plugins/tasklist/tasklist-widget.c
 xfce4-panel-4.16.2/plugins/tasklist/tasklist-widget.c
+@@ -2871,20 +2871,6 @@ xfce_tasklist_button_geometry_changed2 (
+ 
+ 
+ 
+-static gboolean
+-xfce_tasklist_button_size_allocate (GtkWidget *widget,
+-GdkRectangle  *allocation,
+-gpointer   user_data)
+-{
+-  XfceTasklistChild *child = user_data;
+-  /* Make sure the icons have the correct size */
+-  xfce_tasklist_button_icon_changed (child->window, child);
+-
+-  return TRUE;
+-}
+-
+-
+-
+ #ifdef GDK_WINDOWING_X11
+ static void
+ xfce_tasklist_button_geometry_changed (WnckWindow*window,
+@@ -3560,8 +3546,6 @@ xfce_tasklist_button_new (WnckWindow   *
+   G_CALLBACK (xfce_tasklist_button_button_release_event), child);
+ 
+   /* monitor window changes */
+-  g_signal_connect (G_OBJECT (child->button), "size-allocate",
+-  G_CALLBACK (xfce_tasklist_button_size_allocate), child);
+   g_signal_connect (G_OBJECT (window), "icon-changed",
+   G_CALLBACK (xfce_tasklist_button_icon_changed), child);
+   g_signal_connect (G_OBJECT (window), "name-changed",

Bug#1004837: XFCE Window Buttons not visible after Debian upgrade

2022-04-28 Thread Tomas Tintera

Control: tags -1 + patch
Control: tags -1 + fixed-upstream

Hi maintainer,

having the same upgrade experience as the original poster, this prevents me
from promoting users to upgrade yet.

This is probably an upstream bug #188, which has been fixed this February:
https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/188

Could you please backport the upstream fix, as in the provided debpatch?


Best regards,
Tomasdiff -Nru xfce4-panel-4.16.2/debian/changelog xfce4-panel-4.16.2/debian/changelog
--- xfce4-panel-4.16.2/debian/changelog	2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/changelog	2022-04-28 16:20:27.0 +0200
@@ -1,3 +1,10 @@
+xfce4-panel (4.16.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix upstream bug #188: some windows do not appear in the panel.
+
+ -- Tomas Tintera   Thu, 28 Apr 2022 16:20:27 +0200
+
 xfce4-panel (4.16.2-1) unstable; urgency=medium
 
   * New upstream version 4.16.2
diff -Nru xfce4-panel-4.16.2/debian/patches/series xfce4-panel-4.16.2/debian/patches/series
--- xfce4-panel-4.16.2/debian/patches/series	2021-02-27 17:29:44.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/series	2022-04-28 16:20:27.0 +0200
@@ -1,2 +1,3 @@
 01_support-non-multiarch-modules.patch
 02_pager-size-for-viewport.patch
+03_disconnect-size-allocate.patch
diff -Nru xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch
--- xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch	1970-01-01 01:00:00.0 +0100
+++ xfce4-panel-4.16.2/debian/patches/03_disconnect-size-allocate.patch	2022-04-28 16:20:27.0 +0200
@@ -0,0 +1,46 @@
+Origin: upstream, https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/66/diffs
+Date: Thu, 31 Oct 2019 17:20:31 +0100
+Subject: Fix some window buttons not appearing in the panel
+
+This is a backport of an upstream fix to odd behavior of the tasklist widget
+where closing a window would not reposition remaining window buttons and/or
+where new window buttons would not appear.
+
+Bug-Debian: https://bugs.debian.org/1004837
+Bug: https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/188
+Applied-Upstream: https://gitlab.xfce.org/xfce/xfce4-panel/-/commit/9881894b9588d36da69901f15215009c8debf1ac
+
+---
+
+--- xfce4-panel-4.16.2.orig/plugins/tasklist/tasklist-widget.c
 xfce4-panel-4.16.2/plugins/tasklist/tasklist-widget.c
+@@ -2871,20 +2871,6 @@ xfce_tasklist_button_geometry_changed2 (
+ 
+ 
+ 
+-static gboolean
+-xfce_tasklist_button_size_allocate (GtkWidget *widget,
+-GdkRectangle  *allocation,
+-gpointer   user_data)
+-{
+-  XfceTasklistChild *child = user_data;
+-  /* Make sure the icons have the correct size */
+-  xfce_tasklist_button_icon_changed (child->window, child);
+-
+-  return TRUE;
+-}
+-
+-
+-
+ #ifdef GDK_WINDOWING_X11
+ static void
+ xfce_tasklist_button_geometry_changed (WnckWindow*window,
+@@ -3560,8 +3546,6 @@ xfce_tasklist_button_new (WnckWindow   *
+   G_CALLBACK (xfce_tasklist_button_button_release_event), child);
+ 
+   /* monitor window changes */
+-  g_signal_connect (G_OBJECT (child->button), "size-allocate",
+-  G_CALLBACK (xfce_tasklist_button_size_allocate), child);
+   g_signal_connect (G_OBJECT (window), "icon-changed",
+   G_CALLBACK (xfce_tasklist_button_icon_changed), child);
+   g_signal_connect (G_OBJECT (window), "name-changed",

Bug#1010310: python-duniterpy: autopkgtest regression: python3.9: command not found


Source: python-duniterpy
Version: 1.1.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
python-duniterpy   from testing1.1.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. Your (manually 
added) autopkgtest wants to use all supported Python3 versions, but 
doesn't actually ensure they are installed. Hence, you only get the 
default python3 through the dependencies.


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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-duniterpy/21208152/log.gz

bash: line 1: python3.9: command not found
autopkgtest [08:10:25]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009818: V2Ray 4.34.0-5 (Debian Unstable ver.) Crashes when VMess Protocol is Used because an unsynchronized update of Golang and V2Ray - HMAC constructor fix not applied on Debian

2022-04-28 Thread Shelikhoo

The reason this package is often out of update is that whenever a new 
dependency is introduced, that dependency will need to be packaged.



We, the developer, could develop with the dependency availability in 
mind. Or create make dependencies and associated functions optional. If 
that is necessary for other functional updates to be delivered in a 
timely manner.



On 28/4/2022 3:05 pm, Antoine Beaupré wrote:

Control: tags -1 +patch
Control: found -1 4.34.0-1
Control: severity -1 grave

On 2022-04-18 17:40:13, Shelikhoo wrote:

This bug is submitted by upstream developers on behalf of end-users for
a Debian specific bug.  We are ready to cooperate with the Debian side
to resolve this bug.

V2Ray 4.34.0-5 (Debian Unstable ver.) crashes when VMess protocol is
used because an unsynchronized update of Golang and V2Ray as HMAC
constructor fix is not applied on Debian version of V2Ray.

The version of the source code currently included in Debian will not
work if compiled with Golang 1.15+(or possibly 1.16+). We have already
fixed this issue more than 1 year
ago(https://github.com/v2fly/v2ray-core/commit/0024c6e028768d8516bdee11be9834b2617ff00c)
however this changeset is not included in Debian. We recommend this
commit be backported to the Debian version of V2Ray(I will exercise
self-control to refrain from asking you to keep the package up to date.).

No need for self control! The package should be kept up to date, and
feel free to file a bug to report this problem. :)

I think this probably also applies to stable (because it doesn't have a
different set of patches than unstable), so I marked it as affecting
that as well.

Finally, this seems to be more serious than "normal", as it completely
crashes the program ("makes the package in question unusable or mostly
so"), so I bumped the severity as well.

I think the way forward here is to update to latest upstream in
unstable. I don't see why that should be kept out. For stable, that
would need a stable update and it's a little more involved,
specifically:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-security

or:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-stable

a.

Bug#1010309: ITP: node-ws-iconv -- A set of filesystem-related functions for NodeJS

2022-04-28 Thread Roland Mas

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

* Package name: node-ws-iconv
  Version : 0.0~git20220306210217.c039e94 (from Git)
  Upstream Author : "bluelovers" (https://github.com/bluelovers)
* URL : https://github.com/bluelovers/ws-iconv
* License : MIT/ISC/BSD-3-Clause
  Programming Lang: Javascript/Typescript
  Description : A set of filesystem-related functions for NodeJS

This is a set of small NodeJS packages, poorly documented [1], with
functions seemingly related to filesystem and path operations.

It is required (indirectly) by jupyterlab, via node-react-json-tree
(redux-devtools) and node-yarn-tool-resolve-package.

It will be maintained under the js-team umbrella.

[1] No author name, README files are boilerplate-only, git commit logs
are mostly ".", and changelog files are generated from these commit
logs so they also lack useful information.

Bug#1010308: starjava-fits: autopkgtest regression: Compile failed


Source: starjava-fits
Version: 0.1+2022.04.12-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
starjava-fits  from testing0.1+2022.04.12-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. As I note that 
there's also other changes in the starjava-* suite, I wonder if this is 
a missing *versioned* (test|build|) dependency.


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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/s/starjava-fits/21214595/log.gz

Buildfile: /tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/build.xml

prepare:

check_packages:

build:

compile-tests:
[mkdir] Created dir: 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/autopkgtest_tmp/testcases
[javac] Compiling 11 source files to 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/autopkgtest_tmp/testcases
[javac] 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/src/testcases/uk/ac/starlink/fits/BasicInputTest.java:18: 
error: cannot find symbol

[javac] import uk.ac.starlink.util.DataBufferedInputStream;
[javac]   ^
[javac]   symbol:   class DataBufferedInputStream
[javac]   location: package uk.ac.starlink.util
[javac] 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/src/testcases/uk/ac/starlink/fits/BasicInputTest.java:19: 
error: cannot find symbol

[javac] import uk.ac.starlink.util.DataBufferedOutputStream;
[javac]   ^
[javac]   symbol:   class DataBufferedOutputStream
[javac]   location: package uk.ac.starlink.util
[javac] 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/src/testcases/uk/ac/starlink/fits/ColumnReaderTest.java:27: 
error: cannot find symbol

[javac] import uk.ac.starlink.util.DataBufferedOutputStream;
[javac]   ^
[javac]   symbol:   class DataBufferedOutputStream
[javac]   location: package uk.ac.starlink.util
[javac] 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/src/testcases/uk/ac/starlink/fits/BasicInputTest.java:34: 
error: cannot find symbol

[javac] DataBufferedOutputStream out =
[javac] ^
[javac]   symbol:   class DataBufferedOutputStream
[javac]   location: class BasicInputTest
[javac] 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/src/testcases/uk/ac/starlink/fits/BasicInputTest.java:35: 
error: cannot find symbol
[javac] new DataBufferedOutputStream( new 
FileOutputStream( file ) );

[javac] ^
[javac]   symbol:   class DataBufferedOutputStream
[javac]   location: class BasicInputTest
[javac] 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/src/testcases/uk/ac/starlink/fits/BasicInputTest.java:56: 
error: cannot find symbol
[javac] new 
DataBufferedInputStream(

[javac] ^
[javac]   symbol:   class DataBufferedInputStream
[javac]   location: class BasicInputTest
[javac] 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/src/testcases/uk/ac/starlink/fits/BasicInputTest.java:59: 
error: cannot find symbol
[javac] new 
DataBufferedInputStream(

[javac] ^
[javac]   symbol:   class DataBufferedInputStream
[javac]   location: class BasicInputTest
[javac] 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/src/testcases/uk/ac/starlink/fits/BasicInputTest.java:94: 
warning: [deprecation] Integer(int) in Integer has been deprecated

[javac] ixList.add( new Integer( i ) );
[javac] ^
[javac] 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/src/testcases/uk/ac/starlink/fits/ColumnReaderTest.java:427: 
error: cannot find symbol
[javac] DataBufferedOutputStream dout = new 
DataBufferedOutputStream( out );

[javac] ^
[javac]   symbol:   class DataBufferedOutputStream
[javac]   location: class ColumnReaderTest
[javac] 
/tmp/autopkgtest-lxc.9ugdx9jl/downtmp/build.suL/src/src/testcases/uk/ac/starlink/fits/ColumnReaderTest.java:427: 
error: cannot find symbol
[javac] DataBufferedOutputStream dout = new 
DataBufferedOutputStream( out );

[javac] ^
[java

Bug#1010307: user-mode-linux: FTBFS in bookworm as it Build-Depends on removed linux-source-5.16"

Source: user-mode-linux
Version: 5.16um1
Severity: serious
Tags: ftbfs
Justification: ftbfs

I regularly check the checker for Build Dependencies in testing:
https://qa.debian.org/dose/debcheck/src_testing_main/index.html

Recently your package showed up there because it Build-Depends on
linux-source-5.16 which has been removed from bookworm. Versioned
linux packages are moving targets. Are you aware of the unversioned
linux-source instead, such that you don't need to update the BD every
time the linux kernel updates?

Paul

Bug#1010240: Patch available

2022-04-28 Thread Lars Kindermann


I'm affected, too.

For Slackware there seems to be already a patch for this:

https://www.linuxquestions.org/questions/slackware-14/fix-for-broadcom-sta-not-building-in-kernel-5-17-a-4175710375/

Bug#1010263: CVE-2022-1304

2022-04-28 Thread Theodore Ts'o

Applied upstream as commit: ab51d587

Bug#1010264: Bug#1010263: Bug#1010264: CVE-2022-28391

2022-04-28 Thread Theodore Ts'o

On Thu, Apr 28, 2022 at 09:30:45AM +0200, Salvatore Bonaccorso wrote:
> 
> Theodore, btw the BTS reference for the e2fsprogs issue is #1010263
> and the CVE id CVE-2022-1304.

Yes, I've noted that already.

> #1010264 and CVE-2022-28391 is respectively for busybox. the bug
> already reassigned accordingly earlier.

Apologies, I didn't get an e-mail notification for the bug getting
reassigned; I should have double checked the BTS web page for the bug
before replying.

Regards,

- Ted

Bug#1010262: RFS: wifi-qr/0.2-2 -- WiFi Share and Connect with QR


Control: reopen -1

You do not need dpkg-source --commit to just edit a patch. Use whatever editor 
you like.

Bug#1010299: backintime-common: incompatible with most recent Python

2022-04-28 Thread Fabio Fantoni


Control: merge -1 1008653

Hi, this is a duplicate of #1008653, already solved by 1.3.2-0.1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009818: V2Ray 4.34.0-5 (Debian Unstable ver.) Crashes when VMess Protocol is Used because an unsynchronized update of Golang and V2Ray - HMAC constructor fix not applied on Debian

2022-04-28 Thread Antoine Beaupré

Control: tags -1 +patch
Control: found -1 4.34.0-1
Control: severity -1 grave

On 2022-04-18 17:40:13, Shelikhoo wrote:
> This bug is submitted by upstream developers on behalf of end-users for 
> a Debian specific bug.  We are ready to cooperate with the Debian side 
> to resolve this bug.
>
> V2Ray 4.34.0-5 (Debian Unstable ver.) crashes when VMess protocol is 
> used because an unsynchronized update of Golang and V2Ray as HMAC 
> constructor fix is not applied on Debian version of V2Ray.
>
> The version of the source code currently included in Debian will not 
> work if compiled with Golang 1.15+(or possibly 1.16+). We have already 
> fixed this issue more than 1 year 
> ago(https://github.com/v2fly/v2ray-core/commit/0024c6e028768d8516bdee11be9834b2617ff00c)
>  
> however this changeset is not included in Debian. We recommend this 
> commit be backported to the Debian version of V2Ray(I will exercise 
> self-control to refrain from asking you to keep the package up to date.).

No need for self control! The package should be kept up to date, and
feel free to file a bug to report this problem. :)

I think this probably also applies to stable (because it doesn't have a
different set of patches than unstable), so I marked it as affecting
that as well.

Finally, this seems to be more serious than "normal", as it completely
crashes the program ("makes the package in question unusable or mostly
so"), so I bumped the severity as well.

I think the way forward here is to update to latest upstream in
unstable. I don't see why that should be kept out. For stable, that
would need a stable update and it's a little more involved,
specifically:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-security

or:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-stable

a.

-- 
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led
them into it in the first place. - Douglas Adams (1952-2001)

Bug#834724: curl: (35) gnutls_handshake() failed: Public key signature verification has failed.

2022-04-28 Thread okan bağkesen

On Wed, 28 Sep 2016 12:57:49 +0100 Tim Small  wrote:
> Package: curl
> Followup-For: Bug #834724
>
> I fixed this on a sid install by removing libgnutls-deb0-28 which was
> being kept around by an old librtmp1 package version, left over from
> Jessie debian-multimedia.  Possibly libcurl should conflict with this
> package?
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages curl depends on:
> ii  libc62.24-3
> ii  libcurl3-gnutls  7.50.1-1
> ii  zlib1g   1:1.2.8.dfsg-2+b1
>
> curl recommends no packages.
>
> curl suggests no packages.
>
> -- debconf-show failed
>
>

Bug#834724: Como resgatar os biticoi

2022-04-28 Thread rclaudemir190

Enviado do meu smartphone Samsung Galaxy.

Bug#998721: RFP: wmbusmeters -- Receives and decodes utility meter wmbus telegrams

2022-04-28 Thread Petter Reinholdtsen



I created draft build rules and published them in
https://github.com/weetmuts/wmbusmeters/pull/525 >.

-- 
Vennlig hilsen
Petter Reinholdtsen

Bug#998720: RFP: rtl-wmbus -- Software defined receiver for Wireless-M-Bus

2022-04-28 Thread Petter Reinholdtsen



I created draft build rules and published them as
https://github.com/xaelsouth/rtl-wmbus/pull/36 >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#862207: error: libcrypto does not provide GOST


28.04.2022 15:27, Ondřej Surý wrote:
..

Yes, it’s the old one. The 2012 hasn’t been specified for use
in DNSSEC - there was a draft, but it has expired.


Ok, that makes sense. Thank you for clarification.


Please note there are at least 4 symbols in the libldns3
library which are gost-related:

..

We can keep the symbols as dummy shims, so the package
doesn’t have to bump SOVERSION.


Yeah.  Formally we should do either one or another.
In practice I *highly* doubt anyone is using these 4
symbols, so maybe we can just disable the thing without
doing anything. I'm too lazy now to provide the stubs :)

..

There are no GOST signatures used in real world deployments,
there’s no need to have validation enabled anywhere. Keeping
obsoleted algorithm alive is not doing anybody any favor.


I for one have no objections whatsoever against removal it
besides the extra work which is needed. To me it is like,
don't touch it if it does not disturb anyone.

FWIW, for me the whole GOST thing is weird, I'd not have/use it
at all to begin with.  In some contexts it is required though.

/mjt

Bug#1008573: [pkg-gnupg-maint] Bug#1008573: gpg-agent -managed SSH keys stored in Yubikeys cannot be used with OpenSSH 8.9

Control: forwarded 1008573 https://dev.gnupg.org/T5935
Control: tags 1008573 + upstream
Control: severity 1008573 important

This bug report was tagged severity "serious"

https://www.debian.org/Bugs/Developer#severities says that severity
level means:

  > is a severe violation of Debian policy (roughly, it violates a
  > "must" or "required" directive), or, in the package maintainer's or
  > release manager's opinion, makes the package unsuitable for release.

I see no justification for that severity level in the discussion, so i'm
changing it to normal.  If you think that's wrong, feel free to reset it
to "serious" with an explicit justification, thanks!

On Fri 2022-04-22 12:04:15 +0900, NIIBE Yutaka wrote:
> I found an issue of scdaemon.  At upstream development, it is tracked by:
>
>   https://dev.gnupg.org/T5935
>
> When the data is not so large (smaller than the buffer size of token),
> it works using Gnuk, with the patch of scdaemon.

Thanks for tracking this down, gniibe!

If there's a specific patch that we should include in the debian release
of the 2.2 branch, please let me know.  The patch mentioned in
https://dev.gnupg.org/T5935
(https://dev.gnupg.org/rGe8fb8e2b3e66d5ea8a3dc90afdc14611abf2c3da) 
doesn't look like it will apply directly to the 2.2 branch.

In the meantime, people with the affected key/hardware combination
should be able to continue using the workaround described by vagrant.

--dkg

signature.asc
Description: PGP signature

Bug#862207: error: libcrypto does not provide GOST

2022-04-28 Thread Ondřej Surý


> On 28. 4. 2022, at 14:09, Michael Tokarev  wrote:
> 
> 27.04.2022 12:08, Ondřej Surý wrote:
>> Hi,
>> GOST has been deprecated for use in DNSSEC, and the
>> actual standard actually says it MUST NOT be used for
>> signing (and MAY be used for verification), see RFC 8624.
>> I think the best course of action here is to actually disable it
>> everywhere where GOST R 34.10-2001 is used as it has
>> been superseded by GOST R 34.10-2012 in [RFC7091].
> 
> I don't know which version(s) of GOST is enabled in ldns
> when built with --enable-gost[-anyway]. Do you?

Yes, it’s the old one. The 2012 hasn’t been specified for use
in DNSSEC - there was a draft, but it has expired.

There’s an effort to add GOST-2012 to DNSSEC, but it’s
still a draft: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/

But that’s only tangential. The GOST-2001 needs to be
eradicated from DNS.

> Please note there are at least 4 symbols in the libldns3
> library which are gost-related:
> 
> ldns_gost2pkey_raw@Base 1.7.1
> ldns_gost_engine@Base 1.7.1
> ldns_key_EVP_load_gost_id@Base 1.7.1
> ldns_key_EVP_unload_gost@Base 1.7.1

We can keep the symbols as dummy shims, so the package
doesn’t have to bump SOVERSION.

> I'm not sure here, but it looks like we'll have to
> bump the library soname when removing these symbols.
> 
> To me it looks like not worth the effort.  Especially
> since we "MAY" (as the RFC suggests) need it to verify
> some old signatures anyway.

There are no GOST signatures used in real world deployments,
there’s no need to have validation enabled anywhere. Keeping
obsoleted algorithm alive is not doing anybody any favor.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org


signature.asc
Description: Message signed with OpenPGP

Bug#1010305: buster-pu: package freetype/2.9.1-3+deb10u3

2022-04-28 Thread Hugh McMaster

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

This update fixes three security vulnerabilities in FreeType 2.9.1-3+deb10u2.

- CVE-2022-27404: heap buffer overflow via invalid integer decrement in
sfnt_init_face().
- CVE-2022-27405: segmentation violation via ft_open_face_internal() when
attempting to read the value of FT_LONG face_index.
- CVE-2022-27406: segmentation violation via FT_Request_Size() when attempting
to read the value of an unguarded face size handle.

It would be ideal to get these fixes into Buster.
diff -Nru freetype-2.9.1/debian/changelog freetype-2.9.1/debian/changelog
--- freetype-2.9.1/debian/changelog 2020-10-21 06:15:41.0 +1100
+++ freetype-2.9.1/debian/changelog 2022-04-28 21:11:36.0 +1000
@@ -1,3 +1,15 @@
+freetype (2.9.1-3+deb10u3) buster; urgency=medium
+
+  * Add upstream patches to fix multiple vulnerabilities. Closes: #1010183.
+- CVE-2022-27404: heap buffer overflow via invalid integer decrement in
+  sfnt_init_face().
+- CVE-2022-27405: segmentation violation via ft_open_face_internal() when
+  attempting to read the value of FT_LONG face_index.
+- CVE-2022-27406: segmentation violation via FT_Request_Size() when
+  attempting to read the value of an unguarded face size handle.
+
+ -- Hugh McMaster   Thu, 28 Apr 2022 21:11:36 +1000
+
 freetype (2.9.1-3+deb10u2) buster-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru freetype-2.9.1/debian/patches/CVE-2022-27404.patch 
freetype-2.9.1/debian/patches/CVE-2022-27404.patch
--- freetype-2.9.1/debian/patches/CVE-2022-27404.patch  1970-01-01 
10:00:00.0 +1000
+++ freetype-2.9.1/debian/patches/CVE-2022-27404.patch  2022-04-28 
21:06:58.0 +1000
@@ -0,0 +1,19 @@
+Description: Check `face_index` before decrementing to prevent heap buffer
+ overflow (CVE-2022-27404).
+Author: Werner Lemberg
+Origin: 
https://gitlab.freedesktop.org/freetype/freetype/-/commit/53dfdcd8198d2b3201a23c4bad9190519ba918db
+Bug: https://gitlab.freedesktop.org/freetype/freetype/-/issues/1138
+Bug-Debian: https://bugs.debian.org/1010183
+Last-Update: 2022-04-28
+
+--- a/src/sfnt/sfobjs.c
 b/src/sfnt/sfobjs.c
+@@ -923,7 +923,7 @@
+ face_index = FT_ABS( face_instance_index ) & 0x;
+ 
+ /* value -(N+1) requests information on index N */
+-if ( face_instance_index < 0 )
++if ( face_instance_index < 0 && face_index > 0 )
+   face_index--;
+ 
+ if ( face_index >= face->ttc_header.count )
diff -Nru freetype-2.9.1/debian/patches/CVE-2022-27405.patch 
freetype-2.9.1/debian/patches/CVE-2022-27405.patch
--- freetype-2.9.1/debian/patches/CVE-2022-27405.patch  1970-01-01 
10:00:00.0 +1000
+++ freetype-2.9.1/debian/patches/CVE-2022-27405.patch  2022-04-28 
21:08:12.0 +1000
@@ -0,0 +1,26 @@
+Description: Properly guard `face_index` before attempting to read its value
+ (CVE-2022-27405).
+Author: Werner Lemberg
+Origin: 
https://gitlab.freedesktop.org/freetype/freetype/-/commit/22a0cccb4d9d002f33c1ba7a4b36812c7d4f46b5
+Bug: https://gitlab.freedesktop.org/freetype/freetype/-/issues/1139
+Bug-Debian: https://bugs.debian.org/1010183
+Last-Update: 2022-04-28
+
+--- a/src/base/ftobjs.c
 b/src/base/ftobjs.c
+@@ -2345,6 +2345,15 @@
+ #endif
+ 
+ 
++/* only use lower 31 bits together with sign bit */
++if ( face_index > 0 )
++  face_index &= 0x7FFFL;
++else
++{
++  face_index &= 0x7FFFL;
++  face_index  = -face_index;
++}
++
+ #ifdef FT_DEBUG_LEVEL_TRACE
+ FT_TRACE3(( "FT_Open_Face: " ));
+ if ( face_index < 0 )
diff -Nru freetype-2.9.1/debian/patches/CVE-2022-27406.patch 
freetype-2.9.1/debian/patches/CVE-2022-27406.patch
--- freetype-2.9.1/debian/patches/CVE-2022-27406.patch  1970-01-01 
10:00:00.0 +1000
+++ freetype-2.9.1/debian/patches/CVE-2022-27406.patch  2022-04-28 
21:09:23.0 +1000
@@ -0,0 +1,20 @@
+Description: Guard the `face->size` handle before attempting to read its value
+ (CVE-2022-27406).
+Author: Werner Lemberg
+Origin: 
https://gitlab.freedesktop.org/freetype/freetype/-/commit/0c2bdb01a2e1d24a3e592377a6d0822856e10df2
+Bug: https://gitlab.freedesktop.org/freetype/freetype/-/issues/1140
+Bug-Debian: https://bugs.debian.org/1010183
+Last-Update: 2022-04-28
+
+--- a/src/base/ftobjs.c
 b/src/base/ftobjs.c
+@@ -3209,6 +3209,9 @@
+ if ( !face )
+   return FT_THROW( Invalid_Face_Handle );
+ 
++if ( !face->size )
++  return FT_THROW( Invalid_Size_Handle );
++
+ if ( !req || req->width < 0 || req->height < 0 ||
+  req->type >= FT_SIZE_REQUEST_TYPE_MAX )
+   return FT_THROW( Invalid_Argument );
diff -Nru freetype-2.9.1/debian/patches/series 
freetype-2.9.1/debian/patches/series
--- freetype-2.9.1/debian/patches/series2020-10-21 06:15:41.0 
+1100
+++ freetype-2.9.1/debian/patches/series2022-04-28 21:09:11.0 
+1000
@@ -9,3 +9,6 @@
 no-

Bug#1010304: bullseye-pu: package freetype/2.10.4+dfsg-1+deb11u1

2022-04-28 Thread Hugh McMaster

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

This update fixes three security vulnerabilities in FreeType 2.10.4+dfsg-1.

- CVE-2022-27404: heap buffer overflow via invalid integer decrement in
sfnt_init_face() and woff2_open_font().
- CVE-2022-27405: segmentation violation via ft_open_face_internal() when
attempting to read the value of FT_LONG face_index.
- CVE-2022-27406: segmentation violation via FT_Request_Size() when attempting
to read the value of an unguarded face size handle.

It would be ideal to get these fixes into Bullseye.
diff -Nru freetype-2.10.4+dfsg/debian/changelog 
freetype-2.10.4+dfsg/debian/changelog
--- freetype-2.10.4+dfsg/debian/changelog   2020-12-05 19:20:58.0 
+1100
+++ freetype-2.10.4+dfsg/debian/changelog   2022-04-28 19:54:23.0 
+1000
@@ -1,3 +1,15 @@
+freetype (2.10.4+dfsg-1+deb11u1) bullseye; urgency=medium
+
+  * Add upstream patches to fix multiple vulnerabilities. Closes: #1010183.
+- CVE-2022-27404: heap buffer overflow via invalid integer decrement in
+  sfnt_init_face() and woff2_open_font().
+- CVE-2022-27405: segmentation violation via ft_open_face_internal() when
+  attempting to read the value of FT_LONG face_index.
+- CVE-2022-27406: segmentation violation via FT_Request_Size() when
+  attempting to read the value of an unguarded face size handle.
+
+ -- Hugh McMaster   Thu, 28 Apr 2022 19:54:23 +1000
+
 freetype (2.10.4+dfsg-1) unstable; urgency=medium
 
   * New upstream version:
diff -Nru freetype-2.10.4+dfsg/debian/patches/CVE-2022-27404.patch 
freetype-2.10.4+dfsg/debian/patches/CVE-2022-27404.patch
--- freetype-2.10.4+dfsg/debian/patches/CVE-2022-27404.patch1970-01-01 
10:00:00.0 +1000
+++ freetype-2.10.4+dfsg/debian/patches/CVE-2022-27404.patch2022-04-28 
19:54:23.0 +1000
@@ -0,0 +1,30 @@
+Description: Check `face_index` before decrementing to prevent heap buffer
+ overflow (CVE-2022-27404).
+Author: Werner Lemberg
+Origin: 
https://gitlab.freedesktop.org/freetype/freetype/-/commit/53dfdcd8198d2b3201a23c4bad9190519ba918db
+Bug: https://gitlab.freedesktop.org/freetype/freetype/-/issues/1138
+Bug-Debian: https://bugs.debian.org/1010183
+Last-Update: 2022-04-28
+
+--- a/src/sfnt/sfobjs.c
 b/src/sfnt/sfobjs.c
+@@ -553,7 +553,7 @@
+ face_index = FT_ABS( face_instance_index ) & 0x;
+ 
+ /* value -(N+1) requests information on index N */
+-if ( face_instance_index < 0 )
++if ( face_instance_index < 0 && face_index > 0 )
+   face_index--;
+ 
+ if ( face_index >= face->ttc_header.count )
+--- a/src/sfnt/sfwoff2.c
 b/src/sfnt/sfwoff2.c
+@@ -2098,7 +2098,7 @@
+ /* Validate requested face index. */
+ *num_faces = woff2.num_fonts;
+ /* value -(N+1) requests information on index N */
+-if ( *face_instance_index < 0 )
++if ( *face_instance_index < 0 && face_index > 0 )
+   face_index--;
+ 
+ if ( face_index >= woff2.num_fonts )
diff -Nru freetype-2.10.4+dfsg/debian/patches/CVE-2022-27405.patch 
freetype-2.10.4+dfsg/debian/patches/CVE-2022-27405.patch
--- freetype-2.10.4+dfsg/debian/patches/CVE-2022-27405.patch1970-01-01 
10:00:00.0 +1000
+++ freetype-2.10.4+dfsg/debian/patches/CVE-2022-27405.patch2022-04-28 
19:54:23.0 +1000
@@ -0,0 +1,26 @@
+Description: Properly guard `face_index` before attempting to read its value
+ (CVE-2022-27405).
+Author: Werner Lemberg
+Origin: 
https://gitlab.freedesktop.org/freetype/freetype/-/commit/22a0cccb4d9d002f33c1ba7a4b36812c7d4f46b5
+Bug: https://gitlab.freedesktop.org/freetype/freetype/-/issues/1139
+Bug-Debian: https://bugs.debian.org/1010183
+Last-Update: 2022-04-28
+
+--- a/src/base/ftobjs.c
 b/src/base/ftobjs.c
+@@ -2407,6 +2407,15 @@
+ #endif
+ 
+ 
++/* only use lower 31 bits together with sign bit */
++if ( face_index > 0 )
++  face_index &= 0x7FFFL;
++else
++{
++  face_index &= 0x7FFFL;
++  face_index  = -face_index;
++}
++
+ #ifdef FT_DEBUG_LEVEL_TRACE
+ FT_TRACE3(( "FT_Open_Face: " ));
+ if ( face_index < 0 )
diff -Nru freetype-2.10.4+dfsg/debian/patches/CVE-2022-27406.patch 
freetype-2.10.4+dfsg/debian/patches/CVE-2022-27406.patch
--- freetype-2.10.4+dfsg/debian/patches/CVE-2022-27406.patch1970-01-01 
10:00:00.0 +1000
+++ freetype-2.10.4+dfsg/debian/patches/CVE-2022-27406.patch2022-04-28 
19:54:23.0 +1000
@@ -0,0 +1,20 @@
+Description: Guard the `face->size` handle before attempting to read its value
+ (CVE-2022-27406).
+Author: Werner Lemberg
+Origin: 
https://gitlab.freedesktop.org/freetype/freetype/-/commit/0c2bdb01a2e1d24a3e592377a6d0822856e10df2
+Bug: https://gitlab.freedesktop.org/freetype/freetype/-/issues/1140
+Bug-Debian: https://bugs.debian.org/1010183
+Last-Update: 2022-04-28
+
+--- a/src/base/ftobjs.c
 b/src/base/ftobjs.c
+@@ -3273,6 +3273,9 @@
+ if ( !face )
+   return FT_THROW( Invalid_Face_Han

Bug#862207: error: libcrypto does not provide GOST


27.04.2022 12:08, Ondřej Surý wrote:

Hi,

GOST has been deprecated for use in DNSSEC, and the
actual standard actually says it MUST NOT be used for
signing (and MAY be used for verification), see RFC 8624.

I think the best course of action here is to actually disable it
everywhere where GOST R 34.10-2001 is used as it has
been superseded by GOST R 34.10-2012 in [RFC7091].


I don't know which version(s) of GOST is enabled in ldns
when built with --enable-gost[-anyway]. Do you?

Please note there are at least 4 symbols in the libldns3
library which are gost-related:

 ldns_gost2pkey_raw@Base 1.7.1
 ldns_gost_engine@Base 1.7.1
 ldns_key_EVP_load_gost_id@Base 1.7.1
 ldns_key_EVP_unload_gost@Base 1.7.1

I'm not sure here, but it looks like we'll have to
bump the library soname when removing these symbols.

To me it looks like not worth the effort.  Especially
since we "MAY" (as the RFC suggests) need it to verify
some old signatures anyway.

Thanks,

/mjt

Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800

2022-04-28 Thread Salvatore Bonaccorso

Source: networkd-dispatcher
Version: 2.1-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for networkd-dispatcher.

CVE-2022-29799[0] and CVE-2022-29800[1].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-29799
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29799
[1] https://security-tracker.debian.org/tracker/CVE-2022-29800
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29800
[2] 
https://www.microsoft.com/security/blog/2022/04/26/microsoft-finds-new-elevation-of-privilege-linux-vulnerability-nimbuspwn/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1010262: RFS: wifi-qr/0.2-2 -- WiFi Share and Connect with QR

2022-04-28 Thread Ko Ko Ye`

Dear Maintainers and Mentors

Sorry for messing up my email.

When I use the dpkg-source --commit, It's taken from d/changelog.
I am confused and sticky with this template.

until the  @Bastian Germann  Mention on it.

Now I split with d/changelog and patches description and template.

Please kindly check for me.

Best Regards.

Description: Scan Image and connect
 Scan Image file with CLI and GUI.
 .
Author: kokoye2007 
Forwarded: not-needed
Reviewed-By: kokoye2...@gmail.com
Last-Update: 2022-04-28

---


On Thu, Apr 28, 2022 at 1:44 PM Ko Ko Ye`  wrote:

> Dear Mentors
>
> Please kindly check for me.
>
> Description: Scan Image and connect
>  Scan Image file with CLI and GUI.
>  fix #989034
>  .
>  wifi-qr (0.2-2) unstable; urgency=medium
>  .
>* (Closes: #989034)
> Author: kokoye2007 
> Bug-Debian: https://bugs.debian.org/989034
> Forwarded: not-needed
> Reviewed-By: kokoye2...@gmail.com
> Last-Update: 2022-04-28
>
> ---
>
> --- wifi-qr-0.2.orig/wifi-qr
> +++ wifi-qr-0.2/wifi-qr
> @@ -30,8 +30,8 @@ VERSION=0.2
>
> On Wed, Apr 27, 2022 at 10:15 PM Ko Ko Ye`  wrote:
>
>> Thanks for your information.
>>
>> Now It's changed the Description.
>> patch is Ignore README file.
>>
>> BR
>>
>> On Wed, Apr 27, 2022 at 8:55 PM Bastian Germann  wrote:
>>
>>> Something went wrong. The patch
>>> debian/patches/Update-0.2-2-File-Function now contains in the description:
>>> """
>>>   Update Man and Menu Shortcut
>>>   .
>>>   wifi-qr (0.2-2) unstable; urgency=medium
>>>   .
>>> * Improve Summary. (Closes: #989034)
>>>   ...
>>> Bug-Debian: https://bugs.debian.org/989034
>>> """
>>>
>>> This has nothing to do with the patch.
>>>
>>> Why do you patch upstream's README.md with that patch?
>>> If you want to provide additional info, create debian/README.Debian.
>>>
>>> Your binary package description has some language mistakes and redundant
>>> info. I suggest:
>>> Description: WiFi password share via QR codes
>>>   Shares WiFi SSID and password via a QR code.
>>>   Generate a QR code of a WiFi network with its password.
>>>   Scan QR codes and easily connect to WiFi Networks.
>>>   .
>>>   For Android, OS version 10 and above is supported.
>>>   .
>>>   For iOS, the Shortcut app supports generating WiFi QR codes.
>>>
>>
>>
>> --
>>
>> with regards *Ko Ko Ye` *
>>
>>
>> kokoye2...@gmail.com
>> kokoye2...@ubuntu.com
>>
>> https://www.linkedin.com/in/kokoye2007
>> https://ubuntu-mm.net
>> https://kokoye2007.github.io
>>
>
>
> --
>
> with regards *Ko Ko Ye` *
>
>
> kokoye2...@gmail.com
> kokoye2...@ubuntu.com
>
> https://www.linkedin.com/in/kokoye2007
> https://ubuntu-mm.net
> https://kokoye2007.github.io
>


-- 

with regards *Ko Ko Ye` *


kokoye2...@gmail.com
kokoye2...@ubuntu.com

https://www.linkedin.com/in/kokoye2007
https://ubuntu-mm.net
https://kokoye2007.github.io


0.2-2
Description: Binary data

Bug#1010302: Not testing $OPTIONS in the /lib/systemd/system/proftpd.service

2022-04-28 Thread Viktor Simon

Package: proftpd-core
Version: 1.3.7a+dfsg-12+deb11u2
Severity: normal

We have next content in the unit file:

root@changeme:/# cat /lib/systemd/system/proftpd.service
[Unit]
Description=ProFTPD FTP Server
Wants=network-online.target
After=network-online.target nss-lookup.target local-fs.target
remote-fs.target

[Service]
Type=forking
Environment=OPTIONS= CONFIG_FILE=/etc/proftpd/proftpd.conf
EnvironmentFile=-/etc/default/proftpd
ExecStartPre=/usr/sbin/proftpd --configtest -c $CONFIG_FILE
ExecStart=/usr/sbin/proftpd -c $CONFIG_FILE $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/run/proftpd.pid

[Install]
WantedBy=multi-user.target
root@changeme:/#


We can see test string:
ExecStartPre=/usr/sbin/proftpd --configtest -c $CONFIG_FILE

And we can see start string:
ExecStart=/usr/sbin/proftpd -c $CONFIG_FILE $OPTIONS

In the start string, it uses $CONFIG_FILE and $OPTIONS, but in the test
string, it does not use $OPTIONS.
So, options in the /etc/default/proftpd do not work, when proftpd testing
config before start.

When the server haven't correct hostname or it is unable to resolve the
hostname, proftpd can't start.
For solve this, we can add in the /etc/default/proftpd:

OPTIONS="-S 0.0.0.0"

Now, proftpd can be start successfully and not require of hostname
resolving, but proftpd still can't start, because $OPTIONS is not using in
ExecStartPre.

If i open /lib/systemd/system/proftpd.service and find string:

ExecStartPre=/usr/sbin/proftpd --configtest -c $CONFIG_FILE

And change this to:

ExecStartPre=/usr/sbin/proftpd --configtest -c $CONFIG_FILE $OPTIONS

And save changes via "systemctl daemon-reload"

All's good, proftpd correctly work.

Well, i think that it correct, if $OPTIONS testing in ExecStartPre and this
should be added by default.

P.S. Unfortunately, this can't be overridden via
/etc/systemd/system/proftpd.service.d/override.conf

-- 
Best regards, Victor Simon
FastVPS LLC

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon

2022-04-28 Thread Jonas Smedegaard

Quoting Marc Dequènes (duck) (2022-04-28 11:47:16)
> Quack Jonas,
> 
> I hope you're fine.

I am, thanks.  Likewise :-)


> On 2022-04-27 16:28, Jonas Smedegaard wrote:
> 
> > I'd be happy to co-maintain if you are interested in doing so 
> > outside of the Rust team - e.g. using the more loose debian 
> > collaboration section at salsa.
> 
> I'm really new at Rust but really interested in learning more. The 
> team process seems complicated but the static compilations with 
> features is not something easy to handle and I have no idea how I 
> would do better. Contrary to older languages most libraries are not 
> packaged and I think that would be easier to work with the help of the 
> team. I'd like to handle the initial packaging by myself to learn but 
> if you want to later contribute through me without having to handle 
> team interactions, you're welcome.

Fair enough.

I have evolved a structure to maintain draft packaging of Rust-based 
applications with not-yet-packaged crates embedded-but-not-git-tracked. 
If interested in borrowing from that, you can try look at rules and TODO 
and README.source files of https://salsa.debian.org/debian/safe-vdash - 
or feel free to ask for more details or other more complex examples.

I wish you a joyful time getting the pieces packaged,

 - Jonas

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

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

signature.asc
Description: signature

Bug#1010301: ITS: python-argcomplete

2022-04-28 Thread duck


Source: python-argcomplete
Version: 1.12.3-0.1
Severity: important
X-Debbugs-CC: mnen...@debian.org


Quack,

This package has not received love from their maintained since 
2017-01-24. It was NMUed multiple times since then without 
acknowledgement. The git repo is still on a guest account thus limiting 
contributions. In fact I myself made a mistake when NMUing because I did 
not realize all NMU contributions where not in the repo that I used to 
base my work. Also the package reproducibility build FTBFS and this was 
left unanswered for quite some time.


This is strange because Marco Nenciarini seems to have had some concrete 
activity recently (barman and repmg uploads), but 
libapache2-mod-auth-pgsql was left with a RC bug since 2019-12-19. So 
maybe Marco is back and that would improve but since there has been no 
communication from them so far I'm proceeding with this ITS.


Marco, if you're still interested in taking care of this package please 
answer. There are various options ranging from no time/not interested 
anymore to collaborative maintenance. In absence of reply I plan to 
bring the package into shape under the Python Team umbrella where 
hopefully having the backing of an experimented and caring group of 
folks that would ease maintenance and avoid such fate again.


Regards.
\_o<

--
Marc Dequènes

Bug#1010300: nmu: mailfromd_8.13-1

2022-04-28 Thread Roland Rosenfeld

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

nmu mailfromd_8.13-1 . ANY . unstable . -m "Rebuild against libmailutils9 
(1:3.15-2)"

There was a bug in mailutils 3.14 (#1009293), that some symbols were
changed but there was no version bump.
This was fixed in mailutils 3.15, which brings libmailutils9 (instead
of the old libmailutils8).
For this mailfromd, using this library should be rebuilt.

Greetings
Roland


signature.asc
Description: PGP signature

Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon

2022-04-28 Thread duck


Quack Jonas,

I hope you're fine.

On 2022-04-27 16:28, Jonas Smedegaard wrote:

I'd be happy to co-maintain if you are interested in doing so outside 
of

the Rust team - e.g. using the more loose debian collaboration section
at salsa.


I'm really new at Rust but really interested in learning more. The team 
process seems complicated but the static compilations with features is 
not something easy to handle and I have no idea how I would do better. 
Contrary to older languages most libraries are not packaged and I think 
that would be easier to work with the help of the team. I'd like to 
handle the initial packaging by myself to learn but if you want to later 
contribute through me without having to handle team interactions, you're 
welcome.


Regards.
\_o<

--
Marc Dequènes

Bug#1010299: backintime-common: incompatible with most recent Python

2022-04-28 Thread Francesco Potortì

Package: backintime-common
Version: 1.2.1-3
Severity: grave
X-Debbugs-Cc: none, Francesco Potortì 

I suppose the new Python is the culprit:

Traceback (most recent call last):
  File "/usr/share/backintime/common/backintime.py", line 27, in 
import config
  File "/usr/share/backintime/common/config.py", line 32, in 
import tools
  File "/usr/share/backintime/common/tools.py", line 1802, in 
class OrderedSet(collections.MutableSet):
AttributeError: module 'collections' has no attribute 'MutableSet'

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

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

Versions of packages backintime-common depends on:
ii  cron [cron-daemon]  3.0pl1-137.1
ii  openssh-client  1:9.0p1-1
ii  python3 3.10.4-1
ii  python3-dbus1.2.18-3+b1
ii  python3-keyring 23.5.0-1
ii  rsync   3.2.4-1

Versions of packages backintime-common recommends:
ii  backintime-qt  1.2.1-3

Versions of packages backintime-common suggests:
pn  encfs   
ii  powermgmt-base  1.36
ii  sshfs   3.7.2-1

-- no debconf information

Bug#1010298: Ré : Bug#1010298: startx: fbdevhw does not have fbdevhwModuleData data object

2022-04-28 Thread Samuel Thibault

Paul Dufresne, le jeu. 28 avril 2022 05:30:04 -0400, a ecrit:
> [1865310.432] (EE) LoadModule: Module fbdevhw does not have a 
> fbdevhwModuleData
> data object.
> [1865310.432] (EE) Failed to load module "fbdevhw" (invalid module, 0)
> [1865310.432] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card
> support
> [1865310.432] (II) Loading sub module "vbe"
> [1865310.432] (II) LoadModule: "vbe"
> [1865310.432] (II) Loading /usr/lib/xorg/modules/libint10.so
> [1865310.432] (II) Module int10: vendor="X.Org Foundation"
> [1865310.432] compiled for 1.21.1.3, module version = 1.0.0
> [1865310.432] ABI class: X.Org Video Driver, version 25.2
> [1865310.432] (II) Loading sub module "int10"
> [1865310.432] (II) LoadModule: "int10"
> [1865310.432] (II) Loading /usr/lib/xorg/modules/libint10.so
> [1865310.432] (II) Module int10: vendor="X.Org Foundation"
> [1865310.432] compiled for 1.21.1.3, module version = 1.0.0
> [1865310.432] ABI class: X.Org Video Driver, version 25.2
> [1865310.432] (II) VESA(0): initializing int10
> [1865310.432] (EE) VESA(0): Cannot read int vect

Ok so it's really about the int vect error. We don't have an fbdev
infrastructure anyway.

Samuel

Bug#1010128: (no subject)

2022-04-28 Thread Lev Lamberov

I can confirm the problem. Please, find the build log attached.

Cheers!
Lev Lamberov

===File /var/lib/dkms/broadcom-sta/6.30.223.271/build/make.log===
DKMS make.log for broadcom-sta-6.30.223.271 for kernel 5.17.0-1-amd64 (x86_64)
Чт 28 апр 2022 14:11:12 +05
CFG80211 API is prefered for this kernel version
Makefile:89: Neither CFG80211 nor Wireless Extension is enabled in kernel
KBUILD_NOPEDANTIC=1 make -C /lib/modules/5.17.0-1-amd64/build M=`pwd`
make[1]: предупреждение: сервер заданий недоступен: используется -j1. Добавьте 
«+» к правилу в родительском make.
make[1]: вход в каталог «/usr/src/linux-headers-5.17.0-1-amd64»
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: gcc-11 (Debian 11.2.0-20) 11.2.0
  You are using:   gcc-11 (Debian 11.3.0-1) 11.3.0
CFG80211 API is prefered for this kernel version
Using CFG80211 API
Kernel architecture is X86_64
  CC [M]  /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.o
  CC [M]  /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.o
In file included from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:81:
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_iw.h:73: warning: 
"isprint" redefined
   73 | #define isprint(c) bcm_isprint(c)
  | 
In file included from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/string_helpers.h:6,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/seq_file.h:7,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/seq_file_net.h:5,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/net/net_namespace.h:183,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/netdevice.h:37,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linuxver.h:69,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:27:
/usr/src/linux-headers-5.17.0-1-common/include/linux/ctype.h:30: note: this is 
the location of the previous definition
   30 | #define isprint(c)  ((__ismask(c)&(_P|_U|_L|_D|_SP)) != 0)
  | 
In file included from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/osl.h:79,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:28:
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c: In 
function ‘wl_attach’:
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:650:43: 
warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer 
target type [-Wdiscarded-qualifiers]
  650 | bcopy(&wl->pub->cur_etheraddr, dev->dev_addr, ETHER_ADDR_LEN);
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linux_osl.h:156:49: 
note: in definition of macro ‘bcopy’
  156 | #define bcopy(src, dst, len)memcpy((dst), (src), (len))
  | ^~~
In file included from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/string.h:253,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/bitmap.h:11,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/cpumask.h:12,
 from 
/usr/src/linux-headers-5.17.0-1-common/arch/x86/include/asm/cpumask.h:5,
 from 
/usr/src/linux-headers-5.17.0-1-common/arch/x86/include/asm/msr.h:11,
 from 
/usr/src/linux-headers-5.17.0-1-common/arch/x86/include/asm/processor.h:22,
 from 
/usr/src/linux-headers-5.17.0-1-common/arch/x86/include/asm/timex.h:5,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/timex.h:65,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/time32.h:13,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/time.h:60,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/stat.h:19,
 from 
/usr/src/linux-headers-5.17.0-1-common/include/linux/module.h:13,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linuxver.h:40,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:27:
/usr/src/linux-headers-5.17.0-1-common/include/linux/fortify-string.h:212:37: 
note: expected ‘void *’ but argument is of type ‘const unsigned char *’
  212 | __FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t 
size)
  |   ~~^
In file included from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/osl.h:79,
 from 
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:28:
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c: In 
function ‘wl_set_mac_address’:
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:1861:39: 
warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer 
ta

Bug#1009820: snort: Privilege escalation due to insecure use of logrotate

2022-04-28 Thread sec-advisory

Hello,


Thank you very much for your answer. I thought it would be a security issue if 
a user that is not supposed to be root can gain root-access even if it is a 
system-user without a password. There might  be a reason why the snort-process 
is not owned by root. Snort is a high value target and is a "risky software"  
written in c that parses arbitrary traffic from the network. If an attacker 
could gain somehow code execution through snort it would be very easy to 
elevate privileges.


I also want to mention that I did not only proposed a fix by owning 
/var/log/snort by root but also proposed that the problem can be fixed by using 
the su-directive to rotate the files as user snort in the logrotate-config.  It 
might be an option if you don't want to adjust the paths for the logfiles.

Best regards

Wolfgang Hotwagner





From: Javier Fernandez-Sanguino 
Sent: Wednesday, April 27, 2022 6:15:33 PM
To: sec-advisory; 1009...@bugs.debian.org
Cc: Debian Bug Control System
Subject: Re: Bug#1009820: snort: Privilege escalation due to insecure use of 
logrotate

severity 1009820 normal
tags 1009820 - upstream
thanks

Dear Wolfgang,

The 'snort' user is not a regular user (but a user created by the package 
itself, which is blocked from access as it has no password set). Consequently 
the privilege escalation you describe cannot be leveraged by a normal user. The 
only user in a standard installation of this package that can become 'snort' is 
actually the root user itself or if there is a remote code execution in the 
Snort software which compromises the Snort process itself.

The fix proposed (make the files managed by root) is not invalid:
- if /var/log/snort is owned by root then the Snort process (running as Snort 
user) will not be able to create the log files
- the Snort process is running as 'snort' user and should not be modified to be 
run as 'root'

The reason for this setup is precisely to improve the security of the software 
as distributed in Debian and applying a principle of minimum privilege, it is 
not an option to have this software running as root as a vulnerability found in 
the software (which is reading packages from the network, input which is by 
definition, untrusted) could potentially lead to a compromise of the system it 
is running in

Consequently I'm adjusting the bug:
- To normal (to be reviewed) as this is not, in my view, a critical bug
- To Debian-specific, as the configuration of logrotate and the setup (Snort is 
running as 'snort' user) is specific to the package and not defined by upstream

The most likely fix for this bug in any case is to adjust the definitions in 
the logrotate file, which uses "/var/log/snort/*/alert" and 
"/var/log/snort/*/*log". These definitions are too broad and could be 
simplified.

Best regards,

Javier Fernandez-Sanguino


On Mon, 18 Apr 2022 at 19:27, Wolfgang Hotwagner 
mailto:sec-advis...@ait.ac.at>> wrote:
Package: snort
Version: 2.9.15.1-5
Severity: critical
Tags: security upstream
Justification: root security hole
X-Debbugs-Cc: sec-advis...@ait.ac.at

Dear Maintainer,

The path of the logdirectory of snort can be manipulated by user

Snort in Debian Bullseye:

# ls -ld /var/log/snort/
drwxr-s--- 3 snort adm 4096 Apr 14 08:44 /var/log/snort/


The files in /var/log/snort/*/*log are once a day rotated by

logrotate as user root with the following config:

/var/log/snort/snort.alert /var/log/snort/snort.alert.fast /var/log/snort/*log 
/var/log/snort/*/alert /var/log/snort/*/*log {
daily
rotate 7
compress
missingok
notifempty
create 0640 snort adm
sharedscripts
postrotate
if [ -x /usr/sbin/invoke-rc.d ]; then \
invoke-rc.d snort restart > /dev/null; \
else \
/etc/init.d/snort restart > /dev/null; \
fi;
endscript
}

Due to logrotate is prone to a race-condition(see the link to my blog below) it 
is possible for user "snort" to replace or create any directory in 
/var/log/snort/ with a symbolik link to any

directory(for example /etc/bash_completion.d). logrotate will place files AS 
ROOT into /etc/bash_completition.d and set the owner and group to "snort.adm". 
An attacker could simply place a reverse-shell into this file. As soon as root 
logs in, a reverse shell will be executed then.

You can find an exploit for this bug at my blog: 
https://tech.feedyourhead.at/content/abusing-a-race-condition-in-logrotate-to-elevate-privileges
 and https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition

Proof of Concept:
#

snort@b8ff2e70f94d:~$ cd /tm

snort@b8ff2e70f94d:/tmp$ git clone https://github.com/whotwagner/logrotten.git
Cloning into 'logrotten'...
remote: Enumerating objects: 97, done.
remote: Counting objects: 100% (10/10), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 97 (delta 4), reused 7 (delta 2), pack-reused 87
Receiving objects: 10

Bug#1010298: startx: fbdevhw does not have fbdevhwModuleData data object

2022-04-28 Thread Samuel Thibault

Hello,

Paul Dufresne le jeu. 28 avril 2022 04:53:07 -0400, a ecrit:
> after having done the dpkg-reconfigure stuff, I get:
> xinit: unable to connect to the server
> 
> and Xorg.0.log contains a line with:
> fbdevhw does not have a fbdevhwModuleData (newline) data object.

Please send the whole log, not only a random line that could or could
not be informative.

Samuel

Bug#1010290: nmu: libtsm_4.0.2-0.1


Am 28.04.22 um 09:53 schrieb Paul Gevers:
If this was a mistake, please rectify it with a new upload reverting maintenance to Nobuhiro. The upload can be (and 
should be) source only and thus the binNMU isn't needed. If there was agreement, please point us at it.


I am sorry. That was a mistake on my side. I have just uploaded a new revision. 
Thanks for the notice.

Bug#1008997: [OpenPrinting/ipp-usb] ipp-usb is not ready for this device (Issue #48)

2022-04-28 Thread alain


hello alexander pevzner .

I will try to answer your 4 questions clearly:

1) combinations that work :
- stable kernel with stable ipp-usb
- kernel testing / sid with ipp-usb stable version


2) combinations that definitely don't work:
- kernel testing / sid with ipp-usb (testing / sid version)

once my printer is plugged , system-config-printer do not recognize it .

i can not print even a test page . and never see the printer icon .


3) when it works, it works constantly.
system-config-printer is constantly fully functional.

once i plug in my printer (or power it on) , after a very short delay ,

system-config-printer recognize it and i can print a test page and my 
documents .


i see the printer icon  and it is fully functional .


4) when it doesn't work, it's definitive. it doesn't work.

system-config-printer never recognize it and i can not print even a test 
page


apparmor seems to do nothing with the testing/sid  version of ipp-usb .


I answered your questions as you wanted?
Did it help you ?

friendly,
respectfully,

alain.


nb: for instance , i am working with the stable version of ipp-usb and 
all is nearly perfect .


under 5.17 kernel . my system is constantly up-to-date (sid) .


in case of , sorry for the flood .


Le 28/04/2022 à 09:58, alain a écrit :


re ,

up .


Le 27/04/2022 à 13:02, alain a écrit :


hello alexander pevzner .

I will try to answer your 4 questions clearly:

1) combinations that work :
- stable core with stable ipp-usb
- kernel testing / sid with ipp-usb stable

2) combinations that definitely don't work:
- kernel testing / sid with ipp-usb (testing / sid version)

3) when it works, it works constantly.
system-config-printer is constantly fully functional.

4) when it doesn't work, it's definitive. it doesn't work.

I answered your questions as you wanted?
Did it help you ?

friendly,
respectfully,
alain.



Translated with www.DeepL.com/Translator (free version)

Le 27/04/2022 à 11:45, Alexander Pevzner a écrit :


 1. Is there any configuration (combination of kernel version and
ipp-usb version), that *definitely works*?
 2. Is there any configuration, that *definitely doesn't work*?
 3. When it works, does it work reliable or time to time?
 4. When it doesn't work, doesn't it work always or time to time?

Bug#1008997: [OpenPrinting/ipp-usb] ipp-usb is not ready for this device (Issue #48)

2022-04-28 Thread alain


re ,

up .


Le 27/04/2022 à 13:02, alain a écrit :


hello alexander pevzner .

I will try to answer your 4 questions clearly:

1) combinations that work :
- stable core with stable ipp-usb
- kernel testing / sid with ipp-usb stable

2) combinations that definitely don't work:
- kernel testing / sid with ipp-usb (testing / sid version)

3) when it works, it works constantly.
system-config-printer is constantly fully functional.

4) when it doesn't work, it's definitive. it doesn't work.

I answered your questions as you wanted?
Did it help you ?

friendly,
respectfully,
alain.



Translated with www.DeepL.com/Translator (free version)

Le 27/04/2022 à 11:45, Alexander Pevzner a écrit :


 1. Is there any configuration (combination of kernel version and
ipp-usb version), that *definitely works*?
 2. Is there any configuration, that *definitely doesn't work*?
 3. When it works, does it work reliable or time to time?
 4. When it doesn't work, doesn't it work always or time to time?

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

2022-04-28 Thread Salvatore Bonaccorso

Hi,

On Thu, Apr 28, 2022 at 12:04:50AM +0200, Francesco C wrote:
> Hi ,
> 
> 5.16 series is EOL so I've just continued to do tests with vanilla
> linux-5.17.4 and linux-5.17.5 : both do not boot and stop at the same
> point as indicated in the messages above _but_ ... something strange
> is happening also with longterm 5.15 series since version 5.15.35 and
> 5.15.36 do not boot too.

Now this gives us probably a good hint!

https://bugzilla.kernel.org/show_bug.cgi?id=215909

d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state")
and a followup commit bfe55a1f7fd6 ("ACPI: processor: idle: fix lockup
regression on 32-bit ThinkPad T40") were both applied to 5.15.35. I
suspect the former is the one so which causes the regression as well
for you.

If someone can can check if reverting the commit d6b88ce2eb9d helps,
this might need a similar solution for your problem as it was done for
the ThinkPad T40.

Regards,
Salvatore

Bug#1010290: nmu: libtsm_4.0.2-0.1