Bug#989193: [pkg-apparmor] Bug#989193: breaks apt-cacher-ng by blocking link operation

[Eduard Bloch]

Hallo,
* intrigeri [Wed, Jun 02 2021, 10:13:12AM]:
> Control: tag -1 + upstream
> Control: forwarded -1 
> https://gitlab.com/apparmor/apparmor-profiles/-/merge_requests/51
> Control: tag -1 + moreinfo
>
> Hi,
>
> Eduard Bloch (2021-05-28):
> > see attachment, your config which doesn't allow link calls, which
> > sporadically breaks operation of apt-cacher-ng in unexpected ways.
>
> Thanks! I've turned this patch into an upstream merge request.
>
> I see you've made this bug RC. I'd like to better understand the

I set it RC because it deliberately breaks other package's (legal)
operations, and installing such booby traps was not properly announced.

And because you take away the control over the package's behavior from
the maintainers and push them to "collaboration", if I understood
https://wiki.debian.org/AppArmor/Contribute/MergeProfileFromUpstream
correctly. In a way I don't like (shoot first, ask later).

> severity, so I can figure out what I should do for Bullseye.
> I'm wondering because I'm using this AppArmor policy on sid with

There were issues with rare file truncation, one of the potential
improvements was applies after soft-freeze. Line 847 at
https://salsa.debian.org/blade/apt-cacher-ng/-/blob/upstream/sid/source/fileitem.cc
which is a more careful rotation of files with volatile contents.

> apt-cacher-ng myself, and I can't find traces of such denials in
> my logs.

Please. Just because you don't see issues does not mean that issues
don't exist.

> Could you please help me understand what kind of apt-cacher-ng
> operations (or configuration) trigger these denials and are broken by
> the current AppArmor policy?

When the mentioned mechanism was put in place, regular operation started
breaking. This also affects the expiration jobs, therefore your cache
will keep growing when users use non-stable distros.

Or what exactly did make you think that "rw" is okay and everything else
can be dumped? Where are we? "I see all cars on my road are driving
straight, means that we can remove all steering wheels"? *facepalm*

Eduard.

Bug#942579:

[Rich]

Lest anyone think this is resolved, I just experienced it on buster,
running kernel 4.19.0-16-amd64 and 5.2+dfsg-9~bpo10+1 from
buster-backports.

In my case, though, I've used qemu-nbd without difficulty for raw
files on the order of 40G before without difficulty - but this time,
with a VDI of actual size ~19G and...let's call it "virtual" size
100GB, I wrote around a GB of data to it and then suddenly

[2005064.948700] block nbd0: Connection timed out
[2005064.951474] block nbd0: shutting down sockets
[2005064.951479] print_req_error: I/O error, dev nbd0, sector 39028592
[2005064.954230] block nbd0: Connection timed out
[2005064.956982] print_req_error: I/O error, dev nbd0, sector 39029104
[2005064.958271] block nbd0: Connection timed out
[2005064.959345] print_req_error: I/O error, dev nbd0, sector 39029360
[2005064.960527] block nbd0: Connection timed out
[2005064.961608] print_req_error: I/O error, dev nbd0, sector 39029616
[2005064.962677] block nbd0: Connection timed out
[2005064.963726] print_req_error: I/O error, dev nbd0, sector 39029872

(I presume if I hadn't noticed and had waited long enough I too would
see "task blocked for xyz seconds")

The fact that the original report on this particular bug was using a
VDI as well makes me suspect it might be a problem with handling VDIs
- I'm going to try converting it and report back...

- Rich

Bug#989579: arm-trusted-firmware: Raspberry pi builds

[Vagrant Cascadian]

On 2021-06-07, Nolan wrote:
> While it won't provide any real security features, it would let people 
> "fix" the pi's missing PSCI, which would enable the use of kexec.

There appear to be two rpi platforms in arm-trusted-firmware
v2.4. Reading the documentation on rpi3:

  
https://salsa.debian.org/debian/arm-trusted-firmware/-/blob/0f7062a50552947943316e83557dddb47fba3efe/docs/plat/rpi3.rst

There appear to be many permutations of possible configuration options,
so it is unclear exactly what to enable...


The documentation for rpi4:

  
https://salsa.debian.org/debian/arm-trusted-firmware/-/blob/0f7062a50552947943316e83557dddb47fba3efe/docs/plat/rpi4.rst

Is relatively simple and clear, though!


Could you spell out a little more what you'd like enabled, ideally with
a tested patch? :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#988830: [pre-approval] unblock e2fsprogs [Was: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel]

[Theodore Ts'o]

Control: tags -1 -moreinfo
thanks

On Sun, Jun 06, 2021 at 06:18:27AM +0200, Paul Gevers wrote:
> On 03-06-2021 22:06, Paul Gevers wrote:
> > As I can't judge this myself, I'll take your word for it. If the upload
> > can happen in the next couple of days, let's have this in unstable and
> > if nothing is reported, have it in bullseye.
> 
> Please removed the moreinfo tag once the package is available.

I've just uploaded the package to unstable.

The debdiff is attached for your convenience.

   - Ted

diff -Nru e2fsprogs-1.46.2/debian/changelog e2fsprogs-1.46.2/debian/changelog
--- e2fsprogs-1.46.2/debian/changelog   2021-02-28 21:24:34.0 -0500
+++ e2fsprogs-1.46.2/debian/changelog   2021-06-07 07:27:15.0 -0400
@@ -1,3 +1,18 @@
+e2fsprogs (1.46.2-2) unstable; urgency=medium
+
+  * Fix FTBFS on arm32 when building on a system with an arm64 kernel.
+This also fixes a portability problem when replaying a fast-commit
+journal on an arm64 kernel when using an arm32 userspace.
+(Closes: #987641)
+  * Fix additional fast-commit portability problems on non-x86 systems
+which don't allow non-aligned pointer dereferences (for example, on a
+sparc64 system).
+  * Fix a missing mutex unlock on an error path which can cause e2fsck
+to hang on I/O errors.
+  * Clean up and improve the man page for e2image
+
+ -- Theodore Y. Ts'o   Mon, 07 Jun 2021 07:27:15 -0400
+
 e2fsprogs (1.46.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
e2fsprogs-1.46.2/debian/patches/0001-e2fsck-fix-portability-problems-caused-by-unaligned-.patch
 
e2fsprogs-1.46.2/debian/patches/0001-e2fsck-fix-portability-problems-caused-by-unaligned-.patch
--- 
e2fsprogs-1.46.2/debian/patches/0001-e2fsck-fix-portability-problems-caused-by-unaligned-.patch
 1969-12-31 19:00:00.0 -0500
+++ 
e2fsprogs-1.46.2/debian/patches/0001-e2fsck-fix-portability-problems-caused-by-unaligned-.patch
 2021-06-07 07:27:15.0 -0400
@@ -0,0 +1,326 @@
+From 40960a7118171498448870b26d1c867f92fa430e Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o 
+Date: Mon, 3 May 2021 15:37:33 -0400
+Subject: [PATCH 1/5] e2fsck: fix portability problems caused by unaligned
+ accesses
+
+The on-disk format for the ext4 journal can have unaigned 32-bit
+integers.  This can happen when replaying a journal using a obsolete
+checksum format (which was never popularly used, since the v3 format
+replaced v2 while the metadata checksum feature was being stablized),
+and in the fast commit feature (which landed in the 5.10 kernel,
+although it is not enabled by default).
+
+This commit fixes the following regression tests on some platforms
+(such as running 32-bit arm architectures on a 64-bit arm kernel):
+j_recover_csum2_32bit, j_recover_csum2_64bit, j_recover_fast_commit.
+
+https://github.com/tytso/e2fsprogs/issues/65
+
+Addresses-Debian-Bug: #987641
+Signed-off-by: Theodore Ts'o 
+---
+ e2fsck/journal.c   | 83 --
+ e2fsck/recovery.c  | 22 
+ tests/j_recover_fast_commit/script |  1 -
+ 3 files changed, 56 insertions(+), 50 deletions(-)
+
+diff --git a/e2fsck/journal.c b/e2fsck/journal.c
+index a425bbd1..bd0e4f31 100644
+--- a/e2fsck/journal.c
 b/e2fsck/journal.c
+@@ -286,9 +286,9 @@ static int ext4_fc_replay_scan(journal_t *j, struct 
buffer_head *bh,
+   int ret = JBD2_FC_REPLAY_CONTINUE;
+   struct ext4_fc_add_range *ext;
+   struct ext4_fc_tl *tl;
+-  struct ext4_fc_tail *tail;
++  struct ext4_fc_tail tail;
+   __u8 *start, *end;
+-  struct ext4_fc_head *head;
++  struct ext4_fc_head head;
+   struct ext2fs_extent ext2fs_ex = {0};
+ 
+   state = >fc_replay_state;
+@@ -338,16 +338,15 @@ static int ext4_fc_replay_scan(journal_t *j, struct 
buffer_head *bh,
+   break;
+   case EXT4_FC_TAG_TAIL:
+   state->fc_cur_tag++;
+-  tail = (struct ext4_fc_tail *)ext4_fc_tag_val(tl);
++  memcpy(, ext4_fc_tag_val(tl), sizeof(tail));
+   state->fc_crc = jbd2_chksum(j, state->fc_crc, tl,
+   sizeof(*tl) +
+   offsetof(struct ext4_fc_tail,
+   fc_crc));
+   jbd_debug(1, "tail tid %d, expected %d\n",
+-  le32_to_cpu(tail->fc_tid),
+-  expected_tid);
+-  if (le32_to_cpu(tail->fc_tid) == expected_tid &&
+-  le32_to_cpu(tail->fc_crc) == state->fc_crc) {
++le32_to_cpu(tail.fc_tid), expected_tid);
++  if (le32_to_cpu(tail.fc_tid) == expected_tid &&
++  le32_to_cpu(tail.fc_crc) == state->fc_crc) {
+   

Bug#985982: redshift: reshift flickers randomly between night mode and daylight mode

[Bill Blough]

On my system, the repeated cycling between day and night only seems to happen
with the "randr" adjustment method.

If I manually set the method to "vidmode" either on the command line
(-m vidmode) or in the config file (adjustment-method = vidmode), the
color adjusts and stays constant as expected.

I haven't investigated any further, but maybe that's a work-around until
a proper fix can be found.

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#989585: openvswitch-switch-dpdk can't handle any traffics (but openvswitch-switch can)

[Harry Lee]

Package: openvswitch-switch-dpdk
Version: 2.15.0+ds1-2
Severity: important




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

Kernel: Linux 5.10.0-7-amd64 (SMP w/40 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages openvswitch-switch-dpdk depends on:
ii  dpdk20.11-7
ii  libc6   2.31-12
ii  libcap-ng0  0.7.9-2.2+b1
ii  librte-eal2120.11-7
ii  librte-ethdev21 20.11-7
ii  librte-mbuf21   20.11-7
ii  librte-mempool2120.11-7
ii  librte-meter21  20.11-7
ii  librte-vhost21  20.11-7
ii  libssl1.1   1.1.1k-1
ii  libunbound8 1.13.1-1
ii  openvswitch-common  2.15.0+ds1-2
ii  openvswitch-switch  2.15.0+ds1-2

openvswitch-switch-dpdk recommends no packages.

openvswitch-switch-dpdk suggests no packages.

-- no debconf information



I created a br0 and add eth1 to it:
```
# ovs-vsctl show
56e6bee8-0467-4803-9306-fa5f1286745c
Bridge br0
Port eth1
Interface eth1
Port br0
Interface br0
type: internal
ovs_version: "2.15.0"
```

Then I try two ovs versions:
```
# switch ovs version to ovs-vswitchd
update-alternatives --set ovs-vswitchd /usr/lib/openvswitch-common/ovs-vswitchd
/etc/init.d/openvswitch-switch restart
ip link set br0 up
ip addr add 10.90.67.148/25 dev br0
ping 10.90.67.129  # network is ok

# switch ovs version to ovs-vswitchd-dpdk, and I didn't enable dpdk.
update-alternatives --set ovs-vswitchd 
/usr/lib/openvswitch-switch-dpdk/ovs-vswitchd-dpdk
/etc/init.d/openvswitch-switch restart
ip link set br0 up
ip addr add 10.90.67.148/25 dev br0
ping 10.90.67.129  # unreachable
```

When using ovs-vswitchd-dpdk, there are some warnings in ovs-vswitchd.log:
```
2021-06-07T10:36:26.790Z|1|vlog|INFO|opened log file 
/var/log/openvswitch/ovs-vswitchd.log
2021-06-07T10:36:26.794Z|2|ovs_numa|INFO|Discovered 20 CPU cores on NUMA 
node 0
2021-06-07T10:36:26.795Z|3|ovs_numa|INFO|Discovered 20 CPU cores on NUMA 
node 1
2021-06-07T10:36:26.795Z|4|ovs_numa|INFO|Discovered 2 NUMA nodes and 40 CPU 
cores
2021-06-07T10:36:26.795Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connecting...
2021-06-07T10:36:26.795Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connected
2021-06-07T10:36:26.799Z|7|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.15.0
2021-06-07T10:36:26.801Z|8|dpdk|INFO|DPDK Disabled - Use 
other_config:dpdk-init to enable
2021-06-07T10:36:26.830Z|9|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports recirculation
2021-06-07T10:36:26.830Z|00010|ofproto_dpif|INFO|system@ovs-system: VLAN header 
stack length probed as 2
2021-06-07T10:36:26.830Z|00011|ofproto_dpif|INFO|system@ovs-system: MPLS label 
stack length probed as 3
2021-06-07T10:36:26.830Z|00012|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports truncate action
2021-06-07T10:36:26.830Z|00013|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports unique flow ids
2021-06-07T10:36:26.830Z|00014|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports clone action
2021-06-07T10:36:26.831Z|00015|ofproto_dpif|INFO|system@ovs-system: Max sample 
nesting level probed as 10
2021-06-07T10:36:26.831Z|00016|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports eventmask in conntrack action
2021-06-07T10:36:26.831Z|00017|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_clear action
2021-06-07T10:36:26.831Z|00018|ofproto_dpif|INFO|system@ovs-system: Max dp_hash 
algorithm probed to be 0
2021-06-07T10:36:26.831Z|00019|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports check_pkt_len action
2021-06-07T10:36:26.831Z|00020|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports timeout policy in conntrack action
2021-06-07T10:36:26.831Z|00021|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_state
2021-06-07T10:36:26.831Z|00022|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_zone
2021-06-07T10:36:26.831Z|00023|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_mark
2021-06-07T10:36:26.831Z|00024|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_label
2021-06-07T10:36:26.831Z|00025|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_state_nat
2021-06-07T10:36:26.831Z|00026|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_orig_tuple
2021-06-07T10:36:26.831Z|00027|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_orig_tuple6
2021-06-07T10:36:26.831Z|00028|ofproto_dpif|INFO|system@ovs-system: Datapath 
does not support IPv6 ND Extensions
2021-06-07T10:36:27.004Z|00029|bridge|INFO|bridge br0: added interface br0 on 
port 65534
2021-06-07T10:36:27.004Z|00030|bridge|INFO|bridge br0: added interface eth1 on 
port 1
2021-06-07T10:36:27.004Z|00031|bridge|INFO|bridge br0: using 

Bug#989584: dovecot-core: systemd unit does not wait for remote-fs.target

[Hamish Moffatt]

The effect of this of course that is dovecot doesn't start if its 
configuration depends on files on a remote file system.

Bug#989584: dovecot-core: systemd unit does not wait for remote-fs.target

[Hamish Moffatt]

Package: dovecot-core
Version: 1:2.3.4.1-5+deb10u6
Severity: normal

The systemd unit does not specify that dovecot should be started after
remote-fs.target (in after= clause). This is in contrast to the init.d
script, which does specify it should wait for $remote_fs.

Most other similar packages (exim4, apache, greylistd) do wait on
remote-fs.target.

I have checked the package in buster and it is also affected.


Hamish

-- Package-specific info:

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

Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dovecot-core depends on:
ii  adduser  3.118
ii  libapparmor1 2.13.2-10
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libexttextcat-2.0-0  3.4.5-1
ii  libicu63 63.1-6+deb10u1
ii  liblua5.3-0  5.3.3-1.1
ii  liblz4-1 1.8.3-1+deb10u1
ii  liblzma5 5.2.4-1
ii  libpam-runtime   1.3.1-5
ii  libpam0g 1.3.1-5
ii  libsodium23  1.0.17-1
ii  libssl1.11.1.1d-0+deb10u6
ii  libstemmer0d 0+svn585-1+b2
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2019051400
ii  openssl  1.1.1d-0+deb10u6
ii  ssl-cert 1.0.39
ii  ucf  3.0038+nmu1
ii  zlib1g   1:1.2.11.dfsg-1

dovecot-core recommends no packages.

Versions of packages dovecot-core suggests:
pn  dovecot-gssapi
ii  dovecot-imapd 1:2.3.4.1-5+deb10u6
pn  dovecot-ldap  
pn  dovecot-lmtpd 
pn  dovecot-lucene
pn  dovecot-managesieved  
pn  dovecot-mysql 
pn  dovecot-pgsql 
pn  dovecot-pop3d 
pn  dovecot-sieve 
pn  dovecot-solr  
pn  dovecot-sqlite
pn  dovecot-submissiond   
ii  ntp   1:4.2.8p12+dfsg-4

Versions of packages dovecot-core is related to:
ii  dovecot-core [dovecot-common]  1:2.3.4.1-5+deb10u6
pn  dovecot-dev
pn  dovecot-gssapi 
ii  dovecot-imapd  1:2.3.4.1-5+deb10u6
pn  dovecot-ldap   
pn  dovecot-lmtpd  
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
pn  dovecot-sieve  
pn  dovecot-sqlite 

-- no debconf information

Bug#989453: Debian: gcc: add support for ARC

[Vineet Gupta]

On 6/5/21 4:12 AM, Matthias Klose wrote:
> Control: tags -1 + incomplete
> 
> These definitions have to go first to
> https://wiki.debian.org/Multiarch/Tuples
> 
> Please update.

Wiki page updated now.

Thx,
-Vineet

Bug#989583: liblip: Fails to build reproducibly: multiple problems

[Nilesh Patra]

Source: liblip
Version: 2.0.0-1.2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps, buildpath
X-Debbugs-Cc: nil...@debian.org, nil...@debian.org, 
reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

The following problems cause problems in liblip being reproducible:

a) It embeds timestamps into gzip headers, simply passing -n with gzip
  fixes it
b) md5sum that it injects to DEBIAN/md5sums are random in order, simply
  sorting them does the trick
c) It embeds buildpath in resulting .deb because -ffile-prefix-map isn't
  injected by default since this does not seem to use debhelper, and uses a 
hand-coded d/rules w/o dh
  customizations and compat level. Manually adding the -ffile-prefix-map
  with relevant options seems to do the trick.

Please consider applying the attached patch.

Thanks!
Nilesh


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- a/debian/rules
+++ b/debian/rules
@@ -4,16 +4,19 @@
 
 STRIP  = strip --strip-unneeded --remove-section=.comment 
--remove-section=.note
 
+CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)
+CXXFLAGS += -ffile-prefix-map=$(CURDIR)=.
+
 build:
$(checkdir)
cp -f /usr/share/misc/config.sub .
cp -f /usr/share/misc/config.guess .
./configure --prefix=/usr --enable-shared
-   $(MAKE) install prefix=$(CURDIR)/shared
+   $(MAKE) install prefix=$(CURDIR)/shared CXXFLAGS="$(CXXFLAGS)"
[ ! -f Makefile ] || $(MAKE) distclean
-rm -f config.log config.cache
./configure --prefix=/usr --enable-static
-   $(MAKE) install prefix=$(CURDIR)/static
+   $(MAKE) install prefix=$(CURDIR)/static CXXFLAGS="$(CXXFLAGS)"
touch build
 
 clean:
@@ -59,20 +62,22 @@ binary-arch: checkroot build
cp -p docs/* debian/liblip2/usr/share/doc/liblip2/
cp -p examples/example* debian/liblip2/usr/share/doc/liblip2/examples
cp -p examples/makefile debian/liblip2/usr/share/doc/liblip2/examples
-   cd debian/liblip2/usr/share/doc/liblip2 && gzip -9 changelog.Debian 
examples/*
+   cd debian/liblip2/usr/share/doc/liblip2 && gzip -9n changelog.Debian 
examples/*
 
ln -s liblip2 debian/liblip-dev/usr/share/doc/liblip-dev
 
dpkg-shlibdeps debian/liblip2/usr/lib/lip/*
dpkg-gencontrol -isp -pliblip2 -Pdebian/liblip2
-   cd debian/liblip2 && md5sum `find * -type f ! -regex "DEBIAN/.*"` > 
DEBIAN/md5sums
+   cd debian/liblip2 && find * -type f ! -regex "DEBIAN/.*" -print0 |\
+   LC_ALL=C sort -z | xargs -0r md5sum > DEBIAN/md5sums
chown -R root.root debian/liblip2
chmod -x debian/liblip2/usr/lib/lip/*
chmod -R go=rX debian/liblip2
dpkg --build debian/liblip2 ..
 
dpkg-gencontrol -isp -pliblip-dev -Pdebian/liblip-dev
-   cd debian/liblip-dev && md5sum `find * -type f ! -regex "DEBIAN/.*"` > 
DEBIAN/md5sums
+   cd debian/liblip-dev && find * -type f ! -regex "DEBIAN/.*" -print0 |\
+   LC_ALL=C sort -z | xargs -0r md5sum > DEBIAN/md5sums
chown -R root.root debian/liblip-dev
chmod -x debian/liblip-dev/usr/lib/lip/liblip.a
chmod -x debian/liblip-dev/usr/lib/lip/liblip.la

Bug#989582: unblock: darktable/3.4.1-4

[David Bremner]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package darktable

[ Reason ]

This version contains a fix for #989222.  This involves a crash when
exporting raws of a certain format.  According to Jonas this bug is
triggered by output from megapixels which is in bullseye and used by
(at least) the Librem 5 and pinephone (with mobian).

[ Impact ]

Users of some free software friendly phones will be unable to process
their images with darktable from bullseye.

[ Tests ]

I have verified the basic functionality of darktable is still
OK. Jonas tested the DNG images in question and verified that they
exported OK now.

[ Risks ]

darktable is a leaf package. The diff is a bit large, but most of it
is deletions of SSE2 specialized code. The additions are only 7 lines
and easy to sanity check.

[ 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

[ Other info ]

I also attach a "reduced diff" with the deleted #ifdef __SSE__ blocks
collapsed.

unblock darktable/3.4.1-4


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmC+o1YACgkQA0U5G1Wq
FSGEug/+NjvWDdVP6jwcU0rXEUCHpgPbqYXygkVn4TIyVeqRh1e6DJCwU3mzkNo8
DnR7siTEdXp6F9e1MpCaN9G404ptk7MZasN6Aswu5Fj37knj6YzhYnrqp6fbgurL
w1dcbNhnSSlPf6czeDtSIe0uIIR3TNbhG0ICX8D6xhTumolW0+EtPHTcG8E9y7Ib
f+wlp/0mwwdpmeYB32ObkF8v4t7g4f9Y1SWrjPI0xZ/tgYiDgY8nOW39a4Nj0HQX
HzqW0oQXMaLsjFecEv7Wuf3VTWmmBubKKANvs++Lg/EQi3pbjeVMzDa2WuZBTxUL
YHe0bW012OWOtgnfuLuKdIvots8afNYpi1jtS58e4ZT1wHxEvUW2ww09jjcrnsdP
CnKFT5Ybg3WZ7rqUQ8VsYXkgCe5CdauFAlKdWluTK2SAXn7brfvnpzpUpTzFbxRN
zOtZfwPqsCJt8l3rPoMdLIlD5IQAxkPavyc1ow3bym/IIEiuVXCSSbohRHYyUBDT
lQyM7aAVi8aawGVpbB/2MeuBsdWMPCx37etU/Jz3YMtqhC1rIi6OMVoXWFb1BAAQ
sGjgRvrSes/2bkODcC/YBE9jNKinsLXbCbhQU50ObEQqHb7yeec9DsPe7NYfvhGN
22ueQyjNT1LguYVwsNzPE1WBobrSwghdFh8MFcJwNuqJR3SnEDI=
=o+Yk
-END PGP SIGNATURE-
diff -Nru darktable-3.4.1/debian/changelog darktable-3.4.1/debian/changelog
--- darktable-3.4.1/debian/changelog2021-05-20 14:07:16.0 -0300
+++ darktable-3.4.1/debian/changelog2021-06-05 12:41:39.0 -0300
@@ -1,3 +1,11 @@
+darktable (3.4.1-4) unstable; urgency=medium
+
+  * Bug fix: "crashes with 'Floating point exception (core dumped)' after
+loading some DNG files", thanks to Jonas Smedegaard (Closes: #989222).
+Cherry pick upstream commit 2ff4fc58e44.
+
+ -- David Bremner   Sat, 05 Jun 2021 12:41:39 -0300
+
 darktable (3.4.1-3) unstable; urgency=medium
 
   * Bug fix: "broken symlinks: /usr/share/darktable/js/*.js -
diff -Nru 
darktable-3.4.1/debian/patches/0002-Avoid-div-by-zero-in-dt_iop_clip_and_zoom_mosaic_hal.patch
 
darktable-3.4.1/debian/patches/0002-Avoid-div-by-zero-in-dt_iop_clip_and_zoom_mosaic_hal.patch
--- 
darktable-3.4.1/debian/patches/0002-Avoid-div-by-zero-in-dt_iop_clip_and_zoom_mosaic_hal.patch
  1969-12-31 20:00:00.0 -0400
+++ 
darktable-3.4.1/debian/patches/0002-Avoid-div-by-zero-in-dt_iop_clip_and_zoom_mosaic_hal.patch
  2021-06-05 12:41:39.0 -0300
@@ -0,0 +1,1001 @@
+From: Hanno Schwalm 
+Date: Fri, 14 May 2021 18:20:37 +0200
+Subject: Avoid div by zero in dt_iop_clip_and_zoom_mosaic_half_size (#8954)
+
+* Avoid div by zero in dt_iop_clip_and_zoom_mosaic_half_size_plain
+
+Fixes #8951
+
+Although the file given in the issue is crippled we can avoid the crash.
+In `dt_iop_clip_and_zoom_mosaic_half_size` and the sse friend there is 
possibly a div/0
+problem that should be checked.
+
+* Fixing same dib by zero in dt_iop_clip_and_zoom_mosaic_half_size_f
+
+* Remove sse code for dt_iop_clip_and_zoom_mosaic... after testing performance
+
+checked performance non-sse vs sse specific code
+- with added local timers
+- using gcc 10.2
+- testing -t 1/4/8/16
+- intel (xeon like 9900) with fixed clock rate
+
+in
+- dt_iop_clip_and_zoom_mosaic_half_size
+- dt_iop_clip_and_zoom_mosaic_half_size_f
+- dt_iop_clip_and_zoom_demosaic_passthrough_monochrome_f
+- dt_iop_clip_and_zoom_demosaic_half_size_f
+
+with consitant results. For all functions the sse specific code was somewhat 
slower (~20%)
+than the vectorized compiler code. Number of omp cores didn't matter, just 
made the results
+more measurable because of low execution times.
+
+So i removed all the sse specific code for less code burden and better 
performance.
+
+* Fix sse header plus div/0
+
+At least for bayer images we absolutely want to be sure there is no div by 
zero as there might
+be buggy dng files.
+---
+ src/develop/imageop_math.c | 890 +
+ 1 file changed, 7 insertions(+), 883 deletions(-)
+
+diff --git a/src/develop/imageop_math.c b/src/develop/imageop_math.c
+index ef55965..0066a83 100644
+--- a/src/develop/imageop_math.c
 b/src/develop/imageop_math.c
+@@ -18,14 +18,8 @@
+ 
+ #include "develop/imageop_math.h"
+ 

Bug#989575: cloud-init: ca-certs are not getting properly installed if provided more than one

[Noah Meyerhans]

On Mon, Jun 07, 2021 at 11:00:42PM +0200, Vladimir Tiukhtin wrote:
> I use "ca-certs" to supply additional certificates. With just one certiticate 
> everything
> works as expected, however when provided more than one, cloud-init adds them 
> into a single
> file which causes "openssl rehash" to fail as it expects exactly one 
> certificate per file.
> As the result programmes using openssl doen not trus certificates issued by 
> provided CAs.

The certificates do still get added to
/etc/ssl/certs/ca-certificates.crt, so you should still be able to do
file-based verification even if path-based verification doesn't work.
(See
https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_default_verify_file.html
and the -CApath and -CAfile options to "openssl verify")

> The bug is confirmed on Hetzner Cloud. I did not try other clouds

There's nothing provider specific about this functionality, so it will
impact people regardless of where cloud-init is running.

I've forwarded your report upstream. See
https://bugs.launchpad.net/cloud-init/+bug/1931174

noah

Bug#989580: 2nd patch

[dann frazier]

Upon proof-reading, I realized I missed another reference:
https://lore.kernel.org/linux-man/20210607221943.78414-1-dann.fraz...@canonical.com/T/#u

Bug#989581:

[Fabrice Bauzac-Stehly]

Tags: patch

I humbly propose this change:

>From 4de312af857234e20b5e01b5b2fa61fa50496995 Mon Sep 17 00:00:00 2001
From: Fabrice Bauzac 
Date: Tue, 8 Jun 2021 00:00:38 +0200
Subject: [PATCH] autopkgtest: mark ADTTMP as obsolete, replaced with
 AUTOPKGTEST_TMP

Closes: #989581.
---
 autopkgtest.md   | 19 ++-
 debian/changelog |  4 
 2 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/autopkgtest.md b/autopkgtest.md
index c984a23..1480ba7 100644
--- a/autopkgtest.md
+++ b/autopkgtest.md
@@ -30,10 +30,11 @@ If the file to be executed has no execute bits set, `chmod a+x` is
 applied to it (this means that tests can be added in patches without the
 need for additional chmod; contrast this with debian/rules).
 
-During execution of the test, the environment variable `$ADTTMP` will
+During execution of the test, the environment variable
+`$AUTOPKGTEST_TMP` (previously named `$ADTTMP`, now obsolete) will
 point to a directory for the execution of this particular test, which
-starts empty and will be deleted afterwards (so there is no need for the
-test to clean up files left there).
+starts empty and will be deleted afterwards (so there is no need for
+the test to clean up files left there).
 
 If tests want to create artifacts which are useful to attach to test
 results, such as additional log files or screenshots, they can put them
@@ -166,13 +167,13 @@ Defined restrictions
   running the tests. However, the tests are *not* entitled to assume that the
   source package's build dependencies will be installed when the test is run.
 
-  Please use this considerately, as for large builds it unnecessarily builds
-  the entire project when you only need a tiny subset (like the tests/
+  Please use this considerately, as for large builds it unnecessarily builds the
+  entire project when you only need a tiny subset (like the tests/
   subdirectory). It is often possible to run `make -C tests` instead, or copy
-  the test code to `$ADTTMP` and build it there with some custom commands. This
-  cuts down the load on the Continuous Integration servers and also makes tests
-  more robust as it prevents accidentally running them against the built source
-  tree instead of the installed packages.
+  the test code to `$AUTOPKGTEST_TMP` and build it there with some custom
+  commands. This cuts down the load on the Continuous Integration servers and
+  also makes tests more robust as it prevents accidentally running them against
+  the built source tree instead of the installed packages.
 
 - **allow-stderr**
 
diff --git a/debian/changelog b/debian/changelog
index c4cc189..426a931 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,13 @@
 debian-policy (4.5.1.1) UNRELEASED; urgency=medium
 
+  [ Sean Whitton ]
   * 4.4: Fix changelog format: needs an extra space before sign-off
 (Closes: #976301).
 Thanks to Anatoli Babenia for reporting the problem.
 
+  [ Fabrice Bauzac-Stehly ]
+  * autopkgtest: mark ADTTMP as obsolete, replaced with AUTOPKGTEST_TMP.
+Closes: #989581.
 
  -- Sean Whitton   Tue, 19 Jan 2021 13:47:45 -0700
 
-- 
2.30.2

Bug#989580: patch

[dann frazier]

Attached.
diff -Nru manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch
--- manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch	1969-12-31 17:00:00.0 -0700
+++ manpages-5.10/debian/patches/0014-kernel_lockdown.7.patch	2021-06-07 15:55:43.0 -0600
@@ -0,0 +1,45 @@
+From 09df87e9ee3e1a429a2c1709dfd16ec8ff0f6160 Mon Sep 17 00:00:00 2001
+From: dann frazier 
+Date: Wed, 26 May 2021 11:34:55 -0600
+Subject: [PATCH] kernel_lockdown.7: Remove description of lifting via SysRq
+ (not upstream)
+
+The patch that implemented lockdown lifting via SysRq ended up getting
+dropped[*] before the feature was merged upstream. Having the feature
+documented but unsupported has caused some confusion for our users.
+
+[*] http://archive.lwn.net:8080/linux-kernel/cacdnjuuxam06tcnczoa6nwxhnmqueqqm3ma8btukzpucs+d...@mail.gmail.com/
+
+Signed-off-by: dann frazier 
+Cc: Heinrich Schuchardt 
+Cc: David Howells 
+Cc: Pedro Principeza 
+Cc: Randy Dunlap 
+Cc: Kyle McMartin 
+Cc: Matthew Garrett 
+Signed-off-by: Alejandro Colomar 
+
+Bug-Debian: https://bugs.debian.org/989580
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1931171
+Origin: https://github.com/alejandro-colomar/man-pages/commit/09df87e9ee3e1a429a2c1709dfd16ec8ff0f616
+Last-Update: 2021-06-07
+
+diff --git a/man7/kernel_lockdown.7 b/man7/kernel_lockdown.7
+index 30863de62..b0442b3b6 100644
+--- a/man7/kernel_lockdown.7
 b/man7/kernel_lockdown.7
+@@ -33,11 +33,6 @@ where X indicates the process name and Y indicates what is restricted.
+ .PP
+ On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled
+ if the system boots in EFI Secure Boot mode.
+-.PP
+-If the kernel is appropriately configured, lockdown may be lifted by typing
+-the appropriate sequence on a directly attached physical keyboard.
+-For x86 machines, this is
+-.IR SysRq+x .
+ .\"
+ .SS Coverage
+ When lockdown is in effect, a number of features are disabled or have their
+-- 
+2.32.0
+
diff -Nru manpages-5.10/debian/patches/series manpages-5.10/debian/patches/series
--- manpages-5.10/debian/patches/series	2020-12-22 06:18:53.0 -0700
+++ manpages-5.10/debian/patches/series	2021-06-07 15:34:58.0 -0600
@@ -10,3 +10,4 @@
 0010-tzfile.5.patch
 0011-man.7.patch
 0013-rtnetlink.7.patch
+0014-kernel_lockdown.7.patch

Bug#989581: autopkgtest: ADTTMP is now obsolete

[Fabrice BAUZAC]

Package: debian-policy
Version: 4.5.1.0
Severity: normal

Hello,

autopkgtest.md only mentions the ADTTMP environment variable, while
lintian marks ADTTMP usage as deprecated in favour of AUTOPKGTEST_TMP.

See https://lintian.debian.org/tags/uses-deprecated-adttmp

I think autopkgtest.md should at least mention the new variable...

Thanks!

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 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=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  3.4.3-2

Versions of packages debian-policy suggests:
ii  doc-base  0.11.1

-- no debconf information

Bug#989580: kernel_lockdown(7) describes removed SysRq for lifting lockdown

[dann frazier]

Package: manpages
Version: 5.10-1
Severity: normal
Tags: upstream patch

The patch that implemented lockdown lifting via SysRq ended up getting
dropped[*] before the feature was merged upstream, but the man page still
describes it.

I've submitted a patch upstream which has been accepted by a comaintainer:
  
https://github.com/alejandro-colomar/man-pages/commit/09df87e9ee3e1a429a2c1709dfd16ec8ff0f616

IMHO, it would be good to see if we can include this in bullseye since
Secure Boot/lockdown is becoming more widely used.

[*] 
http://archive.lwn.net:8080/linux-kernel/cacdnjuuxam06tcnczoa6nwxhnmqueqqm3ma8btukzpucs+d...@mail.gmail.com/

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  man-db [man-browser]  2.9.4-2

-- no debconf information

Bug#989579: arm-trusted-firmware: Raspberry pi builds

[Nolan]

Source: arm-trusted-firmware
Severity: wishlist

Hello,

While it won't provide any real security features, it would let people 
"fix" the pi's missing PSCI, which would enable the use of kexec.


- nolan

Bug#989571: linux-image-5.10.0-0.bpo.3-amd64: Incorrect large USB disk sizing leading to data corruption

[Anton Ivanov]

Close please.

The 17G was from trying to blank the drive, which for some reason 
disconnected in the process resulting in a file written in /dev with the 
name sda. From there on the loop and so on. So there was a /dev/sda file 
as a left-over after that. Thanks for pointing me in the right direction 
and apologies.


I am going to continue investigating why I got the data corruption in 
the first place, before I tried to blank it, but it looks like it may 
have been a hardware issue with the original USB-to-ATA bridge.


--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#989578: memstat: please clarify license

[Roland Hieber]

Package: memstat
Severity: normal

Dear Maintainer,

The best license statement I could find was line 8 in memstat.c:

Distribution subject to the terms of the GPL.

Is this meant to be equivalent to "GPL 1.0, or at your option, any later
version", or something else?

Cheers,

 - Roland


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

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages memstat depends on:
ii  libc6  2.31-11

memstat recommends no packages.

memstat suggests no packages.

Bug#983095: pidgin: 5353/udp probe every 2 sec

[Richard Laager]

Unfortunately, I don't see any references to 5353 in any of that. 
However, I do see a mention of libgstmicrodns.so. I wonder if that's 
related. Could you run:


dpkg -S /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstmicrodns.so

Then remove whatever package ships that library? You can reinstall it 
again after running the test. Or, if you're worried about removing it 
(e.g. if it's something you can't reinstall easily), maybe you can just 
rename libgstmicrodns.so out of the way and test?


--
Richard

Bug#989577: vim: highlight: Makefile: .SECONDEXPANSION: not correctly highlighted

[Alejandro Colomar]

Package: vim
Version: 2:8.2.2434-3
Severity: minor
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear Maintainer,

.SECONDEXPANSION: is a special target in a Makefile, similar to .PHONY:,
but it isn't being highlighted as such, and instead is being colored as any
other normal target.

Could you please mark it as a special target?

Thanks,

Alex

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

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

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

Versions of packages vim depends on:
ii  libacl1  2.2.53-10
ii  libc62.31-11
ii  libgpm2  1.20.7-8
ii  libselinux1  3.1-3
ii  libtinfo66.2+20201114-2
ii  vim-common   2:8.2.2434-3
ii  vim-runtime  2:8.2.2434-3

vim recommends no packages.

Versions of packages vim suggests:
pn  ctags
pn  vim-doc  
pn  vim-scripts  

-- no debconf information

Bug#989576: cura crashes at exit due to Qt version mismatch

[Dennis Boone]

Package: cura
Version: 4.8-4
Severity: minor
X-Debbugs-Cc: d...@msu.edu

Cura crashes at exit, every time.  This doesn't seem to cause
operational problems, but it does leave a lot of coredumps lying around.

In a github issue discussion, a maintainer indicated that this is
because it needs Qt 5.10, not 5.15.

https://github.com/Ultimaker/Cura/issues/9837

It might be worth packaging 4.9.1 now, which theoretically is ok with
5.15, though see the above issue for discussion of some other problem.

Thanks for packaging cura.


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

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

Versions of packages cura depends on:
ii  cura-engine 1:4.8-1
ii  fdm-materials   4.8-1
ii  fonts-open-sans 1.11-1.1
ii  python3 3.9.2-3
ii  python3-certifi 2020.6.20-1
ii  python3-charon  4.8-1
ii  python3-cryptography3.3.2-1
ii  python3-pynest2d4.8.0-2
ii  python3-pyqt5   5.15.2+dfsg-3
ii  python3-pyqt5.qtopengl  5.15.2+dfsg-3
ii  python3-requests2.25.1+dfsg-2
ii  python3-savitar 4.8-1+b1
ii  python3-serial  3.5~b0-1
ii  python3-shapely 1.7.1-2
ii  python3-uranium 4.8-1
ii  qml-module-qt-labs-folderlistmodel  5.15.2+dfsg-5
ii  qml-module-qt-labs-settings 5.15.2+dfsg-5
ii  qml-module-qtqml-models25.15.2+dfsg-5
ii  qml-module-qtquick-controls 5.15.2-2
ii  qml-module-qtquick-controls25.15.2+dfsg-2
ii  qml-module-qtquick-dialogs  5.15.2-2
ii  uranium-plugins 4.8-1

Versions of packages cura recommends:
ii  python3-zeroconf  0.26.1-1

cura suggests no packages.

-- no debconf information

Bug#989575: cloud-init: ca-certs are not getting properly installed if provided more than one

[Vladimir Tiukhtin]

Package: cloud-init
Version: 20.2-2~deb10u2
Severity: important

Dear Maintainer,

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

I use "ca-certs" to supply additional certificates. With just one certiticate 
everything
works as expected, however when provided more than one, cloud-init adds them 
into a single
file which causes "openssl rehash" to fail as it expects exactly one 
certificate per file.
As the result programmes using openssl doen not trus certificates issued by 
provided CAs.
The bug is confirmed on Hetzner Cloud. I did not try other clouds

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


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cloud-init depends on:
ii  fdisk   2.33.1-0.1
ii  gdisk   1.0.3-1.1
ii  ifupdown0.8.35
ii  locales 2.28-10
ii  lsb-base10.2019051400
ii  lsb-release 10.2019051400
ii  net-tools   1.60+git20180626.aebd88e-1
ii  procps  2:3.3.15-2
ii  python3 3.7.3-1
ii  python3-configobj   5.0.6-3
ii  python3-jinja2  2.10-2
ii  python3-jsonpatch   1.21-1
ii  python3-jsonschema  2.6.0-4
ii  python3-oauthlib2.1.0-1
ii  python3-requests2.21.0-1
ii  python3-yaml3.13-2
ii  util-linux  2.33.1-0.1

Versions of packages cloud-init recommends:
ii  cloud-guest-utils  0.29-1
ii  eatmydata  105-7
ii  sudo   1.8.27-1+deb10u3

Versions of packages cloud-init suggests:
ii  btrfs-progs  4.20.1-2
ii  e2fsprogs1.44.5-1+deb10u3
ii  xfsprogs 4.20.0-1

-- no debconf information

Bug#989574: mlocate: fuse.rclone fs type should be on default prunefs list

[Stefan Breunig]

Package: mlocate
Version: 0.26-5
Severity: wishlist

Dear Maintainer,

mlocate already excludes many FSes that are commonly mounted over the network,
and thus slow (e.g. fuse.sshfs). I suggest to add "fuse.rclone" to the PRUNEFS
list in the updatedb.conf, since rclone is also typically used to mount network
drives.

To verify locally, you can instruct rclone to mount a local directory; rougly:
  apt install rclone
  rclone config create local local
  rclone mount local:/source-dir /target-dir

Cheers
Stefan

PS: I have already created the same bug for plocate (#989520) which uses/used
the same configuration file/scheme

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

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

Versions of packages mlocate depends on:
ii  adduser  3.118
ii  libc62.31-1

mlocate recommends no packages.

Versions of packages mlocate suggests:
pn  nocache  

-- Configuration Files:
/etc/updatedb.conf changed [not included]

-- no debconf information

Bug#989571: linux-image-5.10.0-0.bpo.3-amd64: Incorrect large USB disk sizing leading to data corruption

[Bastian Blank]

Control: severity -1 important
Control: tags -1 moreinfo

On Mon, Jun 07, 2021 at 08:43:21PM +0100, Anton Ivanov wrote:
> Version: 5.10.13-1~bpo10+1

This is not the latest version. 5.10.24 (at least) is in buster-backports.

> [801076.291139] scsi host10: uas
> [801076.291557] scsi 10:0:0:0: Direct-Access ASMT 2115 0  
>   PQ: 0 ANSI: 6
> [801076.292065] sd 10:0:0:0: Attached scsi generic sg0 type 0
> [801076.292232] sd 10:0:0:0: [sda] Spinning up disk...
> [801077.321342] ..ready
> [801082.447597] sd 10:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 
> TB/3.64 TiB)
> [801082.447600] sd 10:0:0:0: [sda] 4096-byte physical blocks
> [801082.447673] sd 10:0:0:0: [sda] Write Protect is off
> [801082.447674] sd 10:0:0:0: [sda] Mode Sense: 43 00 00 00
> [801082.447832] sd 10:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
> doesn't support DPO or FUA
> [801082.448032] sd 10:0:0:0: [sda] Optimal transfer size 33553920 bytes not a 
> multiple of physical block size (4096 bytes)
> [801082.494646] sd 10:0:0:0: [sda] Attached SCSI disk

So it detects a 4TB disk called sda.  Not a <20GB as you claimed.

> [801150.687429] loop: module loaded
> [801150.815997] EXT4-fs (loop0): mounted filesystem with ordered data mode. 
> Opts: (null)
> [803002.579925] blk_update_request: I/O error, dev loop0, sector 0 op 
> 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
> [803002.579960] blk_update_request: I/O error, dev loop0, sector 0 op 
> 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0

But you mount an unrelated loop0.  Don't do that?  Okay, write requests
fail.

> [803318.984016] EXT4-fs (loop0): mounting ext3 file system using the ext4 
> subsystem
> [803318.984583] EXT4-fs (loop0): mounted filesystem with ordered data mode. 
> Opts: (null)

Again you mount loop0, but now it sees an ext3, not an ext4 on it.

Something on your system creates loop devices.  You have to find it.

Maybe the output of "lsblk" can help to see what you actually have.

Bastian

-- 
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.

Bug#989573: unblock: pam-u2f/1.1.0-1.1

[Salvatore Bonaccorso]

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

Hi Release Team,

Please unblock package pam-u2f

[ Reason / Impact ]
pam-u2f 1.1.0 upstream and so in Debian bullseye was affected by
CVE-2021-31924, #987545. which can lead, depending on the pam-u2f
configuration and the application used, to local PIN bypass.

[ Tests ]
None specific, the enabled tests pass.
(What automated or manual tests cover the affected code?)

[ Risks ]
Small, the patch applied comes from upstream for the affected branch
and is targeted.

[ 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 pam-u2f/1.1.0-1.1

Regards,
Salvatore
diff -Nru pam-u2f-1.1.0/debian/changelog pam-u2f-1.1.0/debian/changelog
--- pam-u2f-1.1.0/debian/changelog  2020-11-02 13:49:23.0 +0100
+++ pam-u2f-1.1.0/debian/changelog  2021-06-05 15:04:24.0 +0200
@@ -1,3 +1,10 @@
+pam-u2f (1.1.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Handle converse() returning NULL (CVE-2021-31924) (Closes: #987545)
+
+ -- Salvatore Bonaccorso   Sat, 05 Jun 2021 15:04:24 +0200
+
 pam-u2f (1.1.0-1) unstable; urgency=low
 
   * New upstream version 1.1.0 (2020-09-17)
diff -Nru pam-u2f-1.1.0/debian/patches/Handle-converse-returning-NULL.patch 
pam-u2f-1.1.0/debian/patches/Handle-converse-returning-NULL.patch
--- pam-u2f-1.1.0/debian/patches/Handle-converse-returning-NULL.patch   
1970-01-01 01:00:00.0 +0100
+++ pam-u2f-1.1.0/debian/patches/Handle-converse-returning-NULL.patch   
2021-06-05 15:04:24.0 +0200
@@ -0,0 +1,37 @@
+From: pedro martelletto 
+Date: Wed, 19 May 2021 09:08:44 +0200
+Subject: Handle converse() returning NULL
+Origin: 
https://github.com/Yubico/pam-u2f/commit/6059b057dd9b6d0164fc16f9422c0d728f902bb5
+Bug: https://github.com/Yubico/pam-u2f/issues/175
+Bug-Debian: https://bugs.debian.org/987545
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-31924
+
+If a PIN is required and converse() returns NULL, abort the
+authentication flow instead of reverting to FIDO2 without PIN.
+Fixes #175.
+---
+ util.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/util.c b/util.c
+index 3ea1bd2be7e6..fb07dc70d545 100644
+--- a/util.c
 b/util.c
+@@ -1379,8 +1379,13 @@ int do_authentication(const cfg_t *cfg, const device_t 
*devices,
+   goto out;
+ }
+ 
+-if (pin_verification == FIDO_OPT_TRUE)
++if (pin_verification == FIDO_OPT_TRUE) {
+   pin = converse(pamh, PAM_PROMPT_ECHO_OFF, "Please enter the PIN: ");
++  if (pin == NULL) {
++D(cfg->debug_file, "converse() returned NULL");
++goto out;
++  }
++}
+ if (user_presence == FIDO_OPT_TRUE ||
+ user_verification == FIDO_OPT_TRUE) {
+   if (cfg->manual == 0 && cfg->cue && !cued) {
+-- 
+2.32.0.rc0
+
diff -Nru pam-u2f-1.1.0/debian/patches/series 
pam-u2f-1.1.0/debian/patches/series
--- pam-u2f-1.1.0/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ pam-u2f-1.1.0/debian/patches/series 2021-06-05 15:04:24.0 +0200
@@ -0,0 +1 @@
+Handle-converse-returning-NULL.patch

Bug#989572: gl2ps -- fails to build reproducibly

[Nilesh Patra]

Source: gl2ps
Version: 1.4.2+dfsg1-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: nil...@debian.org, reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

src:gl2ps fails to build reproducibly because its binary package libgl2ps-doc
vendors a pdf that saves in build date.

Since it does not add any real value to get _Build Date_ into the
documentation, I suppose the cheapest way to get it building
reproducibly is to simply not vendoring such a date in its
documentation.

I'll shortly push this to salsa, and I wish to upload post bullseye release.
I'm pasting the patch below for ref as well.

Nilesh

Description: Do not introduce build date in the documentation
Author: Nilesh Patra 
Last-Update: 2021-06-08
--- a/gl2ps.tex
+++ b/gl2ps.tex
@@ -62,6 +62,7 @@

 \title{GL2PS: an OpenGL to PostScript printing library}
 \author{Christophe Geuzaine}
+\date{}

 \maketitle

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

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

Bug#989559: ***SPAM*** Re: Bug#989559: mirror submission for mirror.hostafrica.co.za

[Rudi]

Hi Peter,

Sure thing. I have made the changes and busy running the sync script again.

On 2021/06/07 17:23, Peter Palfrader wrote:

Hi Rudi!

On Mon, 07 Jun 2021, Rudi wrote:


Submission-Type: new
Site: mirror.hostafrica.co.za
Type: leaf
Archive-architecture: amd64 hurd-i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Rudi 
Country: ZA South Africa
Location: Johannesburg

Can you please set the INFO_MAINTAINER field in your ftpsync.conf?



--

Bug#989571: linux-image-5.10.0-0.bpo.3-amd64: Incorrect large USB disk sizing leading to data corruption

[Anton Ivanov]

Package: src:linux
Version: 5.10.13-1~bpo10+1
Severity: critical
Justification: causes serious data loss

Dear Maintainer,

Large USB drives (example - Seagate 4TB Backup) which work perfectly fine with 
4.19 are identified as incorrect size. In the case of the 4TB sized USB it's 
identified as a 17GB and for some unfatomable reason mounted as loop. The 
result is severe data corruption making all 4TB of data on the drive 
unrecoverable.

Tested with the original USB bridge coming with the drive and after attaching 
the SATA drive inside to an alternative USB bridge. Same result in both cases.

-- Package-specific info:
** Version:
Linux version 5.10.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc-8 
(Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 
5.10.13-1~bpo10+1 (2021-02-11)

** Command line:
BOOT_IMAGE=diskless/amd64/vmlinuz-5.10.0-0.bpo.3-amd64 
initrd=diskless/amd64/initrd.img-5.10.0-0.bpo.3-amd64 root=/dev/nfs ip=dhcp 
nfsroot=192.168.3.3:/exports/boot/madding mitigations=off rw  --

** Tainted: S (4)
 * SMP kernel oops on an officially SMP incapable processor

** Kernel log:
[754632.929276] nfs: server 192.168.3.3 OK
[754635.600887] rpc_check_timeout: 443 callbacks suppressed
[754635.600889] nfs: server 192.168.3.3 not responding, still trying
[754635.612996] nfs: server 192.168.3.3 not responding, still trying
[754635.625266] nfs: server 192.168.3.3 not responding, still trying
[754635.625462] nfs: server 192.168.3.3 not responding, still trying
[754635.637374] nfs: server 192.168.3.3 not responding, still trying
[754635.649472] nfs: server 192.168.3.3 not responding, still trying
[754635.661739] nfs: server 192.168.3.3 not responding, still trying
[754635.661922] nfs: server 192.168.3.3 not responding, still trying
[754635.673850] nfs: server 192.168.3.3 not responding, still trying
[754635.686131] nfs: server 192.168.3.3 not responding, still trying
[791938.374623] lxc-bridge0: port 3(tap-opsft2-0) entered blocking state
[791938.374628] lxc-bridge0: port 3(tap-opsft2-0) entered forwarding state
[791938.374654] lxc-bridge0: port 4(tap-opsft3-0) entered blocking state
[791938.374655] lxc-bridge0: port 4(tap-opsft3-0) entered forwarding state
[791938.375075] lxc-bridge0: port 2(tap-opsft1-0) entered blocking state
[791938.375078] lxc-bridge0: port 2(tap-opsft1-0) entered forwarding state
[791938.388241] k8-bridge0: port 2(tap-opsft1-1) entered blocking state
[791938.388243] k8-bridge0: port 2(tap-opsft1-1) entered forwarding state
[791938.388402] k8-bridge0: port 4(tap-opsft3-1) entered blocking state
[791938.388405] k8-bridge0: port 4(tap-opsft3-1) entered forwarding state
[791938.388481] k8-bridge0: port 3(tap-opsft2-1) entered blocking state
[791938.388484] k8-bridge0: port 3(tap-opsft2-1) entered forwarding state
[801076.265404] usb 4-2.4: new SuperSpeed Gen 1 USB device number 5 using 
xhci_hcd
[801076.289933] usb 4-2.4: New USB device found, idVendor=174c, idProduct=55aa, 
bcdDevice= 1.00
[801076.289937] usb 4-2.4: New USB device strings: Mfr=2, Product=3, 
SerialNumber=1
[801076.289939] usb 4-2.4: Product: ASM105x
[801076.289940] usb 4-2.4: Manufacturer: ASMT
[801076.289942] usb 4-2.4: SerialNumber: 
[801076.291139] scsi host10: uas
[801076.291557] scsi 10:0:0:0: Direct-Access ASMT 2115 0
PQ: 0 ANSI: 6
[801076.292065] sd 10:0:0:0: Attached scsi generic sg0 type 0
[801076.292232] sd 10:0:0:0: [sda] Spinning up disk...
[801077.321342] ..ready
[801082.447597] sd 10:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 
TB/3.64 TiB)
[801082.447600] sd 10:0:0:0: [sda] 4096-byte physical blocks
[801082.447673] sd 10:0:0:0: [sda] Write Protect is off
[801082.447674] sd 10:0:0:0: [sda] Mode Sense: 43 00 00 00
[801082.447832] sd 10:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[801082.448032] sd 10:0:0:0: [sda] Optimal transfer size 33553920 bytes not a 
multiple of physical block size (4096 bytes)
[801082.494646] sd 10:0:0:0: [sda] Attached SCSI disk
[801150.687429] loop: module loaded
[801150.815997] EXT4-fs (loop0): mounted filesystem with ordered data mode. 
Opts: (null)
[803002.579925] blk_update_request: I/O error, dev loop0, sector 0 op 
0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
[803002.579960] blk_update_request: I/O error, dev loop0, sector 0 op 
0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
[803017.725341] EXT4-fs (loop0): mounted filesystem with ordered data mode. 
Opts: (null)
[803081.125594] blk_update_request: I/O error, dev loop0, sector 0 op 
0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
[803081.125635] blk_update_request: I/O error, dev loop0, sector 0 op 
0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
[803085.522063] EXT4-fs (loop0): mounted filesystem with ordered data mode. 
Opts: (null)
[803239.336895] blk_update_request: I/O error, dev loop0, sector 0 op 
0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
[803239.336950] blk_update_request: I/O 

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Gilles Filippini]

Hi,

On Wed, 2 Jun 2021 22:22:04 +0200 Sebastian Ramacher 
 wrote:

Hi Gilles, hi Andreas,

On 2021-06-01 14:15:52 +0200, Andreas Beckmann wrote:
> On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder  wrote:
> > One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
> > Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0,
> > and postgresql-11-postgis-2.5 depends on that.  libgdal28 depends on
> > gdal-data (>=3.2.1+dfsg-1).  To me it looks like there's no way to
> > keep postgresql-11-postgis-2.5 around if anything that depends on
> > libgdal28 (postgis, libopencv-imgcodecs4.5, ...) gets installed.
> 
> What would be needed to reintroduce postgresql-11-postgis-2.5 (i.e.

> src:postgis-2.5) (built against bullseye libraries) into bullseye? Probably
> libraries and -dev packages from postgresql-11, too.
> Here I assume that src:postgis-2.5 could be built against gdal 3.2.x and
> that can be used to perform the upgrade to postgis 3.x - is that true?

So here is a different view. At least the hdf5 part of this upgrade
issue could have been avoided if we transitationed to hdf5 1.12 (which
bumps all the SOVERSIONs to 200) for bullseye. Alas, we didn't and it's
too late for that.

So, what if we use the free versions between 103 and 200 to transition
to a Debian-specific version? Attached is a patch that does that. It's
not an optimal solution as we would have a release with a
Debian-specific SOVERSIONs. For good reason, we usually try to avoid
those. So, it would be good for someone more familiar with the users of
hdf5 to check if that would be an issue in this specific case.


I'm not in favor of that. I can't understand why we'd need to bump the 
HDF5 C library's SONAME for no reason but postgis wants an old runtime 
to properly run a migration. That's awkward.


If postgresql-11-postgis-2.5 needs to be re(instroduced, then it has to 
be built against current gdal and hdf5. Is that not feasible?


Best,

_g.

Bug#949336: integritysetup: HMAC(SHA256) key truncated to 106/114bytes in standalone mode

[Jonas Meurer]

Hey Guilhem :)

Guilhem Moulin wrote:

I'm not sure how what the best way to proceed for Bullseye.  Jonas,
what's your take about this?


First sorry for not responding earlier. I simply missed this mail in my 
backlog :-/



I tried to summarize the regression at
https://gitlab.com/cryptsetup/cryptsetup/-/issues/648#note_575895772 .
(Note that the truncation doesn't affect LUKS or dm-crypt, but *only*
standalone dm-integrity devices using HMAC integrity protection with
long key files, which is not widespread.)  It manifests in different
ways depending on cryptsetup and kernel versions:

   * Stretch has cryptsetup <2.0.0 which doesn't have integritysetup(1)
 and is therefore unaffected.
   * For cryptsetup ≥2.0.0 and ≤2.0.4 (some time between the Stretch and
 Buster releases), devices are formatted and opened using a
 *106-bytes* truncation of the key material.  Moreover formatting
 errors out when default sector size 512 bytes is used (so one needs
 to format with --sector-size [1024|2048|4096]).
   * For cryptsetup ≥2.0.5 (Buster and Bullseye), devices are formatted
 and opened using a *114-bytes* truncation of the key material.

So dm-integrity devices that were formatted using cryptsetup ≥2.0.0 and
≤2.0.4 using HMAC integrity protection with >106-bytes long keys don't
open normally (one needs to use `--integrity-key-size 106`) in Buster
and later.  We uploaded 2:2.0.5-1 to sid on October 29 2018; an entire
recycle cycle has since gone by and so far only n.f.b. has reported the
issue.  Given the many “if”s and the lack of bug reports I think it's
fair to assume than not maybe used long HMAC keys with integritysetup
between v2.0.0 and v2.0.4.

In addition: when using cryptsetup ≥2.3 on Linux 5.5 or later, it's not
possible to open a dm-integrity device using HMAC integrity protection
with keys of size exceeding *113 bytes*, regardless of whether it was
formatted using the same integritysetup binary or an older version.
cryptsetup 2:2.3.0-1 and linux 5.5.13-1 were respectively uploaded to
sid on March 04 and March 30 2020; Bullseye is affected and one year
later no one has reported the issue.


I would suggest to take the most pragmatic approach and don't care about 
this corner case. Given that, no stable release ever shipped with a 
faulty integritysetup and that I would expect every user who ran 
unstable/testing back when keys hat 106 bytes to still run 
unstable/testing, let's just keep it the way it is, no?



So I think we should postpone 2:2.3.6-1 to Bookworm.


Agreed.


Maybe we
should just wait until Bullseye is released, and upload the
aforementioned via s-p-u in case we have more reports ;-) 


Sounds like a good plan.

Thanks for taking care, Guilhem :)

Cheers
 jonas




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989103: pulseaudio crashes on startup

[Igor Kovalenko]

On Fri, 28 May 2021 17:40:28 +0200 =?iso-8859-2?Q?Micha=B3_Miros=B3aw?= <
mirq-debo...@rere.qmqm.pl> wrote:
> On Wed, May 26, 2021 at 10:19:31AM -0400, Felipe Sateler wrote:
> > Control: tags -1 unreproducible moreinfo
> >
> >
> > On Tue, May 25, 2021 at 10:27 PM Michał Mirosław <
mirq-li...@rere.qmqm.pl>
> > wrote:
> >
> > > Package: pulseaudio
> > > Version: 14.2-2
> > > Severity: grave
> > > Justification: renders package unusable
> > > X-Debbugs-Cc: mirq-debo...@rere.qmqm.pl
> > >
> > > After upgrade to bullseye, pulseaudio crashes on startup in
> > > pa_alsa_sink_new() -> find_mixer() due to mapping==NULL.
> > >
> >
> > You have this in your config:
> >
> > load-module module-alsa-sink device=hw:1,0 control=Wave
> >
> > Does it crash if you remove that line?
>
> Indeed this is the trigger.
>
> load-module module-alsa-sink device=hw:1,0
>
> works ok. Adding the mixer control name argument ("control=Wave" or
> "control=Wave,0") makes pulseaudio segfault on startup. Guessing from
> the documentation [1] version 14.0 had changes in code supporting this
> case.
>
> [1]
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-alsa-sink
>
> Best Regards
> Michał Mirosław
>
>

I confirm this is a regression in pulseaudio-14.0, fixed in pulseaudio
master now.

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/576

-- 
Kind regards,
Igor V. Kovalenko

Bug#988106: mutt: diff for NMU version 2.0.5-4.1

[Salvatore Bonaccorso]

Control: tags 988106 + patch
Control: tags 988106 + pending


Dear maintainer,

I've prepared an NMU for mutt (versioned as 2.0.5-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru mutt-2.0.5/debian/changelog mutt-2.0.5/debian/changelog
--- mutt-2.0.5/debian/changelog	2021-03-20 17:26:12.0 +0100
+++ mutt-2.0.5/debian/changelog	2021-06-06 21:11:36.0 +0200
@@ -1,3 +1,11 @@
+mutt (2.0.5-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix seqset iterator when it ends in a comma (CVE-2021-32055)
+(Closes: #988106)
+
+ -- Salvatore Bonaccorso   Sun, 06 Jun 2021 21:11:36 +0200
+
 mutt (2.0.5-4) unstable; urgency=medium
 
   * debian/patches:
diff -Nru mutt-2.0.5/debian/patches/series mutt-2.0.5/debian/patches/series
--- mutt-2.0.5/debian/patches/series	2021-03-20 17:24:06.0 +0100
+++ mutt-2.0.5/debian/patches/series	2021-06-06 21:11:36.0 +0200
@@ -13,3 +13,4 @@
 upstream/528233-readonly-open.patch
 upstream/980924-updated-german-translation.patch
 upstream/985152-body-color-slowness.patch
+upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch
diff -Nru mutt-2.0.5/debian/patches/upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch mutt-2.0.5/debian/patches/upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch
--- mutt-2.0.5/debian/patches/upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch	1970-01-01 01:00:00.0 +0100
+++ mutt-2.0.5/debian/patches/upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch	2021-06-06 21:11:36.0 +0200
@@ -0,0 +1,39 @@
+From: Kevin McCarthy 
+Date: Mon, 3 May 2021 13:11:30 -0700
+Subject: Fix seqset iterator when it ends in a comma.
+Origin: https://gitlab.com/muttmua/mutt/-/commit/7c4779ac24d2fb68a2a47b58c7904118f40965d5
+Bug-Debian: https://bugs.debian.org/988106
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-32055
+
+If the seqset ended with a comma, the substr_end marker would be just
+before the trailing nul.  In the next call, the loop to skip the
+marker would iterate right past the end of string too.
+
+The fix is simple: place the substr_end marker and skip past it
+immediately.
+---
+ imap/util.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/imap/util.c b/imap/util.c
+index c529fd8fba3c..488e8396d269 100644
+--- a/imap/util.c
 b/imap/util.c
+@@ -1036,13 +1036,11 @@ int mutt_seqset_iterator_next (SEQSET_ITERATOR *iter, unsigned int *next)
+ if (iter->substr_cur == iter->eostr)
+   return 1;
+ 
+-while (!*(iter->substr_cur))
+-  iter->substr_cur++;
+ iter->substr_end = strchr (iter->substr_cur, ',');
+ if (!iter->substr_end)
+   iter->substr_end = iter->eostr;
+ else
+-  *(iter->substr_end) = '\0';
++  *(iter->substr_end++) = '\0';
+ 
+ range_sep = strchr (iter->substr_cur, ':');
+ if (range_sep)
+-- 
+2.32.0.rc0
+

Bug#927184: Closing this bug (BTS maintenance for src:linux bugs)

[Yury Vidineev]

Thanks, Salvatore!

I think there are few commits with the fix:


https://git.kernel.org/linus/b69d540da7db84e836cea77fbd56a518aafa1f2f

https://git.kernel.org/linus/ceb159e30ad22efa0981d544e6166003515aa896

https://git.kernel.org/linus/a927d6af53eec08661628e3992d74736e848a743

https://git.kernel.org/linus/cc1bb845adc9b3a005cbb67fd18c69af1c3aec94

https://git.kernel.org/linus/24969facd704a5f0dd8e08da86bf32a9ce972bee

https://git.kernel.org/linus/b5fe22e2337d47cd68bb7d8e4103a628808c4d5e

https://git.kernel.org/linus/6be3b0db6db82cf056a72cc18042048edd27f8ee

https://git.kernel.org/linus/9cf545ebd591da673bb6b6c88150212ad83567a9

https://git.kernel.org/linus/e901cbc29316fb06423de5dfbc5afb78d4efda53

https://git.kernel.org/linus/64a09a7bfedee6ab97273d653dfac28e82635b61

https://git.kernel.org/linus/6ac098b2a9d3088781f1c2b7138cf38e817a3da7


I've got this list here:


https://kernelnewbies.org/Linux_5.0


"Improve xfrm policy lookup performance when a lot of (several hundred 
or even thousands) inexact policies exist on a system"





On 6/7/21 11:15 PM, Salvatore Bonaccorso wrote:

Hi,

On Sat, May 29, 2021 at 11:29:31PM +0500, Yury Vidineev wrote:

Hi,

It's fixed in the backports, but still exists in the current stable 4.19.

Thanks; I have added a fixed version for that. If you are able to
tackle the fxining commit(s) then we might look what we can do for
4.19.y.

Regards,
Salvatore

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

Is there any further information I can provide to help debug this (or should it 
get a -moreinfo)?

Note that of interest may be that the workaround of spawning in a screen session only works if lxc-start is passed the 
-F command which places it in the foreground (though sshd still gets the -D option running inside the container).


Matt

On 6/1/21 11:26, Matt Corallo wrote:

Is your sshd configured to use PAM?


Yes, "UsePAM yes" is in the sshd_config (I don't believe I've changed that, it 
appears to be the default?).


So, you log in via ssh, then start a (second) sshd process (inside a lxc 
container) via the above command?


That is correct, yes.


Would be great to have a set a commands which allows us reproduce the problem.


The above command paste should basically do it, eg install lxc, then `lxc-create --name fuzzer -t download` to create a 
(debian) container, then install sshd inside of it via apt, then run the `systemd-run --user -p "Delegate=yes" 
--unit=fuzzer -- lxc-start --name fuzzer -- /usr/sbin/sshd -D` command to spawn it, then log out of the ssh session 
which spawned it. There's likely some network configuration which needs to happen in between but I don't know off-hand 
how to set it up without public IPs for things.



Once you started the process, can you create a systemd-cgls output and attach 
it to this bug report.


Relevant bits post-spawn:

Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│   ├─user@1000.service
│   │ ├─app.slice
│   │ │ └─run-rc291ab200158464d9b477a247d01a095.service
│   │ │   ├─lxc.payload.fuzzer
│   │ │   │ └─12319 /usr/sbin/sshd -D
│   │ │   └─lxc.monitor.fuzzer
│   │ │ └─12313 [lxc monitor] /home/matt/.local/share/lxc fuzzer
│   │ └─init.scope
│   │   ├─1164 /lib/systemd/systemd --user
│   │   └─1165 (sd-pam)
│   ├─session-24.scope
│   │ ├─12207 sshd: matt [priv]
│   │ ├─12213 sshd: matt@pts/0
│   │ ├─12214 -bash
│   │ └─12374 systemd-cgls
│   └─session-1.scope
│ ├─1192 SCREEN
│ └─1193 /bin/bash



On 6/1/21 11:20, Michael Biebl wrote:

Am 01.06.2021 um 17:18 schrieb Michael Biebl:

Am 01.06.2021 um 16:24 schrieb Matt Corallo:

No, the shell is spawned from sshd (and almost nothing else running on the 
host).

On 6/1/21 04:22, Michael Biebl wrote:

Control: tags -1 + moreinfo

Am 01.06.2021 um 02:37 schrieb Matt Corallo:
After upgrading to bullseye on a test machine, spawning an lxc container with systemd-run[1] still kills the lxc 
container after the spawning shell is closed (and the user logs out). No only does the lxc container eventually 
get killed, but systemd refuses any further login for the user while it waits for the lxc container to die 
(something like maybe 30 seconds for a simple lxc container running an sshd service), making it appear the system 
has hung.


This doesn't appear to be resolved by the options suggested in the man page for systemd-run like `loginctl 
enable-linger` or `KillUserProcesses=no` (which appears to still be the default).


Matt

[1] eg systemd-run --user -p "Delegate=yes" --unit=fuzzer -- lxc-start --name 
fuzzer -- /usr/sbin/sshd -D


So, you log in via ssh, then start a (second) sshd process (inside a lxc 
container) via the above command?


Would be great to have a set a commands which allows us reproduce the problem.

Bug#989570: unblock: ffmpeg/7:4.3.2-0+deb11u2

[Sebastian Ramacher]

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

Please unblock package ffmpeg.

[ Reason ]
New CVEs (out-of-band reads caused by malicious files and a buffer
overflow) have been reported for ffmpeg.

[ Impact ]
Some CVEs remain unpatched. If this upload is not unblocked, they will
likely be fixed when pushing the next stable release of the 4.3.x series
via DSA to bullseye.

[ Tests ]
ffmpeg's and the reverse dependencies' autopkgtests have all succeeded.

[ Risks ]
Low as the patches can be reverted in case of regressions.

[ 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

[ Other info ]
ffmpeg is a key package and requires an unblock.

unblock ffmpeg/7:4.3.2-0+deb11u2

Cheers
-- 
Sebastian Ramacher
diff -Nru ffmpeg-4.3.2/debian/changelog ffmpeg-4.3.2/debian/changelog
--- ffmpeg-4.3.2/debian/changelog   2021-02-21 22:19:57.0 +0100
+++ ffmpeg-4.3.2/debian/changelog   2021-06-04 22:34:50.0 +0200
@@ -1,3 +1,13 @@
+ffmpeg (7:4.3.2-0+deb11u2) unstable; urgency=medium
+
+  * debian/patches: Apply upstream patches for CVEs (Closes: #989439)
+- avfilter/vf_vmafmotion: Fix out-of-bounds access (CVE-2020-22019, 
CVE-2020-22033)
+- avfilter/vf_yadif: Fix out-of-bounds access (CVE-2020-22021)
+- avformat/movenc: Fix out-of-bounds access (CVE-2020-22015)
+- avcodec/pngen: Fix buffer overflow (CVE-2020-21041)
+
+ -- Sebastian Ramacher   Fri, 04 Jun 2021 22:34:50 +0200
+
 ffmpeg (7:4.3.2-0+deb11u1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
ffmpeg-4.3.2/debian/patches/0004-avfilter-vf_vmafmotion-Check-dimensions.patch 
ffmpeg-4.3.2/debian/patches/0004-avfilter-vf_vmafmotion-Check-dimensions.patch
--- 
ffmpeg-4.3.2/debian/patches/0004-avfilter-vf_vmafmotion-Check-dimensions.patch  
1970-01-01 01:00:00.0 +0100
+++ 
ffmpeg-4.3.2/debian/patches/0004-avfilter-vf_vmafmotion-Check-dimensions.patch  
2021-06-04 22:34:04.0 +0200
@@ -0,0 +1,29 @@
+From: Michael Niedermayer 
+Date: Sat, 29 May 2021 09:58:31 +0200
+Subject: avfilter/vf_vmafmotion: Check dimensions
+
+Fixes: out of array access
+Fixes: Ticket8241
+Fixes: Ticket8246
+Fixes: CVE-2020-22019
+Fixes: CVE-2020-22033
+
+Signed-off-by: Michael Niedermayer 
+---
+ libavfilter/vf_vmafmotion.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/libavfilter/vf_vmafmotion.c b/libavfilter/vf_vmafmotion.c
+index 88d0b35..0730147 100644
+--- a/libavfilter/vf_vmafmotion.c
 b/libavfilter/vf_vmafmotion.c
+@@ -238,6 +238,9 @@ int ff_vmafmotion_init(VMAFMotionData *s,
+ int i;
+ const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
+ 
++if (w < 3 || h < 3)
++return AVERROR(EINVAL);
++
+ s->width = w;
+ s->height = h;
+ s->stride = FFALIGN(w * sizeof(uint16_t), 32);
diff -Nru 
ffmpeg-4.3.2/debian/patches/0005-avfilter-vf_yadif-Fix-handing-of-tiny-images.patch
 
ffmpeg-4.3.2/debian/patches/0005-avfilter-vf_yadif-Fix-handing-of-tiny-images.patch
--- 
ffmpeg-4.3.2/debian/patches/0005-avfilter-vf_yadif-Fix-handing-of-tiny-images.patch
 1970-01-01 01:00:00.0 +0100
+++ 
ffmpeg-4.3.2/debian/patches/0005-avfilter-vf_yadif-Fix-handing-of-tiny-images.patch
 2021-06-04 22:34:04.0 +0200
@@ -0,0 +1,78 @@
+From: Michael Niedermayer 
+Date: Sat, 29 May 2021 11:17:35 +0200
+Subject: avfilter/vf_yadif: Fix handing of tiny images
+
+Fixes: out of array access
+Fixes: Ticket8240
+Fixes: CVE-2020-22021
+
+Signed-off-by: Michael Niedermayer 
+---
+ libavfilter/vf_yadif.c | 32 ++--
+ 1 file changed, 18 insertions(+), 14 deletions(-)
+
+diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
+index 43dea67..06fd24e 100644
+--- a/libavfilter/vf_yadif.c
 b/libavfilter/vf_yadif.c
+@@ -123,20 +123,22 @@ static void filter_edges(void *dst1, void *prev1, void 
*cur1, void *next1,
+ uint8_t *next2 = parity ? cur  : next;
+ 
+ const int edge = MAX_ALIGN - 1;
++int offset = FFMAX(w - edge, 3);
+ 
+ /* Only edge pixels need to be processed here.  A constant value of false
+  * for is_not_edge should let the compiler ignore the whole branch. */
+-FILTER(0, 3, 0)
++FILTER(0, FFMIN(3, w), 0)
+ 
+-dst  = (uint8_t*)dst1  + w - edge;
+-prev = (uint8_t*)prev1 + w - edge;
+-cur  = (uint8_t*)cur1  + w - edge;
+-next = (uint8_t*)next1 + w - edge;
++dst  = (uint8_t*)dst1  + offset;
++prev = (uint8_t*)prev1 + offset;
++cur  = (uint8_t*)cur1  + offset;
++next = (uint8_t*)next1 + offset;
+ prev2 = (uint8_t*)(parity ? prev : cur);
+ next2 = (uint8_t*)(parity ? cur  : next);
+ 
+-FILTER(w - edge, w - 3, 1)
+-FILTER(w - 3, w, 0)
++FILTER(offset, w - 3, 1)
++offset = FFMAX(offset, w - 3);
++FILTER(offset, w, 0)
+ }
+ 
+ 
+@@ -170,21 +172,23 @@ static void filter_edges_16bit(void *dst1, void 

Bug#989472: mirror submission for mirror.estone.ca

[Mike Egglestone]

Quoting Peter Palfrader :


On Fri, 04 Jun 2021, Mike Egglestone wrote:


Submission-Type: new
Site: mirror.estone.ca
Type: leaf
Archive-architecture: amd64
Archive-http: /debian/
Maintainer: Mike Egglestone 
Country: CA Canada
Location: Prince George BC


Added to our list, thanks.

Please note that we recommend mirrors not sync directly from service aliases
such as ftp..debian.org (only http is guaranteed to be available at
ftp..d.o sites).  Maybe change your config to sync from the site  
currently

backing the ftp..debian.org service you sync from?



Thanks Peter!
I was syncing from ftp2.ca.debian.org, but will switch it to  
debian.mirror.rafal.ca instead.


Cheers,
Mike

Bug#989569: unblock: audacity/2.4.2~dfsg0-5

[Dennis Braun]

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

Please unblock package audacity

audacity (2.4.2~dfsg0-5) unstable; urgency=medium

  * Workaround patch for playback cursor under wayland
Audacity has no full wayland support yet, so we use X11 to start
(Closes: #950150, #962389, #988632, LP: #1877833)
The patch can probably be removed when wxwidgets 3.1.3 is in debian archive
  * Add lintian-overrides to override false positive lintian errors

 -- Dennis Braun  Wed, 26 May 2021 22:26:01 +0200

unblock audacity/2.4.2~dfsg0-5

Bug#989568: Please allow kgames and xmille to be co-installable

[Marvin Renich]

Package: kgames
Version: 1.0-2.1
Severity: normal

kgames Breaks, Replaces, and Provides xmille, but the user interface is
different enough between the two that it is reasonable to want the
xmille package and the other games in kgames at the same time.

I see three obvious solutions, listed in order of my own personal
preference:

1.  Rename the binary in kgames to kmille, and use the alternatives
system to provide links from xmille to either package's binary.
This requires cooperation and coordination with the xmille
maintainer, but provides the best end user experience.

2.  Rename the binary in kgames and don't bother with alternatives.
This is a very close second option.

3.  Move the kgames version of xmille to a separate binary package,
which Conflicts, Replaces, Provides xmille.  I'm not too keen on
this solution, but it allows you to keep the original executable
name without interaction with the xmille maintainer.

Debian Policy section 10.1 says that two packages must not install
programs with different functionality but with the same filenames.  It
goes on to say that the same functionality but different implementations
is handled by "alternatives" or "Conflicts".

I think this best fits the second criterion, but because there is
sufficient reason to want both packages installed at the same time, the
"alternatives" solution seems substantially better than "Conflicts" to
me.

For future reference, Conflicts should be used rather than Breaks when
two packages provide the same file and will continue to do so.  See
Debian Policy section 7.4.  Policy does encourage using Breaks over
Conflicts when possible, but this is a case where Conflicts is
necessary.

Thanks for packaging these games.

...Marvin

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (500, 
'stable-updates'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable')
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_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 /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages kgames depends on:
ii  libc6 2.31-12
ii  libx11-6  2:1.7.1-1
ii  libxaw7   2:1.0.13-1.1
ii  libxmu6   2:1.1.2-2+b3
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.2.0-1

kgames recommends no packages.

kgames suggests no packages.

-- no debconf information

Bug#989567: debconf.postinst is completely unnecessary unless upgrading from pre-etch

[Helmut Grohne]

Package: debconf
Version: 1.5.76
Severity: minor
Tags: patch

$reasons got me looking into debconf.postinst. I read it and figured
that it would only do non-trivial things when upgrading from a release
that predates etch (i.e. old-old-old-old-old-old-stable). Nothing in
there is useful for current upgrades. Can we drop it entirely?

Helmut
diff --minimal -Nru debconf-1.5.76/debian/changelog 
debconf-1.5.76+nmu1/debian/changelog
--- debconf-1.5.76/debian/changelog 2021-03-20 14:14:50.0 +0100
+++ debconf-1.5.76+nmu1/debian/changelog2021-06-07 20:02:34.0 
+0200
@@ -1,3 +1,11 @@
+debconf (1.5.76+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Delete debconf postinst script as it only handles upgrades from pre-etch.
+(Closes: #-1)
+
+ -- Helmut Grohne   Mon, 07 Jun 2021 20:02:34 +0200
+
 debconf (1.5.76) unstable; urgency=medium
 
   [ Colin Watson ]
diff --minimal -Nru debconf-1.5.76/debian/postinst 
debconf-1.5.76+nmu1/debian/postinst
--- debconf-1.5.76/debian/postinst  2021-03-20 14:14:50.0 +0100
+++ debconf-1.5.76+nmu1/debian/postinst 1970-01-01 01:00:00.0 +0100
@@ -1,72 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ -z "$DEBIAN_HAS_FRONTEND" ] && [ "$1" = configure ] && [ -n "$2" ] && \
-   dpkg --compare-versions "$2" lt 1.1.0; then
-   # Transition from old database format before debconf starts up.
-   if dpkg --compare-versions "$2" lt 0.9.00; then
-   if [ -e /var/lib/debconf/config.db -o -e 
/var/lib/debconf/templates.db ]; then
-   /usr/share/debconf/transition_db.pl
-   fi
-   # This package used to add itself to apt.conf. That could 
result in
-   # a zero-byte file, since it no longer does. Detect that and 
remove
-   # the file.
-   if [ ! -s /etc/apt/apt.conf ]; then
-   rm -f /etc/apt/apt.conf
-   fi
-   fi
-   
-   # Fix up broken db's before debconf starts up.
-   if dpkg --compare-versions "$2" lt 1.0.25; then
-   /usr/share/debconf/fix_db.pl
-   fi
-   
-   # configdb splits into passworded and non-passworded parts, before 
debconf
-   # starts up. Do so only if the debconf.conf has the new databases in it.
-   if dpkg --compare-versions "$2" lt 1.1.0 &&
-  perl -e 'use Debconf::Db; Debconf::Db->load; for (@ARGV) { exit 1 
unless
-   Debconf::DbDriver->driver($_) }' config passwords; then
-   # copies in only the passwords, of course
-   debconf-copydb config passwords
-   # makes a new config with only non-passwords in it
-   debconf-copydb config newconfig \
-   -c Name:newconfig \
-   -c Driver:File \
-   -c Reject-Type:password \
-   -c Filename:/var/cache/debconf/newconfig.dat \
-   -c Mode:644
-   mv -f /var/cache/debconf/newconfig.dat 
/var/cache/debconf/config.dat
-   fi
-fi
-
-. /usr/share/debconf/confmodule
-
-if [ "$1" = configure ] && [ -n "$2" ] && dpkg --compare-versions "$2" lt 
1.3.11; then
-   # Remove old debconf database, and associated cruft in /var/lib/debconf.
-   # In fact, the whole directory can go! Earlier versions of debconf in 
the
-   # 0.9.x series kept it just in case, so make sure to delete it on 
upgrade
-   # from any of those versions, or even older versions.
-   if dpkg --compare-versions "$2" lt 0.9.50; then
-   rm -rf /var/lib/debconf
-   fi
-
-   # Kill db cruft.
-   if dpkg --compare-versions "$2" lt 0.9.73; then
-   # It may not be present, if upgrading from long ago.
-   db_unregister foo/bar || true
-   db_unregister debconf/switch-to-slang || true
-   fi
-   if dpkg --compare-versions "$2" lt 1.3.11; then
-   db_unregister debconf/showold || true
-   fi
-
-   # The Text frontend became the Readline frontend.
-   if dpkg --compare-versions "$2" lt 1.0.10; then
-   db_get debconf/frontend || true
-   if [ "$RET" = Text ]; then
-   db_set debconf/frontend Readline || true
-   fi
-   fi
-fi
-
-#DEBHELPER#

Bug#927184: Closing this bug (BTS maintenance for src:linux bugs)

[Salvatore Bonaccorso]

Hi,

On Sat, May 29, 2021 at 11:29:31PM +0500, Yury Vidineev wrote:
> Hi,
> 
> It's fixed in the backports, but still exists in the current stable 4.19.

Thanks; I have added a fixed version for that. If you are able to
tackle the fxining commit(s) then we might look what we can do for
4.19.y.

Regards,
Salvatore

Bug#989355: transition: tinyxml2

[Chow Loong Jin]

On Sat, Jun 05, 2021 at 05:39:04PM +0800, Chow Loong Jin wrote:
> On Wed, Jun 02, 2021 at 12:27:06PM +0200, Sebastian Ramacher wrote:
> > On 2021-06-02 02:45:56, Chow Loong Jin wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > There's been an ABI break without an upstream soname bump in
> > > libtinyxml2-8, between upstream versions 8.0.0 and 8.1.0, see [1] and
> > > [2]. To remedy this, I have uploaded version 8.1.0+dfsg-2 to
> > > experimental with the library package renamed from libtinyxml2-8 to
> > > libtinyxml2-8a. It is waiting in the NEW queue now.
> > 
> > Please revert tinyxml2 in unstable to the state of 8.0.0+dfsg-2 to
> > avoid uploads of reverse dependencies that are targetted for bullseye to
> > be built against the broken version.
> 
> Done -- uploaded 8.0.0+dfsg-2 as 8.1.0+really8.0.0+dfsg-1 to unstable
> 
> Also reuploaded 8.1.0+dfsg-2 as 8.1.0+really8.1.0+dfsg-1 to experimental
> to keep the relative order of the versions.

The upstream developer has uploaded a 9.0.0 release with the desired
soname bump to libtinyxml2.so.9, which I have packaged and uploaded into
experimental as 9.0.0+dfsg-1.

The updated Ben file should now be:

title = "tinyxml2";
is_affected = .depends ~ "libtinyxml2-8" | .depends ~ "libtinyxml2-8a" | 
.depends ~ "libtinyxml2-9";
is_good = .depends ~ "libtinyxml2-9";
is_bad = .depends ~ "libtinyxml2-8" | .depends ~ "libtinyxml2-8a";

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#989554: Add argyll dependency

[Age Bosma]

Package: gnome-control-center
Version: 3.38.5-1

This issue applies to many past versions of gnome-control-center as well, but I 
just ran into it again.

The colour calibration functionality gnome-control-center will happily start 
the lengthy process of colour testing, only the fail at the end with the error:

"Tools required for calibration are not installed"

This without specifying which tools exactly.

Installing the argyll package solves the issue.

It would therefore be good to have this package included as a dependency.

Bug#989566: [wontfix] New 0.2.1 upstream release

[Didier 'OdyX' Raboud]

Source: libopenaptx
Version: 0.2.1
Severity: important
Tags: upstream wontfix
X-Debbugs-Cc: libopena...@packages.debian.org

Upstream released a new 0.2.1 version, with a license version update:

https://github.com/pali/libopenaptx/releases/tag/0.2.1

The changelog has:
https://github.com/pali/libopenaptx/commit/811bc18586d634042618d633727ac0281d4170b8
> License was upgraded to GPLv3+ to to make it compatible with other projects
> under Apache License 2.0 and also to explicitly make it incompatible with
> existing Freedesktop projects due to misusing of their own CoC to support
> license violation of other projects.

For some context on that issue; see:
* https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2235
* https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/664
* https://bugs.gentoo.org/785634

Most of the difference between 0.2.0 and 0.2.1 is this license change; see 
https://github.com/pali/libopenaptx/compare/0.2.0...0.2.1

In the rest of the changes, there's also a patch I proposed, which is already
in the 0.2.0-* Debian packaging.

So. Notwithstanding the license change (which, at first glance, don't seem
acceptable for Debian), the rest of the updates don't justify upgrading this
package to 0.2.1, so I'm (as maintainer) tagging this as +wontfix.

Bug#736803: dh_dkms could automatically replace #MODULE_VERSION#

[Thorsten Glaser]

Package: dkms
Version: 2.6.1-4
Followup-For: Bug #736803

I just ran into that as well because the manpage is ambiguously
worded in a way one could think that that’s already done. Also,
having an option that optionally takes an argument is likely
going to fail.

@Andreas: packages with a literal #MODULE_VERSION# are indeed
already broken: first because of the directory structure…

[…]
drwxr-xr-x root/root 0 2021-06-07 18:52 
./usr/src/sch-jens-#MODULE_VERSION#/ 
-rw-r--r-- root/root   344 2021-06-07 18:44 
./usr/src/sch-jens-#MODULE_VERSION#/dkms.conf
drwxr-xr-x root/root 0 2021-06-07 18:52 
./usr/src/sch-jens-0~20210607.0/ 
-rw-r--r-- root/root20 2021-06-07 15:59 
./usr/src/sch-jens-0~20210607.0/Kbuild   
[…]

… and second because they won’t uninstall: the prerm has…

# Automatically added by dh_dkms/UNDECLARED 
 
DKMS_NAME=sch-jens  
 
DKMS_VERSION=#MODULE_VERSION#   
 

 
case "$1" in
 
remove|upgrade|deconfigure) 
 
  if [  "$(dkms status -m $DKMS_NAME -v $DKMS_VERSION)" ]; then 
 
 dkms remove -m $DKMS_NAME -v $DKMS_VERSION --all   
 
  fi
 

… which will end up calling 'dkms status -m name -v', which works,
and 'dkms remove -m name -v --all', which will fail badly.

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages dkms depends on:
ii  build-essential  12.6
ii  coreutils8.30-3
ii  dpkg-dev 1.19.7
ii  gcc  4:8.3.0-1
ii  kmod 26-1
ii  make 4.2.1-1.2
ii  patch2.7.6-3+deb10u1

Versions of packages dkms recommends:
ii  fakeroot 1.23-1
ii  linux-headers-amd64  4.19+105+deb10u11
ii  lsb-release  10.2019051400
ii  sudo 1.8.27-1+deb10u3

Versions of packages dkms suggests:
ii  menu2.1.47+b1
pn  python3-apport  

-- no debconf information

Bug#985391: gnome-autoar: CVE-2021-28650

[Moritz Muehlenhoff]

On Wed, Mar 17, 2021 at 09:36:44AM +0100, Salvatore Bonaccorso wrote:
> Source: gnome-autoar
> Version: 0.2.4-3
> Severity: important
> Tags: security upstream
> Forwarded: https://gitlab.gnome.org/GNOME/gnome-autoar/-/issues/12
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> ,seb...@ubuntu.com
> Control: fixed -1 0.3.1-1
> 
> Hi,
> 
> I'm X-Debbugs-CC'ing as well explicitly Sebastien.
> 
> The following vulnerability was published for gnome-autoar.
> 
> CVE-2021-28650[0]:
> | autoar-extractor.c in GNOME gnome-autoar before 0.3.1, as used by
> | GNOME Shell, Nautilus, and other software, allows Directory Traversal
> | during extraction because it lacks a check of whether a file's parent
> | is a symlink in certain complex situations. NOTE: this issue exists
> | because of an incomplete fix for CVE-2020-36241.
> 
> It appears that CVE-2020-36241 was not fixed completely, and resulted
> in CVE-2021-28650 with upstream commit [1]. The corresponding upstream
> issue is not (yet?) public, but maybe you have access to it.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2021-28650
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28650
> [1] 
> https://gitlab.gnome.org/GNOME/gnome-autoar/-/commit/8109c368c6cfdb593faaf698c2bf5da32bb1ace4

There's two additional fixes which fix regressions from the security fix:
https://gitlab.gnome.org/GNOME/gnome-autoar/-/commit/135053d5d3a0320891cf2e2ad4684b648bb46fc8
https://gitlab.gnome.org/GNOME/gnome-autoar/-/commit/b9590ab77b70e74e9deffd2af6c32908dc3c5aaf

Cheers,
Moritz

Bug#989565: mergerfs: Duplicated file and directory names in Midnight Commander

[Dmitry Semyonov]

Package: mergerfs
Version: 2.31.0-1
Severity: important
Tags: patch upstream
X-Debbugs-Cc: linu...@gmail.com

Dear Maintainer,

The https://github.com/trapexit/mergerfs/pull/878 patch released as a
part of mergerfs-2.32.3 upstream could be applied to the 2.31.0-1
version currently packaged in Debian bullseye to resolve the $subj
issue.

See https://github.com/trapexit/mergerfs/issues/877 and
https://midnight-commander.org/ticket/4226 for additional background
information.

Alternatively, please consider packaging the latest upstream release. It
contains several other fixes not related to this bug.

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

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

Versions of packages mergerfs depends on:
ii  fuse2.9.9-5
ii  libc6   2.31-12
ii  libfuse22.9.9-5
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6

mergerfs recommends no packages.

mergerfs suggests no packages.

-- no debconf information
Description: reset dentry buffer when rewind'ed

Merge https://github.com/trapexit/mergerfs/pull/878 from mergerfs-2.32.3
that fixes duplicate file and directory names in Midnight Commander.

Origin: upstream, https://github.com/trapexit/mergerfs/pull/878.
Bug: https://github.com/trapexit/mergerfs/issues/877.
Last-Update: 2021-06-07

--- mergerfs-2.31.0.orig/src/fuse_readdir_linux.cpp
+++ mergerfs-2.31.0/src/fuse_readdir_linux.cpp
@@ -66,6 +66,8 @@ namespace l
 uint64_t namelen;
 struct linux_dirent64 *d;
 
+fuse_dirents_reset(buf_);
+
 buf = (char*)g_DENTS_BUF_POOL.alloc();
 if(buf == NULL)
   return -ENOMEM;
--- mergerfs-2.31.0.orig/src/fuse_readdir_plus_linux.cpp
+++ mergerfs-2.31.0/src/fuse_readdir_plus_linux.cpp
@@ -70,6 +70,8 @@ namespace l
 fuse_entry_t entry;
 struct linux_dirent64 *d;
 
+fuse_dirents_reset(buf_);
+
 buf = (char*)g_DENTS_BUF_POOL.alloc();
 
 entry.nodeid   = 0;
--- mergerfs-2.31.0.orig/src/fuse_readdir_plus_posix.cpp
+++ mergerfs-2.31.0/src/fuse_readdir_plus_posix.cpp
@@ -72,6 +72,8 @@ namespace l
 uint64_t namelen;
 fuse_entry_t entry;
 
+fuse_dirents_reset(buf_);
+
 entry.nodeid   = 0;
 entry.generation   = 0;
 entry.entry_valid  = entry_timeout_;
--- mergerfs-2.31.0.orig/src/fuse_readdir_posix.cpp
+++ mergerfs-2.31.0/src/fuse_readdir_posix.cpp
@@ -67,6 +67,8 @@ namespace l
 string fullpath;
 uint64_t namelen;
 
+fuse_dirents_reset(buf_);
+
 for(size_t i = 0, ei = branches_.size(); i != ei; i++)
   {
 int rv;

Bug#956245: dkms: Error! You must be root to use this command STILL broken in buster?

[Thorsten Glaser]

Hi,

this bug is still open in buster…

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#901636: mandoc: "mandoc -mdoc -T man" causes memory dump

[наб]

found 901636 1.14.5-1
thanks

Hi!

I think I hit this as well, but I've a minimal example to show for it:
-- >8 --
.Dd June  7, 2021
.Dt SLEEP 1
.Os
.EQ
Z = X + Y
.EN
-- >8 --

Running "mandoc -Tman" on this file produces some output until it
explodes on the .EQ directive (I think? an equivalent thing happens on
the unminimised version (attached)):
-- >8 --
.\" Automatically generated from an mdoc input file.  Do not edit.
.TH "SLEEP" "1" "June 7, 2021" "Debian" "General Commands Manual"
.nh
mandoc: mdoc_man.c:686: print_node: Assertion `n->tok >= MDOC_Dd && n->tok < 
MDOC_MAX' failed.
Aborted
-- >8 --

Happens on buster (1.14.4-1) and sid (1.14.5-1).

GDB has this to say about it:
-- >8 --
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0xf7e0c515 in __GI_abort () at abort.c:79
#2  0xf7e0c3fe in __assert_fail_base (fmt=, assertion=, file=, line=300,
function=) at assert.c:92
#3  0xf7e1b1ff in __GI___assert_fail (assertion=assertion@entry=0x565a4c88 "tok 
>= MDOC_Dd && tok <= MDOC_MAX",
file=file@entry=0x565a4bba "mdoc_man.c", line=line@entry=300,
function=function@entry=0x565a4b88 <__PRETTY_FUNCTION__.2> "mdoc_man_act") 
at assert.c:101
#4  0x5657f29f in mdoc_man_act (tok=) at mdoc_man.c:300
#5  0x5657f4e8 in mdoc_man_act (tok=) at mdoc_man.c:689
#6  print_node (meta=meta@entry=0x565c6600, n=n@entry=0x565cc610) at 
mdoc_man.c:688
#7  0x56580a4a in man_mdoc (arg=, mdoc=mdoc@entry=0x565c6600) at 
mdoc_man.c:634
#8  0x5657d8cc in parse (curp=curp@entry=0xd450, fd=fd@entry=4, 
file=file@entry=0xd786 "../sleep.1-min")
at main.c:859
#9  0x565613bf in main (argc=, argv=) at 
main.c:540

(gdb) up
#6  print_node (meta=meta@entry=0x565c6600, n=n@entry=0x565cc610) at 
mdoc_man.c:688
(gdb) p n
$2 = (struct roff_node *) 0x565cc610
(gdb) p *n
$3 = {parent = 0x565c6670, child = 0x0, last = 0x0, next = 0x0, prev = 
0x565cc590, head = 0x0, body = 0x0, tail = 0x0,
  args = 0x0, norm = 0x0, string = 0x0, span = 0x0, eqn = 0x565cc670, line = 4, 
pos = 1, flags = 9, prev_font = 0,
  aux = 0, tok = TOKEN_NONE, type = ROFFT_EQN, sec = SEC_NONE, end = 
ENDBODY_NOT}
-- >8 --

n->tok is what's being passed to mdoc_man_act() which produces the
assertion, and TOKEN_NONE is just below MDOC_Md, according to roff.h:
-- >8 --
316 ROFF_cblock,
317 ROFF_RENAMED,
318 ROFF_USERDEF,
319 TOKEN_NONE,
320 MDOC_Dd,
321 MDOC_Dt,
322 MDOC_Os,
-- >8 --

The entire document(?) seems to be
-- >8 --
(gdb) p mdoc->first
$14 = (struct roff_node *) 0x565c6670
(gdb) p *mdoc->first
$15 = {parent = 0x0, child = 0x565cc260, last = 0x565cc610, next = 0x0, prev = 
0x0, head = 0x0, body = 0x0, tail = 0x0,
  args = 0x0, norm = 0x0, string = 0x0, span = 0x0, eqn = 0x0, line = 0, pos = 
0, flags = 3, prev_font = 0, aux = 0,
  tok = TOKEN_NONE, type = ROFFT_ROOT, sec = SEC_NONE, end = ENDBODY_NOT}
(gdb) p *mdoc->first->child
$16 = {parent = 0x565c6670, child = 0x565cc2d0, last = 0x565cc3b0, next = 
0x565cc430, prev = 0x0, head = 0x0,
  body = 0x0, tail = 0x0, args = 0x0, norm = 0x0, string = 0x0, span = 0x0, eqn 
= 0x0, line = 1, pos = 1, flags = 1035,
  prev_font = 0, aux = 0, tok = MDOC_Dd, type = ROFFT_ELEM, sec = SEC_NONE, end 
= ENDBODY_NOT}
(gdb) p *mdoc->first->child->next
$17 = {parent = 0x565c6670, child = 0x565cc4a0, last = 0x565cc510, next = 
0x565cc590, prev = 0x565cc260, head = 0x0,
  body = 0x0, tail = 0x0, args = 0x0, norm = 0x0, string = 0x0, span = 0x0, eqn 
= 0x0, line = 2, pos = 1, flags = 1035,
  prev_font = 0, aux = 0, tok = MDOC_Dt, type = ROFFT_ELEM, sec = SEC_NONE, end 
= ENDBODY_NOT}
(gdb) p *mdoc->first->child->next->next
$18 = {parent = 0x565c6670, child = 0x0, last = 0x0, next = 0x565cc610, prev = 
0x565cc430, head = 0x0, body = 0x0,
  tail = 0x0, args = 0x0, norm = 0x0, string = 0x0, span = 0x0, eqn = 0x0, line 
= 3, pos = 1, flags = 1035,
  prev_font = 0, aux = 0, tok = MDOC_Os, type = ROFFT_ELEM, sec = SEC_NONE, end 
= ENDBODY_NOT}
(gdb) p *mdoc->first->child->next->next->next
$19 = {parent = 0x565c6670, child = 0x0, last = 0x0, next = 0x0, prev = 
0x565cc590, head = 0x0, body = 0x0, tail = 0x0,
  args = 0x0, norm = 0x0, string = 0x0, span = 0x0, eqn = 0x565cc670, line = 4, 
pos = 1, flags = 9, prev_font = 0,
  aux = 0, tok = TOKEN_NONE, type = ROFFT_EQN, sec = SEC_NONE, end = 
ENDBODY_NOT}
(gdb) p *mdoc->first->child->next->next->next->next
Cannot access memory at address 0x0
-- >8 --

Which is likely to be produced by roff.c#roff_EQ(), which seems to be
one of the very few spots where a TOKEN_NONE is actively produced,
and the only one where ROFFT_EQN is:
-- >8 --
   3297 static int
   3298 roff_EQ(ROFF_ARGS)
   3299 {
   3300 struct roff_node*n;
   3301
   3302 if (r->man->meta.macroset == MACROSET_MAN)
   3303 man_breakscope(r->man, ROFF_EQ);
   3304 n = roff_node_alloc(r->man, ln, ppos, ROFFT_EQN, TOKEN_NONE);
   3305 if (ln > r->man->last->line)
   3306 n->flags |= NODE_LINE;

Bug#979599: trscripts: Incorrect build xfonts-bolkhov-misc

[Jochen Sprickerhof]

Hi,

I just realised that I totally forgot to send the nmudiff for this one, 
sorry. I've attached it now, hope that is ok.


Cheers Jochen
diff -Nru trscripts-1.18+nmu1/debian/changelog trscripts-1.18+nmu2/debian/changelog
--- trscripts-1.18+nmu1/debian/changelog	2021-01-07 15:01:30.0 +0100
+++ trscripts-1.18+nmu2/debian/changelog	2021-06-05 20:08:15.0 +0200
@@ -1,3 +1,12 @@
+trscripts (1.18+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make trbdf awk script portable (Closes: #979599).
+POSIX awk does not specify the order in a for(i in array) loop, so
+switching to a for loop with an increment.
+
+ -- Jochen Sprickerhof   Sat, 05 Jun 2021 20:08:15 +0200
+
 trscripts (1.18+nmu1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru trscripts-1.18+nmu1/gen_trbdf trscripts-1.18+nmu2/gen_trbdf
--- trscripts-1.18+nmu1/gen_trbdf	2009-05-02 12:43:11.0 +0200
+++ trscripts-1.18+nmu2/gen_trbdf	2021-06-05 20:08:15.0 +0200
@@ -312,15 +312,15 @@
 EOF
 
 if [ "$usefb" = yes ]; then
-printf "	split(tu[i] \" \" alt1[tu[i]] \" \" alt2[tu[i]], a);\n"
+printf "	an = split(tu[i] \" \" alt1[tu[i]] \" \" alt2[tu[i]], a);\n"
 printf "	split(0 \" \" weight1[tu[i]] \" \" weight2[tu[i]], w);\n"
 else
-printf "	split(tu[i] \" \" alt1[tu[i]], a);\n"
+printf "	an = split(tu[i] \" \" alt1[tu[i]], a);\n"
 printf "	split(0 \" \" weight1[tu[i]], w);\n"
 fi
 
 cat <<"EOF"
-	for(j in a)
+	for(j=1; j <= an; ++j)
 	  {
 	if(ut[a[j]]!="")
 	  {
@@ -339,7 +339,7 @@
 	  }
 	  }
 	k=0;
-	for(j in a)
+	for(j=1; j <= an; ++j)
 	  {
 	if(ut[a[j]]!="")
 	  {
@@ -356,7 +356,7 @@
 	printf "\";\n";
 	  }
 	k=0;
-	for(j in a)
+	for(j=1; j <= an; ++j)
 	  {
 	if(ut[a[j]]!="")
 	  {


signature.asc
Description: PGP signature

Bug#985346: RFS: nspark/1.7.8B2+git+20190713-3 [ITP] -- Decompressor for SparkFS and ArcFS archive files

[Dave Lambley]

Control: tags - moreinfo

Hi Tobias,

Thank you for taking the time to look at this. I have hopefully addressed all 
your comments. I have uploaded 
https://mentors.debian.net/debian/pool/non-free/n/nspark/nspark_1.7.8B2+git20210317.cb30779-1.dsc

Cheers,
Dave

Bug#989257: unblock: kodi/2:19.1+dfsg2-1

[Mattia Rizzolo]

Control: tag -1 -moreinfo

On Mon, Jun 07, 2021 at 09:50:07AM +0200, Sebastian Ramacher wrote:
> please go ahead. Remove the moreinfo tag once the new version is
> available in unstable.

Uploaded.

-- 
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#989564: isync: CVE-2021-3578

[Salvatore Bonaccorso]

Source: isync
Version: 1.3.0-2.1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.3.0-2

Hi,

The following vulnerability was published for isync.

CVE-2021-3578[0]:
| possible remote code execution in isync/mbsync

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3578
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3578
[1] https://www.openwall.com/lists/oss-security/2021/06/07/1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#989563: Add support for new Unicode 8.0 skin tone emojis

[積丹尼 Dan Jacobson]

Package: fonts-noto-color-emoji
Version: 0~20200916-1

Please see
https://bugs.chromium.org/p/chromium/issues/detail?id=1214832#c4

Bug#989562: apache2: CVE-2021-31618: NULL pointer dereference on specially crafted HTTP/2 request

[Salvatore Bonaccorso]

Source: apache2
Version: 2.4.47-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for apache2.

CVE-2021-31618[0]:
| httpd: NULL pointer dereference on specially crafted HTTP/2 request

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-31618
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31618
[1] 
https://github.com/apache/httpd/commit/a4fba223668c554e06bc78d6e3a88f33d4238ae4
[2] https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2021-31618

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#989561: python-websockets: CVE-2021-33880

[Salvatore Bonaccorso]

Source: python-websockets
Version: 8.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-websockets.

CVE-2021-33880[0]:
| The aaugustin websockets library before 9.1 for Python has an
| Observable Timing Discrepancy on servers when HTTP Basic
| Authentication is enabled with
| basic_auth_protocol_factory(credentials=...). An attacker may be able
| to guess a password via a timing attack.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-33880
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33880
[1] 
https://github.com/aaugustin/websockets/commit/547a26b685d08cac0aa64e5e65f7867ac0ea9bc0

Regards,
Salvatore

Bug#989559: mirror submission for mirror.hostafrica.co.za

[Peter Palfrader]

Hi Rudi!

On Mon, 07 Jun 2021, Rudi wrote:

> Submission-Type: new
> Site: mirror.hostafrica.co.za
> Type: leaf
> Archive-architecture: amd64 hurd-i386
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Rudi 
> Country: ZA South Africa
> Location: Johannesburg

Can you please set the INFO_MAINTAINER field in your ftpsync.conf?


-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11

[Samuel Henrique]

Control: severity -1 normal

Hello Jan,

Thanks for the detailed explanation and for pushing your integration
tests. I have pushed them[0] to the main repo (with the same changes
we discussed in the rsakeyfind MR) making use of the "-t 50"
parameter. So the package can have integ tests even before we get to
solve the problem, I hope you don't mind.

It looks like it's not gonna be very easy to debug this, and
considering the way the package works[1], I'm lowering the severity to
normal and I'll likely not gonna try to fix it (anybody reading this
please feel free to submit MRs).

In order to debug this you will probably have to get a stacktrace for
two runs of aeskeyfind against the same dump file, one for each
version of glibc (or whatever is the suspect), and compare them to see
where's the difference in computation occurring for the xor variables.
This is gonna be quite complicated as those variables get changed
inside a loop (for the chunks of memory retrieved) and you're only
interested in one of those iterations (maybe the dump can be
simplified to contain only the key).

I bet it would be an interesting and cool investigation, but one would
have to have enough time for it, so don't feel pressured to do so, the
fact that you found the issue and contributed the integ tests already
put the package in a much better position.

[0] 
https://salsa.debian.org/pkg-security-team/aeskeyfind/-/commit/a282f8ed7afb207a7a713ac0612b3cdba860fb48
[1] The paper where this software comes from starts from the principle
that the key to be retrieved is corrupted (cold memory) and so it has
some heuristics to try to find the key, the threshold parameter is
related to that and so users are expected to understand they need to
tweak "-t" in their investigations.
https://citp.princeton.edu/our-work/memory/

Thanks,

-- 
Samuel Henrique 

Bug#989559: mirror submission for mirror.hostafrica.co.za

[Rudi]

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

Submission-Type: new
Site: mirror.hostafrica.co.za
Type: leaf
Archive-architecture: amd64 hurd-i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Rudi 
Country: ZA South Africa
Location: Johannesburg




Trace Url: http://mirror.hostafrica.co.za/debian/project/trace/
Trace Url: 
http://mirror.hostafrica.co.za/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.hostafrica.co.za/debian/project/trace/mirror.hostafrica.co.za

Bug#989560: xen-hypervisor-common: generates broken grub configuration on armhf

[Maximilian Engelhardt]

Package: xen-hypervisor-common
Version: 4.14.1+11-gb0b734a8b3-1
Severity: important

Installing xen-system-armhf in a test vm and running update-grub left me with 
a grub configuration that cannot boot the xen hypervisor and gets stuck in the 
grub menu. It's still possible to boot the normal linux kernel after manual 
selection. Grub outputs the following error:


Loading Xen 4.14-armhf ...
error: can't find command `multiboot'.
Loading Linux 5.10.0-7-armmp-lpae ...
error: can't find command `module'.
Loading initial ramdisk ...
error: can't find command `module'.

Press any key to continue...


The problem is that the /etc/grub.d/20_linux_xen file from the grub-common 
package generates a multiboot line for the xen hypervisor but there is no 
multiboot module available for grub on armhf.

I did a bit research but could not come up with a way to boot the xen 
hypervisor from grub on armhf, maybe somebody has more knowledge here.

This may be a bug in 20_linux_xen, but only installing xen-hypervisor-common 
causes a not working grub configuration to be generated, so I'm filing this 
against this package now. Feel free to reassign.

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

Bug#989558: apt: please add a pattern that allows one to select packages by priority

[Johannes Schauer Marin Rodrigues]

Package: apt
Version: 2.2.3
Severity: normal

Hi,

it seems that there is currently no pattern that allows one to select
packages by priority according to apt-patterns(7). Please consider
adding that functionality.

Currently I parse "apt-get indextargets ... | /usr/lib/apt/apt-helper
cat-file" in mmdebstrap and I'd like to replace that by something like:

apt-get install 
?and(?archive(unstable),?architecture(amd64),?priority(important))

Thanks!

cheers, josch

Bug#989556: Casync security/backup features

[Michael Biebl]

Am 07.06.21 um 15:50 schrieb Demirci, Yasin:

Package: casync

Version: 2+20180321-2.1

Severity: wishlist

Do you have a rough time for when you will release the encryption and 
verification features from your TODO list?




Fwiw, this is not so much as a bug report but more a (user) question.
The Debian BTS is for tracking issues.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#836211: dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link

[Tomas Krizek]

On Wed, 31 Aug 2016 12:16:10 -0300 Felipe Sateler 
wrote:>  unable to move aside './usr/share/bug/apt' to install new
version: Invalid cross-device link
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

I'm hitting this bug when attempting to use debian in a container backed
by overlayfs.

Kernel version on host: 5.12.8.arch1-1

It works fine with kernel 5.10.41-1.

-- 
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989557: RFS: fontedit/1.1.0-1 [ITP] -- edit fonts as byte arrays for use in embedded systems

[Gürkan Myczko]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fontedit":

 * Package name: fontedit
   Version : 1.1.0-1
   Upstream Author : Dominik Kapusta
 * URL : https://kapusta.cc/fontedit
 * License : BSD-3-clause, MIT, BSL-1.0, GPL-3+, Apache-2.0
 * Vcs : https://salsa.debian.org/fonts-team/fontedit
   Section : fonts

It builds those binary packages:

  fontedit - edit fonts as byte arrays for use in embedded systems

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


  https://mentors.debian.net/package/fontedit/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/f/fontedit/fontedit_1.1.0-1.dsc


Changes for the initial release:

 fontedit (1.1.0-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #962120)

Regards,
--
  Gürkan Myczko

Bug#989556: AW: Bug#989556: Casync security/backup features

[Demirci, Yasin]

The casync salsa.debian.org TODO list 
https://salsa.debian.org/systemd-team/casync/-/blob/master/TODO.

-Ursprüngliche Nachricht-
Von: Michael Biebl  
Gesendet: Montag, 7. Juni 2021 16:02
An: Demirci, Yasin (SMO RI R SYS SEC) ; 
989...@bugs.debian.org
Betreff: Re: Bug#989556: Casync security/backup features

Am 07.06.21 um 15:50 schrieb Demirci, Yasin:
> Package: casync
> 
> Version: 2+20180321-2.1
> 
> Severity: wishlist
> 
> Do you have a rough time for when you will release the encryption and 
> verification features from your TODO list?

Which TODO list?

Bug#989556: Casync security/backup features

[Michael Biebl]

Am 07.06.21 um 15:50 schrieb Demirci, Yasin:

Package: casync

Version: 2+20180321-2.1

Severity: wishlist

Do you have a rough time for when you will release the encryption and 
verification features from your TODO list?


Which TODO list?






OpenPGP_signature
Description: OpenPGP digital signature

Bug#989556: Casync security/backup features

[Demirci, Yasin]

Package: casync
Version: 2+20180321-2.1
Severity: wishlist

Do you have a rough time for when you will release the encryption and 
verification features from your TODO list?
These features are needed to use casync for the security requirements of the 
IEC 62443-4-2.
With best regards,
Yasin Demirci

Siemens Mobility GmbH
SMO RI R SYS SEC
Ackerstr. 22
38126 Braunschweig, Germany
Mobile: +49 173 6244113
mailto:yasin.demi...@siemens.com
www.siemens.com
[cid:image001.gif@01D75BB4.D74DA5B0]
Siemens Mobility GmbH; Chairman of the Supervisory Board: Roland Busch; 
Management Board: Karl Blaim, Michael Peter; Registered office: Munich, 
Germany; Commercial registry Munich, HRB 237219; WEEE-Reg.-No. DE 92917817

Bug#987244: RFS: nbsdgames/4.0-1 [ITP] -- text based mini games for your terminal

[Gürkan Myczko]

Thanks for all the replies.

Upstream agreed to rename all the binaries to nbwhatever, so once that 
happens,

and a new release. This will continue...

Bug#989555: opencryptoki: diff for NMU version 3.8.1+dfsg-3.2

[Laurent Bigonville]

Package: opencryptoki
Version: 3.8.1+dfsg-3.1
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for opencryptoki (versioned as 3.8.1+dfsg-3.2) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru opencryptoki-3.8.1+dfsg/debian/changelog 
opencryptoki-3.8.1+dfsg/debian/changelog
--- opencryptoki-3.8.1+dfsg/debian/changelog2018-08-11 15:27:36.0 
+0200
+++ opencryptoki-3.8.1+dfsg/debian/changelog2021-06-07 15:35:32.0 
+0200
@@ -1,3 +1,11 @@
+opencryptoki (3.8.1+dfsg-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build again on architectures where libitm and transactional memory are not
+available, use locks instead
+
+ -- Laurent Bigonville   Mon, 07 Jun 2021 15:35:32 +0200
+
 opencryptoki (3.8.1+dfsg-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru opencryptoki-3.8.1+dfsg/debian/control 
opencryptoki-3.8.1+dfsg/debian/control
--- opencryptoki-3.8.1+dfsg/debian/control  2017-10-31 15:26:51.0 
+0100
+++ opencryptoki-3.8.1+dfsg/debian/control  2021-06-07 15:35:32.0 
+0200
@@ -10,7 +10,7 @@
  libtspi-dev,
  bison,
  flex,
- libitm1,
+ libitm1 [alpha amd64 arm64 i386 x32 ppc64 ppc64el s390x sh4 sparc64],
  libica-dev [s390x],
  libldap2-dev
 Standards-Version: 4.1.1
diff -Nru opencryptoki-3.8.1+dfsg/debian/rules 
opencryptoki-3.8.1+dfsg/debian/rules
--- opencryptoki-3.8.1+dfsg/debian/rules2017-11-09 12:52:15.0 
+0100
+++ opencryptoki-3.8.1+dfsg/debian/rules2021-06-07 15:34:50.0 
+0200
@@ -4,6 +4,11 @@
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+# Use locks instead of transactional memory in architectures where libitm is 
not available
+ifeq (,$(filter $(DEB_HOST_ARCH), alpha amd64 arm64 i386 x32 ppc64 ppc64el 
s390x sh4 sparc64))
+ENABLE_LOCKS=--enable-locks
+endif
+
 %:
dh ${@}
 
@@ -12,7 +17,7 @@
rm -f usr/lib/pkcs11/api/pkcs11
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-tpmtok --with-systemd=/lib/systemd/system 
ac_cv_path_CHGRP=true
+   dh_auto_configure -- --enable-tpmtok --with-systemd=/lib/systemd/system 
ac_cv_path_CHGRP=true $(ENABLE_LOCKS)
 
 override_dh_auto_install:
dh_auto_install

Bug#989550: suitesparse: enhance 64-bit support in suitesparse

[Drew Parsons]

Thanks Mo, good to see the work is started already.

Drew



On 2021-06-07 14:58, M. Zhou wrote:

Hi Drew,

Thanks for the proposal. Just for your information,
there is a WIP branch on suitesparse64:
https://salsa.debian.org/science-team/suitesparse/-/commits/lumin

I just ... ummm ... need some time to finish it.
Of course, any help would be appreciated.


On Mon, 2021-06-07 at 12:56 +0200, Drew Parsons wrote:

...


Once metis64 is available, we'll be free to provide suitesparse64
i.e. libsuitesparse64-dev (it might be that header files can be
transferred to a libsuitesparse-common-dev to share with
libsuitesparse-dev),
libcholmod64-3 (or similar), etc.

Bug#989553: imapd: bullsey regression: unable to get certificate CRL

[Juergen Pfennig]

Package: cyrus-imapd
Version: 3.2.6-2
Severity: normal
File: imapd

Dear Maintainer,

After upgrading to bullseye clients using tls cannot connect due to:

Jun 06 13:41:06 alpha1 cyrus/imapsr[2393]: inittls: Loading hard-coded DH 
parameters
Jun 06 13:41:06 alpha1 cyrus/imapsr[2388]: verify error:num=3:unable to get 
certificate CRL
Jun 06 13:41:06 alpha1 cyrus/imapsr[2388]: imaps TLS negotiation failed: 
android3.centauri.home [10.21.2.203]

This happens with both, an empty crl.pem and one with a test
certificate:

root@alpha1:~# ls -l /etc/ssl
total 20
drwxr-xr-x 1 root root 10826 2021-01-24 17:54 certs
-rw-r--r-- 1 root root 0 2021-06-07 10:34 crl.pem
-rw-r--r-- 1 root root   593 2014-08-27 10:47 crl.pem.bak
-rw-r--r-- 1 root root 11943 2020-02-22 12:55 openssl.cnf
drwx--x--- 1 root ssl-cert68 2020-12-28 16:16 private
-rw-r--r-- 1 root root18 2018-04-01 18:14 README-crl

The relevant imapd.conf contains the following tls related stuff:

tls_server_cert: /etc/ldap/servercrt.pem
tls_server_key: /etc/ldap/serverkey.pem
tls_client_ca_file: /etc/ldap/cacert.pem
tls_session_timeout: 1440
tls_ciphers: TLSv1.2:+TLSv1:+HIGH:!aNULL:@STRENGTH
tls_versions: tls1_2 tls1_3
tls_require_cert: true
tls_crl_file: /etc/ssl/crl.pem

Commenting out the "tls_crl_file" statement lets clients connect again,
but this would disable certificate revocation.

Jun 07 15:16:29 alpha1 cyrus/imapsr[3112]: login: android3.centauri.home 
[10.21.2.203] internet EXTERNAL+TLS User logged in 
SESSIONID=
Jun 07 15:16:29 alpha1 cyrus/imapsr[3135]: inittls: Loading hard-coded DH 
parameters
Jun 07 15:16:29 alpha1 cyrus/imapsr[3135]: starttls: TLSv1.3 with cipher 
TLS_AES_128_GCM_SHA256 (128/128 bits new) authenticated as internet

Thanks Jürgen

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 cyrus-imapd depends on:
ii  cyrus-common  3.2.6-2
ii  libc6 2.31-12
ii  libcom-err2   1.46.2-1
ii  libsasl2-22.1.27+dfsg-2.1
ii  libssl1.1 1.1.1k-1
ii  libwrap0  7.6.q-31
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages cyrus-imapd recommends:
ii  rsync  3.2.3-4

cyrus-imapd suggests no packages.

-- no debconf information

Bug#989307: DSA-4923-1: upgrading libwebkit2gtk-4.0-37 on buster pulls in xdg-desktop-portal

[Alberto Garcia]

On Mon, Jun 07, 2021 at 08:52:32PM +0900, Olaf Meeuwissen wrote:
> >> Package changes:
> >> + fuse 2.9.9-1+deb10u1 amd64
> >> + libpipewire-0.2-1 0.2.5-1 amd64
> >> + xdg-desktop-portal 1.2.0-1 amd64
> >> + xdg-desktop-portal-gtk 1.2.0-1 amd64
> >
> > Yes, these are the actual new dependencies.
> 
> Plus whatever these depend on that wasn't already installed.

This is the complete list of extra dependencies pulled
by xdg-desktop-portal-gtk on a clean buster system with
libwebkit2gtk-4.0-37 but no other recommended packages installed.

The following NEW packages will be installed:
  fuse libfuse2 libpipewire-0.2-1 xdg-desktop-portal xdg-desktop-portal-gtk

> > Future security updates and buster backports will Suggest
> > xdg-desktop-portal-gtk, although in bullseye it will still be a
> > recommendation.
> 
> Good.  I don't mind packages acquiring Recommends in testing/unstable.
> I do mind when that happens in stable-security.

I understand, but note that although in this particular case it
shouldn't have been a Recommends, we cannot guarantee that in general.
The WebKit packages in Debian follow the upstream stable branches
and like all other major browser engines they have frequent security
updates.

> Bloat.
> Increased attack surface.

Using xdg-desktop-portal-gtk is actually a consequence of the webkit
processes now running inside a sandbox for security reasons, so there
is a trade-off between not using the sandbox at all or using the
sandbox but recommending (not depending on) the portals. I chose the
latter.

> Just let this be a warning for *all* stable-security packages to
> pay some extra attention to changing dependencies.  If it's only
> changing versions of packages already depended upon, that _probably_
> okay.  New packages should raise a red flag.

It was taken into account, and that one of the reasons why it was
downgraded to a recommendation (it was initially a dependency).

Regards,

Berto

Bug#989546: gnome-shell-extension-dash-to-panel: Panel disappears after screen unlock with fullscreen content

[Mitchell]

Package: gnome-shell-extension-dash-to-panel
Version: 40-1
Severity: normal
Tags: patch
X-Debbugs-Cc: bloomfield.evergr...@protonmail.com

Dear maintainer,

There is a bug with the extension that causes the panel to disappear every time 
after the screen is unlocked with fullscreen content. This can be easily 
reproduced with a web browser playing videos in fullscreen mode, getting screen 
locked, then unlocked. This bug is particularly annoying for working from home 
with remote desktop connections where the screensaver timeout would make the 
panel disappear, so if you could merge the fix that would be great!

Proposed working patch: 
https://github.com/home-sweet-gnome/dash-to-panel/pull/1347/files

If you could take a look that would be great!

Thanks!
Mitchell

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

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

Versions of packages gnome-shell-extension-dash-to-panel depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2
ii gnome-shell 3.38.4-1
ii gnome-shell-extension-prefs 3.38.4-1

gnome-shell-extension-dash-to-panel recommends no packages.

gnome-shell-extension-dash-to-panel suggests no packages.

-- no debconf information
Thank you for using reportbug

Bug#989069: nvidia-driver: Crash when displayport is plugged.

[Christian Marillat]

On 07 juin 2021 09:17, Andreas Beckmann  wrote:

> On 06/06/2021 12.44, Christian Marillat wrote:
>> As requested in your previous e-mail (tesla-450) 450.119.04
>
> Thanks, then I'll try to get that unblocked.
>
> Did you have a chance to test 460.84, yet? The (usually sparse)

Well, where are 460.84 driver ?

> upstream changelog doesn't mention anything related to DP, though, but
> that doesn't mean anything.
> Nobody commented in the forum thread about 460.84 so far.

https://forums.developer.nvidia.com/t/465-24-02-page-fault/175782/70

Christian

Bug#989550: suitesparse: enhance 64-bit support in suitesparse

[M. Zhou]

Hi Drew,

Thanks for the proposal. Just for your information,
there is a WIP branch on suitesparse64:
https://salsa.debian.org/science-team/suitesparse/-/commits/lumin

I just ... ummm ... need some time to finish it.
Of course, any help would be appreciated.


On Mon, 2021-06-07 at 12:56 +0200, Drew Parsons wrote:
> Package: suitesparse
> Severity: normal
> Control: block -1 by 961183
> Control: block 961977 by -1
> 
> We've been introducing a 64 bit-build for the computational stack.
> This refers mainly to 64-bit indexing, enabling computation of
> extremely large systems (billions of degrees of freedom)
> 
> Some packages are already 64-bit enabled, including BLAS, PETSc.
> 
> SuiteSparse handles the 64-bit question by defining SuiteSparse_long
> (and using idx_t with metis). If I understand the SuiteSparse
> configuration correctly, this means a specific configuration option
> doesn't need to be set for SuiteSparse to compute large systems.
> 
> But as part of the 64-bit computation stack in Debian, we'd need to
> provide a separate suitesparse64 build in order to link suitesparse
> against blas64 or metis64. (I'm assuming this is a thing we would
> want
> to do in the context of 64-bit computation).
> 
> This affects cholmod, for instance, in the sense that cholmod uses
> idx_t defined in metis.h.  IDXTYPEWIDTH is the quantity in metis.h
> which we'll need to set to 64, in order to provide 64-bit Metis (this
> is requested in Bug#961183).
> 
> Once metis64 is available, we'll be free to provide suitesparse64
> i.e. libsuitesparse64-dev (it might be that header files can be
> transferred to a libsuitesparse-common-dev to share with
> libsuitesparse-dev),
> libcholmod64-3 (or similar), etc.
> 
> Once suitesparse64 is available, we'll be able link it from petsc64,
> which is currently linking to the standard build of suitesparse.
> 
> Drew
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'unstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_AU:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 

Bug#989552: [patch] expand description of --variant

[McIntyre, Vincent (CASS, Marsfield)]

Package: debootstrap
Severity: wishlist
Tags: patch
Thanks

Hello

please consider applying this small patch to the manpage.

Kind regards
Vince

From 1e15507bacfb2547e1c2bace7c3781dd3ab2f45c Mon Sep 17 00:00:00 2001
From: Vincent McIntyre 
Date: Mon, 7 Jun 2021 20:29:08 +1000
Subject: [PATCH] Improve description of --variant

A discussion on debian-boot@lists.d.o elicited an explanation of how
deboostrap selects packages to install, which seems to be a point of
confusion for some users
While here, add a colon before the first item in the list of variants.
---
 debootstrap.8 | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/debootstrap.8 b/debootstrap.8
index e3ed5d7..2527707 100644
--- a/debootstrap.8
+++ b/debootstrap.8
@@ -80,7 +80,10 @@ set this option to track them through debootstrap.log.
 .IP
 .IP "\fB\-\-variant=minbase|buildd|fakechroot\fP"
 Name of the bootstrap script variant to use.
-Currently, the variants supported are minbase, which only includes
+Debootstrap reads the Packages file and determines which packages
+to install based on the \fIPriority:\fR field of each package and
+the selected variant.
+Currently, the variants supported are: minbase, which only includes
 \fIrequired\fR packages and apt; buildd, which installs the build-essential
 packages and fakechroot, which installs the packages without root privileges.
 The default, with no \fB\-\-variant=X\fP argument, is to create a
-- 
2.31.1


-- 

Bug#989307: DSA-4923-1: upgrading libwebkit2gtk-4.0-37 on buster pulls in xdg-desktop-portal

[Olaf Meeuwissen]

Hi Alberto,

Alberto Garcia writes:

> On Sat, Jun 05, 2021 at 11:45:45AM +0900, Olaf Meeuwissen wrote:
>
>> In the mean time, I'll just `apt purge` the added packages.  In my
>> case these were the
>>
>> Package changes:
>> + fuse 2.9.9-1+deb10u1 amd64
>> + libpipewire-0.2-1 0.2.5-1 amd64
>> + xdg-desktop-portal 1.2.0-1 amd64
>> + xdg-desktop-portal-gtk 1.2.0-1 amd64
>
> Yes, these are the actual new dependencies.

Plus whatever these depend on that wasn't already installed.  I haven't
really pruned my Recommends: but other folks may have.

> Future security updates and buster backports will Suggest
> xdg-desktop-portal-gtk, although in bullseye it will still be a
> recommendation.

Good.  I don't mind packages acquiring Recommends in testing/unstable.
I do mind when that happens in stable-security.

> I don't think there's any better way to have those packages removed
> automatically (certainly not a Conflicts, many people had them
> installed anyway). Apart from a couple of MBs of extra used disk
> space, is there anything particularly worrying you?

Bloat.
Increased attack surface.

As far as libwebkit2gtk-4.0-37 is concerned, it happened and everyone
that cares has to clean up manually.  That's too bad.
Just let this be a warning for *all* stable-security packages to pay
some extra attention to changing dependencies.  If it's only changing
versions of packages already depended upon, that _probably_ okay.  New
packages should raise a red flag.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

Bug#989222: marked as done (darktable: crashes with "Floating point exception (core dumped)" after loading some DNG files)

[Jonas Smedegaard]

Hi David,

Quoting David Bremner (2021-06-06 16:41:08)
> Can you confirm that the the -4 upload fixes your crashes?

Yes, works fine now - thanks!

 - 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#989551: linux-image-5.10.0-7-amd64: linux-image-5.10.0.7-amd64 hang on boot. Shows symbols: '^@^@^@' and nothing else. Debian testing.

[Salvatore Bonaccorso]

Control: notfound -1 5.10.28-1
Control: found -1 5.10.38-1
Control: tags -1 + moreinfo

On Mon, Jun 07, 2021 at 02:09:20PM +0300, Mikhail Osipov wrote:
> Package: src:linux
> Version: 5.10.28-1
> Severity: important
> X-Debbugs-Cc: osm...@gmail.com
> 
> 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 ***

I'm assuming here it is relating to the
https://lists.debian.org/debian-kernel/2021/06/msg00066.html report,
thus adjusting the found version to 5.10.38-1.

Mikhail, we have only litte information here to sensibly tackle the
problem.

When you boot 5.10.38-1 do you get any usefull information logged in
the logs? Can you attach those to the bug?

Please try to boot without quiet (and splash), do you get more
information printed and indication where it hangs?

Regards,
Salvatore

Bug#989550: suitesparse: enhance 64-bit support in suitesparse

[Drew Parsons]

Package: suitesparse
Followup-For: Bug #989550

libcholmod3 and libspqr2 and libumfpack5 seem to be the only
SuiteSparse components directly affected by the 64-bit numerical
library stack, by linking to libblas.so.3 and liblapack.so.3.
libcholmod3 also links to libmetis5, and libspqr2 and libumfpack5
link to libcholmod3.

Not sure if this makes the packaging easier or harder.
Should libspqr64-2 link to libamd64-2 or to libamd2 ?
Should libamd64-2 be provided if it's identical to libamd2 ?

Bug#989551: linux-image-5.10.0-7-amd64: linux-image-5.10.0.7-amd64 hang on boot. Shows symbols: '^@^@^@' and nothing else. Debian testing.

[Mikhail Osipov]

Package: src:linux
Version: 5.10.28-1
Severity: important
X-Debbugs-Cc: osm...@gmail.com

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


-- Package-specific info:
** Version:
Linux version 5.10.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.28-1 (2021-04-09)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-6-amd64 root=/dev/mapper/teal--vg-root ro 
RESUME=/dev/mapper/teal--vg-root resume_offset=26163200 quiet splash

** Not tainted

** Kernel log:
[  127.535385] rtw_8822ce :03:00.0: timed out to flush queue 1
[  191.819404] rtw_8822ce :03:00.0: timed out to flush queue 2
[  192.623381] rtw_8822ce :03:00.0: timed out to flush queue 1
[  193.543391] rtw_8822ce :03:00.0: timed out to flush queue 1
[  193.743376] rtw_8822ce :03:00.0: timed out to flush queue 1
[  193.883426] rtw_8822ce :03:00.0: timed out to flush queue 2
[  194.687443] rtw_8822ce :03:00.0: timed out to flush queue 1
[  195.887391] rtw_8822ce :03:00.0: timed out to flush queue 1
[  229.903384] rtw_8822ce :03:00.0: timed out to flush queue 2
[  232.967406] rtw_8822ce :03:00.0: timed out to flush queue 2
[  253.279406] rtw_8822ce :03:00.0: timed out to flush queue 2
[  256.099335] rtw_8822ce :03:00.0: timed out to flush queue 2
[  296.259174] rtw_8822ce :03:00.0: timed out to flush queue 2
[  297.079375] rtw_8822ce :03:00.0: timed out to flush queue 1
[  297.223351] rtw_8822ce :03:00.0: timed out to flush queue 1
[  298.899143] rtw_8822ce :03:00.0: timed out to flush queue 2
[  299.739159] rtw_8822ce :03:00.0: timed out to flush queue 1
[  300.643166] rtw_8822ce :03:00.0: timed out to flush queue 2
[  964.355166] rtw_8822ce :03:00.0: timed out to flush queue 2
[  967.171379] rtw_8822ce :03:00.0: timed out to flush queue 2
[  967.655155] rtw_8822ce :03:00.0: timed out to flush queue 2
[  985.383164] rtw_8822ce :03:00.0: timed out to flush queue 1
[  985.895142] rtw_8822ce :03:00.0: timed out to flush queue 1
[  987.547140] rtw_8822ce :03:00.0: timed out to flush queue 2
[  989.663144] rtw_8822ce :03:00.0: timed out to flush queue 2
[  990.475151] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1002.475153] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1002.955146] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1005.979406] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1007.547153] rtw_8822ce :03:00.0: timed out to flush queue 1
[ 1232.039175] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1232.955149] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1234.643148] rtw_8822ce :03:00.0: timed out to flush queue 1
[ 1235.163144] rtw_8822ce :03:00.0: timed out to flush queue 1
[ 1235.311144] rtw_8822ce :03:00.0: timed out to flush queue 1
[ 1243.055157] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1246.483149] rtw_8822ce :03:00.0: timed out to flush queue 1
[ 1246.631146] rtw_8822ce :03:00.0: timed out to flush queue 1
[ 1246.775144] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1396.307197] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1396.783327] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1399.259160] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1399.411354] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1416.623154] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1458.571414] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1459.067152] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1460.563161] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1461.047161] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1461.527144] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1462.011142] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1462.163155] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1462.899148] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1463.707147] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1464.167142] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1464.311154] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1489.959162] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1490.419191] rtw_8822ce :03:00.0: timed out to flush queue 1
[ 1491.047346] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1582.819155] rtw_8822ce :03:00.0: timed out to flush queue 1
[ 1583.271388] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1609.643194] rtw_8822ce :03:00.0: timed out to flush queue 2
[ 1613.855145] rtw_8822ce :03:00.0: timed 

Bug#967972: [Pkg-samba-maint] Bug#967972: cifs-utils: fails to mount filesystem when keyutils is not installed

[L . P . H . van Belle]

That is already set 
See closed bug in cifs-utils, bugnr.: #986867  

Greetz, 

Louis


> -Oorspronkelijk bericht-
> Van: Pkg-samba-maint 
> [mailto:pkg-samba-maint-bounces+belle=bazuin.nl@alioth-lists.d
ebian.net] Namens Jonathon Reinhart
> Verzonden: maandag 7 juni 2021 6:33
> Aan: 967...@bugs.debian.org
> Onderwerp: [Pkg-samba-maint] Bug#967972: cifs-utils: fails to 
> mount filesystem when keyutils is not installed
> 
> Some sources incorrectly indicate that keyutils is only needed with
> DFS, but keyutils is also needed when using CIFS w/ Kerberos
> authentication.
> 
> When trying to mount a CIFS share using kerberos (sec=krb5), the
> kernel invokes /sbin/request-key to request a key from userspace. Then
> cifs.upcall (from cifs-utils) is executed to handle the SPNEGO
> authentication.
> 
> If keyutils is not installed, then /sbin/request-key is absent, and
> the kernel is completely silent about this.
> 
> [  +0.497021] CIFS VFS: Send error in SessSetup = -2
> [  +0.000992] CIFS VFS: cifs_mount failed w/return code = -2
> 
> Thus, I strongly agree with the proposal for cifs-utils to *Recommend*
> keyutils, rather than merely *Suggesting* it.
> 
> ___
> Pkg-samba-maint mailing list
> pkg-samba-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-s
> amba-maint
> 
> 

Bug#989550: suitesparse: enhance 64-bit support in suitesparse

[Drew Parsons]

Package: suitesparse
Severity: normal
Control: block -1 by 961183
Control: block 961977 by -1

We've been introducing a 64 bit-build for the computational stack.
This refers mainly to 64-bit indexing, enabling computation of
extremely large systems (billions of degrees of freedom)

Some packages are already 64-bit enabled, including BLAS, PETSc.

SuiteSparse handles the 64-bit question by defining SuiteSparse_long
(and using idx_t with metis). If I understand the SuiteSparse
configuration correctly, this means a specific configuration option
doesn't need to be set for SuiteSparse to compute large systems.

But as part of the 64-bit computation stack in Debian, we'd need to
provide a separate suitesparse64 build in order to link suitesparse
against blas64 or metis64. (I'm assuming this is a thing we would want
to do in the context of 64-bit computation).

This affects cholmod, for instance, in the sense that cholmod uses
idx_t defined in metis.h.  IDXTYPEWIDTH is the quantity in metis.h
which we'll need to set to 64, in order to provide 64-bit Metis (this
is requested in Bug#961183).

Once metis64 is available, we'll be free to provide suitesparse64
i.e. libsuitesparse64-dev (it might be that header files can be
transferred to a libsuitesparse-common-dev to share with
libsuitesparse-dev),
libcholmod64-3 (or similar), etc.

Once suitesparse64 is available, we'll be able link it from petsc64,
which is currently linking to the standard build of suitesparse.

Drew


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

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

Bug#989473: choose-mirror: switch mirror list from salsa to mirror-master

[Peter Palfrader]

On Sat, 05 Jun 2021, Philip Hands wrote:

>  c) filter the old masterlist to only include entries that are also in
> the new list, and then use the result of that, perhaps with a tweak
> to promote deb.d.o
> 
> c) is a bit of a cludge, but seems like the only one that's got a chance
> of happening before the release, and gets most of the benefit of the new
> list.

The Type info in the salsa Masterlist is also probably not correct in
a lot of cases.

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#989473: choose-mirror: switch mirror list from salsa to mirror-master

[Peter Palfrader]

On Sat, 05 Jun 2021, Philip Hands wrote:

> Philip Hands  writes:
> 
> ...
> >  c) filter the old masterlist to only include entries that are also in
> > the new list, and then use the result of that, perhaps with a tweak
> > to promote deb.d.o
> 
> BTW Promoting deb.d.o can be done thus:
> 
>   
> https://salsa.debian.org/philh/choose-mirror/-/commit/70caed09fbf4bfbcc9eca82168cf3936868d8394
> 
> which produces this menu ordering:
> 
>   https://openqa.debian.net/tests/6101#step/mirror_selection/2

And then add a line that maybe gives some number (6, 7?) to other things
matching ~/\.debian\.org$/?


-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#988618: unblock: kodi-pvr-iptvsimple/7.6.5+ds1-1

[Vasyl Gello]

Package: release.debian.org
Followup-For: Bug #988618
X-Debbugs-Cc: phunkyf...@kodi.tv

Hi Sebastian,

> The new version also introduces some new features and is not a targeted
> bug fix release. Please cherry pick the fixes if you deem them
> important.

You are right in the part that this upload is not *solely* a bugfix release.
Unlike Kodi itself, Kodi add-ons may implement new features per release policy.
The only requirement is not to introduce breaking changes in release branch
targeting current stable Kodi version (19.x). Branches targeting old-stable
Kodi version (18.x) receive only targeted fixes for security & grave functional
issues.

However, as a user of PVR IPTVSimple, I insist that it is better for an end-user
to have this release in bullseye rather not to have.

Let's consider the changelog for the release chain (omitting commits that touch
only version in addon XML manifest and the changelog file):

> v7.6.5:
> Allow embedded commas in channel name in M3U

This change has numerously been asked on Kodi forums in the past years.
Plus, I had to strip excessive commas from Divan.TV channel names not to break
M3U parser for my HTPC.

> v7.6.4:
> Only use Local logo location if file is relative
> Add string initialisation from macros as some linux fail to compile without it

This is a low-risk change because the release on Debian compiles without issues.
The logo commit is a fix for buggy logic for *some* users who provide custom 
logo
packs for their IPTV channels.

> v7.6.2:
> Always load EPG data if we prefer XMLTV logos or catchup is enabled
> Allow catchup correction (timezone shift) when live URLs have catchup 
> placeholders

This commit is another correction for a previously buggy behavior that resulted 
in
irregular updates of EPG data. The PVR timeshift mode introduced in Kodi 19.0 
requires
daily update of EPG info, and this commit ensures the update takes place.

> v7.6.1:
> Update readme
> update text for path type option
> Allow ignoring M3U logos when using local logo path

This is a requested feature correcting previously buggy behavior (see [1]).
The readme part is a documentation fix reflecting the new logic.

> v7.6.0:
> Support xeev XC catchup prefixes
> Add setting for catchup correction
> Disable other catchup settings if catched is not enabled
> Allow flusonnic channel ids containing forward slashes
> Support url-tvg in M3U header in addition to x-tvg-url
> Add support for XZ compression of XMLTV data

This was requested in Kodi reddit group (if my memory serves me well.
because I can not find the exact post).

> v7.5.1:
> Ensure channel's catchup window is used instead of value from settings
> Treat 'tvg-rec' catchup tag like the siptv 'timeshift' tag
> Fix typo

This is a correction to timeshift ('catchup') code making the addon to
recognize M3U 'tvg-rec' tag supplying the path to TV archive stream.

> v7.5.0:
> Allow setting scope for channels using catchup mode setting to enable 
> overriding
> Support sub channel numbers

This was requested in [2].

Given that I use IPTVSimple daily on testing, I hope the release gets accepted 
as
is.

I am also CC'ing Ross Nicholson aka phunkyfish so he is aware about the matter.

Cheers, 
vasyl

---

[1] https://github.com/kodi-pvr/pvr.iptvsimple/issues/505
[2] https://github.com/kodi-pvr/pvr.iptvsimple/issues/467

Bug#989549: clamav-daemon: any local user can shut clamd down via control socket

[Stephane Chazelas]

Some additional notes, from discussion on the Ubuntu bugs:

1. dpkg-reconfigure dialogs say in the first dialog:

   "The ClamAV suite won't work if it isn't configured".
   However, that dialog is not displayed upon install, and
   except for
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979077
   clamd does work out of the box (after a reboot for instance
   to address 979077).

2. While via dpkg-reconfigure, we can restrict access to the
   socket and somewhat mitigate the vulnerability, it's not
   really an acceptable solution, as that socket is used both
   for the service and for daemon control, so by restricting
   access to the socket, we're preventing access to the service,
   and clients that need access to the service (MTAs, ftp, web
   servers...) are not the same as the ones that are meant to
   control the daemon (systemd, freshclam...).

3. The systemd service unit uses default Type=simple with clamd
   started in foreground. That means clamd is considered up and
   active before it is ready to accept requests. Using
   Type=forking (and remove the --foreground) would address
   that. (reinstating PidFile in clamd.conf would (according to
   systemd doc) make the MainPID detection more reliable and
   help with shutting down / reloading when access to the socket
   is restricted. See also
   https://github.com/extremeshok/clamav-unofficial-sigs/issues/392)

4. I'd expect a number of packages which depend on clamd or can
   be configured to do so currently rely on clamd being
   configured with the socket publicly accessible. Those would
   have to be taken into account in any fix to the issue. At the
   Ubuntu bug, I mention e2guardian or clamsmtp which depend on
   clamav-daemon though I've not looked at those in details.

   There's also amavis which is typically used with clamd for
   email filtering.

   To mitigate the issue on a deployment  where clamd is used
   only by amavis, I changed the socket permissions to be
   rw--- clamav clamav, change the Type to forking as per
   above, and added an ACL to the socket file upon creation for
   amavis to be able to connect to it:

--- /lib/systemd/system/clamav-daemon.service   2021-06-04 15:05:34.272466670 
+0100
+++ /etc/systemd/system/clamav-daemon.service   2021-06-04 15:05:36.072489235 
+0100
@@ -6,11 +6,11 @@
 ConditionPathExistsGlob=/var/lib/clamav/daily.{c[vl]d,inc}
 
 [Service]
-ExecStart=/usr/sbin/clamd --foreground=true
+Type=forking
+ExecStart=/usr/sbin/clamd
 # Reload the database
 ExecReload=/bin/kill -USR2 $MAINPID
-StandardOutput=syslog
-TimeoutStartSec=420
+TimeoutStartSec=5min
 
 [Install]
 WantedBy=multi-user.target
--- /dev/null   2021-06-04 15:21:19.23200 +0100
+++ /etc/systemd/system/clamav-daemon.service.d/amavis.conf 2021-06-04 
15:19:37.335686866 +0100
@@ -0,0 +1,10 @@
+[Unit]
+Before=amavis.service
+
+[Service]
+# clamd allows its clients to shut it down! So access to /run/clamav/clamd.ctl
+# is restricted to a strict minimum. That's only members of the clamav group.
+# The amavis process can only be in one group. It also doesn't need access to
+# any of clamav's private resources. So we're only granting it access to the
+# socket.
+ExecStartPost=/usr/bin/setfacl -m u:amavis:rw /run/clamav/clamd.ctl

(requires acl package. Could be improved by adding PidFile to clamd.conf and
systemd service unit).

-- 
Stephane

Bug#989536: RFS: htmldoc/1.9.11-4 -- HTML processor that generates indexed HTML, PS, and PDF

[Neil Williams]

On Sun, 6 Jun 2021 19:32:37 + =?UTF-8?Q?H=c3=a5vard_Flaget_Aasen?= 
 wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "htmldoc":
> 
>  * Package name: htmldoc
>Version : 1.9.11-4
>Upstream Author : Michael R Sweet 
>  * URL : https://www.msweet.org/htmldoc/
>  * License : IJG, zlib, MIT-CMU, BSD-2-Clause, Apache-2.0 with
> (L)GPL-2 exception, GPL-2, PNG, GPL-2 with document exception,
> bitstream, Apache-2.0
>Section : web

I'll have a look at this request.

--

Neil Williams
=
https://linux.codehelp.co.uk/


pgpytrwyETsq3.pgp
Description: OpenPGP digital signature

Bug#989549: clamav-daemon: any local user can shut clamd down via control socket

[Stephane Chazelas]

Package: clamav-daemon
Version: 0.103.2+dfsg-2
Severity: important

Hello,

this is spawned off
https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1930393
where I reported the same bug for Ubuntu. Also affects Debian.
It's a (non-critical) security vulnerability but the issue has
already made public above.

After the default installation of clamav-daemon, as clamd's
service access socket (which also double as a control socket) is
world read+writeable:

$ namei -l /run/clamav/clamd.ctl
f: /run/clamav/clamd.ctl
drwxr-xr-x root root /
drwxr-xr-x root root run
drwxr-xr-x clamav root clamav
srw-rw-rw- clamav clamav clamd.ctl

(and needs to be for users to be able to pass files to scan, to
use the service)

and clamd doesn't seem to be doing any access control itself
either, any local user can shutdown clamd by sending the
SHUTDOWN (aka QUIT) command there:

$ printf 'zSHUTDOWN\0' | socat - unix-connect:/run/clamav/clamd.ctl

or just

$ echo QUIT | socat - unix:/run/clamav/clamd.ctl

For instance. Which makes it a denial of service vulnerability.

Other commands such as RELOAD (clamdscan --reload) or STATS may also need to be 
restricted.

That's with the current Debian testing version, but I'd expect it
applies to all versions of Debian and derivative.

It should probably be addressed upstreams by clamd checking the
credentials of the incoming connection, or as Seth suggested by
separating out the admin commands to a different (restricted)
socket.


-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "30"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
ConcurrentDatabaseReload = "yes"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "Paranoid"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertBrokenMedia disabled
AlertEncrypted disabled
StructuredCCOnly disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "262144000"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled

Bug#989548: light-locker: Username field has focus when unlocking

[Keith Edmunds]

Package: light-locker
Version: 1.8.0-3
Severity: normal

Dear Maintainer,

New installation of Bullseye with XFCE and light-locker. When the screen is 
locked,
the username is not populated and it also has focus. Previous versions of 
light-locker
would fill in the username and put the focus on the password field.

If one is used to the previous behaviour and starts typing the password, it 
appears in
clear text in the username field.

The username field should be populated with the logged-in user as that is by 
far the most
likely user to be unlocking the system.

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

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

Versions of packages light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libsystemd0  247.3-5
ii  libx11-6 2:1.7.1-1
ii  libxext6 2:1.3.3-1.1
ii  libxss1  1:1.2.3-1
ii  lightdm  1.26.0-7

light-locker recommends no packages.

light-locker suggests no packages.

-- no debconf information

Bug#983384: change owner

[Sudip Mukherjee]

control: owner -1 Christoph Berg 
--

Moving owner to Christoph as discussed in the thread at 
https://lists.debian.org/debian-java/2021/05/msg00017.html.

--
Regards
Sudip

Bug#989547: fai-client: ROOTCMD relies on specific unshare features

[Michael Prokop]

Package: fai-client
Version: 5.10.3
Severity: important

Starting with FAI v5.10, it uses:

  ROOTCMD="unshare --pid --fork --kill-child --mount-proc chroot $FAI_ROOT"

Though fai-client only recommends:

  Recommends: libgraph-perl, fdisk | util-linux (<< 2.29.2-3~)

unshare(1) on e.g. Debian/stretch doesn't know the --kill-child
option yet though. So it actually "Depends: util-linux >=2.32-0.1~"
(the first Debian package version that shipped support for the
--kill-child option).

Furthermore this ROOTCMD setting with unshare fails in e.g.
unprivileged docker containers:

| root@f6c0db65ee69:/code/# unshare --pid --fork --kill-child --mount-proc 
chroot / ls
| unshare: unshare failed: Operation not permitted

It would be nice, if ROOTCMD isn't assumed to always work as such,
and provide an option to either use the old setting
(ROOTCMD="chroot $FAI_ROOT") or allow manually configuring it.

regards
-mika-

Bug#700841: trouble with debootstrap a ppc SPE build

[Petter Reinholdtsen]

Is there some reason this bug report about an expired
ports key is not yet flagged as done, or is it an
oversight?
-- 
Happy hacking
Petter Reinholdtsen

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

Hi Osamu!

On 2021-06-07 09:38, Osamu Aoki wrote:

I have no idea which is better but here is a technical implementation idea.

Add one optional commented out parameter to /etc/default/im-config
  , e.g.: FCITX_IM_ENV

Make im-config use it to override internal default.

So anyone got in to trouble can work around situation easily.

Add this fact to README.Debian...


Oops.. I saw your message only after having uploaded to experimental.

My thought now is that your idea is excellent if the uncertainty remains 
after we have received some user feedback. At this time we don't know if 
we have a situation which motivates another config option.


Does that make sense?

--
Gunnar

Bug#989541: postfix-policyd-spf-perl: openspf.org doesn't exist, shouldn't give it in bounce messages

[Russell Coker]

Package: postfix-policyd-spf-perl
Version: 2.011-1.1
Severity: normal

https://www.getmailbird.com/what-spf-resources-are-available-now-that-openspf-org-is-gone/

According to the above URL openspf.org disappeared in early 2019.

Jun  7 05:18:38 itmustbe postfix/policy-spf[2667136]: Policy action=550 Please 
see 
http://www.openspf.org/Why?s=mfrom;id=%40XXX.X.net;ip=999.99.999.99;r=luv.asn.au

Currently messages like the above are being logged and given in bounce
messages.  It should either direct to another site that gives the same
results as openspf.org used to give, or it should give a human readable
message like "Please note that IP 999.99.999.99 is not allowed to send mail
on behalf of x...@xxx.x.net due to SPF policy".

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/3 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages postfix-policyd-spf-perl depends on:
ii  adduser3.118
ii  libmail-spf-perl   2.9.0-5
ii  libnetaddr-ip-perl 4.079+dfsg-1+b5
ii  libsys-hostname-long-perl  1.5-2
ii  perl [libversion-perl] 5.32.1-4
ii  postfix3.5.6-1+b1

postfix-policyd-spf-perl recommends no packages.

postfix-policyd-spf-perl suggests no packages.

-- no debconf information

Bug#989462: set Vagrant box filesystem size to something much larger than 20GB

[Emmanuel Kasper]

Hi Hans

I had a look at the fai-disk-image, and it seems that nothing in the 
toolchain prevents us from using a disk image with a larger virtual size 
for VirtualBox *and* libvirt,

as currently:
- we create a sparse file of raw format using fai-disk-image
- then we convert this disk image to a thin provisioned vmdk/qcow2
vmdk in virtualbox 6 do support thin provisioned disk images, the 20GB 
current vagrant boxes uses 1.4 GB on my hard drive


So the next for you to do would be:
- bump the disk size in 
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/blob/master/src/debian_cloud_images/cli/build.py#L179

and following

- create a pull request, so that it triggers a build and let's see if 
this passes the test suite


In a distinct, separate step, we should probably review the settings we 
use when creating the qcow2 image in

https://salsa.debian.org/cloud-team/debian-vagrant-images/-/blob/master/utils/vagrant/libvirt/create-vagrant-libvirt-box#L18

to see if if we could make use of the recommended settings mentioned at
https://www.jamescoyle.net/how-to/2060-qcow2-physical-size-with-different-preallocation-settings 
for performance


Do you know any caveats of working with a larger filesystem, let's say 
we would use a 512GB disk image. Slower fsck on boot in case of crash ?

Bug#989539: apt upgrade reports "possibly missing firmware" causing undue concern.

[David Kalnischkies]

Control: reassign -1 initramfs-tools-core

Hi,

On Sun, Jun 06, 2021 at 06:00:52PM -0400, ? wrote:
> This is a known issue that when users perform an apt-upgrade that
> upgrades system/kernel components.
> 
> Actual Result: "Possibly missing firmware ..."  E.g. i915
> Expected Result: No messages that firmware may be missing.

I don't know if more than it already checks is technically possible or
if your suggestion would help (I don't have the slightest idea from
which year the hardware is I am using or the exact model name without
looking it up, so adding that info would confuse me just as much if not
more I guess…).

In either case apt has and can not do anything about it. It is output
produced by one of the packages which are installed/upgraded. In this
case a codesearch over Debian suggests one of the methods from
/usr/share/initramfs-tools/hook-functions which is contained in
initramfs-tools-core.

I am therefore reassign this bug to them.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#989545: libgl1-mesa-dri: si_texture.c:1727 si_texture_transfer_map - failed to create temporary texture to hold untiled copy

[Rubin Simons]

Package: libgl1-mesa-dri
Version: 20.3.4-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

I'm using a Radeon Vega Frontier Edition with a Talos Blackbird Power9 system 
(ppc64le). I'm constantly running into the issue mentioned here:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/4107

The above issue documents an issue in mesa caused by a bug in LLVM.

The issue manifests itself when using Firefox, or in Gnome, when clicking on 
the top-bar, which crashes gnome-shell. Any crash always logs the following:

EE ../src/gallium/drivers/radeonsi/si_texture.c:1727 si_texture_transfer_map - 
failed to create temporary texture to hold untiled copy
LLVM triggered Diagnostic Handler: Illegal instruction detected: VOP* 
instruction violates constant bus restriction
renamable $vgpr4 = V_CNDMASK_B32_e32 32768, killed $vgpr4, implicit killed 
$vcc, implicit $exec
LLVM failed to compile shader
radeonsi: can't compile a main shader part

It would be great if the resolution mentioned in the linked mesa issue #4107 
could be applied (I think this would require recompilation with an LLVM that 
has said fix and/or a more general update of the LLVM runtime?). What I 
understand from the upstream report is that the issue is not isolated to 
non-x86 platforms, so I would imagine any Debian Bullseye user with a Vega 
based Radeon would be impacted.

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

   * What led up to the situation?
 - Install Debian Bullseye + gnome-core on a Radeon Vega based system.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 - Click on Gnome top-bar after login. Watch X crash. Maximize any window. 
Watch X crash.
   * What was the outcome of this action? 
 - Frequent X crashes, graphics drawing corruption in Firefox. Above log 
message appears frequently in logs.
   * What outcome did you expect instead?
 - A working system!

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


VGA-compatible devices on PCI bus:
--
:03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Vega 10 XTX [Radeon Vega Frontier Edition] [1002:6863]
0005:02:00.0 VGA compatible controller [0300]: ASPEED Technology, Inc. ASPEED 
Graphics Family [1a03:2000] (rev 41)

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 639 Jun  3 14:56 00-devices.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.10.0-7-powerpc64le (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.40-1 (2021-05-28)

No Xorg X server log files found.

udev information:
-
P: 
/devices/pci:00/:00:00.0/:01:00.0/:02:00.0/:03:00.1/sound/card0/input10
L: 0
E: 
DEVPATH=/devices/pci:00/:00:00.0/:01:00.0/:02:00.0/:03:00.1/sound/card0/input10
E: SUBSYSTEM=input
E: PRODUCT=0/0/0/0
E: NAME="HDA ATI HDMI HDMI/DP,pcm=11"
E: PHYS="ALSA"
E: PROP=0
E: EV=21
E: SW=140
E: MODALIAS=input:bvpe-e0,5,kramlsfw6,8,
E: USEC_INITIALIZED=5707489
E: ID_INPUT=1
E: ID_INPUT_SWITCH=1
E: ID_PATH=pci-:03:00.1
E: ID_PATH_TAG=pci-_03_00_1
E: ID_FOR_SEAT=input-pci-_03_00_1
E: TAGS=:seat:
E: CURRENT_TAGS=:seat:

P: 
/devices/pci:00/:00:00.0/:01:00.0/:02:00.0/:03:00.1/sound/card0/input10/event10
N: input/event10
L: 0
E: 
DEVPATH=/devices/pci:00/:00:00.0/:01:00.0/:02:00.0/:03:00.1/sound/card0/input10/event10
E: SUBSYSTEM=input
E: DEVNAME=/dev/input/event10
E: MAJOR=13
E: MINOR=74
E: USEC_INITIALIZED=5864423
E: ID_INPUT=1
E: ID_INPUT_SWITCH=1
E: ID_PATH=pci-:03:00.1
E: ID_PATH_TAG=pci-_03_00_1
E: LIBINPUT_DEVICE_GROUP=0/0/0:ALSA
E: TAGS=:power-switch:
E: CURRENT_TAGS=:power-switch:

P: 
/devices/pci:00/:00:00.0/:01:00.0/:02:00.0/:03:00.1/sound/card0/input5
L: 0
E: 
DEVPATH=/devices/pci:00/:00:00.0/:01:00.0/:02:00.0/:03:00.1/sound/card0/input5
E: SUBSYSTEM=input
E: PRODUCT=0/0/0/0
E: NAME="HDA ATI HDMI HDMI/DP,pcm=3"
E: PHYS="ALSA"
E: PROP=0
E: EV=21
E: SW=140
E: MODALIAS=input:bvpe-e0,5,kramlsfw6,8,
E: USEC_INITIALIZED=5707853
E: ID_INPUT=1
E: ID_INPUT_SWITCH=1
E: ID_PATH=pci-:03:00.1
E: ID_PATH_TAG=pci-_03_00_1
E: ID_FOR_SEAT=input-pci-_03_00_1
E: TAGS=:seat:
E: CURRENT_TAGS=:seat:

P: 
/devices/pci:00/:00:00.0/:01:00.0/:02:00.0/:03:00.1/sound/card0/input5/event5
N: input/event5
L: 0
E: 
DEVPATH=/devices/pci:00/:00:00.0/:01:00.0/:02:00.0/:03:00.1/sound/card0/input5/event5
E: SUBSYSTEM=input
E: DEVNAME=/dev/input/event5
E: MAJOR=13
E: MINOR=69
E: USEC_INITIALIZED=5863358
E: ID_INPUT=1
E: ID_INPUT_SWITCH=1
E: ID_PATH=pci-:03:00.1
E: 

Bug#989472: mirror submission for mirror.estone.ca

[Peter Palfrader]

On Fri, 04 Jun 2021, Mike Egglestone wrote:

> Submission-Type: new
> Site: mirror.estone.ca
> Type: leaf
> Archive-architecture: amd64
> Archive-http: /debian/
> Maintainer: Mike Egglestone 
> Country: CA Canada
> Location: Prince George BC

Added to our list, thanks.

Please note that we recommend mirrors not sync directly from service aliases
such as ftp..debian.org (only http is guaranteed to be available at
ftp..d.o sites).  Maybe change your config to sync from the site currently
backing the ftp..debian.org service you sync from?

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/