Bug#987441: bug in Debian 11 RC Installer

[Cyril Brulebois]

Luna Jernberg  (2021-05-03):
> Gets stuck before it tries to download package from the mirrors

Thanks, Luna.

This is Swedish, right?

It seems very likely to be yet another occurrence of this bug, that
usually triggers a title getting displayed but nothing else:
  https://bugs.debian.org/987587

I'm currently working on it.

Thanks for your report (we usually prefer people use reportbug to submit
bug reports, but your mail to the list was fine, especially since this
issue can easily be associated with existing reports).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987947: unblock (pre-approval): gtk+3.0/3.24.24-4

[Cyril Brulebois]

Hi Simon,

Simon McVittie  (2021-05-02):
> [ Risks ]
> This is obviously an important key package that lots of things depend
> on. Technically it also has a udeb, although I'm fairly sure d-i is
> still using GTK 2 and so the udeb is not actually used for anything
> yet.

That's absolutely correct: no objections to anything you would like to
update on your side.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987441: bug in Debian 11 RC Installer

[Luna Jernberg]

Gets stuck before it tries to download package from the mirrors

On Mon, May 3, 2021 at 7:40 AM Cyril Brulebois  wrote:

> Hi,
>
> Luna Jernberg  (2021-05-03):
> > i found a  bug when using the graphical installer in Virtualbox under
> > Ubuntu, and the step to show to package mirrors, don't show up, but it
> > works in the text installer
>
> Any chance you could attach a screenshot when that happens? Thanks.
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#987853: wireshark: CVE-2021-22207

[Salvatore Bonaccorso]

Hi Balint,

On Sun, May 02, 2021 at 10:09:13PM +0200, Balint Reczey wrote:
> Control: tags -1 pending confirmed
> 
> Hi Salvatore,
> 
> On Fri, Apr 30, 2021 at 10:57 PM Salvatore Bonaccorso  
> wrote:
> >
> > Source: wireshark
> > Version: 3.4.4-1
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://gitlab.com/wireshark/wireshark/-/issues/17331
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> >
> > Hi,
> >
> > The following vulnerability was published for wireshark.
> >
> > CVE-2021-22207[0]:
> > | Excessive memory consumption in MS-WSP dissector in Wireshark 3.4.0 to
> > | 3.4.4 and 3.2.0 to 3.2.12 allows denial of service via packet
> > | injection or crafted capture file
> >
> >
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> I've prepared the next upload including this fix at
> https://salsa.debian.org/debian/wireshark/-/commits/debian/master but
> have not uploaded it because I did not consider this vulnerability
> important enough to ask an exception for the freeze.
> 
> I will happily do the upload if it gets unblocked.

Thanks. I do agree, the issue itself might not be important enough,
and in fact for buster we marked it postponed, which can be fixed in a
future update.

Advantage if it get's unblocked would be that we can start bullseye
with a "fresh"/clean state (unless a next round appears between now
and the actual bullseye release).

Thanks for your work on wireshark!

Regards,
Salvatore

Bug#922666: confirmed bug report

[Salvatore Bonaccorso]

Control: found -1 5.10.24-1

Hi Antoine,

On Sun, May 02, 2021 at 08:22:07PM -0400, Antoine Beaupré wrote:
> On 2021-05-01 07:59:01, Salvatore Bonaccorso wrote:
> > Hi Antoine
> >
> > On Fri, Apr 30, 2021 at 07:34:04PM -0400, Antoine Beaupré wrote:
> >> On 2021-04-30 21:04:29, Salvatore Bonaccorso wrote:
> >> > Control: tags -1 + moreinfo
> >> >
> >> > Hi Tollef, Antoine,
> >> >
> >> > On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote:
> >> >> Control: forcemerge 922666 928189
> >> >> Control: severity 922666 important
> >> >> Control: tags 922666 +patch +confirmed
> >> >> 
> >> >> I also see a regression with touchpads and trackpoint on a Thinkpad E431
> >> >> after upgrading from Debian stretch to buster. My research indicates
> >> >> this is a kernel regression, as yet to be fixed.
> >> >> 
> >> >> This is the result of my research, as available online at:
> >> >> 
> >> >> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep
> >> >> 
> >> >> On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
> >> >> freezes after sleep. Keyboard still works but not mouse until a
> >> >> reboot.
> >> >> 
> >> >> There's [bug 922666][] in Debian buster, without a fix. It also says
> >> >> it eventually recovers, which is not our experience. Possible dupe is
> >> >> [bug 928189][].
> >> >> 
> >> >> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
> >> >> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666
> >> >> 
> >> >> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
> >> >> which proposes the following workarounds:
> >> >> 
> >> >>  * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method 
> >> >> disabled`
> >> >> 
> >> >>  * A .service file:
> >> >> 
> >> >> # /etc/systemd/system/touchpad-sleep.service
> >> >> # restore touchpad on suspend
> >> >> 
> >> >> [Unit]
> >> >> Description=Restore Touchpad on suspend
> >> >> Before=sleep.target
> >> >> StopWhenUnneeded=yes
> >> >> 
> >> >> [Service]
> >> >> #Type=oneshot
> >> >> Type=idle
> >> >> RemainAfterExit=yes
> >> >> ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
> >> >> /sys/bus/pci/drivers/i801_smbus/unbind'
> >> >> ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
> >> >> /sys/bus/pci/drivers/i801_smbus/bind'
> >> >> 
> >> >> [Install]
> >> >> WantedBy=sleep.target
> >> >> 
> >> >>  * "Maybe try xserver-xorg-input-evdev instead of 
> >> >> xserver-xorg-input-libinput?"
> >> >> 
> >> >>  * reloading `psmouse`:
> >> >>  
> >> >> sudo modprobe -r psmouse
> >> >> sudo modprobe psmouse
> >> >> 
> >> >>  * "`modprobe i2c-i801` after removing it from the `blacklist.conf` 
> >> >> seems to solve the issue."
> >> >> 
> >> >>  * whatever this is:
> >> >>  
> >> >> # echo 1 > /sys/devices/rmi4-00/nosleep
> >> >> 
> >> >>  * "Anyone who still affected by touchpad issues after S3. Please
> >> >>switch back to suspend-to-idle in BIOS if s2idle is
> >> >>supported. ThinkPad Carbon 6th and Yoga 3rd do support
> >> >>suspend-to-idle in BIOS->config->power menu."
> >> >> 
> >> >> [bug 1791427]: 
> >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427
> >> >> 
> >> >> There's also [bug 1442699][] in Fedora, which suggests those
> >> >> workarounds:
> >> >> 
> >> >>  * another module reload:
> >> >>  
> >> >> sudo rmmod i2c_hid
> >> >> sudo modprobe i2c_hid
> >> >> 
> >> >>  * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing
> >> >>and this issue seems to have been resolved (for me)."
> >> >> 
> >> >>  * another `/proc` hack:
> >> >>  
> >> >> echo -n "reconnect" >  /sys/bus/serio/devices/serio1/drvctl
> >> >> 
> >> >>  * "The `psmouse.synaptics_intertouch=0` workaround still works for me."
> >> >> 
> >> >> [bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699
> >> >> 
> >> >> Also related is this [libinput bug][] that's closed as "not our bug"
> >> >> because they claim it's a bug in the kernel.
> >> >> 
> >> >> [libinput bug]: https://bugs.freedesktop.org/show_bug.cgi?id=103149
> >> >> 
> >> >> There are [two][] [patches][] on the Linux kernel which apparently fix 
> >> >> the
> >> >> issue, still pending approval:
> >> >> 
> >> >> [two]: https://lkml.org/lkml/2019/2/20/700
> >> >> [patches]: https://lkml.org/lkml/2019/2/20/701
> >> >> 
> >> >> Possibly related: https://lkml.org/lkml/2016/8/18/134
> >> >> 
> >> >> [5.1rc7][] shipped two fixes against the `synaptics-rmi4` module. A
> >> >> [pull request][] has been merged in mainline with two other fixes on
> >> >> the module./ [5.0.11][] also has fixes on the module. It's clearly a
> >> >> regression from Debian stretch (kernel 4.9) since it was working fine
> >> >> before.
> >> >> 
> >> >> Possibly related, [two-finger scrolling bug in Ubuntu][], which
> >> >> identifies [this commit][] as 

Bug#987979: RFP: infamous-plugins -- Infamous Plugins is a collection of open-source LV2 plugins

[Fernando Toledo]

Package: wnpp
Severity: wishlist

* Package name: infamous-plugins
  Version : 0.3.0
  Upstream Author : Spencer Jackson
* URL : http://ssj71.github.io/infamousPlugins
* License : GPL-2
  Programming Lang: C, C++
  Description : Infamous collection of open-source LV2 plugins

These are audio plugins in the LV2 format, developed for linux. Most are
suitable for live use (exceptions are noted in the description).

1b. infamous-rule
2. Envelope Follower
2b. Envelope Follower CV
3. Hip2B
4. cheap distortion
5. stuck
5b. stuck stacker
6. power cut
7. power up
8. ewham
9. duffer
10. lushlife
11. playback modulation shifter
12. mindi
13. octolo

Bug#985870: [debian-mysql] Bug#985870: mariadb-server-10.5: unowned files after purge (policy 6.8, 10.8): /usr/share/mysql/debian-10.5.flag

[Otto Kekäläinen]

Hello!

Upstream packaging seems to have introduced this line 9 years ago:
https://github.com/MariaDB/server/commit/cfd4fcb0bc3d469dfca74dae30d17250d65fdd91#diff-733e7d6cfbf529c0530e7b06c97071e2c7dafa6d8b673495fecdce3f1d57015bR139

> # To avoid downgrades.
> touch $mysql_statedir/debian-5.5.flag

Seems very unnecessary for me. The flag thing is used by both MariaDB
and MySQL packaging in Debian/Ubuntu, and it is put in the
/var/lib/mysql datadir. This statedir seems completely unnecessary. I
would guess you can remove the 'touch $mysql_statedir'.

Bug#987978: tor: use /usr/sbin/nologin as the system user's shell

[Christoph Anton Mitterer]

Package: tor
Version: 0.4.5.7-1
Severity: wishlist


Hi.

Hey.

It seems most system users are created with /usr/sbin/nologin as shell,
which gives some nice message when trying to login, unlike /bin/false.


Perhaps you might want to change that, too.
If so, please don't forget to update it also for existing installations.
My installation here still has /bin/bash (which I guess was used previously)
set... probably not so good for a system daemon user :D


Cheers,
Chris.

Bug#987977: Silly shebang "#!./perl -w"

[Trent W. Buck]

Package: perl-modules-5.32
Version: 5.32.1-3
Severity: wishlist
File: /usr/share/perl/5.32.1/ExtUtils/Miniperl.pm

While auditing shebangs for something else, I found this silly one:

$ sed -n 1p /usr/share/perl/*/ExtUtils/Miniperl.pm
#!./perl -w

Can you get upstream to either remove it or change it to something sensible?

It doesn't really *matter*, it just looks so silly I had to say something!




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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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

Versions of packages perl-modules-5.32 depends on:
ii  dpkg   1.20.9
ii  perl-base  5.32.1-3

Versions of packages perl-modules-5.32 recommends:
ii  perl  5.32.1-3

perl-modules-5.32 suggests no packages.

-- no debconf information

Bug#987976: mediawiki: autopkgtests are missing restrictions and dependencies

[Tobias Wiese]

Source: mediawiki
Version: 1:1.35.2-1
Severity: minor
Tags: patch

Dear Maintainer,

The install-* autopkgtest require the start of services and should
therefore be tagged with the isolation-container restriction.
They also use the systemctl command from the systemd package which is
missing in the depends field.

I also think that the lint test should be marked with the superficial
restriction, as it doesn't test the installed packages functionality,
but its code style.

-- 
Tobias Wiese
PGP KEY: https://tobiaswiese.com/pgp.asc
PGP FPR: E1A7A8879BAD75B42D63F3310F067C2DD70E89A0
From 872fc478fc3268fd9874230d613ad3dc8651168d Mon Sep 17 00:00:00 2001
From: Tobias Wiese 
Date: Mon, 3 May 2021 04:08:42 +0200
Subject: [PATCH 1/2] d/tests: update test restrictions

Tag the install-* tests as isolation-container, because they require
starting services (apache2 and most of them the database server).

Tag the lint test as superficial, because it doesn't test the
packages functionality.

Signed-off-by: Tobias Wiese 
---
 debian/tests/control | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index 89fc86bc..9e4f79b3 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,26 +1,27 @@
 Tests: lint
 Depends: @, php-cli, jsonlint
+Restrictions: superficial
 
 Tests: install-sqlite
 Depends: @, php-cli, php-sqlite3, curl, sudo, apache2
-Restrictions: needs-root, allow-stderr
+Restrictions: needs-root, allow-stderr, isolation-container
 
 # default-mysql
 Tests: install-mysql
 Depends: @, php-cli, php-mysql, default-mysql-server, curl, sudo, apache2
-Restrictions: needs-root, allow-stderr
+Restrictions: needs-root, allow-stderr, isolation-container
 
 # mysql
 Tests: install-mysql
 Depends: @, php-cli, php-mysql, mysql-server, curl, sudo, apache2
 # Don't fail when mysql-server isn't in Debian testing
-Restrictions: needs-root, skip-not-installable, allow-stderr
+Restrictions: needs-root, skip-not-installable, allow-stderr, isolation-container
 
 # mariadb
 Tests: install-mysql
 Depends: @, php-cli, php-mysql, mariadb-server, curl, sudo, apache2
-Restrictions: needs-root, allow-stderr
+Restrictions: needs-root, allow-stderr, isolation-container
 
 Tests: install-postgresql
 Depends: @, php-cli, php-pgsql, postgresql, curl, sudo, apache2
-Restrictions: needs-root, allow-stderr
+Restrictions: needs-root, allow-stderr, isolation-container
-- 
2.29.2

From 0dfa20aadb525266f23ee3ccf9bcced12bc4f750 Mon Sep 17 00:00:00 2001
From: Tobias Wiese 
Date: Mon, 3 May 2021 04:23:05 +0200
Subject: [PATCH 2/2] d/tests: Add systemd as test dependency

The install-* tests require systemctl which is provided by the systemd
package.

Signed-off-by: Tobias Wiese 
---
 debian/tests/control | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index 9e4f79b3..7dd837d6 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -3,25 +3,25 @@ Depends: @, php-cli, jsonlint
 Restrictions: superficial
 
 Tests: install-sqlite
-Depends: @, php-cli, php-sqlite3, curl, sudo, apache2
+Depends: @, php-cli, php-sqlite3, curl, sudo, apache2, systemd
 Restrictions: needs-root, allow-stderr, isolation-container
 
 # default-mysql
 Tests: install-mysql
-Depends: @, php-cli, php-mysql, default-mysql-server, curl, sudo, apache2
+Depends: @, php-cli, php-mysql, default-mysql-server, curl, sudo, apache2, systemd
 Restrictions: needs-root, allow-stderr, isolation-container
 
 # mysql
 Tests: install-mysql
-Depends: @, php-cli, php-mysql, mysql-server, curl, sudo, apache2
+Depends: @, php-cli, php-mysql, mysql-server, curl, sudo, apache2, systemd
 # Don't fail when mysql-server isn't in Debian testing
 Restrictions: needs-root, skip-not-installable, allow-stderr, isolation-container
 
 # mariadb
 Tests: install-mysql
-Depends: @, php-cli, php-mysql, mariadb-server, curl, sudo, apache2
+Depends: @, php-cli, php-mysql, mariadb-server, curl, sudo, apache2, systemd
 Restrictions: needs-root, allow-stderr, isolation-container
 
 Tests: install-postgresql
-Depends: @, php-cli, php-pgsql, postgresql, curl, sudo, apache2
+Depends: @, php-cli, php-pgsql, postgresql, curl, sudo, apache2, systemd
 Restrictions: needs-root, allow-stderr, isolation-container
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#987441: Fwd: bug in Debian 11 RC Installer

[Luna Jernberg]

-- Forwarded message -
From: Luna Jernberg 
Date: Mon, May 3, 2021 at 4:25 AM
Subject: bug in Debian 11 RC Installer
To: , , Martin Jernberg <
droidbit...@gmail.com>


Hello!

i found a  bug when using the graphical installer in Virtualbox under
Ubuntu, and the step to show to package mirrors, don't show up, but it
works in the text installer

Bug#987975: unblock: mksh/59c-6

[Thorsten Glaser]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de

Please unblock package mksh

Give it a few days in sid first, please, but I’m filing the
unblock request right now already so it has more time for review.

[ Reason ]
These are cherry-picks, reduced to the minimum necessary (e.g.
less RCS ID churn, some changes that aren’t _that_ crucial removed
or modified in a way to make the diff smaller), that address the
following things:
• some memory leaks
• harden conversion of imported variables to integer, similar to
  Perl’s “taint”; this is basically what ksh93 had as CVE-2019-14868
• fix lexer token state corruption when switching back and forth
  between command line editing and lexing (could be triggered by an
  editing command reliably)
• fix escaping (typeset -p; ${var@Q}) and globbing (tab completion,
  pattern expansion) for pathnames which contain escaped or unescaped
  curly braces, tilde, \x02
Furthermore because this is a new sourceful upload the buildds will
rebuild this against latest linux-libc-dev and klibc (I checked, the
unblock on the latter was already granted) which is a good thing,
especially given klibc’s malloc fixes.

The attached diff is a debdiff in which the single-debian-patch
was replaced by a diff between the patched extracted trees to
increase legibility, as usual. To aid in mapping the patch hunks
to the topics above I will comment on them here:

 mksh-59c/debian/changelog |   25 +

- change documentation

 mksh_59c-6/check.t|   37 +++

- changed version date to 2021/05/03
- new test for the “taint” checks

 mksh_59c-6/edit.c |   73 ++-

- only escaping-related changes

 mksh_59c-6/eval.c |6 +--

- memory leak fixes: s/global(arrayname(x))/arraybase(x)/

 mksh_59c-6/misc.c |1 

- another memory leak, in command line option -T processing

 mksh_59c-6/mksh.1 |4 +-

- documentation for the escaping-related changes

 mksh_59c-6/mksh.faq   |   18 -

- remove note about evaluate-region being broken (lexer state thing)
- documentation for the “taint” thing

 mksh_59c-6/sh.h   |   14 +++

- version number
- escaping-related changes
- arrayname ⇒ arraybase (prototype)

 mksh_59c-6/shf.c  |2 -

- escaping-related

 mksh_59c-6/syn.c  |4 +-

- lexer state issue

 mksh_59c-6/var.c  |   86 ++

- the @@ -938,7 +944,7 @@ hunk and the last one are memory
  leak-related (arrayname ⇒ arraybase; arraybase implementation
  free()s the temporary variable after calling global() properly
  and uses a stack buffer for small values to reduce memory
  allocator pressure)
- all others: “taint”: factor out checking a string for being
  a valid integer from getint() to getnum() and call getnum()
  when converting a variable that was imported from the environment
  to integer to check if it is purely numeric

 11 files changed, 200 insertions(+), 70 deletions(-)


[ Impact ]
- the evaluate-region editing command is still broken
  (I can’t think of any other obvious codepath that triggers
  the lexer issue)
- environment variables COLUMNS, LINES, SECONDS, etc. can be
  used for shell DoS, possibly command execution
- memory leaks (minor, most “lost” blocks are cleaned up when
  a scope is left… if it is even left)
- files with \x02 in them possibly can’t be tab-completed
- pathnames with tildes in them tabcomplete to user homedirs
  instead; same with pattern expansion: 'echo \~bar/*'
- variables with {} or ~ in their values are escaped without
  quoting these characters making them not safe for re-entry
  into the shell (possibly changing their value); this also
  affects internal pass-escaped-values-around like typeset -f
  or even $(…)

[ Tests ]
- the “taint” thing has an automated test
- I wrote excessive code to test the changes to the character
  classes, this is about 600 LoC, which I omitted here to keep
  the diff small, as it’d be called manually while developing
  anyway
- most nōn-interactive functionality is covered by the testsuite
  (which is also run via autopkgtests)
- I tested the escaping and tab-completion things as well as
  the lexer / evaluate-region thing manually

I also did a full rebuild of MirBSD itself with the changes
applied which exercises the shell quite a bit.

[ Risks ]
- the “taint” thing changes the way some scripts may operate,
  but the previous behaviour was unsafe and other shells are
  the same; mksh is de-facto leaf in Debian (I looked at shunit2
  for the previous unblock, and it’ll basically ignore mksh);
  I guess this is medium risk for mksh (which is why this should
  simmer in sid for a while first, though my users tend to find
  bugs rather quickly) but low risk for Debian or the release
  overall considering its virtually-leafness
- the escaping changes only add 

Bug#987974: debian-security-support: use /usr/sbin/nologin as the system user's shell

[Christoph Anton Mitterer]

Package: debian-security-support
Version: 1:11+2021.03.19
Severity: wishlist


Hey.

It seems most system users are created with /usr/sbin/nologin as shell,
which gives some nice message when trying to login, unlike /bin/false.


Perhaps you might want to change that, too.
If so, please don't forget to update it also for existing installations.


Cheers,
Chris.

Bug#987973: lightdm: use /usr/sbin/nologin as the system user's shell

[Christoph Anton Mitterer]

Package: lightdm
Version: 1.26.0-7
Severity: wishlist



Hey.

It seems most system users are created with /usr/sbin/nologin as shell,
which gives some nice message when trying to login, unlike /bin/false.


Perhaps you might want to change that, too.
If so, please don't forget to update it also for existing installations.


Cheers,
Chris.

Bug#621833: System users: removing them

[Christoph Anton Mitterer]

Oh and such creation/deletion of system users/groups should then
definitely done by some centrally managed code.

This would also allow to easily update things like home-dir, shell or
the GECOS field.

Right now most installations quickly run out of sync, e.g. many legacy
installations will have system users with /bin/false as shell, while
apparently at some point this was changed to /usr/sbin/nologin .


Cheers,
Chris.

Bug#621833: System users: removing them

[Christoph Anton Mitterer]

Hey.

Wouldn't something like the following be a solution:

Apart from some "static" system users/groups which every system has,
let system users be in a certain reserved range, which is not the
normal 1-1000 range but neither a range where normal users can be
created.

When packages try to add their system user/group, they check whether it
already exists, if it does not or if it's on the reserved range - fine.

If it does but is in another range, one must presume that the local
admin accidentally used the same name.
Package installation should then fail. What we have right now, that
many packages simply check whether the group exists and create it only
if not, is IMO a security hole.


On purge, the user/group shall be removed, but again, only if it's from
the reserved range.


Existing packages should be mandated to migrate.



Maybe it would additionally make sense to come up with some pseudo-
reserved namespace for user/group names, too.
Like some packages already use debian- ... or _.

It's not perfect and doesn't guarantee that there are no collisions,
but better than nothing.



With respect to files owned by some system user/group and wich are left
over after package removal...
Well, normal removal shouldn't remove the user/group anyway.
And on purge, any files "owned" by the package should be properly
deleted anyway.


If there are nevertheless files which aren't deleted, like e.g. if
stuff in /srv/www would be owned by some daemon user/group, one could
do the following to provide at least some better protection:

When new system users/groups are created, their IDs are recorded and
after deleting them these IDs will only be reused, if otherwise the
reserved range would be empty (starting with the first one deleted).


Cheers,
Chris.

Bug#987972: dcmtk user/group

[Christoph Anton Mitterer]

Package: dcmtk
Version: 3.6.5-1
Severity: normal


Hey.

1) Does dcmtk user really need a shell of /bin/sh?
Most system users have (for security reasons) the default of
/usr/sbin/nologin .

If that can be changed, it should also be updated for existing
installations on upgrade.


2) On purge, the user/group are not cleaned up but leftover.



Cheers,
Chris.

Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found

[John Scott]

Has anyone been able to reproduce this? Attempting to build Sage in a
fresh unstable environment succeeds for me; perhaps the build failure
was spurious.


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

Bug#922666: confirmed bug report

[Antoine Beaupré]

On 2021-05-01 07:59:01, Salvatore Bonaccorso wrote:
> Hi Antoine
>
> On Fri, Apr 30, 2021 at 07:34:04PM -0400, Antoine Beaupré wrote:
>> On 2021-04-30 21:04:29, Salvatore Bonaccorso wrote:
>> > Control: tags -1 + moreinfo
>> >
>> > Hi Tollef, Antoine,
>> >
>> > On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote:
>> >> Control: forcemerge 922666 928189
>> >> Control: severity 922666 important
>> >> Control: tags 922666 +patch +confirmed
>> >> 
>> >> I also see a regression with touchpads and trackpoint on a Thinkpad E431
>> >> after upgrading from Debian stretch to buster. My research indicates
>> >> this is a kernel regression, as yet to be fixed.
>> >> 
>> >> This is the result of my research, as available online at:
>> >> 
>> >> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep
>> >> 
>> >> On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
>> >> freezes after sleep. Keyboard still works but not mouse until a
>> >> reboot.
>> >> 
>> >> There's [bug 922666][] in Debian buster, without a fix. It also says
>> >> it eventually recovers, which is not our experience. Possible dupe is
>> >> [bug 928189][].
>> >> 
>> >> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
>> >> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666
>> >> 
>> >> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
>> >> which proposes the following workarounds:
>> >> 
>> >>  * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method 
>> >> disabled`
>> >> 
>> >>  * A .service file:
>> >> 
>> >> # /etc/systemd/system/touchpad-sleep.service
>> >> # restore touchpad on suspend
>> >> 
>> >> [Unit]
>> >> Description=Restore Touchpad on suspend
>> >> Before=sleep.target
>> >> StopWhenUnneeded=yes
>> >> 
>> >> [Service]
>> >> #Type=oneshot
>> >> Type=idle
>> >> RemainAfterExit=yes
>> >> ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
>> >> /sys/bus/pci/drivers/i801_smbus/unbind'
>> >> ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
>> >> /sys/bus/pci/drivers/i801_smbus/bind'
>> >> 
>> >> [Install]
>> >> WantedBy=sleep.target
>> >> 
>> >>  * "Maybe try xserver-xorg-input-evdev instead of 
>> >> xserver-xorg-input-libinput?"
>> >> 
>> >>  * reloading `psmouse`:
>> >>  
>> >> sudo modprobe -r psmouse
>> >> sudo modprobe psmouse
>> >> 
>> >>  * "`modprobe i2c-i801` after removing it from the `blacklist.conf` seems 
>> >> to solve the issue."
>> >> 
>> >>  * whatever this is:
>> >>  
>> >> # echo 1 > /sys/devices/rmi4-00/nosleep
>> >> 
>> >>  * "Anyone who still affected by touchpad issues after S3. Please
>> >>switch back to suspend-to-idle in BIOS if s2idle is
>> >>supported. ThinkPad Carbon 6th and Yoga 3rd do support
>> >>suspend-to-idle in BIOS->config->power menu."
>> >> 
>> >> [bug 1791427]: 
>> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427
>> >> 
>> >> There's also [bug 1442699][] in Fedora, which suggests those
>> >> workarounds:
>> >> 
>> >>  * another module reload:
>> >>  
>> >> sudo rmmod i2c_hid
>> >> sudo modprobe i2c_hid
>> >> 
>> >>  * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing
>> >>and this issue seems to have been resolved (for me)."
>> >> 
>> >>  * another `/proc` hack:
>> >>  
>> >> echo -n "reconnect" >  /sys/bus/serio/devices/serio1/drvctl
>> >> 
>> >>  * "The `psmouse.synaptics_intertouch=0` workaround still works for me."
>> >> 
>> >> [bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699
>> >> 
>> >> Also related is this [libinput bug][] that's closed as "not our bug"
>> >> because they claim it's a bug in the kernel.
>> >> 
>> >> [libinput bug]: https://bugs.freedesktop.org/show_bug.cgi?id=103149
>> >> 
>> >> There are [two][] [patches][] on the Linux kernel which apparently fix the
>> >> issue, still pending approval:
>> >> 
>> >> [two]: https://lkml.org/lkml/2019/2/20/700
>> >> [patches]: https://lkml.org/lkml/2019/2/20/701
>> >> 
>> >> Possibly related: https://lkml.org/lkml/2016/8/18/134
>> >> 
>> >> [5.1rc7][] shipped two fixes against the `synaptics-rmi4` module. A
>> >> [pull request][] has been merged in mainline with two other fixes on
>> >> the module./ [5.0.11][] also has fixes on the module. It's clearly a
>> >> regression from Debian stretch (kernel 4.9) since it was working fine
>> >> before.
>> >> 
>> >> Possibly related, [two-finger scrolling bug in Ubuntu][], which
>> >> identifies [this commit][] as the source of the regression. [Upstream
>> >> kernel bug][], still open.
>> >> 
>> >> [5.1rc7]: https://lkml.org/lkml/2019/4/28/270
>> >> [pull request]: https://lkml.org/lkml/2019/7/12/19
>> >> [5.0.11]: https://lkml.org/lkml/2019/5/2/287
>> >> [Upstream kernel bug]: https://bugzilla.kernel.org/show_bug.cgi?id=196719
>> >> [this commit]: 
>> >> 

Bug#562817: usbmuxd: usbmux user not deleted on purge

[Christoph Anton Mitterer]

Hey.

Actually quite a lot packages clean up properly on purge, just grep for
deluser in /var/lib/dpkg/info/ and see.


Also I'd say it's pretty unlikely that anyone create a (system) user by
that name.
And the same problem already exists (for apparently all system users)
when creating the username. If it already exists and is used by e.g.
some plain user, this could easily introduce a security hole - but no
one cares.

And if files are left behind by the package itself,... they should
rather be cleaned up, too. (when purging).



Cheers,
Chris.

Bug#987971: logcheck: leftovers on purge

[Christoph Anton Mitterer]

Package: logcheck
Version: 1.3.23
Severity: normal



Hey.

I've just noted, that when purging the package, at least the user
is left behind and not removed.

Any reason for that?


Cheers,
Chris.

Bug#987970: tor: leftovers on purge

[Christoph Anton Mitterer]

Package: tor
Version: 0.4.5.7-1
Severity: normal


Hey.

I've just noted, that when purging the package, at least the user
is left behind and not removed.

Any reason for that?


Cheers,
Chris.

Bug#987969: privoxy: leftovers on purge

[Christoph Anton Mitterer]

Package: privoxy
Version: 3.0.32-2
Severity: normal


Hey.

I've just noted, that when purging the package, at least the user
is left behind and not removed.

Any reason for that?


Cheers,
Chris.

Bug#987934: fdb: fails to build from the source

[Sergio Durigan Junior]

Control: tags -1 + patch

On Sunday, May 02 2021, Andrej Shadura wrote:

> Dear Maintainer,
>
> While rebuilding your package from the source, I received this error:
>
> [ 79%] Building CXX object 
> src/fdb5/CMakeFiles/fdb-hammer.dir/tools/fdb-hammer.cc.o
> cd /<>/obj-x86_64-linux-gnu/src/fdb5 && /usr/bin/c++  
> -I/<>/src -I/<>/obj-x86_64-linux-gnu/src 
> -I/usr/include/metkit -I/us
> r/include/x86_64-linux-gnu/eckit 
> -I/usr/include/x86_64-linux-gnu/eckit/option -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werr
> or=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -O3 -DNDEBUG 
> -fPIE -std=gnu++11 -o CMakeFiles/fdb-hammer.dir/tools/fdb-hammer.cc.o -c 
> /<>/s
> rc/fdb5/tools/fdb-hammer.cc
> /<>/src/fdb5/tools/fdb-hammer.cc:25:10: fatal error: 
> metkit/grib/GribHandle.h: No such file or directory
>25 | #include "metkit/grib/GribHandle.h"
>   |  ^~
> compilation terminated.
> make[3]: *** [src/fdb5/CMakeFiles/fdb-hammer.dir/build.make:85: 
> src/fdb5/CMakeFiles/fdb-hammer.dir/tools/fdb-hammer.cc.o] Error 1
> make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> make[2]: *** [CMakeFiles/Makefile2:1428: 
> src/fdb5/CMakeFiles/fdb-hammer.dir/all] Error 2
>
> The complete build log is attached to the bug report.

Hi,

The following patch fixes the FTBFS for me.  I've also opened an MR
against the salsa project here:

  https://salsa.debian.org/science-team/fdb/-/merge_requests/1

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

diff --git a/debian/changelog b/debian/changelog
index be94e04..43b0a96 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+fdb (5.7.0-6) UNRELEASED; urgency=medium
+
+  * d/p/adjust-metkit-changes.patch: Adjust code to reflect metkit changes.
+Fix FTBFS. (Closes: #987934)
+
+ -- Sergio Durigan Junior   Sun, 02 May 2021 18:45:20 -0400
+
 fdb (5.7.0-5) unstable; urgency=medium
 
   * Add debian/watch file
diff --git a/debian/patches/adjust-metkit-changes.patch b/debian/patches/adjust-metkit-changes.patch
new file mode 100644
index 000..966eb8f
--- /dev/null
+++ b/debian/patches/adjust-metkit-changes.patch
@@ -0,0 +1,38 @@
+From: Emanuele Danovaro 
+Date: Sun, 2 May 2021 18:42:19 -0400
+Subject: METK-80 to reflect changes in metkit
+
+Origin: backported, https://github.com/ecmwf/fdb/commit/09c914a4c7c8336781dacdd9224bd9fd530974f4
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987934
+Last-Updated: 2021-05-02
+---
+ src/fdb5/tools/fdb-hammer.cc | 9 -
+ 1 file changed, 9 deletions(-)
+
+diff --git a/src/fdb5/tools/fdb-hammer.cc b/src/fdb5/tools/fdb-hammer.cc
+index 3298da9..efcfebc 100644
+--- a/src/fdb5/tools/fdb-hammer.cc
 b/src/fdb5/tools/fdb-hammer.cc
+@@ -22,8 +22,6 @@
+ #include "eckit/option/SimpleOption.h"
+ #include "eckit/option/VectorOption.h"
+ 
+-#include "metkit/grib/GribHandle.h"
+-
+ #include "fdb5/grib/GribArchiver.h"
+ #include "fdb5/io/HandleGatherer.h"
+ #include "fdb5/tools/FDBTool.h"
+@@ -106,13 +104,6 @@ void FDBWrite::executeWrite(const eckit::option::CmdArgs ) {
+ codes_handle* handle = codes_handle_new_from_file(nullptr, fin, PRODUCT_GRIB, );
+ ASSERT(handle);
+ 
+-/*long value;
+-metkit::grib::GribHandle gh(*handle);
+-ASSERT(gh.hasKey("number"));
+-ASSERT(gh.hasKey("step"));
+-ASSERT(gh.hasKey("level"));
+-ASSERT(gh.hasKey("expver"));*/
+-
+ size_t nsteps = args.getLong("nsteps");
+ size_t nensembles = args.getLong("nensembles", 1);
+ size_t nlevels = args.getLong("nlevels");
diff --git a/debian/patches/series b/debian/patches/series
index 0a55278..29b3703 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 soversion.patch
+adjust-metkit-changes.patch


signature.asc
Description: PGP signature

Bug#987968: flash-kernel: Tinkered a new DTB to make my version of Olimex A64-Olinuxino-eMMC boot

[Regis Etourmy]

Package: flash-kernel
Version: 3.104
Severity: wishlist

Dear Maintainer,

I could not install a Debian Bullseye that was able to boot on my Olimex 
A64-Olinuxino-eMMC -A64-OLinuXino-1Ge16GW version - with the nightly built SD 
card images. Nothing was happening after the message "Starting kernel".

So I followed the mitigation process proposed here: 
https://wiki.debian.org/InstallingDebianOn/Allwinner#Installing_on_systems_that_are_not_supported_out_of_the_box

As the nightly built DTB was giving the same result - nothing after 'starting 
kernel', I compiled a DTB from the DTS found in the device tree git repo. It 
dit not work better.

While I was trying to have a bootable system from the nightly built SD card 
images, I had noticed that a system install with  Olimex Teres images was 
nearly woking: it was able to boot, but hanged 30 seconds after the boot.

So I have used the Olimex Teres DTS. I have removed the parts relating to 
hardware not present on a64-Olinuxino-eMMc. The system can boot. It complains 
about vcc-p* not found. When I tried to add the parts related to vcc-p* from 
the a64-Olinuxino-eMMc DTS, the system could not boot anymore (again, nothing 
after 'Starting kernel').

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-6-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.75
ii  devio  1.2-1.2+b1
ii  initramfs-tools0.140
ii  linux-base 4.6
ii  mtd-utils  1:2.1.2-2
ii  ucf3.0043

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2021.01+dfsg-4

flash-kernel suggests no packages.

-- Configuration Files:
/etc/flash-kernel/db changed:
Machine: Olimex A64-Olinuxino-eMMC
Kernel-Flavors: arm64
DTB-Id: allwinner/sun50i-a64-olinuxino-emmc.dtb
Boot-Script-Path: /boot/boot.scr
U-Boot-Script-Name: bootscr.uboot-generic
Required-Packages: u-boot-tools


-- debconf information:
* flash-kernel/linux_cmdline: quiet

Bug#987841: xsane: FTBFS on hppa - SANE_LDFLAGS is blank

[John David Anglin]

Hello Jörg,

Your develop branch builds successfully on hppa using dpkg-buildpackage.

Thanks,
Dave

On 2021-05-02 4:01 p.m., Jörg Frings-Fürst wrote:
> Hello John,
>
>
> thank you for spending your time helping to make Debian better with
> this bug report. 
>
> I don't have a hppa system for testing my changes. 
>
> Please can you check the build with my develop - branch? 
>
> https://jff.email/cgit/xsane.git/?h=develop
>
> Many thanks.
>
>
> CU
> Jörg
>


-- 
John David Anglin  dave.ang...@bell.net

Bug#987428: libwebkit2gtk-4.0-37: only recommned xdg-desktop-portal-gtk

[Alberto Garcia]

On Sun, May 02, 2021 at 05:46:44PM +0100, Simon McVittie wrote:
> xdg-desktop-portal(-gtk) is not going to get a dependency on Flatpak
> unless there is an *incredibly* good reason why it must, because that
> would be a circular dependency, and circular dependencies are something
> we avoid.

The only question here is whether we should change the dependency
from webkit on xdg-desktop-portal-gtk with a recommendation, as the
reporter requests.

I think it's not completely unreasonable to do so because webkit
does work without the portal (although with suboptimal quality, as
explained in #987948) and there are probably use cases for which the
portal is not needed. It would also have the side effect of fixing the
balsa autopkgtest bug described in #987686.

Berto

Bug#987948: evolution: bad quality rendering of fonts in sandbox

[Alberto Garcia]

Control: fixed 987948 2.32.0-2

On Sun, May 02, 2021 at 05:47:30PM +0100, Simon McVittie wrote:
> Instead of making each leaf application depend on
> xdg-desktop-portal-gtk, it would be easier and more correct for
> libwebkit2gtk-4.0-37 to depend on xdg-desktop-portal-gtk. This has
> already been fixed in unstable, in webkit2gtk 2.32.0-1, but that
> change has not yet reached bullseye.
  [...]
> webkit2gtk maintainers: is 2.32.x targeted at bullseye? If yes, note
> that it is going to need a release team unblock, and appears to be
> triggering an autopkgtest regression in balsa.

It will be sooner or later because the package is covered by security
updates, and 2.32.0 fixes 3 CVEs.

I didn't want to do it during the freeze because this update would
bring many more changes than a normal point release (it switches to a
new stable branch, 2.30 -> 2.32) so I wanted to be more careful than
usual, and we were also investigating two regressions, #987448 and
#987686. The good news is that the former is already fixed, and the
latter is the autopkgtest regression that you mention and it is not
related to webkit, it's actually triggered by xdg-desktop-portal-gtk.

Berto

Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!

[Alberto Garcia]

Control: found -1 balsa/2.6.1-1

On Tue, Apr 27, 2021 at 11:27:32PM +0200, Alberto Garcia wrote:
> The bug happens because when xdg-desktop-portal-gtk is installed
> Balsa takes a very long time to start so those two seconds are not
> enough.
> 
> g_application_register() calls g_dbus_proxy_new_sync(), and
> that times out. The problem seems to disappear if you unset
> DBUS_SESSION_BUS_ADDRESS, but that's a workaround I guess :)

I'm thinking that this should probably be fixed for bullseye. It may
not fail at the moment because xdg-desktop-portal-gtk is not installed
during the test, but webkit2gtk 2.32.x will make it to bullseye sooner
or later through a security release.

So I think it makes sense to at least apply the workaround?

I'm also attaching the full backtrace of the point where Balsa hangs
during the test.

Berto
(gdb) bt
#0  0x732113ff in __GI___poll (fds=0x55823e00, nfds=1, 
timeout=25000) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x733af0ae in g_main_context_poll (priority=, 
n_fds=1, fds=0x55823e00, timeout=, context=0x55866c00) 
at ../../../glib/gmain.c:4422
#2  g_main_context_iterate (context=0x55866c00, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4114
#3  0x733af40b in g_main_loop_run (loop=0x557e6c70) at 
../../../glib/gmain.c:4317
#4  0x735ff214 in initable_init (initable=0x5578cab0, 
cancellable=0x0, error=0x7fffda50) at ../../../gio/gdbusproxy.c:1903
#5  0x735608e2 in g_initable_new_valist (object_type=, 
first_property_name=0x7363283a "g-flags", 
var_args=var_args@entry=0x7fffd8a0, cancellable=cancellable@entry=0x0, 
error=error@entry=0x7fffda50) at ../../../gio/ginitable.c:248
#6  0x73560999 in g_initable_new 
(object_type=object_type@entry=93824994070512, 
cancellable=cancellable@entry=0x0, error=error@entry=0x7fffda50, 
first_property_name=first_property_name@entry=0x7363283a "g-flags") at 
../../../gio/ginitable.c:162
#7  0x73600913 in g_dbus_proxy_new_sync (connection=0x557180b0, 
flags=G_DBUS_PROXY_FLAGS_NONE, info=info@entry=0x0, 
name=name@entry=0x73d95460 "org.freedesktop.portal.Desktop", 
object_path=0x73d954a8 "/org/freedesktop/portal/desktop", 
interface_name=0x73e01cd0 "org.freedesktop.portal.Inhibit", 
cancellable=0x0, error=0x7fffda50) at ../../../gio/gdbusproxy.c:2093
#8  0x73d604ee in gtk_application_get_proxy_if_service_present 
(connection=, flags=, bus_name=0x73d95460 
"org.freedesktop.portal.Desktop", object_path=, 
interface=, error=0x7fffda50) at 
../../../../gtk/gtkapplication-dbus.c:132
#9  0x73d60678 in gtk_application_impl_dbus_startup 
(impl=0x55825500, register_session=1) at 
../../../../gtk/gtkapplication-dbus.c:461
#10 0x73a93690 in gtk_application_startup 
(g_application=0x557090f0) at ../../../../gtk/gtkapplication.c:307
#11 0x734a00a2 in g_closure_invoke 
(closure=closure@entry=0x557036e0, return_value=return_value@entry=0x0, 
n_param_values=1, param_values=param_values@entry=0x7fffdd10, 
invocation_hint=invocation_hint@entry=0x7fffdc90) at 
../../../gobject/gclosure.c:810
#12 0x734b20aa in signal_emit_unlocked_R 
(node=node@entry=0x55703710, detail=detail@entry=0, 
instance=instance@entry=0x557090f0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffdd10) at 
../../../gobject/gsignal.c:3669
#13 0x734b86cf in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffde90) at ../../../gobject/gsignal.c:3495
#14 0x734b8c3f in g_signal_emit 
(instance=instance@entry=0x557090f0, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3551
#15 0x735c4d92 in g_application_register 
(application=application@entry=0x557090f0, 
cancellable=cancellable@entry=0x0, error=error@entry=0x7fffdfb0) at 
../../../gio/gapplication.c:2204
#16 0x735c517a in g_application_real_local_command_line 
(application=0x557090f0, arguments=0x7fffe018, 
exit_status=0x7fffe014) at ../../../gio/gapplication.c:1106
#17 0x735c54ae in g_application_run (application=0x557090f0, 
argc=-8172, argc@entry=2, argv=argv@entry=0x7fffe188) at 
../../../gio/gapplication.c:2528
#18 0x555881e5 in main (argc=2, argv=0x7fffe188) at main.c:786

Bug#987368: Installer fails at first menu "Choose language"

[Samuel Thibault]

Vagrant Cascadian, le dim. 02 mai 2021 14:36:46 -0700, a ecrit:
> On 2021-04-22, Frédéric Bonnard wrote:
> > Machine: Power10 machine but got it on Power8 as well
> 
> > This happens randomly when the installer menu starts, I get to the first
> > menu "Choose language", but it is red saying "An installation failed...
> > The failing step is: Choose language".
> 
> FWIW, I've seen this a few times on arm64 too.

I got it as well somtimes while testing, on arm and ppc with qemu. I
assumed it could be a qemu emulation bug. But it does happen only on
that screen, indeed.

Samuel

Bug#987368: Installer fails at first menu "Choose language"

[Vagrant Cascadian]

On 2021-04-22, Frédéric Bonnard wrote:
> Machine: Power10 machine but got it on Power8 as well

> This happens randomly when the installer menu starts, I get to the first
> menu "Choose language", but it is red saying "An installation failed...
> The failing step is: Choose language".

FWIW, I've seen this a few times on arm64 too.

I hate to admit I rebooted and tried again the few times it happened,
rather than dive into the details of the problem, but it *usually*
worked on the second try... so this may not be a deterministic bug.

I'll try again soon and try to get more details...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#987967: jade replaced by pug for ages, doesn't work anymore

[Stefan Bühler]

Package: node-jade
Version: 1.11.0+~cs4.1.0-1
Severity: grave

Hi,

https://www.npmjs.com/package/jade says last release was 6 years ago and
it got replaced by pug.

Also it doesn't work anymore in bullseye for two reasons:

1. CLI tool broken due to "--name" conflicting with existing property:

---
Error: option 'name' clashes with existing property 'name' on Command
- call storeOptionsAsProperties(false) to store option values safely,
- or call storeOptionsAsProperties(true) to suppress this check,
- or change option name
---

2. It fails: parseMax got removed in character-parser:

https://github.com/ForbesLindesay/character-parser#parsemax

With this as test.jade:
---
div(class='test')
---

And renaming --name to --nameX in /usr/share/nodejs/jade/bin/jade.js it
fails like this:
---
$ jadejs test.jade

/usr/share/nodejs/jade/lib/runtime.js:240
  throw err;
  ^

TypeError: test.jade:1
  > 1| div(class='test')
2|

characterParser.parseMax is not a function
at Lexer.bracketExpression (/usr/share/nodejs/jade/lib/lexer.js:129:33)
at Lexer.attrs (/usr/share/nodejs/jade/lib/lexer.js:610:24)
at Lexer.next (/usr/share/nodejs/jade/lib/lexer.js:939:15)
at Lexer.lookahead (/usr/share/nodejs/jade/lib/lexer.js:113:46)
at Parser.lookahead (/usr/share/nodejs/jade/lib/parser.js:102:23)
at Parser.peek (/usr/share/nodejs/jade/lib/parser.js:79:17)
at Parser.tag (/usr/share/nodejs/jade/lib/parser.js:773:22)
at Parser.parseTag (/usr/share/nodejs/jade/lib/parser.js:759:17)
at Parser.parseExpr (/usr/share/nodejs/jade/lib/parser.js:211:21)
at Parser.parse (/usr/share/nodejs/jade/lib/parser.js:122:25) {
  path: 'test.jade'
}
---

This is also the reason why isso doesn't build anymore: see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959644 "isso: FTBFS:
TypeError: Jade:1"

cheers,
Stefan

Bug#987839: apt-listbugs: daily cleanup runs hourly

[Ross Boylan]

See below.

On Sun, May 2, 2021 at 11:08 AM Francesco Poli
 wrote:
>
> On Sat, 1 May 2021 11:31:19 -0700 Ross Boylan wrote:
>
> [...]
> > On Fri, Apr 30, 2021 at 2:47 PM Francesco Poli
> >  wrote:
> [...]
> > > Does logcheck send e-mail messages for all the other systemd timers?
> > >
> > > As you may already know, you can get a list of active systemd timers on
> > > your box with the following command:
> > >
> > >   $ systemctl list-timers
> > >
> > Thanks for the tip; I wasn't familiar with list-timers.  There are 11
> > on my list, but the only things I see in my hourly reports from
> > logcheck were  apt-listbugs and complaints about time synchronization.
>
> Do you have anacron installed?

Yes.

> It's another package that has an hourly systemd timer.
>
> I wonder why logcheck does not send hourly mail messages about
> anacron...
>

For logcheck to send a message there must be something in the logs it
checks and it must either match a pattern logcheck thinks is
noteworthy or (from memory) fail to match a pattern for things that
are OK.  I haven't reviewed exactly why the messages are being noted,
albeit at logcheck's lowest severity level.  I configured logcheck  to
use workstation mode.

> > Of course, I don't know how many of the timers are hourly.
>
> The command 'systemctl list-timers' should tell you: just look at the
> LEFT and PASSED columns.
Sun 02 May 2021 01:19:46 PM PDT
NEXTLEFTLAST
PASSED   UNIT ACTIVATES
Sun 2021-05-02 13:30:14 PDT 10min left  Sun 2021-05-02 12:31:06 PDT
48min agoanacron.timeranacron.service
Sun 2021-05-02 22:56:18 PDT 9h left Sun 2021-05-02 12:50:06 PDT
29min agoapt-daily.timer  apt-daily.service
Mon 2021-05-03 00:00:00 PDT 10h leftSun 2021-05-02 00:00:01 PDT
13h ago  exim4-base.timer exim4-base.service
Mon 2021-05-03 00:00:00 PDT 10h leftSun 2021-05-02 00:00:01 PDT
13h ago  logrotate.timer  logrotate.service
Mon 2021-05-03 00:00:00 PDT 10h leftSun 2021-05-02 00:00:01 PDT
13h ago  man-db.timer man-db.service
Mon 2021-05-03 01:25:15 PDT 12h leftMon 2021-04-26 16:32:27 PDT 5
days ago   fstrim.timer fstrim.service
Mon 2021-05-03 06:45:23 PDT 17h leftSun 2021-05-02 06:28:28 PDT 6h
ago   apt-daily-upgrade.timer  apt-daily-upgrade.service
Mon 2021-05-03 10:05:28 PDT 20h leftSun 2021-05-02 10:05:28 PDT 3h
14min ago etckeeper.timer  etckeeper.service
Mon 2021-05-03 10:05:28 PDT 20h leftSun 2021-05-02 10:05:28 PDT 3h
14min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.serv…
Mon 2021-05-03 11:42:24 PDT 22h leftSun 2021-05-02 11:50:28 PDT 1h
29min ago apt-listbugs.timer   apt-listbugs.service
Sun 2021-05-09 03:10:37 PDT 6 days left Sun 2021-05-02 03:11:06 PDT
10h ago  e2scrub_all.timere2scrub_all.service

So it looks as if anacron is the only one that is running hourly.
apt-listbugs would too if I hadn't messed with it.

Let's see how apt-daily-upgrade works:
=apt-daily-upgrade.timer==
[Unit]
Description=Daily apt upgrade and clean activities
After=apt-daily.timer

[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=60m
Persistent=true

[Install]
WantedBy=timers.target


=apt-daily-upgrade.service=
[Unit]
Description=Daily apt upgrade and clean activities
Documentation=man:apt(8)
ConditionACPower=true
After=apt-daily.service network.target network-online.target
systemd-networkd.service NetworkManager.service connman.service

[Service]
Type=oneshot
ExecStartPre=-/usr/lib/apt/apt-helper wait-online
ExecStart=/usr/lib/apt/apt.systemd.daily install
KillMode=process
TimeoutStopSec=900
=

1. So the timer is 6am every day.
2. Persistent=true means if you restart the system and a timer would
have run while it was off, it is run.  Got that from
https://wiki.archlinux.org/title/Systemd/Timers, though it actually is
documented on the man page for systemd.timer.
3. network targets in [Unit] to (try to?) assure connectivity.  BTW,
for some insight into why the network target doesn't work as expected,
see https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/.
I still find it annoying, but I appreciate the point that it is not
straightforward to say exactly what the network being "up" means.

That seems like a model that could work for apt-listbugs, assuming the
script were changed to update unconditionally when invoked.

>
> Or you could read the timer definitions, if you know (or learn) the
> syntax and semantics...
>
> [...]
> > I tried this modification to apt-listbugs.timer:
> > [Timer]
> > OnActiveSec=5min
> > #OnCalendar=*-*-* *:20
> > OnUnitActiveSec=23h 50m
> > RandomizedDelaySec=20min
> >
> > which did  fix the "running every hour" problem (even if the run is
> > only to check if a real  

Bug#987966: unblock: petsc/3.14.5+dfsg1-4

[Drew Parsons]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Andreas Beckmann 

Please unblock package petsc

[ Reason ]

This patch closes RC Bug#987618, reported (and patch provided) by
Andreas Beckmann.

libpetsc-real3.14/libpetsc-complex3.14: Add Breaks against
lib{petsc,slepc}-{real,complex}3.10 and
libpetsc3.10-dev-{common,examples} for smoother upgrades from buster. 

The libraries are not co-installable due to the libhdf5-103 ->
libhdf5-103-1 and other package renames, the -dev-* packages are
affected by the removal of unversioned python.

Breaks have been added without package version since the version
(3.10) is embedded in the package names (libpetsc*3.10*).
Hence lintian overrides are added to ignore the lintian warning
breaks-without-version in libpetsc-real3.14 and libpetsc-complex3.14


[ Impact ]

Without this patch the upgrade from buster to bullseye will not be
smooth for systems with petsc installed. Likely the administrator will need to
manually force installation of the new version of petsc in bullseye,
or manually uninstall petsc temporarily and then reinstall after
upgrade.

[ Tests ]

debci tests are passing in testing both for petsc and dependent
packages (slepc, dolfin, etc). However armhf debci tests are currently
inactive.

Andreas Beckmann has run buster->bullseye upgrade tests to check
the patch works as intended.

[ Risks ]

No code changes, only dependency relationships (Breaks) with the older
3.10 versions of petsc has been added. Hence low risk with respect to
the libraries.

The only risk is if any specific system deliberately wants to retain
petsc 3.10 alongside petsc 3.14 (the petsc package structure in
principle enables this; conservative scientific computational
applications might desire it for particular projects; the libhdf5
problem raised in Bug#987618 is an unanticipated nuisance). In this
case those systems could rebuild petsc 3.10 against the bullseye
toolchain to fix the underlying libhdf5 problem, but will be impacted
by the Breaks introduced here.

An alternative fix is to use versioned Breaks here (<= 3.10.3+dfsg1-5,
allowing local bullseye rebuilds of petsc3.10 as -5.1). But this risk
is probably low probability, and therefore the implementation released
here does not use such versioned breaks in order to ease the
readability of debian/control.

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

unblock petsc/3.14.5+dfsg1-4
diff -Nru petsc-3.14.5+dfsg1/debian/changelog 
petsc-3.14.5+dfsg1/debian/changelog
--- petsc-3.14.5+dfsg1/debian/changelog 2021-04-09 13:28:02.0 +0200
+++ petsc-3.14.5+dfsg1/debian/changelog 2021-05-01 14:26:37.0 +0200
@@ -1,3 +1,21 @@
+petsc (3.14.5+dfsg1-4) unstable; urgency=medium
+
+  [ Andreas Beckmann ]
+  * libpetsc-real3.14/libpetsc-complex3.14: Add Breaks against
+lib{petsc,slepc}-{real,complex}3.10 and libpetsc3.10-dev-{common,examples}
+for smoother upgrades from buster. The libraries are not co-installable
+due to the libhdf5-103 -> libhdf5-103-1 and other package renames, the
+-dev-* packages are affected by the removal of unversioned python.
+Closes: #987618.
+
+  [ Drew Parsons ]
+  * add lintian overrides to ignore breaks-without-version warning in
+libpetsc-real3.14 and libpetsc-complex3.14 from Breaks: libpetsc*3.10*
+and Breaks libslepc*3.10*. The version is embedded in the package
+names.
+
+ -- Drew Parsons   Sat, 01 May 2021 14:26:37 +0200
+
 petsc (3.14.5+dfsg1-3) unstable; urgency=medium
 
   * petsc3.14-doc Depends: sphinx-common.
diff -Nru petsc-3.14.5+dfsg1/debian/control petsc-3.14.5+dfsg1/debian/control
--- petsc-3.14.5+dfsg1/debian/control   2021-04-09 13:28:02.0 +0200
+++ petsc-3.14.5+dfsg1/debian/control   2021-05-01 14:26:37.0 +0200
@@ -113,6 +113,7 @@
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Conflicts: libpetsc3.6 (<< 3.6.2.dfsg1-4)
+Breaks: libpetsc-real3.10, libslepc-real3.10, libpetsc3.10-dev-common, 
libpetsc3.10-dev-examples
 Replaces: libpetsc3.6 (<< 3.6.2.dfsg1-4)
 Description: Shared libraries for version 3.14 of PETSc
  PETSc is the "Portable Extensible Toolkit for Scientific
@@ -250,6 +251,7 @@
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Conflicts: libpetsc-complex-3.6 (<< 3.6.2.dfsg1-4)
+Breaks: libpetsc-complex3.10, libslepc-complex3.10, libpetsc3.10-dev-common, 
libpetsc3.10-dev-examples
 Replaces: libpetsc-complex-3.6 (<< 3.6.2.dfsg1-4)
 Description: Shared libraries for version 3.14 of PETSc with Complex Numbers
  PETSc is the "Portable Extensible Toolkit for Scientific
diff -Nru petsc-3.14.5+dfsg1/debian/libpetsc-complex3.14.lintian-overrides 
petsc-3.14.5+dfsg1/debian/libpetsc-complex3.14.lintian-overrides
--- petsc-3.14.5+dfsg1/debian/libpetsc-complex3.14.lintian-overrides 

Bug#987441: s390x installation bugs

[Valentin Vidic]

Hi,

Probably not critical, but maybe these installation bugs on s390x could
be fixed for the release?

rootskel: steal-ctty no longer works on at least sparc64
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926539

debian-installer: qemu-system-s390x installation fails due to segfault in 
main-menu
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987788

-- 
Valentin

Bug#987965: ITP: libjitsi-utils-java -- Set of basic Java utilities used in Jitsi projects

[Sunil Mohan Adapa]

Package: wnpp
Severity: wishlist
Owner: Sunil Mohan Adapa 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libjitsi-utils-java
  Version : 1.0
  Upstream Author : 8x8 Inc., Atlassian Pty Ltd
* URL : https://github.com/jitsi/jitsi-utils
* License : Apache-2.0
  Programming Lang: Java
  Description : Set of basic Java utilities used in Jitsi projects

Jitsi Videobridge is an XMPP server component that allows for multiuser video
communication. Unlike the expensive dedicated hardware videobridges, Jitsi
Videobridge does not mix the video channels into a composite video stream, but
only relays the received video channels to all call participants. Therefore,
while it does need to run on a server with good network bandwidth, CPU
horsepower is not that critical for performance.

This library is a necessary component of the Jitsi Videobridge.

This is part of a larger effort to package Jitsi Videobridge in Debian. I
intend to maintain the package as part of the Debian Java team.




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAmCPEBoRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfLmNQ//eQFXd32Howg3bisxb47NsMYLMy6X7Fm+
EgrbJ19MRIV58qOPGfJhqPbkUOnC0n9ttLE9p3wboKJtaWMtAbDemyFyY2XTtHzs
xeRAuWSgWWB4MXzqD84aP0UUAQ3h7JOBGqUuSFB/l45uZ5Qjqf/sJvE195yhygmr
QktAQ+ZCHsP20DpNHVt0VkzxtpwBSa90UIEz6j28h1jJRaWHlRJhJ1GsNGCONDug
yYIjMKU5evIyyX6Py58WhIvBKUnpdzxwwV7kxKFx83JIOoSbFI/3405OyylEN2DN
rf+t6Eld+yoEOghF/PNTgwzmwBpins2WFC7w0ZX2Uq3HvI+hxq1t8HJaJeDmOrow
+sSayNTPvzCyCcEDyvBB26YTo+nAvwMm1ZxW8/fSTkYUXreqpGYErz9uUM9UzoYH
CT2QpnWWWAvgcxozxgYUAvVn1Tkw2xgdAc3anbM9ETWudZWNMjVEbtda09Q3J68u
hzEE09qpN8+uQKjEZlT+luI5m5+JkqlCqyg7/VSJk8zqEb53rUN0+8eLze9fY42c
/5ShxYHp4/hNiM1vRPnIxAS5KJsm+bK/Wbu0VBd0SLh04BhD6A5zzG4LT6DL2wyS
HteVEhlB8Yma94jeghbTssCChCXMvSJJHnpW2zGKU1o06Bi/9zNBzBXpQGIITDVI
3IC2ETkt5LY=
=I9Cf
-END PGP SIGNATURE-

Bug#987841: xsane: FTBFS on hppa - SANE_LDFLAGS is blank

[Jörg Frings-Fürst]

Hello John,


thank you for spending your time helping to make Debian better with
this bug report. 

I don't have a hppa system for testing my changes. 

Please can you check the build with my develop - branch? 

https://jff.email/cgit/xsane.git/?h=develop

Many thanks.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.


Am Freitag, dem 30.04.2021 um 18:20 + schrieb John David Anglin:
> Source: xsane
> Version: 0.999-10
> Severity: normal
> 
> Dear Maintainer,
> 
> The xsane package fails to build on hppa.  The following errors
> occurs
> during configuration:
> 
> checking for png_create_info_struct in -lpng... yes
> 
> ERROR: SANE-1.0.0 or newer is needed for compiling xsane
>  - if you installed SANE as rpm make sure you also included
>    sane-devel
> 
> 
> This occurs with latest version of sane-backends.
> 
> HAVE_SANE isn't set to yes because SANE_LDFLAGS is empty.  These are
> the SANE varibles that I see in config.log:
> 
> SANE_CFLAGS=''
> SANE_LDFLAGS=''
> SANE_LIBS='-lsane'
> SANE_MAJOR=''
> SANE_PREFIX='/usr'
> 
> The following lines set HAVE_SANE in configure.in:
> 
> PKG_CHECK_VAR([SANE_LDFLAGS], [sane-backends >= 1.0.0], [ldflags],
>   [HAVE_SANE=yes])
> 
> If I force HAVE_SANE=yes, xsane builds okay.
> 
> Regards,
> Dave Anglin
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'unstable')
> Architecture: hppa (parisc64)
> 
> Kernel: Linux 5.10.33+ (SMP w/4 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)




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

Bug#987853: wireshark: CVE-2021-22207

[Balint Reczey]

Control: tags -1 pending confirmed

Hi Salvatore,

On Fri, Apr 30, 2021 at 10:57 PM Salvatore Bonaccorso  wrote:
>
> Source: wireshark
> Version: 3.4.4-1
> Severity: important
> Tags: security upstream
> Forwarded: https://gitlab.com/wireshark/wireshark/-/issues/17331
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
>
> Hi,
>
> The following vulnerability was published for wireshark.
>
> CVE-2021-22207[0]:
> | Excessive memory consumption in MS-WSP dissector in Wireshark 3.4.0 to
> | 3.4.4 and 3.2.0 to 3.2.12 allows denial of service via packet
> | injection or crafted capture file
>
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

I've prepared the next upload including this fix at
https://salsa.debian.org/debian/wireshark/-/commits/debian/master but
have not uploaded it because I did not consider this vulnerability
important enough to ask an exception for the freeze.

I will happily do the upload if it gets unblocked.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#869684: linux-image-4.9.0-3-686-pae: Thinkpad T60 hangs on resume after suspend to disk; regress since Debian 8

[Bernhard Übelacker]

Control: fixed -1 linux/5.10.28-1


Dear Maintainer,
I got that Thinkpad T60 back, and did upgrade
the installation to bullseye.

I can now confirm that the nokaslr workaround is not
needed any more, hibernate and resume is working for
me with current kernel 5.10.0-6-686-pae/5.10.28-1 in testing.

Unfortunately I did not check if buster kernel already would
have worked without the nokaslr parameter.

I hope it is ok to mark it fixed for current version.

Kind regards,
Bernhard

Bug#987964: unblock: vim-scripts/20210124.1

[James McCoy]

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

Please unblock package vim-scripts

[ Reason ]
The filesystem layout of the package was reorganized, but the default
setting of the VimSokoban files was not updated accordingly.

[ Impact ]
Users of VimSokoban will get an error and have to figure out how to
change the path in their config.

[ Tests ]
Manual tests verified the installed package can start VimSokoban without
any config changes.

[ Risks ]
None.  Single line change to update the default location for VimSokoban.

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


unblock vim-scripts/20210124.1
diffstat for vim-scripts-20210124 vim-scripts-20210124.1

 changelog  |7 +++
 patches/sokoboan_path.diff |2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff -Nru vim-scripts-20210124/debian/changelog 
vim-scripts-20210124.1/debian/changelog
--- vim-scripts-20210124/debian/changelog   2021-01-24 18:58:45.0 
-0500
+++ vim-scripts-20210124.1/debian/changelog 2021-04-27 07:44:43.0 
-0400
@@ -1,3 +1,10 @@
+vim-scripts (20210124.1) unstable; urgency=medium
+
+  * Fix path for VimSokoban levels.  Thanks to Darshaka Pathirana for the
+report.  (Closes: #987498)
+
+ -- James McCoy   Tue, 27 Apr 2021 07:44:43 -0400
+
 vim-scripts (20210124) unstable; urgency=medium
 
   * color_sampler_pack:
diff -Nru vim-scripts-20210124/debian/patches/sokoboan_path.diff 
vim-scripts-20210124.1/debian/patches/sokoboan_path.diff
--- vim-scripts-20210124/debian/patches/sokoboan_path.diff  2021-01-24 
18:58:45.0 -0500
+++ vim-scripts-20210124.1/debian/patches/sokoboan_path.diff2021-04-27 
07:44:43.0 -0400
@@ -10,7 +10,7 @@
  finish
  endif
  let loaded_VimSokoban = 1
-+let g:SokobanLevelDirectory = "/usr/share/vim-scripts/sokoban-levels/"
++let g:SokobanLevelDirectory = 
"/usr/share/vim-scripts/VimSokoban/plugin/VimSokoban/"
  
  " Allow the user to specify the location of the sokoban levels
  if (!exists("g:SokobanLevelDirectory"))

Bug#987658: unblock: openjdk-11-jre-dcevm/11.0.11+9-1

[Paul Gevers]

Hi Emmanuel

On 01-05-2021 14:43, Emmanuel Bourg wrote:
> Every time OpenJDK is
> updated in Debian, the corresponding DCEVM package has to be updated as
> well, otherwise it's likely to fail or crash. That's exactly what
> happens currently in testing, we have OpenJDK 11.0.11 with DCEVM
> 11.0.10, and DCEVM just crashes (a simple invocation of "java -dcevm
> -version" throws an error).

But OpenJDK 11.0.11 was uploaded two months ago, when we were still in
the soft freeze. Why didn't you fix openjdk-11-jre-dcevm then? If your
package is so tightly tied to the version of openjdk I would expect
mechanisms to be in place to warn you of the upload and to prevent
migration of openjdk-11 in case of breakage. E.g. autopkgtest is very
well suited to prevent the migration because it's integrated with our
migration software. Having an autopkgtest has the additional benefit
that at this stage of the release, you're package isn't blocked if it
passes on all architecture and you wouldn't need to bother us with an
unblock request. How do you normally get triggered to update you package?

> I agree the diff is not reviewable, but it can be seen as an update of
> the DCEVM code to the same state as the OpenJDK code that was already
> accepted in testing.

Two months ago, in a different stage of the release.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987930: Rendering typo regarding bug title of package removal requests

[Tobias Wiese]

tags -1 patch
thanks

Hi,

On 21-05-02 10:14:42, Simon Josefsson wrote:
> The source code says:
> 
>  ``RM:``\ *package[architecture list]*\ ``--``\ *reason*, where *package*

The escaped space ("\ ") is removed when sphinx renders the document.

This happened at multiple points. I attached a patch, that fixes all
occurrences I found.

Tobias Wiese

-- 
Tobias Wiese
PGP KEY: https://tobiaswiese.com/pgp.asc
PGP FPR: E1A7A8879BAD75B42D63F3310F067C2DD70E89A0
From b41af23ee9b2d1268c4c24cfc22da270bc186f27 Mon Sep 17 00:00:00 2001
From: Tobias Wiese 
Date: Sun, 2 May 2021 21:07:38 +0200
Subject: [PATCH] Add lost spaces to parts that include literals. Closes
 #987930

At some locations e.g. in Bug title recommendations, literal parts
are mixed with other parts.
These parts had spaces escaped, which resulted in them not showing up in
the final document.

Signed-off-by: Tobias Wiese 
---
 source/pkgs.rst  | 21 ++---
 source/tools.rst |  2 +-
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/source/pkgs.rst b/source/pkgs.rst
index ed6f55e..c131649 100644
--- a/source/pkgs.rst
+++ b/source/pkgs.rst
@@ -25,7 +25,7 @@ including, but not limiting yourself to, the description of the package
 (so that others can review it), the license of the prospective package,
 and the current URL where it can be downloaded from.
 
-You should set the subject of the bug to ``ITP:``\ *foo*\ ``--``\ *short
+You should set the subject of the bug to ``ITP:`` *foo* ``--`` *short
 description*, substituting the name of the new package for *foo*. The
 severity of the bug report must be set to ``wishlist``. Please send a
 copy to ``debian-de...@lists.debian.org`` by using the X-Debbugs-CC
@@ -122,7 +122,7 @@ minimum, you should try the following activities (you'll need to have an
 older version of the same Debian package around):
 
 -  Run ``lintian`` over the package. You can run ``lintian`` as follows:
-   ``lintian -v``\ *package-version*\ ``.changes``. This will check the
+   ``lintian -v`` *package-version*\ ``.changes``. This will check the
source package as well as the binary package. If you don't understand
the output that ``lintian`` generates, try adding the ``-i`` switch,
which will cause ``lintian`` to output a very verbose description of
@@ -387,7 +387,7 @@ uploading to ``ftp.upload.debian.org`` in upload-directory
 ``DELAYED/``\ *X*\ ``-day`` (*X* between 0 and 15). 0-day is uploaded
 multiple times per day to ``ftp.upload.debian.org``.
 
-With dput, you can use the ``--delayed``\ *DELAY* parameter to put the
+With dput, you can use the ``--delayed`` *DELAY* parameter to put the
 package into one of the queues.
 
 .. _s5.6.4:
@@ -722,7 +722,7 @@ applied to the tag ``fixed-in-experimental``.
 
 If you happen to mistype a bug number or forget a bug in the changelog
 entries, don't hesitate to undo any damage the error caused. To reopen
-wrongly closed bugs, send a ``reopen``\ *XXX* command to the bug
+wrongly closed bugs, send a ``reopen`` *XXX* command to the bug
 tracking system's control address, ``cont...@bugs.debian.org``. To close
 any remaining bugs that were fixed by your upload, email the
 ``.changes`` file to *XXX*\ ``-d...@bugs.debian.org``, where *XXX* is
@@ -1068,7 +1068,7 @@ is an old compatibility library which is no longer required), you need
 to file a bug against ``ftp.debian.org`` asking that the package be
 removed; as with all bugs, this bug should normally have normal
 severity. The bug title should be in the form
-``RM:``\ *package[architecture list]*\ ``--``\ *reason*, where *package*
+``RM:`` *package [architecture list]* ``--`` *reason*, where *package*
 is the package to be removed and *reason* is a short summary of the
 reason for the removal request. *[architecture list]* is optional and
 only needed if the removal request only applies to some architectures,
@@ -1121,8 +1121,7 @@ and https://qa.debian.org/howto-remove.html\ .
 If in doubt concerning whether a package is disposable, email
 ``debian-de...@lists.debian.org`` asking for opinions. Also of interest
 is the ``apt-cache`` program from the ``apt`` package. When invoked as
-``apt-cache
-showpkg``\ *package*, the program will show details for *package*,
+``apt-cache showpkg`` *package*, the program will show details for *package*,
 including reverse depends. Other useful programs include
 ``apt-cache rdepends``, ``apt-rdepends``, ``build-rdeps`` (in the
 ``devscripts`` package) and ``grep-dctrl``. Removal of orphaned packages
@@ -1190,7 +1189,7 @@ If you can no longer maintain a package, you need to inform others, and
 see that the package is marked as orphaned. You should set the package
 maintainer to ``Debian QA Group `` and submit a
 bug report against the pseudo package ``wnpp``. The bug report should be
-titled ``O:``\ *package*\ ``--``\ *short description* indicating that
+titled ``O:`` *package* ``--`` *short description* indicating that
 the package is now orphaned. The severity of the bug 

Bug#987963: pymol: flaky autopkgtest on arm64: hits autopkgtest timeout

[Paul Gevers]

Source: pymol
Version: 2.4.0+dfsg-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, because of the failure
"caused" by glbic, I looked into the history of your autopkgtest [1] and
I noticed it fails regularly on arm64 because it hits the autopkgtest
timeout after 2:47 hours.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Paul

[1] https://ci.debian.net/packages/p/pymol/testing/arm64/

https://ci.debian.net/data/autopkgtest/testing/arm64/p/pymol/11477449/log.gz

Run 'pymol -c
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/build_peptide.py'...
Skip
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/contact.pml
Skip
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/dali.py
Skip
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/density.pml
Skip
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/groel_es.pml
Skip
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/multiclip_ray.pml
Skip
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/packing.pml
Skip
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/packsurf.pml
Skip
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/ref_frame.pml
Skip
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/ribosome.pml
:1: DeprecationWarning: the imp module is deprecated in favour
of importlib; see the module's documentation for alternative uses
Run 'pymol -c
/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src/examples/cookbook/scenes2movie.pml'...
:1: DeprecationWarning: the imp module is deprecated in favour
of importlib; see the module's documentation for alternative uses
autopkgtest [04:22:04]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.q81vxtos/downtmp/build.HQz/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.q81vxtos/downtmp/command1-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.q81vxtos/downtmp/command1-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.q81vxtos/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.q81vxtos/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=4; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; touch
/tmp/autopkgtest-lxc.q81vxtos/downtmp/command1-stdout
/tmp/autopkgtest-lxc.q81vxtos/downtmp/command1-stderr; bash -ec 'sh
debian/tests/call-pymol-scripts examples/ \
"(start_pymol)|(xmlrpc01)|(sd_annotate)|(povray01)|(contact)|(dali)|(density)|(groel_es)|(packing)|(packsurf)|(ref_frame)|(ribosome)|(ss_xfer)|(multiclip_ray)|(tkwindow)"'
2> >(tee -a /tmp/autopkgtest-lxc.q81vxtos/downtmp/command1-stderr >&2) >
>(tee -a /tmp/autopkgtest-lxc.q81vxtos/downtmp/command1-stdout);" (kind:
test)
autopkgtest [04:22:04]: test command1: ---]




OpenPGP_signature
Description: OpenPGP digital signature

Bug#987961: systemd-udevd using 100% of CPU

[Aaron Small]

Package: systemd-udevd
Version: upowerd
Severity: normal
X-Debbugs-Cc: a.sm...@unb.ca

After plugging a USB-powered light into a USB port (I have used the same light
in the same port many times before, but certainly possible that it broke since
the last time I used it) the light did not turn on,I get continuous repeated
messages in syslog and systemd-udevd is using 100% of the CPU.

When I plug the lamp in, I see this:

May  2 15:06:59 beta kernel: [18507.692791] usb usb4-port2: over-current
condition
May  2 15:06:59 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1d.0/usb3/3-1/3-1:1.0
May  2 15:06:59 beta kernel: [18507.832869] usb 3-1-port3: over-current
condition
May  2 15:06:59 beta kernel: [18507.908867] usb usb2-port1: over-current
condition
May  2 15:06:59 beta kernel: [18507.908908] usb usb4-port1: over-current
condition
May  2 15:06:59 beta kernel: [18508.124875] usb usb2-port2: over-current
condition
May  2 15:06:59 beta kernel: [18508.124937] usb usb4-port2: over-current
condition
May  2 15:06:59 beta kernel: [18508.136867] usb 3-1-port3: over-current
condition
May  2 15:06:59 beta kernel: [18508.340867] usb usb2-port1: over-current
condition
May  2 15:06:59 beta kernel: [18508.340909] usb usb4-port1: over-current
condition
May  2 15:06:59 beta kernel: [18508.352860] usb 3-1-port4: over-current
condition
May  2 15:07:00 beta kernel: [18508.556738] usb usb4-port2: over-current
condition
May  2 15:07:00 beta kernel: [18508.556762] usb usb2-port2: over-current
condition
May  2 15:07:00 beta kernel: [18508.656865] usb 3-1-port3: over-current
condition
May  2 15:07:00 beta kernel: [18508.772814] usb usb4-port1: over-current
condition
May  2 15:07:00 beta kernel: [18508.772846] usb usb2-port1: over-current
condition
May  2 15:07:00 beta kernel: [18508.872863] usb 3-1-port4: over-current
condition
May  2 15:07:00 beta kernel: [18508.988745] usb usb4-port2: over-current
condition
May  2 15:07:00 beta kernel: [18508.988771] usb usb2-port2: over-current
condition
May  2 15:07:00 beta kernel: [18509.176940] usb 3-1-port3: over-current
condition
May  2 15:07:00 beta kernel: [18509.204731] usb usb4-port1: over-current
condition
May  2 15:07:00 beta kernel: [18509.204745] usb usb2-port1: over-current
condition
May  2 15:07:00 beta kernel: [18509.393089] usb 3-1-port4: over-current
condition
May  2 15:07:00 beta kernel: [18509.420731] usb usb2-port2: over-current
condition
May  2 15:07:00 beta kernel: [18509.420748] usb usb4-port2: over-current
condition
May  2 15:07:01 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1d.0/usb3/3-1/3-1:1.0
May  2 15:07:01 beta kernel: [18509.608855] usb 3-1-port3: over-current
condition
May  2 15:07:01 beta kernel: [18509.636718] usb usb4-port1: over-current
condition
May  2 15:07:01 beta kernel: [18509.636730] usb usb2-port1: over-current
condition
May  2 15:07:01 beta kernel: [18509.852717] usb usb2-port2: over-current
condition
May  2 15:07:01 beta kernel: [18509.852742] usb usb4-port2: over-current
condition


When I unplug the lamp, I see this:

May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb2/2-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb2/2-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb2/2-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb2/2-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb2/2-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb2/2-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb4/4-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event as add on
/sys/devices/pci:00/:00:1c.3/:03:00.0/usb2/2-0:1.0
May  2 15:07:39 beta upowerd[1306]: treating change event 

Bug#987960: Backport fixes from libass 0.15.1

[Nils König]

Source: libass
Version: 1:0.15.0-1
Severity: normal
Tags: patch

Hi,

as you may already have noticed libass 0.15.1 was released recently and fixes
many bugs. I believe at least one of those fixes needs to be pulled into 
Debian.

0.15.0 introduced a regression leading to reliable crashes on some files with
embedded fonts. Without this fix some subtitle files will be plain unplayable
and cause the libass-using application to segfault.
Attached a patch with the relevant upstream commits as 'fix-emf-crash.patch';
it's rebased to apply cleanly on top of current Debian master.

Furthermore, 0.15.1 includes another fix for an older embedded font bug
preventing most libass-API-users from actually utilising embedded fonts as 
they only worked with a specific API-call order. This prevents eg VLC from 
correctly displaying subtitles with embedded fonts. Applying this fix on 
libass' side, will instantly make embedded fonts work in VLC, without further 
changes being neccesary.
I believe, while less severe than crashing, it would be a very good idea to 
also backport this fix to Debian.
Attached a patch with the relevant upstream commits as 'fix-emf-render.patch';
it's rebased to apply cleanly on Debian master + previous patch.


However, as upstream's release notes state, 0.15.1 is a pure bugfix release 
with no actual API changes or additions and there are a number of additional
bugfixes. Perhaps a full upgrade to 0.15.1 would also be a good idea?
But then again, the "Hard Freeze" already started and I'm not sure what the 
guidelines say about pure bugfix releases from an upstream that doesn't 
regularly provide stable bugfix releases.
So, I just thought I'd mention it and leave it up to your judgement :)

Here's the relevant part of upstream's release text:
> This is purely a bug fix and polish release, with no significant API or ABI
> changes.
>
> The only API change is that `ass_add_font` is now declared to accept
> `const char *`. Previously it took only `char *`, but const has worked in
> practice since the very first standalone libass release.
>
> [Full text with a list of all fixes:
>  https://github.com/libass/libass/releases/tag/0.15.1 ]


Cheers
Nils König

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

Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: openrc (via /run/openrc)
PID 1: openrc-init
LSM: AppArmor: enabled
From 4830494fcdcf2cf67f35d92cade1a60713a2fdd1 Mon Sep 17 00:00:00 2001
From: Oleg Oshmyan 
Date: Tue, 27 Oct 2020 15:46:04 +0200
Subject: [PATCH 1/2] Fix crashes on some files with embedded fonts

Squashed from upstream commits 017137471d0043e0321e377ed8da48e45a3ec632
and 59eb317aaa495ad5331c9efdf8d7bf3d860c2992

== Commit message from 017137471d0043e0321e377ed8da48e45a3ec632:
decode_font: fix subtraction broken by change to unsigned type

This caused a one-byte buffer overwrite and an assertion failure.

Regression in commit 910211f1c0078e37546f73e95306724358b89be2.

Discovered by OSS-Fuzz.

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26674.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26678.

== Commit Message from 59eb317aaa495ad5331c9efdf8d7bf3d860c2992
Match more types and format specifiers to size_t fontdata_used

Omissions in commit 910211f1c0078e37546f73e95306724358b89be2.

Microsoft's C library does not support %zu until Universal CRT
(Visual Studio 2015). At worst, this verbose-level message will
look wrong and be useless.
---
 libass/ass.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libass/ass.c b/libass/ass.c
index 428a332..51fa201 100644
--- a/libass/ass.c
+++ b/libass/ass.c
@@ -820,7 +820,7 @@ static unsigned char *decode_chars(const unsigned char *src,
unsigned char *dst, size_t cnt_in)
 {
 uint32_t value = 0;
-for (int i = 0; i < cnt_in; i++)
+for (size_t i = 0; i < cnt_in; i++)
 value |= (uint32_t) ((src[i] - 33u) & 63) << 6 * (3 - i);
 
 *dst++ = value >> 16;
@@ -850,14 +850,14 @@ static int decode_font(ASS_Track *track)
 size_t dsize;  // decoded size
 unsigned char *buf = 0;
 
-ass_msg(track->library, MSGL_V, "Font: %d bytes encoded data",
+ass_msg(track->library, MSGL_V, "Font: %zu bytes encoded data",
 track->parser_priv->fontdata_used);
 size = track->parser_priv->fontdata_used;
 if (size % 4 == 1) {
 ass_msg(track->library, MSGL_ERR, "Bad encoded data size");
 goto error_decode_font;
 }
-buf = malloc(size / 4 * 3 + FFMAX(size % 4 - 1, 0));
+buf = malloc(size / 4 * 3 + FFMAX(size % 4, 1) - 1);
 if (!buf)
 goto error_decode_font;
 q = buf;
@@ -871,7 +871,7 @@ static int decode_font(ASS_Track *track)
 q = decode_chars(p, q, 3);
 }

Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!

[Dmitriy Matrosov]

Package: bash
Version: 5.1-2+b1
Followup-For: Bug #806256

Hi.

This bug seems the same as "fixed" bugs #805605 and #810660, which are
definitely not fixed yet.  The freeze is caused by vt switch performed by
'clear_console', and the commited "fix" just changed vt (choosed for switch)
from 1 and 2 to 5 and 6:

@@ -205,7 +205,7 @@
 #if defined(__linux__)
   num = vtstat.v_active;
 #endif
-  tmp_num = (num == 1 ? 2 : 1);
+  tmp_num = (num == 6 ? 5 : 6);

   /* switch vt to clear the scrollback buffer */
   if (ioctl(fd, VT_ACTIVATE, tmp_num))

So, since this can't fix anything, the bug is easily reproducible:

1. Start X on vt 6.
2. Log in at any other vt.
3. Run '/usr/bin/clear_console' and X crashes/freezes.



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

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

Versions of packages bash depends on:
ii  base-files   11
ii  debianutils  4.11.2
ii  libc62.31-11
ii  libtinfo66.2+20201114-2

Versions of packages bash recommends:
ii  bash-completion  1:2.11-2

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#922873: linux-image-4.19.0-3-amd64: nouveau "PGRAPH TLB flush idle timeout fail" errors, machine unresponsive via ssh

[Salvatore Bonaccorso]

Hi,

On Sun, May 02, 2021 at 06:36:50PM +0200, Vincent Lefevre wrote:
> Control: tags -1 - fixed-upstream
> 
> Removing the fixed-upstream tags to avoid confusion since the bug
> is still open upstream and I've never heard of any fix.

Yes, makes sense (the fixed-upstream came from the debian-bts-link).

Regards,
Salvatore

Bug#987951: Error 500 during HTTP authentication

[Wessel Dankers]

Package: python3-klaus
Version: 1.5.2-1
Severity: normal
Tags: upstream, fixed-upstream, patch

Dear maintainer,

If basic/digest authentication is configured and authentication is
required, klaus fails with HTTP error 500. The server log shows:

TypeError: sequence of byte string values expected, value of type str 
found

This problem is already fixed upstream, in particular in the following
lines:

--- httpauth/httpauth.py
+++ klaus/httpauth.py
@@ -132,7 +132,8 @@
 '401 Authentication Required',
 [('WWW-Authenticate', make_www_authenticate_header(self.realm))],
 )
-return ['401 - Authentication Required']
+html = '401 - Authentication Required'
+return [html if PY2 else html.encode()]

Updating the vendored copy of httpauth should fix this issue.

Met vriendelijke groet,
Wessel Dankers

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.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 python3-klaus depends on:
ii  python3   3.9.2-3
ii  python3-dulwich   0.20.15-1
ii  python3-flask 1.1.2-2
ii  python3-humanize  3.2.0-1
ii  python3-pygments  2.7.1+dfsg-2
ii  python3-six   1.15.0-2
ii  python3-werkzeug  1.0.1+dfsg1-2

Versions of packages python3-klaus recommends:
ii  python3-chardet4.0.0-1
ii  python3-distutils  3.9.2-1
ii  python3-docutils   0.16+dfsg-4
pn  python3-markdown   

Versions of packages python3-klaus suggests:
pn  exuberant-ctags   
pn  uwsgi-plugin-python3 | gunicorn3  

-- no debconf information

Bug#987959: pev: peres affected by off-by-one error in libpe

[Benoit Sevens]

Package: pev
Version: 0.81-2
Severity: grave
Tags: patch security
Justification: user security hole
X-Debbugs-Cc: benoit.sev...@gmail.com, Debian Security Team 


Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

libpe has an off-by-one error which is fixed upstream. libpe is included in the 
pev package. peres calls functions within libpe. Running peres on certain files 
triggers the off-by-one error. Applying the patch fixes the issue.

-- System Information:
Debian Release: rodete
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.26-1rodete1-amd64 (SMP w/6 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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pev depends on:
ii  libc6  2.31-11
ii  libssl1.1  1.1.1k-1

pev recommends no packages.

pev suggests no packages.

-- no debconf information
>From 5737a97c57be175333fc0c6f51bb2cdd7101c17e Mon Sep 17 00:00:00 2001
From: Jardel Weyrich 
Date: Mon, 18 Jan 2021 22:03:49 -0300
Subject: [PATCH] utils: Fix off-by-one error in pe_utils_str_widechar2ascii.

---
 utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils.c b/utils.c
index bd2da84..f05ba67 100644
--- a/utils.c
+++ b/utils.c
@@ -132,7 +132,7 @@ char *pe_utils_str_array_join(char *strings[], size_t 
count, char delimiter) {
 
 void pe_utils_str_widechar2ascii(char *output, const char *widechar, size_t 
length) {
// quick & dirty UFT16 to ASCII conversion
-   for (size_t p = 0; p <= length; p++) {
+   for (size_t p = 0; p < length; p++) {
memcpy(output + p, (uint16_t *)(widechar) + p, 1);
}
 }
>From 5737a97c57be175333fc0c6f51bb2cdd7101c17e Mon Sep 17 00:00:00 2001
From: Jardel Weyrich 
Date: Mon, 18 Jan 2021 22:03:49 -0300
Subject: [PATCH] utils: Fix off-by-one error in pe_utils_str_widechar2ascii.

---
 utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils.c b/utils.c
index bd2da84..f05ba67 100644
--- a/utils.c
+++ b/utils.c
@@ -132,7 +132,7 @@ char *pe_utils_str_array_join(char *strings[], size_t 
count, char delimiter) {
 
 void pe_utils_str_widechar2ascii(char *output, const char *widechar, size_t 
length) {
// quick & dirty UFT16 to ASCII conversion
-   for (size_t p = 0; p <= length; p++) {
+   for (size_t p = 0; p < length; p++) {
memcpy(output + p, (uint16_t *)(widechar) + p, 1);
}
 }
>From 5737a97c57be175333fc0c6f51bb2cdd7101c17e Mon Sep 17 00:00:00 2001
From: Jardel Weyrich 
Date: Mon, 18 Jan 2021 22:03:49 -0300
Subject: [PATCH] utils: Fix off-by-one error in pe_utils_str_widechar2ascii.

---
 utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils.c b/utils.c
index bd2da84..f05ba67 100644
--- a/utils.c
+++ b/utils.c
@@ -132,7 +132,7 @@ char *pe_utils_str_array_join(char *strings[], size_t 
count, char delimiter) {
 
 void pe_utils_str_widechar2ascii(char *output, const char *widechar, size_t 
length) {
// quick & dirty UFT16 to ASCII conversion
-   for (size_t p = 0; p <= length; p++) {
+   for (size_t p = 0; p < length; p++) {
memcpy(output + p, (uint16_t *)(widechar) + p, 1);
}
 }

Bug#987958: buster-pu: package liferea/1.12.6-1+deb10u1

[Paul Gevers]

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

Dear Adam,

[ Reason ]
It used to be enough to declare the liferea custom scheme as local to
access resources with a file scheme, but for WebKit2Gtk >= 2.32 it looks
like it is necessary to register the custom scheme with a handler.
Although WebKit2Gtk hasn't been updated to 2.32 in stable yet, I
understand that it will be relatively soon for security support reasons.

Thanks to pabs for filing the bug (in unstable). Upstream fixed the
issue already and the patch is taken from there. I had to adapt it to
apply cleanly, but upstream was nice and confirmed that what I did was sane.

[ Impact ]
The summary bar in the main window will look odd.

[ Tests ]
Unfortunately, none. I still want to teach myself how to use qemu, but
otherwise I don't have the ability to try out the liferea with the change.

[ Risks ]
The involved code is not very complex.

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

[ Changes ]
Adapted upstream patch to work correctly with WebKit2Gtk >= 2.32.

[ Other info ]
I have chosen to not upload already, because I can't say that the patch
has been tested yet. If you agree that the risk is low, I'll go ahead
with the upload.

Paul
diff -Nru liferea-1.12.6/debian/changelog liferea-1.12.6/debian/changelog
--- liferea-1.12.6/debian/changelog 2018-12-09 21:44:09.0 +0100
+++ liferea-1.12.6/debian/changelog 2021-04-30 20:54:00.0 +0200
@@ -1,3 +1,10 @@
+liferea (1.12.6-1+deb10u1) buster; urgency=medium
+
+  * Add patch to work with webkit2gtk >= 2.32:
+34d26be00328a68d2f1625c78b54dc168da0648e.patch (Closes: #987448)
+
+ -- Paul Gevers   Fri, 30 Apr 2021 20:54:00 +0200
+
 liferea (1.12.6-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
liferea-1.12.6/debian/patches/34d26be00328a68d2f1625c78b54dc168da0648e.patch 
liferea-1.12.6/debian/patches/34d26be00328a68d2f1625c78b54dc168da0648e.patch
--- 
liferea-1.12.6/debian/patches/34d26be00328a68d2f1625c78b54dc168da0648e.patch
1970-01-01 01:00:00.0 +0100
+++ 
liferea-1.12.6/debian/patches/34d26be00328a68d2f1625c78b54dc168da0648e.patch
2021-04-30 20:54:00.0 +0200
@@ -0,0 +1,52 @@
+From 0b199d75be2bc41575de71ed5b5e0a6aa08c30bd Mon Sep 17 00:00:00 2001
+From: Laetitia Berthelot 
+Date: Mon, 5 Apr 2021 14:26:38 +0200
+Subject: [PATCH] Register liferea custom scheme, fixes #973
+
+It used to be enought to declare the liferea custom scheme as local to
+access resources with file scheme, but for WebKit2Gtk >= 2.32 it looks
+like it is necessary to register the custom scheme with a handler.
+
+The handler doesn't do anything interesting for now as we just pass the
+content with webkit_web_view_load_bytes and use the file scheme to
+access resources, but it could be used to load Liferea resources in the
+future ...
+---
+ src/webkit/webkit.c | 17 +
+ 1 file changed, 17 insertions(+)
+
+diff --git a/src/webkit/webkit.c b/src/webkit/webkit.c
+index cc90e4ba0..e43c58149 100644
+--- a/src/webkit/webkit.c
 b/src/webkit/webkit.c
+@@ -370,6 +370,21 @@ liferea_webkit_impl_download_started (WebKitWebContext
*context,
+ }
+ 
+ static void
++liferea_webkit_handle_liferea_scheme (WebKitURISchemeRequest *request, 
gpointer user_data)
++{
++  const gchar *uri = webkit_uri_scheme_request_get_uri (request);
++  GInputStream *stream;
++  gssize length;
++  gchar *contents;
++
++  contents = g_strdup_printf ("Placeholder handler for liferea scheme. 
URI requested : %s", uri);
++  length = (gssize) strlen (contents);
++  stream = g_memory_input_stream_new_from_data (contents, length, g_free);
++  webkit_uri_scheme_request_finish (request, stream, length, 
"text/plain");
++  g_object_unref (stream);
++}
++
++static void
+ liferea_webkit_impl_init (LifereaWebKitImpl *self)
+ {
+   gbooleandisable_javascript, enable_plugins;
+@@ -379,6 +394,8 @@ liferea_webkit_impl_init (LifereaWebKitImpl *self)
+   self->dbus_connections = NULL;
+   self->settings = webkit_settings_new ();
+   font = webkit_get_font ();
++  webkit_web_context_register_uri_scheme 
(webkit_web_context_get_default(), "liferea",
++  (WebKitURISchemeRequestCallback) 
liferea_webkit_handle_liferea_scheme,NULL,NULL);
+ 
+   security_manager = webkit_web_context_get_security_manager 
(webkit_web_context_get_default ());
+   webkit_security_manager_register_uri_scheme_as_local (security_manager, 
"liferea");
diff -Nru liferea-1.12.6/debian/patches/series 
liferea-1.12.6/debian/patches/series
--- liferea-1.12.6/debian/patches/series2018-12-09 21:44:09.0 
+0100
+++ liferea-1.12.6/debian/patches/series2021-04-30 20:54:00.0 
+0200
@@ -1,3 +1,4 @@
 debian-example-feeds.patch
 

Bug#987956: libgcrypt20: ECDH decryption fails with "gpg: public key decryption failed: Invalid object" error message

[Andreas Metzler]

Control: severity -1 serious

On 2021-05-02 "Xavier G."  wrote:
> Package: libgcrypt20
> Version: 1.8.7-4
> Severity: important

> Dear Maintainer,

> After a full-upgrade in Sid on 2021-05-02, `gpg --decrypt somefile.gpg` fails:
[...]
> Considering the list of updated packages this day, libgcrypt20:amd64 (1.8.7-3,
> 1.8.7-4) is the likely culprit.  Its changelog states:

>   libgcrypt20 (1.8.7-4) unstable; urgency=medium

> * Update from LIBGCRYPT-1.8-BRANCH:
>   + 30_07-Fix-previous-commit.patch
>   + 30_08-ecc-Check-the-input-length-for-the-point.patch

>-- Andreas Metzler   Sun, 02 May 2021 13:58:47 +0200

> The second patch is precisely about returning "Invalid object" /
> GPG_ERR_INV_OBJ in some case related to GnuPG and ECDH decryption.

> Therefore, could you please double-check this patch?

Looks fishy, but I have not got time check now. Lets bump the severity
to make double-sure it does not propagate to testing.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#987839: apt-listbugs: daily cleanup runs hourly

[Francesco Poli]

On Sat, 1 May 2021 11:31:19 -0700 Ross Boylan wrote:

[...]
> On Fri, Apr 30, 2021 at 2:47 PM Francesco Poli
>  wrote:
[...]
> > Does logcheck send e-mail messages for all the other systemd timers?
> >
> > As you may already know, you can get a list of active systemd timers on
> > your box with the following command:
> >
> >   $ systemctl list-timers
> >
> Thanks for the tip; I wasn't familiar with list-timers.  There are 11
> on my list, but the only things I see in my hourly reports from
> logcheck were  apt-listbugs and complaints about time synchronization.

Do you have anacron installed?
It's another package that has an hourly systemd timer.

I wonder why logcheck does not send hourly mail messages about
anacron...

> Of course, I don't know how many of the timers are hourly.

The command 'systemctl list-timers' should tell you: just look at the
LEFT and PASSED columns.

Or you could read the timer definitions, if you know (or learn) the
syntax and semantics...

[...]
> I tried this modification to apt-listbugs.timer:
> [Timer]
> OnActiveSec=5min
> #OnCalendar=*-*-* *:20
> OnUnitActiveSec=23h 50m
> RandomizedDelaySec=20min
> 
> which did  fix the "running every hour" problem (even if the run is
> only to check if a real  update is necessary).
> But this does not entirely meet the desired behavior expressed in 932995:
[...]

Not only that, but there's also another issue with this modification.

The timer would only trigger once every (slightly less than one) day:
if your system is not online during that only attempt, you are out of
luck for another day or so...

> > >
> > > Another work-around for the visible annoyance would be for me to tell
> > > logcheck to ignore the relevant messages.
> >
> > I think this should be the way to avoid the annoyance.
> 
> It avoids the annoyance of seeing the message, but it leaves the job
> firing every hour.

I think this is needed to have some reasonable chance to get one
successful cleanup operation a day.

[...]
> > If you do not object, I will close this bug report.
> >
> I suppose, though, as observed in the other bug you mentioned, the
> message about "daily update" is confusing.  The fact that other
> packages aren't exhibiting such behavior suggests there is some other
> way to handle this, but I certainly don't know what it is.

I am open to suggestions on how to change the Description field for the
timer.
I see that the Description for the anacron timer is "Trigger anacron
every hour": maybe I should think about a Description that uses the
word "hourly", rather than "daily".

But then I am afraid I would get bug reports from people saying that an
hourly cleanup is too frequent and asking to reduce the frequency to
daily!

I think that applying the principle of least surprise is especially
tricky in this case...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpCBPJIoZoVX.pgp
Description: PGP signature

Bug#987957: unblock: pypy/7.3.3+dfsg-2 pypy3/7.3.3+dfsg-4

[Stefano Rivera]

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

Please unblock packages pypy & pypy3:

 pypy (7.3.3+dfsg-2) unstable; urgency=medium
 .
   * Move pypy dependencies to Pre-Depends, as the pypy binary is used in
 package maintainer scripts. (Closes: #987213)

 pypy3 (7.3.3+dfsg-4) unstable; urgency=medium
 .
   * Move pypy3 dependencies to Pre-Depends, as the pypy3 binary is used in
 package maintainer scripts. (Closes: #987908)
   * Remove pydoc getfile feature. (CVE-2021-3426)
   * security: Restrict ftplib PASV hosts (no CVE assigned).

[ Reason ]

Promoting pypy dependencies from Depends to Pre-Depends, so that
reverse-dependencies maintainer script execution is delayed until pypy's
dependencies are in in place. (See: #987213)

pypy3 (not a key package) gets the same patch, and a couple of security
updates from upstream hg.

[ Impact ]
Upgrades of pypy libraries from buster to bullseye may fail, without
this patch.

[ Tests ]
autopkgtests verify the broad functionality of the language. piuparts
testing will be the best way to see that upgrading is now reliable.

[ Risks ]
Increasing Pre-Depends isn't ideal, and some of these libraries aren't
needed for pypycompile/pypy3compile to run. But manually splitting the
Pre-Depends and Depends risks more complexity and mistakes in the
future.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

unblock pypy/7.3.3+dfsg-2
unblock pypy3/7.3.3+dfsg-4

SR
diff -Nru pypy3-7.3.3+dfsg/debian/changelog pypy3-7.3.3+dfsg/debian/changelog
--- pypy3-7.3.3+dfsg/debian/changelog   2021-02-25 14:55:51.0 -0400
+++ pypy3-7.3.3+dfsg/debian/changelog   2021-05-02 12:34:45.0 -0400
@@ -1,3 +1,12 @@
+pypy3 (7.3.3+dfsg-4) unstable; urgency=medium
+
+  * Move pypy3 dependencies to Pre-Depends, as the pypy3 binary is used in
+package maintainer scripts. (Closes: #987908)
+  * Remove pydoc getfile feature. (CVE-2021-3426)
+  * security: Restrict ftplib PASV hosts (no CVE assigned).
+
+ -- Stefano Rivera   Sun, 02 May 2021 12:34:45 -0400
+
 pypy3 (7.3.3+dfsg-3) unstable; urgency=medium
 
   * Patch: CVE-2021-23336: Only use '&' as a query string separator.
diff -Nru pypy3-7.3.3+dfsg/debian/control pypy3-7.3.3+dfsg/debian/control
--- pypy3-7.3.3+dfsg/debian/control 2021-02-25 14:55:51.0 -0400
+++ pypy3-7.3.3+dfsg/debian/control 2021-05-02 12:34:45.0 -0400
@@ -36,11 +36,15 @@
 
 Package: pypy3
 Architecture: any
-Depends: pypy3-lib (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}
 Breaks: pypy3-dev (<< ${source:Version})
 Provides: ${pypy3-abi}
 Suggests: pypy3-doc, pypy3-tk (= ${binary:Version})
-Pre-Depends: dpkg (>= 1.15.6~), ${misc:Pre-Depends}
+Pre-Depends:
+ dpkg (>= 1.15.6~),
+ pypy3-lib (= ${binary:Version}),
+ ${misc:Pre-Depends},
+ ${shlibs:Pre-Depends}
 Description: fast alternative implementation of Python 3.x - PyPy interpreter
  PyPy is a fast, compliant alternative implementation of the Python language
  (3.x). It has several advantages and distinct features:
diff -Nru pypy3-7.3.3+dfsg/debian/patches/cve-2021-3426 
pypy3-7.3.3+dfsg/debian/patches/cve-2021-3426
--- pypy3-7.3.3+dfsg/debian/patches/cve-2021-3426   1969-12-31 
20:00:00.0 -0400
+++ pypy3-7.3.3+dfsg/debian/patches/cve-2021-3426   2021-05-02 
12:34:45.0 -0400
@@ -0,0 +1,77 @@
+From: Matti Picus 
+Date: Sun, 2 May 2021 10:57:58 -0400
+Subject: Stdlib: Remove the pydoc getfile feature (bpo 42988) (CVE-2021-3426)
+
+Bug-cPython: https://bugs.python.org/issue42988
+Origin: upstream, 
https://foss.heptapod.net/pypy/pypy/-/commit/f66a96388f8a0ba125005d5d524a31dfd3878a18
+---
+ lib-python/3/pydoc.py   | 18 --
+ lib-python/3/test/test_pydoc.py |  6 --
+ 2 files changed, 24 deletions(-)
+
+diff --git a/lib-python/3/pydoc.py b/lib-python/3/pydoc.py
+index b521a55..5247ef9 100644
+--- a/lib-python/3/pydoc.py
 b/lib-python/3/pydoc.py
+@@ -2312,9 +2312,6 @@ def _url_handler(url, content_type="text/html"):
+ %s%s%s
+ ''' % (title, css_link, html_navbar(), contents)
+ 
+-def filelink(self, url, path):
+-return '%s' % (url, path)
+-
+ 
+ html = _HTMLDoc()
+ 
+@@ -2400,19 +2397,6 @@ def _url_handler(url, content_type="text/html"):
+ 'key = %s' % key, '#ff', '#ee77aa', ''.join(results))
+ return 'Search Results', contents
+ 
+-def html_getfile(path):
+-"""Get and display a source file listing safely."""
+-path = urllib.parse.unquote(path)
+-with tokenize.open(path) as fp:
+-lines = html.escape(fp.read())
+-body = '%s' % lines
+-heading = html.heading(
+-'File Listing',
+-'#ff', '#7799ee')
+-contents = heading + html.bigsection(
+-'File: %s' % path, '#ff', '#ee77aa', 

Bug#987956: libgcrypt20: ECDH decryption fails with "gpg: public key decryption failed: Invalid object" error message

[Xavier G.]

Package: libgcrypt20
Version: 1.8.7-4
Severity: important

Dear Maintainer,

After a full-upgrade in Sid on 2021-05-02, `gpg --decrypt somefile.gpg` fails:

  gpg: encrypted with 256-bit ECDH key, ID [hopefully irrelevant]
  gpg: public key decryption failed: Invalid object
  gpg: decryption failed: No secret key

Strace provides a little more context:

  read(6, "S INQUIRE_MAXLEN 4096\nINQUIRE CIPHERT"..., 1002) = 41
  write(6, "D (7:enc-val(4:ecdh(1:s49:0V\333\26\231\377\242\231\237b\375"..., 
120) = 120
  write(6, "END", 3)  = 3
  write(6, "\n", 1)   = 1
  read(6, "ERR 16777281 Invalid object \n", 1002) = 37

Considering the list of updated packages this day, libgcrypt20:amd64 (1.8.7-3,
1.8.7-4) is the likely culprit.  Its changelog states:

  libgcrypt20 (1.8.7-4) unstable; urgency=medium
  
* Update from LIBGCRYPT-1.8-BRANCH:
  + 30_07-Fix-previous-commit.patch
  + 30_08-ecc-Check-the-input-length-for-the-point.patch
  
   -- Andreas Metzler   Sun, 02 May 2021 13:58:47 +0200

The second patch is precisely about returning "Invalid object" /
GPG_ERR_INV_OBJ in some case related to GnuPG and ECDH decryption.

Therefore, could you please double-check this patch?
Thanks for your work.

Cheers,
-- Xavier G.


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
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)

Versions of packages libgcrypt20 depends on:
ii  libc6  2.31-12
ii  libgpg-error0  1.38-2

libgcrypt20 recommends no packages.

Versions of packages libgcrypt20 suggests:
pn  rng-tools  

-- no debconf information

Bug#902652: [Aptitude-devel] Bug#902652: Bug#902652: aptitude doesn't autoremove kernels

[Julian Andres Klode]

On Sun, May 02, 2021 at 01:42:29PM +0200, Axel Beckert wrote:
> Control: notfound 902652 0.8.13-3
> Contyrol: severity 902652 norma;
> 
> Dear Jidanni,
> 
> > Proof that aptitude is not ready for
> > 
> >/usr/share/doc/apt/NEWS.Debian.gz
> >apt (2.1.16) unstable; urgency=medium
> > 
> >  Automatically remove unused kernels on apt {dist,full}-upgrade. To 
> > revert
> >  to previous behavior, set APT::Get::AutomaticRemove::Kernels to false 
> > or
> >  pass --no-auto-remove to the command. apt-get remains unchanged.
> 
> Proof that this is wrong:
> 
> That feature wasn't present in apt 1.4.8 which was present when the
> original bug was reported. Hence reverting your changes to this bug
> report.
> 
> Feel free to report a separate bug report for compatibility with the
> 2.1.16 apt changes.
> 
> And wrt. to
> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/1772688:
> Please note that apt-get hasn't changed either and behaves differently
> that apt. And nobody stated that aptitude will follow apt and not
> apt-get. (Nobody has stated the opposite either, though, but it's
> obviously the default.)

There is a bug in aptitude, so to speak, as it protects all linux
images, it literally protects like ~n^linux-image or something like
that by supplying its own root set function somewhere, when it should
just rely on APT's default root set function.

That said, that's a post-freeze topic I reckon.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#987955: google-android-build-tools-installer: Missing dependency to libc++1:i386

[Celelibi]

Package: google-android-build-tools-installer
Version: 23.0.3+r1
Severity: important

Dear Maintainer,

The tool aapt installed by this package requires the shared library
libc++.so. It should probably be maked as a dependency.

Moreover, the installed aapt binary is a 32 bits ELF. Therefore, it
requires a 32 bits libc++.so library. Are cross-architecture
dependencies possible?

Best regards,
Celelibi

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)

Versions of packages google-android-build-tools-installer depends on:
ii  build-essential12.9
ii  ca-certificates20210119
ii  debconf [debconf-2.0]  1.5.75
ii  dpkg-dev   1.20.9
ii  libstdc++6 10.2.1-6
ii  make   4.3-4.1
ii  po-debconf 1.0.21+nmu1
ii  unzip  6.0-26
ii  wget   1.21-1+b1
ii  zlib1g 1:1.2.11.dfsg-2

google-android-build-tools-installer recommends no packages.

google-android-build-tools-installer suggests no packages.

-- debconf information:
* google-android-installers/mirror: https://dl.google.com

Bug#987745: apt-listbugs: please clarify, what ruby-httpclient is needed/used for

[Francesco Poli]

On Sat, 01 May 2021 19:41:24 +0200 Christoph Anton Mitterer wrote:

[...]
> Could you perhaps ask the previous maintainer why he originally made a
> Depends on it?

I really doubt he can remember, after some 15 years...

I took a look at the git repository log, to see whether I could spot
an explanation in the commit messages, but I failed to find anything
about this.
Maybe I should use git-bisect to pinpoint the exact commit that
introduced the dependency...
But this would not necessarily be useful: the original reason for
adding the dependency could be obsolete today (maybe the needed feature
is now also implemented in the Ruby net/http library... but other
httpclient features could still be missing from the net/http library!). 

> 
> Other than that, it might still be a possibility to actually demote the
> dependency (perhaps just in unstable), and wait for people to report
> when they run into problems (it shouldn't be anything that wouldn't be
> noticed immediately, the only thing that would be kinda "hidden" was
> TLS/no-TLS, but that's anyway not a point... so if it's something like
> proxy, you'd get rather soon a ticket).
[...]

Well, I am a bit hesitant to break people's systems, just to see what
it breaks!

If I did so in unstable, I would do Debian users a disservice.
If I did so in experimental, the risk would be that too few users would
test the package.

Not easy.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpd5syeK5BpC.pgp
Description: PGP signature

Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected

[Ari Fordsham]

I'm also having this issue.

LG Gram 17 2019
Intel Wireless-AC 9560

Running testing (Debian GNU/Linux bullseye/sid)

Under the current kernel (linux-image-5.10.0-6-amd64) the Wifi was bugging
out constantly, making it almost unusable. (No ethernet port on the
machine!)

I tried all versions of the firmware (by renaming the files in
/lib/firmware/iwlwifi-9000-*) none were noticeably better.

I downgraded to linux-image-4.19.0-16-amd64 (firmware v38), and thought it
was solved, but it's still happening intermittently.

[   23.997128] iwlwifi :00:14.3: Queue 11 is active on fifo 1 and stuck
for 1 ms. SW [51, 83] HW [51, 83] FH TRB=0x0c010b042
[   23.997324] iwlwifi :00:14.3: Microcode SW error detected.
Restarting 0x0.
[   23.997518] iwlwifi :00:14.3: Start IWL Error Log Dump:
[   23.997525] iwlwifi :00:14.3: Status: 0x0100, count: 6
[   23.997529] iwlwifi :00:14.3: Loaded firmware version: 38.755cfdd8.0
[   23.997534] iwlwifi :00:14.3: 0x0084 | NMI_INTERRUPT_UNKNOWN

[   23.997538] iwlwifi :00:14.3: 0x008026F4 | trm_hw_status0
[   23.997542] iwlwifi :00:14.3: 0x | trm_hw_status1
[   23.997546] iwlwifi :00:14.3: 0x00454EAA | branchlink2
[   23.997549] iwlwifi :00:14.3: 0x0045E8C2 | interruptlink1
[   23.997553] iwlwifi :00:14.3: 0x0001BBAE | interruptlink2
[   23.997556] iwlwifi :00:14.3: 0x | data1
[   23.997560] iwlwifi :00:14.3: 0xFF00 | data2
[   23.997564] iwlwifi :00:14.3: 0xF008 | data3
[   23.997567] iwlwifi :00:14.3: 0x1DC16F0A | beacon time
[   23.997571] iwlwifi :00:14.3: 0xF234EEE6 | tsf low
[   23.997574] iwlwifi :00:14.3: 0x015C | tsf hi
[   23.997578] iwlwifi :00:14.3: 0x | time gp1
[   23.997581] iwlwifi :00:14.3: 0x010B7BA0 | time gp2
[   23.997585] iwlwifi :00:14.3: 0x0001 | uCode revision type
[   23.997588] iwlwifi :00:14.3: 0x0026 | uCode version major
[   23.997592] iwlwifi :00:14.3: 0x755CFDD8 | uCode version minor
[   23.997596] iwlwifi :00:14.3: 0x0312 | hw version
[   23.997599] iwlwifi :00:14.3: 0x00C89008 | board version
[   23.997603] iwlwifi :00:14.3: 0x0B33001C | hcmd
[   23.997606] iwlwifi :00:14.3: 0x8002200A | isr0
[   23.997610] iwlwifi :00:14.3: 0x0180 | isr1
[   23.997613] iwlwifi :00:14.3: 0x08001802 | isr2
[   23.997616] iwlwifi :00:14.3: 0x004128C5 | isr3
[   23.997620] iwlwifi :00:14.3: 0x | isr4
[   23.997623] iwlwifi :00:14.3: 0x007B019C | last cmd Id
[   23.997627] iwlwifi :00:14.3: 0x | wait_event
[   23.997630] iwlwifi :00:14.3: 0x0080 | l2p_control
[   23.997634] iwlwifi :00:14.3: 0x2020 | l2p_duration
[   23.997637] iwlwifi :00:14.3: 0x003F | l2p_mhvalid
[   23.997641] iwlwifi :00:14.3: 0x00CE | l2p_addr_match
[   23.997644] iwlwifi :00:14.3: 0x000D | lmpm_pmg_sel
[   23.997648] iwlwifi :00:14.3: 0x08081115 | timestamp
[   23.997651] iwlwifi :00:14.3: 0x0034288C | flow_handler
[   23.997698] iwlwifi :00:14.3: Start IWL Error Log Dump:
[   23.997702] iwlwifi :00:14.3: Status: 0x0100, count: 7
[   23.997706] iwlwifi :00:14.3: 0x0066 | NMI_INTERRUPT_HOST
[   23.997710] iwlwifi :00:14.3: 0x | umac branchlink1
[   23.997713] iwlwifi :00:14.3: 0xC0087C88 | umac branchlink2
[   23.997717] iwlwifi :00:14.3: 0xC00839F8 | umac interruptlink1
[   23.997720] iwlwifi :00:14.3: 0xC00839F8 | umac interruptlink2
[   23.997724] iwlwifi :00:14.3: 0x0100 | umac data1
[   23.997727] iwlwifi :00:14.3: 0xC00839F8 | umac data2
[   23.997731] iwlwifi :00:14.3: 0xDEADBEEF | umac data3
[   23.997734] iwlwifi :00:14.3: 0x0026 | umac major
[   23.997738] iwlwifi :00:14.3: 0x755CFDD8 | umac minor
[   23.997741] iwlwifi :00:14.3: 0xC0886298 | frame pointer
[   23.997745] iwlwifi :00:14.3: 0xC0886298 | stack pointer
[   23.997748] iwlwifi :00:14.3: 0x007B019C | last host cmd
[   23.997752] iwlwifi :00:14.3: 0x | isr status reg
[   23.997760] ieee80211 phy0: Hardware restart was requested
[   24.456774] iwlwifi :00:14.3: BIOS contains WGDS but no WRDS
[  249.488857] iwlwifi :00:14.3: Queue 11 is active on fifo 1 and stuck
for 1 ms. SW [234, 40] HW [234, 40] FH TRB=0x0c010b0f9
[  249.488996] iwlwifi :00:14.3: Microcode SW error detected.
Restarting 0x0.
[  249.489237] iwlwifi :00:14.3: Start IWL Error Log Dump:
[  249.489243] iwlwifi :00:14.3: Status: 0x0100, count: 6
[  249.489248] iwlwifi :00:14.3: Loaded firmware version: 38.755cfdd8.0
[  249.489253] iwlwifi :00:14.3: 0x0084 | NMI_INTERRUPT_UNKNOWN

[  249.489257] iwlwifi :00:14.3: 0x008026F4 | trm_hw_status0
[  249.489261] iwlwifi :00:14.3: 0x | trm_hw_status1
[  249.489265] iwlwifi :00:14.3: 0x00454EAA | branchlink2
[  249.489269] iwlwifi :00:14.3: 0x0045E8C2 | interruptlink1
[  249.489273] iwlwifi :00:14.3: 0x4B86 | 

Bug#950664: ITP: pylatexenc -- Simple LaTeX parser providing conversion to/from unicode

[Diego M. Rodriguez]

Hello Sebastian,

and apologies for the long delay in replying.

On Wed, Dec 9, 2020, at 13:52, Sebastian Ramacher wrote:
> I'd be interested in the package. Have you been able to make any
> progress on it?

I did some groundwork at salsa [1] for the 2.1 upstream version. The main items 
that were left unresolved after that initial effort are:
1. seek advice and finalize d/copyright, as there was one particular file [2] 
where I was unsure how to reflect the licensing.
2. verify that the use of help2man is acceptable for generating the manpages 
for the scripts (and act accordingly, ie. dropping the help2man invocation in 
d/rules or create the documentation manually).

I still have the intent of continuing the work - any help is appreciated! Best,

[1] https://salsa.debian.org/python-team/packages/python-pylatexenc
[2] https://github.com/phfaist/pylatexenc/blob/master/tools/unicode.xml
---
Diego M. Rodriguez

Bug#952298: sshcommand: diff for NMU version 0~20160110.1~2795f65-1.1

[Chris Hofstaedtler]

Hi,

* Fabio Augusto De Muzio Tobich  [210502 17:17]:
> Sorry, forgot to say that I intend to do this NMU in 5 days in DELAYED/10.

Might make sense to just go ahead.

Chris

Bug#987954: RFP: mediapipe -- customizable ML solutions for live and streaming media.

[Petter Reinholdtsen]

Package: wnpp
Severity: wishlist

* Package name: mediapipe
  Version : 0.8.3.2
  Upstream Author : Google
* URL : https://mediapipe.dev/, https://github.com/google/mediapipe
* License : Apache
  Description : customizable ML solutions for live and streaming media.

Python and Web browser library.

-- 
Happy hacking
Petter Reinholdtsen

Bug#850946: pinentry-curses: does not quit on Ctrl-C (SIGINT), still grabs keys, takes 100% CPU time

[Vincent Lefevre]

Control: found -1 2.2.27-2

The bug is still there.

Fixed upstream in 2019, but unfortunately, only for GnuPG 2.3.

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

Bug#987428: libwebkit2gtk-4.0-37: only recommned xdg-desktop-portal-gtk

[Simon McVittie]

For context, I maintain flatpak, xdg-desktop-portal and
xdg-desktop-portal-gtk in Debian.

On Sun, 25 Apr 2021 at 21:17:50 +0200, Alberto Garcia wrote:
> xdg-desktop-portal-gtk was designed for Flatpak as far as I'm aware
> but it does not depend on it.

That is correct. It's the other way round: Flatpak depends on the portals.
It isn't an absolute dependency, so it's a Recommends in Debian, but
Flatpak apps will have very severely reduced functionality without them.

They are useful for any situation where a process runs in a restricted
container (sandbox), but needs to be able to interact with applications
and desktop components outside the sandbox, without gaining a way to
escape from the sandbox and avoid its restrictions. That's a description
of Flatpak and Snap (where the sandboxed process is installed by Flatpak
or Snap), but it's also a description of WebKitGTK (where the sandboxed
process came from the same .deb as the rest of WebKitGTK).

xdg-desktop-portal(-gtk) is not going to get a dependency on Flatpak
unless there is an *incredibly* good reason why it must, because that
would be a circular dependency, and circular dependencies are something
we avoid.

smcv

Bug#987948: evolution: bad quality rendering of fonts in sandbox

[Simon McVittie]

Control: reassign 987948 libwebkit2gtk-4.0-37
Control: affects 987948 + evolution
Control: tags 987948 - moreinfo

On Sun, 02 May 2021 at 23:45:33 +0900, Osamu Aoki wrote:
> By installing xdg-desktop-portal-gtk, problem solved.  So please make
> evolution recommends xdg-desktop-portal-gtk (which pulls in xdg-
> desktop-portal).
> 
> This is a low risk fix.
> 
> I think other similar packages needs dependency adjustment.

Instead of making each leaf application depend on xdg-desktop-portal-gtk,
it would be easier and more correct for libwebkit2gtk-4.0-37 to depend
on xdg-desktop-portal-gtk. This has already been fixed in unstable,
in webkit2gtk 2.32.0-1, but that change has not yet reached bullseye.

I think this bug can be closed as fixed in webkit2gtk >= 2.32.0-1 when the
reassignment has been processed.

webkit2gtk maintainers: is 2.32.x targeted at bullseye? If yes, note that
it is going to need a release team unblock, and appears to be triggering
an autopkgtest regression in balsa.

smcv

Bug#986866: apacheds: ApacheDS fails to start after clean install

[tony mancill]

On Sun, May 02, 2021 at 07:29:56AM -0700, tony mancill wrote:
> 1)  The exception is being thrown in the mina library (source package
> mina2: https://tracker.debian.org/pkg/mina2), so we will likely end up
> reassigning the bug to that package.

I have reassigned the bug to mina2.

> 2) Because mina2 and apacheds2 haven't changed in over 6 months and this
> issue began shortly after the introduction of OpenJDK 11.0.11 to
> unstable, I suspect that Apache Mina2 has been setting a socket option
> that has been deprecated for a while and is now no longer supported.

I didn't find a difference in OpenJDK that would account for the change
in behavior, although it could be that I didn't go far enough back (I
was comparing sources back to 11.0.9.1), or that I missed the salient
bit.

> Assuming my hunch is correct, I propose patching mina2 to no longer
> attempt to set SO_SNDBUF [2].  mina2 is only used by ApacheDS within
> Debian, so it should be fairly quick to test the change.

I have built mina2 with SO_SNDBUF line disabled [1], and then thought
better of it (maybe it still works on certain platforms - it seems to
have worked in the past) and updated the patch to attempt to set the
option and then ignore the UnsupportedOperationException [2] if thrown.

I installed this package locally and tested with the current apacheds,
confirming that it now starts as expected.  I also verified via ratt
that all build r-deps of mina2 are still healthy (although since this is
a runtime bug, that's just due diligence).

I propose uploading and requesting an unblock for mina2 but since we're
in the freeze and this is an RC bug, I want to give other members of the
Java Team who might be more familiar with the code a chance to comment.

If there are no objections, I will upload on 2021-05-03 (afternoon UTC).

Cheers,
tony

[1] 
https://salsa.debian.org/java-team/mina2/-/blob/eab3e3cfeff66c694fc9bf7c7047f13f258946ae/debian/patches/SO_SNDBUF.patch
[2] 
https://salsa.debian.org/java-team/mina2/-/blob/bc58296df862065ec641ce47095f2fb46d54aeb9/debian/patches/SO_SNDBUF.patch


signature.asc
Description: PGP signature

Bug#922873: linux-image-4.19.0-3-amd64: nouveau "PGRAPH TLB flush idle timeout fail" errors, machine unresponsive via ssh

[Vincent Lefevre]

Control: tags -1 - fixed-upstream

Removing the fixed-upstream tags to avoid confusion since the bug
is still open upstream and I've never heard of any fix.

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

Bug#959757: This is a regression

[wferi]

Peter Leipold  writes:

> On 5/2/21 2:54 PM, Salvatore Bonaccorso wrote:
>
>> On Sun, Jul 05, 2020 at 01:15:38PM +0200, wf...@niif.hu wrote:
>>
>>> I started to see this problem after upgrading from 5.4.0-0.bpo.4-amd64
>>> to 5.5.0-0.bpo.2-amd64.  It goes like:
>>
>> Do you still have the issue reproducible with a recent kernel from
>> unstable or buster-backports?
>
> Hi, I'm the original reporter. FYI, the problem was fixed with one of
> the kernel updates on last summer. It's stable since then.

Hi,

I certainly can't reproduce it with the current 5.10.24-1~bpo10+1.  Not
even with 5.10.13-1~bpo10+1, and I haven't got older logs anymore.
-- 
Feri

Bug#987845: hardwired proxy settings by debian-installer with network-auto-config in proxy-auto-config network

[Rado S]

=- Geert Stappers wrote on Fri 30.Apr'21 at 22:04:09 +0200 -=

> On Fri, Apr 30, 2021 at 09:25:47PM +0200, Rado Q wrote:
> > Installation network setup was auto-configured while the system was
> > in a network with proxy-auto-config active.
> > 
> > Expectation:
> > when choosing auto-configure-network during installation, the
> > resulting system should be operative in every foreign environment.
> > (think of notebook in roaming use)
> > 
> > Result:
> > applications strictly following those hardwired configs can't operate
> > outside the original installation network, where the given proxy exists,
> > but nowhere else. PAC results during installation shouldn't be
> > 'hardwired' into the system to last when moving to another network.
> 
> Acknowledge on the problem.
> 
> Which possible solutions do we see?

How about having a boot process check for the network strategy
(fixed or dhcp), and if dhcp, let it discover the proxy by WPAD/PAC
and store it in /var/run, and have general config include it from
there, if it exists, like:

/etc/profile.d/proxy-check:

DYNPROXYCFG=/var/run/proxy-cfg
if [ -s "$DYNPROXYCFG" ]
then
. "$DYNPROXYCFG"
fi

Everything else not respecting those http_proxy vars would need
similar stuff. APT seems to have its own PAC features, which could/
should be used instead of storing fixed values, or use the same as
above (if APT/itude works with those http_proxy vars).

Rado

Bug#695182: linux-image-3.2.0-4-686-pae: Write couple of 1GB files for OOM crash

[Ben Hutchings]

On Sun, 2021-05-02 at 07:30 +1000, Paul Szabo wrote:
> I no longer use 32-bit kernels (but use the 64-bit amd64 kernel, even on
> my few last remaining 32-bt machines): that seems a suitable workaround
> or upgrade path. Should I try to test whether the issue with PAE
> remains?

I don't think there's much point in investigating issues with 32-bit
and 16GB RAM - they will be "wontfix" upstream.

It's possible that this particular problem has been fixed by an mm
change in 4.2, but at the cost of a regression in disk throughput:
.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.


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

Bug#823224: ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or directory

[Ben Hutchings]

Control: found -1 5.10.28-1

On Sun, 2021-05-02 at 08:55 +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Thu, Oct 19, 2017 at 11:04:27PM +0100, Ben Hutchings wrote:
> > On Thu, 2017-10-19 at 22:18 +0200, John Paul Adrian Glaubitz wrote:
> > > Hi Mathieu!
> > > 
> > > I'm now running into exactly this problem when trying to build the SPL 
> > > library
> > > on a native ppc64 system for ZFS-on-Linux, see below.
> > > 
> > > Can you give me a pointer on how to resolve this issue?
> > > 
> > > configure:15763: checking whether modules can be built
> > > configure:15786: cp conftest.c build && make modules -C 
> > > /usr/src/linux-headers-4.13.0-1-powerpc64 
> > > EXTRA_CFLAGS=-Werror-implicit-function-declaration
> > > M=/home/glaubitz/zfstests/spl/build
> > > /bin/sh: 1: /usr/src/linux-headers-4.13.0-1-common/scripts/ld-version.sh: 
> > > not found
> > > /bin/sh: 1: [: -ge: unexpected operator
> > > ld: cannot find arch/powerpc/lib/crtsavres.o: No such file or directory
> > [...]
> > 
> > This is a different problem.  powerpc 64-bit builds have started using
> > that script since 4.13:
> > 
> > commit efe0160cfd40a99c052a00e174787c1f4158a9cd
> > Author: Nicholas Piggin 
> > Date:   Fri May 12 01:56:52 2017 +1000
> > 
> > powerpc/64: Linker on-demand sfpr functions for modules
> > 
> > So we should either ship the script or patch out the version test.
> 
> Is this still an issue for us or can the bug be closed?

We ship that script since 4.13.10-1, and zfs-linux's configure script
is successful on sid/ppc64el (and sid/powerpc).  But that is a
different bug.

The original bug report was about the upstream modules_prepare target
not building crtsavres.o.  And that's still reproducible with 5.10.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.


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

Bug#987917: inkscape: libxml-xql-perl still used?

[Christoph Anton Mitterer]

Thanks a lot :-)

Bug#987952: apg: security concerns in apg

[Christoph Anton Mitterer]

Oh and one follow-up on (2):

The -M modes with capital letters, i.e. "must use  symbol class",
also sound like actually reducing the entropy and - if that's really
the case - one should perhaps warn about this.

My idea is kinda:
Imagine you create a password of 4 symbols.
If the attacker knows, that all 4 categories (SNCL) must have been
included, it will already make his work much easier.

Sure, 4 symbols is not enough for any reasonable password, but I guess
the same principle would probably apply to larger ones?


Cheers,
Chris.

Bug#987952: apg: security concerns in apg

[Christoph Anton Mitterer]

Package: apg
Version: 2.2.3.dfsg.1-5+b2
Severity: normal
Tags: security


Hey.

I was thinking about a number of security concernts, and since I'm no
expert, maybe someone else has an idea:


1) Attack on pronouncable passwords?
Via https://en.wikipedia.org/wiki/Random_password_generator#Stronger_methods
I've stumbled over:
Ganesan, Ravi; Davies, Chris (1994). "A New Attack on Random Pronounceable 
Password Generators"
http://csrc.nist.gov/publications/history/nissc/1994-17th-NCSC-proceedings-vol-1.pdf
and
http://www.andrew.cmu.edu/user/nicolasc/publications/Shay-SOUPS12.pdf

The former seems to be an attack on what I guess apg is dowing when -a 0?

So maybe, if that is real, one should warn against using -a 0?




2) Are symbolls well distributed?
The following is really absolutely NOT solid, and probably just stupid
perception of mine


For many years now I've used:
APG_PARM="-c /dev/urandom  -a 1  -M SNCL  -m 32 -x 32"
and I kinda always had the impression that special symbols are way
over-represented, e.g.
6^20:#;$0dZw7%AWM{@rVX']TK2q3(kX
IHxb*Yse?^@Kx[kZhxJp;4nOPCRxfhe(
ty%'a}U{+A)@>r|4;_#$yP^9[ZVXLTN<
5Fz_0.&_rK2+[3vBC0IRODQD5B]M#T9u
m#_dRg@x@)\mgbbz57,.||(!g5D`R={d
++4v%Ozl3Ae[e

Bug#959757: This is a regression

[Peter Leipold]

Hi, I'm the original reporter. FYI, the problem was fixed with one of 
the kernel updates on last summer. It's stable since then.


Peter

On 5/2/21 2:54 PM, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo

On Sun, Jul 05, 2020 at 01:15:38PM +0200, wf...@niif.hu wrote:

Control: found -1 5.5.0-0.bpo.2-amd64

I started to see this problem after upgrading from 5.4.0-0.bpo.4-amd64
to 5.5.0-0.bpo.2-amd64.  It goes like:

Do you still have the issue reproducible with a recent kernel from
unstable or buster-backports?

Regards,
Salvatore

Bug#886568: exabgp is not able to create its command pipe

[Marco d'Itri]

On May 02, Marco d'Itri  wrote:

> > Adding this to exabgp.service will take care of it.
> Do you have any plans to fix this? As far as I can see exabgp is broken 
> out of the box.
I have wasted a couple of hours today because the version currently in 
testing is broken in a different way and it crashes with Python 
tracebacks due to /run/exabgp/ != /run/.
The exabgp package is not fit to be released.

PermissionsStartOnly and all the ExecStartPre directives in the systemd 
unit must be replaced with:

User=exabgp
Group=exabgp
RuntimeDirectory=exabgp
RuntimeDirectoryMode=0750
ExecStartPre=-/usr/bin/mkfifo /run/exabgp/exabgp.in
ExecStartPre=-/usr/bin/mkfifo /run/exabgp/exabgp.out

This is all that is needed to securely create the pipes.

Optionally, add hardening:

ProtectSystem=strict
ProtectHome=yes
PrivateDevices=yes
PrivateTmp=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
NoNewPrivileges=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#987917: inkscape: libxml-xql-perl still used?

[Mattia Rizzolo]

Hi!

On Sun, May 02, 2021 at 03:41:26AM +0200, Christoph Anton Mitterer wrote:
> I've just wondered whether inkscape still makes use of libxml-xql-perl?
> 
> The shadow effect seems to work without it (at least the one I found),
> also I couldn't find any ocurrance of XML::XQL within the source package.

It doesn't anymore, indeed.  It was used in the SpSVG extension back in
v0.47, but at least in 0.91 it already wasn't used anymore.

> So perhaps one can drop the Suggests?

Yes, I'll do so, thank you for reporting!

> PS: It's great that you describe the Suggests in the package description
> but why not the Recommends?

I'm sure there was some very deep reason back then, but I have no clue
now! :P
I'll see about listing them all, indeed :)

-- 
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#974672: apg: Wrong homepage + possibile new version

[Christoph Anton Mitterer]

>I think that the new homepage is:
>https://github.com/wilx/apg

That's rather a fork, and it seems there ar more:
https://github.com/jabenninghoff/apg/


Also, this is probably a duplicate of #877601.


Cheers,
Chris.

Bug#987948: Info received (evolution: bad quality rendering of fonts in sandbox)

[Osamu Aoki]

Wow, bingo.

By installing xdg-desktop-portal-gtk, problem solved.  So please make
evolution recommends xdg-desktop-portal-gtk (which pulls in xdg-
desktop-portal).

This is a low risk fix.

I think other similar packages needs dependency adjustment.

I didn't need to use experimental to get my concern addressed.

Osamu

Bug#966675: virt-v2v missing

[Hilko Bengen]

* Wong Hoi Sing Edison:

> During contribution to
> https://github.com/vagrant-libvirt/vagrant-libvirt/issues/1256, I
> found that virt-v2v would be a good choice for export/import instance
> as Vagrant Box internal format; BTW, I am using Ubuntu 20.10 and found
> that it is now missing virt-v2v package due to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966675...

I am sorry, I somehow missed the opportunity to get virt-v2v into the
distribution together with virt-p2v. And now it is too late for Debian
11 / "bullseye" because no new packages are accepted into testing at
this point.

I have now uploaded virt-v2v to unstable. As soon as bullseye is
released, I will provide virt-v2v via the backports repository.

Cheers,
-Hilko

Bug#987948: evolution: bad quality rendering of fonts in sandbox

[Osamu Aoki]

Simon, thanks for your comment.

My system was

ii  xdg-desktop-portal 1.8.1-1 desktop integration portal for Flatpak
and Snap
un  xdg-desktop-portal-gtk   (no description available)

I will install them and try experimental

Osamu

Bug#987696: findutils: suggest plocate as an alternative

[Andreas Metzler]

Control: tags -1 pending

On 2021-05-02 Christoph Anton Mitterer  wrote:
> On Sun, 2021-05-02 at 13:25 +0200, Andreas Metzler wrote:
>> thanks for the report. I think it would be better to simply drop the
>> Suggests, it was added eons ago when GNU locate was split-off from
>> find
>> to ease upgrades.

> Seems even better...

Fixed in GIT.

https://salsa.debian.org/debian/findutils/-/commit/d06a9a25d736ac3af9bb3a326a07a11f45940f95

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#986866: apacheds: ApacheDS fails to start after clean install

[tony mancill]

Hello Carlos,

Thank you for reporting this bug and to others for confirming it.
Several comments below:

On Mon, Apr 12, 2021 at 10:09:58PM -0600, Carlos Ramos wrote:
> Package: apacheds
> Version: 2.0.0~M24-4
> Severity: important
> 
> [2021-52-12T21:52:39.039-0600] WARN 
> [org.apache.directory.server.core.DefaultDirectoryService] - You didn't 
> change the admin password of directory service instance 'default'.  Please 
> update the admin password as soon as possible to prevent a possible security 
> breach.
> [2021-52-12T21:52:39.039-0600] DEBUG 
> [org.apache.directory.server.ldap.handlers.extended.StartTlsHandler] - 
> Setting LDAP Service
> [2021-52-12T21:52:39.039-0600] DEBUG 
> [org.apache.directory.server.ldap.handlers.extended.StartTlsHandler] - 
> provider = SUN version 11
> [2021-52-12T21:52:39.039-0600] ERROR 
> [org.apache.directory.server.UberjarMain] - Failed to start the service.
> java.lang.UnsupportedOperationException: 'SO_SNDBUF' not supported
>   at 
> java.base/sun.nio.ch.ServerSocketChannelImpl.setOption(ServerSocketChannelImpl.java:151)
>   at 
> org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:255)
>   at 
> org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:52)
>   at 
> org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.registerHandles(AbstractPollingIoAcceptor.java:591)
>   at 
> org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:460)
>   at 
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:829)

1)  The exception is being thrown in the mina library (source package
mina2: https://tracker.debian.org/pkg/mina2), so we will likely end up
reassigning the bug to that package.

2) Because mina2 and apacheds2 haven't changed in over 6 months and this
issue began shortly after the introduction of OpenJDK 11.0.11 to
unstable, I suspect that Apache Mina2 has been setting a socket option
that has been deprecated for a while and is now no longer supported.

That is speculation so far - I haven't yet tracked this down to a
change in OpenJDK (but will try by reverting locally). However,
11.0.11+$x appears in your bug report and others confirming the bug.

Also, when I look at the Java 11 javadoc for ServerSocketChannel [1], I
don't see SO_SNDBUF as a supported option anyway.

Assuming my hunch is correct, I propose patching mina2 to no longer
attempt to set SO_SNDBUF [2].  mina2 is only used by ApacheDS within
Debian, so it should be fairly quick to test the change.

Thanks,
tony

[1] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/channels/ServerSocketChannel.html
[2] 
https://salsa.debian.org/java-team/mina2/-/blob/master/src/mina-core/src/main/java/org/apache/mina/transport/socket/nio/NioSocketAcceptor.java#L253-256


signature.asc
Description: PGP signature

Bug#975039: Cleaner work around for Evolution 3.38.3-1 which still fails to render emails

[Osamu Aoki]

After I posted previous workaround, I realize this can be done more
cleanly to get GUI icon start up to work.

I created /usr/local/bin/evolution as:

```
#!/bin/sh -e
WEBKIT_FORCE_SANDBOX=0 exec /usr/bin/evolution "$@"

```

Since my PATH setting is ordered as 
  /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
this nicely replace all invocation of evolution without full path.

Osamu

Bug#945055: closed by car...@debian.org (Closing this bug (BTS maintenance for src:linux bugs))

[Christoph Anton Mitterer]

On Sun, 2021-05-02 at 15:56 +0200, Salvatore Bonaccorso wrote:
> In this case I'm reopening the bug again. But I suggest to ping again
> upstream in this case, because without progress/movement/ideas
> upstream we cannot do anything here downstream.

I'm afraid that upstream has shown pretty clearly that they have
basically no interest to look into that issue (guess Intel only spends
money on stuff they still sell).

Just look at the bug reports I've linked to (and the subsequent ones
linkes from there).
I put in many hours of testing and made many plots from which it should
be clear that something is quite wrong. But no further reaction.



For me, I found a workaround:

The CPU/GPU would (according to upstream devs) be very well capable of
controlling a HiDPI screen and doing FullHD playback there (actually
the developer said it should easily do several such stream).
And the notebook in fact has a HiDPI screen.

Now starting around after kernel 5.2, with HiDPI resolutions enabled,
the issues I've described show up:
- even little GPU loads like moving windows in circles leading to
extremely high temperatures ~70-90°C
- video playback in fullscreen generally 100°C.
- even non-GPU related load seemed to have caused such issues, as my
tests showed.


At some point, by chance I reduced the screen resolution to "just"
1920x1080 (from the HiDPI default of 3840x2160).

That immediately solved all issues.


Well, actually, e.g. Cinnamon still seems to run under higher CPU
temperatures than e.g. GNOME Classic (and I'm not only talking about
the idle temperature, but also when doing things like moving Windows),
but it's all so low now that I can live with it.

Under HiDPI, the difference bettween Cinnamon and GNOME Classic was
sometimes quite considerable, IIRC.



That being said, I think you may further lower the severity if you
wish, but it makes perhaps sense to keep the bug open for a while (I
guess until the CPU/GPU is so old, nobody would likely still use it),
so that people have an easier chance of finding it (and the
workaround)?


Cheers,
Chris.

Bug#987950: d-shlibs: d-devlibdeps does not recognize musl

[Jonas Smedegaard]

Quoting Helmut Grohne (2021-05-02 15:51:52)
> Package: d-shlibs
> Filename: /usr/bin/d-devlibdeps
> Version: 0.98
> Severity: important
> Tags: patch
> Control: affects -1 + src:libzstd
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> d-devlibdeps does not recognize musl as a C library, building libzstd
> fails:
> 
> | devlibs error: There is no package matching [libclibc.so-dev] and noone 
> provides it, please report bug to d-shlibs maintainer
> 
> The mangling looks strange, but it may not be the worts aspect. In
> effect, it it fails the build. The following sed command fixes the
> issue:
> 
> sed -i -e '/libc\>/a\   -e '"'"'s/libclibc\.so-dev//'"'"' \\' 
> /usr/bin/d-devlibdeps

Thanks!

FYI, until fixed in d-shlibs (and when backporting to older released), 
you can alternatively pass the override option like this:

  dh-slibmove --override 's/libclibc\.so-dev//' [...]


 - Jonas

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

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

signature.asc
Description: signature

Bug#978479: linux-image-5.9.0-5-amd64: NVMe AMD-Vi IO_PAGE_FAULT only with hardware IOMMU

[Salvatore Bonaccorso]

Hi Lisandro,

On Sun, May 02, 2021 at 10:49:58AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Version: 5.10.28-1
> 
> Hi Salvatore!
> 
> On Sun, 2 May 2021 at 10:26, Salvatore Bonaccorso  wrote:
> >
> > is this something you still can reproduce with the 5.10 kernel in
> > unstable?
> 
> Thanks for pinging, indeed I forgot about this issue. I have just
> removed the kernel parameter, rebooted, opened my session and my MUA
> and here I am writing this mail, so I would say it's no longer
> reproducible.
> 
> According to dpkg my current kernel version is
> linux-image-5.10.0-6-amd64 5.10.28-1, so I'm closing this bug with it.
> 
> Again, thanks for pinging the bug!!

Many thanks to your for your quick checking back and confirming the
issue is fixed!

Regards,
Salvatore

Bug#945055: closed by car...@debian.org (Closing this bug (BTS maintenance for src:linux bugs))

[Salvatore Bonaccorso]

Control: reopen -1

Hi,

On Sun, May 02, 2021 at 03:40:20PM +0200, Christoph Anton Mitterer wrote:
> This bug has actually NOT been fixed.
> 
> It's NOT the one with the CPU not going into the RC6 state.

In this case I'm reopening the bug again. But I suggest to ping again
upstream in this case, because without progress/movement/ideas
upstream we cannot do anything here downstream.

Regards,
Salvatore, trying to do some maintenance on open src:linux bugs
without progress.

Bug#987950: d-shlibs: d-devlibdeps does not recognize musl

[Helmut Grohne]

Package: d-shlibs
Filename: /usr/bin/d-devlibdeps
Version: 0.98
Severity: important
Tags: patch
Control: affects -1 + src:libzstd
User: helm...@debian.org
Usertags: rebootstrap

d-devlibdeps does not recognize musl as a C library, building libzstd
fails:

| devlibs error: There is no package matching [libclibc.so-dev] and noone 
provides it, please report bug to d-shlibs maintainer

The mangling looks strange, but it may not be the worts aspect. In
effect, it it fails the build. The following sed command fixes the
issue:

sed -i -e '/libc\>/a\   -e '"'"'s/libclibc\.so-dev//'"'"' \\' 
/usr/bin/d-devlibdeps

Please consider applying it to the package. To reproduce the issue,
please build libzstd in chroot hosting a musl-linux-any architecture
such as musl-linux-i386. Unfortunately, no binary Debian packages are
published for musl architectures at this time, so one has to bootstrap
them. Cross building also reproduces the issue.

Helmut

Bug#945055: closed by car...@debian.org (Closing this bug (BTS maintenance for src:linux bugs))

[Christoph Anton Mitterer]

This bug has actually NOT been fixed.

It's NOT the one with the CPU not going into the RC6 state.

Cheers,
Chris.

Bug#975039: Evolution 3.38.1-3 rendering still not good for bulleseye

[Simon McVittie]

Control: clone -1 -2
Control: retitle -2 evolution: bad quality rendering of fonts in sandbox
Control: tags -2 + moreinfo
Control: forwarded -2 https://gitlab.gnome.org/GNOME/evolution/-/issues/1161

(Please note that I am not an Evolution or WebKitGTK maintainer.)

On Mon, 22 Feb 2021 at 21:06:32 +0900, Osamu Aoki wrote:
> I still experience very bad quality rendering of fonts.  Fonts looks
> like very small number pixel fonts zoomed up in current pre-release
> testing/unstable.

This is not the same issue that the reporter of #975039 reported, so we
should treat it as a separate bug, even if the WEBKIT_FORCE_SANDBOX=0
workaround is the same. The original topic of #975039 was that emails
did not render *at all*, whereas you are talking about emails rendering
as low-quality text.

Please send replies about low-quality font rendering to the new cloned
bug, not to #975039.

Do you have xdg-desktop-portal and xdg-desktop-portal-gtk installed?
If not, does installing them improve the font rendering?

Does upgrading libgtk-3-0 to the version from experimental improve the
font rendering? There have been some changes related to font settings
and sandboxing.

smcv

Bug#987696: findutils: suggest plocate as an alternative

[Christoph Anton Mitterer]

On Sun, 2021-05-02 at 13:25 +0200, Andreas Metzler wrote:
> thanks for the report. I think it would be better to simply drop the
> Suggests, it was added eons ago when GNU locate was split-off from
> find
> to ease upgrades.

Seems even better...

Cheers,
Chris.

Bug#982904: mumble: CVE-2021-27229

[Salvatore Bonaccorso]

Hi Chris,

On Sun, May 02, 2021 at 01:18:58PM +, Chris Knadle wrote:
> Salvatore Bonaccorso:
> > Hi Chris,
> > 
> > On Sat, May 01, 2021 at 05:52:04PM +, Chris Knadle wrote:
> > > Salvatore Bonaccorso:
> [...]
> > > Yes I submitted release.debian.org bug #987859 last night and did the 
> > > upload
> > > (and was "accepted"), which I think fits almost all of the criteria in the
> > > link above except that I did a "source only" upload rather than upload a
> > > built package; hopefully a source-only upload is acceptable here -- if 
> > > it's
> > > not let me know.
> > 
> > Yes defintively, in meanwhile source-only are possible (and would
> > encourage so) to do as well for stable (buster, and buster-security)
> > uploads.
> 
> Last question on this: for non-dsa security uploads, is it better to target
> "buster" or "buster-security"?  In my upload I targeted "buster" but I still
> have some confusion as to whether buster-security would be "better".

The target distribution would be 'buster' in case of an upload as you
prepared it now for the point release and uploading to the main
archive.

Only when you would upload to the security archive host the target
distribution would be buster-security.

Hope this helps!

Regards,
Salvatore

Bug#978479: linux-image-5.9.0-5-amd64: NVMe AMD-Vi IO_PAGE_FAULT only with hardware IOMMU

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Lisandro,

On Sun, Dec 27, 2020 at 07:22:06PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Package: src:linux
> Version: 5.9.15-1
> Severity: important
> Tags: upstream
> Forwarded: https://bugzilla.kernel.org/show_bug.cgi?id=202665
> X-Debbugs-Cc: lisan...@debian.org
> 
> Hi! I'm filing this bug for 5.9.0-5-amd64 but it also happens with 
> 5.9.0-4-amd64.
> 
> After upgrading Plasma (KDE) to current unstable and trying to log in I
> get nnme/AMD-Vi page faults (see attached photo). I could not determine
> what specifically in Plasma triggers the issue, in fact I had to log in
> via ssh prior to log in to get the demsg output.
> 
> I tried to log in with other desktops and they did not show the problem.
> 
> At first I thought it was a Plasma or video driver-triggered issue. I even
> tried installing the proprietary NVidia driver to see if it was
> somehow triggered by the video driver and no luck.
> 
> And then I found:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=202665
> 
> The work around in that bug (using "iommu=soft" as a kernel parameter)
> worked like a charm. The only thing I could not check (because I don't
> know how) is if it's really related to fstrim/discard.
> 
> I'm using the above URL as forwarded tag, but of course feel free to
> change that as needed.
> 
> If I can be of further help please just ping me.
> 
> Kinds regards and **thanks** for your work

is this something you still can reproduce with the 5.10 kernel in
unstable?

Regards,
Salvatore

Bug#987913: libglib2.0-0: upgrade or reinstallation removes /usr/lib//gio/modules/ if empty

[Simon McVittie]

On Sat, 01 May 2021 at 23:54:16 +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package misses two
> directories after an upgrade. These directories are shipped by the
> package.

I agree this is a bug, but I'm not sure what its severity is. Are you
aware of a user-visible impact to this bug, or is it (as far as you know)
only a theoretical issue?

>From the gio/giomodule.c source code, it looks as though a missing GIO
modules directory should be exactly equivalent to a GIO modules directory
that contains (no cache and) no modules.

The only reason I can see for this to be a practical problem is if
it prevented dpkg from triggering libglib2.0-0 after we install a
package that contains at least one GIO module. Also, the cache is
just a cache (unlike /usr/share/glib-2.0/schemas/gschemas.compiled,
which is functionally necessary), and GIO should still successfully
load GIO modules even if the cache was not regenerated - it will just
be significantly higher-overhead.

If there's little or no practical impact then I'm inclined to postpone
fixing this until after bullseye.

Thanks,
smcv

Bug#982904: mumble: CVE-2021-27229

[Chris Knadle]

Salvatore Bonaccorso:

Hi Chris,

On Sat, May 01, 2021 at 05:52:04PM +, Chris Knadle wrote:

Salvatore Bonaccorso:

[...]

Yes I submitted release.debian.org bug #987859 last night and did the upload
(and was "accepted"), which I think fits almost all of the criteria in the
link above except that I did a "source only" upload rather than upload a
built package; hopefully a source-only upload is acceptable here -- if it's
not let me know.


Yes defintively, in meanwhile source-only are possible (and would
encourage so) to do as well for stable (buster, and buster-security)
uploads.


Last question on this: for non-dsa security uploads, is it better to target 
"buster" or "buster-security"?  In my upload I targeted "buster" but I still 
have some confusion as to whether buster-security would be "better".


Thanks

   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#975039: Work around for Evolution 3.38.3-1 still fails to render emails

[Osamu Aoki]

Hi,

I finally found upstream discussion on this very annoying problem.

Evolution for Debian 11 Bullseye under wayland has ugly font problem as
of May 2, 2021.  (Similar issue with firefox, etc.).

This is caused by WebKit bug which exposes it under sandboxing. 

  https://gitlab.gnome.org/GNOME/evolution/-/issues/1161

According to upstream, this is not evolution bug.

For now, I workaround this problem by starting "evolution" by defining
shell alias and starting it from console shell prompt.


alias evolution="WEBKIT_FORCE_SANDBOX=0 evolution"

Osamu

Bug#987947: unblock (pre-approval): gtk+3.0/3.24.24-4

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org, debian-b...@lists.debian.org

I'd like to update gtk+3.0 in bullseye to pick up an assortment of fixes
from upstream. Exactly *which* fixes is something I'm happy to discuss:
I've prepared a candidate package with a reasonable set. Does this
look acceptable?

unblock gtk+3.0/3.24.24-4

[ Reason ]
Backport various targeted fixes from upstream 3.24.25 up to 3.24.29,
avoiding lower-impact and higher-regression-risk parts (notably avoiding
theme and input-method changes, which have been more problematic).

[ Impact ]
Most of the changes here are about avoiding infrequent crashes, such
as LP: #1911036 which can happen during drag-and-drop when using the
proprietary NVIDIA driver. Please let me know if you need more information
on the impact of any of the crash fixes.

d/p/x11-Be-quiet-on-exit-by-default.patch silences warnings when a
GTK application exits in response to the X11 server going away. These
warnings go to the system log and create a lot of log noise at the
end of an X11 session (at which time they are completely harmless),
or if Xorg or Xwayland crashes (in which case we want users to report
the Xorg/Xwayland crash as a bug, rather than getting distracted by all
their GTK apps exiting and misinterpreting the log as implying that an
app crash is the root cause).

d/p/gdkpixbuf-drawable-Free-the-pixbuf-on-Cairo-error.patch fixes a
resource leak.

Fixing LP: #1919404 fixes visual appearance of a specific GNOME Shell
extension (and anything else with similar behaviour) on HiDPI displays.

d/p/fontchooser-Fix-some-since-annotations.patch is low-impact but also
low-risk; it corrects API documentation.

d/p/placesview-Open-location-even-if-mount-was-not-found.patch fixes
a regression in Nautilus v40 (not in bullseye), and perhaps other
file managers. With the gvfs backends for SMB (Samba, CIFS, Windows
Networking), the intention is that smb://192.168.1.1/ lists the shares
on 192.168.1.1 and smb://192.168.1.1/music displays a specific share,
but displaying smb://192.168.1.1/ was not possible. The version of nautilus
in bullseye is unaffected by this bug.

[ Tests ]
Most of the upstream unit tests are run at build-time and as autopkgtests.
Some tests that are known-broken upstream or are particularly sensitive
to implementation details of other packages are skipped.

Manual testing: I use GNOME daily, and have been using the newer upstream
releases in experimental, from which these changes were backported. I've
now switched to this proposed version to get it some more testing. Some
of the fixes here are also used in Ubuntu.

I have a machine with the NVIDIA driver which exhibits the warnings
silenced by d/p/x11-Be-quiet-on-exit-by-default.patch during session
logout, and I confirm that the patch does successfully silence them.

I have not attempted to reproduce the various crashes.

[ Risks ]
This is obviously an important key package that lots of things depend on.
Technically it also has a udeb, although I'm fairly sure d-i is still
using GTK 2 and so the udeb is not actually used for anything yet.

The changes are targeted and simple (avoiding NULL dereferences and that
sort of thing).

I'm not particularly attached to any of the specific fixes here, and
I'm happy to drop them or postpone them to bullseye-pu if the release
team consider them to be an unacceptable risk. I don't think any of the
changes have dependencies between them, so we can keep or drop any
particular change as needed.

[ 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 testing
diffstat for gtk+3.0-3.24.24 gtk+3.0-3.24.24

 changelog   |   43 +
 patches/Fix-a-possible-crash-in-gtk_show_uri.patch  |   27 +
 patches/Wayland-ignore-touch-tablet-events-on-destroyed-surfaces.patch  |  241 ++
 patches/cssshadowvalue-Apply-device-scale-to-the-offset-when-blur.patch |   30 +
 patches/fontchooser-Fix-some-since-annotations.patch|   44 +
 patches/gdkpixbuf-drawable-Free-the-pixbuf-on-Cairo-error.patch |   23 
 patches/label-Skip-updating-link-state-if-we-have-no-layout.patch   |   31 +
 patches/placesview-Open-location-even-if-mount-was-not-found.patch  |   46 +
 patches/scale-Fix-sporadic-criticals.patch  |   52 ++
 patches/series  |   11 
 patches/updateiconcache-Sort-list-of-entries.patch  |1 
 patches/x11-Be-quiet-on-exit-by-default.patch   |   49 ++
 patches/x11-Don-t-beep-on-untrusted-displays.patch  |   42 +
 patches/x11-dnd-Ignore-XErrors-from-the-COW.patch   |   36 +
 14 files changed, 

Bug#970984: linux-image-5.8.0-2-amd64: Please replace console scrollback

[Salvatore Bonaccorso]

On Tue, Sep 29, 2020 at 09:48:47PM +0200, Salvatore Bonaccorso wrote:
> Hi Asher,
> 
> On Mon, Sep 28, 2020 at 04:16:40PM -0400, Asher Gordon wrote:
> > Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=209421
> > 
> > Hi Moritz,
> > 
> > Moritz Mühlenhoff  writes:
> > 
> > > Yeah, I'm also bitten by this for my day-to-day workflows, but
> > > unfortunately this was removed upstream, this is not a Debian-specific
> > > patch, so this needs to be fixed upstream, before it becomes available
> > > in Debian again.
> > 
> > OK, I forwarded this upstream here:
> > https://bugzilla.kernel.org/show_bug.cgi?id=209421
> 
> FTR, here is Linus statement on the removal and what needs to be done:
> https://lore.kernel.org/stable/CAHk-=whe4zdtdcebnewqc4gsqzwsvj5-emg0bucogcwphoa...@mail.gmail.com/
>  

I'm inclined to to just close this bug now as it probbly won't come
back, or if so it will flow automatically back into then rebased
versions of kernel in Debian.

I will not close it right now, to give a second pair of eyes time to
comment or take action.

Regards,
Salvatore

Bug#952298: sshcommand: diff for NMU version 0~20160110.1~2795f65-1.1

[Fabio Augusto De Muzio Tobich]

Sorry, forgot to say that I intend to do this NMU in 5 days in DELAYED/10.

Em 02/05/2021 09:56, Fabio A. De Muzio Tobich escreveu:

Dear maintainer,

I've prepared an NMU for sshcommand (versioned as 0~20160110.1~2795f65-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.



--
⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich
⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683
⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄  GPG:rsa4096/7EF63B2E

Bug#987946: ITP: capsule-maven-nextflow -- packaging tool for Java applications with Maven coordinates

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-med team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: capsule-maven-nextflow
  Version : 1.0.3.1
  Upstream Author : Paolo di Tommaso 
* URL : https://github.com/nextflow-io/capsule-maven
* License : EPL-1.0
  Programming Lang: Java
  Description : packaging tool for Java applications with Maven coordinates

A capsule is a single executable JAR that contains everything an application
needs to run either in the form of embedded files or as declarative metadata.
Maven Capsule is a capsule that allows the creations of capsules that, instead
of embedding their dependencies, download all or some of them from a Maven
repository. The dependencies are downloaded, cached locally, and shared among
other capsules that also depend on them. In addition, this capsule allows
specifying capsule metadata in a POM file in addition to the manifest.

A capsule with the Maven caplet that has all (or almost all) of its
dependencies downloaded rather than embedded is known as a "thin" capsule (as
opposed to a "fat" capsule, which embeds all of its dependencies). In fact, a
capsule may not contain any of the application's classes/JARs at all. Instead,
the capsule's manifest may contain these attributes alone (and no files in the
capsule JAR besides the manifest). When the capsule is launched, the newest
available version of the application will be downloaded, cached and launched.

This package contains a fork of the original capsule-maven project. This fork
is suited as a dependency of nextflow.