Bug#1009891: hexchat locks up hard when connecting to bip server

[duck]

Quack Seven,

I'm involved with bip packaging and upstream and we wondered what 
version of bip you are using. Did you upgrade bip recently?
We have yet no reason to think that it could be triggered by a bug in 
bip, just checking. Clearly hexchat should behave better anyway.


Can you reproduce this problem by connecting directly to the IRC server?

Regards.
\_o<

--
Marc Dequènes

Bug#1009892: ITP: mkdocstrings -- Automatic Python documentation from sources for MkDocs

[Carsten Schoenert]

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

* Package name: mkdocstrings
  Version : 0.17.0
  Upstream Author : Timothée Mazzucotelli 
* URL : https://github.com/mkdocstrings/mkdocstrings
* License : ISC
  Programming Lang: Python
  Description : Automatic Python documentation from sources for MkDocs

 MkDocs is a fast, simple and downright gorgeous static site generator
 that's geared towards building project documentation. Documentation
 source files are written in Markdown, and configured with a single YAML
 configuration file.
 .
 This package contains an plugin for MkDocs to build automatic documentation
 from docstrings within your source code files.

This package is a new direct dependency for the recent released minor
version of NetBox 3.2.x.

It will be maintained within the Debian Python Team.

Bug#867977: youtube-dl: Arbitary JavaScript execution?

[Andres Salomon]

On Mon, 10 Jul 2017 22:02:20 +0200 =?utf-8?q?Joonas_Kylm=C3=A4l=C3=A4?= 
wrote:

> Package: youtube-dl
> Version: 2017.05.18.1-1
> Severity: normal
>
> Dear Maintainer,
>
> Recently Trisquel GNU/Linux users discovered that youtube-dl might in
> some cases execute (as far as I understood) arbitary JavaScript served
> by the web server it connects to, and thus be harmful for the
> user. See
> . Can
> we somehow work around these JavaScript requirements? At least I think
> it would be a good thing to warning the user about arbitary JavaScript
> being run as I, for example, didn't expect that a cli application
> would run JavaScript.
>
> Joonas


There's a further discussion about this linked from that trisquel page, 
with further interesting details and logic:


https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-07/msg3.html

Bug#1009893: gzip FTCBFS for amd64 -> i386: time_t detection fails

[Helmut Grohne]

Source: gzip
Version: 1.12-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gzip fails to cross build from source when building for i386 on amd64.
In this scenario, ./configure does not detect a cross build and thinks
we are doing a native build on i386. When it comes to detecting time_t,
it notices that time_t is Y2038-buggy. It then looks into whether files
can represent larger timestamps and concludes that time_t should be
working. This later logic is guarded by a test for cross compiling and
would be skipped if a cross build were to be detected. On real native
i386, the test with a file fails and prevents the failure. The easy
solution here is to explicitly pass the build architecture thus fixing
the cross compilation detection. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru gzip-1.12/debian/changelog gzip-1.12/debian/changelog
--- gzip-1.12/debian/changelog  2022-04-10 04:22:26.0 +0200
+++ gzip-1.12/debian/changelog  2022-04-20 06:58:46.0 +0200
@@ -1,3 +1,10 @@
+gzip (1.12-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS from 64bit to 32bit: Pass --build to configure (closes: #-1)
+
+ -- Helmut Grohne   Wed, 20 Apr 2022 06:58:46 +0200
+
 gzip (1.12-1) sid; urgency=high
 
   * new upstream release
diff --minimal -Nru gzip-1.12/debian/rules gzip-1.12/debian/rules
--- gzip-1.12/debian/rules  2022-04-09 04:15:18.0 +0200
+++ gzip-1.12/debian/rules  2022-04-20 06:58:45.0 +0200
@@ -53,7 +53,7 @@
--disable-silent-rules
 
 ifneq (${DEB_BUILD_ARCH},${DEB_HOST_ARCH})
-CONFIGURE_ARGS+=   --host=${DEB_HOST_GNU_TYPE}
+CONFIGURE_ARGS+=   --build=${DEB_BUILD_GNU_TYPE} 
--host=${DEB_HOST_GNU_TYPE}
 endif
 
 reconf-stamp:

Bug#994151: New release

[Andreas Tille]

Hi Andreas,

Am Tue, Apr 19, 2022 at 05:45:46PM -0400 schrieb Andres Salomon:
> 
> I don't know what the current status of upstream is, but if youtube-dl
> upstream continues - I would be happy to help co-maintain the package. I'd
> can also do stable updates if it breaks, although it's currently working for
> me in bullseye.

Great.  Just add yourself to Uploaders and do what you consider
sensible to do. ;-)

Thanks a lot for stepping in

  Andreas.

-- 
http://fam-tille.de

Bug#1009891: hexchat locks up hard when connecting to bip server

[Steven Rostedt]

Package: hexchat
Version: 2.16.0-4+b2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When connecting hexchat to my bip server it locks up hard. It use to
work fine, until I upgraded to 2.16. The bip server connects to
OFTC, and when I connect to it, the application just stops. That is
the screen is blank, none of the buttons react to anything.

When I do: ps -efL | grep hexchat:
rostedt 850968458509  04 22:19 ?00:00:00 hexchat
rostedt 850968458521  04 22:19 ?00:00:00 hexchat
rostedt 850968458522  04 22:19 ?00:00:00 hexchat
rostedt 850968458550  04 22:19 ?00:00:00 hexchat

Then look at:

$ cat /proc/8509/wchan
futex_wait_queue

$ cat /proc/8521/wchan
do_sys_poll

$ cat /proc/8522/wchan
do_sys_poll

$ cat /proc/8550/wchan
do_sys_poll

It appears that a thread holds a futex (pthread_mutex?) and is then doing
a poll() system call and never returning. The main thread is then
stuck doing nothing, and the application hangs. The only way to stop it
is to send a signal to it.

It connects to other servers fine, just not my bip proxy. But it
use to work before this upgrade. I do not remember what the older version
was, but I upgrade my system once a month, so whatever the debian
version of it was back in March was the last version that worked for me.

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

Kernel: Linux 5.17.3-custom (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hexchat depends on:
ii  hexchat-common   2.16.0-4
ii  libc62.33-7
ii  libcanberra0 0.30-10
ii  libdbus-glib-1-2 0.112-2
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.0-1+b1
ii  libgtk2.0-0  2.24.33-2
ii  libpango-1.0-0   1.50.6+ds-2
ii  libssl1.11.1.1k-1+deb11u2
ii  libx11-6 2:1.7.5-1

Versions of packages hexchat recommends:
ii  ca-certificates  20211016
ii  hexchat-lua  2.16.0-4+b2
ii  hexchat-perl 2.16.0-4
ii  hexchat-plugins  2.16.0-4+b2
ii  hexchat-python3  2.16.0-4+b2
ii  libglib2.0-bin   2.72.0-1+b1

Versions of packages hexchat suggests:
ii  hexchat-otr  0.2.2-3
pn  unifont  

-- no debconf information

Bug#1003135: resolvconf: prevents wifi.sncf from being resolved

[Vincent Lefevre]

On 2022-04-20 01:21:23 +0300, Michael Tokarev wrote:
> 20.04.2022 00:55, Vincent Lefevre wrote:
> > If I stop unbound, then I still get hostname resolution. But if I only
> > have
> > 
> > nameserver 127.0.0.1
> > 
> > and unbound is stopped, then hostname resolution no longer works.
> > This shows that 192.168.1.1 is used as a fallback.
> 
> So this is all about resolvconf: it should have a way to treat some
> nameservers as "fallback-only" and not propagate them to local nameservers.

Yes, I recall that I initially reported the bug against resolvconf.
But Andrej Shadura eventually reassigned it to unbound, implying
that unbound was doing that with its resolvconf integration. So
this is really confusing.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-20 01:03:36 +0300, Michael Tokarev wrote:
> 20.04.2022 00:58, Vincent Lefevre wrote:
> > On 2022-04-20 00:43:48 +0300, Michael Tokarev wrote:
> > > 20.04.2022 00:40, Vincent Lefevre wrote:
> > > 
> > > > > Well, systemd already have its own nameserver configuration and its
> > > > > own resolver cache which does not need any reload of daemons, since
> > > > > resolv.conf does not change (It does not change with resolvconf and
> > > > > unbound running with resolvconf hook enabled, either, and postfix
> > > > > already needs no restart).
> > > > 
> > > > But AFAIK, it doesn't have a way to fall back to the nameservers
> > > > provided by DHCP.
> > > 
> > > Yes. Neither does unbound or other nameservers shipped in Debian,
> > > because there's just no _notion_ of "fall back".
> > 
> > Wrong. The normal use of /etc/resolv.conf via glibc does
> > (so, assuming that resolvconf is not installed).
> > See additional information in my mail to bug 1003135.
> 
> glibc is not a nameserver, Vincent.  Please actually read what I write
> before saying I'm wrong.

glibc is not a nameserver, but it provides functions to resolve
hostnames. This is what applications see.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1006863: tevent: reproducible-builds: build path embedded in various libraries

[Vagrant Cascadian]

On 2022-03-13, Andrew Bartlett wrote:
> On Sat, 2022-03-12 at 13:53 -0800, Vagrant Cascadian wrote:
>> Originally reported as https://bugs.debian.org/1006863 where I proposed
>> passing additional arguments via CFLAGS in the debian build system.
>> 
>> Attached is a proof of concept patch that works by adding the argument
>> to CFLAGS by patching the upstream buildsystem.
>> 
>> The patch is bit ugly in how it derives the top level source directory
>> and likely error-prone... a cleaner way of going about that would be
>> much appreciated!
>> 
>> It also requires gcc 8+ or clang 10+ ... making it detect weather the
>> argument was supported and only adding it conditionally might be
>> desireable.
>
> testflags=True should be doing that, the CI should help determine if
> that works for this option.

Excellent!


>> I am not too familiar with samba project processes, let me know if
>> there's a better place to send this!
>
> https://wiki.samba.org/index.php/Contribute shows how to open a Merge
> Request for samba.  Once you get a gitlab username let me know and you
> can skip to using our shared development repo for a full CI.

Ok, I've got:

  https://gitlab.com/vagrantc

I'll work on som e updated patches.

Should it be a merge request into the samba repository or tevent, or is
there a better place for it?


> conf.env.srcdir should get you the srcdir you need.

Yes, that worked well, thanks!


> I guess my main concern is once Samba is packaged etc, can we still get
> a full backtrace?  How does this interact with debug packages etc?

I think the short answer is yes, although it may require passing
arguments to the debugger:

   
https://stackoverflow.com/questions/67191647/using-ffile-prefix-map-breaks-debugging

Both gdb and lldb allow you to set the path to the source code.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1008849: shiboken2 - Needs tighter dependency on python3

[Yuri D'Elia]

On Wed, Apr 13 2022, Nicholas D Steeves wrote:
> I understand, and agree that the issue is real, and that a rebuild is
> required.  A binNMU is the most expedient solution ;-)  Please read
> "What are binNMUs?" at the link provided above...

Yes, but I wouldn't call this "expedient", since ...

> Kurt, this is the point I'm wondering about, because it would be better
> if the transition tracker would alert us of outstanding issues rather
> than waiting for someone to report breakage.  If this isn't feasible,
> could you document that fact in the source package?

... we're waiting for somebody to report the unavoidable breakage, since
shiboken2 enforces this through a minor version check (we're not hoping
it will work - it will just refuse to work).

That would be a "grave" bug report from that perspective, not too
dissimilar to any ABI breakage rendering downstream users _and_ packages
unusable until fixed.

> This might be by design.  Kurt, do you know?  There's also the question
> of if pyside2/shiboken2 is even py3.10-ready (I haven't tested yet).

Answering this for an hypothetical 3.11 transition, the answer would
similarly be "likely doesn't matter - it's worth attempting a build and
hope for the best, because the current version is broken".

> As a general principle, I worry that this would either reduce
> functionality and/or debugging, or introduce regression potential, so
> this is not a change I'm willing to make as a team member and not
> as one of the primary maintainers/uploaders of pyside2.

I understand this. And the documentation around this define is lacking
as well. Looking at the sources, it does seem to reduce the number of
exported methods, so it is fair to say we might have users that expect
the full API to be available and would break if used...

Bug#1009890: libqca-qt5: QCA::startDecrypt() doesn't ask for a pass phrase

[Ron Murray]

Package: libqca-qt5-2
Version: 2.3.4-1
Severity: normal
File: libqca-qt5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   I'm writing an app that can use PGP/GPG to encrypt entries, and,
since the rest of the app is written in Qt5, I chose to use QCA for
that part.

   My code (the relevant part, anyway) looks like this:

QByteArray message = content.toLocal8Bit();

QCA::OpenPGP gpg;
QCA::SecureMessage msg();

msg.startDecrypt();
msg.update(message);
msg.end();
msg.waitForFinished(-1);

   When I try to decrypt a GPG entry with this code, it returns
"ErrorUnknown", which I take to indicate that it doesn't have a
passphrase for the secret key. It certainly didn't ask for one.

   It is interesting, however, that if I use the command-line gpg to
decrypt a file using the same secret key (and get asked for a
pass phrase), I can go back to my app, try to decrypt the same PGP
entry again, and it works, because gpg-agent still contains the pass
phrase until it times out.

   So it seems that QCA can access pass phrases in gpg-agent, but it's
unable to request a pinentry from gpg-agent to collect a pass phrase
otherwise. I did manage to catch an invocation of gpg while my app was
decrypting a largish file, and perhaps that's relevant. It's

/usr/bin/gpg --no-tty --pinentry-mode loopback --fixed-list-mode \
- --with-colons --with-fingerprint --with-fingerprint --list-public-keys

   Looking through the documentation, I don't see anything related to
collecting pass phrases for secret keys, but it's possible that I
missed it. Please let me know if that's the case.

 .Ron

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

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

Versions of packages libqca-qt5-2:amd64 depends on:
ii  libc6 2.33-7
ii  libgcc-s1 12-20220319-1
ii  libqt5core5a  5.15.2+dfsg-16
ii  libstdc++612-20220319-1

Versions of packages libqca-qt5-2:amd64 recommends:
ii  ca-certificates   20211016
ii  libqca-qt5-2-plugins  2.3.4-1

libqca-qt5-2:amd64 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmJfOwcOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52G3Ow//a+u92Kix9NZ17BhIvi86d3U076pDxMi+zMql
2T1UixZqTerckymfWiP63KYgV8FLFEZihdby2bgNYvgc17bmAcG6AL7/pAFwaQc2
6S2f+90nxggOCfyW+6BggkttIBZ5uJPVmdrjQnonk7cgpPn+NFHhpBMFcP1J0bFv
x7uvG/Q/NTjB+cpMvdyn1EuHDtxL+qimnCdPEvzUjmz1tVe0DlP0sXdRG2Wr+HwS
KKB5IzsDE2b2Ysa2N4alfYcQ0ioraD1Y9Xt1IU1jd0aRTEwwUmM655PMqNg6pCv7
mcBZH3Jf0+sPkxjR2NT+NyF7hbGg2JbMaxIINex9rWRXMG6TJDVDBvw6tWuzxnat
RJYPNWS82Y1ZOjNmkqAbVMmpaD7bT+s1wyd5I/NZE6Roviu+ubvohw2XI2PETwJy
XAds4jr96Oxy6VYvSWqdUoVYvy96EvnoMFLsYTy+nRjwva3qJbkKe0eWNknKs99s
CHsIvHQC6fqnFkuNRQsowVCDJAPHLz6M39f2Pw/RqvEH28qwFkguE2+rWjy6MP93
WTthn0aIVjrxw702qsf2s1eG9/BnY4RbHOhYpV3m4D5QYhg6D67MEuygnS+xJly8
mbG1XT52mnjCexqWU5kt9S7KhjPo7sj29P+/T3nvLdi+tZQAzxg31b62pmcNm+j8
eVgw0xE=
=ZfLf
-END PGP SIGNATURE-

Bug#563340: libsasl2-modules-sql: Please add a sql_defaultrealm option.

[Bastian Germann]

Control: tags -1 moreinfo

This patch still applies on 2.1.18 with fuzz.
It does not appear in upstream's issues or pull requests.

Somebody will need to document it properly and propose it to
upstream again if there is still interest to get this into Debian.
However, I will only take such a new feature via upstream.

Bug#1009889: bind9 depends on too old libuv1 package

[DC-1]

Package:  bind9
Version: 1:9.16.27-1~deb11u1

I've started to upgrading stretch to bullseye, and noticed that bind9
depends on libuv1 (>= 1.4.2) which is rather old. It causes
named[22885]: udp.c:229: fatal error:
named[22885]: udp.c:229: fatal error: uv_udp_init_ex failed: invalid argument
named[22885]: udp.c:229: fatal error: uv_udp_init_ex failed: invalid argument
named[22885]: uv_udp_init_ex failed: invalid argument
named[22885]: exiting (due to fatal error in library)

...because of old libuv1=1.9.1-3. It's still newer than the recommended 1.4.2
but it's not enough. Please refresh the dependencies of bind9 package with 
libuv1 (>= 1.40.0-2)

Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package

[Peter Michael Green]

Package: rust-h2
Version: 0.1.26-1
X-debbugs-cc: d...@jones.dk

I noticed that Jonas had set a number of bugs about broken rust packages as
blockers of 900928, so I decided to take a look at some of them. I fixed up
bytemuck, image and related packages.

I then started looking at reqwest which lead me to h2 (which has been broken
since the tokio 1.x transition but noone ever got around to filing a 
bug) which

lead me to http which jonas recently NMU'd.

I feel I need to comment on the technical details of the NMU, I should 
preface

this by saying that I don't think it's unreasonable to 0-day NMU a minimal
fix for a long term RC issue, even if (as was not the case here but was the
case for some of the other NMUs noone ever bothered to actually file the
RC bug).

However, this NMU did considerably more than just add a minimal fix for
the rc issue. Most painfullly, the "orig" tarball for the new upstream 
version

appears to have been derived from upstream git rather than from crates.io
and this breaks our workflow. If you are going to 0-day stuff please keep
your uploads minimal. If you want to do more invasive NMUs please give
the maintainers a chance to respond.

Fortunately it seems the answer is to move to an even newer upstream
version. The only reverse dependencies of rust-http seem to be the
h2/hyper stack which badly needs an update to move away from tokio
0.x. I have already committed the http update to debcargo-conf and may
upload it at some point.

Unfortunately moving back up the stack I ran into another issue. h2 and
hyper have grown a new dependency on tracing. While I am I am happy to
help with fixing existing rust packages, I am reluctant to take 
responsibility

for a new package unless it's something I personally use.

So this is where I personally tap out on h2/hyper until/unless someone
packages tracing.

Bug#1009887: ITP: proftpd-mod-kafka -- ProFTPD module mod_kafka

[Hilmar Preuße]

Package: wnpp
Severity: wishlist
Owner: Hilmar Preusse 
X-Debbugs-Cc: debian-de...@lists.debian.org, ProFTPD Maintainance Team 


* Package name: proftpd-mod-kafka
  Version : 0.1-1
  Upstream Author : TJ Saunders 
* URL : https://github.com/Castaglia/proftpd-mod_kafka
* License : GPL2+
  Programming Lang: C++
  Description : ProFTPD module mod_kafka

 The mod_kafka module for ProFTPD allows for sending log messages, as JSON,
 to Kafka brokers using the librdkafka client library.

 See the mod_kafka.html documentation for more details.

More information:
 - The package might be useful for people, who would like to
   collect logs of proftp servers in a central data instance.
 - I intend to maintain it as a member of the the "ProFTPD
   Maintainance Team".

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

20.04.2022 00:58, Vincent Lefevre wrote:

On 2022-04-20 00:43:48 +0300, Michael Tokarev wrote:

20.04.2022 00:40, Vincent Lefevre wrote:


Well, systemd already have its own nameserver configuration and its
own resolver cache which does not need any reload of daemons, since
resolv.conf does not change (It does not change with resolvconf and
unbound running with resolvconf hook enabled, either, and postfix
already needs no restart).


But AFAIK, it doesn't have a way to fall back to the nameservers
provided by DHCP.


Yes. Neither does unbound or other nameservers shipped in Debian,
because there's just no _notion_ of "fall back".


Wrong. The normal use of /etc/resolv.conf via glibc does
(so, assuming that resolvconf is not installed).
See additional information in my mail to bug 1003135.


glibc is not a nameserver, Vincent.  Please actually read what I write
before saying I'm wrong.

/mjt

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-20 00:43:48 +0300, Michael Tokarev wrote:
> 20.04.2022 00:40, Vincent Lefevre wrote:
> 
> > > Well, systemd already have its own nameserver configuration and its
> > > own resolver cache which does not need any reload of daemons, since
> > > resolv.conf does not change (It does not change with resolvconf and
> > > unbound running with resolvconf hook enabled, either, and postfix
> > > already needs no restart).
> > 
> > But AFAIK, it doesn't have a way to fall back to the nameservers
> > provided by DHCP.
> 
> Yes. Neither does unbound or other nameservers shipped in Debian,
> because there's just no _notion_ of "fall back".

Wrong. The normal use of /etc/resolv.conf via glibc does
(so, assuming that resolvconf is not installed).
See additional information in my mail to bug 1003135.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1003135: resolvconf: prevents wifi.sncf from being resolved

[Vincent Lefevre]

On 2022-04-19 23:33:06 +0300, Michael Tokarev wrote:
> On Wed, 5 Jan 2022 16:36:40 +0100 Vincent Lefevre  wrote:
> ..
> > But I don't understand. The upstream nameservers are supposed to be
> > used as a fallback. Even if upstream nameservers do not perform DNSSEC
> > validation, this is still better than a failure when DNSSEC is not
> > required.
> 
> For the record, this is incorrect, just like has been stated in #1004032
> numerous times already.
> 
> The upstream nameservers provided by DHCP were never supposed to be used
> as a "fallback", even more, there's no _notion_ of a "fallback" in this
> context.
> 
> We EITHER use the DHCP-provided nameservers, OR we use the regular recursive
> way.  But not both.
> 
> I know no recursive resolver software which has notion of "fallback" like
> this.

Without resolvconf installed, it appears to work: if unbound cannot
resolv the hostname, then the next nameserver in /etc/resolv.conf is
used.

For instance, I currently have in /etc/resolv.conf:

nameserver 127.0.0.1
nameserver 192.168.1.1

If I stop unbound, then I still get hostname resolution. But if I only
have

nameserver 127.0.0.1

and unbound is stopped, then hostname resolution no longer works.
This shows that 192.168.1.1 is used as a fallback.

And something like "strace wget ... |& grep sin_addr=inet_addr" also
confirms this behavior.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#994151: New release

[Andres Salomon]

On Sun, 19 Dec 2021 14:54:12 +0100 Adrien CLERC wrote:
> Hi,
>
> As a matter of fact, there was a new release 3 days ago:
> https://github.com/ytdl-org/youtube-dl/releases/tag/2021.12.17
>
> However, the main maintainer remove himself from the list of active
> developers:
> 
https://github.com/ytdl-org/youtube-dl/commit/21b759057502c6e70d51011cfb3fb86d84055182

>
> So, I guess this is time to move to something else.
>
> Adrien


I don't know what the current status of upstream is, but if youtube-dl 
upstream continues - I would be happy to help co-maintain the package. 
I'd can also do stable updates if it breaks, although it's currently 
working for me in bullseye.

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-19 19:11:42 +0300, Michael Tokarev wrote:
> 19.04.2022 17:49, Vincent Lefevre wrote:
> ..
> > > I don't think this is in the scope of resolvconf people, because
> > > the whole purpose of resolvconf is different.
> > 
> > I don't know what you mean here. In my case, the purpose of resolvconf
> > is just to restart postfix each time /etc/resolv.conf is modified
> 
> resolvconf does not "check" updates of resolv.conf, it *manages*
> resolv.conf and maintains a list of available nameservers, including
> nameservers provided by DHCP.

My point is that the postfix package provides a resolvconf hook to
restart postfix when /etc/resolv.conf changes:
/etc/resolvconf/update-libc.d/postfix

This is why resolvconf is the recommended way to make sure that
postfix uses up-to-date nameservers.

> Well, systemd already have its own nameserver configuration and its
> own resolver cache which does not need any reload of daemons, since
> resolv.conf does not change (It does not change with resolvconf and
> unbound running with resolvconf hook enabled, either, and postfix
> already needs no restart).

But AFAIK, it doesn't have a way to fall back to the nameservers
provided by DHCP.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

20.04.2022 00:40, Vincent Lefevre wrote:


Well, systemd already have its own nameserver configuration and its
own resolver cache which does not need any reload of daemons, since
resolv.conf does not change (It does not change with resolvconf and
unbound running with resolvconf hook enabled, either, and postfix
already needs no restart).


But AFAIK, it doesn't have a way to fall back to the nameservers
provided by DHCP.


Yes. Neither does unbound or other nameservers shipped in Debian,
because there's just no _notion_ of "fall back".

Thanks,

/mjt

Bug#1009886: cargo: autopkgtest failure on ppc64el

[Sebastian Ramacher]

Source: cargo
Version: 0.57.0-5
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

cargo fails to migrate due to an autopkgtest failure on ppc64el:

error: could not compile `cargo` due to previous error
warning: build failed, waiting for other jobs to finish...
error: linking with `cc` failed: exit status: 1
  |
  = note: "cc" "-m64" 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.105aqhkkj5npu4h3.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.10jt1ius0k2cltvb.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.13jkfyh8pw2ug2r2.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.14n1glj3u0lo40e4.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.14p2ag9meabq90fv.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.159a8pdj3tzi5dud.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.15mosqd8utrqi1ml.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.163fjwq685f8yrrm.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.16yd30y9naudnkmd.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.17j4teldp82ihcjw.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.17m2ngr4wl3l1r20.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.17vvpayder0895fc.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.188s2ikcjax07pap.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.19nq0tt1my97sq98.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1cjlcvzjlf7ff3rg.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1clyzrngs47wapfl.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1d9m3n6kqyqgt665.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1e3xet9dpki5yp7.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1ewfciuwo3oxzcdr.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1f0adcv69ddmkxxw.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1fbe5jxdoz5c7uu6.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1fe6tyf5pm85q960.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1i1l1rnzugokryl9.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1i6lr7g2neq45u1h.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1jdnpq6ggj3gnyex.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1jllbaeoewnrxtbx.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1jt054uto9o35xh7.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1k0c5k32wom7zvma.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1kfmlvdn5yykki49.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1kvfc9kmo2y2kr1z.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1m7baly2vpd9djv0.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1nt9gs9hmawlgvty.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1nxdwf0uul0ddxyh.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1ot0xyxi5uypaet2.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1otctgr0qqdscqmz.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1pnw8lkvxki8qi56.rcgu.o"
 
"/tmp/autopkgtest-lxc.1c_v4y20/downtmp/build.v7Z/src/target/debug/deps/testsuite-19fcb54c09ec86fc.1pr41ls0jw3b9uwv.rcgu.o"
 

Bug#989959: closed by Debian FTP Masters (reply to Michael Tokarev ) (Bug#989959: fixed in unbound 1.15.0-2)

[Michael Tokarev]

19.04.2022 23:38, Dennis Filder wrote:

I wasn't CC'ed, thus the late reply.


I didn't know either, Dennis. I just replied to the bug :)


But now I've a question: how the initial problem happened?

Okay, it smells like it is, and it definitely it should not be
copied from /usr/share/dns/root.key..


What can I say?  My /var partition became full (too many .deb files
IIRC) and unbound.service wouldn't start because of an unusable trust


Yeah, I see it quite well now how exactly things went wrong, and
you confirm my thoughts.

And the root cause was using install/cp to create the file, --
neither of which do it atomically. So any error during the
copy and we'll have some bad file out there. Even for a small
file like this - today we have filesystems with inline data,
when small files are written directly into the directory,
and only for larger files a real extent is allocated, -
this root.key is enough to flip from inline to extent (which
we might not have).


anchor file (which was empty).  How exactly that happened I have no
idea.  It may have been from unbound trying to replace root.key with
its own changes and failing, but looking at the code
(validator/autotrust.c:autr_write_file()) that should have left the
old version in place upon failure.  So maybe it was from
package-helper trying to copy over the existing file for some other


It definitely is. Because install/cp which was used.
...

As far as I see it a problem also was that (in the old version) after
the reboot the package-helper script only tried to overwrite
/var/lib/unbound/root.key when it was older than


Because no one thought about possible partial file in there.
It should never be partial.  And this update ensures just that.
Well, there still *is* a possibility here, but I don't know if
any real modern filesystem allows this: a file should be comitted
to disk before the final rename completes.

...

Am I right this is just the initial key and unbound updates this key
automatically by its own?


I think so, but I'm not sure.  My knowledge of both unbound and the
details of DNSSEC is rather spotty.


It is the initial value and unbound will keep it updated.


P.S.: I also noticed that unbound.service under [Service] defines no
StateDirectory=/var/lib/unbound to ensure that it is mounted on start.


Hmm this is a good idea to add this.


The chroot setup procedure has its own load of issues.


I see.  Maybe adding just

After=var.mount var-lib.mount var-lib-unbound.mount


I think StateDirectory helps here.

Thank you!

/mjt

Bug#1009885: qbittorrent:src fails to build using dpkg-buildpackage, reports it can't find '-l-pthread'

[Raphael Marion Pilgrim]

Source: qbittorrent
Version: 4.4.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: raphael.marion.pilg...@gmail.com

Relevant part of the build log:
linking qbittorrent-nox
/usr/bin/ld : ne peut pas trouver -l-pthread : Aucun fichier ou dossier de ce 
type
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:680 : qbittorrent-nox] Erreur 1
make[3] : on quitte le répertoire « 
/home/ramapi/Workspace/Deb/qbittorrent-4.4.2/build-nox/src »
make[2]: *** [Makefile:47 : sub-src-make_first] Erreur 2
make[2] : on quitte le répertoire « 
/home/ramapi/Workspace/Deb/qbittorrent-4.4.2/build-nox »
dh_auto_build: error: cd build-nox && make -j4 returned exit code 2
make[1]: *** [debian/rules:19 : override_dh_auto_build] Erreur 2
make[1] : on quitte le répertoire « 
/home/ramapi/Workspace/Deb/qbittorrent-4.4.2 »
make: *** [debian/rules:7 : build] Erreur 2
dpkg-buildpackage: erreur: debian/rules build subprocess returned exit status 2
E: La commande de construction « cd qbittorrent-4.4.2 && dpkg-buildpackage -b 
-uc » a échoué.



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

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

Bug#1009884: pulseaudio uses 10%--20% of CPU even when no sound is played

[Maxime Devos]

Package: pulseaudio
Version: 14.2-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Some time ago (I guess a month?), I noticed the fans didn't stop spinning even
when I'm not doing anything on the computer.  Looking at the output of
gnome-system-monitor, it appears that pulseaudio is using 17% of one CPU.
(It's only using a single CPU, according to the graphs).
The other CPUs are at 0%.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

To investigate a bit, I ran strace (from htop) on pulseaudio.
I noticed it does:

[start of output]
strace: Process 3615 attached
ppoll([{fd=4, events=POLLIN}, {fd=45, events=POLLIN}, {fd=49, events=POLLIN}, 
{fd=44, events=POLLIN}, {fd=46, events=POLLIN}, {fd=21, events=POLLIN}, {fd=29, 
events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=41, 
events=POLLIN}, {fd=38, events=POLLIN}, {fd=9, events=POLLIN}, {fd=35, 
events=POLLIN}, {fd=33, events=POLLIN}, {fd=32, events=POLLIN}, {fd=16, events=P
OLLIN}, {fd=31, events=POLLIN}, {fd=3, events=POLLIN}, {fd=30, 
events=POLLIN|POLLERR|POLLHUP}, {fd=30, events=0}, {fd=24, events=POLLIN}, 
{fd=27, events=POLLIN}, {fd=17, events=POLLIN}, {fd=20, events=POLLIN}, {fd=15, 
events=POLLIN|POLLERR|POLLHUP}, {fd=15, events=0}, {fd=14, events=POLLIN}, 
{fd=13, events=POLLIN}, {fd=7, events=POLLIN}], 29, NULL, NULL, 8) = 1 
([{fd=20, revents
=POLLIN}])
read(20, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "W", 1)= 1
read(4, "W", 10)= 1
write(40, "\1\0\0\0\0\0\0\0", 8)= 8
read(4, 0x7ffddf14e70e, 10) = -1 EAGAIN (Hulpbron is tijdelijk 
onbeschikbaar)
ppoll([{fd=4, events=POLLIN}, {fd=45, events=POLLIN}, {fd=49, events=POLLIN}, 
{fd=44, events=POLLIN}, {fd=46, events=POLLIN}, {fd=21, events=POLLIN}, {fd=29, 
events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=41, 
events=POLLIN}, {fd=38, events=POLLIN}, {fd=9, events=POLLIN}, {fd=35, 
events=POLLIN}, {fd=33, events=POLLIN}, {fd=32, events=POLLIN}, {fd=16, events=P
OLLIN}, {fd=31, events=POLLIN}, {fd=3, events=POLLIN}, {fd=30, 
events=POLLIN|POLLERR|POLLHUP}, {fd=30, events=0}, {fd=24, events=POLLIN}, 
{fd=27, events=POLLIN}, {fd=17, events=POLLIN}, {fd=20, events=POLLIN}, {fd=15, 
events=POLLIN|POLLERR|POLLHUP}, {fd=15, events=0}, {fd=14, events=POLLIN}, 
{fd=13, events=POLLIN}, {fd=7, events=POLLIN}], 29, NULL, NULL, 8) = 1 
([{fd=29, revents
=POLLIN}])
read(29, "\1\0\0\0\0\0\0\0", 8) = 8
write(18, "\1\0\0\0\0\0\0\0", 8)= 8
read(4, 0x7ffddf14e70e, 10) = -1 EAGAIN (Hulpbron is tijdelijk 
onbeschikbaar)
ppoll([{fd=4, events=POLLIN}, {fd=45, events=POLLIN}, {fd=49, events=POLLIN}, 
{fd=44, events=POLLIN}, {fd=46, events=POLLIN}, {fd=21, events=POLLIN}, {fd=29, 
events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=41, 
events=POLLIN}, {fd=38, events=POLLIN}, {fd=9, events=POLLIN}, {fd=35, 
events=POLLIN}, {fd=33, events=POLLIN}, {fd=32, events=POLLIN}, {fd=16, events=P
OLLIN}, {fd=31, events=POLLIN}, {fd=3, events=POLLIN}, {fd=30, 
events=POLLIN|POLLERR|POLLHUP}, {fd=30, events=0}, {fd=24, events=POLLIN}, 
{fd=27, events=POLLIN}, {fd=17, events=POLLIN}, {fd=20, events=POLLIN}, {fd=15, 
events=POLLIN|POLLERR|POLLHUP}, {fd=15, events=0}, {fd=14, events=POLLIN}, 
{fd=13, events=POLLIN}, {fd=7, events=POLLIN}], 29, NULL, NULL, 8) = 1 
([{fd=20, revents
=POLLIN}])
read(20, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "W", 1)= 1
read(4, "W", 10)= 1
write(40, "\1\0\0\0\0\0\0\0", 8)= 8
read(4, 0x7ffddf14e70e, 10) = -1 EAGAIN (Hulpbron is tijdelijk 
onbeschikbaar)
ppoll([{fd=4, events=POLLIN}, {fd=45, events=POLLIN}, {fd=49, events=POLLIN}, 
{fd=44, events=POLLIN}, {fd=46, events=POLLIN}, {fd=21, events=POLLIN}, {fd=29, 
events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=41, 
events=POLLIN}, {fd=38, events=POLLIN}, {fd=9, events=POLLIN}, {fd=35, 
events=POLLIN}, {fd=33, events=POLLIN}, {fd=32, events=POLLIN}, {fd=16, events=P
OLLIN}, {fd=31, events=POLLIN}, {fd=3, events=POLLIN}, {fd=30, 
events=POLLIN|POLLERR|POLLHUP}, {fd=30, events=0}, {fd=24, events=POLLIN}, 
{fd=27, events=POLLIN}, {fd=17, events=POLLIN}, {fd=20, events=POLLIN}, {fd=15, 
events=POLLIN|POLLERR|POLLHUP}, {fd=15, events=0}, {fd=14, events=POLLIN}, 
{fd=13, events=POLLIN}, {fd=7, events=POLLIN}], 29, NULL, NULL, 8) = 1 
([{fd=20, revents
=POLLIN}])
read(20, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "W", 1)= 1
read(4, "W", 10)= 1
write(40, "\1\0\0\0\0\0\0\0", 8)= 8
read(4, 0x7ffddf14e70e, 10) = -1 EAGAIN (Hulpbron is tijdelijk 
onbeschikbaar)
ppoll([{fd=4, events=POLLIN}, {fd=45, events=POLLIN}, {fd=49, events=POLLIN}, 
{fd=44, events=POLLIN}, {fd=46, events=POLLIN}, {fd=21, events=POLLIN}, {fd=29, 
events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=41, 
events=POLLIN}, 

Bug#962021: forwarded upstream

[Vagrant Cascadian]

Control: tags 962021 fixed-upstream

On 2020-07-04, Bernhard M. Wiedemann wrote:
> https://gitlab.com/graphviz/graphviz/-/merge_requests/1454
> was easy, because I had the forked repo still around

This was merged upstream:

  
https://gitlab.com/graphviz/graphviz/-/commit/9b758128c20f7a1d3bb2332327269c7d490ef055

Which was included in 2.46.0.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1009857: python3-hy: 'hy' fails to start

[Tianon Gravi]

On Tue, 19 Apr 2022 at 03:30, IOhannes m zmölnig  wrote:
> $ hy3
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/hy/compiler.py", line 1696, in 
> compile_eval_and_compile
> hy_eval(new_expr + body,
>   File "/usr/lib/python3/dist-packages/hy/compiler.py", line 2109, in hy_eval
> eval(ast_compile(_ast, filename, "exec"),
>   File "/usr/lib/python3/dist-packages/hy/compiler.py", line 64, in 
> ast_compile
> return compile(a, filename, mode, hy_ast_compile_flags)
> TypeError: required field "lineno" missing from alias

Unfortunately, I think this is probably a duplicate of #1002344
(definitely the same error message).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#989959: closed by Debian FTP Masters (reply to Michael Tokarev ) (Bug#989959: fixed in unbound 1.15.0-2)

[Dennis Filder]

I wasn't CC'ed, thus the late reply.

> But now I've a question: how the initial problem happened?
>
> Okay, it smells like it is, and it definitely it should not be
> copied from /usr/share/dns/root.key..

What can I say?  My /var partition became full (too many .deb files
IIRC) and unbound.service wouldn't start because of an unusable trust
anchor file (which was empty).  How exactly that happened I have no
idea.  It may have been from unbound trying to replace root.key with
its own changes and failing, but looking at the code
(validator/autotrust.c:autr_write_file()) that should have left the
old version in place upon failure.  So maybe it was from
package-helper trying to copy over the existing file for some other
reason.  Maybe due to the missing StateDirectory=/var/lib/unbound
directive /var was not yet mounted when [ ! -e
"$ROOT_TRUST_ANCHOR_FILE" ] ran fooling the script into thinking it
should update that "missing" file, but became mounted before
/usr/bin/install was invoked which then failed due to missing disk
space leaving behind an empty file.  The "-" in
"ExecStartPre=-/usr/lib/unbound/package-helper root_trust_anchor_update"
then resulted in this error being ignored which would have made it
impossible for me to learn what exactly went wrong.  Again, I have no
way of reconstructing whether it happened like this, I'm just guessing
here.

As far as I see it a problem also was that (in the old version) after
the reboot the package-helper script only tried to overwrite
/var/lib/unbound/root.key when it was older than
/usr/share/dns/root.key or missing, but not when it was empty or
corrupted.  Having package-helper automatically detect and try to
auto-repair that would be a nice convenience to have as then simply
restarting the unit would fix the problem.

> The script (/usr/lib/unbound/package-helper) use install(1) to
> update the file and to chown it (this also smells unsafe from the
> security PoV). And install unlinks the destination file first,
> creates destination file, writes contents to it, and closes it.  It
> looks like we should not use install(1) here, or maybe install it to
> .tmp and mv it atomically, - and from _there_, the problem will just
> go away.
> ...
> Am I right this is just the initial key and unbound updates this key
> automatically by its own?

I think so, but I'm not sure.  My knowledge of both unbound and the
details of DNSSEC is rather spotty.

> > P.S.: I also noticed that unbound.service under [Service] defines no
> > StateDirectory=/var/lib/unbound to ensure that it is mounted on start.
>
> The chroot setup procedure has its own load of issues.

I see.  Maybe adding just

   After=var.mount var-lib.mount var-lib-unbound.mount

would still be worth considering.  It would cause unbound.service to
wait only if these mount units exist.  And since /var/lib/unbound gets
installed as part of the package this should not cause any problems
even if unbound is run in chroot-mode.

Regards.

Bug#1009883: dh_haskell_install_ghc_registration: does not support directories

[Scott Talbert]

Package: haskell-devscripts
Severity: normal

Dear Maintainer,

While attempting to update haskell-attoparsec to upstream release
0.14.4, it was observed that this version of attoparsec produces a
*directory* and not a *file* for its GHC registration.  This currently
fails because of bug #1009873, but after that is fixed, this will still
fail because dh_haskell_install_dhc_registration is searching for:
"Creating package registration file"
where attoparsec produces:
"Creating package registration directory"

And thus will result in "Cannot get package registration file." once the
aforementioned bug is fixed.  It's not quite clear to me how a directory
is supposed to be handled (install each file in the directory?), but perhaps
someone with more familiarity with GHC registrations might know.

Thanks,
Scott

Bug#1003135: resolvconf: prevents wifi.sncf from being resolved

[Michael Tokarev]

On Wed, 5 Jan 2022 16:36:40 +0100 Vincent Lefevre  wrote:
..

But I don't understand. The upstream nameservers are supposed to be
used as a fallback. Even if upstream nameservers do not perform DNSSEC
validation, this is still better than a failure when DNSSEC is not
required.


For the record, this is incorrect, just like has been stated in #1004032
numerous times already.

The upstream nameservers provided by DHCP were never supposed to be used
as a "fallback", even more, there's no _notion_ of a "fallback" in this
context.

We EITHER use the DHCP-provided nameservers, OR we use the regular recursive
way.  But not both.

I know no recursive resolver software which has notion of "fallback" like
this.

Thanks,

/mjt

Bug#888999: unbound-anchor: please move unbound-anchor from /usr/sbin to /usr/bin

[Michael Tokarev]

Control: tag -1 + upstream

Hello!

On Wed, 31 Jan 2018 22:12:59 -0500 Daniel Kahn Gillmor  
wrote:

Package: unbound-anchor
Version: 1.6.7-1
Severity: wishlist

the dns-root-data package's debian/rules uses unbound-anchor in its
get_orig_source target.  It currently specifies the path explicitly,
because it shouldn't need to be run as root.

This is a classic example of a program that doesn't need to be run as
root living in /usr/sbin when it should live in /usr/bin.  Let's let
people rely on their standard $PATH without making brittle scripts.
I'm fine with shipping a symlink from /usr/sbin/unbound-anchor so that
we don't break existing brittle scripts, but we shouldn't encourage
creation of more brittle scripts in the first place.


Well yes, it appears to be that unbound-anchor does not need to be a
"system" command, it is a user-callable command. But this is how upstream
doe is, - and they ship unbound-anchor.8 manpage too.  I don't know why
it is done this way. Maybe it historically it were supposed to be run
as a daemon to keep the file updated? It was definitely used by unbound
itself to fetch the DNS root key, and now in Debian, dns-root-data package
sits "between" unbound-anchor and the unbound daemon.

Maybe we should talk with upstream for them to reconsider?
I don't have an opinion here besides the fact that I want to have as few
debian-specific changes as possible.

Thanks,

/mjt

Bug#537899: could respect domain search path from resolv.conf

[Michael Tokarev]

Control: tag -1 + confirmed upstream

Hello!

Replying to a bug from 2009, this is more than 12 years old! :)

On Tue, 21 Jul 2009 18:07:14 +0200 martin f krafft  wrote:

Package: unbound-host
Version: 1.3.2-1
Severity: wishlist
File: /usr/bin/unbound-host

I understand unbound-host does not read resolv.conf and regard that
as a feature. However, it /could/ read the search domain(s) from
/etc/resolv.conf, which would make it a little more useful for quick
use. Please consider.


Yeah, this is annoying indeed that unbound-host does not, by default,
read neither forwarders, nor the root key, nor the search domains.
And while for the forwarders and the root key there are options to
turn that on (I'd do it the other way around but heck), for the
domain search order there's no option at all.

But this is how upstream does it. We wont implement it in Debian,
I think...

Thanks!

/mjt

Bug#1008309: clang-14: address sanitizer creates broken binaries

[Sylvestre Ledru]

Also, please provide a test case. it isn't easy for us to test with big 
software!


Cheers

S



Le 26/03/2022 à 17:05, Christian Göttsche a écrit :

Package: clang-14
Version: 1:14.0.0-1
Severity: grave

Using address sanitizer with Clang 14 produces broken binaries while
using Clang 13 works fine, e.g for SELint:

 git clone https://github.com/TresysTechnology/selint
 cd selint/
 ./autogen.sh
 ./configure CC=clang-14 CFLAGS='-O1 -g -fsanitize=address
-fsanitize-address-use-after-scope -fno-omit-frame-pointer'
 make check

results in

 PASS: check_maps
 ../test-driver: line 112: 17567 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_tree
 PASS: check_parsing
 PASS: check_parse_functions
 PASS: check_parse_fc
 PASS: check_template
 PASS: check_check_hooks
 PASS: check_fc_checks
 ../test-driver: line 112: 17672 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_file_list
 PASS: check_if_checks
 PASS: check_runner
 ../test-driver: line 112: 17727 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_selint_config
 PASS: check_te_checks
 ../test-driver: line 112: 17764 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_string_list
 PASS: check_perm_macro
 ../test-driver: line 112: 17780 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_startup
 ../test-driver: line 112: 17808 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_ordering

with crashes like

PID: 17968 (check_selint_co)
   UID: 1000 (christian)
   GID: 1000 (christian)
Signal: 11 (SEGV)
 Timestamp: Sat 2022-03-26 16:53:06 CET (9min ago)
  Command Line: ./tests/check_selint_config
Executable: ./selint/tests/check_selint_config
Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-e43b2d75763e4b0da70e80f64c26a3e4.scope
  Unit: user@1000.service
 User Unit: app-org.kde.konsole-e43b2d75763e4b0da70e80f64c26a3e4.scope
 Slice: user-1000.slice
 Owner UID: 1000 (christian)
   Boot ID: 10c66335d13d4d1eadcfd8c0158aa69e
Machine ID: 9c96f8739cf9458d85028070c30b63fc
  Hostname: debianHome
   Storage: 
/var/lib/systemd/coredump/core.check_selint_co.1000.10c66335d13d4d1eadcfd8c0158aa69e.17968.164830998600.zst
(present)
 Disk Size: 129.0K
   Message: Process 17968 (check_selint_co) of user 1000 dumped core.

Module /usr/lib/x86_64-linux-gnu/libc.so.6 with
build-id dbe01d361066dd24f54239c184702d6e515d3134
Module /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
with build-id 41994ebf17dd9d27781e6aa7d5d380760bfc938c
Module linux-vdso.so.1 with build-id
c556e37440595bd7e11951e409de7d941439a8ef
Stack trace of thread 17968:
#0  0x606ade2de9e0 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64

and a backtrace of

#0  0x606ade2de9e0 in ?? ()
No symbol table info available.
#1  
No symbol table info available.
#2  0x606ade2de9e0 in ?? ()
No symbol table info available.
#3  
No symbol table info available.
#4  0x606ade2de9e0 in ?? ()
No symbol table info available.
#5  
No symbol table info available.
#6  0x606ade2de9e0 in ?? ()
No symbol table info available.
#7  
No symbol table info available.
#8  0x606ade2de9e0 in ?? ()
No symbol table info available.
#9  
No symbol table info available.
#10 0x606ade2de9e0 in ?? ()
No symbol table info available.
#11 
No symbol table info available.
#12 0x606ade2de9e0 in ?? ()
No symbol table info available.
#13 
No symbol table info available.
#14 0x606ade2de9e0 in ?? ()
No symbol table info available.
#15 
No symbol table info available.
#16 0x606ade2de9e0 in ?? ()
No symbol table info available.
#17 
No symbol table info available.
#18 0x606ade2de9e0 in ?? ()
No symbol table info available.
#19 
No symbol table info available.
#20 0x606ade2de9e0 in ?? ()
No symbol table info available.
#21 
No symbol table info available.
#22 0x606ade2de9e0 in ?? ()
No symbol table info available.
#23 
No symbol table info available.
#24 0x606ade2de9e0 in ?? ()
No symbol table info available.
#25 
No symbol table info available.
#26 0x606ade2de9e0 in ?? ()
No symbol table info available.
#27 
No symbol table info available.
#28 0x606ade2de9e0 in ?? ()
No symbol table info available.
#29 
No symbol table info available.
#30 0x606ade2de9e0 in ?? ()
No symbol table info available.
#31 
No symbol table info available.
#32 0x606ade2de9e0 in ?? ()
No symbol table info available.
#33 
No symbol table info available.
#34 0x606ade2de9e0 in ?? ()
No symbol table info available.
#35 
No symbol table info available.
#36 0x606ade2de9e0 in ?? ()
No symbol table info available.
#37 
No symbol table info 

Bug#1008309: clang-14: address sanitizer creates broken binaries

[Sylvestre Ledru]

Hello

You should report the bug upstream as it seems like an upstream bug.

Sylvestre

Le 26/03/2022 à 17:05, Christian Göttsche a écrit :

Package: clang-14
Version: 1:14.0.0-1
Severity: grave

Using address sanitizer with Clang 14 produces broken binaries while
using Clang 13 works fine, e.g for SELint:

 git clone https://github.com/TresysTechnology/selint
 cd selint/
 ./autogen.sh
 ./configure CC=clang-14 CFLAGS='-O1 -g -fsanitize=address
-fsanitize-address-use-after-scope -fno-omit-frame-pointer'
 make check

results in

 PASS: check_maps
 ../test-driver: line 112: 17567 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_tree
 PASS: check_parsing
 PASS: check_parse_functions
 PASS: check_parse_fc
 PASS: check_template
 PASS: check_check_hooks
 PASS: check_fc_checks
 ../test-driver: line 112: 17672 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_file_list
 PASS: check_if_checks
 PASS: check_runner
 ../test-driver: line 112: 17727 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_selint_config
 PASS: check_te_checks
 ../test-driver: line 112: 17764 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_string_list
 PASS: check_perm_macro
 ../test-driver: line 112: 17780 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_startup
 ../test-driver: line 112: 17808 Segmentation fault  (core
dumped) "$@" >> "$log_file" 2>&1
 FAIL: check_ordering

with crashes like

PID: 17968 (check_selint_co)
   UID: 1000 (christian)
   GID: 1000 (christian)
Signal: 11 (SEGV)
 Timestamp: Sat 2022-03-26 16:53:06 CET (9min ago)
  Command Line: ./tests/check_selint_config
Executable: ./selint/tests/check_selint_config
Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-e43b2d75763e4b0da70e80f64c26a3e4.scope
  Unit: user@1000.service
 User Unit: app-org.kde.konsole-e43b2d75763e4b0da70e80f64c26a3e4.scope
 Slice: user-1000.slice
 Owner UID: 1000 (christian)
   Boot ID: 10c66335d13d4d1eadcfd8c0158aa69e
Machine ID: 9c96f8739cf9458d85028070c30b63fc
  Hostname: debianHome
   Storage: 
/var/lib/systemd/coredump/core.check_selint_co.1000.10c66335d13d4d1eadcfd8c0158aa69e.17968.164830998600.zst
(present)
 Disk Size: 129.0K
   Message: Process 17968 (check_selint_co) of user 1000 dumped core.

Module /usr/lib/x86_64-linux-gnu/libc.so.6 with
build-id dbe01d361066dd24f54239c184702d6e515d3134
Module /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
with build-id 41994ebf17dd9d27781e6aa7d5d380760bfc938c
Module linux-vdso.so.1 with build-id
c556e37440595bd7e11951e409de7d941439a8ef
Stack trace of thread 17968:
#0  0x606ade2de9e0 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64

and a backtrace of

#0  0x606ade2de9e0 in ?? ()
No symbol table info available.
#1  
No symbol table info available.
#2  0x606ade2de9e0 in ?? ()
No symbol table info available.
#3  
No symbol table info available.
#4  0x606ade2de9e0 in ?? ()
No symbol table info available.
#5  
No symbol table info available.
#6  0x606ade2de9e0 in ?? ()
No symbol table info available.
#7  
No symbol table info available.
#8  0x606ade2de9e0 in ?? ()
No symbol table info available.
#9  
No symbol table info available.
#10 0x606ade2de9e0 in ?? ()
No symbol table info available.
#11 
No symbol table info available.
#12 0x606ade2de9e0 in ?? ()
No symbol table info available.
#13 
No symbol table info available.
#14 0x606ade2de9e0 in ?? ()
No symbol table info available.
#15 
No symbol table info available.
#16 0x606ade2de9e0 in ?? ()
No symbol table info available.
#17 
No symbol table info available.
#18 0x606ade2de9e0 in ?? ()
No symbol table info available.
#19 
No symbol table info available.
#20 0x606ade2de9e0 in ?? ()
No symbol table info available.
#21 
No symbol table info available.
#22 0x606ade2de9e0 in ?? ()
No symbol table info available.
#23 
No symbol table info available.
#24 0x606ade2de9e0 in ?? ()
No symbol table info available.
#25 
No symbol table info available.
#26 0x606ade2de9e0 in ?? ()
No symbol table info available.
#27 
No symbol table info available.
#28 0x606ade2de9e0 in ?? ()
No symbol table info available.
#29 
No symbol table info available.
#30 0x606ade2de9e0 in ?? ()
No symbol table info available.
#31 
No symbol table info available.
#32 0x606ade2de9e0 in ?? ()
No symbol table info available.
#33 
No symbol table info available.
#34 0x606ade2de9e0 in ?? ()
No symbol table info available.
#35 
No symbol table info available.
#36 0x606ade2de9e0 in ?? ()
No symbol table info available.
#37 
No symbol table info available.

Bug#1009882: golang-github-containers-buildah: CVE-2022-27651

[Salvatore Bonaccorso]

Source: golang-github-containers-buildah
Version: 1.23.1+ds1-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-github-containers-buildah.

CVE-2022-27651[0]:
| A flaw was found in buildah where containers were incorrectly started
| with non-empty default permissions. A bug was found in Moby (Docker
| Engine) where containers were incorrectly started with non-empty
| inheritable Linux process capabilities, enabling an attacker with
| access to programs with inheritable file capabilities to elevate those
| capabilities to the permitted set when execve(2) runs. This has the
| potential to impact confidentiality and integrity.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-27651
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27651
[1] 
https://github.com/containers/buildah/commit/e7e55c988c05dd74005184ceb64f097a0cfe645b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvaotre

Bug#1009881: crun: CVE-2022-27650

[Salvatore Bonaccorso]

Source: crun
Version: 0.17+dfsg-1.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.17+dfsg-1

Hi,

The following vulnerability was published for crun.

CVE-2022-27650[0]:
| A flaw was found in crun where containers were incorrectly started
| with non-empty default permissions. A vulnerability was found in Moby
| (Docker Engine) where containers were started incorrectly with non-
| empty inheritable Linux process capabilities. This flaw allows an
| attacker with access to programs with inheritable file capabilities to
| elevate those capabilities to the permitted set when execve(2) runs.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-27650
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27650
[1] 
https://github.com/containers/crun/commit/b847d146d496c9d7beba166fd595488e85488562

Regards,
Salvatore

Bug#1009880: fio: New upstream version available (3.30)

[Salvatore Bonaccorso]

Source: fio
Version: 3.28-1
Severity: wishlist
X-Debbugs-Cc: car...@debian.org

Hi Martin

There is a new upstream version available for fio, 3.30 at time of
writing. If you have time, can you upload the new version to unstable?

Regards,
Salvatore

Bug#1009879: pypdf2: CVE-2022-24859: Manipulated inline images can cause Infinite Loop

[Salvatore Bonaccorso]

Source: pypdf2
Version: 1.26.0-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/py-pdf/PyPDF2/issues/329
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for pypdf2.

CVE-2022-24859[0]:
| PyPDF2 is an open source python PDF library capable of splitting,
| merging, cropping, and transforming the pages of PDF files. In
| versions prior to 1.27.5 an attacker who uses this vulnerability can
| craft a PDF which leads to an infinite loop if the PyPDF2 if the code
| attempts to get the content stream. The reason is that the last while-
| loop in `ContentStream._readInlineImage` only terminates when it finds
| the `EI` token, but never actually checks if the stream has already
| ended. This issue has been resolved in version `1.27.5`. Users unable
| to upgrade should validate and PDFs prior to iterating over their
| content stream.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24859
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24859
[1] https://github.com/py-pdf/PyPDF2/issues/329
[2] https://github.com/py-pdf/PyPDF2/security/advisories/GHSA-xcjx-m2pj-8g79

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1009878: /usr/sbin/libvirtd: Live migration of guest VM fails with kernel oops error

[Ross Moutell]

Package: libvirt-daemon
Version: 7.0.0-3
Severity: important
File: /usr/sbin/libvirtd

Dear Maintainer,

   * What led up to the situation?

 Attempting live migration of VM between hosts, either from virt-manager on 
a seperate workstation or from the host itself via terminal.

 Example - virsh migrate --live web02 qemu+ssh://hypervisor01:64228/system 

   * What exactly did you do (or not do) that was effective (or ineffective)?

 Investigated the following logs.

 /var/log/syslog

 Apr 18 09:25:45 hypervisor04 libvirtd[542]: Cannot start job (query, none, 
none) for domain email01; current job is (none, none, migration in) owned by (0 
, 0 , 0 remoteDispatchDomainMigratePrepare3Params (flags=0x19)) for 
(0s, 0s, 305s)

 /var/log/kern.log

 Apr 17 22:45:45 hypervisor05 kernel: [  804.114785] Internal error: Oops: 
9604 [#1] SMP
 Apr 17 22:57:49 hypervisor05 kernel: [  206.952482] Internal error: Oops: 
9604 [#1] SMP
 Apr 18 01:06:11 hypervisor05 kernel: [  463.133575] Internal error: Oops: 
9604 [#1] SMP
 Apr 18 11:12:39 hypervisor05 kernel: [36851.073954] Internal error: Oops: 
9604 [#2] SMP
 Apr 18 11:29:19 hypervisor05 kernel: [37850.896463] Internal error: Oops: 
9604 [#3] SMP

 error in dmesg

 [  324.673078] audit: type=1400 audit(1650240228.486:23): 
apparmor="STATUS" operation="profile_replace" profile="unconfined" 
name="libvirt-72799f47-939c-4415-92c3-73ec371425fd" pid=979 
comm="apparmor_parser"
 [  324.768028] audit: type=1400 audit(1650240228.582:24): 
apparmor="DENIED" operation="capable" profile="libvirtd" pid=542 
comm="rpc-worker" capability=39  capname="bpf"
 [  324.774241] audit: type=1400 audit(1650240228.586:25): 
apparmor="DENIED" operation="capable" profile="libvirtd" pid=542 
comm="rpc-worker" capability=38  capname="perfmon"
 [  326.770324] audit: type=1400 audit(1650240230.582:26): 
apparmor="DENIED" operation="capable" profile="libvirtd" pid=542 
comm="rpc-worker" capability=39  capname="bpf"

 I added

  capability bpf,
  capability perfmon,

 to /etc/apparmor.d/usr.sbin.libvirtd which resolved the DENIED errors but 
did not resolve the live migration failures.

   * What was the outcome of this action?

 The following errors were produced.

 kernel:\[37850.896463\] Internal error: Oops: 9604 \[#3\] SMP

 Message from syslogd@hypervisor05 at Apr 18 11:29:19 ...

 kernel:\[37851.195226\] Code: 910003fd f9000bf3 2a0003f3 97ff7164 
(b95ed801)

 The VM that was submitted for migration ends up hung in a paused state. 
The only way to recover it is force power off on the VM, then 'sudo systemctl 
restart libvirtd.service'. The VM can then be powered on again normally.

   * What outcome did you expect instead?

 Live migration to complete successfully which has been the case on eariler 
kernel versions. However at this time I do not know which kernel versions 
worked other than the one it shipped with which was as follows.

 linux-image-5.10.0-8-arm64  5.10.46-5  arm64  Linux 5.10 for 64-bit ARMv8 
machines (signed)


-- System Information:
Debian Release: 11.3
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-13-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 libvirt-daemon depends on:
ii  libblkid1   2.36.1-8+deb11u1
ii  libc6   2.31-13+deb11u3
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libnetcf1   1:0.2.8-1.1
ii  libparted2  3.4-1
ii  libpcap0.8  1.10.0-2
ii  libpciaccess0   0.16-1
ii  libselinux1 3.1-3
ii  libudev1247.3-7
ii  libvirt-daemon-driver-qemu  7.0.0-3
ii  libvirt07.0.0-3
ii  libxml2 2.9.10+dfsg-6.7+deb11u1

Versions of packages libvirt-daemon recommends:
ii  libvirt-daemon-driver-lxc   7.0.0-3
pn  libvirt-daemon-driver-vbox  
ii  libvirt-daemon-driver-xen   7.0.0-3
ii  libxml2-utils   2.9.10+dfsg-6.7+deb11u1
ii  netcat-openbsd  1.217-3
ii  qemu-system 1:5.2+dfsg-11+deb11u1
ii  qemu-system-arm [qemu-kvm]  1:5.2+dfsg-11+deb11u1

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-iscsi-direct  
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   7.0.0-3
pn  numad   

-- no debconf information

Bug#1004588: libzip: New upstream release (1.8.0, 2021 Jun 18)

[Florian Ernst]

Following up to myself:

On Sun, Jan 30, 2022 at 08:52:17PM +0100, Florian Ernst wrote:
> there is a new upstream release available, cf.
> .
> 
> The changes contain
> 
> | Add support for zstd (Zstandard) compression.
> | Add support for lzma (ID 14) compression.
> | Add zip_source_window_create().
> | Add zip_source_zip_create() variant to zip_source_zip().
> | Allow method specific comp_flags in zip_set_file_compression().
> | Allow zip_source_tell() on sources that don't support seeking and 
> zip_ftell() on compressed data.
> | Provide more details for consistency check errors.
> | Improve output of zipcmp.
> | In zipcmp, don’t ignore empty directories when comparing directory listing.
> | Treat empty string as no password given in zip_file_set_encryption(), 
> zip_fopen_encrypted(), and zip_set_default_password().
> 
> which seem nice enough to eventually have in Debian.

I confirmed that the current packaging can still be used for
libzip-1.8.0 when dropping the SOVERSION patch which does not apply
anymore. Well, maybe it's finally time to do the transition anyways.

Of course, the resulting build is not clean then, and further changes
could (most possibly should) be applied. But this just as a heads-up.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1009367: libnss3 file location changes

[Stephan Verbücheln]

Another hint:

There are hardcoded paths in the following file:
~/.pki/nssdb/pkcs11.txt

e.g.:
> library=/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so

To me it is not clear who creates that file, nss or evolution.

Regards

Bug#1003045: libreoffice: Since testing update on Jan 2, 2021, libreoffice doesn't start.

[Rene Engelhard]

Hi,

Am 17.04.22 um 18:47 schrieb yg2709:

Package: libreoffice
Followup-For: Bug #1003045
X-Debbugs-Cc: yg2...@hotmail.com

Dear Maintainer,

Probbing at a VM debian testing (12), checking with MATE (1.26.0),
  after upgrading all versions (from 1:7.2.4-1 thru 1:7.3.1-1), it opens 
sucessfully.


Good..

(Especially since that bug never was reproducible in the first place.)


The real machine with version 1:7.2.4-1 and with apt-listbugs,
  is waiting to solve this issue.


Then upgrade that system. We don't support some random state of testing.

Testing hasn't 7.2.x anymore for long.


(And if you use testing (a development release!) and apt-listbugs, you 
should be able to get around it.)



Regards,


Rene

Bug#1009844: debhelper: Build failed with dh_installalternatives: error: Alternative ...

[Sven Joachim]

Control: affects -1 src:xterm
Control: severity -1 serious

On 2022-04-19 13:59 +0100, Colin Watson wrote:

> Control: affects -1 src:openssh
>
> On Tue, Apr 19, 2022 at 12:05:22PM +0900, Hiroyuki YAMAMORI wrote:
>> When rebuilding rsh-redone, the following message is output and the build 
>> fails.
>>
>> dh_installalternatives: error: Alternative "/usr/bin/rsh-redone-rsh" for 
>> "rsh" in debian/rsh-redone-client.alternatives does not exist in 
>> debian/rsh-redone-client or is a directory
>> make: *** [debian/rules:16: binary] Error 25
>> dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
>> status 2
>>
>>
>> Solved with the following patch.
>>
>> --- a/usr/bin/dh_installalternatives
>> +++ b/usr/bin/dh_installalternatives
>> @@ -99,7 +99,7 @@ sub _parse_alternative_and_generate_main
>> if (index($link_name, '/') > -1) {
>> error(qq{Invalid link name "${link_name}" in 
>> "${alternatives_file}": Must not contain slash});
>> }
>> -   if ( ! -l "${tmpdir}/${impl_path}" or -d _) {
>> +   if ( ! -e "${tmpdir}/${impl_path}" or -d _ or ! -r _) {
>> error(qq{Alternative "${impl_path}" for "${link_name}" in 
>> ${alternatives_file} does not exist in ${tmpdir} or is a directory});
>> }
>> if ($link_name eq $impl_path) {
>
> This also causes openssh to fail to build (see e.g.
> https://salsa.debian.org/flurb/openssh/-/jobs/2683517).  Something like
> this patch looks reasonable to me, and at any rate the previous code
> doesn't make sense; it seems to require the potential *target* of the
> alternative to be a symlink.

I get the same error in xterm, so I have raised the severity as at
least three packages now fail to build.

Cheers,
   Sven

Bug#1009875: libtorrent-rasterbar-dev: pkg-config --libs is wrong, leads to FTBFS

[Hilko Bengen]

Package: libtorrent-rasterbar-dev
Version: 2.0.6-2
Severity: grave
X-Debbugs-Cc: none, Hilko Bengen 

Dear Maintainer,

nbdkit which build-depends on libtorrent-rasterbar-dev fails to build
from source:

,
| Making all in torrent
| make[3]: Entering directory '/home/bengen/p/deb/nbdkit/plugins/torrent'
| /bin/bash ../../libtool  --tag=CXX   --mode=link g++  -g -O2 
-ffile-prefix-map=/home/bengen/p/deb/nbdkit=. -fstack-protector-strong -Wformat 
-Werror=format-security -module -avoid-version -shared  
-Wl,--version-script=../../plugins/plugins.syms  -Wl,-z,relro -o 
nbdkit-torrent-plugin.la -rpath /usr/lib/x86_64-linux-gnu/nbdkit/plugins 
nbdkit_torrent_plugin_la-torrent.lo  ../../common/utils/libutils.la  -lpthread 
-ltorrent-rasterbar -l-pthread -lssl -lcrypto  
| libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/11/crtbeginS.o  
.libs/nbdkit_torrent_plugin_la-torrent.o  -Wl,--whole-archive 
../../common/utils/.libs/libutils.a -Wl,--no-whole-archive  -lpthread 
-ltorrent-rasterbar -l-pthread -lssl -lcrypto 
-L/usr/lib/gcc/x86_64-linux-gnu/11 
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../.. -lstdc++ -lm -lc -lgcc_s 
/usr/lib/gcc/x86_64-linux-gnu/11/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crtn.o  -g -O2 
-fstack-protector-strong -Wl,--version-script=../../plugins/plugins.syms -Wl,-z 
-Wl,relro   -pthread -Wl,-soname -Wl,nbdkit-torrent-plugin.so -o 
.libs/nbdkit-torrent-plugin.so
| /usr/bin/ld: cannot find -l-pthread: No such file or directory
| collect2: error: ld returned 1 exit status
`

I am pretty sure that the immmediate cause for this is the "-l-pthread"
bit:

,
| $ pkg-config --libs libtorrent-rasterbar
| -ltorrent-rasterbar -l-pthread -lssl -lcrypto
`

It's not immediately obvious to me how libtorrent-rasterbar.pc gets
generated.

According to buildd logs (e.g. [1]), libtorrent-rasterbar-dev/2.0.5-6+b1
did not have this problem.

Cheers,
-Hilko

[1] 
https://buildd.debian.org/status/fetch.php?pkg=nbdkit=amd64=1.30.2-1=1649198599=0

Bug#1009367: libnss3 file location changes

[Jeremy Bicha]

Control: affects -1 src:nss

On Tue, Apr 19, 2022 at 6:09 AM Stephan Verbücheln
 wrote:
> Further analysis shows that it is related to changed file locations
> between the libnss3 versions. Some files were moved out of the nss
> directory.

Would rebuilding evolution fix this issue?

There will be a new evolution release on Friday anyway.

If it does fix the issue, then maybe we would need to rebuild some or
all of the nss reverse dependencies.

Thank you,
Jeremy Bicha

Bug#1009018: linux-image-5.16.0-5-amd64: Shutdown, reboot, and suspend broken on chromebook when module cros_ec_typec is loaded.

[Vincent Blut]

Version: 5.17.3-1

Hi,

Le 2022-04-05 18:23, Dan Bassett a écrit :
> Package: src:linux
> Version: 5.16.14-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: b...@fizix.org
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>I upgraded my system from Stable (5.10 kernel) to Testing in order
>to get sound working, however, upon upgrade, my system was no longer
>able to shutdown, reboot, or suspend properly.  All of these actions
>would result in the system hanging, requiring a hard reset.
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>I manually built a series of kernels to try to narrow down where
>the issue was occuring and found that when I disabled the building of
>chromebook related platform drivers, my system would happily reboot
>and suspend.  I also noticed that the kernel was throwing an error 
>at boot when attempting to load the cros_ec_typec module.  Given this
>information, I attempted to boot the stock debian kernel
>(5.16.0-5-amd64) with the option module_blacklist=cros_ec_typec,
>which resulted in a system that rebooted and suspended as expected.
>I am unaware of any functionality that I may be losing by not loading
>the cros_ec_typec module.
> 
> 
>* What was the outcome of this action?
> 
>I have a working system, though ideally this module would properly
>load on boot (as my hardware configuration seems to want it), and not
>break shutdown/reboot/suspend.
> 
> 
>* What outcome did you expect instead?
> 
>The system should work without disabling relevant kernel modules.

Dan confirmed to me privately that this issue has been fixed in Linux 5.17.3.
Closing!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#641704: unbound-host should be preconfigured with DNS root trust anchor

[Michael Tokarev]

Control: tag -1 + confirmed

Hi Janus!

Replying to a bugreport which is more than 10 years old already.. :)

On Thu, 15 Sep 2011 11:46:58 +0200 Thue Janus Kristensen  
wrote:

Package: unbound-host
Version: 1.4.12-1
Severity: normal

Dear Maintainer,

Using a simple "aptitude install unbound-host", the installed
unbound-host doesn't seem to know about the root trust anchor. And
there is no description in the man page, or in
/ush/share/doc/unbound-host, about how to get and install this anchor.


Yes, there's no information provided. I guess unbound-host can use
data provided by dns-root-data.

However, if unbound-host is installed together with unbound itself,
unbound-host will use unbound's /var/lib/unbound/root.key. Which
maybe good or may be not good, since this file is in untrusted
directory, managed by a network daemon.

/mjt

Bug#1009866: rsyslog-pgsql: postinst script fails with non-zero exit at dbc_postinst_cleanup

[Michael Biebl]

Am 19.04.22 um 16:15 schrieb Wilko Meyer:

Package: rsyslog-pgsql
Version: 8.2102.0-2
Severity: minor

Dear Maintainer,

The postinst script fails under certain conditions due to the lack of
error handling in dbc_postinst_cleanup with a non-zero exit code:

Output with `set -x` set:

#+BEGIN_SRC

+ IFS=
+ printf %s\n RESET rsyslog-pgsql/app-password-confirm
+ IFS=

+ read -r _db_internal_line
+ IFS=

+ RET=10 rsyslog-pgsql/app-password-confirm doesn't exist
+ return 10
+ true
+ db_fset rsyslog-pgsql/app-password-confirm seen false
+ _db_cmd FSET rsyslog-pgsql/app-password-confirm seen false
+ _db_internal_IFS=

+ IFS=
+ printf %s\n FSET rsyslog-pgsql/app-password-confirm seen false
+ IFS=

+ read -r _db_internal_line
+ IFS=

+ RET=10 rsyslog-pgsql/app-password-confirm doesn't exist
+ return 10
+ true
+ db_reset rsyslog-pgsql/internal/skip-preseed
+ _db_cmd RESET rsyslog-pgsql/internal/skip-preseed
+ _db_internal_IFS=

+ IFS=
+ printf %s\n RESET rsyslog-pgsql/internal/skip-preseed
+ IFS=

+ read -r _db_internal_line
+ IFS=

+ RET=10 rsyslog-pgsql/internal/skip-preseed doesn't exist
+ return 10
+ db_reset rsyslog-pgsql/internal/reconfiguring
+ _db_cmd RESET rsyslog-pgsql/internal/reconfiguring
+ _db_internal_IFS=

+ IFS=
+ printf %s\n RESET rsyslog-pgsql/internal/reconfiguring
+ IFS=

+ read -r _db_internal_line
+ IFS=

+ RET=10 rsyslog-pgsql/internal/reconfiguring doesn't exist
+ return 10
+ return 10
dpkg: error processing package rsyslog-pgsql (--configure):
  installed rsyslog-pgsql package post-installation script subprocess returned 
error exit status 10

#+END_SRC

the last successful running part of the postinst script is the calling
of dbc_forget_app_password(), dbc_postinst_cleanup() is where 10 as an
exit code is returned and where the script fails.

As far as I can tell the error occurs because:

* db_reset $dbc_package/internal/reconfiguring returns 10, but the
   script fails to catch this by either appending || true nor by
   returning 0 at the end of the function.


This would mean ignoring an error.
Why do you think it is appropriate to ignore this failure?


* I also noticed that on systems where the postinst script is broken
   debconf does not hold any entries corresponding to the package;
   which may point into the right direction for a possible fix.


Is this maybe a bug in dbconfig-common?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#907314: unbound: exception in python module due to the dnameAsStr() function

[Michael Tokarev]

Control: tag -1 + moreinfo unreproducible

On Sun, 26 Aug 2018 11:13:22 + root  wrote:

Package: unbound
Version: 1.7.3-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   
   trying to implement an unbound python module (python code executed

   while the unbound server is handling requests and responses, see the
   pythonmod/ in unbound's source code).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   starting with the log.py example (included in the unbound's source
   code), modified the print functions to make it work with Python3, and
   added a single print() to illustrate the problem:
 print("=> %s"%q.qname_str)
   When a client requests a resolution, the ubound server reports an exception
   where it should not.


Hello!

Can you please verify the problem still exists with current version of
unbound (1.13.1 or 1.15 currently in experimental)?

I tried this with log.py, - the examples provided by upstream in there
weren't updated for python3 still, but the thing appears to be working
at least.  I know right to nothing about python so I can't say for sure.

Thanks!

/mjt

Bug#914405: appears to not update auto-trust-anchors without requests

[Michael Tokarev]

Control: tag -1 + upstream moreinfo

On Fri, 23 Nov 2018 07:19:05 + Peter Palfrader  wrote:

Package: unbound
Version: 1.6.0-3+deb9u2
Severity: normal

Hi!

we have unbound configured as a recursor on most of our hosts,
and we have a few trust-anchors in addition to the root zone's
configured with auto-trust-anchor-file.

One of the covered zone sees rarely, if ever, any queries.

It appears unbound is not maintaining the auto-trust-anchor without
seeing queries however.


I think this should be addressed upstream.  I understand your
concern but there's nothing we can do with this in Debian.

Besides, is it still an issue now with version 1.13 or 1.15 of
unbound?

Thanks,

/mjt

Bug#1009874: findutils FTBFS on musl-any-any: outdated gettext macros

[Helmut Grohne]

Source: findutils
Version: 4.9.0-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

findutils fails to build from source on musl-any-any, because it fails
to detect gettext availability. The cause is the use of outdated gettext
macros in configure.ac. Updating to newer versions fixes the issue.
Please consider applying the attached patch.

Helmut
--- a/configure.ac
+++ b/configure.ac
@@ -278,7 +278,8 @@

 dnl internationalization macros
 AM_GNU_GETTEXT([external])
-AM_GNU_GETTEXT_VERSION([0.19.3])
+AM_GNU_GETTEXT_REQUIRE_VERSION([0.19.8])
+AM_GNU_GETTEXT_VERSION([0.19.6])

 dnl regextype.c and regexprops.c are designed to be usable outside findutils,
 dnl but findutils doesn't want to support all the regex types in gnulib,

Bug#1009864: xscreensaver: firefox stops (inhibits) xscreensaver from firing. Needs option to ignore firefox

[Jamie Zawinski]

> people want firefox, when playing a video, to inhibit xscreensaver.

"Monkey paw curls."

> Only problem is I'm not playing a video.  Unfortunately, the net is full of 
> ads, so pretty much every page claims to be "playing a video".

Yeah, that's awesome, isn't it? I had been under the impression that the bug 
you are describing only happened with Chromium, not with Firefox. Here's an 
excerpt from the tragically-long comment at the top of xscreensaver-systemd.c:

 * Twitter (and many other sites) auto-convert GIFs to looping MP4s to
 * save bandwidth.  Chromium inhibits the screen saver any time a Twitter
 * GIF is on screen (either in the browser or in Tweetdeck).
 *
 * The proper way for Chrome to fix this would be to stop inhibiting once
 * the video loops.  That way your multi-hour movie inhibits properly, but
 * your looping GIF only inhibits for the first few seconds.

Firefox, Chrome and Chromium also all will leave the screen permanently 
inhibiited if they crash, too, which is great.

And Firefox, Chromium and MPV inhibit screen blanking when only *audio* is 
playing, which makes no damned sense at all.

So, if someone could report bugs against those applications, that would be 
great.

Also, so that I'm clear on exactly what is happening, can you do a test with 
Firefox and see if what is going on is, in fact, that it treats any 2-second 
looping MP4 thumbnail as "playing a movie"? Finding any looping GIF on Twitter 
is a good way to test it. Then navigate away from that page and see if it 
uninhibits. 

I believe that Firefox didn't used to do this, so it would be interesting to 
know when they started.

> I just want to be able to tell xscreensaver to ignore any calls from this 
> list of programs:
> 
> 1) firefox-esr
> 
> Oh look at that, end of list.

Oh ho ho ho, the list of other programs that fuck this up is so much longer 
than that. It's basically all of them. 

Your best bet is probably just "rm xscreensaver-systemd". This will 
unfortunately have the side effect that your screen will not auto-lock when you 
close the laptop lid.

> Yes, I know the proper fix is to tell firefox to give me an option to not 
> inhibit the screensaver

That's not actually the fix, it's just that they are inhibiting it in the 
stupidest possible way. Maybe "be less stupid" will get more traction than 
"stop". We can dare to dream.

-- 
Jamie Zawinski • jwz.org • dnalounge.com

Bug#1009859: sbuild does not download http(s) .dsc files if libwww-perl is not installed

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Carles Pina i Estany (2022-04-19 13:39:23)
> sbuild does not download packages unless libwww-perl is installed.
> 
> To reproduce:
> 
> $ docker run -it debian:bullseye /bin/bash # just to have a clean system
> # apt-get update && apt-get -y install sbuild # same final result as using 
> "apt install sbuild"
> # sbuild --no-clean --arch-any --arch-all --no-source --dist=stable 
> --arch=amd64  http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-2.dsc
> E: Failed to open build log 
> //http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-2.dsc_amd64-2022-04-19T10:20:26Z.build:
>  No such file or directory
> E: Error creating chroot
> 
> I expected the .dsc file to be downloaded.
> 
> After installing libwww-perl sbuild works as expected:
> 
> # apt-get -y install libwww-perl
> 
> # sbuild --no-clean --arch-any --arch-all --no-source --dist=stable 
> --arch=amd64  http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-2.dsc 
> # it downloads the package as expected
> 
> 
> Not a Perl programmer here but I followed the code:
> 
> /usr/bin/sbuild around line 103 does "check_url($jobname)" which is 
> implemented in /usr/share/perl5/Sbuild/Utility.pm around line 166. It does:
> 
> # Load LWP::UserAgent if possible, else return 0.
> if (! can_load( modules => { 'LWP::UserAgent' => undef, } )) {
> return 0;
> }
> 
> Without libwww-perl package installed it returns 0. Then sbuild assumes that
> http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-2.dsc is a
> local file.
> 
> I don't know if the way to go is to make the error message more helpful
> (suggesting to install the package?), or make libwww-perl a dependency
> (or at least recommended). Or perhaps add a note in the manual? It
> currently says "For .dsc files  in  remote locations,  the source
> packages are downloaded first, then built." without noting that
> libwww-perl is required for this.

wow, I didn't even know sbuild could do this!

I don't think it'd be wise to promote libwww-perl from a Suggests to a
Recommends because this far from an essential sbuild functionality and I only
see it as a convenience feature. And even as that I never needed it. For
example you run:

sbuild --no-clean --arch-any --arch-all --no-source --dist=stable 
--arch=amd64  http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-2.dsc

But you can achieve the same thing by running:

sbuild --no-clean --arch-any --arch-all --no-source --dist=stable 
--arch=amd64 hello_2.10-2

I've now added a warning if libwww-perl is missing:

https://salsa.debian.org/debian/sbuild/-/commit/c510b2f54e0a743d7ba06a630e65d20d8f95118c

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

19.04.2022 17:49, Vincent Lefevre wrote:
..

I don't think this is in the scope of resolvconf people, because
the whole purpose of resolvconf is different.


I don't know what you mean here. In my case, the purpose of resolvconf
is just to restart postfix each time /etc/resolv.conf is modified


resolvconf does not "check" updates of resolv.conf, it *manages*
resolv.conf and maintains a list of available nameservers, including
nameservers provided by DHCP.

[]

I tend to close this bug report, Vincent.  This is not the intended
usage of resolvconf, and is not something to fix in unbound, either.
Unbound can either accept whatever resolvconf gives it from dhcp and
use that as its own forwarders (with the the script in $subject
enabled), or it can continue to perform recursive queries as before,
starting with the root nameservers.  There's no such thing as a
"fallback" here, at all.


Then this should be a resolvconf bug. But the fix on the postfix side


There's no bug per se, at least I still can't see one.
And there's no "fallback" here. either.


(Debian bug 1003152) makes resolvconf no longer needed. So, as long
as other Debian packages do not need resolvconf, I no longer care
about it.


Well, systemd already have its own nameserver configuration and its
own resolver cache which does not need any reload of daemons, since
resolv.conf does not change (It does not change with resolvconf and
unbound running with resolvconf hook enabled, either, and postfix
already needs no restart).

Thank you for your patience!

/mjt

Bug#1009873: haskell-devscripts: imports missing for encode_utf8 in dh_haskell_* scripts

[Scott Talbert]

Package: haskell-devscripts
Version: 0.16.11
Severity: important

Dear Maintainer,

While attempting to build an updated version of haskell-attoparsec, I
ran into the following error:

Creating package registration directory: attoparsec-0.14.4.conf
Undefined subroutine ::encode_utf8 called at 
/usr/bin/dh_haskell_install_ghc_registration line 59.
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:171: 
install/libghc-attoparsec-dev] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2

It appears that dh_haskell_install_ghc_registration and several other of the
dh_haskell_* scripts are missing a:
use Unicode::UTF8 qw(encode_utf8);

Thanks,
Scott

Bug#1009262: linux-image-5.16.0-0.bpo.4-arm64: power supply incorrectly reported as offline

[Diederik de Haas]

On dinsdag 19 april 2022 01:29:04 CEST Diederik de Haas wrote:
> On Sunday, 10 April 2022 13:39:54 CEST James Valleroy wrote:
> > In the log it showed "WARNING System is on battery power, stopping".
> > It uses the on_ac_power command from powermgmt-base package.
> 
> Pretty sure the problem is in the on_ac_power script from powermgmt-base.
> It appears to be a really simplistic script which searches through 4
> categories and I checked (with `ls -l ` what it would do on my Rock64:
> 
> 1) /sys/class/power_supply/
> total 0
> (iow: that directory does exist, but is empty)

It turns out that directory isn't empty on a RockPro64 and it returns '0' with
``cat /sys/class/power_supply/tcpm-source-psy-4-0022/online``
(the type property returns 'USB' fwiw)

Which in turn makes the script conclude it's offline/on battery power.
Someone running a manjaro kernel on a RockPro64 also got '0', which makes it 
unlikely to be a Debian kernel issue.

FTR: on my other Rock64's one running LibreELEC and the other armbian, they 
all have an empty power_supply directory.
It was also empty on a RPi 2B running an raspbian.org kernel and a RPi 3B 
running a Debian kernel

> My guess is that it's unaware of device-tree ... which is a problem (for ARM
> devices).

While I didn't see any reference to DT in the powermgmt-base source code, that 
may not be important.

What I don't know is whether the (upstream) kernel is reporting an incorrect 
value for the 'online' property or whether the script makes an incorrect 
assumption wrt what that property's return value represents.

This is as far as I can provide input on this issue. Now someone with 
knowledge about ``/sys/class/power_supply`` should take over.

HTH,
  Diederik

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

Bug#1009872: dovecot-core: postinst fails when snakeoil cert is removed

[Julien Cristau]

Package: dovecot-core
Version: 1:2.3.13+dfsg1-2
Severity: serious
X-Debbugs-Cc: jcris...@debian.org

This bit of dovecot-core.postinst breaks (at least on the second invocation) if
the snakeoil cert or key don't exist: test -e returns false, but ln -s fails
because the symlink is already there:

  # SSL configuration
  # Use the ssl-cert-snakeoil certificate in the following cases:
  # - On new installations
  # - On upgrades from versions that did not enable SSL by default
  if [ -z "$2" ] || dpkg --compare-versions "$2" lt "1:2.2.31-1~"; then
if [ ! -e /etc/dovecot/private/dovecot.key ] && \
   [ ! -e /etc/dovecot/private/dovecot.pem ]; then
  ln -s /etc/ssl/certs/ssl-cert-snakeoil.pem 
/etc/dovecot/private/dovecot.pem
  ln -s /etc/ssl/private/ssl-cert-snakeoil.key 
/etc/dovecot/private/dovecot.key
fi
  fi


Cheers,
Julien

Bug#1009870: ncurses: CVE-2022-29458

[Salvatore Bonaccorso]

Source: ncurses
Version: 6.3-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ncurses.

CVE-2022-29458[0]:
| ncurses 6.3 before patch 20220416 has an out-of-bounds read and
| segmentation violation in convert_strings in tinfo/read_entry.c in the
| terminfo library.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-29458
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29458
[1] https://invisible-island.net/ncurses/NEWS.html#t20220416

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1009863: more info

[Roderich Schupp]

The message in the report's subject can be found at the end of the attached
journal.txt

This message doesn't appear in (self-built) kernels 5.17.{0,1}, appeared in
5.17.2.
Reverting b99e33d7aa82fafabba067270b4e0cec8707ae07 (in 5.17.2)
"Revert "ACPI: Pass the same capabilities to the _OSC regardless of the
query flag""
makes the message go away for me (but I don't know what I'm doing here).

Cheers, Roderich

Bug#1009868: ITP: node-openurl -- Open a URL via the operating system

[Michael Ikwuegbu]

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

* Package name: node-openurl
  Version : 1.1.1
  Upstream Author  : Axel Rauschmayer 
* URL  : https://github.com/rauschma/openurl#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Open a URL via the operating system
openurl is a Node.js module for opening a URL via the operating  system
.
 Node.js is an event-based server-side JavaScript engine.

Bug#1009867: RFS: odr-dabmux/4.2.1-1 [ITP] -- Digital Audio Broadcasting multiplexer compliant to ETSI EN 300 401

[Robin ALEXANDER]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "odr-dabmux":

 * Package name    : odr-dabmux
   Version : 4.2.1-1
   Upstream Author : Matthias P. Braendli 
 * URL : https://www.opendigitalradio.org/Mmbtools
 * License : FSFAP, GPL-3.0+ with autoconf exception, BSL-1.0,
GPL-3.0+, Apache-2.0, LGPL-2.1, GPL-2.0+, Expat
 * Vcs : https://salsa.debian.org/ralex/odr-dabmux
   Section : hamradio

The source builds the following binary packages:

  odr-dabmux - Digital Audio Broadcasting multiplexer compliant to ETSI
EN 300 401

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

  https://mentors.debian.net/package/odr-dabmux/

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

  dget -x
https://mentors.debian.net/debian/pool/main/o/odr-dabmux/odr-dabmux_4.2.1-1.dsc

Changes for the initial release:

 odr-dabmux (4.2.1-1) unstable; urgency=low
 .
   * Initial release. Closes: #1009225

Regards,

-- 
Robin ALEXANDER



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

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-19 16:24:57 +0300, Michael Tokarev wrote:
> 19.04.2022 16:02, Vincent Lefevre wrote:
> > On 2022-04-19 15:15:11 +0300, Michael Tokarev wrote:
> > > unbound resolvconf integration (the disabled one) works by setting
> > > DNS servers obtained via DHCP to become the forwarders in
> > > unbound.  As simple as that.  I'm not saying about 127.0.0.1
> > > filtering there, it's a different issue.
> > > 
> > > If we (re)enable /etc/resolvconf/update.d/unbound , the dhcp-provided
> > > nameservers will be used as the primary nameservers with unbound sitting
> > > just as a local cache. Unbound will not use them as fallbacks but as
> > > primary forwarders.
> > 
> > The issue is that resolvconf assumes that unbound will use them
> > as fallbacks (see below).
> 
> Um. Did you forget to describe this "below" case? I don't see where you
> wrote that below.

No, I meant what I wrote about how resolvconf behaves.

> > > The only way to do what - I think - you're asking for, is for
> > > resolvconf to modify /etc/resolv.conf file to specify one unbound-
> > > provided nameserver line (with 127.0.0.1 in there) and *add* the
> > > dhcp-provided nameservers there *too*. And you don't want in this
> > > case to enable unbound's resolvconf integration.
> > 
> > resolvconf actually does the opposite: instead of leaving the
> > /etc/resolv.conf contents as is, it removes every nameserver
> > after 127.0.0.1, assuming that they will be handled by the
> > local nameserver.
> 
> Yes, I know what it does, and why.  It assumes whatever is running
> at 127.* is a local caching thing which will do its own forwarding
> when needed, and for that forwarding resolvconf gives it the
> dhcp-provided nameservers.  What I wrote is the only way I know
> to achieve what you wanted.
> 
> > Perhaps this is something to see with the resolvconf authors.
> 
> I don't think this is in the scope of resolvconf people, because
> the whole purpose of resolvconf is different.

I don't know what you mean here. In my case, the purpose of resolvconf
is just to restart postfix each time /etc/resolv.conf is modified
(typically due to the connection of a laptop to a different network),
as recommended at

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

However, the upcoming postfix package version will contain another
method without needing resolvconf:

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

> > > But this doesn't really work and it is unreliable.  Because quite
> > > some software will query *all* nameservers listed in resolv.conf
> > > at the same time (accepting the first reply), and some software
> > > will only query the first one.
> > 
> > This would clearly be a bug, as not conforming with the
> > /etc/resolv.conf spec. See the resolv.conf(5) man page:
> 
> I know perfectly well what resolv.conf manage says.  And I know
> perfectly well that software already uses it in slightly different
> ways, for different reasons. Usually you don't have lots of stuff
> in there - it is either your upstream nameservers from dhcp, or
> something like 8.8.8.8, or 127.0.0.{1,53} which is your local
> dns cache.  In most cases it is irrelevant in which way or in
> which order you query them.

There is another use case: by default, have some nameserver
that doesn't use the ones provided by DHCP, e.g. 127.0.0.1
or 8.8.8.8, and have the nameservers provided by DHCP as a
fallback. The fallback is needed in case UDP packets are
filtered, as with captive portals; see example at

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

and it is important that the query to the default nameserver
is done first, because the nameservers provided by DHCP can
provide incorrect answers (e.g. preventing users from using
servers blacklisted by the government).

> I tend to close this bug report, Vincent.  This is not the intended
> usage of resolvconf, and is not something to fix in unbound, either.
> Unbound can either accept whatever resolvconf gives it from dhcp and
> use that as its own forwarders (with the the script in $subject
> enabled), or it can continue to perform recursive queries as before,
> starting with the root nameservers.  There's no such thing as a
> "fallback" here, at all.

Then this should be a resolvconf bug. But the fix on the postfix side
(Debian bug 1003152) makes resolvconf no longer needed. So, as long
as other Debian packages do not need resolvconf, I no longer care
about it.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1007170: transition: qtbase-opensource-src

[Sebastian Ramacher]

Control: tags -1 = moreinfo

On 2022-04-19 17:38:50, Dmitry Shachnev wrote:
> Dear Sebastian and the Release Team,
> 
> On Tue, Apr 19, 2022 at 02:14:47PM +0200, Sebastian Ramacher wrote:
> > Control: tags -1 confirmed
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/qtbase-abi-5-15-3.html
> >
> > On 2022-03-12 20:46:57, Dmitry Shachnev wrote:
> > > Dear Release Team,
> > >
> > > Source code for Qt 5.15.3 was released recently (source code for 5.15.x
> > > is published after a year from the corresponding commercial release).
> > >
> > > I have now prepared this release in experimental. As usual, we have 
> > > private
> > > ABI change for qtbase and qtdeclarative.
> >
> > With python3.10-default now done, please go ahead.
> 
> Unfortunately, qtwebengine started FTBFS on mips64el and mipsel recently [1].
> 
> It looks related to nodejs update from 12 to 14, which happened in the end of
> March. With nodejs 16.14 from experimental it works fine. I have asked the
> maintainer whether he has any ETA for uploading it to unstable, waiting for
> the reply.
> 
> Until it's fixed, I think it would be wise to delay this transition. Maybe we
> can even skip 5.15.3 and upload 5.15.4, source code for which will be released
> in May.
> 
> Please ACK some other transition for now (if it doesn't involve qtwebengine
> rebuild).

ACK, please remove the moreinfo tag once the transition is ready to
proceed.

Cheers

> 
> [1]: 
> https://buildd.debian.org/status/package.php?p=qtwebengine-opensource-src=experimental
> 
> --
> Dmitry Shachnev



-- 
Sebastian Ramacher

Bug#1007170: transition: qtbase-opensource-src

[Dmitry Shachnev]

Dear Sebastian and the Release Team,

On Tue, Apr 19, 2022 at 02:14:47PM +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/qtbase-abi-5-15-3.html
>
> On 2022-03-12 20:46:57, Dmitry Shachnev wrote:
> > Dear Release Team,
> >
> > Source code for Qt 5.15.3 was released recently (source code for 5.15.x
> > is published after a year from the corresponding commercial release).
> >
> > I have now prepared this release in experimental. As usual, we have private
> > ABI change for qtbase and qtdeclarative.
>
> With python3.10-default now done, please go ahead.

Unfortunately, qtwebengine started FTBFS on mips64el and mipsel recently [1].

It looks related to nodejs update from 12 to 14, which happened in the end of
March. With nodejs 16.14 from experimental it works fine. I have asked the
maintainer whether he has any ETA for uploading it to unstable, waiting for
the reply.

Until it's fixed, I think it would be wise to delay this transition. Maybe we
can even skip 5.15.3 and upload 5.15.4, source code for which will be released
in May.

Please ACK some other transition for now (if it doesn't involve qtwebengine
rebuild).

[1]: 
https://buildd.debian.org/status/package.php?p=qtwebengine-opensource-src=experimental

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1009866: rsyslog-pgsql: postinst script fails with non-zero exit at dbc_postinst_cleanup

[Wilko Meyer]

Package: rsyslog-pgsql
Version: 8.2102.0-2
Severity: minor

Dear Maintainer,

The postinst script fails under certain conditions due to the lack of
error handling in dbc_postinst_cleanup with a non-zero exit code:

Output with `set -x` set:

#+BEGIN_SRC

+ IFS= 
+ printf %s\n RESET rsyslog-pgsql/app-password-confirm  
+ IFS=   

+ read -r _db_internal_line
+ IFS=

+ RET=10 rsyslog-pgsql/app-password-confirm doesn't exist 
+ return 10
+ true   
+ db_fset rsyslog-pgsql/app-password-confirm seen false
+ _db_cmd FSET rsyslog-pgsql/app-password-confirm seen false
+ _db_internal_IFS=

+ IFS=   
+ printf %s\n FSET rsyslog-pgsql/app-password-confirm seen false
+ IFS=

+ read -r _db_internal_line
+ IFS=  

+ RET=10 rsyslog-pgsql/app-password-confirm doesn't exist
+ return 10
+ true
+ db_reset rsyslog-pgsql/internal/skip-preseed
+ _db_cmd RESET rsyslog-pgsql/internal/skip-preseed
+ _db_internal_IFS=

+ IFS=   
+ printf %s\n RESET rsyslog-pgsql/internal/skip-preseed
+ IFS=   

+ read -r _db_internal_line
+ IFS=

+ RET=10 rsyslog-pgsql/internal/skip-preseed doesn't exist
+ return 10
+ db_reset rsyslog-pgsql/internal/reconfiguring
+ _db_cmd RESET rsyslog-pgsql/internal/reconfiguring
+ _db_internal_IFS=

+ IFS=
+ printf %s\n RESET rsyslog-pgsql/internal/reconfiguring
+ IFS=

+ read -r _db_internal_line
+ IFS=

+ RET=10 rsyslog-pgsql/internal/reconfiguring doesn't exist
+ return 10
+ return 10
dpkg: error processing package rsyslog-pgsql (--configure):
 installed rsyslog-pgsql package post-installation script subprocess returned 
error exit status 10

#+END_SRC

the last successful running part of the postinst script is the calling
of dbc_forget_app_password(), dbc_postinst_cleanup() is where 10 as an
exit code is returned and where the script fails.

As far as I can tell the error occurs because:

* db_reset $dbc_package/internal/reconfiguring returns 10, but the
  script fails to catch this by either appending || true nor by
  returning 0 at the end of the function.
* I also noticed that on systems where the postinst script is broken
  debconf does not hold any entries corresponding to the package;
  which may point into the right direction for a possible fix.

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

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

Versions of packages rsyslog-pgsql depends on:
ii  dbconfig-common2.0.19
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u3
ii  libpq5 13.5-0+deb11u1
ii  rsyslog8.2102.0-2
ii  ucf3.0043

Versions of packages rsyslog-pgsql recommends:
ii  postgresql-client 13+225
ii  postgresql-client-13 [postgresql-client]  13.5-0+deb11u1

Versions of packages rsyslog-pgsql suggests:
ii  postgresql  13+225

-- debconf information excluded

Bug#1009865: transition: octave

[Sébastien Villemot]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-oct...@lists.debian.org

Dear Release Team,

Please schedule a transition for octave. The new major upstream release
(7.1.0), currently in experimental, changes the ABI. 

Reverse dependencies have been rebuilt against the new version, and bugs filed:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=octave7;users=debian-oct...@lists.debian.org

Most of them are now fixed. Only three are left, one of which concerning a
package not in testing (octave-tisean), and the other two concerning leaf
packages for which there is no obvious fix, and that could temporarily be
removed from testing.

Ben file:

title = "octave";
is_affected = .depends ~ "octave-abi-56" | .depends ~ "octave-abi-57";
is_good = .depends ~ "octave-abi-57";
is_bad = .depends ~ "octave-abi-56";

Cheers,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#1008973: linux-image-amd64: Very slow wireless with MEDIATEK 7961

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2022-04-05 14:39, Xavier Chantry a écrit :
> Package: linux-image-amd64
> Version: 5.10.84-1
> Severity: important
> X-Debbugs-Cc: chantry.xav...@gmail.com
> 
> Dear Maintainer,
> 
> We have a problem with MEDIATEK 7961 wireless on Levono P14s with AMD
> Ryzen.
> 
> With 5.10 kernel on debian stable the wireless just does not work, so we
> installed kernel 5.16 from testing.
> 
> With kernel 5.16 the wireless is so slow that it's unusable, each
> internet query takes several seconds. A simple ping to google.com varies
> from 100ms to 3000ms.
> 
> With kernel 5.17 it's slighly better but the ping still goes up to
> 600ms.
> 
> With kernel 5.15 however, it works quite good, Internet is very usable,
> ping varies from 3ms to 30ms.
> (on the same network, the P14s with Intel wireless does better and is
> always under 10ms).
> 
> It looks like big changes were made to the mt7921e driver in 5.16
> according to Phoronix :
> The Mediatek MT7921 WiFi driver has added support for 6GHz WiFi, active
> state power management (ASPM), and other improvements.
> 
> And it looks like this caused a big regression with MEDIATEK 7961.
> 
> Besides the network performance problem on 5.16, suspend/resume is also
> broken, while it works perfectly on 5.15.

Le 2022-04-06 10:19, Christoph Martin a écrit :
> I have the same Problem with an P14s and Mediathek 7921e.
> There is even about 30% package loss.
> 
> Christoph
> 
> Am 05.04.22 um 14:39 schrieb Xavier Chantry:
> > 
> > With kernel 5.16 the wireless is so slow that it's unusable, each
> > internet query takes several seconds. A simple ping to google.com varies
> > from 100ms to 3000ms.
> > 
> > With kernel 5.17 it's slighly better but the ping still goes up to
> > 600ms.

Le 2022-04-15 14:19, Julien Negros a écrit :
> Hi,
> 
> Same issue here, switching to linux-image-5.15.0-0.bpo.3-amd64 did the
> trick. Hope the next kernel version fixes this problem !
> 
> Cheers
> -- 
> Julien Négros
 
Linux 5.17.3 (uploaded to unstable earlier today) includes a lot of fixes for
Mediatek WLAN devices. Could you please check if that kernel fixes the slowness
you are seeing?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1009864: xscreensaver: firefox stops (inhibits) xscreensaver from firing. Needs option to ignore firefox

[Tim Connors]

Package: xscreensaver
Version: 5.45+dfsg1-2
Severity: normal

All the search results on the internet are for doing the opposite of
what I want - people want firefox, when playing a video, to inhibit
xscreensaver.

It already does that for me.  xscreensaver -verbose:


xscreensaver-systemd: 23:28:03: uninhibited by "firefox-esr" with cookie 
DEB56E99
xscreensaver-systemd: 23:28:03: inhibit: unable to get pid of "firefox-esr": No 
data available
xscreensaver-systemd: 23:28:03: inhibited by "firefox-esr" with "video-playing" 
-> cookie ADCA6C0D
xscreensaver-systemd: 23:28:16: uninhibited by "firefox-esr" with cookie 
ADCA6C0D
xscreensaver-systemd: 23:28:16: inhibit: unable to get pid of "firefox-esr": No 
data available
xscreensaver-systemd: 23:28:16: inhibited by "firefox-esr" with "video-playing" 
-> cookie 57431273
xscreensaver-systemd: 23:28:28: uninhibited by "firefox-esr" with cookie 
57431273
xscreensaver-systemd: 23:28:28: inhibit: unable to get pid of "firefox-esr": No 
data available
xscreensaver-systemd: 23:28:28: inhibited by "firefox-esr" with "video-playing" 
-> cookie B8F2311F
xscreensaver-systemd: 23:28:41: uninhibited by "firefox-esr" with cookie 
B8F2311F
xscreensaver-systemd: 23:28:41: inhibit: unable to get pid of "firefox-esr": No 
data available

Only problem is I'm not playing a video.  Unfortunately, the net is
full of ads, so pretty much every page claims to be "playing a video".
I just want to be able to tell xscreensaver to ignore any calls from
this list of programs:

1) firefox-esr

Oh look at that, end of list.

Yes, I know the proper fix is to tell firefox to give me an option to
not inhibit the screensaver, but we all know how likely that feature
request is to ever be actioned without "CLOSED WONTFIX".

In the meantime, you're trusting every application not to be abusive.
In this case, firefox is being abusing, and there should be an
override to tell the system to ignore it.


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

Kernel: Linux 5.10.0-12-amd64 (SMP w/20 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.60
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u3
ii  libcrypt11:4.4.18-4
ii  libglib2.0-0 2.66.8-1
ii  libgtk2.0-0  2.24.33-2
ii  libpam0g 1.4.0-9+deb11u1
ii  libpango-1.0-0   1.46.2-3
ii  libsystemd0  247.3-7
ii  libx11-6 2:1.7.2-1
ii  libxext6 2:1.3.3-1.1
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxml2  2.9.10+dfsg-6.7+deb11u1
ii  libxmu6  2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxt6   1:1.2.0-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data5.45+dfsg1-2

Versions of packages xscreensaver recommends:
ii  libjpeg-turbo-progs 1:2.0.6-4
ii  perl5.32.1-4+deb11u2
ii  wbritish [wordlist] 2019.10.06-1
ii  wbritish-huge [wordlist]2019.10.06-1
ii  wbritish-insane [wordlist]  2019.10.06-1
ii  wbritish-large [wordlist]   2019.10.06-1
ii  wbritish-small [wordlist]   2019.10.06-1
ii  xfonts-100dpi   1:1.0.4+nmu1.1

Versions of packages xscreensaver suggests:
ii  chromium [www-browser]100.0.4896.127-1~deb11u1
ii  dillo [www-browser]   3.0.5-7
ii  falkon [www-browser]  3.1.0+dfsg1-11
ii  firefox-esr [www-browser] 91.8.0esr-1~deb11u1
ii  fortune-mod [fortune] 1:1.99.1-7.1
pn  gdm3 | kdm-gdmcompat  
ii  google-chrome-stable [www-browser]100.0.4896.127-1
ic  google-chrome-unstable [www-browser]  84.0.4115.5-1
ii  konqueror [www-browser]   4:20.12.0-4
ii  links [www-browser]   2.21-1+b1
ii  lynx [www-browser]2.9.0dev.6-3~deb11u1
pn  qcam | streamer   
ii  vivaldi-stable [www-browser]  5.2.2623.39-1
ii  w3m [www-browser] 0.5.3+git20210102-6
pn  xdaliclock
pn  xfishtank 
ii  xscreensaver-data-extra   5.45+dfsg1-2
ii  xscreensaver-gl   5.45+dfsg1-2
ii  xscreensaver-gl-extra 5.45+dfsg1-2

-- no debconf information

Bug#1009863: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330)

[Roderich Schupp]

Package: src:linux
Version: 5.17.3-1
Severity: normal
X-Debbugs-Cc: roderich.sch...@gmail.com



-- Package-specific info:
** Version:
Linux version 5.17.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.2.0-20) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 
5.17.3-1 (2022-04-18)

** Command line:
BOOT_IMAGE=/vmlinuz-5.17.0-1-amd64 root=/dev/mapper/nuc8--vg-root ro splash 
quiet apparmor=0

** Tainted: E (8192)
 * unsigned module was loaded

** Kernel log:
[   12.256432] pstore: Using crash dump compression: deflate
[   12.256440] pstore: Registered efi as persistent store backend
[   12.257761] mei_me :00:16.0: enabling device ( -> 0002)
[   12.265684] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   12.267995] EXT4-fs (nvme0n1p2): mounting ext2 file system using the ext4 
subsystem
[   12.270078] EXT4-fs (nvme0n1p2): mounted filesystem without journal. Quota 
mode: none.
[   12.270083] ext2 filesystem being mounted at /boot supports timestamps until 
2038 (0x7fff)
[   12.285847] cfg80211: Loading compiled-in X.509 certificates for regulatory 
database
[   12.286042] cfg80211: Loaded X.509 cert 'b...@debian.org: 
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[   12.286212] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[   12.286358] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   12.287203] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db
[   12.287679] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db.p7s
[   12.317942] iTCO_wdt iTCO_wdt: Found a Intel PCH TCO device (Version=6, 
TCOBASE=0x0400)
[   12.318064] iTCO_wdt iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   12.325095] Intel(R) Wireless WiFi driver for Linux
[   12.325142] iwlwifi :00:14.3: enabling device ( -> 0002)
[   12.326053] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters, 655360 ms 
ovfl timer
[   12.326056] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[   12.326057] RAPL PMU: hw unit of domain package 2^-14 Joules
[   12.326058] RAPL PMU: hw unit of domain dram 2^-14 Joules
[   12.326059] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[   12.326059] RAPL PMU: hw unit of domain psys 2^-14 Joules
[   12.330089] iwlwifi :00:14.3: firmware: direct-loading firmware 
iwlwifi-9000-pu-b0-jf-b0-46.ucode
[   12.330114] iwlwifi :00:14.3: WRT: Overriding region id 0
[   12.330116] iwlwifi :00:14.3: WRT: Overriding region id 1
[   12.330118] iwlwifi :00:14.3: WRT: Overriding region id 2
[   12.330119] iwlwifi :00:14.3: WRT: Overriding region id 3
[   12.330121] iwlwifi :00:14.3: WRT: Overriding region id 4
[   12.330122] iwlwifi :00:14.3: WRT: Overriding region id 6
[   12.330124] iwlwifi :00:14.3: WRT: Overriding region id 8
[   12.330125] iwlwifi :00:14.3: WRT: Overriding region id 9
[   12.330127] iwlwifi :00:14.3: WRT: Overriding region id 10
[   12.330128] iwlwifi :00:14.3: WRT: Overriding region id 11
[   12.330130] iwlwifi :00:14.3: WRT: Overriding region id 15
[   12.330131] iwlwifi :00:14.3: WRT: Overriding region id 16
[   12.330132] iwlwifi :00:14.3: WRT: Overriding region id 18
[   12.330134] iwlwifi :00:14.3: WRT: Overriding region id 19
[   12.330135] iwlwifi :00:14.3: WRT: Overriding region id 20
[   12.330137] iwlwifi :00:14.3: WRT: Overriding region id 21
[   12.330138] iwlwifi :00:14.3: WRT: Overriding region id 28
[   12.330967] iwlwifi :00:14.3: loaded firmware version 46.6b541b68.0 
9000-pu-b0-jf-b0-46.ucode op_mode iwlmvm
[   12.331002] iwlwifi :00:14.3: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[   12.331009] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   12.347550] Adding 6291452k swap on /dev/mapper/nuc8--vg-swap_1.  
Priority:-2 extents:1 across:6291452k SSFS
[   12.357627] snd_hda_intel :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040380
[   12.357744] snd_hda_intel :00:1f.3: enabling device ( -> 0002)
[   12.358030] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   12.428895] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: 
bound :00:02.0 (ops i915_hdcp_component_ops [i915])
[   12.450898] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC233: 
line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:hp
[   12.450905] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   12.450907] snd_hda_codec_realtek hdaudioC0D0:hp_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   12.450910] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   12.450911] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   12.450913] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x19
[   12.450914] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[   12.535162] Bluetooth: Core ver 2.22
[   12.535212] NET: Registered PF_BLUETOOTH 

Bug#1009861: intel-microcode: Laptop DELL Studio 1555 freeze after update of intel-microcode

[ilexa]

Package: intel-microcode
Version: 3.20220207.1~deb10u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I have started updating the system via apt-get update and upgrade. New version 
of intel-microcode was buster/non-free: 3.20220207.1~deb10u1

System booted normally but started to crash/freeze with garbadge screen and did 
not response to any keyboard combination after starting Firefox browser and let 
say watching YouTube video.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I revert back to old package 3.20210608.2~deb10u1 and this bring back the 
stable state of system. No more crashes or garbadge screen.

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 4.19.0-20-amd64 (SMP w/2 CPU cores)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), 
LANGUAGE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages intel-microcode depends on:
ii  iucode-tool  2.3.1-1

Versions of packages intel-microcode recommends:
ii  initramfs-tools  0.133+deb10u1

intel-microcode suggests no packages.

-- no debconf information

Bug#1009862: mirror submission for archive.debian.petiak.ir

[Arash Sadeghi]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: archive.debian.petiak.ir
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Arash Sadeghi 
Country: IR Iran, Islamic Republic of
Location: Tehran
Sponsor: Petiak https://www.petiak.com
Comment: Greeting from Tehran,
 
 We had some misconfiguration which had been solved already.
 Please add our mirror to official Debian's archives mirrors.
 We'd like to become country mirror for Iran.
 
 Thanks,
 Arash




Trace Url: http://archive.debian.petiak.ir/debian/project/trace/
Trace Url: 
http://archive.debian.petiak.ir/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://archive.debian.petiak.ir/debian/project/trace/archive.debian.petiak.ir

Bug#1009764: [pkg-crosswire-devel] Processed: Re: Bug#1009764: xiphos: freezes when page is changed

[Fr Cyrille]

Le 18/04/2022 à 19:15, Bastian Germann a écrit :

Am 17.04.22 um 23:24 schrieb Fr Cyrille:

I have the same issue on Macbook Pro (of course with Ubuntu 20.04).
Maybe this bug have to be reported upstream.


So can you provide more info? Does this happen with every Bible module?


I don't have the computer with me, but yes it seems to be randomly.

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

19.04.2022 16:02, Vincent Lefevre wrote:

On 2022-04-19 15:15:11 +0300, Michael Tokarev wrote:

unbound resolvconf integration (the disabled one) works by setting
DNS servers obtained via DHCP to become the forwarders in
unbound.  As simple as that.  I'm not saying about 127.0.0.1
filtering there, it's a different issue.

If we (re)enable /etc/resolvconf/update.d/unbound , the dhcp-provided
nameservers will be used as the primary nameservers with unbound sitting
just as a local cache. Unbound will not use them as fallbacks but as
primary forwarders.


The issue is that resolvconf assumes that unbound will use them
as fallbacks (see below).


Um. Did you forget to describe this "below" case? I don't see where you
wrote that below.


The only way to do what - I think - you're asking for, is for
resolvconf to modify /etc/resolv.conf file to specify one unbound-
provided nameserver line (with 127.0.0.1 in there) and *add* the
dhcp-provided nameservers there *too*. And you don't want in this
case to enable unbound's resolvconf integration.


resolvconf actually does the opposite: instead of leaving the
/etc/resolv.conf contents as is, it removes every nameserver
after 127.0.0.1, assuming that they will be handled by the
local nameserver.


Yes, I know what it does, and why.  It assumes whatever is running
at 127.* is a local caching thing which will do its own forwarding
when needed, and for that forwarding resolvconf gives it the
dhcp-provided nameservers.  What I wrote is the only way I know
to achieve what you wanted.


Perhaps this is something to see with the resolvconf authors.


I don't think this is in the scope of resolvconf people, because
the whole purpose of resolvconf is different.


But this doesn't really work and it is unreliable.  Because quite
some software will query *all* nameservers listed in resolv.conf
at the same time (accepting the first reply), and some software
will only query the first one.


This would clearly be a bug, as not conforming with the
/etc/resolv.conf spec. See the resolv.conf(5) man page:


I know perfectly well what resolv.conf manage says.  And I know
perfectly well that software already uses it in slightly different
ways, for different reasons. Usually you don't have lots of stuff
in there - it is either your upstream nameservers from dhcp, or
something like 8.8.8.8, or 127.0.0.{1,53} which is your local
dns cache.  In most cases it is irrelevant in which way or in
which order you query them.

I tend to close this bug report, Vincent.  This is not the intended
usage of resolvconf, and is not something to fix in unbound, either.
Unbound can either accept whatever resolvconf gives it from dhcp and
use that as its own forwarders (with the the script in $subject
enabled), or it can continue to perform recursive queries as before,
starting with the root nameservers.  There's no such thing as a
"fallback" here, at all.

Thanks,

/mjt

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-19 15:15:11 +0300, Michael Tokarev wrote:
> unbound resolvconf integration (the disabled one) works by setting
> DNS servers obtained via DHCP to become the forwarders in
> unbound.  As simple as that.  I'm not saying about 127.0.0.1
> filtering there, it's a different issue.
> 
> If we (re)enable /etc/resolvconf/update.d/unbound , the dhcp-provided
> nameservers will be used as the primary nameservers with unbound sitting
> just as a local cache. Unbound will not use them as fallbacks but as
> primary forwarders.

The issue is that resolvconf assumes that unbound will use them
as fallbacks (see below).

> The only way to do what - I think - you're asking for, is for
> resolvconf to modify /etc/resolv.conf file to specify one unbound-
> provided nameserver line (with 127.0.0.1 in there) and *add* the
> dhcp-provided nameservers there *too*. And you don't want in this
> case to enable unbound's resolvconf integration.

resolvconf actually does the opposite: instead of leaving the
/etc/resolv.conf contents as is, it removes every nameserver
after 127.0.0.1, assuming that they will be handled by the
local nameserver.

Perhaps this is something to see with the resolvconf authors.

> But this doesn't really work and it is unreliable.  Because quite
> some software will query *all* nameservers listed in resolv.conf
> at the same time (accepting the first reply), and some software
> will only query the first one.

This would clearly be a bug, as not conforming with the
/etc/resolv.conf spec. See the resolv.conf(5) man page:

  nameserver Name server IP address
Internet address of a name server that the resolver should query,
either an IPv4 address (in dot notation), or an IPv6 address in
colon (and possibly dot) notation as per RFC 2373. Up to MAXNS
(currently 3, see ) name servers may be listed, one per
keyword. If there are multiple servers, the resolver library
 ^^^
queries them in the order listed. If no nameserver entries are
^
present, the default is to use the name server on the local
machine. (The algorithm used is to try a name server, and if the
query times out, try the next, until out of name servers, then
repeat trying all the name servers until a maximum number of
retries are made.)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1009844: debhelper: Build failed with dh_installalternatives: error: Alternative ...

[Colin Watson]

Control: affects -1 src:openssh

On Tue, Apr 19, 2022 at 12:05:22PM +0900, Hiroyuki YAMAMORI wrote:
> When rebuilding rsh-redone, the following message is output and the build 
> fails.
> 
> dh_installalternatives: error: Alternative "/usr/bin/rsh-redone-rsh" for 
> "rsh" in debian/rsh-redone-client.alternatives does not exist in 
> debian/rsh-redone-client or is a directory
> make: *** [debian/rules:16: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2
> 
> 
> Solved with the following patch.
> 
> --- a/usr/bin/dh_installalternatives
> +++ b/usr/bin/dh_installalternatives
> @@ -99,7 +99,7 @@ sub _parse_alternative_and_generate_main
> if (index($link_name, '/') > -1) {
> error(qq{Invalid link name "${link_name}" in 
> "${alternatives_file}": Must not contain slash});
> }
> -   if ( ! -l "${tmpdir}/${impl_path}" or -d _) {
> +   if ( ! -e "${tmpdir}/${impl_path}" or -d _ or ! -r _) {
> error(qq{Alternative "${impl_path}" for "${link_name}" in 
> ${alternatives_file} does not exist in ${tmpdir} or is a directory});
> }
> if ($link_name eq $impl_path) {

This also causes openssh to fail to build (see e.g.
https://salsa.debian.org/flurb/openssh/-/jobs/2683517).  Something like
this patch looks reasonable to me, and at any rate the previous code
doesn't make sense; it seems to require the potential *target* of the
alternative to be a symlink.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1007115: [Debian-on-mobile-maintainers] Bug#1007115: squeekboard covers applications in landscape

[Jeremy Bicha]

Control: forwarded -1
https://gitlab.gnome.org/World/Phosh/squeekboard/-/issues/327

The upstream report suggests this issue was fixed in the 1.17.1 release.

Thank you,
Jeremy Bicha

Bug#200715: Halo how are you dear

[khateb Adams]

Bug#1009860: RM: nemiver -- RoM; FTBFS; unmaintained, use gnome-builder instead

[Jeremy Bicha]

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

Please remove nemiver from Debian.

This request was approved by the package maintainer in
https://bugs.debian.org/1008781

Nemiver has been archived upstream, which means that bugfixes,
translations, and even bug reports are no longer accepted:
https://gitlab.gnome.org/Archive/nemiver

It has failed to build for more than a year in Debian.

The latest version of ghex switched to GTK4. Nemiver would need to be
ported to GTK4 to build with the new ghex library but nobody is
working on this.

GNOME Builder is the recommended replacement for nemiver.

Thank you,
Jeremy Bicha

Bug#1007170: transition: qtbase-opensource-src

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/qtbase-abi-5-15-3.html

On 2022-03-12 20:46:57, Dmitry Shachnev wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> Source code for Qt 5.15.3 was released recently (source code for 5.15.x
> is published after a year from the corresponding commercial release).
> 
> I have now prepared this release in experimental. As usual, we have private
> ABI change for qtbase and qtdeclarative.

With python3.10-default now done, please go ahead.

Cheers

> 
> Ben file (based on the previous one [1]):
> 
> title = "qtbase-opensource-src and qtdeclarative-opensource-src";
> is_affected = .depends ~ "qtdeclarative-abi-5-15-2" | .depends ~ 
> "qtdeclarative-abi-5-15-3" | .depends ~ "qtbase-abi-5-15-2" | .depends ~ 
> "qtbase-abi-5-15-3";
> is_good = .depends ~ "qtbase-abi-5-15-3" | .depends ~ 
> "qtdeclarative-abi-5-15-3";
> is_bad = .depends ~ "qtbase-abi-5-15-2" | .depends ~ 
> "qtdeclarative-abi-5-15-2";
> 
> The only blocker known to me is libwebp regression (#1006009), but we can NMU
> it again if needed.
> 
> [1]: 
> https://salsa.debian.org/release-team/transition-data/-/blob/master/old/qtbase-abi-5-15-2.ben
> 
> --
> Dmitry Shachnev



-- 
Sebastian Ramacher

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

19.04.2022 14:11, Vincent Lefevre wrote:

On 2022-04-19 13:22:53 +0300, Michael Tokarev wrote:

In my understanding over the years, I expected the nameservers
received from/by DHCP should be used *first*. I did this with
unbound or dnsmasq even before resolvconf has been written -
using custom dhcp script to reconfigure local DNS resolver.

I don't even know unbund has a way to specify "fallback"
nameservers. You either set forwarders for a zone or you don't,
there's no _notion_ of fallback per se.


The fallback is what resolvconf expects and precisely why
bug 1003135 was reassigned from resolvconf to unbound:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003135#40

   "In fact, unbound comes with resolvconf integration, so it should
   know about other nameservers coming from DHCP. [...]"


I still don't understand you here.

unbound resolvconf integration (the disabled one) works by setting
DNS servers obtained via DHCP to become the forwarders in
unbound.  As simple as that.  I'm not saying about 127.0.0.1
filtering there, it's a different issue.

If we (re)enable /etc/resolvconf/update.d/unbound , the dhcp-provided
nameservers will be used as the primary nameservers with unbound sitting
just as a local cache. Unbound will not use them as fallbacks but as
primary forwarders.

The only way to do what - I think - you're asking for, is for
resolvconf to modify /etc/resolv.conf file to specify one unbound-
provided nameserver line (with 127.0.0.1 in there) and *add* the
dhcp-provided nameservers there *too*. And you don't want in this
case to enable unbound's resolvconf integration.

But this doesn't really work and it is unreliable.  Because quite
some software will query *all* nameservers listed in resolv.conf
at the same time (accepting the first reply), and some software
will only query the first one.

/mjt

Bug#1008823: transition: thrift

[Sebastian Ramacher]

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

On 2022-04-02 11:48:40, László Böszörményi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi RMs,
> 
> A quick transition of thrift from 0.13.0 to 0.16.0 as the only reverse
> build dependency is gnuradio. It builds with the new thrift version as
> well.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1009835: transition: hmat-oss

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-04-18 20:57:00, Pierre Gruet wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release team,
> 
> I would like to request a transition slot for hmat-oss. This would be a
> tiny transition with only 1 reverse dependency. The reason is upstream changed
> the interface quite a lot recently. The version I would like to upload to
> unstable has cleared NEW.
> 
> The automatic ben file looks good.
> 
> The reverse dependency:
> * openturns
> ftbfs with the new library, but (as it is team-maintained by Debian Science
> team, of which I am a member) I have uploaded a fixed version of it to
> experimental, and it builds fine. A bug with severity important has been 
> filed.
> I am ready to start transitioning when you tell me.
> 
> openturns is also part of other ongoing transitions, it will comply with all
> of them.

openturns is not in testing, so please feel free to go ahead.

Cheers

> 
> Best regards,
> 
> -- 
> Pierre
> 

-- 
Sebastian Ramacher

Bug#1009859: sbuild does not download http(s) .dsc files if libwww-perl is not installed

[Carles Pina i Estany]

Package: sbuild
Version: 0.81.2
Severity: normal
Tags: upstream

Dear Maintainer,

sbuild does not download packages unless libwww-perl is installed.

To reproduce:

$ docker run -it debian:bullseye /bin/bash # just to have a clean system
# apt-get update && apt-get -y install sbuild # same final result as using "apt 
install sbuild"
# sbuild --no-clean --arch-any --arch-all --no-source --dist=stable 
--arch=amd64  http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-2.dsc
E: Failed to open build log 
//http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-2.dsc_amd64-2022-04-19T10:20:26Z.build:
 No such file or directory
E: Error creating chroot

I expected the .dsc file to be downloaded.

After installing libwww-perl sbuild works as expected:

# apt-get -y install libwww-perl

# sbuild --no-clean --arch-any --arch-all --no-source --dist=stable 
--arch=amd64  http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-2.dsc # 
it downloads the package as expected


Not a Perl programmer here but I followed the code:

/usr/bin/sbuild around line 103 does "check_url($jobname)" which is implemented 
in /usr/share/perl5/Sbuild/Utility.pm around line 166. It does:

# Load LWP::UserAgent if possible, else return 0.
if (! can_load( modules => { 'LWP::UserAgent' => undef, } )) {
return 0;
}

Without libwww-perl package installed it returns 0. Then sbuild assumes that
http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-2.dsc is a
local file.

I don't know if the way to go is to make the error message more helpful
(suggesting to install the package?), or make libwww-perl a dependency
(or at least recommended). Or perhaps add a note in the manual? It
currently says "For .dsc files  in  remote locations,  the source
packages are downloaded first, then built." without noting that
libwww-perl is required for this.

Thank you,


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

Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.81.2
ii  perl5.32.1-4+deb11u2

Versions of packages sbuild recommends:
ii  autopkgtest  5.16
ii  debootstrap  1.0.123
ii  schroot  1.6.10-12

Versions of packages sbuild suggests:
ii  deborphan  1.7.33
ii  e2fsprogs  1.46.2-2
ii  kmod   28-1
ii  wget   1.21-1+deb11u1

-- no debconf information

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-19 13:22:53 +0300, Michael Tokarev wrote:
> In my understanding over the years, I expected the nameservers
> received from/by DHCP should be used *first*. I did this with
> unbound or dnsmasq even before resolvconf has been written -
> using custom dhcp script to reconfigure local DNS resolver.
> 
> I don't even know unbund has a way to specify "fallback"
> nameservers. You either set forwarders for a zone or you don't,
> there's no _notion_ of fallback per se.

The fallback is what resolvconf expects and precisely why
bug 1003135 was reassigned from resolvconf to unbound:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003135#40

  "In fact, unbound comes with resolvconf integration, so it should
  know about other nameservers coming from DHCP. [...]"

Note: resolvconf filters out nameservers coming from DHCP only those
that are placed after 127.0.0.1, i.e. those that are normally used as
a fallback when resolvconf isn't installed, because it assumes that
this fallback is provided by the local nameserver (here, unbound).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1009858: linux: please consider building the modules necessary for the MNT Reform laptop

[Johannes Schauer Marin Rodrigues]

Source: linux
Version: 5.10.106-1
Severity: wishlist
X-Debbugs-Cc: jo...@debian.org

Hi,

currently, we add the following to the arm64 kernel config provided by
the Debian kernel packaging to build a kernel that powers the MNT Reform
2 open source laptop:

CONFIG_DRM_LVDS_CODEC=m
CONFIG_DRM_SIMPLE_BRIDGE=m
CONFIG_DRM_TI_SN65DSI86=m
CONFIG_DRM_CDNS_MHDP8546=m
CONFIG_DRM_CDNS_HDMI_CEC=m
CONFIG_DRM_IMX_CDNS_MHDP=m
CONFIG_DRM_IMX_DCSS=m
CONFIG_DRM_PANEL_LVDS=m
CONFIG_I2C_IMX_LPI2C=m
CONFIG_I2C_MUX_REG=m
CONFIG_INTERCONNECT_IMX=m
CONFIG_INTERCONNECT_IMX8MQ=m
CONFIG_MFD_WM8994=m
CONFIG_MUX_GPIO=m
CONFIG_MUX_MMIO=m
CONFIG_RTC_DRV_PCF8523=m
CONFIG_USB_EHCI_FSL=m
CONFIG_BACKLIGHT_GPIO=m
CONFIG_BACKLIGHT_LED=m
CONFIG_NO_HZ_IDLE=y
CONFIG_SND_SOC_WM8960=m
CONFIG_SND_SOC_FSL_MICFIL=m
CONFIG_SND_IMX_SOC=m
CONFIG_SND_SOC_FSL_ASOC_CARD=m
CONFIG_SND_SOC_IMX_AUDMIX=m
CONFIG_SND_SOC_IMX_HDMI=m

Would you consider enabling these modules in the official Debian
packaging?

We still carry some patches that are not upstreamed yet but I wanted to
bring up this topic with you already to discuss this in parallel.

Thanks!

cheers, josch

Bug#989959: unbound: Corrupt/empty trust anchor file is not healed upon start

[Michael Tokarev]

On Mon, 18 Apr 2022 08:43:24 +0300 Michael Tokarev  wrote:
..

Maybe we can always update this (very small) file as a part of the
daemon startup procedure.


It looks like I completely misunderstood this file purpose.
Am I right this is just the initial key and unbound updates
this key automatically by its own?

auto-trust-anchor-file: 
 File with trust anchor for one zone, which is tracked with RFC5011 probes.

Okay, it smells like it is, and it definitely it should not
be copied from /usr/share/dns/root.key..

I'll re-do my changes there (which I already comitted).

But now I've a question: how the initial problem happened?

The script (/usr/lib/unbound/package-helper) use install(1)
to update the file and to chown it (this also smells unsafe
from the security PoV). And install unlinks the destination
file first, creates destination file, writes contents to
it, and closes it.  It looks like we should not use install(1)
here, or maybe install it to .tmp and mv it atomically, -
and from _there_, the problem will just go away.

/mjt

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

[Karel Zak]

On Tue, Apr 12, 2022 at 04:25:14PM +0200, наб wrote:
> Added pty->free_buffers where we put free-to-use (fully-written-out buffers)
> instead of free()ing them; my testing indicates, that for interactive use
> we allocate a single buffer and re-use 100% of the time.
 
Cool.

>  include/pty-session.h |   7 +++
>  lib/pty-session.c | 126 ++
>  2 files changed, 110 insertions(+), 23 deletions(-)

Applied, thanks!

Please, next time use "Signed-off-by:" line :-)

Karel


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

Bug#1009857: python3-hy: 'hy' fails to start

[Debian/GNU]

Package: python3-hy
Version: 0.19.0-2
Severity: important

Dear Maintainer,

starting 'hy' from the cmdline gives stops immediately with a
traceboack.
doing an 'import hy' from Python3.10, works fine though.


```
$ python3 -m hy
$ echo $?
0

$ hy3
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 1696, in 
compile_eval_and_compile
hy_eval(new_expr + body,
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 2109, in hy_eval
eval(ast_compile(_ast, filename, "exec"),
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 64, in ast_compile
return compile(a, filename, mode, hy_ast_compile_flags)
TypeError: required field "lineno" missing from alias

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/hy3", line 12, in 
sys.exit(hy_main())
  File "/usr/lib/python3/dist-packages/hy/cmdline.py", line 662, in hy_main
sys.exit(cmdline_handler("hy", sys.argv))
  File "/usr/lib/python3/dist-packages/hy/cmdline.py", line 653, in 
cmdline_handler
return run_repl(
  File "/usr/lib/python3/dist-packages/hy/cmdline.py", line 442, in run_repl
hr = HyREPL(**kwargs)
  File "/usr/lib/python3/dist-packages/hy/cmdline.py", line 249, in __init__
self.hy_compiler = HyASTCompiler(self.module)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 399, in __init__
load_macros(self.module)
  File "/usr/lib/python3/dist-packages/hy/macros.py", line 230, in load_macros
builtin_mod = importlib.import_module(builtin_mod_name)
  File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 1006, in _find_and_load_unlocked
  File "", line 688, in _load_unlocked
  File "", line 879, in exec_module
  File "", line 1017, in get_code
  File "/usr/lib/python3/dist-packages/hy/importer.py", line 128, in 
_hy_source_to_code
data = hy_compile(hy_tree, module)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 2195, in hy_compile
result = compiler.compile(tree)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 448, in compile
reraise(type(e), e, sys.exc_info()[2])
  File "/usr/lib/python3/dist-packages/hy/_compat.py", line 14, in reraise
raise value.with_traceback(traceback)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 438, in compile
ret = self.compile_atom(tree)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 432, in 
compile_atom
return Result() + _model_compilers[type(atom)](self, atom)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 1782, in 
compile_expression
return Result() + build_method(
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 643, in compile_do
return self._compile_branch(body)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 515, in 
_compile_branch
for x in map(self.compile, exprs[:-1]):
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 448, in compile
reraise(type(e), e, sys.exc_info()[2])
  File "/usr/lib/python3/dist-packages/hy/_compat.py", line 14, in reraise
raise value.with_traceback(traceback)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 438, in compile
ret = self.compile_atom(tree)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 432, in 
compile_atom
return Result() + _model_compilers[type(atom)](self, atom)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 1782, in 
compile_expression
return Result() + build_method(
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 1712, in 
compile_eval_and_compile
reraise(HyEvalError,
  File "/usr/lib/python3/dist-packages/hy/_compat.py", line 14, in reraise
raise value.with_traceback(traceback)
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 1696, in 
compile_eval_and_compile
hy_eval(new_expr + body,
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 2109, in hy_eval
eval(ast_compile(_ast, filename, "exec"),
  File "/usr/lib/python3/dist-packages/hy/compiler.py", line 64, in ast_compile
return compile(a, filename, mode, hy_ast_compile_flags)
hy.errors.HyEvalError:
  File "[HyExpression([
  HySymbol('import'),
  HySymbol('hy')]), HyExpression([
  HyExpression([
HySymbol('hy.macros.macro'),
HyString('defmacro')]),
  HyExpression([
HySymbol('fn'),
HyList([
  HySymbol(''),
  HySymbol('macro-name'),
  HySymbol('lambda-list'),
  HySymbol(''),
  HySymbol('body')]),
HyString('the defmacro macro'),
HyExpression([
  HySymbol('if*'),
  HyExpression([
HySymbol('not'),
HyExpression([
  HySymbol('isinstance'),
  HySymbol('macro-name'),
  HySymbol('hy.models.HySymbol')])]),
  HyExpression([

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Michael Tokarev]

19.04.2022 13:09, Vincent Lefevre wrote:
...> The way resolvconf expects it to work is to use the usual method,

and in case of an error, fall back to the upstream nameservers.

Since the upstream nameservers should be used as a fallback, I don't
see why this would be problematic.


hm.. now this is interesting.

In my understanding over the years, I expected the nameservers
received from/by DHCP should be used *first*. I did this with
unbound or dnsmasq even before resolvconf has been written -
using custom dhcp script to reconfigure local DNS resolver.

I don't even know unbund has a way to specify "fallback"
nameservers. You either set forwarders for a zone or you don't,
there's no _notion_ of fallback per se.

Now I wonder if my understanding is completely out of this world..

/mjt

Bug#1009856: chrony: Support refclock in /etc/chrony/sources.d

[Stephan Austermühle]

Package: chrony
Version: 4.0-8+deb11u2
Severity: important

Dear Maintainer,

please consider adding support for 'refclock' in /etc/chrony/sources.d.

Some compute providers (Azure, Hetzner, KVM) support PTP as a
high-precision alternative to NTP but that feature requires to
configure a refclock in chrony.

Example (works for Azure, Hetzner, and KVM):

refclock PHC /dev/ptp0 poll 2 dpoll -2 offset 0

Note that using PTP usually requires loading a corresponding Linux
kernel module, too (e.g., ptp_kvm).

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

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/32 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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chrony depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  iproute2 5.10.0-4
ii  libc62.31-13+deb11u3
ii  libcap2  1:2.44-1
ii  libedit2 3.1-20191231-2+b1
ii  libgnutls30  3.7.1-5
ii  libnettle8   3.7.3-1
ii  libseccomp2  2.5.1-1+deb11u1
ii  tzdata   2021a-1+deb11u3
ii  ucf  3.0043

chrony recommends no packages.

Versions of packages chrony suggests:
ii  bind9-dnsutils [dnsutils]  1:9.16.27-1~deb11u1
ii  dnsutils   1:9.16.27-1~deb11u1
pn  networkd-dispatcher

-- Configuration Files:
/etc/default/chrony changed:
DAEMON_OPTS="-F 1 -P 0"


-- no debconf information

Bug#927877: unbound: "Warning: query response not set" with dig, i.e. QR bit not set in the response

[Michael Tokarev]

19.04.2022 12:59, Vincent Lefevre wrote:

On 2022-04-19 12:38:24 +0300, Michael Tokarev wrote:

..

I for one don't know what a maintainer has to do with this bug.


Note that I've let the bug closed since it is not clear that the
issue will occur again.


Oh. This is what happens when you start doing $stuff in -ENOCOFFEE mode :)

I was sure you reopened it.  A small thought occured to me to actually
think that "notfixed" != "reopen", but that was quickly faded out :))

Please excuse me for this misunderstanding.

Thank you for your patience and for good work!

/mjt

Bug#1005775: ksmbd-tools: backport package for bullseye

[Gürkan Myczko]

Dear Maintainer,


Hello Solya


Linux kernel 5.15 is already available for bullseye backports, and is
also the default kernel for Raspberry Pi OS, which brings ksmbd kernel
module for bullseye users. Is there any chance someone might be
interested in providing a backport of ksmbd-tools to bullseye users as
well?


That's a good idea. I have requested get to the ACL to be able to 
maintain

a backport of it, two weeks ago. Once I get the access to it, it should
appear shortly.

Best,
Alex


Best regards,
Reka
-BEGIN PGP SIGNATURE-
Version: BCPG C# v1.8.10.0

iQE4BAEBCAAiBQJiCqKtGxxTb2x5YSBSZWthIDxyZWthQGJ1dGEubW9lPgAKCRDX
S8NKJK0NOpTQB/0auYkLY4XG0oTnKZcntAtX2swnKppCS8UXQK+daXQ2R5TyC0vz
tR40npLEN9uLNBcQS+F3m+IUpem2Al+0z9s6chcMaXGiiwnAX9W8+6IxSC8Eums6
VXIxgaO0jhpujWOkL8SDtOOkv9pvHCPTi/CsXvr0E0aOoYOtxPcTdQk2/WlMzxsz
ZJsbFCVXsPobMXWf0gKlyUXhu6GFi+G0LJrtXAWEOecHKUkZjGHDLdyMSl680J6Q
8ENrUlcQW3S/7L1bd0NXsN9cmqDTcTvQLnItTzUf89MQhCzRlOiOoUpv/hHVWtcZ
g7wCXUT9HAEcD9Zh2B3mIKWwBPxS6ppon39N
=bKl3
-END PGP SIGNATURE-

Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy

[Vincent Lefevre]

On 2022-04-18 10:26:46 +0300, Michael Tokarev wrote:
> On Wed, 19 Jan 2022 16:33:46 +0100 Vincent Lefevre  wrote:
> > Package: unbound
> > Version: 1.13.1-1
> > Severity: important
> > 
> > Note: The changes I've done on /etc/resolvconf/update.d/unbound
> > is just logging messages (to known what's going on).
> > 
> > When /run/resolvconf/interface/NetworkManager is obsolete (which
> > can occur as NetworkManager is not the only was to connect: I use
> > it only for wifi), DNS resolution no longer works.
> > 
> > I fear that even when this file is not obsolete, unbound does not
> > work as expected.
> 
> Well, this file is *disabled*.

But the fact that it is disabled is a bug:

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

> We added a note to this file telling just that, to clarify:
> 
> +# This update hook is **disabled** by default: the execute bit is not set.
> +#
> +# This hook can be problematic, especially if the
> +# upstream nameservers do not perform DNSSEC validation, or if a
> +# "forward-zone" declaration for the root zone has been statically
> +# configured by the administrator. In previous versions, the hook was
> +# enabled by default, but it is now disabled by default. It can be
> +# explicitly enabled by running "chmod +x /etc/resolvconf/update.d/unbound".
> +#
> +# If enabled (by setting the execute bit), upstream nameservers
> +# supplied by resolvconf will be configured into the running Unbound instance
> +# via the "unbound-control forward" command.
> +#
> 
> But besides that, what exactly do *you* think is buggy about it?

The way resolvconf expects it to work is to use the usual method,
and in case of an error, fall back to the upstream nameservers.

Since the upstream nameservers should be used as a fallback, I don't
see why this would be problematic.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1009367: libnss3 file location changes

[Stephan Verbücheln]

Further analysis shows that it is related to changed file locations
between the libnss3 versions. Some files were moved out of the nss
directory.

Files in stable (libnss3 2:3.61-1+deb11u2):
/usr/lib/x86_64-linux-gnu/libnss3.so
/usr/lib/x86_64-linux-gnu/libnssutil3.so
/usr/lib/x86_64-linux-gnu/libsmime3.so
/usr/lib/x86_64-linux-gnu/libssl3.so
/usr/lib/x86_64-linux-gnu/nss/libfreebl3.chk
/usr/lib/x86_64-linux-gnu/nss/libfreebl3.so
/usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.chk
/usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.so
/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
/usr/lib/x86_64-linux-gnu/nss/libnssdbm3.chk
/usr/lib/x86_64-linux-gnu/nss/libnssdbm3.so
/usr/lib/x86_64-linux-gnu/nss/libsoftokn3.chk
/usr/lib/x86_64-linux-gnu/nss/libsoftokn3.so
/usr/share/doc/libnss3/changelog.Debian.gz
/usr/share/doc/libnss3/copyright
/usr/share/lintian/overrides/libnss3

Files in unstable (libnss3 2:3.77-1):
/usr/lib/x86_64-linux-gnu/libfreebl3.chk
/usr/lib/x86_64-linux-gnu/libfreebl3.so
/usr/lib/x86_64-linux-gnu/libfreeblpriv3.chk
/usr/lib/x86_64-linux-gnu/libfreeblpriv3.so
/usr/lib/x86_64-linux-gnu/libnss3.so
/usr/lib/x86_64-linux-gnu/libnssckbi.so
/usr/lib/x86_64-linux-gnu/libnssdbm3.chk
/usr/lib/x86_64-linux-gnu/libnssdbm3.so
/usr/lib/x86_64-linux-gnu/libnssutil3.so
/usr/lib/x86_64-linux-gnu/libsmime3.so
/usr/lib/x86_64-linux-gnu/libsoftokn3.chk
/usr/lib/x86_64-linux-gnu/libsoftokn3.so
/usr/lib/x86_64-linux-gnu/libssl3.so
/usr/share/doc/libnss3/changelog.Debian.gz
/usr/share/doc/libnss3/copyright
/usr/share/lintian/overrides/libnss3

QUICK FIX
Manually creating a nss directory with symlinks to the shared objects
appears to fix the problem. However, that is not a good solution as it
could have undesired side effects.

I am not sure whether it is the job for libnss3 or evolution
maintainers to fix this.

Regards

Bug#927877: unbound: "Warning: query response not set" with dig, i.e. QR bit not set in the response

[Vincent Lefevre]

On 2022-04-19 12:38:24 +0300, Michael Tokarev wrote:
> 19.04.2022 11:51, Vincent Lefevre wrote:
> ..
> > Since there is no way to know whether there was any fix (or even
> > any change that would make the issue disappear as a side effect),
> > let's rather tag the bug as unreproducible.
> 
> Hi Vincent!
> 
> Out of curiocity, what do you expect this bug staying like this
> to give us?  Even you, as you report, were seeing the problem for
> only 20 minutes after which it disappeared, and it was quite some
> time ago, with a log has changed since that.
> 
> I for one don't know what a maintainer has to do with this bug.

Note that I've let the bug closed since it is not clear that the
issue will occur again.

But it is always better to ensure that the bug metadata are meaningful
in case the issue reappears. This is what I've done.

A bug should be marked as fixed only if something was done to change
the behavior (with the goal to fix the bug) or it was tested that the
bug was reproducible with the old version but not with the new version.

> Should it be closed after being marked "unreproducible"
> for some time maybe?

The bug is currently closed. So there's nothing to be done.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#927877: unbound: "Warning: query response not set" with dig, i.e. QR bit not set in the response

[Michael Tokarev]

19.04.2022 11:51, Vincent Lefevre wrote:
..

Since there is no way to know whether there was any fix (or even
any change that would make the issue disappear as a side effect),
let's rather tag the bug as unreproducible.


Hi Vincent!

Out of curiocity, what do you expect this bug staying like this
to give us?  Even you, as you report, were seeing the problem for
only 20 minutes after which it disappeared, and it was quite some
time ago, with a log has changed since that.

I for one don't know what a maintainer has to do with this bug.

In my work I tend to reduce the number of bugs open to some number
which is possible to maintain. When the same bug which I know
I have nothing to do is included in every next list in my to-do
queue, it becomes annoying and with time I tend to look there
less and less, so new bugs gets less chance to be dealt with.

This is just my personal thing, I can't say for others...

But anyway, how do you think it will be useful this way?
Should it be closed after being marked "unreproducible"
for some time maybe?

Thanks,

/mjt

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

[Roland Clobus]

Hello list,

On 19/04/2022 09:52, luigi scarso wrote:

Thank you very much for your patch, I will check it this weekend.


Another note:
While preparing for a generic change request for Lua, I found a mail by 
Hans Hagen [1], stating that all cases have been found in luatex. 
Sorting the table (as in my original patch) is also a solution, but my 
proposed patch in lstate.c will fix the root cause.


I would rather fix the root cause.
If you prefer the sorting patch, I'll adapt it to activate only when 
FORCE_SOURCE_DATE=1 and SOURCE_DATE_EPOCH are set.


With kind regards,
Roland Clobus

[1] http://lua-users.org/lists/lua-l/2014-07/msg00564.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009781: ITP: safe-vdash -- the Safe Network - node dashboard

[Jonas Smedegaard]

Needs embedding 6 crates (4 missing, 2 outdated, 1 outdated and broken); 
builds in ~4 minutes; completely untested

After some nudging and poking, the package now builds with most 
dependencies satisfied by crates already packaged in Debian.

Main task now, besides keeping the packaging up-to-date with upstream 
releases, is to package the missing packages.

You can help by testing this draft package (either build it yourself or 
tell if you want access to binary packages I've built unofficially) and 
provide feedback on how well it works for you.

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


 - Jonas

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

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

signature.asc
Description: signature

Bug#1009854: ITS: opusfile

[Debian/GNU]

Source: opusfile
Version: 0.9+20170913-1.1
Severity: important

Dear Maintainer,

I intend to salvage the package "opusfile", for the following reasons:

- "opusfile" currently FTBFS (due to using a very outdated debhelper
  compat) [#965762]
- multiple new upstream releases of "opusfile" have been missed
  - 0.11 (in 2018)
  - 0.12 (in 2020)
  - [#935591, #923031]
- lacking multiarch support [#935590, #899138, #923031]

- no visible packaging activity for 1660 days
  - the last upload by the current maintainer was 2017-10-03
  - there has been a non-NMU, no-source-change upload on 2020-12-17 by
the Reproducible Build teams in the meantime)
  - there are 7 open bug reports, ranging from wishlist to *serious*
since 2017-11-15
not a single bug report has seen *any* reaction from the current
maintainer.

I'm aware that the maintainer of "opusfile" does not usually want to make
packaging changes without specific reasons, but I don't think that this
allows for completely ignoring open bug-reports of severity SERIOUS for
more than 1½ year.

I tried contacting the current maintainer multiple times about a year
ago, but the *only* answer I ever got was "I've been afk for a bit, but
I'm catching up on things again now".

I'm happy with co-maintaining the package (although my stance at
maintenance is definitely more aggressive with regard to updating to the
latest and greatest source format, dh-compat and the like).
I would more than welcome maintenance of the package under the
multimedia-team umbrella.


it would be great to hear something from the current maintainer of
"opusfile".

cheers

Bug#1009853: RM: transifex-client [all] -- RoM

[Hans-Christoph Steiner]

Package: ftp.debian.org
Severity: normal

Please remove transifex-client source and binary packages from unstable and 
testing.  Upstream has sunsetted it and no longer supports it.


* 
https://community.transifex.com/t/postponing-api-2-0-2-5-and-transifex-client-sunset-date/2759

* https://github.com/transifex/transifex-client

Upstream says this is the replacement:
https://github.com/transifex/cli