Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/5/22 13:14, Mattia Rizzolo wrote:

On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote:

I suppose I'll see how it goes in the coming few days.

So it's not crashing but it's being unbearably slow in gmail, to the
point that I just wasn't able to type a mail there, while throwing one
CPU core to 100%.
Also it was kind go generally slow in several other sites, compared to
v93.  Always compared to v93, it takes far longer (and by far much much
more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
all the time, trusting the browser to reopen them where I left when I
close it).

I didn't mesure anything and I don't have any numbers to share, but
that's what I see.


At least, it looks like it has not been leaking as much memory as v93
was (that in this regard was buggier than v90).



If you want to try with chromium 97; it now builds as an official build, 
so those DCHECKs shouldn't even be compiled in. It also supports wayland 
automatically, in case that's related to your slowdowns.


https://salsa.debian.org/dilinger/chromium/-/tree/v97

Bug#1002132: A patch from upstream

[handsome_feng]

Hi,


I saw this bug older than 7 days and no maintainer activity, but it
fixed upstream: 

https://github.com/canonical/lightdm/commit/270b3bfcf84939ab2d71db3f3470cffd36816852

So I prepared a debdiff,  and I hope this will help.


Cheers,

handsome_feng
diff -Nru lightdm-1.26.0/debian/changelog lightdm-1.26.0/debian/changelog
--- lightdm-1.26.0/debian/changelog 2020-02-04 03:13:13.0 +0800
+++ lightdm-1.26.0/debian/changelog 2022-01-06 14:49:08.0 +0800
@@ -1,3 +1,12 @@
+lightdm (1.26.0-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches:
+- 10_fix-build-glibc-2.33 added, fix FTBFS with glibc 2.33.
+  (Closes: #1002132)
+
+ -- handsome_feng   Thu, 06 Jan 2022 14:49:08 +0800
+
 lightdm (1.26.0-7) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru lightdm-1.26.0/debian/patches/10_fix-build-glibc-2.33.patch 
lightdm-1.26.0/debian/patches/10_fix-build-glibc-2.33.patch
--- lightdm-1.26.0/debian/patches/10_fix-build-glibc-2.33.patch 1970-01-01 
08:00:00.0 +0800
+++ lightdm-1.26.0/debian/patches/10_fix-build-glibc-2.33.patch 2022-01-06 
14:49:08.0 +0800
@@ -0,0 +1,22 @@
+--- a/tests/src/libsystem.c
 b/tests/src/libsystem.c
+@@ -329,6 +329,10 @@ stat64 (const char *path, struct stat64
+ return _stat64 (new_path, buf);
+ }
+ 
++// glibc 2.33 and newer does not declare these functions in a header file
++#pragma GCC diagnostic push
++#pragma GCC diagnostic ignored "-Wmissing-prototypes"
++
+ int
+ __xstat (int version, const char *path, struct stat *buf)
+ {
+@@ -365,6 +369,8 @@ __fxstatat64(int ver, int dirfd, const c
+ return ___fxstatat64 (ver, dirfd, new_path, buf, flags);
+ }
+ 
++#pragma GCC diagnostic pop
++
+ DIR *
+ opendir (const char *name)
+ {
diff -Nru lightdm-1.26.0/debian/patches/series 
lightdm-1.26.0/debian/patches/series
--- lightdm-1.26.0/debian/patches/series2020-02-04 03:13:13.0 
+0800
+++ lightdm-1.26.0/debian/patches/series2022-01-06 14:49:08.0 
+0800
@@ -5,3 +5,4 @@
 06_change-user-dirs.patch
 08_reset-SIGPIPE-before-exec.patch
 09_hide_systemd_nologin.patch
+10_fix-build-glibc-2.33.patch

Bug#1003201: libc6: Upgrading to libc 2.33-1 causes lots of strange crashes

[Rich Ercolani]

Package: libc6
Version: 2.33-1
Severity: important
X-Debbugs-Cc: rincebr...@gmail.com

Dear Maintainer,

(I marked this as serious because it's "just" ppc64, but the system is 
permaneantly unusable if this upgrade is installed.)

I booted my ppc64 VM in qemu 6.1, apt update, apt upgrade, and 20-30 packages 
in, it died horribly
with Python3 packages erroring out with "Cannot get content of [whatever 
package]".

Trying to log into a shell over ssh or at a tty after this happens dies with an 
error that flashes fast, but
but seems to be "free(): invalid pointer"

Random applications will now just crash out, in addition to the obvious. (I'm 
writing this from a session
spawned before the upgrade, which can still spawn children successfully until I 
log out.)

If I reboot after upgrading, all services fail to start on boot, and it never 
spawns a login prompt or rescue
prompt, it just sits forever on a list of failed service starts.

Anything that would be helpful to debug this? I have a snapshot of the VM 
before this began, so I can
just roll it back and repeat the exercise.

- Rich

-- System Information:
Debian Release: bookworm/sid
Architecture: powerpc64 (ppc64)

Kernel: Linux 5.15.0-2-powerpc64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1003200: python3-lexicon: please package 3.8.5 or newer

[Nicholas D Steeves]

Source: python3-lexicon
Version: 3.3.17-1
Severity: normal
X-Debbugs-Cc: team+pyt...@tracker.debian.org

Hi Ana!

I've informally started work packaging a Certbot plugin for Dynu (DDNS
provider); however, Lexicon 3.3.17 doesn't support Dynu.  I wasn't
able to discover what version introduced support for Dynu by verifying
the upstream changelog, so I've selected the current upstream version
which I've informally supports Dynu--with a quick silversearcher-ag
run.

Unfortunately the update doesn't appear to be trivial.  Python3-bs4
appears as a new requirement, and if I understand the build output
correctly Oracle's Oci is now also needed (or the test needs to be
disabled).  I've CCed the DPT in case other people are interested in
working on this, or any of the other potentially NEW deps; they may
only be necessary for unit tests and since pyproject.toml indicates
they're optional I suspect they're optional runtime deps.

Happy new year!
Nicholas

Bug#992313: hexedit: please add non-superficial autopkgtest

[Paul Wise]

Control: tags -1 - moreinfo

On Fri, 2021-10-29 at 23:08 -0300, Eriberto Mota wrote:

> To:   992...@bugs.debian.org

Please CC submitters when you have questions/comments they should see,
I only saw your message by coincidence when looking at the bug.

> Unfortunately, your script ends with
> 'pipetty: can't allocate a pseudo-terminal: No such file or directory'.

I don't get this on the machine where I tested the script.

It sounds like your test environment doesn't have /dev/pts/ mounted?

> If possible, to create an empty file in Bash, use '> file' instead of
> 'touch file'.

I've adopted that. The script also had some other issues that I fixed;
it was not compatible with dash printf (which doesn't support \xNN),
included unwanted LF bytes and also neglected to truncate the file at
the right place after writing the result string.

Please include this script instead:

   #!/bin/sh
   set -e
   rm -f nonempty empty result
   echo -n nonempty > nonempty
   echo -n > empty
   echo -n result > result
   for f in nonempty empty ; do
 echo "Editing $f in hexedit"
 printf "$f"'\n\tresult\33ty\30y' |
 pipetty hexedit 2>&1 |
 ansi2txt |
 tr '\r' '\n'
   done
   head -vn-0 nonempty empty result ; echo
   for f in nonempty empty ; do
 cmp "$f" result
   done

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1001685: mailman: CVE-2021-44227 and updated fix for CVE-2021-42097

[Salvatore Bonaccorso]

Control: forwarded -1 https://bugs.launchpad.net/mailman/+bug/1954694

Hi Thomas,

On Tue, Dec 14, 2021 at 09:40:44PM +0100, Salvatore Bonaccorso wrote:
> Hi Thomas,
> 
> On Tue, Dec 14, 2021 at 09:13:02PM +0100, Salvatore Bonaccorso wrote:
> > Control: tags -1 + upstream security
> > 
> > Hi Thomas,
> > 
> > On Tue, Dec 14, 2021 at 11:23:53AM +0100, Thomas Arendsen Hein wrote:
> > > Package: mailman
> > > Version: 1:2.1.29-1+deb10u2
> > > Severity: important
> > > 
> > > Hi!
> > > 
> > > Mailman 2.1.38 has been released to fix CVE-2021-44227 (a list
> > > member or moderator can get a CSRF token and craft an admin request),
> > > and 2.1.39 has been released to fix a regression in above fix and
> > > to update the fix for CVE-2021-42097.
> > > 
> > > https://mail.python.org/archives/list/mailman-annou...@python.org/thread/D54X2LXETPMVP5KZNM2WP6Z6UOPJXSVD/
> > > Can you update the packages for Debian buster (and ideally for
> > > stretch LTS, too)?
> > 
> > See: https://bugs.debian.org/1001556 so it's pending for the next
> > buster point release.
> > 
> > > In bug report #1000367 an updated package 1:2.1.29-1+deb10u3 has
> > > been created, but it is not yet available via buster-security.
> > > That's why I have marked this ticket with "1:2.1.29-1+deb10u2"
> > > above.
> > 
> > Samewise: https://bugs.debian.org/1000386 
> > 
> > So in summary, all the CVE fixes are already pending for the next
> > point release for buster.
> 
> Btw, that said, I would appreciate if the proposed packages get some
> additional testing exposure.
> 
> I will try to provide in the next days as well a followup to the
> additional regression fix and improvement bugfix mentioned from the
> 2.1.39 release.

Friendly ping back on this: there are as said pending versions for the
next point release in proposed-updates. Would you be able to test
those so we can make sure the packages for buster have seen some real
situation testing?

The above regression fix is not yet included, would you be able to
test the followup as well?

Regards,
Salvatore

Bug#1003027: roundcube: XSS vulnerability via HTML messages with malicious CSS content

[Salvatore Bonaccorso]

Control: retitle -1 roundcube: CVE-2021-46144: XSS vulnerability via HTML 
messages with malicious CSS content

Hi Guilhem,

On Wed, Jan 05, 2022 at 09:19:49PM +0100, Guilhem Moulin wrote:
> Hi carnil,
> 
> On Wed, 05 Jan 2022 at 20:49:35 +0100, Salvatore Bonaccorso wrote:
> > FTR, have not yet heard back on the assignment. We can wait a bit
> > longer, but just wanted to say we do not necessarily need to block on
> > the missing assignment if we want to release the DSA earlier. The
> > issue is not that urgent though I think that we could not wait a bit
> > longer.
> 
> Thanks for the follow-up!  I have the debdiff ready (modulo d/changelog)
> but I agree with your assessment that the severity is not serious
> enough to warrant rushing the DSA through.  Let's wait a bit longer then :-)

CVE-2021-46144 has been assigned for the roundcube issue.

Regards,
Salvatore

Bug#1003199: dh-raku: dh_raku_install POD

[gregor herrmann]

Package: dh-raku
Version: 0.5
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The POD in dh_raku_install is a nice mixture of copypastes from both
dh_raku_build(1) (NAME and SYNOPSIS) and dh_raku_test(1)
(DESCRIPTION) but says nothing about dh_raku_install :)


Cheers,
gregor


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dh-raku depends on:
ii  debhelper  13.6
ii  libdebian-source-perl  0.116

dh-raku recommends no packages.

dh-raku suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmHWXw9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbTuQ//eSjXjiMTC9MbtyYvExU/MPaZx0GjLOXO4N0HnysiEHlcb0KJmeS0A1iF
rJShYcVl2mCRUWFYu7hBoov1mRYYVXxzGYA4VQ0LYvvoM1WAbc1zlbYwsCEbA3kD
kiKkYqOR/yEKG/zpDrtWlVBkT9ZVB4gHxlzwFYxHAREOYhDhbThZmT9/wxtUhUCS
76pwzPkm2vNk+q/dfQDmQ64wN+NLY30gkeuKROL1S6+pt1AHLhZKi7i86ZvBjdMh
3IxzfLTMZxFLVn+w+caSm5uQz1u5TamsjtZ3hY2ue8GddCXSK1CbGNEM8fJrrD+1
lcV2L6+l9Ktvh/yFrhJDK9zM3ocdCe/5A+h0Ntg1RM9vcH0ZqJrYXM/sKqJ+EhHt
HVS6AdJlNTJWJfYojOfS681+6vxYjfXld/xxc4DMEDIduVdslvWN5EXWuO0lN+TS
WQsa3HJYXUlsljt6IyAqElP/VwnbBiOpiAstVtOpv+fc6E9PPkqrQ3vSNQyOdpa7
fvkqh9TrSITx11TQVnr3OrClNGfcBJaJok/qkPe5SIkd3zSdnOIvh9E1x7P+b1oT
tH/hjSj13x+o/G5YyFGzdusuvS8ljOY+QISTWmYVdRz79v5S88LYkk8cOiXcPhmF
CAlbeEMinuAC1/puZhUgNp/QqOkdrSGfKYvWdlEjqIDdWT59Nj4=
=JSWZ
-END PGP SIGNATURE-

Bug#1001730: New contributor would like to learn and help with this bug

[rachit bhojani cs]

Heyy I am rachit
I intend to be a new contributor at debian and know a little bit about
python , i would love to help fix this bug and learn more about it, but I
will need some guidance as to fix this bug

Bug#1003198: python-arrow: Update Homepage url

[Emmanuel Arias]

Source: python-arrow
Version: 1.2.1-1
Severity: wishlist
X-Debbugs-Cc: eam...@yaerobi.com

Dear Maintainer,

Please consider update Homepage url. According to the setup.py file the
homepage should be: `https://arrow.readthedocs.io` instead of 
`https://crsmithdev.com/arrow/`.

Thanks!

Cheers
Emmanuel

Bug#1003197: Acknowledgement (ITP: libwebrtc-owt -- Provides real time voice and video processing functionality to enable the implementation of PeerConnection/MediaStream.)

[汤孟]

Reference link for previous discussion:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003102

Bug#1003102: Info received (Bug#1003102: ITP: webrtc -- WebRTC provides real time voice and video processing functionality to enable the implementation of PeerConnection/MediaStream.)

[汤孟]

You can follow progress on this Bug here:
1003197: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003197

Bug#1003197: ITP: libwebrtc-owt -- Provides real time voice and video processing functionality to enable the implementation of PeerConnection/MediaStream.

[tangmeng]

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

* Package name: libwebrtc-owt
  Version : 5.0
  Upstream Author : jianjunz 
* URL : https://github.com/open-webrtc-toolkit/owt-deps-webrtc
* License : BSD, etc.
  Programming Lang: C, C++, Java, Python, etc.
  Description : Provides real time voice and video processing functionality 
to enable the implementation of PeerConnection/MediaStream.

 libwebrtc-owt contains the upstream webrtc stack code, with updates for Open
 WebRTC Toolkit.

 WebRTC is a free, open software project** that provides browsers and mobile
 applications with Real-Time Communications (RTC) capabilities via simple APIs.
 The WebRTC components have been optimized to best serve this purpose.

 WebRTC provides a library of real-time communication (RTC) functions for
 browsers and mobile applications through simple APIs.

Bug#1003196: python3-mailman-hyperkitty: postinst should run django-admin migrate

[Peter Chubb]

Package: python3-mailman-hyperkitty
Version: 1.1.0-10
Severity: normal

Dear Maintainer,

After a routine apt-upgrade, archives showed 'server error' instead of an 
archive.

THe issue was that the database schema needed update.

I believe the postinst script should run:
  sudo -u www-data django-admin migrate --pythonpath /usr/share/mailman3-web 
--settings settings 
or ask the user to.

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

Kernel: Linux 5.10.0-8-cloud-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 python3-mailman-hyperkitty depends on:
ii  debconf [debconf-2.0]   1.5.79
ii  mailman33.3.3-1
ii  python3 3.9.8-1
ii  python3-pkg-resources   59.6.0-1
ii  python3-requests2.25.1+dfsg-2
ii  python3-zope.interface  5.4.0-1+b1
ii  ucf 3.0043

Versions of packages python3-mailman-hyperkitty recommends:
ii  mailman3-web   0+20200530-2
ii  python3-django-hyperkitty  1.3.5-1

python3-mailman-hyperkitty suggests no packages.

-- debconf information:
  python3-mailman-hyperkitty/no_archiverkey:

Bug#1003154: sudo 1.9.8p2-1 breaks sshuttle

[Hilko Bengen]

I have dug around a bit in the manpages:

As for the error itself:

,
| NAME
|  setsid - creates a session and sets the process group ID
| 
| [...]
| 
| ERRORS
| 
|  EPERM
|   The process group  ID of any process equals  the PID of
|   the  calling process.   Thus,  in particular,  setsid()
|   fails if the calling process is already a process group
|   leader.
`

I suppose that this is exactly the case because of use_pty.

,
| NAME
|  sudoers — default sudo security policy plugin
| 
| [...]
| 
|  use_pty   If set, and sudo is running in a terminal, the command
|will be run in a pseudo-terminal (even if no I/O log‐
|ging is being done).  If the sudo process is not at‐
|tached to a terminal, use_pty has no effect.
`

So is there a way to prevent ssh from allocating a terminal? Turns out
there is:

,
| NAME
|  ssh — OpenSSH remote login client
| 
| [...]
| 
|  -T  Disable pseudo-terminal allocation.
`

I suppose that patching sshuttle to call ssh with that parameter might
work.

Cheers,
-Hilko

Bug#1003195: enlightenment: E crashes after coming back from a different VTY

[Robert Waldner]

Package: enlightenment
Version: 0.24.2-8
Severity: normal

Dear Maintainer,

after upgrading from Debian 10 to 11.2, I can no longer seamlessly switch
to different VTYs/Window Managers and then back to Enlightenment.

F'rex, switching to VTY1 (text console) works as expected, but after
switching back to Enlightenment on VTY7 E crashes.
Same after switching back to VTY7 from VTY8 (where a different user runs
XFCE4).

_Most_ of the time I get a black screen with red writing, citing "Guru
meditation #02248813.0011", and can recover my Enlightenment session
(and open programs) via pressing F1. At other times I get a non-responsive
screen where I can see the title bars of all windows but clicking anywhere
with the mouse is non-responsive - this I can usually recover via
restarting Enlightenment (which I've bound to ctrl-alt-x for this purpose),
but sometines all I can do is kill all Enlightenment processes from, say,
VTY1 and logging in again from lightdm.

Backtrace log / ~/.e-crashdump.txt from when I get the back screen/red
writing situation:
---
Thread 1 (Thread 0x7f287f74e740 (LWP 5319)):
#0  0x7f287d1c6b8d in pause () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  
No locals.
#2  0x7f286afbed2b in ?? ()
   from /usr/lib/enlightenment/modules/comp/linux-gnu-x86_64-0.17.3/module.so
No symbol table info available.
#3  0x7f286afbef4b in ?? ()
   from /usr/lib/enlightenment/modules/comp/linux-gnu-x86_64-0.17.3/module.so
No symbol table info available.
#4  0x7f287f031657 in ?? () from /usr/lib/x86_64-linux-gnu/libecore.so.1
No symbol table info available.
#5  0x7f287f0359d9 in ?? () from /usr/lib/x86_64-linux-gnu/libecore.so.1
No symbol table info available.
#6  0x7f287f035f17 in ecore_main_loop_begin ()
   from /usr/lib/x86_64-linux-gnu/libecore.so.1
No symbol table info available.
#7  0x00434ac0 in main ()
No symbol table info available.
Detaching from program: /usr/bin/enlightenment, process 5319
---

VTY-switching in this manner has worked well for me for over a decade
now, and I'm a bit stumped on as to how to debug this.

Thanks for any pointers.

Kind regards,
Robert

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

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

Versions of packages enlightenment depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  enlightenment-data0.24.2-8
ii  libasound21.2.4-1.1
ii  libbluetooth3 5.55-3.1
ii  libc6 2.31-13+deb11u2
ii  libecore-con1 1.25.1-1
ii  libecore-drm2-1   1.25.1-1
ii  libecore-evas11.25.1-1
ii  libecore-file11.25.1-1
ii  libecore-input1   1.25.1-1
ii  libecore-ipc1 1.25.1-1
ii  libecore-wl2-11.25.1-1
ii  libecore-x1   1.25.1-1
ii  libecore1 1.25.1-1
ii  libedje-bin   1.25.1-1
ii  libedje1  1.25.1-1
ii  libeet1   1.25.1-1
ii  libeeze1  1.25.1-1
ii  libefreet-bin 1.25.1-1
ii  libefreet1a   1.25.1-1
ii  libeina1a 1.25.1-1
ii  libeio1   1.25.1-1
ii  libelementary11.25.1-1
ii  libelput1 1.25.1-1
ii  libemile1 1.25.1-1
ii  libemotion1   1.25.1-1
ii  libevas1  1.25.1-1
ii  libevas1-engines-drm  1.25.1-1
ii  libevas1-engines-wayland  1.25.1-1
ii  libevas1-engines-x1.25.1-1
ii  libpam0g  1.4.0-9+deb11u1
ii  libpulse0 14.2-2
ii  libuuid1  2.36.1-8
ii  libwayland-client01.18.0-2~exp1.1
ii  libwayland-server01.18.0-2~exp1.1
ii  libxkbcommon0  

Bug#994728: libtirpc3:amd64: rpcbind stops replying to subnet broadcast CALLIT after one stray UDP datagram

[Martin Dorey]

On Sun, 19 Sep 2021 19:11:26 -0700 Martin Dorey 
wrote:
> Package: libtirpc3
> Version: 1.1.4-0.4

My production occurrence was always on Stretch, but I'd thought that the
patch might be more easily accepted against a less stale branch.  It
applies to Stretch too, where I've just put it into production.

> sendmsg(7, {msg_name={sa_family=AF_INET, sin_port=htons(800),
sin_addr=inet_addr("172.27.5.162")}, msg_namelen=16,
msg_iov=[{iov_base="\0\2:\270\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2\371\0\0\0\4"...,
iov_len=36}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_IP,
cmsg_type=IP_PKTINFO, cmsg_data={ipi_ifindex=0,
ipi_spec_dst=inet_addr("127.0.0.1"), ipi_addr=inet_addr("127.0.0.1")}}],
msg_controllen=32, msg_flags=0}, 0) = -1 EINVAL (Invalid argument)

I don't, today, see EINVAL being returned on Stretch, though I did before.
While successfully sent, the response doesn't get to its intended target
for me today, perhaps ending up at 127.0.0.1 instead of the intended
172.27.5.162 (to use the IP address from the above output).

> Once an rpcbind process has got into this state, it doesn't
> recover without being restarted.

I found, today, that sending Stretch rpcbind the poison pill from a
different machine caused it to recover.  I've only seen the problem
exhibited, then, when the poison has been sent locally.

> First enable remote call support.

That was first disabled in Buster, so isn't needed to reproduce the problem
on Stretch.

> rpcinfo -b 10 4

For my Stretch reproduction today, I have to make this call from a
different computer to the one on which rpcbind is running to see the
problem.  Sending a unicast request, like rpcbind -T udp sirius 10 4,
didn't suffer from the problem for me, at least not today, on Stretch.

Bug#1003194: Inconsistencies between "make bindeb-pkg" and official Debian kernels

[Trent W. Buck]

Package: debian-kernel-handbook
Version: 1.0.19
Severity: normal

[Initially filed against debian-kernel-handbook because while the
problem is in src:linux, it's not strictly a problem with src:linux's
official binary packages.]

Debian Live images with custom kernels need some workarounds, because
"make bindeb-pkg" is inconsistent with official Debian kernels.
I would like to remove both the inconsistencies and my workarounds.

Attached are two scripts, one using stock kernel, one using custom
kernel built with "make bindeb-pkg" and then hosted on a PPA.
Removing either workaround breaks the "download" lines.

A few minor issues are annoying me:


  1. /vmlinuz and /initrd.img are not created.

 The problem appears to be inconsistency between these two scripts:

 a. official images use this, which calls linux-update-symlinks (and 
Depends: linux-base)

 
https://sources.debian.org/src/linux/5.14.9-2%7Ebpo11+1/debian/templates/image.postinst.in/#L17

 b. "make bindeb-pkg" use this, which does not

 
https://sources.debian.org/src/linux/5.14.9-2~bpo11+1/scripts/package/builddeb/#L186-L209

 Is it reasonable to make builddeb call linux-update-symlinks and Depends: 
linux-base?
 This seems reasonable to me.


  2. /boot/initrd.img- is not created.

 I think this is because there is no Depends, so
 (if everything happens in a single "apt install"),
 /var/lib/dpkg/info/linux-image-X.postinst runs before
 /etc/kernel/postinst.d/initramfs-tools exists.

 This does not happen with stock kernels, which I think use this:

 
https://sources.debian.org/src/linux/5.14.9-2%7Ebpo11+1/debian/templates/control.image.in/#L3-L5

 Is it reasonable to make builddeb add equivalent 
Depends/Recommends/Suggests?

 It would need to NOT mention initrd when build with CONFIG_MODULES=n, but
 builddeb already knows when this is the case.

 If build with (for example) "make localyesconfig", then even if 
CONFIG_MODULES=y,
 it should probably only Recommends or Suggests initramfs-tools (for 
amd64-microcode).

 This gets a little messy!


  3. I'd like a Provides or metapackage equivalent to "linux-image-generic", so
 with a PPA, I can say --include=linux-image-inmate and have it always pick 
the latest available.
 Currently with --include=linux-image-5.14.9inmate, I have to keep updating 
the --include line.

 The "inmate" comes from CONFIG_LOCALVERSION=inmate, so
 I guess builddeb would check if that was set, and if so, add

 Provides: linux-image-${CONFIG_LOCALVERSION}

 Is this reasonable?
 I can't see any downside, and it sounds easy.
 If I can get my head around builddeb, I'll try to submit a patch for this.


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/8 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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
#!/bin/bash
cmd=(
mmdebstrap
bullseye
live/filesystem.squashfs
--customize-hook='download /vmlinuz ./live/vmlinuz'
--customize-hook='download /initrd.img ./live/initrd.img'
--include=live-boot
--include=linux-image-generic
https://deb.debian.org/debian
)

mkdir live
"${cmd[@]}"
ls -hlR live
#!/bin/bash
cmd=(
mmdebstrap
bullseye
live/filesystem.squashfs
# Work around lack of linux-update-symlinks
--customize-hook='chroot $1 linux-update-symlinks install 5.14.9inmate 
/boot/vmlinuz-5.14.9inmate'
# Work around lack of Depends: initramfs-tools
--customize-hook='chroot $1 dpkg-reconfigure linux-image-5.14.9inmate'
--customize-hook='download /vmlinuz ./live/vmlinuz'
--customize-hook='download /initrd.img ./live/initrd.img'
--include=live-boot
--include=linux-image-5.14.9inmate
https://deb.debian.org/debian
'deb [signed-by=/home/twb/PrisonPC-archive-pubkey.asc] 
https://apt.cyber.com.au/PrisonPC bullseye kernel-demo'
)

mkdir live
"${cmd[@]}"
ls -hlR live

Bug#1003158: [pkg-apparmor] Bug#1003158: apparmor: tunables/home seems to have wrong order of variables

[Karsten Hilbert]

Am Wed, Jan 05, 2022 at 09:13:12PM +0100 schrieb Christian Boltz:

> AppArmor rules are in most cases declarative so that the order doesn't
> matter (exception: before you can extend a variable with "+=" you have
> to initialize it with "=").
>
> The current definition is technically not a bug, "just" confusing.

I agree it is not *technically* a bug.

> However, I agree that defining @{HOMEDIRS} before using it would make
> sense to make it less confusing for human parsers ;-)

Nevertheless, intent-wise it is because it also makes @{HOME}
not include anything from /home/ because @{HOMEDIRS} is
undefined when @{HOME} is set up ?

> Since the change is more cosmetic,

Unless I misunderstand apparmor profile logic it is not
purely cosmetic. It excludes "/home/*/" from @{HOME}.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#1003154: sudo 1.9.8p2-1 breaks sshuttle

[H. S. Teoh]

On Wed, Jan 05, 2022 at 08:35:55PM +0100, Marc Haber wrote:
[...]
> The changes we made that might cause this are mainly setting use_pty
> in /etc/sudoers and some changes in pam configuration. Can you try
> using sudo 1.9.8 with the sudoers file and and /etc/pam.d snapshot
> from sudo 1.9.5?
[...]

Some further digging turned up this:

https://github.com/sshuttle/sshuttle/pull/668

Looks like sshuttle is incompatible with use_pty.  Upstream has a patch
that issues a more helpful error message in this case, but that version
hasn't made it into Debian yet.  Perhaps this bug should be reassigned
to sshuttle?


T

-- 
Why waste time reinventing the wheel, when you could be reinventing the engine? 
-- Damian Conway

Bug#930306: New maintainer for teensy-loader-cli

[Geert Stappers]

control -1 pending
thanks


Hi,

Teensy-loader-cli will have a new uploader:  Me.
And for the better bus-factor will it be done
under the umbrella of the Debian Electronics Team.

The teensy-loader-cli.git.tar.xz fetch from 
https://alioth-archive.debian.org/git/collab-maint/
has been handled as documented at 
https://wiki.debian.org/Salsa/AliothMigration#By_hand
so now there is https://salsa.debian.org/electronics-team/teensy-loader-cli

Actual new upload will happen when I have seen version 2.2 been working.
Current version is 2.1 and have never used t.l.c. before.  :-/

 
Groeten
Geert Stappers
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#1003193: Switch maintainer?

[Dirk Eddelbuettel]

Package: tiledb
Severity: normal

Hi Adam,

Would you be ok with me more formally adopting the package as maintainer?

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1003154: sudo 1.9.8p2-1 breaks sshuttle

[H. S. Teoh]

On Wed, Jan 05, 2022 at 08:35:55PM +0100, Marc Haber wrote:
[...]
> The changes we made that might cause this are mainly setting use_pty
> in /etc/sudoers and some changes in pam configuration. Can you try
> using sudo 1.9.8 with the sudoers file and and /etc/pam.d snapshot
> from sudo 1.9.5?
[...]

I did some digging, and discovered that setting use_pty is indeed what
makes the difference. Installing sudo 1.9.8 and manually commenting out
use_pty fixes the problem.

I've no idea why, though.  Maybe sshuttle needs to pass some extra
options to sudo in order to work around this?


T

-- 
In theory, there is no difference between theory and practice.

Bug#1002986: libguestfs-tools: Depends on guestfs-tools that is not in the archive

[Joseph Carter]

On Sun, 02 Jan 2022 23:28:32 +0100 Hilko Bengen  wrote:
> * Laurent Bigonville:
> 
> > It looks like libguestfs-tools version 1:1.46.2-1 in depending on
> > guestfs-tools that is not in the archive making the package uninstalable
> >
> > guestfs-tools is currently stuck in the new queue
> 
> Right. Let's  just wait. (Or do you know of a way to speed this up?)

Cold beverages of the FTP maintainer's choice?  Hopefully it'll be in the 
archive soon, but looking at https://ftp-master.debian.org/new.html there are 
packages that have been sitting in NEW for almost a year now. It might be a 
case of squeaky wheels—or that some of those packages having a hold-up for a 
particular reason. Probably a bit of both.

Joseph

Bug#1003153: [pkg-apparmor] Bug#1003153: /etc/apparmor.d/usr.sbin.apache2: Apache profile complains when ss -tnlp is run

[Craig Small]

On 2022-01-05 at 12:24, debian-b...@cboltz.de wrote:
> so all profiles that include abstractions/base can be ptraced.
>
> However, what you see happens in the HANDLING_UNTRUSTED_INPUT hat (this
> hat is used when Apache processes are idle) - and Apache hats typically
> don't include abstractions/base.
Ah ha, that's what doing it. Thanks for the explanation.

> (Nevertheless, the apache hats should allow to be ptraced. I'll leave
> that to the maintainer of the Apache profile in Debian - and would love
> to see the fix upstreamed.)
I suppose all of the hats should have some line for this. I suspect it
is possible to ptrace apache when in the non-idle hat; my webserver is
just not very busy.

 - Craig

Bug#1002296: ITP: dh-haskell -- Debhelper build system for cabal-based Haskell packages

[Clint Adams]

On Tue, Dec 21, 2021 at 12:57:13PM -0800, Felix Lechner wrote:
> Version 0.4 was dropped from unstable on 2018-11-04 at the author's
> request in #912000. While the software seemed not useful then, the dh
> sequencer is now the dominant build system. [1]
> 
> This version is a simple, but complete rewrite based on
> /usr/share/cdbs/1/class/hlibrary.mk. It was tested with a Haskell
> executable that is not in the archive, but not yet with any libraries
> or documentation. Further adaptation may be required.
> 
> Going forward, I would like to maintain the software, potentially
> jointly, as a prospective member of the Haskell Group!
> 
> [1] https://trends.debian.net/#build-systems

Thanks for doing this before cdbs bitrot leaves no other alternative.

Bug#1003158: [pkg-apparmor] Bug#1003158: apparmor: tunables/home seems to have wrong order of variables

[Christian Boltz]

Hello,

AppArmor rules are in most cases declarative so that the order doesn't 
matter (exception: before you can extend a variable with "+=" you have 
to initialize it with "=").

The current definition is technically not a bug, "just" confusing.
However, I agree that defining @{HOMEDIRS} before using it would make 
sense to make it less confusing for human parsers ;-)

I submitted a patch for re-ordering the variable definition upstream:
https://gitlab.com/apparmor/apparmor/-/merge_requests/820

Since the change is more cosmetic, it will probably only be included in 
AppArmor 3.1 and newer. I don't expect to get it backported to the 3.0 
or 2.x branches.


Regards,

Christian Boltz
-- 
> Using the internet since 28.8kbit. Yes, I'm 'old'.
My first modem was 300 bits/sec, you young whipper snapper!  ;-)
[> Yamaban and James Knott in opensuse-factory]


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

Bug#1003130: ITP: luit in 2013.

[Thomas Dickey]

On Wed, Jan 05, 2022 at 03:26:13PM +0200, Timo Aaltonen wrote:
> On 4.1.2022 20.48, Thomas Dickey wrote:
> > On Tue, Jan 04, 2022 at 11:46:03AM -0500, Thomas Dickey wrote:
> > > Package: x11-utils
> > > Version: 7.7+5
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > * x11-utils copy of luit was superseded by luit 2.0 in 2013.
> > > * mentioned this several times to developers in X Strike Force
> > > * developers did not reply to those comments
> > > * developers could have suggested a way to address the issue
> > >
> > > As a solution to that, I propose to create a new package "luit2",
> > 
> > Actually, the package should be named "luit", but the executable "luit2".
> > 
> 
> Hi, so are you going to maintain it?

sure - if I have a sponsor for the uploads.

Keep in mind that I'm the upstream developer for several programs,
but have been involved with Debian mainly by interaction with the
developers who package my programs, e.g., ncurses, xterm, lynx,
vile, dialog, vttest, cproto, diffstat, libcdk5 (there's another
half-dozen).

I recently was reminded that byacc wasn't being kept up to date,
and decided to remedy that.  luit's one of five programs that weren't
up to date -- in Debian.  A reminder to Santiago Vila got dialog
updated, and someone offered to work on tapecalc.  byacc and luit
are what I've been working on this week - see

https://mentors.debian.net/package/byacc/
https://mentors.debian.net/package/luit/
https://mentors.debian.net/package/x11-utils/

(further improvements are contemplated...)
 
> If not, I don't see a point in creating a separate package for it. And I
> could only find a single message about luit from you (feb 15th 2021) on my
> local archive of debian-x messages since 2011..

I've discussed it more than once with other developers (Julien Cristau
and Sven Joachim) over the past ten years, and gotten no response.

I don't recall talking to you before.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1003027: roundcube: XSS vulnerability via HTML messages with malicious CSS content

[Guilhem Moulin]

Hi carnil,

On Wed, 05 Jan 2022 at 20:49:35 +0100, Salvatore Bonaccorso wrote:
> FTR, have not yet heard back on the assignment. We can wait a bit
> longer, but just wanted to say we do not necessarily need to block on
> the missing assignment if we want to release the DSA earlier. The
> issue is not that urgent though I think that we could not wait a bit
> longer.

Thanks for the follow-up!  I have the debdiff ready (modulo d/changelog)
but I agree with your assessment that the severity is not serious
enough to warrant rushing the DSA through.  Let's wait a bit longer then :-)

cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#972741: help2man: version-string too restrictive, needs to allow empty version

[Drew Parsons]

Package: help2man
Version: 1.48.5
Followup-For: Bug #972741

The version-string handling is still too restrictive.

It's strange to assume that if there is no --version argument then
then the help output can't be used at all.  Plenty of programs are in
that situation. help2man's output is still fine.  Let help2man do what
it can do, it won't cause the entire system to crash just because
there's no --version argument.

The specific example I'm looking at right now is qdarkstyle.example
from python3-qdarkstyle.  It's a sample gui program, we're lucky it
provides any help at all.  But "qdarkstyle.example --help" does
generate meaningful output, and help2man could generate a man page
that's useful if it were allowed to. The output needs some further
editing but presents optional arguments clearly enough.  Plenty good
enough for closing lintian no-manual-page warnings.

Bug#1003191: mmdebstrap fails when identifying suite by codename

[Johannes Schauer Marin Rodrigues]

Package: mmdebstrap
Severity: serious
Version: 0.8.2-1

Hi,

Quoting Benjamin Drung (2022-01-05 20:59:37)
> I saw that the autopkgtests for bdebstrap fails for mmdebstrap 0.8.2-1
> on Ubuntu jammy:
> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
> 
> amd64 log:
> https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/b/bdebstrap/20220101_132038_11625@/log.gz
> 
> E: nothing got downloaded
> W: listening on child socket failed: Undefined subroutine
> ::Cover::get_coverage called at /usr/bin/mmdebstrap line 105.
> 
> I haven't investigated further.

this is a problem introduced with 0.8.2 and fixing it properly requires a new
apt release with this commit in it:

https://salsa.debian.org/apt-team/apt/-/commit/c6bd75f906c9c782e739ec99f2983407500811bf

On Debian you can work around this by using 'stable', 'unstable', 'testing'
instead of 'bullseye' or 'sid'.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#907606: fsck takes hours to complete, just due to slow screen output

[Thorsten Glaser]

On Wed, 5 Jan 2022, Loorey wrote:

> information they can always by logs anyway.

It’s not that easy. fsck can become interactive, and then
there’s the point of where to write the logs during root
and /var⚠ fsck and how to promote them to the eventual
/var and this needs coordination between multiple packages
I think anyway…

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1003190: tcpslice: CVE-2021-41043: use-after-free in extract_slice()

[Salvatore Bonaccorso]

Source: tcpslice
Version: 1.3-2
Severity: grave
Tags: security upstream
Forwarded: https://github.com/the-tcpdump-group/tcpslice/issues/11
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for tcpslice.

CVE-2021-41043[0]:
| Use after free in tcpslice triggers AddressSanitizer, no other
| confirmed impact.

The impact is not confirmed to be exploitable TTBOMK so far, but the
severity is choosen as better safe than sorry afterwards. Can you
update tcpslice first in unstable? Possibly ideally directly to 1.5
containing other fixes.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-41043
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41043
[1] https://github.com/the-tcpdump-group/tcpslice/issues/11
[2] 
https://github.com/the-tcpdump-group/tcpslice/commit/030859fce9c77417de657b9bb29c0f78c2d68f4a

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1003189: ITP: fiji -- "batteries-included" distribution of ImageJ2

[Roland Mas]

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

* Package name: fiji
  Version : 2.3.1
  Upstream Author : Laboratory for Optical and Computational Instrumentation at 
the University of Wisconsin-Madison
* URL : https://fiji.sc/
* License : GPL-3 (but plugins may have different licenses)
  Programming Lang: Java
  Description : "batteries-included" distribution of ImageJ2

Fiji is an image processing package — a "batteries-included"
distribution of ImageJ, bundling many plugins which facilitate
scientific image analysis.

I intend to maintain this package under the Debian Science Team
umbrella.

Bug#1003177: mmdebstrap: --dry-run fails with error: cannot read /var/cache/apt/archives/

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Benjamin Drung (2022-01-05 18:02:13)
> mmdebstrap from Debian stable fails to run with --dry-run. Example:
> 
> ```
> $ mmdebstrap -v --dry-run --variant=minbase unstable root.tar
> [...]
> Inst sysvinit-utils (3.01-1 Debian:unstable [amd64])
> Conf sysvinit-utils (3.01-1 Debian:unstable [amd64])
> I: skip extracting packages because of --dry-run
> I: no essential packages -- skipping...
> E: cannot read /var/cache/apt/archives/
> W: listening on child socket failed: 
> I: removing tempdir /tmp/mmdebstrap.e7VYvXTJ31...
> ```
> 
> Running the same command on Debian unstable with mmdebstrap 0.8.2-1
> works, but backporting mmdebstrap >= 0.8 to Debian bullseye fails,
> because mmdebstrap >= 0.8 requires a APT version that is newer than the
> one shipped in bullseye.

yes, backporting is not an option. Luckily, the fix is trivial:

--- /usr/bin/mmdebstrap 2022-01-05 19:47:50.477129738 +
+++ /usr/bin/mmdebstrap.fixed   2022-01-05 19:47:43.277074092 +
@@ -2779,7 +2779,7 @@
 # /var/cache/apt/archives/ might not be empty either because
 # the user used hooks to populate it or because skip options
 # like essential/unlink or check/empty were used.
-{
+if (-e "$options->{root}/var/cache/apt/archives/") {
 my $apt_archives = "/var/cache/apt/archives/";
 opendir my $dh, "$options->{root}/$apt_archives"
   or error "cannot read $apt_archives";

I'll ask the release team to also accept that fix in addition to what I already
proposed in #1003188.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1003027: roundcube: XSS vulnerability via HTML messages with malicious CSS content

[Salvatore Bonaccorso]

Hi Guilhem,

On Mon, Jan 03, 2022 at 10:22:49AM +0100, Salvatore Bonaccorso wrote:
> Hi Guilhem,
> 
> On Mon, Jan 03, 2022 at 09:57:29AM +0100, Guilhem Moulin wrote:
> > Control: notfixed -1 1.5.1+dfsg-1
> > Control: found -1 1.5.1+dfsg-1
> > 
> > Hi Salvatore!
> > 
> > On Mon, 03 Jan 2022 at 09:47:28 +0100, Salvatore Bonaccorso wrote:
> > > On Sun, Jan 02, 2022 at 10:50:25PM +0100, Guilhem Moulin wrote:
> > >> Package: roundcube
> > >> Severity: important
> > >> Tags: security
> > >> Control: found -1 1.3.17+dfsg.1-1~deb10u1
> > >> Control: found -1 1.4.12+dfsg.1-1~deb11u1
> > >> Control: fixed -1 1.5.1+dfsg-1
> > > 
> > > 
> > > 
> > > Is this correct with the 1.5.1+dfsg-1 version? The release notes say
> > > that it is fixed in 1.5.2 upstream. Asking for clarifying the
> > > tracking.
> > 
> > Oops sorry wrong copy-paste, well spotted!  I'll propose uploads for
> > buster- and bullseye-security later today; meanwhile perhaps you or
> > another Security Team member would like to assign a CVE number for this?
> > Then I'll have the proper d/changelog right away :-)
> > 
> > I'm planning to upload 1.5.2+dfsg-1 to sid later today too, but note
> > that it won't enter testing because 1.5 is not fully compatible with PHP
> > 8.1.
> 
> Thank you. I have requested a CVE, will update this bug once/if one is
> assigned.

FTR, have not yet heard back on the assignment. We can wait a bit
longer, but just wanted to say we do not necessarily need to block on
the missing assignment if we want to release the DSA earlier. The
issue is not that urgent though I think that we could not wait a bit
longer.

Regards,
Salvatore

Bug#1003154: sudo 1.9.8p2-1 breaks sshuttle

[Marc Haber]

On Wed, Jan 05, 2022 at 09:17:46AM -0800, H. S. Teoh wrote:
> On Wed, Jan 05, 2022 at 02:25:27PM +0100, Marc Haber wrote:
> [...]
> > On Tue, Jan 04, 2022 at 06:36:52PM -0800, H. S. Teoh wrote:
> > > PermissionError: [Errno 1] Operation not permitted
> > > c : fatal: ['/usr/bin/sudo', '-p', '[local sudo] Password: ', 
> > > '/usr/bin/env', 'PYTHONPATH=/usr/lib/python3/dist-packages', 
> > > '/usr/bin/python3', '/usr/bin/sshuttle', '-v', '--method', 'nft', 
> > > '--firewall'] returned 1
> > 
> > Can you please verify whether this command also fails on the command
> > line, and then reduce the command line so that we can find out whatever
> > the current sudo doesn't like?
> [...]
> 
> The failure appears to be coming from sshuttle itself, with that
> specific combination of arguments.  It's not sudo that's rejecting the
> command per se, but something about the environment it sets up isn't
> working well with sshuttle.  The failure is coming from the os.setsid()
> call inside sshuttle (the lines before the ones you quoted above).
> 
> The previous version of sudo was obviously setting up *something*
> differently, such that this call worked.

The changes we made that might cause this are mainly setting use_pty in
/etc/sudoers and some changes in pam configuration. Can you try using
sudo 1.9.8 with the sudoers file and and /etc/pam.d snapshot from sudo
1.9.5?

Remember to have a root shell open in a different window or the "real"
root password handy when doing such experiments with sudo.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1003188: bullseye-pu: package mmdebstrap/0.7.5-2.2

[Johannes Schauer Marin Rodrigues]

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

[ Reason ]
Currently, when a user happens to have an ASCII armored key in
/etc/apt/trusted.gpg.d, running mmdebstrap without any special options
will not work. See #1003175 for details.

The problem is fixed in unstable and testing, starting with 0.8.0-1.

[ Impact ]
Users will either have to remove an ASCII armored key from their
/etc/apt/trusted.gpg.d or supply keys to mmdebstrap manually. But either
is unlikely to happen because the error message does not give a clue
about the actual cause of the problem.

[ Tests ]
Me and two users checked that the attached debdiff fixed the
problem. If desired, I can also add a test from the upstream project
to the debdiff but that would double its size. Essentially, the change
is already well tested upstream.

[ Risks ]
In the worst case, GPG key autodetection breaks and one has to pass the
keyring material to mmdebstrap manually. This is what users with ASCII
armored keys in /etc/apt/trusted.gpg.d already have to do today without
this patch.

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

[ Changes ]
GPG is called with --show-keys instead of with --list-keys.  The latter
requires "public keyring v4" key material while the former also allows
ASCII armored keys.

[ Other info ]
This is my first upload to a stable release, so stupid mistakes can be
hiding anywhere.

Thanks!

cheers, josch
diff -Nru mmdebstrap-0.7.5/debian/changelog mmdebstrap-0.7.5/debian/changelog
--- mmdebstrap-0.7.5/debian/changelog   2021-05-07 17:30:39.0 +0200
+++ mmdebstrap-0.7.5/debian/changelog   2022-01-05 16:05:13.0 +0100
@@ -1,3 +1,10 @@
+mmdebstrap (0.7.5-2.2+deb11u1) bullseye; urgency=medium
+
+  * Do not error out with ASCII armored keyrings in /etc/apt/trusted.gpg.d
+(closes: #1003175)
+
+ -- Johannes Schauer Marin Rodrigues   Wed, 05 Jan 2022 
16:05:13 +0100
+
 mmdebstrap (0.7.5-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch 
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
--- 
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
1970-01-01 01:00:00.0 +0100
+++ 
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
2022-01-05 16:04:09.0 +0100
@@ -0,0 +1,23 @@
+From 91d8be5f9c204f0ee8d524eb1382934e608a9d43 Mon Sep 17 00:00:00 2001
+From: Johannes Schauer Marin Rodrigues 
+Date: Thu, 26 Aug 2021 07:58:27 +0200
+Subject: [PATCH] Do not use gpg --trust-model=always
+
+ - gpg will not create a trustdb when running with --update-trustdb with
+   --trust-model=always:
+   gpg: no need for a trustdb update with 'always' trust model
+ - subsequent gpg calls will fail because there is no trustdb in GPGHOME
+---
+ mmdebstrap | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/mmdebstrap
 b/mmdebstrap
+@@ -4861,7 +4861,6 @@ sub main() {
+ '--ignore-time-conflict', '--no-options',
+ '--no-default-keyring',   '--homedir',
+ $gpghome, '--no-auto-check-trustdb',
+-'--trust-model',  'always'
+ );
+ my ($ret, $message);
+ {
diff -Nru 
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
 
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
--- 
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
1970-01-01 01:00:00.0 +0100
+++ 
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
2022-01-05 16:05:13.0 +0100
@@ -0,0 +1,75 @@
+From ccd4b5c163d322045c92f734f43bb5e1945fa774 Mon Sep 17 00:00:00 2001
+From: Konstantin Demin 
+Date: Thu, 15 Apr 2021 03:00:39 +0300
+Subject: [PATCH] gpg: handle ASCII-armored keyrings as well
+
+gpg command "--list-keys" requires input files to be passed with
+option "--keyring" and each file must match type "public keyring v4"
+while gpg command "--show-keys" doesn't require extra options and
+handles also ASCII-armored public keyrings as well.
+
+Signed-off-by: Konstantin Demin 
+---
+ mmdebstrap | 28 +---
+ 1 file changed, 17 insertions(+), 11 deletions(-)
+
+--- a/mmdebstrap
 b/mmdebstrap
+@@ -4880,30 +4880,37 @@ sub main() {
+   . " signed-by value";
+ last;
+ }
++# initialize gpg trustdb with empty one
++{
++`@gpgcmd --update-trustdb >/dev/null 2>/dev/null`;
++$? == 

Bug#993806: kodi: No audio on DVD playback, AC3 Support

[Torsten Crass]

> I have nearly completed the recovery from COVID 

Oh my goodness! All the best for your recovery! Sincerely hope you won't
experience long COVID syndrome! So...

> and will try solving the DVD issue among the others.

...take it slowly, will you?

Cheers --

Torsten

-- 

Dr. rer. nat. Torsten Crass
Biochemiker, Bioinformatiker,
Software-Entwickler
https://www.aldebaran.de
https://www.tcits.de

Breite Lade 20
31275 Lehrte
Tel. 05132/8219177
https://www.tcrass.de



OpenPGP_signature
Description: OpenPGP digital signature

Bug#998194: This bug got fixed by guake 3.8.1

[shirish शिरीष]

Dear Maintainer,

This got fixed by guake 3.8.1, Please close the bug, thank you :)

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#982655: MBF: please drop transitional dummy package foo (if they were part of two releases or more)

[Holger Levsen]

hi,

On Sun, Aug 22, 2021 at 08:47:06PM +0200, Moritz Mühlenhoff wrote:
> Holger Levsen  wrote:
> > again, I'm planning an small mass bug filing against obsolete transitional
> > packages,  which are at least marked "dummy transitional" since the buster 
> > release,
> 
> Thanks for taking care of this!
> 
> But I'm wondering if this wouldn't be a perfect task for a Debian Janitor 
> fixer
> script, have you considered filing a task for this? After all those 
> transitional
> deps are reliably detectable and fixable.

actually there's already a bug, #982655 (cc:ed), titled "scrub-obsolete: replace
dependencies on transitional or removed packages" which I believed could be 
extended
to also cover removing transitional packages which have been present for more 
than
2 releases.

Jelmer, do you agree or do you want another bug for this feature request?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If we'd ban all cars from cities tomorrow, next week we will wonder why we
waited for so long.


signature.asc
Description: PGP signature

Bug#996997: marked as done (buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster"))

[Adam D. Barratt]

On Sun, 2021-12-19 at 18:47 +, Adam D. Barratt wrote:
[...]
> How does this sound as text for an SUA?
> 
> "
> http-parser is a parser for HTTP messages, designed to be used in
> high
> performance HTTP applications.
> 
> The update to http-parser included in the 10.10 point release
> introduced
> a regression affecting dependent applications. This update resolves
> that
> regression.
> 
> If you use http-parser, we strongly recommend that you install this
> update.
> "

Quick post-holidays ping on the above.

Regards,

Adam

Bug#1003186: aptitude: is too verbose after updating with -v option

[Michael Hannema]

Package: aptitude
Version: 0.8.13-3
Severity: normal
Tags: patch

Dear Maintainer,

While browsing the source I came upon some functionality that is
apparently unused. When running `aptitude -v update`, it seems
aptitude is meant to only print the number of new/upgradable/broken
packages if they are not zero, and always print them if the -v option is
used multiple times. I deduced this from the logic of the
show_stats_change function in cmdline_util.cc. However, two arguments in
the call to this function are mixed up, causing -v to have the same
behaviour as -vv in this case.

For example, I'm getting this output when updating with -v:

Current status: 0 (+0) broken, 0 (+0) upgradable, 88466 (+0) new.

While I'm expecting it to be like this:

Current status: 88466 (+0) new.

The former line is what I would expect when -v is used multiple times.

I have included a patch that switches the arguments. This function is
not called anywhere else in this project.


Regards,
Michael

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 10.2.1 20210110
Compiled against:
  apt version 6.0.0
  NCurses version 6.2
  libsigc++ version: 2.10.4
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.2.20201114
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffe2f394000)
libapt-pkg.so.6.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7ffb01eba000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7ffb01e7f000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7ffb01e5)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7ffb01e47000)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7ffb01d41000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7ffb01bfe000)
libboost_iostreams.so.1.74.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7ffb01be3000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7ffb019c1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7ffb0199f000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7ffb017d2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ffb0168e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7ffb01674000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ffb014ad000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7ffb01493000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ffb01476000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7ffb01463000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7ffb0143b000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7ffb01418000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7ffb0133b000)
libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 
(0x7ffb01313000)
libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7ffb0125e000)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7ffb0113e000)
libxxhash.so.0 => /usr/lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7ffb01125000)
/lib64/ld-linux-x86-64.so.2 (0x7ffb024f4000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ffb0111f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7ffb01112000)
libuuid.so.1 => /usr/lib/x86_64-linux-gnu/libuuid.so.1 
(0x7ffb01109000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7ffb010e3000)

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

Kernel: Linux 5.10.0-10-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 aptitude depends on:
ii  aptitude-common   0.8.13-3
ii  libapt-pkg6.0 2.2.4
ii  libboost-iostreams1.74.0  1.74.0-9
ii  libc6 2.31-13+deb11u2
ii  libcwidget4   0.5.18-5
ii  libgcc-s1 10.2.1-6
ii  libncursesw6  6.2+20201114-2
ii  libsigc++-2.0-0v5 2.10.4-2
ii  libsqlite3-0  3.34.1-3
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  libxapian30   1.4.18-3

Versions of packages aptitude recommends:
ii  libdpkg-perl1.20.9
ii  sensible-utils  0.0.14

Bug#1003185: dialog: Dialog segfaults when passing large line to editbox

[Nikos Dragazis]

Package: dialog
Version: 1.3-20201126-1
Severity: normal

Dear Maintainer,

There is a segfault bug in the editbox widget. Specifically, the dialog
can segfault when typing a line that is longer than the --max-input.

Steps to reproduce:
1. Run: touch /tmp/foo && dialog --max-input 10 --editbox /tmp/foo 18 80
2. Type a very long string. In my system, it suffices to type a
   40-character string.

The root cause of this bug seems to be a heap buffer overflow in the
editbox input buffer. The buffer overflow seems in turn to originate in
this line in dlg_editbox():

644 strncpy(buffer, input, max_len - 1)[max_len - 1] = '\0';

If the length of the string in the buffer and the cursor position (i.e.,
*chr_offset) are both equal to max_len, setting buffer[max_len - 1] to
\0 reduces the string length by one. This causes the cursor position to
exceed the string length. Since dlg_edit_string() checks only the string
length and not the cursor position, this leads eventually to buffer
overflow when typing new characters in the same line.

Note that this bug seems to be the same with the one reported a couple
of years ago here:
https://lists.gnu.org/archive/html/bug-ncurses/2019-06/msg1.html


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

Kernel: Linux 5.4.0-91-generic (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dialog depends on:
ii  debianutils   4.8.1.1
ii  libc6 2.31-13+deb11u2
ii  libncursesw6  6.2+20201114-2
ii  libtinfo6 6.2+20201114-2

dialog recommends no packages.

dialog suggests no packages.

-- no debconf information

Bug#1003184: plasma-framework: FTBFS on hppa - symbols

[John David Anglin]

Source: plasma-framework
Version: 5.88.0-1
Severity: normal

Dear Maintainer,

Build fails here:
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libkf5plasma5/DEBIAN/symbols doesn't match 
completely debian/libkf5plasma5.symbols
--- debian/libkf5plasma5.symbols (libkf5plasma5_5.88.0-1_hppa)
+++ dpkg-gensymbolsKLiCHv   2022-01-05 18:10:45.931286828 +
@@ -75,9 +75,11 @@
  _ZN6Plasma11Containment4initEv@Base 4.96.0
  _ZN6Plasma11Containment7restoreER12KConfigGroup@Base 4.96.0
  _ZN6Plasma11Containment9addAppletEPNS_6AppletE@Base 4.96.0
+ 
_ZN6Plasma11ContainmentC1EP7QObjectRK15KPluginMetaDataRK5QListI8QVariantE@Base 
5.88.0-1
  _ZN6Plasma11ContainmentC1EP7QObjectRK5QListI8QVariantE@Base 4.96.0
  _ZN6Plasma11ContainmentC1EP7QObjectRK7QStringj@Base 4.96.0
  _ZN6Plasma11ContainmentC1ERK15KPluginMetaDataj@Base 5.28.0
+ 
_ZN6Plasma11ContainmentC2EP7QObjectRK15KPluginMetaDataRK5QListI8QVariantE@Base 
5.88.0-1
  _ZN6Plasma11ContainmentC2EP7QObjectRK5QListI8QVariantE@Base 4.96.0
  _ZN6Plasma11ContainmentC2EP7QObjectRK7QStringj@Base 4.96.0
  _ZN6Plasma11ContainmentC2ERK15KPluginMetaDataj@Base 5.28.0
@@ -123,6 +125,7 @@
  _ZN6Plasma12PluginLoader15setPluginLoaderEPS0_@Base 4.96.0
  _ZN6Plasma12PluginLoader16listContainmentsERK7QStringS3_@Base 4.96.0
  
_ZN6Plasma12PluginLoader18internalLoadAppletERK7QStringjRK5QListI8QVariantE@Base
 4.96.0
+ _ZN6Plasma12PluginLoader18listAppletMetaDataERK7QString@Base 5.88.0-1
  _ZN6Plasma12PluginLoader18listAppletMetaDataERK7QStringS3_@Base 5.28.0
  _ZN6Plasma12PluginLoader18listDataEngineInfoERK7QString@Base 4.96.0
  _ZN6Plasma12PluginLoader19internalLoadPackageERK7QStringS3_@Base 4.96.0
@@ -296,6 +299,7 @@
  _ZN6Plasma5Theme11qt_metacastEPKc@Base 4.96.0
  _ZN6Plasma5Theme12setThemeNameERK7QString@Base 4.96.0
  _ZN6Plasma5Theme12themeChangedEv@Base 4.96.0
+ _ZN6Plasma5Theme13globalPaletteEv@Base 5.88.0-1
  _ZN6Plasma5Theme13setCacheLimitEi@Base 4.96.0
  _ZN6Plasma5Theme15insertIntoCacheERK7QStringRK7QPixmap@Base 4.96.0
  _ZN6Plasma5Theme15insertIntoCacheERK7QStringRK7QPixmapS3_@Base 4.96.0
@@ -367,11 +371,13 @@
  _ZN6Plasma6Applet8setTitleERK7QString@Base 5.21.0
  _ZN6Plasma6Applet9activatedEv@Base 4.97.0
  _ZN6Plasma6Applet9setStatusENS_5Types10ItemStatusE@Base 4.96.0
+ _ZN6Plasma6AppletC1EP7QObjectRK15KPluginMetaDataRK5QListI8QVariantE@Base 
5.88.0-1
  _ZN6Plasma6AppletC1EP7QObjectRK5QListI8QVariantE@Base 4.96.0
  _ZN6Plasma6AppletC1EP7QObjectRK7QStringj@Base 4.96.0
  _ZN6Plasma6AppletC1ERK11KPluginInfoP7QObjectj@Base 4.96.0
  _ZN6Plasma6AppletC1ERK15KPluginMetaDataP7QObjectj@Base 5.28.0
  _ZN6Plasma6AppletC1ERK7QStringj@Base 4.96.0
+ _ZN6Plasma6AppletC2EP7QObjectRK15KPluginMetaDataRK5QListI8QVariantE@Base 
5.88.0-1
  _ZN6Plasma6AppletC2EP7QObjectRK5QListI8QVariantE@Base 4.96.0
  _ZN6Plasma6AppletC2EP7QObjectRK7QStringj@Base 4.96.0
  _ZN6Plasma6AppletC2ERK11KPluginInfoP7QObjectj@Base 4.96.0
@@ -482,7 +488,7 @@
  _ZN6Plasma8FrameSvgD1Ev@Base 4.96.0
  _ZN6Plasma8FrameSvgD2Ev@Base 4.96.0
  (optional=templinst|arch=arm64 armel armhf hurd-i386 i386 kfreebsd-i386 m68k 
mips mipsel powerpc powerpcspe ppc64el 
sparc64)_ZNK12KConfigGroup9readEntryI6QRectFEET_PKcRKS2_@Base 4.100.0
- (arch=!hurd-i386 !i386 !m68k !mipsel !ppc64 
!s390x)_ZNK12KConfigGroup9readEntryI6QSizeFEET_PKcRKS2_@Base 5.81.0
+#MISSING: 5.88.0-1# (arch=!hurd-i386 !i386 !m68k !mipsel !ppc64 
!s390x)_ZNK12KConfigGroup9readEntryI6QSizeFEET_PKcRKS2_@Base 5.81.0
  (optional=templinst)_ZNK12KConfigGroup9readEntryIbEET_PKcRKS1_@Base 5.61.0
  (optional=templinst)_ZNK12KConfigGroup9readEntryIdEET_PKcRKS1_@Base 5.17.0
  (optional=templinst)_ZNK12KConfigGroup9readEntryIiEET_PKcRKS1_@Base 4.100.0
@@ -747,3 +753,9 @@
  _ZTVN6Plasma6CoronaE@Base 4.96.0
  _ZTVN6Plasma7ServiceE@Base 4.96.0
  _ZTVN6Plasma8FrameSvgE@Base 4.96.0
+ 
_ZZZN14KPluginFactory17instantiatePluginIN6Plasma10DataEngineEEENS_6ResultIT_EERK15KPluginMetaDataP7QObjectRK5QListI8QVariantEENKUlvE_clEvE15qstring_literal@Base
 5.88.0-1
+ 
_ZZZN14KPluginFactory17instantiatePluginIN6Plasma12ScriptEngineEEENS_6ResultIT_EERK15KPluginMetaDataP7QObjectRK5QListI8QVariantEENKUlvE_clEvE15qstring_literal@Base
 5.88.0-1
+ 
_ZZZN14KPluginFactory17instantiatePluginIN6Plasma16PackageStructureEEENS_6ResultIT_EERK15KPluginMetaDataP7QObjectRK5QListI8QVariantEENKUlvE_clEvE15qstring_literal@Base
 5.88.0-1
+ 
_ZZZN14KPluginFactory17instantiatePluginIN6Plasma18ContainmentActionsEEENS_6ResultIT_EERK15KPluginMetaDataP7QObjectRK5QListI8QVariantEENKUlvE_clEvE15qstring_literal@Base
 5.88.0-1
+ 
_ZZZN14KPluginFactory17instantiatePluginIN6Plasma6AppletEEENS_6ResultIT_EERK15KPluginMetaDataP7QObjectRK5QListI8QVariantEENKUlvE_clEvE15qstring_literal@Base
 5.88.0-1
+ 

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote:
> I suppose I'll see how it goes in the coming few days.

So it's not crashing but it's being unbearably slow in gmail, to the
point that I just wasn't able to type a mail there, while throwing one
CPU core to 100%.
Also it was kind go generally slow in several other sites, compared to
v93.  Always compared to v93, it takes far longer (and by far much much
more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
all the time, trusting the browser to reopen them where I left when I
close it).

I didn't mesure anything and I don't have any numbers to share, but
that's what I see.


At least, it looks like it has not been leaking as much memory as v93
was (that in this regard was buggier than v90).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/5/22 13:14, Mattia Rizzolo wrote:

On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote:

I suppose I'll see how it goes in the coming few days.

So it's not crashing but it's being unbearably slow in gmail, to the
point that I just wasn't able to type a mail there, while throwing one
CPU core to 100%.
Also it was kind go generally slow in several other sites, compared to
v93.  Always compared to v93, it takes far longer (and by far much much
more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
all the time, trusting the browser to reopen them where I left when I
close it).

I didn't mesure anything and I don't have any numbers to share, but
that's what I see.


At least, it looks like it has not been leaking as much memory as v93
was (that in this regard was buggier than v90).



I've been testing on x11 (under xfce). Are you using wayland, by chance?

Bug#993526: please give me my localhost mail support BACK!!!!!

[Carsten Schoenert]

Am 05.01.22 um 18:29 schrieb Mike K:



      What the hell???   NOBODY uses icedove for looking at their
localhost mail

That's a whole lotta BS.  I use it EVERYDAY to monitor system activity,
errors, firewall, etc, etc.

all root sys messages.

      Who is the genius that decided to REMOVE this support in version
91.4.1??  I'm on Debian Stretch still
on this box.


https://bugzilla.mozilla.org/show_bug.cgi?id=1625741

As mentioned by the issue starter already.



      I can't believe that mozilla broke thunderbird *again*. sigh.


      Somebody really f'd up this time.


--
Regards
Carsten

Bug#907606: fsck takes hours to complete, just due to slow screen output

[Thorsten Glaser]

tags 907606 - unreproducible
thanks

On Wed, 5 Jan 2022, Adam Borowski wrote:

> Yet in so many cases it's this log output that's an order or two of
> magnitude slower than actual fsck.  Even a spinner gives 200 seeks per

Indeed, especially with fb consoles it’s very very slow on scroll,
but slow serial links are obviously a similar PITA.

I’ve seen this, so removing the tag.

> I don't think there's much point running fsck on boot time on any filesystem
> newer than ext2 (ie, Hurd),

I do. If the journal replay suffices, it doesn’t do much, but if
not it’s needed.

> but if it's being done, there's no point dumping
> all these details to the screen where no human can possibly read.

Except for the case where fsck becomes interactive, or the last
thing is actually relevant…

> Perhaps we should decrease fsck's verbosity or rate-limit screen output,
> discarding excess text?

I’d suggest something like OpenBSD’s build watcher, that is,
'fsck >log 2>&1 & while sleep 2; do tail -3 log; done', or
the watch utility. But the fsck can suddenly become interactive
case is a problem.

Humans see “Clearing orphaned inode […]” so collapsing these
into a “Clearing orphaned inodes: $count\r” would be possible,
but some log should be guaranteed to have the full information
once booted (and, perhaps, even if the boot aborts).

I believe this would be best served by support from within
the relevant fsck utilities and perhaps starting by taking
e2fsck into Cc to discuss ideas is a good first step? Maybe
an extra option¹ that reduces screen output while adding
the full information to some file (which tbd because we need
to consider root fs fsck, then copying that over later to
whereever /var is, and with/without initrd setups).

① probably not an option, because all fscks would need to
  support this in lockstep, but perhaps an environment
  variable which can then be added to these that need it,
  i.e. these that can produce more than a couple of lines
  of output on boot (not all do)…

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1003154: sudo 1.9.8p2-1 breaks sshuttle

[H. S. Teoh]

On Wed, Jan 05, 2022 at 02:25:27PM +0100, Marc Haber wrote:
[...]
> On Tue, Jan 04, 2022 at 06:36:52PM -0800, H. S. Teoh wrote:
> > PermissionError: [Errno 1] Operation not permitted
> > c : fatal: ['/usr/bin/sudo', '-p', '[local sudo] Password: ', 
> > '/usr/bin/env', 'PYTHONPATH=/usr/lib/python3/dist-packages', 
> > '/usr/bin/python3', '/usr/bin/sshuttle', '-v', '--method', 'nft', 
> > '--firewall'] returned 1
> 
> Can you please verify whether this command also fails on the command
> line, and then reduce the command line so that we can find out whatever
> the current sudo doesn't like?
[...]

The failure appears to be coming from sshuttle itself, with that
specific combination of arguments.  It's not sudo that's rejecting the
command per se, but something about the environment it sets up isn't
working well with sshuttle.  The failure is coming from the os.setsid()
call inside sshuttle (the lines before the ones you quoted above).

The previous version of sudo was obviously setting up *something*
differently, such that this call worked.


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson

Bug#1003181: cython: sparc64 is not building cython ("Not For Us")

[Drew Parsons]

Source: cython
Version: 0.29.24-2
Severity: normal
X-Debbugs-Cc: debian-sp...@lists.debian.org

cython previously built on sparc64 for bullseye (stable) at version 0.29.21-3

Now (for version 0.29.24-2), cython is marked "Not For Us" on sparc64
and is no longer building.

python3.10 is still building for sparc64.  A lot of python packages
need cython, it would be a shame not to let them be available any
more.

I can't see any configuration or documentation in cython source that
would prevent building on sparc64.  I haven't heard that the sparc64
port is being abandoned altogether (again, python3.10 is still
building there).

Do we know why sparc64 has stopped building cython?

Bug#1003180: votca-xtp: virtual memory exhausted: Cannot allocate memory

[Sebastian Ramacher]

Source: votca-xtp
Version: 2021.2-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

| [  7%] Building CXX object 
src/libxtp/CMakeFiles/votca_xtp.dir/calculators/eanalyze.cc.o
| cd /<>/obj-mipsel-linux-gnu/src/libxtp && /usr/bin/c++ 
-DBOOST_ALL_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK 
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_TIMER_DYN_LINK 
-Dvotca_xtp_EXPORTS -I/<>/obj-mipsel-linux-gnu/src/libxtp 
-I/<>/src/libxtp -I/<>/include 
-I/usr/include/hdf5/serial -I/<>/obj-mipsel-linux-gnu/include 
-I/<>/obj-mipsel-linux-gnu/include/votca/xtp -isystem 
/usr/include/eigen3 -isystem /usr/include/libint2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -O1 -g1 -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-fopenmp -std=c++14 -MD -MT 
src/libxtp/CMakeFiles/votca_xtp.dir/calculators/eanalyze.cc.o -MF 
CMakeFiles/votca_xtp.dir/calculators/eanalyze.cc.o.d -o 
CMakeFiles/votca_xtp.dir/calculators/eanalyze.cc.o -c 
/<>/src/libxtp/calculators/eanalyze.cc
| virtual memory exhausted: Cannot allocate memory
| make[3]: *** [src/libxtp/CMakeFiles/votca_xtp.dir/build.make:163: 
src/libxtp/CMakeFiles/votca_xtp.dir/aomatrices/aomatrix.cc.o] Error 1

See
https://buildd.debian.org/status/fetch.php?pkg=votca-xtp=mipsel=2021.2-1%2Bb1=1641244404=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1003179: freeipa: fails to clean after successful build

[Andreas Beckmann]

Source: freeipa
Version: 4.9.8-1+exp1
Severity: important

Hi,

freeipa (at least in experimental, I haven't tried the version in sid)
fails to clean after a successful build (and therefore cannot be built
again in this tree):

 fakeroot debian/rules clean
dh clean --with python3
   dh_auto_clean
make -j3 distclean
make[1]: Entering directory '/build/freeipa-4.9.8'
Making distclean in asn1
make[2]: Entering directory '/build/freeipa-4.9.8/asn1'
[...]
make[2]: Entering directory '/build/freeipa-4.9.8'
test -z "ipa makeaci makeapi " || rm -f ipa makeaci makeapi 
rm -rf .libs _libs
rm -rf "/build/freeipa-4.9.8/rpmbuild"
test -z "ipasetup.pyc ipasetup.pyo pylint_plugins.pyc pylint_plugins.pyo" || rm 
-f ipasetup.pyc ipasetup.pyo pylint_plugins.pyc pylint_plugins.pyo
rm -f *.lo
rm -rf "./dist"
test -z "" || rm -f 
rm -f config.h stamp-h1
rm -rf "./.tox"
test . = "." || test -z "" || rm -f 
rm -f libtool config.lt
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -rf "./__pycache__"
rm -f cscope.out cscope.in.out cscope.po.out cscope.files
rm -f "."/freeipa-*.tar.gz
rm -rf "./cov-int"
rm -f "./freeipa.tgz"
make -C "./doc" distclean
make[3]: Entering directory '/build/freeipa-4.9.8/doc'
/bin/sh: 1: sphinx-build: not found
make[3]: *** [Makefile:24: clean] Error 127
make[3]: Leaving directory '/build/freeipa-4.9.8/doc'
make[2]: *** [Makefile:1140: clean-local] Error 2
make[2]: Leaving directory '/build/freeipa-4.9.8'
make[1]: *** [Makefile:691: distclean-recursive] Error 1
make[1]: Leaving directory '/build/freeipa-4.9.8'
dh_auto_clean: error: make -j3 distclean returned exit code 2


Andreas


freeipa_4.9.8-1+exp1_twice.log.gz
Description: application/gzip

Bug#1003155: opensbi: tar.xz is not supported by 'git archive'

[Vagrant Cascadian]

Control: severity 1003155 minor

On 2022-01-05, Heinrich Schuchardt wrote:
> The opensbi package has a maintainer script debian/bin/git-snapshot with
> commands
>
>  archive=tar.xz
>  git archive \
>   --format=${archive} \

Adding to .gitconfig makes it work:

[tar "tar.xz"]
command = xz --threads=0


> tar.xz is not a valid archive format. 'git archive -l' gives this list:
>
> * tar
> * tgz
> * tar.gz
> * zip
>
> Please, change the maintainer script to use --format=tar and issue a
> separate command to compress with xz.

Or maybe not bother with .xz at all and just use a .tar.gz. I usually
use the "released" tarballs downloaded via debian/watch, which ends up
with .tar.gz from github anyways...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1001081: response to Sébastien's question

[David Loyall]

Hello, Sébastien.

It took me a long time to reply, please accept my apologies.

> In order to rule out problems caused by your initialization
> scripts, can you try the following:
>
> sbcl --no-sysinit --no-userinit --load \
> /usr/share/common-lisp/source/quicklisp/quicklisp.lisp

Sure. Ok, I got the same result when invoking that exact command line
you provided: "Internal error 222".

(Separately, I confirmed these two files have identical contents:
/usr/share/common-lisp/source/quicklisp/quicklisp.lisp and
/home/sebboh/prj/quicklisp.lisp)

I found that I do NOT have to `killall -9 sbcl`...  Instead, after the
error, I can select [CONTINUE] and then invoke (quit).  Log of that
follows my signature.  Maybe your eyes can see a clue where mine do
not yet.  Hm, when I do it this way, now the output does list a
specific undefined function.

I hope this helps, and I'm still willing to gather more information.
More quickly next time. :)

Cheers,
--sebboh

sebboh@debian:~$ sbcl --no-sysinit --no-userinit --load
/usr/share/common-lisp/source/quicklisp/quicklisp.lisp
This is SBCL 2.1.11.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
While evaluating the form starting at line 1154, column 0
  of #P"/usr/share/common-lisp/source/quicklisp/quicklisp.lisp":

debugger invoked on a SIMPLE-ERROR @52CF6451 in thread
#:
  internal error 222: NIL; args=NIL

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY   ] Retry EVAL of current toplevel form.
  1: [CONTINUE] Ignore error and continue loading file
"/usr/share/common-lisp/source/quicklisp/quicklisp.lisp".
  2: [ABORT   ] Abort loading file
"/usr/share/common-lisp/source/quicklisp/quicklisp.lisp".
  3:Ignore runtime option --load
"/usr/share/common-lisp/source/quicklisp/quicklisp.lisp".
  4:Skip rest of --eval and --load options.
  5:Skip to toplevel READ/EVAL/PRINT loop.
  6: [EXIT] Exit SBCL (calling #'EXIT, killing the process).

(SB-C:MAKE-TN-REF # T)
0] 1
;
; compilation unit aborted
;   caught 1 fatal ERROR condition

; file: /usr/share/common-lisp/source/quicklisp/quicklisp.lisp
; in: DEFUN READ-HTTP-HEADER
; (QLQS-HTTP::PROCESS-HEADER QLQS-HTTP::HEADER-DATA)
;
; caught STYLE-WARNING:
;   undefined function: QLQS-HTTP::PROCESS-HEADER
;
; compilation unit finished
;   Undefined function:
; PROCESS-HEADER
;   caught 1 STYLE-WARNING condition

   quicklisp quickstart 2015-01-28 loaded 

To continue with installation, evaluate: (quicklisp-quickstart:install)

For installation options, evaluate: (quicklisp-quickstart:help)

* (quit)

Bug#907606: fsck takes hours to complete, just due to slow screen output

[Adam Borowski]

On Wed, Jan 05, 2022 at 03:17:50PM +, Loorey wrote:
> FSCK is the utility for checking the filesystem for Errors and
> fixing those, of course after an ungraceful shutdown this operation
> can take hours, and of course printing the log will be much faster
> than the actual operation, because fsck fixes the system while also
> logging, and in the other case you are just reading and printing the
> log file.

Yet in so many cases it's this log output that's an order or two of
magnitude slower than actual fsck.  Even a spinner gives 200 seeks per
second, while a good modern disk can do in excess of 2M random reads.
Meanwhile, a 115200 terminal is limited to 180 80-character lines per
second, and fbdev on a high-end GPU is much slower than that.

Cf #991218 which is this same problem from another program.

I don't think there's much point running fsck on boot time on any filesystem
newer than ext2 (ie, Hurd), but if it's being done, there's no point dumping
all these details to the screen where no human can possibly read.

Perhaps we should decrease fsck's verbosity or rate-limit screen output,
discarding excess text?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ You should never, ever, degrade a human being by saying they're
⣾⠁⢠⠒⠀⣿⡁ a worthless waste of food and air.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄ You should also never anthropomorphize spammers and telemarketers.

Bug#1003177: mmdebstrap: --dry-run fails with error: cannot read /var/cache/apt/archives/

[Benjamin Drung]

Package: mmdebstrap
Version: 0.7.5-2.2
Severity: normal

Hi,

mmdebstrap from Debian stable fails to run with --dry-run. Example:

```
$ mmdebstrap -v --dry-run --variant=minbase unstable root.tar
[...]
Inst sysvinit-utils (3.01-1 Debian:unstable [amd64])
Conf sysvinit-utils (3.01-1 Debian:unstable [amd64])
I: skip extracting packages because of --dry-run
I: no essential packages -- skipping...
E: cannot read /var/cache/apt/archives/
W: listening on child socket failed: 
I: removing tempdir /tmp/mmdebstrap.e7VYvXTJ31...
```

Running the same command on Debian unstable with mmdebstrap 0.8.2-1
works, but backporting mmdebstrap >= 0.8 to Debian bullseye fails,
because mmdebstrap >= 0.8 requires a APT version that is newer than the
one shipped in bullseye.

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations Cloud

IONOS SE | Revaler Str. 30 | 10245 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Britta Schmidt, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#1003176: transition: perl 5.34

[Niko Tyni]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-p...@lists.debian.org, p...@packages.debian.org
Control: block -1 with 1002093 997267 997189

Hi,

we'd like a transition slot for Perl 5.34.

Should have done this months ago, but real life has interfered. Sorry
about that.

Perl 5.36 is scheluded for May or so, and I expect that will be our target
for bookworm.  Nevertheless, it's probably best to do this incrementally
and have a 5.34 transition now in case 5.36 turns out to be difficult
for some reason.

The changes in 5.34 are quite small, as upstream spent most of that
release cycle planning Perl 7 (which did not quite work out.) This
reflects in the very low number regressions we found in our test
rebuilds, visible at

  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.34-transition;users=debian-p...@lists.debian.org

with just one bug open (openscap, not in testing).

I did a full archive test rebuild back in May, and partial test rebuilds
in August. Coming back to this now, I've done another round of test
rebuilds for those packages that will need binNMUs. I don't think another
full round is necessary: it seems unlikely that the other packages might
have introduced any Perl 5.34 related regressions in the meantime.

There's a few packages that have unrelated build failures in current sid.
I'm marking the ones in testing as blockers for this.

Not sure if this Ben file is correct but hope it helps a bit:

title = "perl";
is_affected = .depends ~ "libperl5.32|perlapi-5.32" | .pre-depends ~ 
"libperl5.32|perlapi-5.32";
is_good = .depends ~ "libperl5.34|perlapi-5.34" | .pre-depends ~ 
"libperl5.34|perlapi-5.34";
is_bad = .depends ~ "libperl5.32|perlapi-5.32" | .pre-depends ~ 
"libperl5.32|perlapi-5.32";

Thanks for your work,
-- 
Niko Tyni   nt...@debian.org

Bug#1003175: mmdebstrap: fails to run with ASCII armored keys in /etc/apt/trusted.gpg.d

[Johannes Schauer Marin Rodrigues]

Source: mmdebstrap
Version: 0.7.5-2.2
Severity: important
X-Debbugs-Cc: jo...@debian.org

Since version 1.4 apt supports ASCII armored keyrings in
/etc/apt/trusted.gpg.d. If mmdebstrap is run in such an environment, the
following error is produced:

gpg: [don't know]: invalid packet (ctb=2d)
gpg: keydb_search_first failed: Invalid packet
E: gpg failed at /usr/bin/mmdebstrap line 170.
main::error("gpg failed") called at /usr/bin/mmdebstrap line 4915
main::main() called at /usr/bin/mmdebstrap line 5796

A workaround is to run mmdebstrap with manually passed keyring material.
But normal executions like:

mmdebstrap bullseye chroot.tar

Will fail with above error.

This is fixed upstream in commit ccd4b5c1 and in Debian since version
0.8.0-1.

Bug#1002396: djangorestframework: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

[Lukas Märdian]

Package: djangorestframework
Followup-For: Bug #1002396
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com
Control: tags -1 patch

Hello Sandro,

you disabled the test_markdown test in your recent upload of
djangorestframework 3.12.4-2 in order to handle the failure described in
https://github.com/encode/django-rest-framework/issues/8160

The same test suite is run as an autopkgtest and I'd like to proposed disabling
this very test in the same way there, too.

In Ubuntu, the attached patch was applied to achieve the following:

  * d/tests/control
- skip test_markdown, which is currently failing; see issue #8160 upstream
  for followups (LP: #1955134)


Thanks for considering the patch.

Cheers,
  Lukas


-- System Information:
Debian Release: 11.0
  APT prefers impish-updates
  APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 
'impish'), (100, 'impish-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-23-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru djangorestframework-3.12.4/debian/tests/control 
djangorestframework-3.12.4/debian/tests/control
--- djangorestframework-3.12.4/debian/tests/control 2021-12-31 
08:05:52.0 +0100
+++ djangorestframework-3.12.4/debian/tests/control 2022-01-05 
17:47:08.0 +0100
@@ -1,4 +1,7 @@
-Test-Command: cp -r tests $AUTOPKGTEST_TMP && cd $AUTOPKGTEST_TMP && pytest-3
+# Disable test_markdown until the upstream issue is resolved:
+# https://github.com/encode/django-rest-framework/issues/8160
+# Disable it the same way as done in dh_auto_test (debian/rules) at build time
+Test-Command: cp -r tests $AUTOPKGTEST_TMP && cd $AUTOPKGTEST_TMP && pytest-3 
-k 'not test_markdown'
 Depends:
  python3-pygments,
  python3-pytest,

Bug#970368: soundmodem: please remove irl from uploaders

[Roland OE1RSA]

Dear debian hams,

Am 15.09.20 um 10:39 schrieb Iain R. Learmonth:

Package: soundmodem
Severity: normal
User: i...@debian.org
Usertags: refactor2020
X-Debbugs-Cc: debian-h...@lists.debian.org

Hi,

Please remove me from the uploaders list on the next upload, I no longer
intend to maintain this package and it's good to keep that list
accurate.


I just completed a fork of the soundmodem package from Thomas Sailer, 
which can be seen on


https://gitlab.com/packetradio/soundmodem

I would be interested in keeping the package (or my successor) available 
from the debian repos. I would also offer to help maintaining the debian 
package, however this would be my first debian package. So I would be 
glad for a helping hand and some advice.


What would I need to do to become member of the debian-hams?

73 Roland, oe1rsa

Bug#1001555: openconnect: can't connect to server that use SSO SAML with protocol "anyconnect"

[Luca Boccassi]

On Mon, 2022-01-03 at 20:08 +0100, Antonio wrote:
> Dear maintainer,
> I tried the updated version of OpenConnect.
> 
> ---
> 
>  From GNOME interface:
> 
> - When the VPN is active, the form for the insertion of username and 
> password appears.
> - Provide access credentials I receive notification from Microsoft 
> Authenticator
> - confirmed identity via authenticator, the "remain connected" form 
> appears and I reply "yes"
> 
> The page is then shown:
> 
> "Cisco AnyConnect Secure Mobility Client"
> "You have successfully authenticated. You may now close this browser
> tab"
> 
> Now the VPN should be active but if I try from terminal or browser I 
> can't access the VPN network, despite successfully executed all the
> steps.
> 
> If I close the browser page, as indicated, the network menu indicates
> that the VPN is off.
> 
> Or rather, I think it's never started.
> 
> Journal reports: "Final Secrets Request Failed to Provide Sufficient 
> Secrets"

Strange - but not unexpected, these VPNs are terrible. I have reports
of users with AnyConnect and other SAML providers working fine with the
latest version.
There also was an unfixed issue with some newer AnyConnect servers that
was fixed with yesterday's upload, try and have a look if that makes a
difference.

If it doesn't, it sounds like you need to debug it to figure out where
it's going wrong - you can run the auth dialog in gdb and walkthrough
the code as such:

- install network-manager-openconnect-dbgsym network-manager-
openconnect-gnome-dbgsym openconnect-dbgsym libopenconnect5
-dbgsym
- create a local script somewhere with something like:

#!/bin/bash
gdbserver localhost:12345 /usr/lib/NetworkManager/nm-openconnect-auth-dialog $@

- edit temporarily /usr/lib/NetworkManager/VPN/nm-openconnect-
service.name and change auth-dialog to point to the script above

Then you'll be able to connect with gdb and debug as usual after
activating the VPN via the Gnome GUI.

> ---
> 
>  From KDE interface:
> 
> - same configuration
> 
> - I can now select correct AUTHGROUP
> 
> However, when I click on the "Access" button, the form does not
> appear 
> to insert the credentials.
> 
> Unlike the GNOME interface, the log log continues to report the
> message 
> "No SSO Handler".
> 
> Thank you,
> Antonio

As the message implies, KDE is not supported, nobody has done the work
to make it happen.

> 
> Il 31/12/21 01:34, Luca Boccassi ha scritto:
> > Control: tag -1 pending
> > 
> > Hello,
> > 
> > Bug #1001555 in openconnect reported by you has been fixed in the
> > Git repository and is awaiting an upload. You can see the commit
> > message below and you can check the diff of the fix at:
> > 
> > https://salsa.debian.org/debian/openconnect/-/commit/145c237a574d06f348d0147390f33b5993e5b52d
> > 
> > ---
> > -
> > Update SAML patch
> > 
> > Correctly detect termination on Anyconnect + Google SAML.
> > Also restore backward compatibility for legacy CLI based workflow.
> > 
> > Closes: #1001555
> > 
> > Gbp-Dch: full
> > ---
> > -
> > 
> > (this message was generated automatically)

-- 
Kind regards,
Luca Boccassi


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

Bug#998553: RC bug in libdbi-drivers

[GCS]

Hi Thorsten,

On Wed, Jan 5, 2022 at 1:09 PM Thorsten Alteholz  wrote:
> are you already working on an upload of libdbi-drivers? Or do you need some 
> help?
 Did a quick check back then, but couldn't find the root cause. I
couldn't devote more time to this issue since then. Maybe tomorrow I
can check it. But of course, any help is appreciated.

Regards,
Laszlo/GCS

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

[Vincent Lefevre]

Control: reassign -1 unbound 1.13.1-1
Control: retitle -1 unbound: /etc/resolvconf/update.d/unbound should be 
reenabled by default

The unbound behavior should be similar to the one without
resolvconf installed. So /etc/resolvconf/update.d/unbound
should be reenabled by default so that name resolution works
when UDP is filtered, and perhaps more generally to make it
work with captive portals, which are common nowadays.

The current situation is very confusing, and the installation
of resolvconf (e.g. because some other package needs it) may
make things no longer work as expected.

On 2022-01-05 16:22:16 +0100, Vincent Lefevre wrote:
> Indeed, this was the cause of the issue. After making unbound
> executable, I now get:
> 
> # unbound-control forward
> 192.168.43.173 192.168.1.1
> 
> instead of "off".
> 
> However, this is broken: 192.168.1.1 shouldn't be there!!!

Concerning this issue, this is because a reboot was needed, as
documented in the resolvconf(8) man page (I think that resolvconf
should have been smarter, but this is probably not a big issue).

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

Bug#1003174: darktable: misses optional dependencies sdl2 and portmidi

[David Bremner]

Package: darktable
Version: 3.8.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Version 3.8 introduces optional dependencies on sdl2 and
portmidi. Currently the debian package does not build against these
libraries.

Presumably some features are also missing.

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

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

Versions of packages darktable depends on:
ii  libc62.33-1
ii  libcairo21.16.0-5
ii  libcolord-gtk1   0.1.26-2+b1
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-7
ii  libcurl3-gnutls  7.80.0-3
ii  libexiv2-27  0.27.3-3.1
ii  libgcc-s111.2.0-13
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.2-1
ii  libgomp1 11.2.0-13
ii  libgphoto2-6 2.5.27-1
ii  libgphoto2-port122.5.27-1
ii  libgraphicsmagick-q16-3  1.4+really1.3.37-1
ii  libgtk-3-0   3.24.31-1
ii  libicu67 67.1-7
ii  libilmbase25 2.5.7-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  liblcms2-2   2.12~rc1-2
ii  liblensfun1  0.3.2-6
ii  libopenexr25 2.5.7-1
ii  libopenjp2-7 2.4.0-3
ii  libosmgpsmap-1.0-1   1.2.0-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1
ii  libpng16-16  1.6.37-3
ii  libpugixml1v51.11.4-1
ii  librsvg2-2   2.50.7+dfsg-2
ii  libsecret-1-00.20.4-2
ii  libsoup2.4-1 2.74.2-3
ii  libsqlite3-0 3.36.0-2
ii  libstdc++6   11.2.0-13
ii  libtiff5 4.3.0-2
ii  libwebp6 0.6.1-2.1
ii  libx11-6 2:1.7.2-2+b1
ii  libxml2  2.9.12+dfsg-5+b1
ii  libxrandr2   2:1.5.2-1
ii  zlib1g   1:1.2.11.dfsg-2

darktable recommends no packages.

darktable suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmHVwjQACgkQA0U5G1Wq
FSGo3w/9Fcz8nFDXzdRS2UhBaJGzsRzGGiTJ+Ba81gDmFxwlMW0h54yzVCcP4lrS
BfpoEt6pOirm7zXVsnCMkp0rcjul4gmq0PV8ciGyOP6Pw0AqB6CwhV8cptzYntX+
8izlm0EBUhVFtYF8CJZyUlUP0jHKeDMkzlVMXeN3CEfTUi2bIhSs5itcpU+M6tpQ
Chh5zyXYAoCm1/+dmQ9O31VFxe/mnL+BoCRDA+TgKtvtJnPIdOqJP024RkoglzdH
PTWoOUNnG5dslpwYe4eKEzjnHfVFUWluUuP0E3mTT4+mBPpXK40EZrfbBjvfTmbC
tNsCC5XKr3JyAzGBNGdp94I0qlaNgPAKRzol830stMT58E9PsYgViv1aiDuEc+cu
abvEXoVwVwkp7iWwv742Ac1Da4++Ln96iDFDi1krRC+POYeu4o3TpDsUQH5AlqJP
D2pEIHhopKdL51ABpC1DL322Xz9lNRoNe6Wuy4gtUKelg/Cule3HVGrw1BKSyNhK
Fzp5GpyFiqsICoSc/mq3mW1J6yOmAKojsW4NRSlklOq3zqX5QJarApnPT+vHaHB/
arSrqtpLZI7RxqsygvgfrlyJuBdmyZE4j5bpCxxF73Bk7XoMG3zA1mxadXHC2UH3
zeFjY5LOBm16uoT7utQXs2kYkxjBNAIjedDyTKqiF8X2XjhZUTA=
=IbPd
-END PGP SIGNATURE-

Bug#1003173: bullseye-pu: package nvidia-cuda-toolkit/11.2.2-3+deb11u1

[Andreas Beckmann]

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

Hi,

I'd like to update nvidia-cuda-toolkit in bullseye/non-free in order to
disable the non-functional python3 support in cuda-gdb. This causes 
segmentation faults if libpython2.7.so.1 is available on the system, due
to dlopening that library even if we built cuda-gdb against python3.x.
(python3 support in cuda-gdb became functional and was re-enabled in 11.4,
it does not look fixable in 11.2 due to incomplete python3 support)

I'll take this opportunity to also update the bundled openjdk-8 snapshot
to the version currently in unstable, probably fixing a ton of CVEs.

Upstream treats the cuda toolkit as a bundle of several individually
versioned components, unfortunately the versions are not always
monotonic... In order to detect (and workaround) the versioning errors at
buildtime (and not by ftp-master rejecting the binary packages), I've
automated that in debian/rules. That change may look big, but to show
that it does not affect the resulting binary packages I'm also attaching
a binary debdiff against a rebuild of 11.2.2-3 as 11.2.2-3+deb11u1 with
no further changes than the version bump.


Andreas


nct-11.2.2-3+deb11u1.diff.xz
Description: application/xz


nvidia-cuda-toolkit_11.2.2-3+deb11u1_amd64.changes.bindiff.xz
Description: application/xz

Bug#1003169: telegram-desktop: ”Internal server error.“ when confirming the phone number

[Nicholas Guriev]

Hello!

To fix login issue, please install more recent version of Telegram
Desktop. You can use 3.1.1 from backports. It should work.

I mean the buster-backports-sloppy suite that you can activate via
sources.list(5).



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

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

[Karel Zak]

On Tue, Jan 04, 2022 at 06:31:24PM +0100, наб wrote:
> Control: tags -1 + upstream
> 
> On Tue, Jan 04, 2022 at 05:24:54PM +0100, Chris Hofstaedtler wrote:
> > * наб  [220104 00:06]:
> > > (This, at least, responds to ^\, but it also seems to function
> > >  slightly differently. Also, this is a race and you're more
> > >  likely to lose it under strace. The loopy thing seems
> > >  like it's pretty good at hitting it 100% of the time.)
> As an additional note, because it's a race, if you're using bash,
>   script < some-photo.jpeg
> also hangs, because setup takes long enough.
> 
> > 1) is this Debian-specific or already present upstream?
> Debian doesn't patch script.c at all, so this is an upstream bug.
> 
> > 2) did this work with previous versions of util-linux?
> The oldest one I fould from the site at Homepage: in d/control is
> "util-linux-ng 2.13", dated 19.1.2012. It's much closer to the original
> 4.4BSD-Lite implementation and still forks twice. As expected, testing
> reveals it does not have the bug.
> 
> Performing a simple manual bisect across the versions available therein
> reveals that 2.25 is the first broken version. (Though, skimming the
> source, with a slightly different code path (select(2)?), since it still
> double-forks and is not so hard-stuck so as to be immune to ^\.)
> 
> The first version that does get hard-stuck (because it forks once
> and only uses poll) is 2.27.

Resolve the problem with the signal should be simple. Now it
ignores all when it write to the master. Something like:


diff --git a/lib/pty-session.c b/lib/pty-session.c
index 6f038e1c5..84ea33860 100644
--- a/lib/pty-session.c
+++ b/lib/pty-session.c
@@ -292,7 +292,20 @@ static int write_output(char *obuf, ssize_t bytes)
 
 static int write_to_child(struct ul_pty *pty, char *buf, size_t bufsz)
 {
-   return write_all(pty->master, buf, bufsz);
+   sigset_t set, org;
+   int rc;
+
+   sigemptyset();
+   sigemptyset();
+   sigaddset(, SIGINT);
+   sigaddset(, SIGTERM);
+
+   sigprocmask(SIG_UNBLOCK, , );
+
+   rc = write_all(pty->master, buf, bufsz);
+
+   sigprocmask(SIG_SETMASK, , NULL);
+   return rc;
 }


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

Bug#1002733: Improve /sbin/runlevel for runlevels 0 and 6

[Andras Korn]

On Sun, Jan 02, 2022 at 11:45:27PM +0100, Lorenzo wrote:

Hi,

> > I'd argue that introducing stricter requirements on the existence and
> > correct mode of /run/runit.reboot that apply over the whole uptime of
> > the system is a more dangerous and invasive change than introducing a
> > new control file with semantics that are obvious and well defined
> > from the beginning.
> > 
> >[ ...]
> > The problem with this is that runit hasn't so far cared about the
> > mode of runit.reboot before stage 3, and people may set runit.reboot
> > to mode 100 early, for example out of a desire to make sure a box
> > will reboot instead of shut down if pid 1 were to receive a CONT
> > signal for any reason.
> 
> Didn't thought about that: I'm not sure is a good idea but I'll
> let the local admin have that call.
> So I'm going with flag files, runit.runlevel.$LAST as you suggested
> in your first message.

Thanks, but that's not quite what I suggested. :)

You now have two flag files and unconditinally use /lib/runit.runlevel.6
first if it exists, even if /lib/runit.runlevel.0 also exists and is newer.

If you want one flag file per runlevel, I'd suggest something like

#!/bin/sh
ls -t /lib/runit.runlevel.[0-9] 2>/dev/null \
| sed 's@.*/@@g;s/^runit\.runlevel\.//;/^[0-9S]$/!d' \
| while read level; do
exec printf "N $level"
done
exec printf 'N 2'

(The ugly sed command makes sure we only print numbers even if some joker
creates a file called literally '/lib/runit.runlevel.[0-9]'. The while loop
makes sure we only execute the first printf if there was actually something
to read.)

I'm not sure this is better than using the first character of the contents
of /lib/runit.runlevel, or making it a symlink instead of a file and using
the first character of its target (we can also implement the former without
depending on head(1)).

(FWIW, I think the technically correct solution would be to have a "runit
runlevel daemon": a simple process that provides a fifo to read the current
runlevel from, and another fifo to write into when the runlevel changes; but
this is overkill as the concept of a 'runlevel' is very rarely needed.)

Best regards,

András

-- 
  Aunt Em. Hate Kansas. Hate you. Took dog. Dorothy.

Bug#1003171: calibre: Calibre version used in debian stable does not start

[Julien Cristau]

Control: tag -1 moreinfo
Control: severity -1 normal

On Wed, Jan 05, 2022 at 04:34:34PM +0100, Georges Gouriten wrote:
>   File "/usr/lib/calibre/calibre/devices/smart_device_app/driver.py", line 
> 2044, in 
> from zeroconf import (BadTypeInNameException, _HAS_A_TO_Z,
> ImportError: cannot import name '_HAS_A_TO_Z' from 'zeroconf' 
> (/usr/local/lib/python3.9/dist-packages/zeroconf/__init__.py)
> 
You've got a zeroconf python package installed in /usr/local, outside
the Debian package management, overriding the packaged version, and
breaking things.

Cheers,
Julien

Bug#1003172: ITP: node-copy-paste -- access to the system clipboard

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: node-copy-paste
  Version : 1.3.0
  Upstream Author : Xavi Ramirez
* URL : https://github.com/xavi-/node-copy-paste
* License : Expat
  Programming Lang: Javascript
  Description : access to the system clipboard

node-copy-paste allows read/write (i.e copy/paste) access to the system
clipboard. It does this by wrapping xclip for Linux, FreeBSD, and OpenBSD.

node-copy-paste is required by node-wikibase-cli which I intend to package.

Remark: This package is to be maintained with Debian Javascript
Maintainers at
   https://salsa.debian.org/js-team/node-copy-paste

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

[Vincent Lefevre]

On 2022-01-05 16:28:21 +0100, Vincent Lefevre wrote:
> On 2022-01-05 16:12:52 +0100, Andrej Shadura wrote:
> > unbound (1.5.7-2) unstable; urgency=medium
> > 
> >   * debian/rules: Disable the resolvconf update.d hook by default
> > 
> > I guess this is it. No idea why, no explanation.
> 
> Probably. In any case, having the hook script installed, but silently
> disabled will confuse many people!
> 
> But I don't see why it should be disabled: if the users do not want
> the DHCP-provided servers as a fallback, they can just configure the
> DHCP client not to accept these servers.

/usr/share/doc/unbound/NEWS.Debian.gz, in 2016:

The resolvconf update.d 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".

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.

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

Bug#1003171: calibre: Calibre version used in debian stable does not start

[Georges Gouriten]

Package: calibre
Version: 5.12.0+dfsg-1+deb11u1
Severity: grave
Tags: a11y patch
Justification: renders package unusable

Dear Maintainer,

The version used in debian stable for Calibre does not seem to work.

It creates the following problem:

Traceback (most recent call last):
  File "/usr/bin/calibre", line 20, in 
sys.exit(calibre())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 73, in calibre
main(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 516, in main
run_main(app, opts, args, gui_debug, si)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 523, in run_main
return run_gui(opts, args, app, gui_debug=gui_debug)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 388, in run_gui
run_gui_(opts, args, app, gui_debug)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 398, in run_gui_
from calibre.gui2.ui import Main
  File "/usr/lib/calibre/calibre/gui2/ui.py", line 32, in 
from calibre.customize.ui import available_store_plugins, interface_actions
  File "/usr/lib/calibre/calibre/customize/ui.py", line 18, in 
from calibre.customize.builtins import plugins as builtin_plugins
  File "/usr/lib/calibre/calibre/customize/builtins.py", line 752, in 
from calibre.devices.smart_device_app.driver import SMART_DEVICE_APP
  File "/usr/lib/calibre/calibre/devices/smart_device_app/driver.py", line 
2044, in 
from zeroconf import (BadTypeInNameException, _HAS_A_TO_Z,
ImportError: cannot import name '_HAS_A_TO_Z' from 'zeroconf' 
(/usr/local/lib/python3.9/dist-packages/zeroconf/__init__.py)

I found a patch from gentoo to fix the problem:

--- driver.ori.py   2022-01-05 16:22:28.978735392 +0100
+++ driver.py   2022-01-05 16:23:00.627144736 +0100
@@ -2041,12 +2041,6 @@
 # Copied from https://github.com/jstasiak/python-zeroconf version 0.28.1
 
 
-from zeroconf import (BadTypeInNameException, _HAS_A_TO_Z,
-  _HAS_ONLY_A_TO_Z_NUM_HYPHEN_UNDERSCORE,
-  _HAS_ASCII_CONTROL_CHARS,
-  _HAS_ONLY_A_TO_Z_NUM_HYPHEN)
-
-
 def service_type_name(type_: str, *, allow_underscores: bool = False) -> str:
 """
 Validate a fully qualified service name, instance or subtype. [rfc6763]
@@ -2087,6 +2081,10 @@
 :param type_: Type, SubType or service name to validate
 :return: fully qualified service name (eg: _http._tcp.local.)
 """
+from zeroconf import (BadTypeInNameException, _HAS_A_TO_Z,
+  _HAS_ONLY_A_TO_Z_NUM_HYPHEN_UNDERSCORE,
+  _HAS_ASCII_CONTROL_CHARS,
+  _HAS_ONLY_A_TO_Z_NUM_HYPHEN)
 if not (type_.endswith('._tcp.local.') or type_.endswith('._udp.local.')):
 raise BadTypeInNameException("Type '%s' must end with '._tcp.local.' 
or '._udp.local.'" % type_)

Best regards

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

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

Versions of packages calibre depends on:
ii  calibre-bin  5.12.0+dfsg-1+deb11u1
ii  dpkg 1.20.9
ii  fonts-liberation22.1.3-1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  libjpeg-turbo-progs  1:2.0.6-4
ii  libjxr-tools 1.1-6+b1
ii  optipng  0.7.7-1+b1
ii  poppler-utils20.09.0-3.1
ii  python3  3.9.2-3
ii  python3-apsw 3.34.0-r1-1
ii  python3-bs4  4.9.3-1
ii  python3-chardet  4.0.0-1
ii  python3-chm  0.8.6-2+b3
ii  python3-css-parser   1.0.6-1
ii  python3-cssselect1.1.0+ds-1
ii  python3-cssutils 1.0.2-3
ii  python3-dateutil 2.8.1-6
ii  python3-dbus 1.2.16-5
ii  python3-feedparser   5.2.1-3
ii  python3-html2text2020.1.16-1
ii  python3-html5-parser 0.4.9-3+b3
ii  python3-html5lib 1.1-3
ii  python3-lxml 4.6.3+dfsg-0.1
ii  python3-markdown 3.3.4-1
ii  python3-mechanize1:0.4.5-2
ii  python3-msgpack  1.0.0-6+b1
ii  python3-netifaces0.10.9-0.2+b3
ii  python3-pil  8.1.2+dfsg-0.3
ii  python3-pkg-resources52.0.0-4
ii  python3-py7zr0.11.3+dfsg-1
ii  python3-pygments 2.7.1+dfsg-2.1
ii  python3-pyparsing2.4.7-1
ii  python3-pyqt55.15.2+dfsg-3
ii  python3-pyqt5.qtsvg  5.15.2+dfsg-3
ii  

Bug#1003170: RM: rabit -- ROM; codebase merged to src:xgboost by upstream

[Mo Zhou]

Package: ftp.debian.org
Severity: normal

Dear ftp-masters,

The src:rabit codebase has been merged into src:xgboost. And I have
uploaded
the latest release of src:xgboost onto unstable. Since src:rabit is
nolonger
used standalone, I'm requesting the removal of it.


Thank you for using reportbug

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

[Vincent Lefevre]

On 2022-01-05 16:12:52 +0100, Andrej Shadura wrote:
> unbound (1.5.7-2) unstable; urgency=medium
> 
>   * debian/rules: Disable the resolvconf update.d hook by default
> 
> I guess this is it. No idea why, no explanation.

Probably. In any case, having the hook script installed, but silently
disabled will confuse many people!

But I don't see why it should be disabled: if the users do not want
the DHCP-provided servers as a fallback, they can just configure the
DHCP client not to accept these servers.

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

Bug#1003134: grilo-plugins: FTBFS: ccache: error: Failed to create directory /sbuild-nonexistent/.cache/ccache/tmp: Permission denied

[Alberto Garcia]

Control: tags -1 pending

On Wed, Jan 05, 2022 at 02:39:47PM +0200, Andrius Merkys wrote:

As I suspected this is a known problem because it potentially affects
any package using sbuilder and meson. See #935817 for more details.

The fix is to use debhelper with the compatibility level set to 13,
which does exactly this:

> > 1. create that directory somewhere else (where?)

This will be included in the next upload:

   
https://salsa.debian.org/berto/grilo-plugins/-/commit/6f6bf34fcdfe74a7f69b2a3cfead3cdfa45d28af

Berto

Bug#1003169: telegram-desktop: ”Internal server error.“ when confirming the phone number

[Julian Schreck]

Package: telegram-desktop
Version: 1.5.11-1
Severity: important

Dear Maintainer,
   * What led up to the situation?
I deleted all active sessions (?) of my Telegram account from my phone under 
”Settings“ → ”Devices“. After entering my phone number in telegram-desktop I 
didn't come forth because ”Internal server error.“ was shown between ”NEXT“ and 
my phone number.

   * What exactly did you do (or not do) that was effective (or ineffective)?
I removed (not purged) telegram-desktop to see whether I had ”a wrong“ package 
version installed, but apt installed the same package again. I used:

$ sudo apt remove telegram-desktop
$ sudo apt install telegram-desktop

   * What was the outcome of this action?
The package ”telegram-desktop“ was removed and installed afterwards in the same 
version.

   * What outcome did you expect instead?
I thought that another version (like telegram-desktop/buster-backports 
2.6.1+ds-1~bpo10+1, e. g.) would be installed, but ”$ sudo apt list -a 
*telegram-desktop*“ didn't change by re-installation.

I tried to log in telegram-web (https://web.telegram.org) and this works as 
expected. Therefore, I don't think it depends on my number or a setting within 
the app itself. But I got a message that this version of Telegram would be 
outdated and it wouldn't be supported in some time (I don't remember the 
original terms).
I don't know for how long this behaviour exists, but it seems to not affect 
telegram-desktop when a user stays logged in/active with Debian (buster). I 
also recognised the same behaviour with Ubuntu 18.04 LTS since December 2021.

Kind regards,
 Julian Schreck

-- System Information:
Debian Release: 10.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF8, LC_CTYPE=de_DE.UTF8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages telegram-desktop depends on:
ii  libavcodec58  10:4.1.8-dmo0+deb10u1
ii  libavformat58 10:4.1.8-dmo0+deb10u1
ii  libavutil56   10:4.1.8-dmo0+deb10u1
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libglib2.0-0  2.58.3-2+deb10u3
ii  liblzma5  5.2.4-1
ii  libminizip1   1.1-8+b1
ii  libopenal11:1.19.1-1
ii  libopus0  1.3-1
ii  libqt5core5a [qtbase-abi-5-11-3]  5.11.3+dfsg1-1+deb10u4
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u4
ii  libqt5gui55.11.3+dfsg1-1+deb10u4
ii  libqt5network55.11.3+dfsg1-1+deb10u4
ii  libqt5widgets55.11.3+dfsg1-1+deb10u4
ii  libssl1.1 1.1.1d-0+deb10u7
ii  libstdc++68.3.0-6
ii  libswresample310:4.1.8-dmo0+deb10u1
ii  libswscale5   10:4.1.8-dmo0+deb10u1
ii  libx11-6  2:1.6.7-1+deb10u2
ii  libxxhash00.6.5-2
ii  qt5-image-formats-plugins 5.11.3-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans  1.11-1

telegram-desktop suggests no packages.

-- no debconf information

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

[Vincent Lefevre]

On 2022-01-05 16:10:50 +0100, Vincent Lefevre wrote:
> On 2022-01-05 15:56:33 +0100, Andrej Shadura wrote:
> I can see:
> 
> zira:~> ll /etc/resolvconf/update.d
> total 12
> -rwxr-xr-x 1 root root 4641 2021-12-28 22:36:01 libc*
> -rw-r--r-- 1 root root  661 2022-01-05 15:36:36 unbound
> 
> While "libc" is executable, "unbound" is not. This may be the cause
> of the bug (the resolvconf(8) man page is not explicit about the
> behavior). I'm going to do some tests.

Indeed, this was the cause of the issue. After making unbound
executable, I now get:

# unbound-control forward
192.168.43.173 192.168.1.1

instead of "off".

However, this is broken: 192.168.1.1 shouldn't be there!!!

FYI:

zira:~> cat /run/resolvconf/interface/NetworkManager
nameserver 127.0.0.1
nameserver 192.168.43.173

Where does 192.168.1.1 come from?

Perhaps /run/resolvconf/interface/original.resolvconf, which contains

# Generated by NetworkManager
nameserver 127.0.0.1
nameserver 192.168.1.1

So, in short, there seems to be 2 bugs:

1. One in unbound: /etc/resolvconf/update.d/unbound is not executable.

2. One in resolvconf, which adds an obsolete original.resolvconf in
   /run/resolvconf/interface (no mention of it in the resolvconf(8)
   man page).

Moreover, the resolvconf(8) man page should be improved about the
executable status of file in "/etc/resolvconf/update.d".

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

Bug#907606: fsck takes hours to complete, just due to slow screen output

[Loorey]

severity 907606 minor
tags 907606 unreproducible
quit

Hey there!

FSCK is the utility for checking the filesystem for Errors and
fixing those, of course after an ungraceful shutdown this operation
can take hours, and of course printing the log will be much faster
than the actual operation, because fsck fixes the system while also
logging, and in the other case you are just reading and printing the
log file.

Loorey 
Public Key Fingerprint:
CDFB 530E 248B F5E7 915B  EA35 CA0D 819B 719A 4DBD

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

[Andrej Shadura]

On Wed, 5 Jan 2022, at 16:10, Vincent Lefevre wrote:
>> By default resolvconf truncates on localhost, so the resulting file
>> doesn’t change. I guess I need to give it a bit more though.
>
> This means that the hook scripts in /etc/resolvconf/update-libc.d
> will not be run. But the hook scripts in /etc/resolvconf/update.d
> should still be run, as documented in the resolvconf(8) man page.
>
> I can see:
>
> zira:~> ll /etc/resolvconf/update.d
> total 12
> -rwxr-xr-x 1 root root 4641 2021-12-28 22:36:01 libc*
> -rw-r--r-- 1 root root  661 2022-01-05 15:36:36 unbound
>
> While "libc" is executable, "unbound" is not. This may be the cause
> of the bug (the resolvconf(8) man page is not explicit about the
> behavior). I'm going to do some tests.

unbound (1.5.7-2) unstable; urgency=medium

  * debian/rules: Disable the resolvconf update.d hook by default

I guess this is it. No idea why, no explanation.

-- 
Cheers,
  Andrej

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

[Vincent Lefevre]

On 2022-01-05 15:56:33 +0100, Andrej Shadura wrote:
> Hi,
> 
> On Wed, 5 Jan 2022, at 15:34, Vincent Lefevre wrote:
> > Oops, I forgot /etc/resolvconf/update.d/unbound, but it isn't run
> > either, even if the nameservers change, e.g. from
> >
> > zira:~> cat /run/resolvconf/interface/NetworkManager
> > nameserver 127.0.0.1
> > nameserver 192.168.43.31
> >
> > to
> >
> > zira:~> cat /run/resolvconf/interface/NetworkManager
> > nameserver 127.0.0.1
> > nameserver 192.168.1.1
> >
> > So this may be a bug in resolvconf after all, since this script
> > is supposed to be run when nameserver information has changed.
> 
> By default resolvconf truncates on localhost, so the resulting file
> doesn’t change. I guess I need to give it a bit more though.

This means that the hook scripts in /etc/resolvconf/update-libc.d
will not be run. But the hook scripts in /etc/resolvconf/update.d
should still be run, as documented in the resolvconf(8) man page.

I can see:

zira:~> ll /etc/resolvconf/update.d
total 12
-rwxr-xr-x 1 root root 4641 2021-12-28 22:36:01 libc*
-rw-r--r-- 1 root root  661 2022-01-05 15:36:36 unbound

While "libc" is executable, "unbound" is not. This may be the cause
of the bug (the resolvconf(8) man page is not explicit about the
behavior). I'm going to do some tests.

> In any case though, you probably shouldn’t prepend localhost in your
> DHCP config, but rely on unbound’s integration instead.

This is needed if resolvconf is not installed. This is not the
cause of the bug, anyway.

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

Bug#1003168: qemu-user-static: fails to run lyx user directory configuation

[Andreas Beckmann]

Package: qemu-user-static
Version: 1:6.1+dfsg-8
Severity: important

Hi,

I have a few foreign architecture chroots (for test-building packages
on an amd64 host) relying on foreign binfmt execution via
qemu-user-static.

mbrola fails to build in this environment (at least arm64, armhf,
ppc64el), I could reduce the failure to this reproducer (which works
fine in an arm64 chroot on a porterbox):

in a minimal sid arm64 chroot run
$ apt-get install lyx
$ t=$(mktemp -d) && lyx -userdir $t -E pdf $t/t.pdf $t/no.lyx
LyX: reconfiguring user directory
support/Systemcall.cpp (276): Systemcall: 'python3 -tt 
"/usr/share/lyx/configure.py" --binary-dir="/usr/bin/"' finished with exit code 
-1
LyX: Done!
LayoutFile.cpp (110): LayoutFileList::Read: unable to find textclass file  
`textclass.lst'.
LayoutFile.cpp (172): LayoutFileList::Read: no textclasses found!
ModuleList.cpp (128): unable to find modules file `lyxmodules.lst'.
No modules will be available.
CiteEnginesList.cpp (173): unable to find cite engines file `citeengines.lst'.
No cite engines will be available.
Error: Document class not found

The layout file:
article
could not be found. A default textclass with default
layouts will be used. LyX will not be able to produce
correct output.
Warning: Cite Engine not available

The cite engine basic has been requested by
this document but has not been found in the list of
available engines. If you recently installed it, you
probably need to reconfigure LyX.

LyX failed to load the following file: /tmp/tmp.DcNdlA0sNJ/no.lyx

But if I run the lyx/configure.py script manually, this works without
error:

$ cd $(mktemp -d) && python3 -tt "/usr/share/lyx/configure.py" 
--binary-dir="/usr/bin/"
checking for a Latex2e program...
+checking for "latex"...  no
+checking for "latex2e"...  no
checking for a DVI postprocessing program...
+checking for "pplatex"...  no
[...]
/usr/share/lyx/layouts/bicaption.module
/usr/share/lyx/layouts/algorithm2e.module
/usr/share/lyx/layouts/InStar.module
done
+checking list of cite engines...
/usr/share/lyx/citeengines/natbib.citeengine
/usr/share/lyx/citeengines/jurabib.citeengine
/usr/share/lyx/citeengines/biblatex.citeengine
/usr/share/lyx/citeengines/biblatex-natbib.citeengine
/usr/share/lyx/citeengines/basic.citeengine
done
+checking list of external templates...
/usr/share/lyx/xtemplates/xfig.xtemplate
/usr/share/lyx/xtemplates/vector_graphics.xtemplate
/usr/share/lyx/xtemplates/raster_image.xtemplate
/usr/share/lyx/xtemplates/pdfpages.xtemplate
/usr/share/lyx/xtemplates/lilypond.xtemplate
/usr/share/lyx/xtemplates/inkscape.xtemplate
/usr/share/lyx/xtemplates/gnumeric.xtemplate
/usr/share/lyx/xtemplates/dia.xtemplate
/usr/share/lyx/xtemplates/chess.xtemplate
done
checking LaTeX configuration...  default values
+checking list of textclasses...
done
+generating default list of packages...
done


Andreas

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

[Andrej Shadura]

Hi,

On Wed, 5 Jan 2022, at 16:04, Vincent Lefevre wrote:
> On 2022-01-05 15:34:38 +0100, Vincent Lefevre wrote:
>> On 2022-01-05 15:22:55 +0100, Andrej Shadura wrote:
>> > On Wed, 5 Jan 2022, at 15:17, Vincent Lefevre wrote:
>> > > What happens with unbound is that /run/resolvconf/resolv.conf
>> > > *always* contains "nameserver 127.0.0.1", i.e. this file never
>> > > changes, even though the DHCP-provided nameservers (which are
>> > > not listed in this file) do. So putting the unbound hook script
>> > > in this /etc/resolvconf/update-libc.d directory is very silly!
>
> /etc/resolvconf/update-libc.d actually just contains the postfix
> hook script, which is correct. The unbound hook script is just in
> /etc/resolvconf/update.d, which is also correct. So the only issue
> is the following, i.e. the fact that the unbound hook script is
> not run when the nameservers provided by DHCP (via NetworkManager)
> change:

>> zira:~> cat /run/resolvconf/interface/NetworkManager
>> nameserver 127.0.0.1
>> nameserver 192.168.43.31
>> 
>> to
>> 
>> zira:~> cat /run/resolvconf/interface/NetworkManager
>> nameserver 127.0.0.1
>> nameserver 192.168.1.1
>> 
>> So this may be a bug in resolvconf after all, since this script
>> is supposed to be run when nameserver information has changed.

Well, this works just fine here — I run resolvconf with NetworkManager and 
connect to all sorts of networks all the time, including those with forced 
login pages and all that stuff. Can you maybe try and debug it?

-- 
Cheers,
  Andrej

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

[Vincent Lefevre]

[Another update to clarify, sorry, I mixed up two related issues, one
about postfix name resolution and one about resolvconf + unbound.]

On 2022-01-05 15:34:38 +0100, Vincent Lefevre wrote:
> On 2022-01-05 15:22:55 +0100, Andrej Shadura wrote:
> > On Wed, 5 Jan 2022, at 15:17, Vincent Lefevre wrote:
> > > What happens with unbound is that /run/resolvconf/resolv.conf
> > > *always* contains "nameserver 127.0.0.1", i.e. this file never
> > > changes, even though the DHCP-provided nameservers (which are
> > > not listed in this file) do. So putting the unbound hook script
> > > in this /etc/resolvconf/update-libc.d directory is very silly!

/etc/resolvconf/update-libc.d actually just contains the postfix
hook script, which is correct. The unbound hook script is just in
/etc/resolvconf/update.d, which is also correct. So the only issue
is the following, i.e. the fact that the unbound hook script is
not run when the nameservers provided by DHCP (via NetworkManager)
change:

> Oops, I forgot /etc/resolvconf/update.d/unbound, but it isn't run
> either, even if the nameservers change, e.g. from
> 
> zira:~> cat /run/resolvconf/interface/NetworkManager
> nameserver 127.0.0.1
> nameserver 192.168.43.31
> 
> to
> 
> zira:~> cat /run/resolvconf/interface/NetworkManager
> nameserver 127.0.0.1
> nameserver 192.168.1.1
> 
> So this may be a bug in resolvconf after all, since this script
> is supposed to be run when nameserver information has changed.

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

[Andrej Shadura]

Hi,

On Wed, 5 Jan 2022, at 15:34, Vincent Lefevre wrote:
> Oops, I forgot /etc/resolvconf/update.d/unbound, but it isn't run
> either, even if the nameservers change, e.g. from
>
> zira:~> cat /run/resolvconf/interface/NetworkManager
> nameserver 127.0.0.1
> nameserver 192.168.43.31
>
> to
>
> zira:~> cat /run/resolvconf/interface/NetworkManager
> nameserver 127.0.0.1
> nameserver 192.168.1.1
>
> So this may be a bug in resolvconf after all, since this script
> is supposed to be run when nameserver information has changed.

By default resolvconf truncates on localhost, so the resulting file doesn’t 
change. I guess I need to give it a bit more though.

In any case though, you probably shouldn’t prepend localhost in your DHCP 
config, but rely on unbound’s integration instead.

-- 
Cheers,
  Andrej

Bug#1003167: RFP: virtnbdbackup: Backup utiliy for Libvirt kvm / qemu with Incremental backup support.

[Michael Ablassmeier]

Package: wnpp
Severity: wishlist


* Package name: virtnbdbackup
  Version : 0.35
  Upstream Author : Michael Ablassmeier 
* URL : https://github.com/abbbi/virtnbdbackup
* License : GPL 3.0
  Programming Lang: Python
  Description : Backup utiliy for Libvirt kvm / qemu with Incremental 
backup support.

Backup utility for libvirt, using the latest changed block tracking features.
Create online, thin provisioned full and incremental backups of your kvm/qemu
virtual machines.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Tue, Jan 04, 2022 at 06:46:46PM -0500, Andres Salomon wrote:
> On 1/4/22 15:15, Mattia Rizzolo wrote:
> > On Tue, Jan 04, 2022 at 02:50:20PM -0500, Andres Salomon wrote:
> > > I pushed a commit to the skip-a11y-checks branch, please give that a try. 
> > > I
> > > need to take a look at other distributions that are shipping chromium to 
> > > see
> > > if they're just disabling DCHECKs outright, or what.
> 
> Just took a look at fedora, arch, and ungoogle-chromium debian packaging.
> They're all setting is_official_build=true, which completely disables those
> DCHECKs. We should probably set it like that as well, although the
> dcheck_is_configurable=true thing that I added to the skip-a11y-checks
> branch should at least allow the DCHECKs to not be fatal - so there's no
> need to restart your build.


So, this one at least didn't crash on me as soon as I started.
Also, it looks like the saved passwords that went away came back, so I
reckon perhaps the local storage format changed in the upgrade, so v93
wasn't able to see them anymore, or something similar.

I suppose I'll see how it goes in the coming few days.


Thank you for your work!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

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

[Vincent Lefevre]

On 2022-01-05 15:34:38 +0100, Vincent Lefevre wrote:
> On 2022-01-05 15:22:55 +0100, Andrej Shadura wrote:
> > Having looked at it again, it seems Thomas, the original author of
> > resolvconf, have actually included a workaround for your use case.
> > Set TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no in
> > /etc/default/resolvconf, and it should do the thing.
> 
> Well, the bug needs to be fixed to avoid the workaround.
> Or the workaround should be the default.

About the TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS
documentation, the resolvconf(8) man page says:

  The advantage of truncating the nameserver list after a loopback
  address is that doing so inhibits unnecessary changes to resolv.conf
  and thus reduces the number of instances in which the update-libc.d/
  scripts have to be run. When an interface is brought up or down the
  local caching nameserver that listens on the loopback address is
  still informed of the change and adapts accordingly; the clients of
  ^^^
  the resolver which use the local caching nameserver do not need to
  be notified of the change. A disadvantage of this mode of operation
  is that applications have no secondary or tertiary nameserver
  address to fall back on should the local caching nameserver crash.
  Insofar as a local nameserver crash can be regarded as an unlikely
  event, this is a relatively minor disadvantage.

The issue I have is that the local caching nameserver (unbound)
is *not* informed of the change, because resolvconf does not run
/etc/resolvconf/update.d/unbound, contrary to what is documented.
The point of TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS is
to have a fallback in case of the crash of the local caching
nameserver, but there is no crash in my case, i.e. setting
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS to "no" should
not be needed in my case.

-- 
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-01-05 15:22:55 +0100, Andrej Shadura wrote:
> Hi,
> 
> On Wed, 5 Jan 2022, at 15:17, Vincent Lefevre wrote:
> > What happens with unbound is that /run/resolvconf/resolv.conf
> > *always* contains "nameserver 127.0.0.1", i.e. this file never
> > changes, even though the DHCP-provided nameservers (which are
> > not listed in this file) do. So putting the unbound hook script
> > in this /etc/resolvconf/update-libc.d directory is very silly!

Oops, I forgot /etc/resolvconf/update.d/unbound, but it isn't run
either, even if the nameservers change, e.g. from

zira:~> cat /run/resolvconf/interface/NetworkManager
nameserver 127.0.0.1
nameserver 192.168.43.31

to

zira:~> cat /run/resolvconf/interface/NetworkManager
nameserver 127.0.0.1
nameserver 192.168.1.1

So this may be a bug in resolvconf after all, since this script
is supposed to be run when nameserver information has changed.

> Having looked at it again, it seems Thomas, the original author of
> resolvconf, have actually included a workaround for your use case.
> Set TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no in
> /etc/default/resolvconf, and it should do the thing.

Well, the bug needs to be fixed to avoid the workaround.
Or the workaround should be the default.

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

Bug#1003166: RM: gnome-shell-extension-multi-monitors -- ROM; rc buggy, not maintained upstream

[Jonathan Carter]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: j...@debian.org

Please remove gnome-shell-extension-multi-monitors from unstable,
it no longer works with gnome-shell in testing/unstable, and
there is no activity to fix this upstream.

thanks,

-Jonathan

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

[Andrej Shadura]

Hi,

On Wed, 5 Jan 2022, at 15:17, Vincent Lefevre wrote:
> What happens with unbound is that /run/resolvconf/resolv.conf
> *always* contains "nameserver 127.0.0.1", i.e. this file never
> changes, even though the DHCP-provided nameservers (which are
> not listed in this file) do. So putting the unbound hook script
> in this /etc/resolvconf/update-libc.d directory is very silly!

Having looked at it again, it seems Thomas, the original author of resolvconf, 
have actually included a workaround for your use case.
Set TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no in 
/etc/default/resolvconf, and it should do the thing.

-- 
Cheers,
  Andrej

Bug#679905: 2021.8+ds2-1 - Pending

[Andrius Merkys]

On 2022-01-05 13:37, Neil Williams wrote:
> On Fri, 17 Dec 2021 12:57:48 +0200 Andrius Merkys 
> wrote:
>> I see you have switched from having all libraries in cctbx/
>> subdirectory [1] to public libs and libdevel locations. Personally I
>> do think Debian as a downstream should be setting SONAMEs. This does
>> not seem to be forbidden by the policy, but in case the upstream
>> introduces SONAMEs, clashes may occur. Moreover, caring for ABI
>> compatibility is a lot of work.
> 
> When trying to package libobjcryst, it became obvious that a SONAME had
> to be applied to cctbx, just as libobjcryst itself needs to patch in a
> SONAME. It is an extra amount of work but C++ symbols based on a
> package using lots of templates are fuzzy at best and with so many
> different modules in cctbx, the only practical way to handle it seems
> to be a new SONAME each time. The header files are also problematic. We
> might be able to restrict SONAME changes to upstream versions which
> make changes to the header files included in libcctbx-dev rather than
> every new upstream release. Until we've got cctbx through NEW, it is
> going to be hard to tell.

Understood. So it boils down to uploading to NEW with each and every
upstream release. But I guess we will have to live with that as there
are no better alternatives.

>> On a separate thread, I managed to package reduce [2] locally.
>> However, as you have also noted it, the name of source, binary and
>> executable is problematic. Maybe it is worth trying to talk to
>> upstream about renaming it to avoid clashes.
> 
> Maybe package it as pdb-reduce or pdb-hydrogen-reduce ?
> 
> /usr/bin/reduce does not exist in Debian yet but it may be worth
> packaging the script as pdb-reduce with a note in README.Debian -
> anyone switching from using the upstream build to Debian packages will
> need to make other changes anyway.

pdb-hydrogen-reduce sounds good to me.

>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679905#98
>> [2] https://github.com/rlabduke/reduce

Best,
Andrius

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

[Vincent Lefevre]

On 2022-01-05 15:11:04 +0100, Vincent Lefevre wrote:
> After testing, /etc/resolvconf/update.d/unbound isn't run at all:
> I've added "logger /etc/resolvconf/update.d/unbound" at the beginning
> of this script, and it doesn't appear in the logs.
> 
> So this seems to be a resolvconf bug.

Well, perhaps not. The resolvconf(8) man page says:

  When nameserver information is updated, the script
  /etc/resolvconf/update.d/libc generates a new version of the
  resolver configuration file, /run/resolvconf/resolv.conf, as
  described below. If the new version of the file differs from
  the previously generated one then the hook scripts found in
  /etc/resolvconf/update-libc.d/ are executed.

What happens with unbound is that /run/resolvconf/resolv.conf
*always* contains "nameserver 127.0.0.1", i.e. this file never
changes, even though the DHCP-provided nameservers (which are
not listed in this file) do. So putting the unbound hook script
in this /etc/resolvconf/update-libc.d directory is very silly!

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

Bug#1003165: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x

[Neil Williams]

Source: scikit-learn
Version: 0.23.2-5
Severity: serious
Tags: ftbfs
Justification: Fails to build from source
X-Debbugs-Cc: codeh...@debian.org

The new version of scikit-learn has not migrated to testing because it
has not built on all required architectures. This is now affecting other
packages as the version of scikit-learn in testing is too old to allow
reverse dependencies to build. e.g. opentsne

https://buildd.debian.org/status/package.php?p=scikit-learn

This error crops up in the in-build tests:

=== FAILURES ===
[31m[1m [doctest] sklearn.ensemble._weight_boosting.AdaBoostRegressor 
_[0m
1004 Examples
1005 
1006 >>> from sklearn.ensemble import AdaBoostRegressor
1007 >>> from sklearn.datasets import make_regression
1008 >>> X, y = make_regression(n_features=4, n_informative=2,
1009 ...random_state=0, shuffle=False)
1010 >>> regr = AdaBoostRegressor(random_state=0, n_estimators=100)
1011 >>> regr.fit(X, y)
1012 AdaBoostRegressor(n_estimators=100, random_state=0)
1013 >>> regr.predict([[0, 0, 0, 0]])
Expected:
array([4.7972...])
Got:
array([5.74049295])




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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 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

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

[Vincent Lefevre]

On 2022-01-05 10:04:38 +0100, Andrej Shadura wrote:
> I just wanted to clarify: unbound already puts itself (as 127.0.0.1)
> first in resolvconf configuration. You should not need to modify you
> DHCP client’s configuration to add it once more. Unbound’s
> resolvconf integration should theoretically filter 127.0.0.1 out and
> tell unbound to forward its requests to your network’s name servers,
> but for some reason it doesn’t. Or maybe you’ve modified unbound’s
> configuration to disallow that.

After testing, /etc/resolvconf/update.d/unbound isn't run at all:
I've added "logger /etc/resolvconf/update.d/unbound" at the beginning
of this script, and it doesn't appear in the logs.

So this seems to be a resolvconf bug.

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

Bug#1003164: dpkg-dev - dpkg-buildpackage redefined terse as quiet

[Bastian Blank]

Package: dpkg-dev
Version: 1.21.1
Severity: important

Moin

dpkg-buildpackage started to feed "-s" into MAKEFLAGS if the "terse"
build option is set.  This redefines terse as quiet, as all output of
make is silenced.  I would see that in violation the policy definition
of the terse option and make it even unusable.

| terse
|   This tag means that the package build will be less verbose than
|   default. For example, debian/rules might pass options to the package’s
|   configure script that cause the compiler to produce less output.

Please revert that.

Bastian

-- Package-specific info:
System tainted due to merged-usr-via-aliased-dirs.

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg-dev depends on:
ii  binutils  2.37-10.1
ii  bzip2 1.0.8-5
ii  libdpkg-perl  1.21.1
ii  make  4.3-4.1
ii  patch 2.7.6-7
ii  perl  5.32.1-6
ii  tar   1.34+dfsg-1
ii  xz-utils  5.2.5-2

Versions of packages dpkg-dev recommends:
ii  build-essential  12.9
ii  fakeroot 1.25.3-1.1
ii  gcc [c-compiler] 4:11.2.0-2
ii  gcc-10 [c-compiler]  10.3.0-13
ii  gcc-11 [c-compiler]  11.2.0-13
ii  gnupg2.2.27-2
ii  gpgv 2.2.27-2
pn  libalgorithm-merge-perl  

Versions of packages dpkg-dev suggests:
pn  debian-keyring  

-- no debconf information

Bug#894126: help2man: Problem with encoding kk_KZ.RK1048

[Marcus Hardt]

I'm experiencing the same problem every now and then, because reprotest
uses this encoding to verify reproducible builds.

The problem seems to be triggered by setting this environment:

LANG=kk_KZ.RK1048
LANGUAGE=kk_KZ.RK1048:fr


Cheers,
-- 
Marcus.


signature.asc
Description: PGP signature

Bug#1003163: paprefs: Fix for #531251 doesn't handle current path

[Yves-Alexis Perez]

Package: paprefs
Version: 1.1-2
Severity: important

Hi,

I hesitated unarchiving/reopening #531251 (which is more than ten years
old), but in the end opened a new one because maybe the bug could
actually be fixed in pulseaudio and modules here.

I've justed installed paprefs and pulseaudio-module-raop and noticed the
greyed out boxes in the Network Access tab. I looked at #531251 and done
an strace, and noticed it tried to access
`/usr/lib/pulse-15.0/modules/module-esound-protocol-tcp.so` while the
path on my system is /usr/lib/pulse-15.0+dfsg1. So it seems either the
patch in paprefs is not entirely correct, or maybe the prefix was added
later or something.

After adding a symlink from /usr/lib/pulse-15.0+dfsg1 to
/usr/lib/pulse-15.0 the boxes are available in paprefs.

Regards,

-- 
Yves-Alexis

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 paprefs depends on:
ii  gnome-icon-theme 3.12.0-4
ii  libatkmm-1.6-1v5 2.28.2-1
ii  libc62.33-1
ii  libgcc-s111.2.0-13
ii  libglib2.0-0 2.70.2-1
ii  libglibmm-2.4-1v52.66.2-1
ii  libgtk-3-0   3.24.31-1
ii  libgtkmm-3.0-1v5 3.24.5-1
ii  libpulse015.0+dfsg1-3
ii  libsigc++-2.0-0v52.10.4-2
ii  libstdc++6   11.2.0-13
ii  pulseaudio-module-gsettings  15.0+dfsg1-3
ii  pulseaudio-module-zeroconf   15.0+dfsg1-3

paprefs recommends no packages.

paprefs suggests no packages.

-- no debconf information

Bug#1003162: Add support for Parallels/hds virtual disk image format

[MichaIng]

Package: qemu-utils
Version: 1:6.1+dfsg-8+b2

Aiming to automate VM image creation, I recognised that on Debian, 
qemu-img does not support the Parallels virtualizer hds virtual disk 
image format. Generally it seems to be supported by QEMU, like here on 
RHEL 7: 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-using_qemu_img-supported_qemu_img_formats


I guess it is a build flag, or does it have to do with licensing? 
Generally, it would be great if Debian could add support for 
Parallels/hds to qemu-utils/qemu-img, when required via contrib or 
non-free components.


Best regards,

Micha

Bug#999155: RC bug in mm and zlib

[Mark Brown]

On Wed, Jan 05, 2022 at 12:57:47PM +0100, Thorsten Alteholz wrote:

> are you already working on an update of mm and zlib? Or do you need some
> help?

They're utterly trivial, I'll get round to them at some point when I do
a batch run through all my packages.  It'd be more effort to integrate
something.


signature.asc
Description: PGP signature