Bug#991867: Lamobo_R1

[Geert Stappers]

On Wed, Aug 04, 2021 at 01:51:49PM +1200, Nevyn wrote:
> 
> U-Boot works but loading kernel results in a blank screen (with cursor in
> top left corner).

And what happens on the serial port?




Regards
Geert Stappers
Has a R1, never used the HDMI port

Bug#991869: release-notes: Document default change for unprivileged calls to bpf()

[Salvatore Bonaccorso]

Package: release-notes
Severity: normal
X-Debbugs-Cc: car...@debian.org,debian-ker...@lists.debian.org

Hi

There is no pressure on including this but it might be worth
documetning the default change for unprivileged calls to bpf() to be
disabled in the release notes for Debian 11 (bullseye).

Attached is a corresponding patch proposal for the wording.

Regards,
Salvatore
>From d120af71a5a1bc590511a193b7ae790febc38c5c Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Wed, 4 Aug 2021 07:02:08 +0200
Subject: [PATCH] Document default change for unprivileged calls to bpf()

Starting in src:linux 5.10.46-4 Linux disables unprivileged calls to
bpf() by default. Document the fact in the release notes and explain on
how to revert to keep unprivileged calls to bpf() enabled.

Reference the Debian bug asking for implementing the change as
additional hardening for BPF related security issues.

Signed-off-by: Salvatore Bonaccorso 
---
 en/issues.dbk | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index f708c325c6a3..29221aba56e9 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -322,6 +322,28 @@ user.max_user_namespaces = 0
   
 
 
+
+  Linux disables unprivileged calls to bpf() by default
+  
+From Linux 5.10, Debian disables unprivileged
+calls to bpf() by default. However, an admin can still change this
+setting later on, if needed, by writing 0 or 1 to the
+kernel.unprivileged_bpf_disabled sysctl.
+  
+  
+If you prefer to keep unprivileged calls to bpf() enabled, set
+the sysctl:
+  
+  
+kernel.unprivileged_bpf_disabled = 0
+  
+  
+For background on the change as default in Debian see
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990411;>
+the change request.
+  
+
+
 
   
   redmine missing in bullseye
-- 
2.32.0

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Ron]

On Tue, Aug 03, 2021 at 10:08:42PM +0200, Aurelien Jarno wrote:
> On 2021-08-01 00:05, Ron wrote:
> > 
> > Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> > Preparing to unpack .../openssh-client_1%3a8.4p1-5_amd64.deb ...
> > Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> > Preparing to unpack .../runit-helper_2.10.3_all.deb ...
> > Unpacking runit-helper (2.10.3) ...
> > Preparing to unpack .../openssh-server_1%3a8.4p1-5_amd64.deb ...
> > Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> > Preparing to unpack .../libc6_2.31-13_amd64.deb ...
> > Checking for services that may need to be restarted...
> > Checking init scripts...
> > Unpacking libc6:amd64 (2.31-13) over (2.28-10) ...
> > Setting up libc6:amd64 (2.31-13) ...
> > Checking for services that may need to be restarted...
> > Checking init scripts...
> > Services to restart for GNU libc library upgrade:
> > cron atd
> > Restarting services possibly affected by the upgrade:
> >   cron: restarting...done.
> >   atd: restarting...done.
> > Services restarted successfully.
> > Preparing to unpack .../libc-bin_2.31-13_amd64.deb ...
> > Unpacking libc-bin (2.31-13) over (2.28-10) ...
> > Setting up libc-bin (2.31-13) ...
> >  ...
> >  
> >  ...
> > Setting up openssh-server (1:8.4p1-5) ...
> 
> Thanks for this upgrade log, with it I have been able to understand and
> reproduce the issue. The libc restart logic looks for installed
> packaged, however due to all the breaks and depends between
> openssh-server and libc6 in the buster -> bullseye upgrade path, it
> could happen that at the moment the libc6 postinst script is ran, the
> openssh-server has been degraded from installed to unpacked.
> 
> I have tested the following fix, which works well when used in the same
> conditions as the above log:
> 
> diff --git a/debian/script.in/nsscheck.sh b/debian/script.in/nsscheck.sh
> index 8406a543..ee99ac16 100644
> --- a/debian/script.in/nsscheck.sh
> +++ b/debian/script.in/nsscheck.sh
> @@ -1,8 +1,8 @@
>   echo -n "Checking for services that may need to be restarted..."
>   # Only get the ones that are installed, of the same architecture
>   # as libc (or arch all) and configured
> - check=$(dpkg-query -W -f='${binary:Package} ${Status} 
> ${Architecture}\n' $check 2> /dev/null | \
> - grep -E "installed (all|${DPKG_MAINTSCRIPT_ARCH})$" | 
> sed 's/[: ].*//')
> + check=$(dpkg-query -W -f='${binary:Package} ${db:Status-Want} 
> ${Architecture}\n' $check 2> /dev/null | \
> + grep -E "(install|hold) 
> (all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//')
>   # some init scripts don't match the package names
>   check=$(echo $check | \
>   sed -e's/\bapache2.2-common\b/apache2/g' \
> 
> However before uploading such a fix so close to the release, I think it
> requires a review by many more pair of eyes.

Again flying blind to a lot of important details -- but what happens if
libc postinst tries to restart a service that is unpacked but not yet
configured?

I'm guessing that depends a lot on what the service post* do, but how
horrible could that get?  Does this really need to be a trigger that
(also?) restarts each of the half-installed services after they are
fully (re)configured again?

I was able to restart ssh manually during the upgrade, but by the time I
figured out that was what was needed, the install was probably far enough
through that it had likely been configured and was fully installed again ...

  Cheers,
  Ron

Bug#991868: linux-image.NEWS entry not installed into/available in binary packages doc directory

[Salvatore Bonaccorso]

Source: linux
Version: 5.10.46-4
Severity: normal
X-Debbugs-Cc: car...@debian.org

The linux-image.NEWS file which we intend to provide in the
linux-image packages is not correctly installed.

>From Ben: We would to revert 70af1a4e805ba7f355fb69b3a041b3fdb9b977dd
(at least for image (meta-)packages).

Regards,
Salvatore

Bug#990283: openvpn: Upgrades break systemd supervision

[Daniel Gnoutcheff]

Hello Jörg, thanks for the reply.


Was the computer rebooted after the update?


It was not.  Rebooting fixes the issue, as does manually kill(1)ing the
errant openvpn instances and restarting the systemd unit(s).

Sorry, "Upgrades break systemd supervision" was perhaps not the best
summary.  It's more like "Upgrades restart openvpn outside of
systemd".


I have checked your bug report on every server I have access to.

Likewise, I have checked the problem in multiple VMs. The error was not
reproducible there either.


This worked for me on a fresh amd64 buster VM:

  echo "deb http://snapshot.debian.org/archive/debian/20210601T022916Z/ buster 
main" >/etc/apt/sources.list.d/snapshot.list
  apt update
  apt install openvpn=2.4.7-1 ssl-cert

  # placeholder config
  zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz 
>/etc/openvpn/server.conf
  ln -s /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/openvpn/server.crt
  ln -s /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/openvpn/ca.crt
  ln -s /etc/ssl/private/ssl-cert-snakeoil.key /etc/openvpn/server.key
  openssl dhparam -out /etc/openvpn/dh2048.pem 2048
  openvpn --genkey --secret /etc/openvpn/ta.key

  systemctl start openvpn@server
  
  apt install unattended-upgrades

  systemctl start apt-daily-upgrade
  systemctl status
  # Observe: openvpn process is now in apt-daily-upgrade.service
  systemctl start apt-daily-upgrade  # (a second time)
  # systemd now warns about the lingering process

Alternatively, replace 'apt install unattended-upgrades' and everything
thereafter with:

  apt upgrade
  systemctl status

Which should show the openvpn daemon lingering in whatever scope unit
contains your shell.

Or, simpler still:

  invoke-rc.d openvpn cond-restart

which is invoked by openvpn's postinst and has much the same effect.


Can you please provide the complete update logs?


Attached are extracts of of `journalctl --output=with-unit` and
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log after having
done the above.  HTH!

Thanks,
--
Daniel Gnoutcheff
Systems Administrator
Software Freedom Law Center
-- Logs begin at Tue 2021-08-03 17:57:06 EDT. --
Tue 2021-08-03 17:59:18 EDT bug4 session-4.scope[1238]: group added to /etc/group: name=ssl-cert, GID=112
Tue 2021-08-03 17:59:18 EDT bug4 session-4.scope[1238]: group added to /etc/gshadow: name=ssl-cert
Tue 2021-08-03 17:59:18 EDT bug4 session-4.scope[1238]: new group: name=ssl-cert, GID=112
Tue 2021-08-03 17:59:20 EDT bug4 init.scope[1]: Reloading.
Tue 2021-08-03 17:59:21 EDT bug4 init.scope[1]: Reloading.
Tue 2021-08-03 17:59:21 EDT bug4 init.scope[1]: Reloading.
Tue 2021-08-03 17:59:23 EDT bug4 init.scope[1]: Reloading.
Tue 2021-08-03 17:59:23 EDT bug4 init.scope[1]: Reloading.
Tue 2021-08-03 17:59:24 EDT bug4 init.scope[1]: Listening on PC/SC Smart Card Daemon Activation Socket.
Tue 2021-08-03 17:59:24 EDT bug4 init.scope[1]: Started PC/SC Smart Card Daemon.
Tue 2021-08-03 17:59:24 EDT bug4 init.scope[1]: Reloading.
Tue 2021-08-03 17:59:24 EDT bug4 init.scope[1]: Reloading.
Tue 2021-08-03 17:59:28 EDT bug4 init.scope[1]: Reloading.
-- Logs begin at Tue 2021-08-03 17:57:06 EDT. --
Tue 2021-08-03 18:02:47 EDT bug4 init.scope[1]: Created slice system-openvpn.slice.
Tue 2021-08-03 18:02:47 EDT bug4 init.scope[1]: Reached target Network is Online.
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: WARNING: file 'server.key' is group or others accessible
Tue 2021-08-03 18:02:47 EDT bug4 init.scope[1]: Starting OpenVPN connection to server...
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
Tue 2021-08-03 18:02:47 EDT bug4 init.scope[1]: Started OpenVPN connection to server.
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: Diffie-Hellman initialized with 2048 bit key
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: ROUTE_GATEWAY 10.179.201.1/255.255.255.0 IFACE=eth0 HWADDR=52:54:00:ec:b2:f5
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: TUN/TAP device tun0 opened
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: TUN/TAP TX queue length set to 100
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: /sbin/ip link set dev tun0 up mtu 1500
Tue 2021-08-03 18:02:47 EDT bug4 kernel: tun: Universal TUN/TAP device driver, 1.6
Tue 2021-08-03 18:02:47 EDT bug4 openvpn@server.service[1667]: /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Tue 

Bug#989560: Bug #989560 is grub-common, not xen-hypervisor-common

[Elliott Mitchell]

I rate #989560 as a grub-common bug, *not* a xen-hypervisor-common bug.
As you've noticed, the problem is with the file /etc/grub.d/20_linux_xen,
which is part of grub-common, not xen-hypervisor-common.

A working grub.cfg will be generated by the version of the file from
GRUB 2.04.  If you can deal with installing *only* GRUB from testing,
that should work.

The bug should be reassigned to grub-common, but marked as effecting
Xen so duplicate reports don't show up (actually I'm pretty sure reports
against grub-common or src:grub2 already exist).


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#991867: Lamobo_R1

[Nevyn]

Package: installation-reports

Boot method: SDCard (https://wiki.debian.org/InstallingDebianOn/Allwinner)
Image version:

https://deb.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/firmware.Lamobo_R1.img.gz

https://deb.debian.org/debian/dists/stable/main/installer-armhf/current/images/netboot/SD-card-images/partition.img.gz
Date: 2021-08-04, 12pm (

Machine: Lamobo_R1
Processor: A20
Memory: 1GB
Partitions: N/A

Output of lspci -knn (or lspci -nn): N/A

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[ ]
Configure network:  [ ]
Detect media:   [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

U-Boot works but loading kernel results in a blank screen (with cursor in
top left corner).
Downloaded files described in Image Version: above, used:
  zcat firmware.Lamobo_R1.img.gz partition.img.gz > /dev/mmcblk0
to write to SD Card. Inserted into Lamobo R1 (Banana Pi R1) and booted.
Last message is "Loading kernel".
Also tried with daily builds but the files appear to be corrupted (I
uncompressed and ran "fdisk -l" on each of the files and got no results).

Bug#991845: unblock: libx11/2:1.7.2-1

[Cyril Brulebois]

Hi,

Paul Gevers  (2021-08-03):
> The item below needs your ack.
> 
> Paul
> 
> On 03-08-2021 10:54, Timo Aaltonen wrote:
> > Please unblock package libx11
> > 
> > [ Reason ]
> > The new upstream release fixes regressions in the previous CVE
> > release, including a segfault in fdesign. (bug 990998)
> > 
> > [ Impact ]
> > Regressions remain in bullseye release.
> > 
> > [ Tests ]
> > The new version has a commit that fixes a bug with a similar
> > backtrace as 990998, Matt can verify here that fdesign works with
> > the new libx11.
> > 
> > [ Risks ]
> > The upstream changes are small, only three commits, 
> > 
> > [ 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 ]
> > The diff is filtered to have only changes to the code and packaging,
> > autotools changes are removed.
> > 
> > unblock libx11/2:1.7.2-1

ACK on principle; I can't perform runtime tests right away, but as we
aren't in a hurry to build a new d-i anyway, we could live with some
regression — should that happen! — until it's time to upload. Right now,
I'm hoping the next d-i upload is going to be for 11.1.


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


signature.asc
Description: PGP signature

Bug#991856: debian-security-support: Unix username *way* too long

[Thorsten Glaser]

Holger Levsen dixit:

>too wide for what?

For reasonable terminals (~80-100 columns).

>> Unix usernames are supposed to be up to 8 characters
>
>says who? (besides you obviously :) and then GNU's not unix ;)

The person who was pissed off by getting a shell account on
a GNU/Linux box “mirabilo”…

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#991854: dmidecode

[Jessica Clarke]

On 4 Aug 2021, at 00:11, Paul Wise  wrote:
> 
> On Tue, 2021-08-03 at 23:51 +0100, Jessica Clarke wrote:
> 
>> I’m unaware of any systems that provide it. The whole EDK2+ACPI+SMBIOS
>> ecosystem remains rather far off for RISC-V at this point
> 
> Is it an option for virtual machines with qemu yet?

No; for some strange reason the old HiFive Unleashed was the primary
target for EDK2, not QEMU’s virt machine, the thing that the vast
majority of people are/should be using. Last I checked basically none
of even that was upstream and what was upstream was a bit dodgy.

I haven’t even seen patches floating around for anything ACPI on any
RISC-V platform, not even QEMU. The next generation of interrupt
controllers, AIA (“Advanced Interrupt Architecture”) remains a draft
spec that’s being iterated on, so even if support for that were
upstream in QEMU (which it is not, just in a fork), the only stable
interrupt controller option would be impossible to support with ACPI.
As for SMBIOS the only thing I’ve seen is talk that it should exist and
outlining what they believe it should include, but don’t believe it’s
proven technology yet.

>> nor worth Ubuntu carrying a patch for.
> 
> Heinrich, could you describe Canonical's interest in riscv64 dmidecode?
> 
>> dmidecode ... atrocious software engineering practice
> 
> Hopefully someone will file a bug/patch about this upstream.

If I had time to spare I’d just write the patches myself to use C99
uintX_t and to always do byte-by-byte accesses, letting the compiler
optimise it to the unaligned word access (with possible byte reverse
for big-endian) when possible, as that’s completely portable code with
no #ifdef’s needed. But I have better things to be doing with my time,
sadly (or maybe fortunately?)…

Jess

> I note there are some alternative implementations:
> 
>https://nongnu.org/dmidecode/ (scroll down)
> 
> libsmbios is already in Debian but only available on x86.
> 
> The Rust based smbios-lib/dmidecode-rs are not in Debian.
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

Bug#991854: dmidecode

[Paul Wise]

On Tue, 2021-08-03 at 23:51 +0100, Jessica Clarke wrote:

> I’m unaware of any systems that provide it. The whole EDK2+ACPI+SMBIOS
> ecosystem remains rather far off for RISC-V at this point

Is it an option for virtual machines with qemu yet?

> nor worth Ubuntu carrying a patch for.

Heinrich, could you describe Canonical's interest in riscv64 dmidecode?

> dmidecode ... atrocious software engineering practice

Hopefully someone will file a bug/patch about this upstream.

I note there are some alternative implementations:

   https://nongnu.org/dmidecode/ (scroll down)

libsmbios is already in Debian but only available on x86.

The Rust based smbios-lib/dmidecode-rs are not in Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#991854: dmidecode

[Jessica Clarke]

On 3 Aug 2021, at 23:42, Paul Wise  wrote:
> 
> On Tue, 03 Aug 2021 20:14:57 +0200 Jörg Frings-Fürst wrote:
> 
>> because of the bugreport[1] I would like to ask here if it is useful to
>> compile dmidecode also for riscv64?
> 
> Apparently the SMBIOS spec v3.3.0 and later includes RISC-V support:
> 
> https://github.com/riscv/riscv-smbios/blob/master/RISCV-SMBIOS.md
> 
> I've no idea if dmidecode meaningfully works on RISC-V hardware though?

I’m unaware of any systems that provide it. The whole EDK2+ACPI+SMBIOS
ecosystem remains rather far off for RISC-V at this point, especially
given ACPI will only include bindings for the future generation of
interrupt controllers and thus will never be supported for the current
generation of hardware. If it compiles then it might as well be
enabled, but this hardly seems essential, nor worth Ubuntu carrying a
patch for.

Looking at dmidecode itself, the primary reason it shouldn’t be
Architecture: any is it assumes unaligned access and little-endianness
by default unless you put -DALIGNMENT_WORKAROUND/-DBIGENDIAN in CFLAGS
manually, which is atrocious software engineering practice in many
respects... and for added fun it defines its own u64 type as a struct
containing a pair of u32’s (also manually typedef’ed to unsigned int)
whose order depends on BIGENDIAN.

Jess

Bug#991854: dmidecode

[Paul Wise]

On Tue, 03 Aug 2021 20:14:57 +0200 Jörg Frings-Fürst wrote:

> because of the bugreport[1] I would like to ask here if it is useful to
> compile dmidecode also for riscv64?

Apparently the SMBIOS spec v3.3.0 and later includes RISC-V support:

https://github.com/riscv/riscv-smbios/blob/master/RISCV-SMBIOS.md

I've no idea if dmidecode meaningfully works on RISC-V hardware though?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#991866: ITP: osicat -- lightweight operating system interface for Common Lisp on POSIX-like systems

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-common-l...@lists.debian.org

* Package name: osicat
  Version : 0.7.0+git20210221.e635611
  Upstream Author : Nikodemus Siivola and contributors
* URL : https://github.com/osicat/osicat
* License : Expat
  Programming Lang: Common Lisp
  Description : lightweight operating system interface for Common Lisp on 
POSIX-like systems

This is an upcoming dependency for Consfigurator; I would like access to
stat(2), in particular.  I intend to maintain this as part of the Common
Lisp team.

-- 
Sean Whitton

Bug#991627: installation-guide: expand firmware-related documentation

[Holger Wansing]

Hi,

Am 3. August 2021 01:55:06 MESZ schrieb Cyril Brulebois :
>Petter Reinholdtsen  (2021-08-02):
>> I had a look at the 6.4 section about isenkram, and it looked good to
>> me.
>
>Thanks for your feedback!

I tested this today on my T60, and it works great: it detected missing 
firmware for my realtek network card and installed it without problems.
So a confirmation, that the isenkram thing works here, too.

(Some months ago, I played around with isenkram a bit, and that did not
work that well, so I wanted to do some testing now.)


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#991856: debian-security-support: Unix username *way* too long

[Holger Levsen]

On Tue, Aug 03, 2021 at 10:10:58PM +, Holger Levsen wrote:
> > (in fact, some
> > environments fail if they are longer, silently truncate them, or
> > otherwise explode). This is… untenable.
> "untenable" (which means indefensible AIUI) is plain wrong

(because reasons I gave in that very mail) and
unless of course you 'show explosions' in Debian (due to this)...


-- 
cheers,
Holger

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

Dat gifft in Plattdüütschen keen Woort för „Flüchtlinge”. Dat sünd allens Lüüd, 
Mischen, Kinners, Olle, Froons, Mannslüüd, so as Du un Ick.


signature.asc
Description: PGP signature

Bug#991856: debian-security-support: Unix username *way* too long

[Holger Levsen]

control: severity -1 wishlist
# or minor, not sure..
thanks

Hi Thorsten,

thank you for flying debian-security-support and filing bugs!

On Tue, Aug 03, 2021 at 05:47:24PM +0200, Thorsten Glaser wrote:
> Colour my surprise when I did an “ls -l /var/lib” and saw:
> […]
> drwxr-xr-x  3 rootroot 4096 Oct  1  
> 2019 ucf/
> drwxr-xr-x  2 rootroot 4096 Jul  6  
> 2012 update-rc.d/
> drwxr-xr-x  2 rootroot 4096 Sep  7  
> 2012 urandom/
> drwxr-xr-x  3 rootroot 4096 Feb  7  
> 2007 vim/
> drwxr-xr-x  2 rootroot 4096 Feb 17  
> 2020 xfonts/
> drwxr-xr-x  2 rootroot 4096 Dec 17  
> 2015 xml-core/

I share your surprise... (and I joined maintenance of the package long after
this has been implemented the way it is.)
 
> That’s *massively* too wide. Scrolling up revealed the culprit:

too wide for what? and maybe rather: if that's a problem, why not use ls -ln 
/var/lib?
'ls -l' is not ment to be parsable...

also:

$ tput cols
295
$ tput cols
81
$ tput cols
128

(all on different terminals I have currently running here...)

> drwxr-xr-x  2 debian-security-support debian-security-support  4096 Feb 17  
> 2020 debian-security-support/
> 
> Unix usernames are supposed to be up to 8 characters

says who? (besides you obviously :) and then GNU's not unix ;) 

> (in fact, some
> environments fail if they are longer, silently truncate them, or
> otherwise explode). This is… untenable.

"untenable" (which means indefensible AIUI) is plain wrong, because...
 
> Please change this. Thanks!

change has a cost, you know :)

So why and how exactly should this be changed, what would be your migration
proposal and could you maybe be so kind and provide patches?

I'm not totally opposed to the idea, but I don't see how we can sensibly
fix installed systems as removing users is a no-go and I believe renaming
them is also a bad idea. Which leaves adding another user (for existing
installs) and then probably changing ownership for the existing files -
all actions where I see potential problems for little benefit.

Maybe/probably you could convince me by providing an migration plan and patches 
*and* the offer to help fixing potenial fallout...(!)

I definitly don't have a hard stance on this, I just don't share the
pain/problem and I see problems on the road for little benefit to me.


-- 
cheers,
Holger

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

There are only two kinds of nazis: stupid ones and those without an excuse.
(Volker Strübing)


signature.asc
Description: PGP signature

Bug#991865: unblock: openjdk-11-jre-dcevm/11.0.12+7-1

[Emmanuel Bourg]

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

Please unblock package openjdk-11-jre-dcevm

openjdk-11-jre-dcevm is a patched OpenJDK VM with extra debugging features
for developers, it's tighly tied to the openjdk-11 package and often has
to follow the major updates. The openjdk-11/11.0.12+7-2 upload last week
broke openjdk-11-jre-dcevm (#991006), this was fixed with the upload of
openjdk-11-jre-dcevm/11.0.12+7-1 for which I'd like to request an unblock.

Besides rebasing on top of OpenJDK 11.0.12+7, the DCEVM update has no other
changes compared to the previous version 11.0.11+9. I'm adding below the diff
between the DCEVM changes for OpenJDK 11.0.11 and 11.0.12, only the hunk headers
changed, not the content.

Thank you,

Emmanuel Bourg



$ diff dcevm-11.0.11+9.patch dcevm-11.0.12+7.patch
1,8d0
< diff --git a/AdoptOpenJDK.md b/AdoptOpenJDK.md
< new file mode 100644
< index 00..88a0a38ee8
< --- /dev/null
< +++ b/AdoptOpenJDK.md
< @@ -0,0 +1,2 @@
< +AdoptOpenJDK marker file
< +
93c85
< index b9440902d3..111610cb25 100644
---
> index 12a95c5948..ab880836ec 100644
123c115
< index bc2561fb09..9a2d66bdd5 100644
---
> index 211c2acda2..88ccb82937 100644
126c118
< @@ -3784,6 +3784,10 @@ bool GraphBuilder::try_inline_full(ciMethod* callee, 
bool holder_known, bool ign
---
> @@ -3783,6 +3783,10 @@ bool GraphBuilder::try_inline_full(ciMethod* callee, 
> bool holder_known, bool ign
282c274
< index 6d65cca210..7158fdb77d 100644
---
> index 154dab55e4..59dcd44724 100644
413c405
< index f0cf1fb7cb..5713bb9e98 100644
---
> index 03954f5215..c2c8348f74 100644
416c408
< @@ -1501,6 +1501,7 @@ InstanceKlass* ClassLoader::load_class(Symbol* name, 
bool search_append_only, TR
---
> @@ -1498,6 +1498,7 @@ InstanceKlass* ClassLoader::load_class(Symbol* name, 
> bool search_append_only, TR
425c417
< index c58026ae19..f319cca3b2 100644
---
> index 21f8b67d13..e451f5407c 100644
697c689
< index 3ac1ca69ae..6c072407fd 100644
---
> index b949bac8de..a1baaef86f 100644
1223c1215
< index bfd67334f8..3368b74217 100644
---
> index 4509025cf7..1ef4ffc0a2 100644
1346c1338
< @@ -1372,6 +1395,10 @@ InstanceKlass* 
SystemDictionary::load_shared_class(InstanceKlass* ik,
---
> @@ -1374,6 +1397,10 @@ InstanceKlass* 
> SystemDictionary::load_shared_class(InstanceKlass* ik,
1357c1349
< @@ -1553,11 +1580,12 @@ static void post_class_define_event(InstanceKlass* k, 
const ClassLoaderData* def
---
> @@ -1555,11 +1582,12 @@ static void post_class_define_event(InstanceKlass* k, 
> const ClassLoaderData* def
1371c1363
< @@ -1582,7 +1610,13 @@ void 
SystemDictionary::define_instance_class(InstanceKlass* k, TRAPS) {
---
> @@ -1584,7 +1612,13 @@ void 
> SystemDictionary::define_instance_class(InstanceKlass* k, TRAPS) {
1386c1378
< @@ -1616,7 +1650,7 @@ void 
SystemDictionary::define_instance_class(InstanceKlass* k, TRAPS) {
---
> @@ -1618,7 +1652,7 @@ void 
> SystemDictionary::define_instance_class(InstanceKlass* k, TRAPS) {
1395c1387
< @@ -1694,7 +1728,7 @@ InstanceKlass* 
SystemDictionary::find_or_define_instance_class(Symbol* class_nam
---
> @@ -1696,7 +1730,7 @@ InstanceKlass* 
> SystemDictionary::find_or_define_instance_class(Symbol* class_nam
1404c1396
< @@ -1817,6 +1851,19 @@ void SystemDictionary::add_to_hierarchy(InstanceKlass* 
k, TRAPS) {
---
> @@ -1819,6 +1853,19 @@ void SystemDictionary::add_to_hierarchy(InstanceKlass* 
> k, TRAPS) {
1424c1416
< @@ -1941,6 +1988,16 @@ bool SystemDictionary::is_well_known_klass(Symbol* 
class_name) {
---
> @@ -1943,6 +1990,16 @@ bool SystemDictionary::is_well_known_klass(Symbol* 
> class_name) {
1441c1433
< @@ -2113,7 +2170,7 @@ void SystemDictionary::check_constraints(unsigned int 
d_hash,
---
> @@ -2115,7 +2172,7 @@ void SystemDictionary::check_constraints(unsigned int 
> d_hash,
1451c1443
< index 649b321a6a..4220978a02 100644
---
> index a14728df75..aba2780a32 100644
1463c1455
< @@ -302,6 +304,7 @@ public:
---
> @@ -305,6 +307,7 @@ public:
1471c1463
< @@ -310,6 +313,7 @@ public:
---
> @@ -313,6 +316,7 @@ public:
1479c1471
< @@ -318,6 +322,7 @@ public:
---
> @@ -321,6 +325,7 @@ public:
1487c1479
< @@ -462,6 +467,12 @@ public:
---
> @@ -465,6 +470,12 @@ public:
1500c1492
< @@ -655,7 +666,7 @@ protected:
---
> @@ -658,7 +669,7 @@ protected:
1548c1540
< index 8955dd0b36..daaa8d1237 100644
---
> index cef3f530cb..3477a408cb 100644
1551c1543
< @@ -286,6 +286,8 @@
---
> @@ -287,6 +287,8 @@
1560c1552
< @@ -340,6 +342,7 @@
---
> @@ -341,6 +343,7 @@
1568c1560
< @@ -352,6 +355,8 @@
---
> @@ -353,6 +356,8 @@
1577c1569
< @@ -446,6 +451,12 @@
---
> @@ -447,6 +452,12 @@
1604c1596
< index 7838d24677..26d6cd1bc6 100644
---
> index 65eb05efd4..6b7d2aad07 100644
1626c1618
< @@ -55,6 +61,7 @@ void CompiledMethod::init_defaults() {
---
> @@ -62,6 +68,7 @@ void CompiledMethod::init_defaults() {
1635c1627
< index 1dd185dc53..935c295485 100644
---
> index 75ca840bea..725895bdda 100644
1659c1651
< index 60aa462604..bc39e147f2 100644
---
> index 

Bug#991839: [debian-mysql] Bug#991839: mariadb-server-10.3: MariaDB intermittantly not starting on boot on AWS EC2 t2.medium instance

[Daniel Black]

Jeremy,

You are correct in that this is due to one of the hardening directives
in the service file Protect{Home,System} or PrivateDevices that is
trying to be applied before the kernel/system has completed the
underlying mounts on which they depend.

Without these hardening directives, and without
PermissionsStartOnly=true and all of the ExecStartPre= directives the
system is pretty secure as the mysqld/mariadbd process is run under
the non-privileged mysql user which ordinary cannot perform the
restricted items. Being a tiny VM I'm assuming this is the only
services there.

systemd-analyze dump (hint from
https://freedesktop.org/wiki/Software/systemd/Debugging/#reportingsystemdbugs-
Information to Attach to a Bug Report) may include some timing
information of services to verify. The logs since boot `journalctl -b`
might give enough information to see what ordering is happening at
boot.

kernel argument systemd.log_level=debug will include more information
in the mariadb.service journal `journalctl -u mariadb.service
--priority=7` such that the specific mount/system call might be able
to be identified. systemd.log_level=debug will probably make the
journalctl -b too verbose to read

Bug#991864: unblock: i2c-tools/4.2-2

[Aurelien Jarno]

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

Please unblock package i2c-tools

[ Reason ]
During the "transition" from Python 2 to Python 3, I forgot to update
the Suggests: entry from python-smbus to python3-smbus. As a consequence
apt suggests a non-existing package, and users do not get suggested to
install python3-smbus.

[ Impact ]
To be honest, if the unblock isn't granted, it is not the end of the
world, and I would totally understand if this bug is just closed.
However given a user bothered to report a bug (initially with severity
important), and that the changes are trivial, I am just giving it a try.

[ Tests ]
Only manual installation of the package has been done to test the
changes.

[ Risks ]
The risks are very very low, as the changes are trivial, do not concern
the shipped code but only the Suggests: entry, and given that apt does
not install suggested packages by default. 

[ 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 i2c-tools/4.2-2
diff -Nru i2c-tools-4.2/debian/changelog i2c-tools-4.2/debian/changelog
--- i2c-tools-4.2/debian/changelog  2020-10-14 18:01:27.0 +0200
+++ i2c-tools-4.2/debian/changelog  2021-07-24 15:17:41.0 +0200
@@ -1,3 +1,9 @@
+i2c-tools (4.2-2) unstable; urgency=medium
+
+  * Suggest python3-smbus instead of python-smbus (closes: #991010).
+
+ -- Aurelien Jarno   Sat, 24 Jul 2021 15:17:41 +0200
+
 i2c-tools (4.2-1) unstable; urgency=medium
 
   * New upstream version:
diff -Nru i2c-tools-4.2/debian/control i2c-tools-4.2/debian/control
--- i2c-tools-4.2/debian/control2020-10-14 18:00:59.0 +0200
+++ i2c-tools-4.2/debian/control2021-07-24 15:16:43.0 +0200
@@ -13,7 +13,7 @@
 Conflicts: lm-sensors (<< 1:3.0.0-1)
 Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}, adduser, udev
 Recommends: read-edid
-Suggests: libi2c-dev, python-smbus
+Suggests: libi2c-dev, python3-smbus
 Description: heterogeneous set of I2C tools for Linux
  This package contains a heterogeneous set of I2C tools for Linux: a bus
  probing tool, a chip dumper, register-level access helpers, EEPROM

Bug#991653: isoquery: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Dr. Tobias Quathamer]

Am 29.07.21 um 17:11 schrieb Lucas Nussbaum:
> Source: isoquery
> Version: 3.2.4-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210728 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in bullseye, your package failed to build
> on amd64.
> 
> This sounds like #963371.

Hi Lucas,

thanks for filing this bug. It's triggered by outdated test data, the
program is fully functional.

As Paul has already tagged this bug as "bullseye-ignore", I'm going to
fix this after the release of bullseye.

Regards,
Tobias



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991863: devscripts: uscan does not work when gpg signatures are enabled for git log

[Pirate Praveen]

Package: devscripts
Version: 2.21.3
Severity" important

With showSignature option added for git log,

$ cat ~/.gitconfig
# This is Git's per-user configuration file.
[log]
showSignature = true

uscan fails to create the orig.tar with correct name in git mode

version=4
opts="mode=git,pgpmode=none" \
https://github.com/blakeembrey/change-case.git HEAD

$ uscan --verbose
uscan info: uscan (version 2.21.3) See uscan(1) for help
uscan info: Scan watch files in .
find: File system loop detected; './node_modules/pascal-case' is part 
of the same file system loop as '.'.

uscan info: Check debian/watch and debian/changelog in .
uscan info: package="node-pascal-case" version="3.1.2-1" (as seen in 
debian/changelog)
uscan info: package="node-pascal-case" version="3.1.2" (no 
epoch/revision)
uscan info: ./debian/changelog sets package="node-pascal-case" 
version="3.1.2"

uscan info: Process watch file at: debian/watch
   package = node-pascal-case
   version = 3.1.2
   pkg_dir = .
uscan info: opts: mode=git,pgpmode=none
uscan info: line: https://github.com/blakeembrey/change-case.git HEAD
uscan info: Parsing mode=git
uscan info: Parsing pgpmode=none
uscan info: line: https://github.com/blakeembrey/change-case.git HEAD
uscan info: Last orig.tar.* tarball version (from debian/changelog): 
3.1.2

uscan info: Last orig.tar.* tarball version (dversionmangled): 3.1.2
uscan info: Looking at $base = 
https://github.com/blakeembrey/change-case.git with

   $filepattern = HEAD found
   $newfile = HEAD
   $newversion = gpg: Warning: using insecure memory!
gpg: Signature made Mon May 10 00:19:00 2021 UTC
gpg: using RSA key 4AEE18F83AFDEB23
gpg: Can't check signature: No public key
0.0~git20210510.c24a0e1
   $lastversion = 3.1.2
uscan info: Upstream URL(+tag) to download is identified as 
https://github.com/blakeembrey/change-case.git HEAD
uscan info: Filename (filenamemangled) for downloaded file: 
node-pascal-case-gpg: Warning: using insecure memory!

gpg: Signature made Mon May 10 00:19:00 2021 UTC
gpg: using RSA key 4AEE18F83AFDEB23
gpg: Can't check signature: No public key
0.0~git20210510.c24a0e1.tar.xz
uscan info: Newest version of node-pascal-case on remote site is gpg: 
Warning: using insecure memory!

gpg: Signature made Mon May 10 00:19:00 2021 UTC
gpg: using RSA key 4AEE18F83AFDEB23
gpg: Can't check signature: No public key
0.0~git20210510.c24a0e1, local version is 3.1.2
uscan info: => Only older package available from:
=> https://github.com/blakeembrey/change-case.git HEAD
uscan info: Removing git repo (../node-pascal-case-temporary.384.git)
uscan info: Scan finished

The filenames have the error messaages in them

$ ls ..
node-pascal-case-3.1.2
'node-pascal-case-gpg: Warning: using insecure memory!'$'\n''gpg: 
Signature made Mon May 10 00:19:00 2021 UTC'$'\n''gpg: using RSA key 
4AEE18F83AFDEB23'$'\n''gpg: Can'\''t check signature: No public 
key'$'\n''0.0~git20210510.c24a0e1.tar.xz'

node-pascal-case_3.1.2-1.debian.tar.xz
node-pascal-case_3.1.2-1.dsc
node-pascal-case_3.1.2.orig.tar.gz
'node-pascal-case_gpg: Warning: using insecure memory!'$'\n''gpg: 
Signature made Mon May 10 00:19:00 2021 UTC'$'\n''gpg: using RSA key 
4AEE18F83AFDEB23'$'\n''gpg: Can'\''t check signature: No public 
key'$'\n''0.0~git20210510.c24a0e1.orig.tar.xz'

node-pascal-case_itp.mail
pascal-case-3.1.2.tgz

after commenting out the line in .gitconfig, it works

$ uscan --verbose --force-download
uscan info: uscan (version 2.21.3) See uscan(1) for help
uscan info: Scan watch files in .
find: File system loop detected; './node_modules/pascal-case' is part 
of the same file system loop as '.'.

uscan info: Check debian/watch and debian/changelog in .
uscan info: package="node-pascal-case" version="3.1.2-1" (as seen in 
debian/changelog)
uscan info: package="node-pascal-case" version="3.1.2" (no 
epoch/revision)
uscan info: ./debian/changelog sets package="node-pascal-case" 
version="3.1.2"

uscan info: Process watch file at: debian/watch
   package = node-pascal-case
   version = 3.1.2
   pkg_dir = .
uscan info: opts: mode=git,pgpmode=none
uscan info: line: https://github.com/blakeembrey/change-case.git HEAD
uscan info: Parsing mode=git
uscan info: Parsing pgpmode=none
uscan info: line: https://github.com/blakeembrey/change-case.git HEAD
uscan info: Last orig.tar.* tarball version (from debian/changelog): 
3.1.2

uscan info: Last orig.tar.* tarball version (dversionmangled): 3.1.2
uscan info: Looking at $base = 
https://github.com/blakeembrey/change-case.git with

   $filepattern = HEAD found
   $newfile = HEAD
   $newversion = 0.0~git20210510.c24a0e1
   $lastversion = 3.1.2
uscan info: Upstream URL(+tag) to download is identified as 
https://github.com/blakeembrey/change-case.git HEAD
uscan info: Filename (filenamemangled) for downloaded file: 
node-pascal-case-0.0~git20210510.c24a0e1.tar.xz
uscan info: Newest version of node-pascal-case on remote site is 
0.0~git20210510.c24a0e1, local version is 3.1.2

uscan info: => Only 

Bug#991647: libisocodes: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Dr. Tobias Quathamer]

Am 29.07.21 um 17:13 schrieb Lucas Nussbaum:
> Source: libisocodes
> Version: 1.2.3-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210728 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in bullseye, your package failed to build
> on amd64.
> 
> See also #963371 and the bug I just filed against isoquery.

Hi Lucas,

thanks for filing this bug. Yes, those three bugs are all related and
occur due to outdated test data.

As Paul has already tagged this bug as "bullseye-ignore", I'm going to
fix this after the release of bullseye.

Regards,
Tobias



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Aurelien Jarno]

control: reopen 990069
control: found 990069 2.31-13
control: tag 990069 + patch

On 2021-08-01 00:05, Ron wrote:
> 
> Hi,
> 
> Sadly I can confirm this problem still persists in 2.31-13 too.  I found
> it (before I found this report of it) yesterday upgrading a fully up to
> date buster vm to bullseye ...
> 
> In my case I noticed it at the first conffile prompt when trying to ssh
> a new connection into the vm failed, which was after the first prompting
> from libc to restart services (and ssh was not included in the list of
> services to restart then).
> 
> I can confirm that manually restarting ssh (while the upgrade was still
> in progress) did fix it to enable logins again.
> 
> The interesting bit of the upgrade log is included below - I'm not sure
> offhand exactly how the libc restart logic is coded, but at first blush
> I'd note the new openssh-server is unpacked but not set up at the time
> the libc service restart takes place ...
> 
>   Cheers,
>   Ron
> 
> Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> Preparing to unpack .../openssh-client_1%3a8.4p1-5_amd64.deb ...
> Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> Preparing to unpack .../runit-helper_2.10.3_all.deb ...
> Unpacking runit-helper (2.10.3) ...
> Preparing to unpack .../openssh-server_1%3a8.4p1-5_amd64.deb ...
> Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
> Preparing to unpack .../libc6_2.31-13_amd64.deb ...
> Checking for services that may need to be restarted...
> Checking init scripts...
> Unpacking libc6:amd64 (2.31-13) over (2.28-10) ...
> Setting up libc6:amd64 (2.31-13) ...
> Checking for services that may need to be restarted...
> Checking init scripts...
> Services to restart for GNU libc library upgrade:
> cron atd
> Restarting services possibly affected by the upgrade:
>   cron: restarting...done.
>   atd: restarting...done.
> Services restarted successfully.
> Preparing to unpack .../libc-bin_2.31-13_amd64.deb ...
> Unpacking libc-bin (2.31-13) over (2.28-10) ...
> Setting up libc-bin (2.31-13) ...
>  ...
>  
>  ...
> Setting up openssh-server (1:8.4p1-5) ...

Thanks for this upgrade log, with it I have been able to understand and
reproduce the issue. The libc restart logic looks for installed
packaged, however due to all the breaks and depends between
openssh-server and libc6 in the buster -> bullseye upgrade path, it
could happen that at the moment the libc6 postinst script is ran, the
openssh-server has been degraded from installed to unpacked.

I have tested the following fix, which works well when used in the same
conditions as the above log:

diff --git a/debian/script.in/nsscheck.sh b/debian/script.in/nsscheck.sh
index 8406a543..ee99ac16 100644
--- a/debian/script.in/nsscheck.sh
+++ b/debian/script.in/nsscheck.sh
@@ -1,8 +1,8 @@
echo -n "Checking for services that may need to be restarted..."
# Only get the ones that are installed, of the same architecture
# as libc (or arch all) and configured
-   check=$(dpkg-query -W -f='${binary:Package} ${Status} 
${Architecture}\n' $check 2> /dev/null | \
-   grep -E "installed (all|${DPKG_MAINTSCRIPT_ARCH})$" | 
sed 's/[: ].*//')
+   check=$(dpkg-query -W -f='${binary:Package} ${db:Status-Want} 
${Architecture}\n' $check 2> /dev/null | \
+   grep -E "(install|hold) 
(all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//')
# some init scripts don't match the package names
check=$(echo $check | \
sed -e's/\bapache2.2-common\b/apache2/g' \

However before uploading such a fix so close to the release, I think it
requires a review by many more pair of eyes.

Regards,
Aurelien 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#991862: ITP: shark -- Mapping-free filtering of useless RNA-Seq reads

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: shark -- Mapping-free filtering of useless RNA-Seq reads
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: shark
  Version : 1.2.0
  Upstream Author : Copyright:2019 Tamara Ceccato, Luca Denti, Yuri Pirola, 
Marco Previtali
* URL : https://algolab.github.io/shark/
* License : GPL-3.0+
  Programming Lang: C
  Description : Mapping-free filtering of useless RNA-Seq reads
 For RNA-seq, to determine the identity of a gene that is described
 by a read, one maps it against a reference genome. Now, such may
 not be available, or one has an special variant that would make it
 too lossy to perform the mapping. This tool allows to filter for
 those reads that have a redundancy between themselves, i.e. that
 occur more frequently and are hence likely to be meaningful for
 subsequent comparisons.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/debian/shark

Bug#991788: xfce4-settings: black screen after suspend when laptop lid is closed and re-opened

[truetechie]

This is on the 5.10.0-8 kernel on Debian Bullseye with Nvidia graphics with the 
proprietary driver installed. I am using light-locker 1.8.0 and upower 
0.99.11-2 with the desktop configured to suspend my computer on lid closures. 
This happens whether or not the laptop is plugged in and is a confirmed bug 
upstream with how the upower support is implemented.

Aug 3, 2021, 05:28 by dilin...@queued.net:

> On Mon, 2 Aug 2021 02:08:09 +0200 (CEST) truetec...@tutanota.com wrote:
>
>> Package: xfce4-settings
>> Version: 4.16.0-1
>> Severity: critical
>>
>> On Debian and, by extension, Ubuntu, when suspending a laptop via closing 
>> the lid on XFCE, the screen stays black after resuming from suspend. The 
>> only way to "fix" the system is to blindly type "xrandr --auto" into a 
>> terminal or switch to a TTY and restart X.
>>
>
> As an xfce user, I haven't experienced this problem. What graphics hardware 
> and kernel are you seeing this with? Is this on battery or when plugged in? 
> Are you using light-locker (and if so, what version)? Do you have upower 
> installed (and if so, what version)? What is xfce4 configured to do on a lid 
> close (xfconf-query --verbose --list -c xfce4-power-manager)?
>

Bug#991861: make check has 100+ failures due to `libgcc_s.so.1 must be installed for pthread_cancel to work`

[Fangrui Song]

Source: glibc
Severity: normal
Tags: upstream
X-Debbugs-Cc: i...@maskray.me

On many(all?) Debian derivatives, when building the upstream glibc,
`make check` has 100+ failures due to `libgcc_s.so.1 must be installed for 
pthread_cancel to work`

I filed https://sourceware.org/bugzilla/show_bug.cgi?id=28177 .
An upstream maintainer told me that:

> Please talk to Debian or Ubuntu about upstreaming their multiarch
> patches. The upstream toolchain is consistent in this area. The issue
> only happens if you try to do glibc development on a system that has
> these custom downstream patches in its system toolchain.
>
> (Just to be clear, I would like to see these patches upstreamed, it's
> just not something I'm sure I can do due to the licensing aspects
> involved.)

So hope a Debian developer can upstream the path so that
a glibc contributor doesn't need to
`cp /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 $prefix/bfd/lib/`
to make `make check` happy.


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

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

Bug#991843: unblock: libjdom2-java/2.0.6-1.1

[Utkarsh Gupta]

Hi Sebastian,

On Tue, Aug 3, 2021 at 10:35 PM Sebastian Ramacher  wrote:
> Unstable and bullseye contain the same version of libjdom2-java. Are you
> sure that the upload reached unstable?

There was a bit of a fiasco and processing delay from dak (see my mail
at -devel for more information) but the new version of libjdom2-java
should now be available in sid.

$ rmadison libjdom2-java
libjdom2-java | 2.0.6-1   | oldoldstable| source, all
libjdom2-java | 2.0.6-1   | oldstable   | source, all
libjdom2-java | 2.0.6-1   | stable  | source, all
libjdom2-java | 2.0.6-1.1 | unstable| source
libjdom2-java | 2.0.6-2   | testing | source, all
libjdom2-java | 2.0.6-2   | unstable| source, all
libjdom2-java | 2.0.6-2.1 | buildd-unstable | source, all
libjdom2-java | 2.0.6-2.1 | unstable| source, all

Please let me know if you need any more information. Thank you!


- u

Bug#991798: closed by Lisandro Damián Nicanor Pérez Meyer (Re: Bug#991798: Acknowledgement (qtcreator: No suitable kits found) [worked around])

[Ross Boylan]

If this is the intended behavior, I suggest the intentions should change.
At a minimum, some clues in a README.Debian would be helpful.
Ross

On Mon, Aug 2, 2021 at 8:12 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the qtcreator package:
>
> #991798: qtcreator: No suitable kits found
>
> It has been closed by Lisandro Damián Nicanor Pérez Meyer <
> perezme...@gmail.com>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Lisandro Damián
> Nicanor Pérez Meyer  by
> replying to this email.
>
>
> --
> 991798: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991798
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "Lisandro Damián Nicanor Pérez Meyer" 
> To: 991798-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 2 Aug 2021 12:09:19 -0300
> Subject: Re: Bug#991798: Acknowledgement (qtcreator: No suitable kits
> found) [worked around]
> Hi Ross!
>
> There is a normal misunderstanding with respect to Qt Creator:
> installing it does not warrant you have the necessary Qt development
> files. This is because Qt Creator does not necessarily have to be used
> to code Qt stuff, in fact I use it for coding microcontrollers. So no,
> it will not "work out the box" in the way you expected.
>
> On Mon, 2 Aug 2021 00:42:07 -0700 Ross Boylan
>  wrote:
> > I seem to have got things working on bullseye.  I'm not sure how many of
> > the following steps are essential, except the last one!
> > Also, though this may solve my immediate problem, the issue that
> qtcreator
> > doesn't work "out of the box" remains.  If something about the
> > interrelations between packages makes it impossible to configure
> > automatically, there should at least be guidance about what to do.
> >
> > 1. Install qtbase5-dev.
>
> This is the necessary first step for building Qt applications, no
> matter if you use Qt Creator or not.
>
> > 2. In QtCreator Tools | Options | Kits select the Qt tab.  Apparently the
> > link facility only works for stuff installed
> > in a certain way, not including distribution packages (or so says the
> > internet) .  Use add to point to the qmake which is now
> > available because of 1.
> > 3. Also needed to set Qt version in the Desktop kit, which took a couple
> of
> > tries (maybe need to restart to have it register).
>
> In fact these two steps can be avoided by simply installing Qt and
> then opening Qt Creator.
>
> > 4. Install qtquickcontrols2-5-dev when QtCreator still says"Unknown
> > modules in Qt: Quick".  This is the only qtquick.*dev package, though
> > it hardly seems on point.  Didn't help.
> > 5. Install qtdeclarative5-dev.  Project now builds.
> >
> That's an issue that comes from upstream. The -dev packages are mostly
> named after the Qt submodules it was built from. So the core of the
> QML stuff is installed by qtdeclarative5-dev
>
> Maybe the qtquickcontrols2-5-dev package needs a dependency on
> qtdeclarative5-dev. But all it does is adding controls to QML.
>
> > My guess is that all but #4 are necessary.  #5 is specific to Qt Quick;
> the
> > others are not.
>
> Depends a lot on what you are doing. If you need to use the serial
> port you would need to install libqt5serialport5-dev.
>
> Tip: using aptitude you can look for all the -dev packages by issuing:
>
> aptitude search qt | grep 5 | grep -dev
>
> There is surely a better/apt-only way of doing this, but that's the
> thing I normally use :-)
>
> By the way: we removed qt5-default package from bullseye. That package
> should have never existed.
>
> So what you found are not bugs but indeed the intended way to use
> these packages. I'm so closing this bug.
>
> Cheers, Lisandro.
>
>
> -- Forwarded message --
> From: Ross Boylan 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 01 Aug 2021 22:49:59 -0700
> Subject: qtcreator: No suitable kits found
> Package: qtcreator
> Version: 4.14.1-1
> Severity: important
> Justification: Unable to use package
>
> Dear Maintainer,
>
>* What led up to the situation?
>
>Install qtcreator and launch it.
>File | New File or Project
>Application (Qt Quick) | Qt Quick Application - Scroll
>Hit choose
>Enter location. Next.
>Accept defaults until get to Kit Selection
>
>It says "No suitable kits found" and the Next button is greyed out.
>Desktop appears as the only entry in the bottom panel, but it is
>greyed out and hovering over brings up a bubble saying at least one
>required feature is missing. The Qt Version shows as None in that
> bubble.
>
>Clicked on the options link (or the manage button for the desktop
>kit) shows Desktop listed under kits and nothing under Qt Versions.
>
>* What exactly did you 

Bug#991854: dmidecode

[Jörg Frings-Fürst]

Hello,

because of the bugreport[1] I would like to ask here if it is useful to
compile dmidecode also for riscv64?


CU
Jörg

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991854
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

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

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


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

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


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



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

Bug#991778: dlint: Dlint fails to find version number of dig

[Paul Gevers]

Control: tags -1 bullseye-ignore

Hi Patrik, Florian,

On Sun, 01 Aug 2021 19:00:34 +0200 Patrik Schindler  wrote:
> On my Debian Buster system, dig fails to work with

On my Debian bullseye system, this works as expected, see below. So
apparently it's either only broken in buster, or it's not always broken.
As it's too late to fix this for the upcoming release of bullseye in two
weeks, I mark this bug as bullseye-ignore (Release Team member hat on).
If the package is broken in buster only, that may be fixed via a point
release update.

Paul

paul@mulciber ~ $ dlint debian.org
WARNING: tempfile is deprecated; consider using mktemp instead.
WARNING: tempfile is deprecated; consider using mktemp instead.
WARNING: tempfile is deprecated; consider using mktemp instead.
WARNING: tempfile is deprecated; consider using mktemp instead.
WARNING: tempfile is deprecated; consider using mktemp instead.
WARNING: tempfile is deprecated; consider using mktemp instead.
WARNING: tempfile is deprecated; consider using mktemp instead.
WARNING: tempfile is deprecated; consider using mktemp instead.
;; dlint version 1.4.0, Copyright (C) 1998 Paul A. Balyoz 
;; Dlint comes with ABSOLUTELY NO WARRANTY.
;; This is free software, and you are welcome to redistribute it
;; under certain conditions.  Type 'man dlint' for details.
;; command line: /usr/bin/dlint debian.org
;; flags: normal-domain recursive.
;; using dig version 9.16.15
;; run starting: di  3 aug 2021 19:58:00 CEST
;; 
;; Now linting debian.org
;; Checking serial numbers per nameserver
;; 2021080326 sec1.rcode0.net.
;; 2021080326 nsp.dnsnode.net.
;; 2021080326 sec2.rcode0.net.
;; 2021080326 dns4.easydns.info.
;; All nameservers agree on the serial number.
;; Now caching whole zone (this could take a minute)
;; trying nameserver dns4.easydns.info.
ERROR: no A records found.
;; no subzones found below debian.org, so no recursion will take place.
;; 
;; dlint of debian.org run ending with errors.
;; run ending: di  3 aug 2021 19:58:01 CEST



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991834: unblock: galera-4/26.4.9-1

[Andreas Beckmann]

On 03/08/2021 17.50, Paul Gevers wrote:

+Breaks: galera-3 (<< 26.4)
+Replaces: galera-3 (<< 26.4)

What are these versions? The highest version of galera-3 from
src:galera-3 is 25.3.34-1.


26.4 is galera-4 ==> anything earlier galera-3

Andreas

Bug#990283: openvpn: Upgrades break systemd supervision

[Jörg Frings-Fürst]

tags 990283 + moreinfo
thanks


Hi,

I have checked your bug report on every server I have access to.

Likewise, I have checked the problem in multiple VMs. The error was not
reproducible there either.

Can you please provide the complete update logs?
Was the computer rebooted after the update? 

Or can someone confirm the error?

Many thanks

CU
Jörg

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

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

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


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

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


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



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

Bug#991860: hivex: CVE-2021-3622

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for hivex.

CVE-2021-3622[0]:
| stack overflow due to recursive call of _get_children()

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-3622
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3622
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1975489
[2] 
https://github.com/libguestfs/hivex/commit/771728218dac2fbf6997a7e53225e75a4c6b7255
[3] https://listman.redhat.com/archives/libguestfs/2021-August/msg2.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#991843: unblock: libjdom2-java/2.0.6-1.1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-08-03 14:11:25 +0530, Utkarsh Gupta wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hey,
> 
> src:libjdom2-java has been affected by CVE-2021-33813 which is fixed
> in sid & stretch. -pu update for buster is also being filed.
> 
> Since this is just a CVE fix, I'd request you to unblock this and let
> it go to bullseye, please? (I am sorry for doing this on the eleventh
> hour :/)
> 
> The debdiff is duly attached. Let me know if you any more information. TIA! 
> \o/

Unstable and bullseye contain the same version of libjdom2-java. Are you
sure that the upload reached unstable?

Cheers

> 
> 
> - u



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#991749: unblock: ruby-maven-libs/3.3.9+ds-2

[Nilesh Patra]

control: retitle -1 unblock: ruby-maven-libs/3.3.9+ds-3

Hi Graham,

On Sun, 1 Aug 2021 14:33:35 +0200 Graham Inggs  wrote:
> Control: tags -1 + moreinfo
> 
> Hi Praveen
> 
> On Sat, 31 Jul 2021 at 21:21,  wrote:
> > +  * Bump debhelper from old 10 to 12.
> 
> Please revert this change.  See 'Target fixes' section of the freeze policy 
> [1].

I reverted this debhelper bump and uploaded a -3 to unstable. Debdiff
for both the -3 release v/s -2 release (this one), and -3 v/s -1.1 release (in
testing) can be found attached w/ this email

Since the -2 changelog states inclusion of d/salsa-ci.yml, but the
package did not include it, I added two lines of this file, which should
be absolutely harmless by all metrics.

Thanks a lot for your work on the release :-)

Nilesh
diff -Nru ruby-maven-libs-3.3.9+ds/debian/changelog 
ruby-maven-libs-3.3.9+ds/debian/changelog
--- ruby-maven-libs-3.3.9+ds/debian/changelog   2021-08-01 00:23:32.0 
+0530
+++ ruby-maven-libs-3.3.9+ds/debian/changelog   2021-08-03 22:02:31.0 
+0530
@@ -1,3 +1,10 @@
+ruby-maven-libs (3.3.9+ds-3) unstable; urgency=medium
+
+  * Team Upload.
+  * Revert debhelper bump from 10 to 12 for bullseye release
+
+ -- Nilesh Patra   Tue, 03 Aug 2021 22:02:31 +0530
+
 ruby-maven-libs (3.3.9+ds-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru ruby-maven-libs-3.3.9+ds/debian/compat 
ruby-maven-libs-3.3.9+ds/debian/compat
--- ruby-maven-libs-3.3.9+ds/debian/compat  1970-01-01 05:30:00.0 
+0530
+++ ruby-maven-libs-3.3.9+ds/debian/compat  2021-08-03 21:59:35.0 
+0530
@@ -0,0 +1 @@
+10
diff -Nru ruby-maven-libs-3.3.9+ds/debian/control 
ruby-maven-libs-3.3.9+ds/debian/control
--- ruby-maven-libs-3.3.9+ds/debian/control 2021-08-01 00:23:32.0 
+0530
+++ ruby-maven-libs-3.3.9+ds/debian/control 2021-08-03 22:00:16.0 
+0530
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Ruby Team 

 Uploaders: Miguel Landaeta 
-Build-Depends: debhelper-compat (= 12),
+Build-Depends: debhelper (>= 10~),
gem2deb
 Standards-Version: 4.5.1
 Vcs-Git: https://salsa.debian.org/ruby-team/ruby-maven-libs.git
diff -Nru ruby-maven-libs-3.3.9+ds/debian/salsa-ci.yml 
ruby-maven-libs-3.3.9+ds/debian/salsa-ci.yml
--- ruby-maven-libs-3.3.9+ds/debian/salsa-ci.yml1970-01-01 
05:30:00.0 +0530
+++ ruby-maven-libs-3.3.9+ds/debian/salsa-ci.yml2021-08-03 
21:59:05.0 +0530
@@ -0,0 +1,4 @@
+---
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
diff -Nru ruby-maven-libs-3.3.9+ds/debian/changelog 
ruby-maven-libs-3.3.9+ds/debian/changelog
--- ruby-maven-libs-3.3.9+ds/debian/changelog   2021-01-09 17:39:58.0 
+0530
+++ ruby-maven-libs-3.3.9+ds/debian/changelog   2021-08-03 22:02:31.0 
+0530
@@ -1,9 +1,36 @@
-ruby-maven-libs (3.3.9+ds-1.1) unstable; urgency=medium
+ruby-maven-libs (3.3.9+ds-3) unstable; urgency=medium
 
-  * Non maintainer upload by the Reproducible Builds team.
-  * No source change upload to rebuild on buildd with .buildinfo files.
+  * Team Upload.
+  * Revert debhelper bump from 10 to 12 for bullseye release
 
- -- Holger Levsen   Sat, 09 Jan 2021 13:09:58 +0100
+ -- Nilesh Patra   Tue, 03 Aug 2021 22:02:31 +0530
+
+ruby-maven-libs (3.3.9+ds-2) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Utkarsh Gupta ]
+  * Add salsa-ci.yml
+
+  [ Debian Janitor ]
+  * Use secure copyright file specification URI.
+  * Bump debhelper from old 10 to 12.
+  * Set debhelper-compat version in Build-Depends.
+  * Update Vcs-* headers from URL redirect.
+  * Use canonical URL in Vcs-Git.
+
+  [ Cédric Boutillier ]
+  * Update team name
+  * Add .gitattributes to keep unwanted files out of the source package
+
+  [ Pirate Praveen ]
+  * Add a simple require autopkgtest (to check the version patch)
+  * Fix maven version detection patch (Thanks to Raul Tambre) (Closes: #989175)
+  * Bump Standards-Version to 4.5.1 (no changes needed)
+  * Include NOTICE file in binary package
+  * Move debian/watch to gemwatch.debian.net
+
+ -- Pirate Praveen   Sun, 01 Aug 2021 00:23:32 +0530
 
 ruby-maven-libs (3.3.9+ds-1) unstable; urgency=medium
 
diff -Nru ruby-maven-libs-3.3.9+ds/debian/control 
ruby-maven-libs-3.3.9+ds/debian/control
--- ruby-maven-libs-3.3.9+ds/debian/control 2017-03-10 00:09:43.0 
+0530
+++ ruby-maven-libs-3.3.9+ds/debian/control 2021-08-03 22:00:16.0 
+0530
@@ -1,13 +1,13 @@
 Source: ruby-maven-libs
 Section: ruby
 Priority: optional
-Maintainer: Debian Ruby Extras Maintainers 

+Maintainer: Debian Ruby Team 

 Uploaders: Miguel Landaeta 
 Build-Depends: debhelper (>= 10~),
gem2deb
-Standards-Version: 3.9.8
-Vcs-Git: https://anonscm.debian.org/git/pkg-ruby-extras/ruby-maven-libs.git
-Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-ruby-extras/ruby-maven-libs.git
+Standards-Version: 4.5.1
+Vcs-Git: 

Bug#991597: pulseaudio: Please enable GStreamer support

[Felipe Sateler]

Hi!

On Wed, Jul 28, 2021 at 5:24 AM Laurent Bigonville  wrote:

> Source: pulseaudio
> Version: 14.99.2+dfsg1-1
> Severity: wishlist
>
> Hello,
>
> Would be nice to enable the GStreamer support in pulseaudio so more
> codecs are supported for the bluetooth headsets (LDAC, AptX and maybe
> AAC later)
>
> ATM the support/elements in GStreamer are still missing (coming in the
> next release), but we could already prepare the pulseaudio side.
>

Does that mean that enabling it, would only add some dependencies but not
actually do anything?


-- 

Saludos,
Felipe Sateler

Bug#991844: unblock: libpam-tacplus/1.3.8-2.1

[Utkarsh Gupta]

Hi Paul,

On Tue, Aug 3, 2021 at 9:46 PM Paul Gevers  wrote:
> On 03-08-2021 10:46, Utkarsh Gupta wrote:
> > src:libpam-tacplus
>
> ... is not in testing.
>
> closing this bug as there's nothing to do (no, we're not going to let it
> in now).

Ugh, my bad for not checking that. Thanks and of course not letting it
go to bullseye absolutely makes sense! Thank you and sorry for the
noise!


- u

Bug#991859: ITP: r-bioc-basilisk -- Freezing Python Dependencies Inside Bioconductor Packages

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-basilisk -- Freezing Python Dependencies Inside 
Bioconductor Packages
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-basilisk
  Version : 1.4.0
  Upstream Author : Aaron Lun,
* URL : https://bioconductor.org/packages/basilisk/
* License : GPL-3
  Programming Lang: GNU R
  Description : Freezing Python Dependencies Inside Bioconductor Packages
 Installs a self-contained conda instance that is managed by the
 R/Bioconductor installation machinery. This aims to provide a consistent
 Python environment that can be used reliably by Bioconductor packages.
 Functions are also provided to enable smooth interoperability of
 multiple Python environments in a single R session.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-basilisk

Bug#991845: unblock: libx11/2:1.7.2-1

[Paul Gevers]

Control: tags -1 confirmed d-i

Hi Cyril,

The item below needs your ack.

Paul

On 03-08-2021 10:54, Timo Aaltonen wrote:
> Please unblock package libx11
> 
> [ Reason ]
> The new upstream release fixes regressions in the previous CVE release, 
> including a segfault in fdesign. (bug 990998)
> 
> [ Impact ]
> Regressions remain in bullseye release.
> 
> [ Tests ]
> The new version has a commit that fixes a bug with a similar backtrace as 
> 990998, Matt can verify here that fdesign works with the new libx11.
> 
> [ Risks ]
> The upstream changes are small, only three commits, 
> 
> [ 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 ]
> The diff is filtered to have only changes to the code and packaging, 
> autotools changes are removed.
> 
> unblock libx11/2:1.7.2-1
> 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991858: ITP: r-bioc-basilisk.utils -- Basilisk Installation Utilities

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-basilisk.utils -- Basilisk Installation Utilities
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-basilisk.utils
  Version : 1.4.0+ds
  Upstream Author : Aaron Lun
* URL : https://bioconductor.org/packages/basilisk.utils/
* License : GPL-3
  Programming Lang: GNU R
  Description : Basilisk Installation Utilities
 Implements utilities for installation of the basilisk package, primarily
 for creation of the underlying Conda instance. This allows us to avoid
 re-writing the same R code in both the configure script (for centrally
 administered R installations) and in the lazy installation mechanism
 (for distributed package binaries). It is highly unlikely that
 developers - or, heaven forbid, end-users! - will need to interact with this
 package directly; they should be using the basilisk package instead.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-basilisk.utils

Bug#991857: /etc/skel/.profile suggests installing non existant package

[u34]

Package: bash
Version: 5.0-4

/etc/skel/.profile is installed by the bash package.

$ grep -C2 libpam-umask /etc/skel/.profile 

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

As far as I can tell, there is no libpam-umask package.
There is also now 
https://salsa.debian.org/vorlon/pam/-/merge_requests/3/diffs?commit_id=56fb6980b1ff5936bb62e7c8313af8329e9f0d86
I suggest rewriting the comment as follow:

# the default umask is set in /etc/profile; consider setting the umask
# with pam-umask at /etc/pam.d/common-session{,-noninteractive}.
#umask 022

--
u34

Bug#991856: debian-security-support: Unix username *way* too long

[Thorsten Glaser]

Package: debian-security-support
Version: 2019.12.12~deb8u2
Severity: normal

Colour my surprise when I did an “ls -l /var/lib” and saw:

[…]
drwxr-xr-x  3 rootroot 4096 Oct  1  
2019 ucf/
drwxr-xr-x  2 rootroot 4096 Jul  6  
2012 update-rc.d/
drwxr-xr-x  2 rootroot 4096 Sep  7  
2012 urandom/
drwxr-xr-x  3 rootroot 4096 Feb  7  
2007 vim/
drwxr-xr-x  2 rootroot 4096 Feb 17  
2020 xfonts/
drwxr-xr-x  2 rootroot 4096 Dec 17  
2015 xml-core/

That’s *massively* too wide. Scrolling up revealed the culprit:

drwxr-xr-x  2 debian-security-support debian-security-support  4096 Feb 17  
2020 debian-security-support/

Unix usernames are supposed to be up to 8 characters (in fact, some
environments fail if they are longer, silently truncate them, or
otherwise explode). This is… untenable.

Please change this. Thanks!


-- System Information:
Debian Release: 8.11
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-11-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages debian-security-support depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  gettext-base   0.19.3-2

debian-security-support recommends no packages.

debian-security-support suggests no packages.

-- debconf information:
  debian-security-support/ended:
  debian-security-support/limited:
  debian-security-support/earlyend:

Bug#991834: unblock: galera-4/26.4.9-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi

On 02-08-2021 23:00, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package galera-4
> 
> It's a new upstream bugfix release, Otto can probably comment on that.

Yes, please. We want totally targeted fixes at this moment. This doesn't
sound like one.

> Packaging wise it contains the second half of solving the mariadb
> upgrade issues (there is a conflicts cycle between galera-3 and galera-4
> and upgrading from buster to bullseye requires switching from galera-3
> to galera-4 ... sometimes the upgrade outcome is an unexpected removal
> of mariadb-server - #990708)
> 
> Andreas
> 
> unblock galera-4/26.4.9-1

diff -Nru galera-4-26.4.8/debian/control galera-4-26.4.9/debian/control
[...]
-Breaks: galera,
-galera-3
-Replaces: galera
+Breaks: galera-3 (<< 26.4)
+Replaces: galera-3 (<< 26.4)

What are these versions? The highest version of galera-3 from
src:galera-3 is 25.3.34-1.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991788: xfce4-settings: black screen after suspend when laptop lid is closed and re-opened

[Andres Salomon]

On 8/3/21 11:05 AM, truetec...@tutanota.com wrote:


This is on the 5.10.0-8 kernel on Debian Bullseye with Nvidia graphics 
with the proprietary driver installed. I am using light-locker 1.8.0 
and upower 0.99.11-2 with the desktop configured to suspend my 
computer on lid closures. This happens whether or not the laptop is 
plugged in and is a confirmed bug upstream with how the upower support 
is implemented.




Thank you!


This appears to be reported upstream at 
https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/222 , which was 
fixed (and merged) with 
https://gitlab.xfce.org/xfce/xfce4-settings/-/merge_requests/20 in a 
somewhat unsatisfying way.


It's up to the debian xfce4 maintainers to determine if there's value in 
leaving upower enabled for xfce4-settings in bullseye, and/or this bug 
should be reassigned or cloned to upower.

Bug#991723: claws-mail: CVE-2021-37746

[Ricardo Mones]

Hi Kentaro,

On Tue, Aug 03, 2021 at 11:46:50PM +0900, Kentaro Hayashi wrote:
> On Fri, 30 Jul 2021 22:31:07 +0200 Salvatore Bonaccorso  
> wrote:
> > [1] 
> > https://git.claws-mail.org/?p=claws.git;a=commit;h=ac286a71ed78429e16c612161251b9ea90ccd431
> 
> I'm not an expert, so feedback are welcome.
> I think that [1] maybe incomplete.
> 
> [1] commit fixes two parts, checking by is_uri_string [2] and new comparison 
> with uri->uri. [3]
> 
> [2]
> if (is_uri_string(uri->uri) == FALSE)
> -   return TRUE;
> +   return FALSE;
> 
> 
> It seems ok, if it is not valid string, it should return FALSE.
> 
> 
> [3]
> 
> +   if (strlen(uri->uri) > get_uri_len(uri->uri))
> +   retval = FALSE;
> 
> Before this check, there are "if (retval == FALSE)" block,
> thus the above code must be put before "if (retval == FALSE)" block,
>  so this fix is wrong. (at least it doesn't work as expected)

The "if (retval == FALSE)" block before [3] you mention is allowing the
user to inspect the URL in a dialog and override the decission computed
by the function so far.

Moving the strlen/get_url_len check before that block would mean the
user could also override that check. Therefore it has to be determined
first if that difference in URL lengths can be also easily detected by
user eyes.

I suspect is not that easy, and allowing users to override that would
make it easier for phishers to introduce dangerous URLs. But I may be
wrong, of course.

As currently, even if the used has decided to display the URL, the
function will deny if the lenghts differ, so I think that's safer, but,
as you say, some users may not expect that. Perhaps this unexpected
behaviour requires some more info in the UI, better than opening the
door to unsafe URLs.

regards,
-- 
  Ricardo Mones 
  ~
  I'm sorry, my responses are limited. You must ask the right 
  questions.   A hologram



signature.asc
Description: PGP signature

Bug#991723: claws-mail: CVE-2021-37746

[Kentaro Hayashi]

On Fri, 30 Jul 2021 22:31:07 +0200 Salvatore Bonaccorso  
wrote:
> [1] 
> https://git.claws-mail.org/?p=claws.git;a=commit;h=ac286a71ed78429e16c612161251b9ea90ccd431

I'm not an expert, so feedback are welcome.
I think that [1] maybe incomplete.

[1] commit fixes two parts, checking by is_uri_string [2] and new comparison 
with uri->uri. [3]

[2]
if (is_uri_string(uri->uri) == FALSE)
-   return TRUE;
+   return FALSE;


It seems ok, if it is not valid string, it should return FALSE.


[3]

+   if (strlen(uri->uri) > get_uri_len(uri->uri))
+   retval = FALSE;

Before this check, there are "if (retval == FALSE)" block,
thus the above code must be put before "if (retval == FALSE)" block,
 so this fix is wrong. (at least it doesn't work as expected)


Regards,

Bug#991855: RFP: ferdi -- All your messaging services in one place

[Markus Hatvan]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: markus_hat...@aon.at

* Package name: ferdi
  Version : 5.6.0
  Upstream Author : Amine Mouafik 
* URL : https://getferdi.com/
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : All your messaging services in one place.

Based on one of the most popular messaging browsers.

Ferdi is based on Franz - a messaging browser already used by thousands of 
people.
Due to this, Ferdi is compatible with all Franz recipes and your existing Franz 
account.

All your messaging services in one place.

One Slack application, one WhatsApp application, keeping your WebMail open in 
the browser? 
Ferdi brings all your messaging services into one app.

No restrictions.

Ferdi doesn't restrict its usage. Use every service you want, as many times as 
you want and how you want.

Password Lock.

Protect your messages by using Password Lock. Password Lock allows you to lock 
your messages using a password.

No login required.

With Ferdi you can choose between logging in to your Ferdi account to sync your 
services between devices or using Ferdi without an account so your data doesn't 
get send to external servers.

Custom Servers.

Don't want to trust third-parties to store your information? With Ferdi, you 
can set up your own Server - minimal hardware and knowledge required.

Service Hibernation.

By default, Ferdi will keep your services loaded in the background - this can 
use a lot of resources. If you want to, you can enable service hibernation in 
Ferdi's settings.
This will automatically unload unused services to keep your computer running 
fast.

Ferdi Todos.

Always keep an eye on your Todo list with Ferdi Todos. Already use another Todo 
service like Todoist? Simply change the Todo Server in Ferdi's settings.

Quick Switch.

You have a lot of services that you quickly want to navigate? Simply press 
CMD/CTRL + P to open Quick Switch and search for your service.

Private Notification.

Want to be notified about new messages but don't want to reveal their content? 
Enable Private Notifications to protect your message information.

Keep individual Workspaces loaded.

Ferdi allows you to keep individual Workspaces loaded at all times - so you can 
continue where you last left.

Scheduled Do-not-Disturb.

Define a timeframe, in which Ferdi shouldn't notify you about new notifications.

Cross-platform.

Being built on ElectronJS, Ferdi is compatible with Windows, Mac and Linux.

Bug#991854: dmidecode: not build for riscv64

[Heinrich Schuchardt]

Package: dmidecode
Version: 3.3-2
Severity: normal
Tags: patch
Usertags: origin-ubuntu impish ubuntu-patch

Dear Maintainer,

please, enable building dmidecode on riscv64. This requires only changes 
to debian/control:


diff -Nru dmidecode-3.3/debian/control dmidecode-3.3/debian/control
--- dmidecode-3.3/debian/control2021-05-07 06:54:34.0 +
+++ dmidecode-3.3/debian/control2021-08-02 15:22:49.0 +
@@ -11,7 +11,7 @@

 Package: dmidecode
 Priority: important
-Architecture: any-amd64 arm64 armhf ia64 any-i386
+Architecture: any-amd64 arm64 armhf ia64 any-i386 riscv64
 Multi-Arch: foreign
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: SMBIOS/DMI table decoder
@@ -30,7 +30,7 @@

 Package: dmidecode-udeb
 Section: debian-installer
-Architecture: any-amd64 arm64 armhf ia64 any-i386
+Architecture: any-amd64 arm64 armhf ia64 any-i386 riscv64
 Package-Type: udeb
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: SMBIOS/DMI table decoder (udeb)

Best regards

Heinrich
diff -Nru dmidecode-3.3/debian/changelog dmidecode-3.3/debian/changelog
--- dmidecode-3.3/debian/changelog	2021-05-17 16:53:43.0 +
+++ dmidecode-3.3/debian/changelog	2021-08-02 15:25:54.0 +
@@ -1,3 +1,9 @@
+dmidecode (3.3-2ubuntu1) impish; urgency=medium
+
+  * Add riscv64 build architecture (LP: #1938705) 
+
+ -- Heinrich Schuchardt   Mon, 02 Aug 2021 17:25:54 +0200
+
 dmidecode (3.3-2) unstable; urgency=medium
 
   * Add upstream recommended patches (Closes: #987033):
diff -Nru dmidecode-3.3/debian/control dmidecode-3.3/debian/control
--- dmidecode-3.3/debian/control	2021-05-07 06:54:34.0 +
+++ dmidecode-3.3/debian/control	2021-08-02 15:22:49.0 +
@@ -11,7 +11,7 @@
 
 Package: dmidecode
 Priority: important
-Architecture: any-amd64 arm64 armhf ia64 any-i386
+Architecture: any-amd64 arm64 armhf ia64 any-i386 riscv64
 Multi-Arch: foreign
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: SMBIOS/DMI table decoder
@@ -30,7 +30,7 @@
 
 Package: dmidecode-udeb
 Section: debian-installer
-Architecture: any-amd64 arm64 armhf ia64 any-i386
+Architecture: any-amd64 arm64 armhf ia64 any-i386 riscv64
 Package-Type: udeb
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: SMBIOS/DMI table decoder (udeb)

Bug#991853: archive.debian.org: Invalid SSL/TLS certificate, https fails

[Greg Wooledge]

Package: www.debian.org
Severity: normal

Apologies if this is the wrong pseudo-package; I couldn't find one
for archive.debian.org specifically.

Attempts to download a package from the archive.debian.org site using
https with command line tools fail.  These examples are performed on a
bullseye host:


$ wget 
https://archive.debian.org/debian/pool/main/a/apt/apt-transport-https_0.9.7.9+deb7u7_amd64.deb
--2021-08-03 08:26:17--  
https://archive.debian.org/debian/pool/main/a/apt/apt-transport-https_0.9.7.9+deb7u7_amd64.deb
Resolving archive.debian.org (archive.debian.org)... 217.196.149.234, 
193.62.202.28, 130.89.148.13, ...
Connecting to archive.debian.org (archive.debian.org)|217.196.149.234|:443... 
connected.
ERROR: The certificate of ‘archive.debian.org’ is not trusted.
ERROR: The certificate of ‘archive.debian.org’ doesn't have a known issuer.
The certificate's owner does not match hostname ‘archive.debian.org’

$ curl 
https://archive.debian.org/debian/pool/main/a/apt/apt-transport-https_0.9.7.9+deb7u7_amd64.deb
 > apt-transport-https_0.9.7.9+deb7u7_amd64.deb
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.


If I go to https://archive.debian.org/debian/pool/main/a/apt/ in
Google Chrome, I'm prompted with the standard warning about an
invalid certificate; if I choose to go forward despite that, I get:


Not Found
The requested URL was not found on this server.

Apache Server at archive.debian.org Port 443


Finally, I will note that it would be most helpful if the archive.debian.org
site can be accessed directly by older systems using the apt-transport-https
package.  If this is impossible due to security concerns, then downloading
the packages by hand on a newer system, and then moving them over to the
older systems, would still be better than the current situation, which is
that the packages are completely inaccessible in environments where plain
http is blocked.

Bug#991852: unblock: debian-edu-doc/2.11.26

[Holger Levsen]

On Tue, Aug 03, 2021 at 02:50:27PM +0300, Adrian Bunk wrote:
> Please unblock package debian-edu-doc
[...]
> unblock debian-edu-doc/2.11.26

thanks for filing this unblock request, Adrian!


-- 
cheers,
Holger

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

"A developed country is not a place where the poor have cars. It's where the
rich use public transportation." (quote attributed to several people)


signature.asc
Description: PGP signature

Bug#991852: unblock: debian-edu-doc/2.11.26

[Adrian Bunk]

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

Please unblock package debian-edu-doc

  * Update Debian Edu Bullseye manual from the wiki.
  [ Translation updates ]
  * Bullseye manual:
- German: Wolfgang Schweer
- Dutch: Frans Spiesschaert
- Portuguese (Brazil): Barbara Tostes and Fred Maranhão
- Polish: Stanisław Stefan Krukowski
- Chinese (Simplified): Ma Yong
  * Buster manual:
- Portuguese (Brazil): Barbara Tostes and Fred Maranhão
- Polish: Stanisław Stefan Krukowski
- Chinese (Simplified): Ma Yong
(changes by Holger Levsen)

Documentation-only change, no debdiff due to size:
 debian/changelog   
  |   18
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual-stripped.xml  
  |   27
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.da.po 
  |   61
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.de.po 
  |   83
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.es.po 
  |   48
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.fr.po 
  | 1798 --
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.it.po 
  | 1802 --
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.ja.po 
  |   76
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.nb-no.po  
  |   58
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.nl.po 
  | 7847 ++
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.pl.po 
  |  343
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.pot   
  |   45
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.pt-br.po  
  |   95
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.pt-pt.po  
  |   80
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.pt.po 
  |   80
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.ro.po 
  |   49
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.sv.po 
  |   49
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.xml   
  |   27
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.zh-cn.po  
  |  117
 documentation/debian-edu-bullseye/debian-edu-bullseye-manual.zh-tw.po  
  |   47
 
documentation/debian-edu-bullseye/source/AllInOne-debian-edu-bullseye-manual.xml
 |8
 documentation/debian-edu-buster/debian-edu-buster-manual.pl.po 
  |  135
 documentation/debian-edu-buster/debian-edu-buster-manual.pt-br.po  
  |   20
 documentation/debian-edu-buster/debian-edu-buster-manual.zh-cn.po  
  |   17
 24 files changed, 5972 insertions(+), 6958 deletions(-)


unblock debian-edu-doc/2.11.26

Bug#991851: unblock: piuparts/1.1.4

[Andreas Beckmann]

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

Please unblock package piuparts

This update prepares the package for stable=bullseye.
It also switches some scripts to the mariadb and postgresql versions we
have in bullseye.
The pkgsummary changes fix some recent breakage observed on piuparts.d.o
and have been deployed there for some days already.

There will probably be a larger update coming for the first
bullseye point release... if I find some time...

unblock piuparts/1.1.4

Andreas

(trying to get the last unblock request in before the deadline :-)


piuparts-1.1.4.diff.gz
Description: application/gzip

Bug#991850: unblock: tmpreaper/1.6.14+nmu2

[Adrian Bunk]

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

Please unblock package tmpreaper

  * Apply patch from Mick Switser to fix protect on directory.
(Closes: #636459)

unblock tmpreaper/1.6.14+nmu2
diff -Nru tmpreaper-1.6.14+nmu1/ChangeLog tmpreaper-1.6.14+nmu2/ChangeLog
--- tmpreaper-1.6.14+nmu1/ChangeLog 2019-09-06 16:20:49.0 +0300
+++ tmpreaper-1.6.14+nmu2/ChangeLog 2021-08-03 08:35:41.0 +0300
@@ -1,3 +1,11 @@
+tmpreaper (1.6.14+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from Mick Switser to fix protect on directory.
+(Closes: #636459)
+
+ -- Adrian Bunk   Tue, 03 Aug 2021 08:35:41 +0300
+
 tmpreaper (1.6.14+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru tmpreaper-1.6.14+nmu1/debian/changelog 
tmpreaper-1.6.14+nmu2/debian/changelog
--- tmpreaper-1.6.14+nmu1/debian/changelog  2019-09-06 16:20:49.0 
+0300
+++ tmpreaper-1.6.14+nmu2/debian/changelog  2021-08-03 08:35:41.0 
+0300
@@ -1,3 +1,11 @@
+tmpreaper (1.6.14+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from Mick Switser to fix protect on directory.
+(Closes: #636459)
+
+ -- Adrian Bunk   Tue, 03 Aug 2021 08:35:41 +0300
+
 tmpreaper (1.6.14+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru tmpreaper-1.6.14+nmu1/tmpreaper.c tmpreaper-1.6.14+nmu2/tmpreaper.c
--- tmpreaper-1.6.14+nmu1/tmpreaper.c   2019-01-05 17:23:01.0 +0200
+++ tmpreaper-1.6.14+nmu2/tmpreaper.c   2021-08-03 08:35:41.0 +0300
@@ -519,6 +519,21 @@
continue;
}
 
+if (FLAGS_PROTECT_P (flags)) {
+   skip = i = 0;
+   do {
+   if (sb.st_ino == protect_table[i].inode) {
+   message (LOG_VERBOSE,
+"Entry matching `--protect' pattern 
skipped. `%s'\n",
+protect_table[i].name);
+   skip = 1;
+   break;
+   }
+   } while (protect_table[i++].name);
+   if (skip)
+   continue;
+   }
+
if (S_ISDIR (sb.st_mode)) {
 #ifdef HAVE_LIBMOUNT_LIBMOUNT_H
struct mountpoint_control ctl = { NULL };
@@ -565,21 +580,6 @@
 (u_int) getpid(), ent->d_name);
}
 
-   if (FLAGS_PROTECT_P (flags)) {
-   skip = i = 0;
-   do {
-   if (sb.st_ino == protect_table[i].inode) {
-   message (LOG_VERBOSE,
-"Entry matching `--protect' pattern 
skipped. `%s'\n",
-protect_table[i].name);
-   skip = 1;
-   break;
-   }
-   } while (protect_table[i++].name);
-   if (skip)
-   continue;
-   }
-
/* Decide whether to remove the file or not */
/* check for mtime on directory instead of atime if requested */
if ( FLAGS_MTIME_P(flags) ||

Bug#991849: unblock: sctk/2.4.10-20151007-1312Z+dfsg2-3.1

[Adrian Bunk]

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

Please unblock package sctk

  * Apply patch by Michael Hudson-Doyle to use pdftoppm instead
of convert to convert pdf to jpg as the latter fails with the
changed security policy of ImageMagick. (Closes: #962439)
diff -Nru sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog 
sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog
--- sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog   2016-04-27 
19:42:33.0 +0300
+++ sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog   2021-08-03 
09:44:24.0 +0300
@@ -1,3 +1,12 @@
+sctk (2.4.10-20151007-1312Z+dfsg2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch by Michael Hudson-Doyle to use pdftoppm instead
+of convert to convert pdf to jpg as the latter fails with the
+changed security policy of ImageMagick. (Closes: #962439)
+
+ -- Adrian Bunk   Tue, 03 Aug 2021 09:44:24 +0300
+
 sctk (2.4.10-20151007-1312Z+dfsg2-3) unstable; urgency=medium
 
   * Fix an error in replacement files Makefile.
diff -Nru sctk-2.4.10-20151007-1312Z+dfsg2/debian/control 
sctk-2.4.10-20151007-1312Z+dfsg2/debian/control
--- sctk-2.4.10-20151007-1312Z+dfsg2/debian/control 2016-04-27 
19:42:33.0 +0300
+++ sctk-2.4.10-20151007-1312Z+dfsg2/debian/control 2021-08-03 
09:44:12.0 +0300
@@ -8,6 +8,7 @@
  dh-buildinfo,
  dpkg-dev (>= 1.16.1~),
  librsvg2-bin,
+ poppler-utils,
  texlive-latex-base,
  texlive-latex-extra,
  imagemagick,
diff -Nru sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile 
sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile
--- sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile  
2016-04-27 19:42:33.0 +0300
+++ sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile  
2021-08-03 09:43:34.0 +0300
@@ -34,7 +34,7 @@
 all: $(OUTPUT)
 
 %.jpg: %.pdf
-   convert -density 300 $< $@
+   pdftoppm -jpeg -singlefile -r 300 $< > $@
 
 %.png: %.svg
convert "$<" "$@"

Bug#991848: unblock: statsvn/0.7.0.dfsg-10

[Adrian Bunk]

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

Please unblock package statsvn

  * Add patch from FreeBSD to disable the version check that broke
with Subversion >= 10. (Closes: #990488)

unblock statsvn/0.7.0.dfsg-10
diff -Nru statsvn-0.7.0.dfsg/debian/changelog 
statsvn-0.7.0.dfsg/debian/changelog
--- statsvn-0.7.0.dfsg/debian/changelog 2018-11-18 13:02:28.0 +0200
+++ statsvn-0.7.0.dfsg/debian/changelog 2021-08-03 08:05:50.0 +0300
@@ -1,3 +1,11 @@
+statsvn (0.7.0.dfsg-10) unstable; urgency=medium
+
+  * QA upload.
+  * Add patch from FreeBSD to disable the version check that broke
+with Subversion >= 10. (Closes: #990488)
+
+ -- Adrian Bunk   Tue, 03 Aug 2021 08:05:50 +0300
+
 statsvn (0.7.0.dfsg-9) unstable; urgency=medium
 
   * QA upload.
diff -Nru statsvn-0.7.0.dfsg/debian/patches/patch-src_net_sf_statsvn_Main.java 
statsvn-0.7.0.dfsg/debian/patches/patch-src_net_sf_statsvn_Main.java
--- statsvn-0.7.0.dfsg/debian/patches/patch-src_net_sf_statsvn_Main.java
1970-01-01 02:00:00.0 +0200
+++ statsvn-0.7.0.dfsg/debian/patches/patch-src_net_sf_statsvn_Main.java
2021-08-03 08:05:38.0 +0300
@@ -0,0 +1,17 @@
+Skip SVN version check which doesn't work anymore with SVN 1.10.0
+
+--- a/src/net/sf/statsvn/Main.java.orig2018-06-25 06:52:30 UTC
 b/src/net/sf/statsvn/Main.java
+@@ -105,12 +105,6 @@ public final class Main {
+ public static void generate() {
+ try {
+ RepositoryFileManager manager = createRepoManager();
+-String version = 
manager.getProcessor().getVersionProcessor().checkSvnVersionSufficient();
+-final boolean isNewerDiffPossible = 
manager.getProcessor().getVersionProcessor().checkDiffPerRevPossible(version);
+-// fall-back to older option.
+-if (!isNewerDiffPossible) {
+-SvnConfigurationOptions.setLegacyDiff(true);
+-}
+ 
+ 
manager.getProcessor().getInfoProcessor().checkRepoRootAvailable();
+ generateDefaultHTMLSuite(manager);
diff -Nru statsvn-0.7.0.dfsg/debian/patches/series 
statsvn-0.7.0.dfsg/debian/patches/series
--- statsvn-0.7.0.dfsg/debian/patches/series2018-04-20 00:41:58.0 
+0300
+++ statsvn-0.7.0.dfsg/debian/patches/series2021-08-03 08:05:48.0 
+0300
@@ -1,3 +1,4 @@
 10-build-xml-classpath.diff
 15-build-xml-build-jar-only.diff
 20-remove-backport-util-concurrent.diff
+patch-src_net_sf_statsvn_Main.java

Bug#986527: Patches for flaky build and cython unavailability

[Tobias Hansen]

Thanks a lot for the patches Ahzo. Especially fixing the file handle leak 
should help a lot.

I guess it's too late for bullseye now, but I can at least upload a fixed 
package to experimental. I'll also try to fix many of the failing tests by 
including sage's (large) patch to support pari 2.13 which was finished in June 
[1]. I have to see if I can backport that to sage 9.2 or if I update to sage 
9.4 right away.

Best,
Tobias

[1] https://trac.sagemath.org/ticket/30801

On 7/31/21 8:47 PM, Ahzo wrote:
> Control: tags -1 patch
>
> Hi,
>
> the main problem making the sagemath testsuite flaky is that it randomly 
> aborts due to 'Too many open files'.
> Thus only a small part of the test suite gets actually run, when the build is 
> heavily parallelized.
> This can be seen by reporting not only the number of failed, but also that of 
> run tests, which shows significant fluctuations.
>
> The problem occurs, because every finished, but not yet logged worker, holds 
> an open fd (a pipe used to read the output of the child actually doing the 
> tests).
> Thus when following a long running worker, i.e. logging its messages, while 
> it is still running, so many finished tests can accumulate, that the open 
> files limit (ulimit -n) is reached.
>
> However, there should be no open pipe per finished worker, as the test suite 
> calls 'os.close(self.rmessages)' before waiting for logging the messages.
> So this seems to be caused by something that python does behind the scenes.
> Removing the single line 'finished.append(w)' in src/sage/doctest/forker.py 
> prevents the open fd increase, though at the cost of hardly logging any test 
> output.
>
> This problem can be avoided by simply logging every finished test, but no 
> running one.
>
> With only the 0001-Report-the-number-of-total-tests-run.patch, the result is 
> something like:
> Success: 5 of 71435 tests failed, up to 200 failures are tolerated
>
> Adding the dt-Do-not-follow-a-running-worker.patch, the result becomes:
> Success: 194 of 361139 tests failed, up to 200 failures are tolerated
>
> These 194 failures are pretty close to the threshold of 200, so it is not 
> particularly surprising, that this can fail in some environments.
> Slightly passing this threshold triggered the build failure in this bug and 
> also the one in bug #983931.
>
> Increasing the threshold to 300 should make that rather unlikely, though.
> And considering that there are more than 360 thousand tests, less then 300 
> failures means more than 99.9 % of the tests succeeded.
>
> The "cython: not found" issue is trivial to fix and important, because 
> otherwise 'sage --cython' does not work and there is no '--cython3' option 
> (unlike e.g. the '--ipython3' option).
>
> After adding the 0002-Tolerate-up-to-300-failing-tests.patch and the 
> u2-Adapt-to-python2-removal.patch the test result is:
> Success: 189 of 361139 tests failed, up to 300 failures are tolerated
>
> It would also be a good idea to include a backport of commit 5cf493ca51 
> ("Avoid libgmp's new lazy allocation") in the next sagemath upload, as that 
> fixes a severe memory leak (see bug #964848).
>
> As to the crashes, I can't reproduce any crash when testing 
> interfaces/singular.py:
> sage -t --long --random-seed=0 src/sage/interfaces/singular.py
>     [404 tests, 3.87 s]
>
> This crash also does not always happen for the reproducible builds either, 
> e.g. the following log shows it first crashing and then passing this test:
> https://tests.reproducible-builds.org/debian/rbuild/bullseye/amd64/sagemath_9.2-2.rbuild.log.gz
> [...]
> sage -t --long --random-seed=0 src/sage/interfaces/singular.py
>     Killed due to segmentation fault
> [...]
> sage -t --long --random-seed=0 src/sage/interfaces/singular.py
>     [404 tests, 21.06 s]
> [...]
>
> However, a number of other crashes happen during every test run, but only one 
> of them causes a test failure:
> sage -t --long --random-seed=0 src/sage/interfaces/tests.py
> **
> File "src/sage/interfaces/tests.py", line 34, in sage.interfaces.tests
> Failed example:
>     subprocess.call("echo syntax error | ecl", **kwds) in (0, 255)
> Expected:
>     True
> Got:
>     False
> **
>
> Similar crashes sometimes also occur when testing interfaces/lisp.py, but 
> without causing the test to fail.
> This is a problem in ecl, which crashes when both stdout and stderr are full, 
> see bug #710953.
>
> Then there is a crash in nauty-gentourng triggered by 
> src/sage/graphs/digraph_generators.py.
> For details see bug #991750.
>
> There are also two SIGABRT crashes in mwrank triggered by 
> src/sage/interfaces/mwrank.py.
> These seem to be intentional due to invalid input.
>
> Finally, there are some python crashes (5 SIGQUIT, 1 SIGABRT, 1 SIGSEGV) that 
> are all caused intentionally by the test suite.
>
> So none of these crashes are 

Bug#991847: libnuma-dev: Include pkgconfig file in dev package

[Florian Fischer]

Package: libnuma-dev
Version: 2.0.12-1
Severity: normal

Dear Maintainer,

* What led up to the situation?

I tried to consume libnuma using the meson build system, which uses
pkgconfig to find the appropriate compiler flags for project
dependencies.


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

Declare a dependency to libnuma in a meson build file:

numa_dep = dependency('numa')


* What was the outcome of this action?

meson could not determine how to use the installed libnuma.

meson output:
Run-time dependency numa found: NO (tried pkgconfig and cmake)
meson.build:13:0: ERROR: Dependency "numa" not found, tried pkgconfig and cmake


* What outcome did you expect instead?

On a arch-linux system where /usr/lib/pkgconfig/numa.pc is installed by the
numactl package (there is no libnuma-dev package equivalent) meson
can consume the installed libnuma.

Upstream provides a pkgconfig template at:
https://github.com/numactl/numactl/blob/master/numa.pc.in

Please consider shipping it in debian with the libnuma-dev package.
Thanks for your work.
Florian Fischer


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

Kernel: Linux 5.10.0-0.bpo.8-amd64 (SMP w/48 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libnuma-dev depends on:
ii  libc6-dev [libc-dev]  2.28-10
ii  libnuma1  2.0.12-1

libnuma-dev recommends no packages.

libnuma-dev suggests no packages.

-- no debconf information

Bug#991802: ITP: fonts-vazir -- A free sans font for Persian and Arabic

[eshagh094]

I asked the upstream repository holder to remove those pre-made fonts.

I have already created a test package on my computer and put it in my
PPA in the launchpad and it worked fine.
https://launchpad.net/~eshagh79/+archive/ubuntu/fonts

In this package, I just put the fonts in TTF format and for
installation, copy them to /usr/share/fonts/truetype/vazir/*.ttf.

This is an easy method for me, but I have to manually update the package
every time the font is updated.

Do you think this method is correct?
Another question is how and where should I upload this trial package to
use it in Debian or Ubuntu?

Bug#991788: xfce4-settings: black screen after suspend when laptop lid is closed and re-opened

[Andres Salomon]

On Mon, 2 Aug 2021 02:08:09 +0200 (CEST) truetec...@tutanota.com wrote:
> Package: xfce4-settings
> Version: 4.16.0-1
> Severity: critical
>

> On Debian and, by extension, Ubuntu, when suspending a laptop via 
closing the lid on XFCE, the screen stays black after resuming from 
suspend. The only way to "fix" the system is to blindly type "xrandr 
--auto" into a terminal or switch to a TTY and restart X.


As an xfce user, I haven't experienced this problem. What graphics 
hardware and kernel are you seeing this with? Is this on battery or when 
plugged in? Are you using light-locker (and if so, what version)? Do you 
have upower installed (and if so, what version)? What is xfce4 
configured to do on a lid close (xfconf-query --verbose --list -c 
xfce4-power-manager)?

Bug#991846: unblock: openjdk-17/17~33ea-1

[Matthias Klose]

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

Please unblock openjdk-17, the next openjdk-17 snapshot build, also including
security fixes from the last openjdk-11 security release. That could be done as
a security update as well, the unblock would just avoid that extra work.

The only packaging change is to mark the early-access status in the Debian
package versions.

Not attaching a debdiff compared to the version in testing, it's huge.

openjdk-17 (17~33ea-1) unstable; urgency=high

  * OpenJDK 17 snapshot, build 33.
  * Regenerate the control file.

 -- Matthias Klose   Fri, 30 Jul 2021 14:48:42 +0200

openjdk-17 (17~32ea-1) unstable; urgency=high

  * OpenJDK 17 snapshot, build 32.
  * Security fixes:
- JDK-8256157: Improve bytecode assembly.
- JDK-8256491: Better HTTP transport.
- JDK-8258432, CVE-2021-2341: Improve file transfers.
- JDK-8260453: Improve Font Bounding.
- JDK-8260960: Signs of jarsigner signing.
- JDK-8260967, CVE-2021-2369: Better jar file validation.
- JDK-8262380: Enhance XML processing passes.
- JDK-8262403: Enhanced data transfer.
- JDK-8262410: Enhanced rules for zones.
- JDK-8262477: Enhance String Conclusions.
- JDK-8262967: Improve Zip file support.
- JDK-8264066, CVE-2021-2388: Enhance compiler validation.
- JDK-8264079: Improve abstractions.
- JDK-8264460: Improve NTLM support.

 -- Matthias Klose   Mon, 26 Jul 2021 11:25:32 +0200

openjdk-17 (17~31ea-1) unstable; urgency=medium

  * OpenJDK 17 snapshot, build 31.
  * Encode the early-access status into the package version. LP: #1934895.

 -- Matthias Klose   Sat, 17 Jul 2021 14:25:02 +0200

openjdk-17 (17~29-1) unstable; urgency=medium

  * OpenJDK 17 snapshot, build 29.
  * Update watch file.
  * Prepare to build with jtreg6, where available.

 -- Matthias Klose   Thu, 01 Jul 2021 16:42:23 +0200

openjdk-17 (17~27-1) unstable; urgency=medium

  * OpenJDK 17 snapshot, build 27.
  * Only build using lto with GCC 11.
  * Build using GCC 11 in recent distributions.
  * Update VCS attributes.
  * Disable runnning the tests, requires not yet packaged jtreg6.
  * Remove rimd, removed upstream.

 -- Matthias Klose   Fri, 18 Jun 2021 15:06:18 +0200

openjdk-17 (17~24-1) unstable; urgency=medium

  * OpenJDK 17 snapshot, build 24.
  * Drop the work around for JDK 8211105.
  * Remove jaotc (the experimental JIT compiler), removed upstream.
  * Add an (unapplied) patch to replace OASIS header files with ones
imported from NSPR and NSS. See #985765.  Not reviewed, not applying.

 -- Matthias Klose   Thu, 27 May 2021 11:26:59 +0200

Bug#986821: freecad: Garbled menu makes freecad unusable

[jaroslav]

Hello,

I found this bug report trying to troubleshoot the same issue - for me, 
FreeCAD UI is completely garbled, all menu items, all icons, all other 
UI elements are larger than the space allocated for them, resulting in 
"create new empty document" icon being cut after 90% of its length, 
"open document" after 60% etc. making 4th icon barely visible and rest 
completely invisible. Essentially, the UI element graphics is being 
drawn into different positions compared to where those elements are 
actually placed in the UI.


Since the symptoms were the same for me - no issue for clean slate 
system user - I tried the strace approach. But even after filtering 
things that are the same out, I was unsuccessful. However, using the 
QT_SCALE_FACTOR=1 QT_AUTO_SCREEN_SCALE_FACTOR=0 variables made the thing 
work and eventually I figured out the problem is caused by my monitor 
DPI settings (xfce4-settings-manager -> Appearance -> Fonts -> Custom 
DPI settings)


I have this value set to 80. Tried changing it to "default" 96 and that 
fixed the issue for me.


I would say this is a FreeCAD bug though, according to my x.org log, my 
monitor does have 80DPI:


(++) RADEON(0): DPI set to (80, 80)

(The monitor has 59.6x33.6cm screen dimensions with 1920x1080 
resolution, which also amounts to 80DPI.)


As far as I know (was told once by some develeper), developers tend to 
assume that every monitor has 96DPI and write programs accordingly. 
Might be the case here.

Bug#991845: unblock: libx11/2:1.7.2-1

[Timo Aaltonen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: b...@debian.org mzagr...@d.umn.edu

Please unblock package libx11

[ Reason ]
The new upstream release fixes regressions in the previous CVE release, 
including a segfault in fdesign. (bug 990998)

[ Impact ]
Regressions remain in bullseye release.

[ Tests ]
The new version has a commit that fixes a bug with a similar backtrace as 
990998, Matt can verify here that fdesign works with the new libx11.

[ Risks ]
The upstream changes are small, only three commits, 

[ 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 ]
The diff is filtered to have only changes to the code and packaging, autotools 
changes are removed.

unblock libx11/2:1.7.2-1
diff -Nru libx11-1.7.1/configure.ac libx11-1.7.2/configure.ac
--- libx11-1.7.1/configure.ac   2021-05-18 17:14:20.0 +0300
+++ libx11-1.7.2/configure.ac   2021-06-06 19:48:52.0 +0300
@@ -1,7 +1,7 @@
 
 # Initialize Autoconf
 AC_PREREQ([2.60])
-AC_INIT([libX11], [1.7.1],
+AC_INIT([libX11], [1.7.2],
 [https://gitlab.freedesktop.org/xorg/lib/libx11/issues], [libX11])
 AC_CONFIG_SRCDIR([Makefile.am])
 AC_CONFIG_HEADERS([src/config.h include/X11/XlibConf.h])
diff -Nru libx11-1.7.1/debian/changelog libx11-1.7.2/debian/changelog
--- libx11-1.7.1/debian/changelog   2021-08-03 11:34:34.0 +0300
+++ libx11-1.7.2/debian/changelog   2021-08-03 11:34:35.0 +0300
@@ -1,3 +1,13 @@
+libx11 (2:1.7.2-1) unstable; urgency=medium
+
+  [ Timo Aaltonen ]
+  * New upstream release. (Closes: #990998)
+
+  [ Julien Cristau ]
+  * Fix Vcs-Git control field.
+
+ -- Timo Aaltonen   Mon, 26 Jul 2021 11:29:39 +0300
+
 libx11 (2:1.7.1-1) unstable; urgency=medium
 
   [ Julien Cristau ]
diff -Nru libx11-1.7.1/debian/control libx11-1.7.2/debian/control
--- libx11-1.7.1/debian/control 2021-08-03 11:34:34.0 +0300
+++ libx11-1.7.2/debian/control 2021-08-03 11:34:35.0 +0300
@@ -17,7 +17,7 @@
  xorg-sgml-doctools (>= 1:1.10),
  w3m,
 Standards-Version: 4.5.0
-Vcs-Git: https://salsa.debian.org/xorg-team/lib/libx11
+Vcs-Git: https://salsa.debian.org/xorg-team/lib/libx11.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/lib/libx11
 
 Package: libx11-6
diff -Nru libx11-1.7.1/README.md libx11-1.7.2/README.md
--- libx11-1.7.1/README.md  2021-05-18 17:14:20.0 +0300
+++ libx11-1.7.2/README.md  2021-06-06 19:48:52.0 +0300
@@ -31,6 +31,11 @@
 
   https://www.x.org/wiki/Development/Documentation/SubmittingPatches
 
+## Release 1.7.2
+
+This is a bug fix release, correcting a regression introduced by and
+improving the checks from the fix for CVE-2021-31535.
+
 ## Release 1.7.1
 
 This is a bug fix release, including a security fix for
diff -Nru libx11-1.7.1/src/Font.c libx11-1.7.2/src/Font.c
--- libx11-1.7.1/src/Font.c 2021-05-18 17:14:33.0 +0300
+++ libx11-1.7.2/src/Font.c 2021-06-06 19:48:53.0 +0300
@@ -102,7 +102,7 @@
 XF86BigfontCodes *extcodes = _XF86BigfontCodes(dpy);
 #endif
 
-if (strlen(name) >= USHRT_MAX)
+if (name != NULL && strlen(name) >= USHRT_MAX)
 return NULL;
 if (_XF86LoadQueryLocaleFont(dpy, name, _result, (Font *)0))
   return font_result;
@@ -656,7 +656,7 @@
XFontStruct **xfp,
Font *fidp)
 {
-int l;
+size_t l;
 const char *charset, *p;
 char buf[256];
 XFontStruct *fs;
@@ -664,7 +664,7 @@
 
 if (!name)
return 0;
-l = (int) strlen(name);
+l = strlen(name);
 if (l < 2 || name[l - 1] != '*' || name[l - 2] != '-' || l >= USHRT_MAX)
return 0;
 charset = NULL;
@@ -677,11 +677,11 @@
charset = "ISO8859-1";
p = charset + 7;
 }
-if (l - 2 - (p - charset) < 0)
+if (l - 2 < p - charset)
return 0;
 if (_XlcNCompareISOLatin1(name + l - 2 - (p - charset), charset, p - 
charset))
return 0;
-if (strlen(p + 1) + (size_t) l - 1 >= sizeof(buf) - 1)
+if (strlen(p + 1) + l - 1 >= sizeof(buf) - 1)
return 0;
 strcpy(buf, name);
 strcpy(buf + l - 1, p + 1);
diff -Nru libx11-1.7.1/src/FontInfo.c libx11-1.7.2/src/FontInfo.c
--- libx11-1.7.1/src/FontInfo.c 2021-05-18 17:14:33.0 +0300
+++ libx11-1.7.2/src/FontInfo.c 2021-06-06 19:48:53.0 +0300
@@ -58,7 +58,7 @@
 register xListFontsReq *req;
 int j;
 
-if (strlen(pattern) >= USHRT_MAX)
+if (pattern != NULL && strlen(pattern) >= USHRT_MAX)
 return NULL;
 
 LockDisplay(dpy);
diff -Nru libx11-1.7.1/src/FontNames.c libx11-1.7.2/src/FontNames.c
--- libx11-1.7.1/src/FontNames.c2021-05-18 17:14:33.0 +0300
+++ libx11-1.7.2/src/FontNames.c2021-06-06 19:48:53.0 +0300
@@ -51,7 +51,7 @@
 register xListFontsReq *req;
 unsigned long rlen = 0;
 
-if (strlen(pattern) >= USHRT_MAX)
+if 

Bug#991813: net-smnp packaging team also suitable for other snmp packages?

[Tobias Frost]

Dear net-snmp maintainers,

I'm pondering with packaging snmpb [1] and its dependencies
netsmp++ [2] and an updated libsmi [3].

Best of course would be that the packages would be team maintained,
so I'm wondering if the net-snmp would be open to the idea to expand their
scope to handle also such packages.

Let me know, you thoughts!

-- 
tobi


[1] https://sourceforge.net/projects/snmpb/ 
[2] https://www.agentpp.com/api/cpp/snmp_pp.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991813


signature.asc
Description: PGP signature

Bug#991844: unblock: libpam-tacplus/1.3.8-2.1

[Utkarsh Gupta]

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

Hey,

src:libpam-tacplus has been affected by CVE-2020-13881 which is fixed
in sid & stretch. -pu update for buster is also being filed. This
update also helps in fixing the versioning problem because as of now,
the version in stretch is greater than that in stable and sid. So this
update will help fix things for sid and bullseye, at least.

Since this is just a CVE fix, I'd request you to unblock this and let
it go to bullseye, please? (I am sorry for doing this on the eleventh
hour :/)

The debdiff is duly attached. Let me know if you any more information. TIA! \o/


- u


libpam-tacplus_sid.debdiff
Description: Binary data

Bug#991843: unblock: libjdom2-java/2.0.6-1.1

[Utkarsh Gupta]

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

Hey,

src:libjdom2-java has been affected by CVE-2021-33813 which is fixed
in sid & stretch. -pu update for buster is also being filed.

Since this is just a CVE fix, I'd request you to unblock this and let
it go to bullseye, please? (I am sorry for doing this on the eleventh
hour :/)

The debdiff is duly attached. Let me know if you any more information. TIA! \o/


- u


libjdom2-java_sid.debdiff
Description: Binary data

Bug#991842: unblock: libjdom1-java/1.1.3-2.1

[Utkarsh Gupta]

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

Hey,

src:libjdom1-java has been affected by CVE-2021-33813 which is fixed
in sid & stretch. -pu update for buster is also being filed.

Since this is just a CVE fix, I'd request you to unblock this and let
it go to bullseye, please? (I am sorry for doing this on the eleventh hour :/)

The debdiff is duly attached. Let me know if you any more information. TIA! \o/


- u


libjdom1-java_sid.debdiff
Description: Binary data

Bug#991841: unblock: perm/0.4.0-6

[Nilesh Patra]

control: retitle -1 perm/0.4.0-7

On Tue, 3 Aug 2021 09:39:04 +0200 Sebastian Ramacher  
wrote:
>> Control: tags -1 moreinfo
>> +-inline char* myStrCpy(char* caBuf, const char* str, int iBufSize)
>> ++inline int myStrCpy(char* caBuf, const char* str, int iBufSize)
>> + {
>> + if (caBuf == NULL) {
>> + ERR;
>> +-return(NULL);
>> ++return(-1);
>> + }
>> + int iBufSizeMinus1 = iBufSize - 1;
>> +-char* returnV = strncpy(caBuf, str, iBufSizeMinus1);
>> ++int returnV = strlcpy(caBuf, str, iBufSizeMinus1);

> The interesting thing about strlcpy is that you don't have to deal with
> this -1 nonsense and the explicit NUL-termination that follows. In fact,
> this patch now makes every buffer 1 byte smaller. strlcpy copies
> iBufSizeMinus1 - 1 characters in this case. Is that intended?

Aw, crap, no. I got sloppy here. I just did another upload on top of it, to
copy right buffer length, retitled accordingly.
Hopefully this should be fine now.
The debdiff is also attached w/ the version in testing

> I agree that this issue should be fixed, but I'm not sure if it is
> necessary to rush a fix now.

IMO, if this fixed is not merged now, I'll have to push it to next
stable point release, creating more work for everyone, and also passing
in this seemingly RC bug to the first release.
Being a leaf package with a relatively low popcon score, I think it is
not going to do a lot of damage, and I think it
would be really really great if you consider to let this in now, than later.
Upstream is not active, and I do not expect much from them.

Ofcourse, I agree that this creates some last minute noise+work for
the release team and I'm really
sorry about this -- it was discovered just yesterday, and I uploaded
after enough ACKs as soon as I found a relevant workaround.
But I'd be obliged if you consider to let this in.

Nilesh
diff -Nru perm-0.4.0/debian/changelog perm-0.4.0/debian/changelog
--- perm-0.4.0/debian/changelog 2020-11-24 14:40:20.0 +0530
+++ perm-0.4.0/debian/changelog 2021-08-03 13:17:48.0 +0530
@@ -1,3 +1,31 @@
+perm (0.4.0-7) unstable; urgency=medium
+
+  * Team Upload.
+  * d/p/fix-buffer-overflow.patch: Do not reduce buffer size by 1
+
+ -- Nilesh Patra   Tue, 03 Aug 2021 13:17:48 +0530
+
+perm (0.4.0-6) unstable; urgency=medium
+
+  * Team Upload.
+  [ Shruti Sridhar ]
+  * d/tests/data: Add testdata
+  * d/tests: Add autopkgtest
+  * d/example: Install test data as example
+  * d/docs: Install d/README.* and d/tests/run-unit-test
+as documents
+  * d/p/hardening.patch: Add CPPFLAGS which helped detect
+buffer overflow
+  * d/copyright: Test data has been written by Shruti, mentioning
+them in copyright for the same
+
+  [ Nilesh Patra ]
+  * d/p/fix-buffer-overflow.patch: Use strlcpy from libbsd-dev
+instead of strncpy in order to fix buffer overflow
+  * d/control: Add B-D on libbsd-dev
+
+ -- Nilesh Patra   Tue, 03 Aug 2021 00:31:10 +0530
+
 perm (0.4.0-5) unstable; urgency=medium
 
   * Standards-Version: 4.5.1 (routine-update)
diff -Nru perm-0.4.0/debian/control perm-0.4.0/debian/control
--- perm-0.4.0/debian/control   2020-11-24 14:40:20.0 +0530
+++ perm-0.4.0/debian/control   2021-08-02 21:22:22.0 +0530
@@ -3,7 +3,7 @@
 Uploaders: Andreas Tille 
 Section: science
 Priority: optional
-Build-Depends: debhelper-compat (= 13)
+Build-Depends: debhelper-compat (= 13), libbsd-dev
 Standards-Version: 4.5.1
 Vcs-Browser: https://salsa.debian.org/med-team/perm
 Vcs-Git: https://salsa.debian.org/med-team/perm.git
diff -Nru perm-0.4.0/debian/copyright perm-0.4.0/debian/copyright
--- perm-0.4.0/debian/copyright 2020-11-24 14:40:20.0 +0530
+++ perm-0.4.0/debian/copyright 2021-08-03 00:41:56.0 +0530
@@ -12,6 +12,10 @@
2014-2017 Andreas Tille 
 License: Apache-2.0
 
+Files: debian/tests/data/*
+Copyright: Shruti Sridhar 
+License: Apache-2.0
+
 License: Apache-2.0
  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
diff -Nru perm-0.4.0/debian/docs perm-0.4.0/debian/docs
--- perm-0.4.0/debian/docs  1970-01-01 05:30:00.0 +0530
+++ perm-0.4.0/debian/docs  2021-08-02 17:25:32.0 +0530
@@ -0,0 +1,2 @@
+debian/README*
+debian/tests/run-unit-test
\ No newline at end of file
diff -Nru perm-0.4.0/debian/examples perm-0.4.0/debian/examples
--- perm-0.4.0/debian/examples  1970-01-01 05:30:00.0 +0530
+++ perm-0.4.0/debian/examples  2021-08-02 17:25:32.0 +0530
@@ -0,0 +1 @@
+debian/tests/data/*
\ No newline at end of file
diff -Nru perm-0.4.0/debian/patches/fix-buffer-overflow.patch 
perm-0.4.0/debian/patches/fix-buffer-overflow.patch
--- perm-0.4.0/debian/patches/fix-buffer-overflow.patch 1970-01-01 
05:30:00.0 +0530
+++ perm-0.4.0/debian/patches/fix-buffer-overflow.patch 2021-08-03 
13:14:38.0 +0530
@@ -0,0 +1,42 @@
+Description: Use strlcpy from libbsd-dev instead of 

Bug#991813: libsmi: New upstream version 0.5.0 available.

[Vincent Bernat]

 ❦  3 August 2021 08:33 +02, Tobias Frost:

>> > So -- my 2 cent -- I would even package trunk of the git repo, it would
>> > be much better than the more-than-adecade(!) old version in Debian.
>> 
>> If you have some time, feel free to take over the package. I have too
>> much on my plate currently.
>> 
>> > Regarding ABI: I've diffed the 0.4.8 smi.h with the 0.5.0 one:
>> > all those changes should not be ABI changing.
>> 
>> Thanks for checking. If you don't want to take over the package, I'll
>> try to find some time to update to 0.5.0.
>
> Lets form a team or maybe ask the net-snmp people if they would be ok
> in expanding the scope towards are more snmp team?

Whatever you see fit. I don't think the SNMP team has much bandwidth
either, so I wouldn't go through the trouble.
-- 
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain

Bug#991787: unblock: ucspi-unix/1.0-2

[Peter Pentchev]

On Tue, Aug 03, 2021 at 09:19:27AM +0200, Sebastian Ramacher wrote:
> On 2021-08-02 01:52:18 +0300, Peter Pentchev wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: r...@debian.org
> > 
> > This is a pre-approval request before I upload ucspi-unix to
> > unstable to fix a FTBFS on architectures where dietlibc is
> > not built; see #991774.
> 
> None of the release architectures are affected by this bug, so this
> sounds like bookworm material to me. It's too late for this type of
> changes, sorry.

No worries, thanks for your time!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#991841: unblock: perm/0.4.0-6

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-08-03 11:19:46 +0530, Nilesh Patra wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: nil...@debian.org, debian-med-packag...@lists.alioth.debian.org
> 
> Please unblock package perm
> 
> [ Reason ]
> An autopkgtest was recently added to perm on its git repository, which
> resulted in uncovering a buffer overflow. Here's the log:
> 
> https://salsa.debian.org/med-team/perm/-/jobs/1788156
> 
> AIUI, this is a security issue and such issues are RC
> 
> [ Impact ]
> The users machine will contain a version of perm which can potentially
> cause a buffer overflow
> 
> [ Tests ]
> Autopkgtests have been added for this release
> 
> [ Risks ]
> Perm is a leaf package, I do not see any risks
> 
> [ 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 ]
> Some stuff like installing docs in d/docs, or installing autopkgtests in
> d/examples might look redundant, but they are needed to run tests in a
> sane fashion. These changes are not too major, and are rather harmless.
> 
> unblock perm/0.4.0-6

> diff -Nru perm-0.4.0/debian/changelog perm-0.4.0/debian/changelog
> --- perm-0.4.0/debian/changelog   2020-11-24 14:40:20.0 +0530
> +++ perm-0.4.0/debian/changelog   2021-08-03 00:31:10.0 +0530
> @@ -1,3 +1,24 @@
> +perm (0.4.0-6) unstable; urgency=medium
> +
> +  * Team Upload.
> +  [ Shruti Sridhar ]
> +  * d/tests/data: Add testdata
> +  * d/tests: Add autopkgtest
> +  * d/example: Install test data as example
> +  * d/docs: Install d/README.* and d/tests/run-unit-test
> +as documents
> +  * d/p/hardening.patch: Add CPPFLAGS which helped detect
> +buffer overflow
> +  * d/copyright: Test data has been written by Shruti, mentioning
> +them in copyright for the same
> +
> +  [ Nilesh Patra ]
> +  * d/p/fix-buffer-overflow.patch: Use strlcpy from libbsd-dev
> +instead of strncpy in order to fix buffer overflow
> +  * d/control: Add B-D on libbsd-dev
> +
> + -- Nilesh Patra   Tue, 03 Aug 2021 00:31:10 +0530
> +
>  perm (0.4.0-5) unstable; urgency=medium
>  
>* Standards-Version: 4.5.1 (routine-update)
> diff -Nru perm-0.4.0/debian/control perm-0.4.0/debian/control
> --- perm-0.4.0/debian/control 2020-11-24 14:40:20.0 +0530
> +++ perm-0.4.0/debian/control 2021-08-02 21:22:22.0 +0530
> @@ -3,7 +3,7 @@
>  Uploaders: Andreas Tille 
>  Section: science
>  Priority: optional
> -Build-Depends: debhelper-compat (= 13)
> +Build-Depends: debhelper-compat (= 13), libbsd-dev
>  Standards-Version: 4.5.1
>  Vcs-Browser: https://salsa.debian.org/med-team/perm
>  Vcs-Git: https://salsa.debian.org/med-team/perm.git
> diff -Nru perm-0.4.0/debian/copyright perm-0.4.0/debian/copyright
> --- perm-0.4.0/debian/copyright   2020-11-24 14:40:20.0 +0530
> +++ perm-0.4.0/debian/copyright   2021-08-03 00:31:10.0 +0530
> @@ -12,6 +12,10 @@
> 2014-2017 Andreas Tille 
>  License: Apache-2.0
>  
> +Files: debian/tests/data/*
> +Copyright: Shruti Sridhar 
> +License: Apache-2.0
> +
>  License: Apache-2.0
>   Unless required by applicable law or agreed to in writing, software
>   distributed under the License is distributed on an "AS IS" BASIS,
> diff -Nru perm-0.4.0/debian/docs perm-0.4.0/debian/docs
> --- perm-0.4.0/debian/docs1970-01-01 05:30:00.0 +0530
> +++ perm-0.4.0/debian/docs2021-08-02 17:25:32.0 +0530
> @@ -0,0 +1,2 @@
> +debian/README*
> +debian/tests/run-unit-test
> \ No newline at end of file
> diff -Nru perm-0.4.0/debian/examples perm-0.4.0/debian/examples
> --- perm-0.4.0/debian/examples1970-01-01 05:30:00.0 +0530
> +++ perm-0.4.0/debian/examples2021-08-02 17:25:32.0 +0530
> @@ -0,0 +1 @@
> +debian/tests/data/*
> \ No newline at end of file
> diff -Nru perm-0.4.0/debian/patches/fix-buffer-overflow.patch 
> perm-0.4.0/debian/patches/fix-buffer-overflow.patch
> --- perm-0.4.0/debian/patches/fix-buffer-overflow.patch   1970-01-01 
> 05:30:00.0 +0530
> +++ perm-0.4.0/debian/patches/fix-buffer-overflow.patch   2021-08-03 
> 00:30:42.0 +0530
> @@ -0,0 +1,42 @@
> +Description: Use strlcpy from libbsd-dev instead of strncpy in order to 
> avoid buffer overflow
> +Author: Nilesh Patra 
> +Last-Update: 2021-08-03
> +--- a/makefile
>  b/makefile
> +@@ -2,7 +2,7 @@
> + CC = g++ -O2 $(CFLAGS)
> + 
> + TARGETS = perm
> +-LIBS = -lm -lstdc++ 
> ++LIBS = -lm -lstdc++ -lbsd 
> +  
> + PER_M = AlignmentsQ.cpp Filename.cpp GenomeNTdata.cpp ReadInBits.cpp 
> PerM.cpp chromosomeNTdata.cpp\
> + bitsOperationUtil.cpp FileOutputBuffer.cpp HashIndexT.cpp ReadInBitsSet.cpp 
> SeedPattern.cpp\
> +--- a/stdafx.h
>  b/stdafx.h
> +@@ -12,6 +12,7 @@
> + #include 
> + #include "time.h"
> + #include "Filename.h"
> ++#include 
> + 

Bug#991839: [debian-mysql] Bug#991839: mariadb-server-10.3: MariaDB intermittantly not starting on boot on AWS EC2 t2.medium instance

[Jeremy Davis]

Hi Otto,

On 3/8/21 15:13, Otto Kekäläinen wrote:

Thanks for the report!



You're most welcome. Thanks for the quick response!


Could you do a favour and test and identical scenario with Debian
Bullseye and the MariaDB 10.5 in it?



Done.

I can NOT reproduce the issue in Bullseye! :)



FWIW, I took a snapshot of my current server; removed the workaround and 
upgraded to bullseye. I rebooted 5 or six times and MariaDB restarted 
cleanly every time! :)


Following that, on the off chance that there may be some service file 
change that helps, I tried pulling the newer service file into my 
original Buster server. I had to tweak it a little to get it to play 
nice with the older systemd. But after doing that, the issue is back 
again. :(


So a 1 second pre-start sleep it is until Bullseye...

Regards,
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991830: unblock: linux/5.10.46-4

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo

Hi Paul,

On Mon, Aug 02, 2021 at 10:53:00PM +0200, Paul Gevers wrote:
> Control: tags -1 confirmed moreinfo
> 
> Hi Salvatore,
> 
> On 02-08-2021 22:19, Salvatore Bonaccorso wrote:
> > Upstream added in 5.13-rc4 a new kconfig know to diable unprivilged
> > bpf by default, but without making it irreversible. I cherry-picked
> > this commit as well, and set BPF_UNPRIV_DEFAULT_OFF, closing #990411.
> 
> I wonder if this would warrant a NEWS item and if you have time left to
> squeeze it in.

Yes, I have added a NEWS entry accordingly describing the default in
Debian staring with the 5.10.46-4 upload. Thanks for raising this.

> > Would you agree on such a very short timed upload still to be
> > targetting for bullseye?
> 
> If all (including magic of signing) can be build and ready for Saturday
> I think this issue is worth it. Normally you kernel people know very
> well what you're doing.

Thank you for the ack, this is very much appreciated. The full set of
changes, for the record were (but not adding a debdiff now):

   * bpf: Introduce BPF nospec instruction for mitigating Spectre v4
 (CVE-2021-34556, CVE-2021-35477)
   * bpf: Fix leakage due to insufficient speculative store bypass mitigation
 (CVE-2021-34556, CVE-2021-35477)
   * bpf: Remove superfluous aux sanitation on subprog rejection
   * Ignore ABI changes for bpf_offload_dev_create and bpf_verifier_log_write
   * bpf: Add kconfig knob for disabling unpriv bpf by default
   * init: Enable BPF_UNPRIV_DEFAULT_OFF (Closes: #990411)
   * linux-image: Add NEWS entry documenting that unprivileged calls to bpf() 
are
 disabled by default in Debian.
   * bpf: verifier: Allocate idmap scratch in verifier env
   * bpf: Fix pointer arithmetic mask tightening under state pruning

Regards,
Salvatore

Bug#991837: /usr/lib/python3/dist-packages/gbp/scripts/supercommand.py: import-orig failure

[Guido Günther]

control: reassign -1 pristine-tar
control: affects -1 git-buildpackage

Hi Steve,
On Mon, Aug 02, 2021 at 08:41:12PM -0500, Steve M. Robbins wrote:
> Package: git-buildpackage
> Version: 0.9.22
> Severity: normal
> File: /usr/lib/python3/dist-packages/gbp/scripts/supercommand.py
> 
> Dear Maintainer,
> 
> I attempted to import a new version into 'experimental' branches using: "gbp 
> import-orig --pristine-tar --upstream-branch=upstream-experimental 
> --debian-branch=experimental  ~/Downloads/digikam-7.3.0.tar.xz"
> 
> It "failed to reproduce build of ../digikam_7.3.0.orig.tar.xz"
> 
> Run with --verbose:
> 
> gbp:debug: ['git', 'rev-parse', '--show-cdup']
> gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
> gbp:debug: ['git', 'rev-parse', '--git-dir']
> gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
> gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream-experimental']
> gbp:debug: ['git', 'status', '--porcelain']
> What is the upstream version? [7.3.0] 
> gbp:debug: ['git', 'tag', '-l', 'upstream/7.3.0']
> gbp:debug: tar ['-C', '../tmpbk46rf8d', '-a', '-xf', 
> '/home/steve/Downloads/digikam-7.3.0.tar.xz'] []
> gbp:debug: Unpacked '/home/steve/Downloads/digikam-7.3.0.tar.xz' to 
> '../tmpbk46rf8d/digikam-7.3.0'
> gbp:info:  path='/home/steve/Downloads/digikam-7.3.0.tar.xz' signaturefile=None>
> gbp:info: Importing '/home/steve/Downloads/digikam-7.3.0.tar.xz' to branch 
> 'upstream-experimental'...
> gbp:info: Source package is digikam
> gbp:info: Upstream version is 7.3.0
> gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream-experimental']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 
> 'upstream-experimental']
> gbp:debug: ['git', 'add', '-f', '.']
> gbp:debug: ['git', 'write-tree']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 
> 'upstream-experimental']
> gbp:debug: ['git', 'commit-tree', 'f8eadb9d14b1596e9f6ab263a895230a71614291', 
> '-p', '2090afd33254af7acfdd2fd5e57a77cc270fa584']
> gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 7.3.0', 
> 'refs/heads/upstream-experimental', 
> '5f5a4bf691c048b5c7a9b9641b55af38193f2e23', 
> '2090afd33254af7acfdd2fd5e57a77cc270fa584']
> gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
> gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar']
> gbp:debug: ['git', 'ls-tree', '-z', 'upstream-experimental', '--']
> gbp:debug: ['git', 'mktree', '-z']
> gbp:debug: pristine-tar [] ['commit', '../digikam_7.3.0.orig.tar.xz', 
> 'f8eadb9d14b1596e9f6ab263a895230a71614291']
> gbp:error: Import of ../digikam_7.3.0.orig.tar.xz failed: Couldn't commit to 
> 'pristine-tar' with upstream 'f8eadb9d14b1596e9f6ab263a895230a71614291': 
> pristine-xz failed to reproduce build of ../digikam_7.3.0.orig.tar.xz
> (Please file a bug report.)

This is the problem. pristine-tar (which gets invoked by gbp) fails to
build a reproducible tarball for digikam_7.3.0.orig.tar.xz so
reassigning there.

Cheers,
 -- Guido


> pristine-tar: failed to generate delta
> gbp:error: Error detected, Will roll back changes.
> gbp:info: Rolling back branch upstream-experimental by resetting it to 
> 2090afd33254af7acfdd2fd5e57a77cc270fa584
> gbp:debug: ['git', 'update-ref', '-m', 'gbp import-orig: failure rollback of 
> upstream-experimental', 'refs/heads/upstream-experimental', 
> '2090afd33254af7acfdd2fd5e57a77cc270fa584']
> gbp:info: Rolling back branch pristine-tar by resetting it to 
> 0505953bee2887d1fef8d301b0d852773a178ac6
> gbp:debug: ['git', 'update-ref', '-m', 'gbp import-orig: failure rollback of 
> pristine-tar', 'refs/heads/pristine-tar', 
> '0505953bee2887d1fef8d301b0d852773a178ac6']
> gbp:error: Rolled back changes after import error.
> gbp:debug: rm ['-rf', '../tmpbk46rf8d'] []
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing
>   APT policy: (500, 'testing'), (200, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_CA:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages git-buildpackage depends on:
> ii  devscripts 2.21.3
> ii  git1:2.30.2-1
> ii  man-db 2.9.4-2
> ii  python33.9.2-3
> ii  python3-dateutil   2.8.1-6
> ii  python3-pkg-resources  52.0.0-4
> ii  sensible-utils 0.0.14
> 
> Versions of packages git-buildpackage recommends:
> ii  cowbuilder0.89
> ii  pbuilder  0.231
> ii  pristine-tar  1.49
> ii  python3-requests  2.25.1+dfsg-2
> ii  sbuild0.81.2
> 
> Versions of packages git-buildpackage suggests:
> ii  python3-notify2  0.3-4
> ii  sudo 1.9.5p2-3
> ii  unzip

Bug#962439: sctk: diff for NMU version 2.4.10-20151007-1312Z+dfsg2-3.1

[Adrian Bunk]

Dear maintainer,

I've prepared an NMU for sctk (versioned as 2.4.10-20151007-1312Z+dfsg2-3.1).
The diff is attached to this message.

cu
Adrian
diff -Nru sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog
--- sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog	2016-04-27 19:42:33.0 +0300
+++ sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog	2021-08-03 09:44:24.0 +0300
@@ -1,3 +1,12 @@
+sctk (2.4.10-20151007-1312Z+dfsg2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch by Michael Hudson-Doyle to use pdftoppm instead
+of convert to convert pdf to jpg as the latter fails with the
+changed security policy of ImageMagick. (Closes: #962439)
+
+ -- Adrian Bunk   Tue, 03 Aug 2021 09:44:24 +0300
+
 sctk (2.4.10-20151007-1312Z+dfsg2-3) unstable; urgency=medium
 
   * Fix an error in replacement files Makefile.
diff -Nru sctk-2.4.10-20151007-1312Z+dfsg2/debian/control sctk-2.4.10-20151007-1312Z+dfsg2/debian/control
--- sctk-2.4.10-20151007-1312Z+dfsg2/debian/control	2016-04-27 19:42:33.0 +0300
+++ sctk-2.4.10-20151007-1312Z+dfsg2/debian/control	2021-08-03 09:44:12.0 +0300
@@ -8,6 +8,7 @@
  dh-buildinfo,
  dpkg-dev (>= 1.16.1~),
  librsvg2-bin,
+ poppler-utils,
  texlive-latex-base,
  texlive-latex-extra,
  imagemagick,
diff -Nru sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile
--- sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile	2016-04-27 19:42:33.0 +0300
+++ sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile	2021-08-03 09:43:34.0 +0300
@@ -34,7 +34,7 @@
 all: $(OUTPUT)
 
 %.jpg: %.pdf
-	convert -density 300 $< $@
+	pdftoppm -jpeg -singlefile -r 300 $< > $@
 
 %.png: %.svg
 	convert "$<" "$@"

Bug#991791: RFS: pynauty

[Andrius Merkys]

Hi Doug,

On 2021-08-02 06:00, Torrance, Douglas wrote:
> I've recently packaged pynauty [1], which provides a Python interface to
> nauty
> [2] for computing automorphism groups of graphs.
> 
> I'm a DM, but this package would be NEW, so I need a sponsor.  Would
> anyone be
> willing to review?
> https://salsa.debian.org/python-team/packages/pynauty

I have reviewed the package, all seems well, uploaded. Thanks a lot for
working on it!

> [1] https://github.com/pdobsan/pynauty
> [2] https://pallini.di.uniroma1.it/

Best,
Andrius

Bug#991813: libsmi: New upstream version 0.5.0 available.

[Tobias Frost]

On Tue, Aug 03, 2021 at 07:54:26AM +0200, Vincent Bernat wrote:
>  ❦  3 August 2021 07:42 +02, Tobias Frost:
> 
> > So -- my 2 cent -- I would even package trunk of the git repo, it would
> > be much better than the more-than-adecade(!) old version in Debian.
> 
> If you have some time, feel free to take over the package. I have too
> much on my plate currently.
> 
> > Regarding ABI: I've diffed the 0.4.8 smi.h with the 0.5.0 one:
> > all those changes should not be ABI changing.
> 
> Thanks for checking. If you don't want to take over the package, I'll
> try to find some time to update to 0.5.0.

Lets form a team or maybe ask the net-snmp people if they would be ok
in expanding the scope towards are more snmp team?

> -- 
> Instrument your programs.  Measure before making "efficiency" changes.
> - The Elements of Programming Style (Kernighan & Plauger)

Bug#636459: tmpreaper: diff for NMU version 1.6.14+nmu2

[Adrian Bunk]

Control: tags 636459 + patch

Dear maintainer,

I've prepared an NMU for tmpreaper (versioned as 1.6.14+nmu2).
The diff is attached to this message.

cu
Adrian
diff -Nru tmpreaper-1.6.14+nmu1/ChangeLog tmpreaper-1.6.14+nmu2/ChangeLog
--- tmpreaper-1.6.14+nmu1/ChangeLog	2019-09-06 16:20:49.0 +0300
+++ tmpreaper-1.6.14+nmu2/ChangeLog	2021-08-03 08:35:41.0 +0300
@@ -1,3 +1,11 @@
+tmpreaper (1.6.14+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from Mick Switser to fix protect on directory.
+(Closes: #636459)
+
+ -- Adrian Bunk   Tue, 03 Aug 2021 08:35:41 +0300
+
 tmpreaper (1.6.14+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru tmpreaper-1.6.14+nmu1/debian/changelog tmpreaper-1.6.14+nmu2/debian/changelog
--- tmpreaper-1.6.14+nmu1/debian/changelog	2019-09-06 16:20:49.0 +0300
+++ tmpreaper-1.6.14+nmu2/debian/changelog	2021-08-03 08:35:41.0 +0300
@@ -1,3 +1,11 @@
+tmpreaper (1.6.14+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from Mick Switser to fix protect on directory.
+(Closes: #636459)
+
+ -- Adrian Bunk   Tue, 03 Aug 2021 08:35:41 +0300
+
 tmpreaper (1.6.14+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru tmpreaper-1.6.14+nmu1/tmpreaper.c tmpreaper-1.6.14+nmu2/tmpreaper.c
--- tmpreaper-1.6.14+nmu1/tmpreaper.c	2019-01-05 17:23:01.0 +0200
+++ tmpreaper-1.6.14+nmu2/tmpreaper.c	2021-08-03 08:35:41.0 +0300
@@ -519,6 +519,21 @@
 		continue;
 		}
 
+if (FLAGS_PROTECT_P (flags)) {
+		skip = i = 0;
+		do {
+			if (sb.st_ino == protect_table[i].inode) {
+			message (LOG_VERBOSE,
+ "Entry matching `--protect' pattern skipped. `%s'\n",
+ protect_table[i].name);
+			skip = 1;
+			break;
+			}
+		} while (protect_table[i++].name);
+		if (skip)
+			continue;
+		}
+
 		if (S_ISDIR (sb.st_mode)) {
 #ifdef HAVE_LIBMOUNT_LIBMOUNT_H
 		struct mountpoint_control ctl = { NULL };
@@ -565,21 +580,6 @@
 			 (u_int) getpid(), ent->d_name);
 		}
 
-		if (FLAGS_PROTECT_P (flags)) {
-		skip = i = 0;
-		do {
-			if (sb.st_ino == protect_table[i].inode) {
-			message (LOG_VERBOSE,
- "Entry matching `--protect' pattern skipped. `%s'\n",
- protect_table[i].name);
-			skip = 1;
-			break;
-			}
-		} while (protect_table[i++].name);
-		if (skip)
-			continue;
-		}
-
 		/* Decide whether to remove the file or not */
 		/* check for mtime on directory instead of atime if requested */
 		if ( FLAGS_MTIME_P(flags) ||