Bug#987702: virt-manager: Resolution 5120x1440 wrongly snaps to 5120x2160 in the guest

[Paul Dreik]

Package: virt-manager
Version: 1:3.2.0-3
Severity: normal
X-Debbugs-Cc: debianb...@pauldreik.se

Dear Maintainer,

I run Debian bullseye in both the host and guest. I have a 5120x1440 screen
which works perfectly fine in the host.
When using the guest in fullscreen mode, I want it to use 5120x1440 as well.
It is however not available in the gnome screen resolution menu, instead 
5120x2160
shows up which is a bit awkward to use because it crops the bottom.

Using Debian Buster instead of Bullseye in the guest works as expected.
Ubuntu 20.04 as a guest has the same problem as Debian Bullseye.
I have tried changing the video model in virt-manager to see if it helps, it 
doesn't.

An observation is that both Ubuntu 20.04 and Debian Bullseye, when run as 
guests,
report the screen as "Red Hat, 53 inch''". Debian Bullseye reports it as 
"Unknown display".

Thanks, Paul

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.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 virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-gtk-3.0   3.24.24-3
ii  gir1.2-gtk-vnc-2.0   1.0.0-1
ii  gir1.2-gtksource-4   4.8.0-1
ii  gir1.2-libosinfo-1.0 1.8.0-1
ii  gir1.2-libvirt-glib-1.0  3.0.0-1
ii  gir1.2-vte-2.91  0.62.3-1
ii  python3  3.9.2-3
ii  python3-dbus 1.2.16-5
ii  python3-gi   3.38.0-2
ii  python3-gi-cairo 3.38.0-2
ii  python3-libvirt  7.0.0-2
ii  virtinst 1:3.2.0-3

Versions of packages virt-manager recommends:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.5-2
ii  gir1.2-spiceclientglib-2.0   0.39-1
ii  gir1.2-spiceclientgtk-3.00.39-1
ii  libvirt-daemon-system7.0.0-3

Versions of packages virt-manager suggests:
ii  gir1.2-secret-1  0.20.4-2
ii  gnome-keyring3.36.0-1
pn  python3-guestfs  
pn  ssh-askpass  
ii  virt-viewer  7.0-2

Versions of packages virt-manager is related to:
ii  libvirt-clients  7.0.0-3
ii  libvirt-daemon   7.0.0-3
ii  libvirt0 7.0.0-3
ii  osinfo-db0.20210215-1

-- no debconf information

Bug#987701: installation-reports: installation failed on Linkstation Pro: Out of memory during partitioning

[Cyril Brulebois]

Hi Ryan,

Ryan Tandy  (2021-04-27):
> I am booting this network-console image over TFTP... I guess there's no 
> easy way to provide the 'lowmem' boot parameter. I'd have to modify and 
> rebuild the install image (probably the initrd)?

I don't know anything about lowmem, but glancing at its code, I think
you can?


https://salsa.debian.org/installer-team/lowmem/-/blob/master/debian-installer-startup.d/S15lowmem#L112-119

Or are you already aware of this, and don't know how to pass the extra
option via TFTP?


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


signature.asc
Description: PGP signature

Bug#987701: installation-reports: installation failed on Linkstation Pro: Out of memory during partitioning

[Ryan Tandy]

Package: installation-reports
Severity: important
Tags: d-i

Dear Maintainer,

Bullseye RC1 fails to install on my Linkstation Pro (LS-GL). It runs out 
of memory just after confirming the partitions, when it starts to format 
the disk, and the installation process gets killed. Ironically, I think 
this is happening only seconds before it would format and activate the 
swap partition.

The Linkstation Pro is an orion5x NAS with 128MB RAM. I checked the 
Installation Guide; it says that the installer's memory requirement is 
80 MB. https://www.debian.org/releases/testing/armel/ch02s05.en.html

The installation images were retrieved from: 
https://deb.debian.org/debian/dists/testing/main/installer-armel/current/images/orion5x/network-console/buffalo/lspro_ls-gl/

I have (re-)installed buster successfully. The installation process uses 
some swap (especially during 'apt-get update') but does eventually 
complete. I upgraded it to bullseye, no problem.

I am attaching the full syslog from a failed attempt at installing 
bullseye. Please let me know if I can provide any other information.

I am booting this network-console image over TFTP... I guess there's no 
easy way to provide the 'lowmem' boot parameter. I'd have to modify and 
rebuild the install image (probably the initrd)?

thanks,
Ryan
Jan  1 00:00:16 syslogd started: BusyBox v1.30.1
Jan  1 00:00:16 kernel: klogd started: BusyBox v1.30.1 (Debian 1:1.30.1-6+b1)
Jan  1 00:00:16 kernel: [0.00] Booting Linux on physical CPU 0x0
Jan  1 00:00:16 kernel: [0.00] Linux version 5.10.0-6-marvell 
(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 Debian 5.10.28-1 (2021-04-09)
Jan  1 00:00:16 kernel: [0.00] CPU: Feroceon [41069260] revision 0 
(ARMv5TEJ), cr=a005317f
Jan  1 00:00:16 kernel: [0.00] CPU: VIVT data cache, VIVT instruction 
cache
Jan  1 00:00:16 kernel: [0.00] OF: fdt: Machine model: Buffalo 
Linkstation Pro/Live
Jan  1 00:00:16 kernel: [0.00] Memory policy: Data cache writeback
Jan  1 00:00:16 kernel: [0.00] Zone ranges:
Jan  1 00:00:16 kernel: [0.00]   Normal   [mem 
0x-0x07ff]
Jan  1 00:00:16 kernel: [0.00]   HighMem  empty
Jan  1 00:00:16 kernel: [0.00] Movable zone start for each node
Jan  1 00:00:16 kernel: [0.00] Early memory node ranges
Jan  1 00:00:16 kernel: [0.00]   node   0: [mem 
0x-0x07ff]
Jan  1 00:00:16 kernel: [0.00] Initmem setup node 0 [mem 
0x-0x07ff]
Jan  1 00:00:16 kernel: [0.00] On node 0 totalpages: 32768
Jan  1 00:00:16 kernel: [0.00]   Normal zone: 256 pages used for memmap
Jan  1 00:00:16 kernel: [0.00]   Normal zone: 0 pages reserved
Jan  1 00:00:16 kernel: [0.00]   Normal zone: 32768 pages, LIFO batch:7
Jan  1 00:00:16 kernel: [0.00] pcpu-alloc: s0 r0 d32768 u32768 
alloc=1*32768
Jan  1 00:00:16 kernel: [0.00] pcpu-alloc: [0] 0 
Jan  1 00:00:16 kernel: [0.00] Built 1 zonelists, mobility grouping on. 
 Total pages: 32512
Jan  1 00:00:16 kernel: [0.00] Kernel command line: 
console=ttyS0,115200 root=/dev/sda2 rw initrd=0x00800040,15M panic=5 
BOOTVER=1.10 tftpboot=yes
Jan  1 00:00:16 kernel: [0.00] Dentry cache hash table entries: 16384 
(order: 4, 65536 bytes, linear)
Jan  1 00:00:16 kernel: [0.00] Inode-cache hash table entries: 8192 
(order: 3, 32768 bytes, linear)
Jan  1 00:00:16 kernel: [0.00] mem auto-init: stack:off, heap alloc:on, 
heap free:off
Jan  1 00:00:16 kernel: [0.00] Memory: 106908K/131072K available (4732K 
kernel code, 830K rwdata, 1312K rodata, 292K init, 224K bss, 24164K reserved, 
0K cma-reserved, 0K highmem)
Jan  1 00:00:16 kernel: [0.00] random: get_random_u32 called from 
cache_random_seq_create+0x60/0x110 with crng_init=0
Jan  1 00:00:16 kernel: [0.00] SLUB: HWalign=32, Order=0-3, 
MinObjects=0, CPUs=1, Nodes=1
Jan  1 00:00:16 kernel: [0.00] ftrace: allocating 8 entries in 44 
pages
Jan  1 00:00:16 kernel: [0.00] ftrace: allocated 44 pages with 3 groups
Jan  1 00:00:16 kernel: [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated 
irqs: 16
Jan  1 00:00:16 kernel: [0.00] clocksource: orion_clocksource: mask: 
0x max_cycles: 0x, max_idle_ns: 11467562657 ns
Jan  1 00:00:16 kernel: [0.28] sched_clock: 32 bits at 166MHz, 
resolution 6ns, wraps every 12884901885ns
Jan  1 00:00:16 kernel: [0.000116] Switching to timer-based delay loop, 
resolution 6ns
Jan  1 00:00:16 kernel: [0.000349] Calibrating delay loop (skipped), value 
calculated using timer frequency.. 333.33 BogoMIPS (lpj=66)
Jan  1 00:00:16 kernel: [0.000417] pid_max: default: 32768 minimum: 301
Jan  1 00:00:16 kernel: [0.001220] LSM: Security Framework initializing
Jan  1 00:00:16 kernel: [0.001775] Yama: 

Bug#987676: unblock: mkdepend/0.0~svn45-3

[Andrius Merkys]

On 2021-04-27 21:50, Sebastian Ramacher wrote:
> On 2021-04-27 18:44:24 +0300, Andrius Merkys wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Dear release-team,
>>
>> I am seeking pre-approval to upload mkdepend/0.0~svn45-3.
>>
>> [ Reason ]
>> mkdepend/0.0~svn45-2 tries to access the network during build due to
>> missing stylesheet (#987673). The fix is to depend on a package
>> containing the required stylesheets, docbook-xsl.
>>
>> [ Impact ]
>> Without the fix, mkdepend will fail to build on builders with disabled
>> network access.
>>
>> [ Tests ]
>> * Built on clean sid chroot;
>> * Autopkgtest passes;
> 
> As it's also not a key package, no unblock is required. Please go ahead.

Thanks!

Best,
Andrius

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

[Salvatore Bonaccorso]

Hi Adrian,

On Sat, Apr 24, 2021 at 11:20:43PM +0300, Adrian Bunk wrote:
> Package: imagemagick
> Version: 8:6.9.11.60+dfsg-1.2
> Severity: serious
> Tags: ftbfs
> Control: found -1 8:6.9.10.23+dfsg-2.1+deb10u1
> Control: affects -1 src:ftgl src:foxtrotgps src:gri src:kannel src:mlpost 
> src:muttprint src:ns3 src:sctk src:texworks-manual src:therion src:vlfeat 
> src:x4d-icons src:xnee
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/ftgl.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/foxtrotgps.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/gri.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/kannel.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/mlpost.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/muttprint.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/ns3.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/sctk.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/texworks-manual.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/therion.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/vlfeat.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/x4d-icons.html
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/xnee.html
> 
> ...
> convert-im6.q16: attempt to perform an operation not allowed by the security 
> policy `EPS' @ error/constitute.c/IsCoderAuthorized/408.
> convert-im6.q16: attempt to perform an operation not allowed by the security 
> policy `EPS' @ error/constitute.c/IsCoderAuthorized/408.
> make[3]: *** [Makefile:931: screenshots/map-download.eps] Error 1
> 
> 
> A security change that went just went into imagemagick in unstable,
> but already went into imagemagick in buster last autumn,
> makes around a dozen packages FTBFS in unstable resp. buster.
> 
> Background:
> https://bugs.launchpad.net/ubuntu/+source/kannel/+bug/1838425
> 
> Options are either reverting the imagemagick change or fixing
> the packages that got broken in bullseye and buster.
> 
> Security and release teams are Cc'ed.

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?

Regards,
Salvatore

Bug#987649: unblock: libxcrypt/1:4.4.18-4

[Cyril Brulebois]

Hi Paul,

Paul Gevers  (2021-04-27):
> To be totally sure, I understood from our IRC chat yesterday that you're
> OK with migrating udeb's like this one at this moment.

Yes, you could even lift the udeb block if you don't want to use
unblock-udeb on each such package. That would need to happen in
/srv/release.debian.org/britney/etc (respighi).

As for this specific package, the udeb doesn't change between -2 and -4
so that looks totally fine anyway.


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


signature.asc
Description: PGP signature

Bug#868875: Status update

[adam]

It seems like there are a lot of bug fixes in the latest version: 
https://github.com/canonical/cloud-utils/blob/master/bin/growpart

If there is a desire to only fix this >2TB disk bug and not the others, I've 
extracted the patch for the 2TB limit and am attaching it here.

Cheers,
Adam


On April 26, 2021 1:57:40 AM CDT, Thomas Goirand  wrote:
>Hi,
>
>Thanks for the information.
>
>On 4/26/21 2:29 AM, a...@hax0rbana.org wrote:
>> [...]
>> So I believe this is fixed upstream and I'd love to help get the
>patched
>> version accepted into buster. If anyone can let me know how I can
>help
>> make this happen, please let me know.
>
>Well, easy, just send a patch, and someone (probably me) will add it to
>the current package, then ping the Stable release team to ask if they
>find it acceptable for Buster.
>
>Cheers,
>
>Thomas Goirand

-- 
Sent from my iPod. Please excuse my brevity.--- growpart	2021-04-28 04:07:32.10595 +
+++ growpart	2021-04-28 04:17:09.269811349 +
@@ -282,18 +282,22 @@
 		[ -n "${max_end}" ] ||
 		fail "failed to get max_end for partition ${PART}"
 
-	mbr_max_sectors=$((mbr_max_512*$((sector_size/512
-	if [ "$max_end" -gt "$mbr_max_sectors" ]; then
-		max_end=$mbr_max_sectors
-	fi
-
 	if [ "$format" = "gpt" ]; then
 		# sfdisk respects 'last-lba' in input, and complains about
 		# partitions that go past that.  without it, it does the right thing.
 		sed -i '/^last-lba:/d' "$dump_out" ||
 			fail "failed to remove last-lba from output"
 	fi
-
+	if [ "$format" = "dos" ]; then
+		mbr_max_sectors=$((mbr_max_512*$((sector_size/512
+		if [ "$max_end" -gt "$mbr_max_sectors" ]; then
+			max_end=$mbr_max_sectors
+		fi
+		[ $(($disk_size/512)) -gt $mbr_max_512 ] &&
+			debug 0 "WARNING: MBR/dos partitioned disk is larger than 2TB." \
+"Additional space will go unused."
+	fi
+ 
 	local gpt_second_size="33"
 	if [ "${max_end}" -gt "$((${sector_num}-${gpt_second_size}))" ]; then
 		# if mbr allow subsequent conversion to gpt without shrinking the

Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before the shell

[Cyril Brulebois]

Hi Étienne,

Étienne Mollier  (2021-04-26):
> Cyril Brulebois, on 2021-04-26 02:18:49 +0200:
> > Are you happy to trust me with a netboot/gtk/mini.iso build that you
> > would deploy on some USB device (like you would with a Netinst ISO,
> > except it'll need network access to download all d-i components that
> > aren't in the initramfs), to see if the problem goes away entirely for
> > you?
> 
> Sure!

Let's see if this helps!
  https://people.debian.org/~kibi/bug-987377/

For transparency, this was built from the master branch of the
debian-installer git repository, with the following command:

make -C build/ rebuild_netboot-gtk USE_UDEBS_FROM=testing

with a deb-reversion'd pango udeb stashed into build/localudebs
beforehand.

kibi@tokyo:~/debian-installer/installer$ dpkg --info 
build/localudebs/libpango1.0-udeb_1.42.4-8_amd64.udeb 
…
 Version: 1:1.42.4-8
…

just adding an epoch to make sure that the latest known good version
(1.42.4-8) is picked instead of the current one (1.46.2-3), as per:
  https://bugs.debian.org/987587


Also, thanks for all the tests so far, I've seen the follow-ups… that's
much appreciated (even if slightly frightening if the image linked above
doesn't make the problem go away altogether).


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


signature.asc
Description: PGP signature

Bug#987700: bornagain: buggy cmake file

[Yangfl]

Source: bornagain
Tags: patch

Hi,

cmake/BornAgain/Linux.cmake currently has the following lines:
  execute_process(COMMAND uname -m OUTPUT_VARIABLE SYSCTL_OUTPUT)
  if(${SYSCTL_OUTPUT} MATCHES x86_64)
  message(STATUS "Found a 64bit system")
  set(BIT_ENVIRONMENT "-m64")
  set(BORNAGAIN_ARCHITECTURE linuxx8664)
  else()
  message(STATUS "Found a 32bit system")
  set(BIT_ENVIRONMENT "-m32")
  add_definitions(-DEIGEN_DONT_ALIGN_STATICALLY=1)
  endif()

This has the following affects:
  * It stops cross building since it reads build's `uname`.
  * It stops building for most non-amd64 64-bit archs since it doesn't
recognize them as 64-bit archs.
  * It stops building for most non-i386 archs since they don't accept `-m32`.

Please consider applying this patch.
diff --git a/cmake/BornAgain/Linux.cmake b/cmake/BornAgain/Linux.cmake
index 2f482ee..98f67a5 100644
--- a/cmake/BornAgain/Linux.cmake
+++ b/cmake/BornAgain/Linux.cmake
@@ -1,14 +1,13 @@
 set(BORNAGAIN_ARCHITECTURE linux)
 set(BORNAGAIN_PLATFORM linux)
 
-execute_process(COMMAND uname -m OUTPUT_VARIABLE SYSCTL_OUTPUT)
-if(${SYSCTL_OUTPUT} MATCHES x86_64)
+if(CMAKE_SIZEOF_VOID_P GREATER 4)
 message(STATUS "Found a 64bit system")
-set(BIT_ENVIRONMENT "-m64")
-set(BORNAGAIN_ARCHITECTURE linuxx8664)
+if(${CMAKE_SYSTEM_PROCESSOR} STREQUAL x86_64)
+set(BORNAGAIN_ARCHITECTURE linuxx8664)
+endif()
 else()
 message(STATUS "Found a 32bit system")
-set(BIT_ENVIRONMENT "-m32")
 add_definitions(-DEIGEN_DONT_ALIGN_STATICALLY=1)
 endif()
 

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Lev Lamberov]

Hi Antoine,

Вт 27 апр 2021 @ 13:53 Antoine Beaupre :

> Package: elpa-esup
> Version: 0.7.1-3
> Severity: grave
> Tags: upstream
>
> This package is unusable in Debian 11 bullseye in its current
> state. In my Emacs 1:27.1+1-3.1 session, i run M-x esup and I get:
>
> error in process sentinel: Wrong type argument: (or eieio-object class), nil, 
> obj
>
> *Messages* has this:
>
> Loading /usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup-autoloads.el 
> (source)...done
> Starting esup...
> esup process started on port 37851
> at 1
> error in process sentinel: slot-value: Wrong type argument: (or eieio-object 
> class), nil, obj
> error in process sentinel: Wrong type argument: (or eieio-object class), nil, 
> obj
>
> This is the upstream bug: https://github.com/jschaf/esup/issues/85
>
> It looks like it is a packaging issue, since, according to the above
> bug report, recompiling the .el files fixes the problem (haven't tested).

Thanks for reporting, investigating and forwarding!

Is it a fresh install of elpa-esup?

I have elpa-esup installed for a long time and I cannot reproduce the
bug on my machine. Running esup starts another GNU Emacs session and
gives me a proper report on startup like the following excerpt:

```
Total User Startup Time: 0.357sec Total Number of GC Pauses: 3 Total GC 
Time: 0.065sec

package.elc:16  0.134sec   37%
(byte-code "\301\302!\210\301\303!\210 [...]
```

I wonder how recompiling could fix the problem you face, since
installing/reinstalling the package or GNU Emacs itself should trigger
recompilation of it along with all other installed Emacs packages.

The package does not contain any pre-compiled files:

```
$ apt-file show elpa-esup
elpa-esup: /usr/lib/emacsen-common/packages/compat/elpa-esup
elpa-esup: /usr/lib/emacsen-common/packages/install/elpa-esup
elpa-esup: /usr/lib/emacsen-common/packages/remove/elpa-esup
elpa-esup: /usr/share/doc/elpa-esup/README.md
elpa-esup: /usr/share/doc/elpa-esup/changelog.Debian.gz
elpa-esup: /usr/share/doc/elpa-esup/copyright
elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup-autoloads.el
elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup-child.el
elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup-pkg.el
elpa-esup: /usr/share/emacs/site-lisp/elpa-src/esup-0.7.1/esup.el
```

So, may it be a bug in dh-elpa or GNU Emacs itself?

Cheers!
Lev

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Lev Lamberov]

By the way here is the relevant output from *Message* on my machine:

```
Starting esup...
esup process started on port 45217
at 1
esup finished
```

Cheers!
Lev

Bug#987699: installation-reports: bullseye background art covers kernel commandline on legacy BIOS

[Federico Grau]

Package: installation-reports
Severity: normal

Boot method: netinst ISO image for kvm VM
Image version: 
https://cdimage.debian.org/cdimage/bullseye_di_rc1/amd64/iso-cd/debian-bullseye-DI-rc1-amd64-netinst.iso
 2021-04-23
Date: 2021-04-27 21:00  UTC-4

Machine: VM
Partitions: N/A


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

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

Comments/Problems:

The current (d-i RC1) bullseye background art covers or obfuscates the grub
kernel command line, at least on a legacy BIOS boot (likely less of an issue
with UEFI BIOS).

While it's a nice addition to include the "Debian 11" version text in the
background image, that text is currently located in the bottom left corner of
the screen which is where the kernel command line text can be if it is two
lines long.

Maybe relocate the "Debian 11" text to the top left corner of the background
image.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210415"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux saltdev14 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC 
[Natoma] [8086:1237] (rev 02)
lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA 
[Natoma/Triton II] [8086:7000]
lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE 
[Natoma/Triton II] [8086:7010]
lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
lspci -knn: Kernel driver in use: ata_piix
lspci -knn: Kernel modules: ata_piix, ata_generic
lspci -knn: 00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI 
[8086:7113] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Red Hat, Inc. QXL 
paravirtual graphic card [1b36:0100] (rev 04)
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: 00:03.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network 
device [1af4:1000]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0001]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:04.0 Audio device [0403]: Intel Corporation 
82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller 
[8086:2668] (rev 01)
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:05.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB UHCI Controller #1 [8086:2934] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:05.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB UHCI Controller #2 [8086:2935] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:05.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB UHCI Controller #3 [8086:2936] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: 00:05.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 
Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: 00:06.0 Communication controller [0780]: Red Hat, Inc. Virtio 
console [1af4:1003]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0003]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:07.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio block 
device [1af4:1001]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0002]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:08.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory 
balloon [1af4:1002]
lspci -knn: Subsystem: Red 

Bug#987652: surf does not start

[Aymeric Agon-Rambosson]

Hello Herr Sprickerhof,

First of all thank you for your quick answer. Your last remark 
gave me the hint I needed :


It turns out I had a stale libsurf-webext.so in the directory 
/usr/local/lib/surf, removing it solved the problem. This is due 
to the fact that upstream changed the name of the library from 
libsurf-webext.c to webext-surf.c between debian/2.0+git20181009 
and debian/2.0+git20201107, which means that a not careful enough 
direct use of the Makefile (make install once in each branch, not 
separated with a make uninstall) would mean that two versions of 
the shared object library (the stale one libsurf-webext.so, and 
the new one webext-surf.so) would cohabit in the same directory 
/usr/local/lib/surf.


These two shared object libraries would have competing versions of 
each symbol, and more specifically two versions of the culprit 
symbol webkit_web_initialize_with_user_data() :
- one (libsurf-webext.so) that would have g_variant_get(gv, 
 "(ii)", , )
- the other (webext-surf.so) that would have g_variant_get(gv, 
 "i", )


Since in the new version (debian/2.0+git20201107), gv would be 
created like this :

gv = g_variant_new("i", spair[1])

surf would work correctly only if the dynamic linking would use 
webext-surf.so, and crash if the dynamic linking had chosen 
libsurf-webext.so. I have no idea how the choice is made 
(alphabetic order of each shared object file maybe ??), but it 
seems the dynamic linking systematically chose the stale file 
before we removed it.


So the problem was entirely my fault, and a more careful direct 
use of the Makefile solved the problem. So I am sorry for having 
wasted your time.


However, the stuff I do on my own patched version of surf (that 
goes in /usr/local/bin, with the shared object going in 
/usr/local/lib/surf/) should have no influence on the Debian 
version of surf living in /usr/bin : even when I launched 
/usr/bin/surf, the stale library 
/usr/local/lib/surf/libsurf-webext.so would be used over 
/usr/lib/surf/webext-surf.so ! So a user-compiled shared object 
(in /usr/local) would take precedence over a Debian-compiled 
version (in /usr), even when the binary is itself in /usr ?


This, in my opinion, is still a bug (albeit a lot less severe and 
a lot more subtle, and arguably a different one). What is the next 
course of action ?


The symbol webkit_web_initialize_with_user_data() is not called 
from surf, but from webkit. So the bug lies not with the surf 
package, but probably with the libwebkit2gtk-4.0-37.


So the original bug (surf not starting) can be closed (I have no 
idea how to do that). I'll let you tell me whether you agree with 
my opinion that webkit should try to resolve 
webkit_web_initialize_with_user_data() from /usr/lib/surf and not 
from /usr/local/lib/surf when the binary is /usr/bin/surf, and 
whether this warrants another bug report (and in which package ) ?


Thank you again for your time reading this long message,

Best regards,

Aymeric Agon-Rambosson


Jochen Sprickerhof  writes:

* Aymeric Agon-Rambosson  [2021-04-27 
03:18]:

$ /usr/bin/surf

output :

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: the 
GVariant format string '(ii)' has a type of '(ii)' but the given 
value has a type of 'i'


(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: 
g_variant_get: assertion 'valid_format_string (format_string, 
TRUE, value)' failed


(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: the 
GVariant format string '(ii)' has a type of '(ii)' but the given 
value has a type of 'i'


(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: 
g_variant_get: assertion 'valid_format_string (format_string, 
TRUE, value)' failed

web process terminated: crashed


Also, can you check if you have a custom webext-surf.so in your
~/.surf or elsewhere in your ld path?

Bug#986027: firefox: WebExtensions process sometimes consumes 100% CPU indefinitely on Firefox 87

[Dmitry Borodaenko]

I get this on X11 and GNOME, too.

Looks like the same bug was reported upstream:
https://bugzilla.mozilla.org/show_bug.cgi?id=1706594

-- 
Dmitry Borodaenko

Bug#987448: fixed in liferea 1.13.5-2

[Paul Wise]

On Tue, 2021-04-27 at 19:03 +, Paul Gevers wrote:

>    * Add patch to work with latest webgit2gkt:
>  34d26be00328a68d2f1625c78b54dc168da0648e.patch (Closes: #987448)

I confirm that this change has fixed the issue that I reported.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#952298: sshcommand: FTBFS: shellcheck fails

[Fabio A. De Muzio Tobich]

Hello,

Here's a possible patch to fix this:

--- sshcommand-0~20160110.1~2795f65.orig/sshcommand
+++ sshcommand-0~20160110.1~2795f65/sshcommand
@@ -32,7 +32,7 @@ case "$1" in
   create) # sshcommand create  
 if [[ $# -ne 3 ]]; then
   echo "Usage : sshcommand create user command"
-  exit -1
+  exit 1
 fi
 USER="$2"; COMMAND="$3"

@@ -52,7 +52,7 @@ case "$1" in
   acl-add) # sshcommand acl-add  
 if [[ $# -ne 3 ]]; then
   echo "Usage : sshcommand acl-add user identifier"
-  exit -1
+  exit 1
 fi
 USER="$2"; NAME="$3"

@@ -68,7 +68,7 @@ case "$1" in

 if [[ ! "$FINGERPRINT" =~ :.* ]]; then
   echo "Invalid ssh public key"
-  exit -1
+  exit 1
 fi
 KEY_PREFIX="command=\"FINGERPRINT=$FINGERPRINT NAME=\\\"$NAME\\\" \`cat 
$USERHOME/.sshcommand\` 
\$SSH_ORIGINAL_COMMAND\",no-agent-forwarding,no-user-rc,no-X11-forwarding,no-port-forwarding"
 echo "$KEY_PREFIX $KEY" >> "$USERHOME/.ssh/authorized_keys"
@@ -78,7 +78,7 @@ case "$1" in
   acl-remove) # sshcommand acl-remove  
 if [[ $# -ne 3 ]]; then
   echo "Usage : sshcommand acl-remove user identifier"
-  exit -1
+  exit 1
 fi
 USER="$2"; NAME="$3"





Best regards,


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


signature.asc
Description: PGP signature

Bug#987689: Upgrade to 2021.03

[KOLANICH]

Package: libtbb2
Version: 2020.03

Severity: normal

libtbb2 is of obsolete version that dropped by numba in master branch.

Bug#949767: arrayfire update fails in configure step

[Aaron M. Ucko]

Andreas Tille  writes:

> https://salsa.debian.org/science-team/arrayfire/-/jobs/1608881

It looks like you're down to two real errors:

  CMake Error: File 
/builds/science-team/arrayfire/debian/output/source_dir/extern/forge/CMakeModules/version.h.in
 does not exist.
  CMake Error at CMakeModules/AFconfigure_forge_submodule.cmake:47 
(configure_file):
configure_file Problem configuring file

Please try commenting out the configure_file call at the end of
CMakeModules/AFconfigure_forge_submodule.cmake.

  CMake Error at /usr/share/cmake-3.18/Modules/ExternalProject.cmake:2350 
(message):
error: could not find git for clone of clFFT-ext
  Call Stack (most recent call first):
/usr/share/cmake-3.18/Modules/ExternalProject.cmake:3206 
(_ep_add_download_command)
CMakeModules/build_clFFT.cmake:33 (ExternalProject_Add)
src/backend/opencl/CMakeLists.txt:15 (include)

Please try adding a build dependency on libclfft-dev and replacing
src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call
to

  find_package(clFFT)

> Thanks a lot for your initial hint

No problem.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#365427: [O: apt-build] Is this package worth adopting or has it been replaced?

[Brian Thompson]

On Sat, 17 Apr 2021 05:48:48 +0200 Axel Beckert  wrote:
> Hi,
> 
> No Body wrote:
> > Is this package worth adopting or has it been replaced by something
> > else?
> 
> There's nothing like it so far AFAIK. apt-src is close, but has a
> different focus (modification instead of compile-time optimization).
> 
> > I read the entire bug message history and saw that in 2016 there was some
> > development going on to replace the package.
> 
> I don't see which message you mean. In 2016, there were only control
> messages and spam in this bug report.
> 
>   Regards, Axel
> -- 
>  ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
> : :' :  |  Debian Developer, ftp.ch.debian.org Admin
> `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
>   `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
> 
> 

Axel, switched my email address to one that I actually use. Going to start 
looking into this package more.
-- 
Best regards,

Brian

Bug#987698: rhash --version outputs wrong version

[Aleksey Kravchenko]

Package: rhash
Version: 1.4.1-1
Severity: normal
Control: tag -1 fixed-upstream
Control: fixed -1 1.4.1-2

RHash from the 1.4.1-1 deb package outputs wrong version 'v1.4.0'
instead of expected 'v1.4.1'.

Commands to reproduce:

$ rhash --version
RHash v1.4.0


Upstream git has commit [1], which bumps RHash version and fixes this bug.
The commit mistakenly has not been included into upstream release tarball.


[1]
https://github.com/rhash/RHash/commit/eb9bc3ff3f4b2003c9441f43f5cd930a8d211ceb



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

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

Versions of packages rhash depends on:
ii  libc6  2.31-11
ii  librhash0  1.4.1-2

Versions of packages rhash recommends:
ii  libssl1.1  1.1.1k-1

rhash suggests no packages.

-- no debconf information




OpenPGP_signature
Description: OpenPGP digital signature

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

On Tue, Apr 27, 2021, at 12:15 AM, John Paul Adrian Glaubitz wrote:> 
> On 4/27/21 8:54 AM, Rick Thomas wrote:
> > I'll look around and see if I have any MDD (mirror drive door -- the type 
> > in the
> > original bugreport) machines.  If so, I'll try to find some time to install 
> > Adrian's
> > latest and report back.
> 
> OK, thank you. Maybe someone else with a machine that previously had 
> this issue can also
> comment so that we can be sure the issue has been fixed.
> 
> Rick, maybe you can check whether the windfarm module(s) get(s) loaded 
> on your machine?
> 
> # lsmod |grep windfarm

On the G4 (which is _not_ the MDD) I get nothing from that

On the G5 I get:

rbthomas@kmac:~$ lsmod | grep wind
windfarm_smu_sat8626  0
windfarm_ad7417_sensor 7755  0
windfarm_fcu_controls12227  0
windfarm_cpufreq_clamp 3881  0
windfarm_pm72  14329  0
windfarm_pid3256  1 windfarm_pm72
windfarm_lm75_sensor 5350  0
windfarm_max6690_sensor 4600  0
windfarm_core  11920  7 
windfarm_cpufreq_clamp,windfarm_fcu_controls,windfarm_max6690_sensor,windfarm_smu_sat,windfarm_ad7417_sensor,windfarm_pm72,windfarm_lm75_sensor

Hope that helps.
Rick

PS: I do have a MDD, but I haven't yet tried Adrian's latest on it.  Maybe 
later today, maybe it'll have to wait for the weekend.

Bug#987697: ITS: materia-gtk-theme

[Leandro Cunha]

Source: materia-gtk-theme
Version:  20200916-0.2
Severity: important
X-Debbugs-CC: i.vikra...@gmail.com

Dear package materia-gtk-theme maintainer in Debian,

After 3 NMU and 2 done by me with Boyuan Yang, I would like to know if you
are still interested in maintaining this package. Even the Gitlab
repository is out of date and pending MR. I appreciate the work of making
this package available in Debian. Accordingly the Debian Developer
Reference [2] what mentions about ITS. And what makes this package readable
are the items of 5.12.1:

* Bugs filed against the package do not have answers from the maintainer.

* Upstream has released several versions, but despite there being a bug
entry asking for it, it has not been packaged.

* QA problems were ignored by the maintainer and solved by NMU.

By the Wiki [1] the items:

* There is no visible activity regarding the package for six months.

* The last upload was an NMU and there was no maintainer upload within one
year.

The deadline for responding to this bug is 21 days according to the Debian
Developers Reference [2] 5.12.2 items 2 and 3.
Due to the freeze the period will be longer until the release of the
Bullseye that the package will be able to receive new uploads of newer
versions [3].

[1] https://wiki.debian.org/PackageSalvaging
[2]
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[3] https://release.debian.org

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.

Bug#932087: knot-host: Add to update-alternatives

[Daniel Baumann]

tag 932087 patch
thanks

Hi,

I've attached patches that we're using in our Debian derrivate for this.
I've also send the required patches to a bugreport against src:bind9
(will add a "block by" to this bug after having recieved the bugnumber).

Regards,
Daniel

>From 89bc67e87478cd3256431a28396fe04d2279c403 Mon Sep 17 00:00:00 2001
From: Daniel Baumann 
Date: Tue, 27 Apr 2021 23:44:42 +0200
Subject: [PATCH 05/15] Adding update-alternatives to use kdig for
 /usr/bin/dig.

Signed-off-by: Daniel Baumann 
---
 debian/knot-dnsutils.postinst | 25 +
 debian/knot-dnsutils.prerm| 23 +++
 2 files changed, 48 insertions(+)
 create mode 100644 debian/knot-dnsutils.postinst
 create mode 100644 debian/knot-dnsutils.prerm

diff --git a/debian/knot-dnsutils.postinst b/debian/knot-dnsutils.postinst
new file mode 100644
index 000..f31f650
--- /dev/null
+++ b/debian/knot-dnsutils.postinst
@@ -0,0 +1,25 @@
+#!/bin/sh
+
+set -e
+
+case "${1}" in
+	configure)
+		# update-alternatives: dig
+		update-alternatives --quiet \
+			--install /usr/bin/dig dig /usr/bin/kdig 20 \
+			--slave /usr/share/man/man1/dig.1.gz dig.1.gz /usr/share/man/man1/kdig.1.gz
+		;;
+
+	abort-upgrade|abort-remove|abort-deconfigure)
+
+		;;
+
+	*)
+		echo "postinst called with unknown argument \`${1}'" >&2
+		exit 1
+		;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/knot-dnsutils.prerm b/debian/knot-dnsutils.prerm
new file mode 100644
index 000..178b8a1
--- /dev/null
+++ b/debian/knot-dnsutils.prerm
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+set -e
+
+case "${1}" in
+	remove|upgrade|deconfigure)
+		# update-alternatives: dig
+		update-alternatives --quiet --remove dig /usr/bin/kdig
+		;;
+
+	failed-upgrade)
+
+		;;
+
+	*)
+		echo "prerm called with unknown argument \`${1}'" >&2
+		exit 1
+		;;
+esac
+
+#DEBHELPER#
+
+exit 0
-- 
2.30.2

>From 37ed9c5f94bd81dc72a90f6a08f877adfe9f4da9 Mon Sep 17 00:00:00 2001
From: Daniel Baumann 
Date: Tue, 27 Apr 2021 23:44:44 +0200
Subject: [PATCH 06/15] Adding update-alternatives to use khost for
 /usr/bin/host (Closes: #932087).

Signed-off-by: Daniel Baumann 
---
 debian/knot-host.postinst | 25 +
 debian/knot-host.prerm| 23 +++
 2 files changed, 48 insertions(+)
 create mode 100644 debian/knot-host.postinst
 create mode 100644 debian/knot-host.prerm

diff --git a/debian/knot-host.postinst b/debian/knot-host.postinst
new file mode 100644
index 000..7bc0ee9
--- /dev/null
+++ b/debian/knot-host.postinst
@@ -0,0 +1,25 @@
+#!/bin/sh
+
+set -e
+
+case "${1}" in
+	configure)
+		# update-alternatives: host
+		update-alternatives --quiet \
+			--install /usr/bin/host host /usr/bin/khost 20 \
+			--slave /usr/share/man/man1/host.1.gz host.1.gz /usr/share/man/man1/khost.1.gz
+		;;
+
+	abort-upgrade|abort-remove|abort-deconfigure)
+
+		;;
+
+	*)
+		echo "postinst called with unknown argument \`${1}'" >&2
+		exit 1
+		;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/knot-host.prerm b/debian/knot-host.prerm
new file mode 100644
index 000..d2e70f3
--- /dev/null
+++ b/debian/knot-host.prerm
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+set -e
+
+case "${1}" in
+	remove|upgrade|deconfigure)
+		# update-alternatives: host
+		update-alternatives --quiet --remove host /usr/bin/khost
+		;;
+
+	failed-upgrade)
+
+		;;
+
+	*)
+		echo "prerm called with unknown argument \`${1}'" >&2
+		exit 1
+		;;
+esac
+
+#DEBHELPER#
+
+exit 0
-- 
2.30.2

Bug#987696: findutils: suggest plocate as an alternative

[Christoph Anton Mitterer]

Package: findutils
Version: 4.8.0-1
Severity: wishlist


Hey.

plocate advertises itself as a drop-in replacement for mlocate (+ being faster)
and seems to have some active development.

So maybe you should add this as a (preferred?) alternative in the Suggests?

Cheers,
Chris.

Bug#987695: please add update-alternatives for host and dig commands

[Daniel Baumann]

Package: bind9
Version: 1:9.16.13-1
Tags: patch

Hi,

in order to transparently use host/dig from src:bind9 or src:knot
packages, it would be nice if you could add update-alternative support
for those.

I've attached packages that we're using in our Debian derrivative.

Regards,
Daniel
>From 02aabd9d59bbdd51f211fc652500114228f23433 Mon Sep 17 00:00:00 2001
From: Daniel Baumann 
Date: Tue, 27 Apr 2021 23:24:06 +0200
Subject: [PATCH 05/22] Using update-alternatives to handle /usr/bin/dig.

Signed-off-by: Daniel Baumann 
---
 debian/dnsutils.postinst | 25 +
 debian/dnsutils.prerm| 23 +++
 debian/rules |  7 +++
 3 files changed, 55 insertions(+)
 create mode 100644 debian/dnsutils.postinst
 create mode 100644 debian/dnsutils.prerm

diff --git a/debian/dnsutils.postinst b/debian/dnsutils.postinst
new file mode 100644
index 000..76a6234
--- /dev/null
+++ b/debian/dnsutils.postinst
@@ -0,0 +1,25 @@
+#!/bin/sh
+
+set -e
+
+case "${1}" in
+	configure)
+		# update-alternatives: dig
+		update-alternatives --quiet \
+			--install /usr/bin/dig dig /usr/bin/dig.bind9 10 \
+			--slave /usr/share/man/man1/dig.1.gz dig.1.gz /usr/share/man/man1/dig.bind9.1.gz
+		;;
+
+	abort-upgrade|abort-remove|abort-deconfigure)
+
+		;;
+
+	*)
+		echo "postinst called with unknown argument \`${1}'" >&2
+		exit 1
+		;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/dnsutils.prerm b/debian/dnsutils.prerm
new file mode 100644
index 000..07589cc
--- /dev/null
+++ b/debian/dnsutils.prerm
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+set -e
+
+case "${1}" in
+	remove|upgrade|deconfigure)
+		# update-alternatives: dig
+		update-alternatives --quiet --remove dig /usr/bin/dig.bind9
+		;;
+
+	failed-upgrade)
+
+		;;
+
+	*)
+		echo "prerm called with unknown argument \`${1}'" >&2
+		exit 1
+		;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/rules b/debian/rules
index 14071f2..b70f9ed 100755
--- a/debian/rules
+++ b/debian/rules
@@ -98,6 +98,13 @@ override_dh_install:
 	# Install apparmor profile
 	dh_apparmor -pbind9 --profile-name=usr.sbin.named
 
+	# update-alternatives: dig
+	if [ -e debian/dnsutils/usr/bin/dig ]; \
+	then \
+		mv debian/dnsutils/usr/bin/dig debian/dnsutils/usr/bin/dig.bind9; \
+		mv debian/dnsutils/usr/share/man/man1/dig.1 debian/dnsutils/usr/share/man/man1/dig.bind9.1; \
+	fi
+
 override_dh_missing:
 	dh_missing --exclude=.la --exclude=lwresd --exclude=__pycache_ --fail-missing
 
-- 
2.30.2

>From 1512957f464f2e7f3cf7bbec3db917ea5f0e83e8 Mon Sep 17 00:00:00 2001
From: Daniel Baumann 
Date: Tue, 27 Apr 2021 23:24:06 +0200
Subject: [PATCH 06/22] Using update-alternatives to handle /usr/bin/host.

Signed-off-by: Daniel Baumann 
---
 debian/bind9-host.postinst | 25 +
 debian/bind9-host.prerm| 23 +++
 debian/rules   |  7 +++
 3 files changed, 55 insertions(+)
 create mode 100644 debian/bind9-host.postinst
 create mode 100644 debian/bind9-host.prerm

diff --git a/debian/bind9-host.postinst b/debian/bind9-host.postinst
new file mode 100644
index 000..3a60813
--- /dev/null
+++ b/debian/bind9-host.postinst
@@ -0,0 +1,25 @@
+#!/bin/sh
+
+set -e
+
+case "${1}" in
+	configure)
+		# update-alternatives: host
+		update-alternatives --quiet \
+			--install /usr/bin/host host /usr/bin/host.bind9 10 \
+			--slave /usr/share/man/man1/host.1.gz host.1.gz /usr/share/man/man1/host.bind9.1.gz
+		;;
+
+	abort-upgrade|abort-remove|abort-deconfigure)
+
+		;;
+
+	*)
+		echo "postinst called with unknown argument \`${1}'" >&2
+		exit 1
+		;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/bind9-host.prerm b/debian/bind9-host.prerm
new file mode 100644
index 000..359634a
--- /dev/null
+++ b/debian/bind9-host.prerm
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+set -e
+
+case "${1}" in
+	remove|upgrade|deconfigure)
+		# update-alternatives: host
+		update-alternatives --quiet --remove host /usr/bin/host.bind9
+		;;
+
+	failed-upgrade)
+
+		;;
+
+	*)
+		echo "prerm called with unknown argument \`${1}'" >&2
+		exit 1
+		;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/rules b/debian/rules
index b70f9ed..811bd09 100755
--- a/debian/rules
+++ b/debian/rules
@@ -105,6 +105,13 @@ override_dh_install:
 		mv debian/dnsutils/usr/share/man/man1/dig.1 debian/dnsutils/usr/share/man/man1/dig.bind9.1; \
 	fi
 
+	# update-alternatives: host
+	if [ -e debian/bind9-host/usr/bin/host ]; \
+	then \
+		mv debian/bind9-host/usr/bin/host debian/bind9-host/usr/bin/host.bind9; \
+		mv debian/bind9-host/usr/share/man/man1/host.1 debian/bind9-host/usr/share/man/man1/host.bind9.1; \
+	fi
+
 override_dh_missing:
 	dh_missing --exclude=.la --exclude=lwresd --exclude=__pycache_ --fail-missing
 
-- 
2.30.2

Bug#962290: smuxi-frontend-gnome: freezes when I click on the channel with a recent notification

[Raphael Hertzog]

Control: tags -1 - moreinfo unreproducible

Hello,

Le mercredi 10 février 2021, Raphael Hertzog a écrit :
> > Can you please open a terminal and run Smuxi in debug mode like this:
> > smuxi-frontend-gnome -d
> 
> I'll try to get you this soon.

Finally I reproduced the issue!

Here's the end of the log:

2021-04-27 23:28:15,511 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
GroupChatView.AddPerson(person = )
2021-04-27 23:28:57,065 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:29:57,095 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:30:57,153 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:31:24,501 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
GroupChatView.AddPerson(person = )
2021-04-27 23:31:24,502 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
MainWindow.UpdateTitle(chatView = <#kali-linux>, protocolStatus = (null))
2021-04-27 23:31:57,212 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:32:57,243 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:33:57,300 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:34:57,357 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:35:57,388 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:36:57,419 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:37:57,476 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:38:25,246 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:38:25,248 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:38:57,534 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:39:27,423 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:39:27,426 [LastSeenHighlightQueue()] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] ChatView.OnMessageTextViewMessageHighlighted(sender 
= (null), e = (null))
2021-04-27 23:39:27,458 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:39:57,566 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:40:14,953 [Main] DEBUG Smuxi.Frontend.Gnome.MessageTextView - 
OnMotionNotifyEvent(): at url tag
2021-04-27 23:40:14,961 [Main] DEBUG Smuxi.Frontend.Gnome.MessageTextView - 
OnMotionNotifyEvent(): not at url tag
2021-04-27 23:40:16,355 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
MainWindow.OnFocusInEvent(sender = Smuxi.Frontend.Gnome.MainWindow, e = 
Gtk.FocusInEventArgs)
2021-04-27 23:40:16,355 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#kali-linux>)
2021-04-27 23:40:16,357 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
StatusIconManager.OnMainWindowFocusInEvent(sender = 
Smuxi.Frontend.Gnome.MainWindow, e = Gtk.FocusInEventArgs)
2021-04-27 23:40:16,357 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
NotifyManager.OnMainWindowFocusInEvent(sender = 
Smuxi.Frontend.Gnome.MainWindow, e = Gtk.FocusInEventArgs)
2021-04-27 23:40:16,384 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatViewManager.OnTreeViewSelectionChanged(sender = Gtk.TreeSelection, e = 
System.EventArgs)
2021-04-27 23:40:16,384 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
MessageTextView.UpdateMarkerline()
2021-04-27 23:40:16,384 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
Notebook.OnSwitchPage(sender = Smuxi.Frontend.Gnome.Notebook, e = 
Gtk.SwitchPageArgs)
2021-04-27 23:40:16,384 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:40:16,386 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:40:16,387 [SwitchPage] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
Notebook.OnSwitchPage(sender = (null), e = (null))
2021-04-27 23:40:16,387 [Main] DEBUG TRACE - [smuxi-engine.dll] Config.Save()
2021-04-27 23:40:16,387 [Main] DEBUG Smuxi.Engine.Config - Saving config
2021-04-27 23:40:16,388 [Main] DEBUG TRACE - [smuxi-engine.dll] Config.Save()
2021-04-27 23:40:16,388 [Main] DEBUG Smuxi.Engine.Config - Saving config
2021-04-27 23:40:16,389 [Main] DEBUG TRACE - [smuxi-engine.dll] Config.Save()
2021-04-27 

Bug#987694: desktop entry Exec key has quoted %-escapes

[Marriott NZ]

Package: k4dirstat
Version: 3.2.2-1
Tags: security

Dear Maintainer,
the k4dirstat package desktop entry (/usr/share/applications/k4dirstat.desktop) 
has quoted %-escapes in the Exec key, which is not standard compliant:
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html
"Field codes must not be used inside a quoted argument, the result of field 
code expansion inside a quoted argument is undefined."

The Exec line should be changed from:

 Exec=k4dirstat %i -qwindowtitle "%c" "%u"

to:

 Exec=k4dirstat %i -qwindowtitle %c %u

I'm using the "security" tag because such line is used by update-mime(8) to 
generate a mailcap entry in /etc/mailcap. The quotes are preserved in the 
conversion, resulting in a mailcap rule with quoted %-escapes which is 
vulnerable to shell command injection:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930908
https://lintian.debian.org/tags/quoted-placeholder-in-mailcap-entry.html
(The lintian tag is not triggered by k4dirstat because the rule is generated.)

If you need more information let me know.

Thanks,
MNZ

Bug#987693: mysql-workbench has mailcap entries with quoted %-escapes

[Marriott NZ]

Package: mysql-workbench
Version: 8.0.19+dfsg-1
Tags: security

Dear Maintainer,
the mysql-workbench package has mailcap entries with quoted %-escapes. That is 
considered unsafe. Proper escaping should be left to the programs using the 
entry.

This Lintian tag is triggered:
https://lintian.debian.org/tags/quoted-placeholder-in-mailcap-entry.html

See also grave bug #930908, which was recently closed because "a Lintian test 
already exists":
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930908

I'm using the "security" tag because the affected rules in combination with 
certain mail user agents (or document openers) are the cause of a shell command 
injection vulnerability.

/usr/lib/mime/packages/mysql-workbench should be changed from:

 application/vnd.mysql-workbench-model; mysql-workbench '%s'; 
description="MySQL Workbench Model"; test=test -n "$DISPLAY"; 
nametemplate=%s.mwb
 application/sql; mysql-workbench --script '%s'; description="MySQL Workbench 
Query File"; test=test -n "$DISPLAY"; nametemplate=%s.sql

to:

 application/vnd.mysql-workbench-model; mysql-workbench %s; description="MySQL 
Workbench Model"; test=test -n "$DISPLAY"; nametemplate=%s.mwb
 application/sql; mysql-workbench --script %s; description="MySQL Workbench 
Query File"; test=test -n "$DISPLAY"; nametemplate=%s.sql

If you need more information let me know.

Thanks,
MNZ

Bug#987692: smpeg-plaympeg has mailcap entries with quoted %-escapes

[Marriott NZ]

Package: smpeg-plaympeg
Version: 0.4.5+cvs20030824-9
Tags: patch, security

Dear Maintainer,
the smpeg-plaympeg package has mailcap entries with quoted %-escapes. That is 
considered unsafe. Proper escaping should be left to the programs using the 
entry.

This Lintian tag is triggered:
https://lintian.debian.org/tags/quoted-placeholder-in-mailcap-entry.html

See also grave bug #930908, which was recently closed because "a Lintian test 
already exists":
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930908

I'm using the "security" tag because the affected rules in combination with 
certain mail user agents (or document openers) are the cause of a shell command 
injection vulnerability.

If you need more information let me know.

Thanks,
MNZ
diff --git a/debian/smpeg-gtv.mime b/debian/smpeg-gtv.mime
index 36d543c..3833e00 100644
--- a/debian/smpeg-gtv.mime
+++ b/debian/smpeg-gtv.mime
@@ -1,2 +1,2 @@
-audio/mpeg; /usr/bin/gtv '%s'; description="MPEG audio files"; test=test -n "$DISPLAY"; priority=2
-video/mpeg; /usr/bin/gtv '%s'; description="MPEG video files"; test=test -n "$DISPLAY"; priority=7
+audio/mpeg; /usr/bin/gtv %s; description="MPEG audio files"; test=test -n "$DISPLAY"; priority=2
+video/mpeg; /usr/bin/gtv %s; description="MPEG video files"; test=test -n "$DISPLAY"; priority=7
diff --git a/debian/smpeg-plaympeg.mime b/debian/smpeg-plaympeg.mime
index 4d97bac..7bdc0f5 100644
--- a/debian/smpeg-plaympeg.mime
+++ b/debian/smpeg-plaympeg.mime
@@ -1,2 +1,2 @@
-audio/mpeg; /usr/bin/plaympeg '%s'; description="MPEG audio files"; priority=2
-video/mpeg; /usr/bin/plaympeg '%s'; description="MPEG video files"; test=test -n "$DISPLAY"; priority=7
+audio/mpeg; /usr/bin/plaympeg %s; description="MPEG audio files"; priority=2
+video/mpeg; /usr/bin/plaympeg %s; description="MPEG video files"; test=test -n "$DISPLAY"; priority=7

Bug#987691: imagemagick has mailcap entries with quoted %-escapes

[Marriott NZ]

Package: imagemagick
Version: 8:6.9.11.60+dfsg-1.3
Tags: patch, security

Dear Maintainer,
the imagemagick package has mailcap entries with quoted %-escapes. That is 
considered unsafe. Proper escaping should be left to the programs using the 
entry.

This Lintian tag is triggered:
https://lintian.debian.org/tags/quoted-placeholder-in-mailcap-entry.html

See also grave bug #930908, which was recently closed because "a Lintian test 
already exists":
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930908

I'm using the "security" tag because the affected rules in combination with 
certain mail user agents (or document openers) are the cause of a shell command 
injection vulnerability.

If you need more information let me know.

Thanks,
MNZ
diff --git a/debian/imagemagick-IMVERSION.QUANTUMDEPTH.mime.in b/debian/imagemagick-IMVERSION.QUANTUMDEPTH.mime.in
index fd035f3..418f076 100644
--- a/debian/imagemagick-IMVERSION.QUANTUMDEPTH.mime.in
+++ b/debian/imagemagick-IMVERSION.QUANTUMDEPTH.mime.in
@@ -1,42 +1,42 @@
-image/avs; display-im${IMVERSION}.${QUANTUMDEPTH}. 'avs:%s'; test=test -n "$DISPLAY"; priority=2
-image/bie; display-im${IMVERSION}.${QUANTUMDEPTH} 'jbig:%s'; test=test -n "$DISPLAY"; priority=2
-image/x-ms-bmp; display-im${IMVERSION}.${QUANTUMDEPTH} 'bmp:%s'; test=test -n "$DISPLAY"; priority=2
-image/cmyk; display-im${IMVERSION}.${QUANTUMDEPTH} 'cmyk:%s'; test=test -n "$DISPLAY"; priority=2
-image/dcx; display-im${IMVERSION}.${QUANTUMDEPTH} 'dcx:%s'; test=test -n "$DISPLAY"; priority=2
-image/eps; display-im${IMVERSION}.${QUANTUMDEPTH} 'eps:%s'; test=test -n "$DISPLAY"; priority=2
-image/fax; display-im${IMVERSION}.${QUANTUMDEPTH} 'fax:%s'; test=test -n "$DISPLAY"; priority=2
-image/fits; display-im${IMVERSION}.${QUANTUMDEPTH} 'fits:%s'; test=test -n "$DISPLAY"; priority=2
-image/gif; display-im${IMVERSION}.${QUANTUMDEPTH} 'gif:%s'; test=test -n "$DISPLAY"; priority=2
-image/gray; display-im${IMVERSION}.${QUANTUMDEPTH} 'gray:%s'; test=test -n "$DISPLAY"; priority=2
-image/jpeg; display-im${IMVERSION}.${QUANTUMDEPTH} 'jpeg:%s'; test=test -n "$DISPLAY"; priority=2
-image/pjpeg; display-im${IMVERSION}.${QUANTUMDEPTH} 'jpeg:%s'; test=test -n "$DISPLAY"; priority=2
-image/miff; display-im${IMVERSION}.${QUANTUMDEPTH} 'miff:%s'; test=test -n "$DISPLAY"; priority=2
-image/mono; display-im${IMVERSION}.${QUANTUMDEPTH} 'mono:%s'; test=test -n "$DISPLAY"; priority=2
-image/mtv; display-im${IMVERSION}.${QUANTUMDEPTH} 'mtv:%s'; test=test -n "$DISPLAY"; priority=2
-image/x-portable-bitmap; display-im${IMVERSION}.${QUANTUMDEPTH} 'pbm:%s'; test=test -n "$DISPLAY"; priority=2
-image/pcd; display-im${IMVERSION}.${QUANTUMDEPTH} 'pcd:%s'; test=test -n "$DISPLAY"; priority=2
-image/pcx; display-im${IMVERSION}.${QUANTUMDEPTH} 'pcx:%s'; test=test -n "$DISPLAY"; priority=2
-image/pdf; display-im${IMVERSION}.${QUANTUMDEPTH} 'pdf:%s'; test=test -n "$DISPLAY"; priority=2
-image/x-portable-graymap; display-im${IMVERSION}.${QUANTUMDEPTH} 'pgm:%s'; test=test -n "$DISPLAY"; priority=2
-image/pict; display-im${IMVERSION}.${QUANTUMDEPTH} 'pict:%s'; test=test -n "$DISPLAY"; priority=2
-image/png; display-im${IMVERSION}.${QUANTUMDEPTH} 'png:%s'; test=test -n "$DISPLAY"; priority=2
-image/x-portable-anymap; display-im${IMVERSION}.${QUANTUMDEPTH} 'pnm:%s'; test=test -n "$DISPLAY"; priority=2
-image/x-portable-pixmap; display-im${IMVERSION}.${QUANTUMDEPTH} 'ppm:%s'; test=test -n "$DISPLAY"; priority=2
-image/ps; display-im${IMVERSION}.${QUANTUMDEPTH} 'ps:%s'; test=test -n "$DISPLAY"; priority=2
-image/rad; display-im${IMVERSION}.${QUANTUMDEPTH} 'rad:%s'; test=test -n "$DISPLAY"; priority=2
-image/x-rgb; display-im${IMVERSION}.${QUANTUMDEPTH} 'rgb:%s'; test=test -n "$DISPLAY"; priority=2
-image/rgba; display-im${IMVERSION}.${QUANTUMDEPTH} 'rgba:%s'; test=test -n "$DISPLAY"; priority=2
-image/rla; display-im${IMVERSION}.${QUANTUMDEPTH} 'rla:%s'; test=test -n "$DISPLAY"; priority=2
-image/rle; display-im${IMVERSION}.${QUANTUMDEPTH} 'rle:%s'; test=test -n "$DISPLAY"; priority=2
-image/sgi; display-im${IMVERSION}.${QUANTUMDEPTH} 'sgi:%s'; test=test -n "$DISPLAY"; priority=2
-image/sun-raster; display-im${IMVERSION}.${QUANTUMDEPTH} 'sun:%s'; test=test -n "$DISPLAY"; priority=2
-image/targa; display-im${IMVERSION}.${QUANTUMDEPTH} 'tga:%s'; test=test -n "$DISPLAY"; priority=2
-image/tiff; display-im${IMVERSION}.${QUANTUMDEPTH} 'tiff:%s'; test=test -n "$DISPLAY"; priority=2
-image/uyvy; display-im${IMVERSION}.${QUANTUMDEPTH} 'uyvy:%s'; test=test -n "$DISPLAY"; priority=2
-image/vid; display-im${IMVERSION}.${QUANTUMDEPTH} 'vid:%s'; test=test -n "$DISPLAY"; priority=2
-image/viff; display-im${IMVERSION}.${QUANTUMDEPTH} 'viff:%s'; test=test -n "$DISPLAY"; priority=2
-image/x-xbitmap; display-im${IMVERSION}.${QUANTUMDEPTH} 'xbm:%s'; test=test -n "$DISPLAY"; priority=2
-image/x-xpixmap; display-im${IMVERSION}.${QUANTUMDEPTH} 'xpm:%s'; test=test -n "$DISPLAY"; priority=2
-image/x-xwindowdump; display-im${IMVERSION}.${QUANTUMDEPTH} 'xwd:%s'; test=test 

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

[Alberto Garcia]

Control: notfound -1 webkit2gtk/2.32.0-2

On Tue, Apr 27, 2021 at 09:27:35PM +0200, Paul Gevers wrote:

> With a recent upload of webkit2gtk the autopkgtest of balsa fails
> in testing when that autopkgtest is run with the binary packages of
> webkit2gtk from unstable.

Nothing to do with webkit actually. The test launches Balsa, waits for
two seconds and then takes a screenshot of the window. The bug happens
because when xdg-desktop-portal-gtk is installed Balsa takes a very
long time to start so those two seconds are not enough.

g_application_register() calls g_dbus_proxy_new_sync(), and
that times out. The problem seems to disappear if you unset
DBUS_SESSION_BUS_ADDRESS, but that's a workaround I guess :)

I haven't debugged why this happens when xdg-desktop-portal-gtk is
installed.

More information here:

   https://bugs.launchpad.net/ubuntu/+source/webkit2gtk/+bug/1923817

Berto

Bug#979276: xserver-xorg-video-intel: Server fails to start: "Illegal instruction"

[Stefan Monnier]

Julien Cristau [2021-03-18 14:58:30] wrote:

> On Thu, Mar 18, 2021 at 09:39:36AM -0400, Stefan Monnier wrote:
>> > I tried to reconstruct the given backtrace in [1].
>> 
>> Thanks,
>> 
>> > So the actual issue seems to be a "movq" instruction which
>> > seems to be due to [3] a SSE2 instruction, which might
>> > the "Pentium III M" is lacking, like Stefan already noted.
>> > I am not sure where the current Debian baseline could be
>> > consulted regarding this, maybe [4] could give a hint.
>> 
>> AFAIK Debian's i386 architecture does not (yet) require SSE2 (as
>> witnessed by the existence of the package `sse2-support`).
>> 
>> Where does this instruction come from?
>> Is it generated by GCC (and if so, why does GCC generate it)?
>> 
>
> I'm guessing because of this:
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/blob/master/src/sna/blt.c#L37
>
> Does the below help?

I just tried to upgrade my `testing` installation but the problem is
still present.  Did you install the patch there?


Stefan

Bug#987690: openafs-fileserver: Servers do not work with des3-cbc-sha1 keys

[Chaskiel Grundman]

Package: openafs-fileserver
Version: 1.8.2-1+deb10u1
Severity: important
Tags: upstream

Dear Maintainer,

The servers in this release do not work when used with des3-cbc-sha1
(enctype 16) keys. The requested size of the key is computed incorrectly
as 21 bytes instead of 24, and authcon.c:_afsconf_GetRxkadKrb5Key rejects
the key from the KeyFileExt. If the 3des key is the only one available,
it is impossible to authenticate to the server, even with -localauth.

This has been fixed upstream (https://gerrit.openafs.org/#/c/14203/),
but the patch is apparently not yet in any release

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

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

Versions of packages openafs-fileserver depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libhcrypto4-heimdal7.5.0+dfsg-3
ii  libroken18-heimdal 7.5.0+dfsg-3
ii  lsb-base   10.2019051400
ii  openafs-client 1.8.2-1+deb10u1

Versions of packages openafs-fileserver recommends:
ii  ntp  1:4.2.8p12+dfsg-4

Versions of packages openafs-fileserver suggests:
pn  openafs-doc  

-- debconf information:
  openafs-fileserver/thiscell: grand.central.org
  openafs-fileserver/alpha-broken:

Bug#949767: arrayfire update fails in configure step

[Andreas Tille]

Hi Aaron,

On Mon, Apr 26, 2021 at 08:30:39AM -0400, Aaron M. Ucko wrote:
> Andreas Tille  writes:
> 
> > /usr/bin/ld: cannot find -lpthreads
> 
> Thanks for posting a link to the full log!  AFAICT, the actual errors
> appear much earlier, on lines 1573-1593:
> 
>   CMake Error: File 
> /builds/science-team/arrayfire/debian/output/source_dir/extern/forge/CMakeModules/version.h.in
>  does not exist.
>   CMake Error at CMakeModules/AFconfigure_forge_submodule.cmake:47 
> (configure_file):
> configure_file Problem configuring file
>   Call Stack (most recent call first):
> CMakeLists.txt:117 (include)
>   CMake Error at CMakeLists.txt:163 (add_subdirectory):
> add_subdirectory given source "extern/spdlog" which is not an existing
> directory.
>   CMake Error at CMakeLists.txt:164 (add_subdirectory):
> add_subdirectory given source "extern/glad" which is not an existing
> directory.
>   -- Performing Test has_ignored_attributes_flag
>   -- Performing Test has_ignored_attributes_flag - Success
>   -- Performing Test has_all_warnings_flag
>   -- Performing Test has_all_warnings_flag - Success
>   CMake Error at /usr/share/cmake-3.18/Modules/ExternalProject.cmake:2350 
> (message):
> error: could not find git for clone of clFFT-ext
>   Call Stack (most recent call first):
> /usr/share/cmake-3.18/Modules/ExternalProject.cmake:3206 
> (_ep_add_download_command)
> CMakeModules/build_clFFT.cmake:33 (ExternalProject_Add)
> src/backend/opencl/CMakeLists.txt:15 (include)
> 
> The subsequent output consists of dumps of CMake's internal logs, which
> sometimes provide additional clues but need to be taken in context; for
> instance, the -lpthreads error comes from

A, that hint brough me a bit further.  Unfortunately the configure
issue is not solved and I take the freedom to point again to the build
log in salsa-ci:

https://salsa.debian.org/science-team/arrayfire/-/jobs/1608881

I have no good idea how to continue from here.

Thanks a lot for your initial hint

  Andreas.


-- 
http://fam-tille.de

Bug#987688: Please add more filesystem drivers to hd-media

[Phillip Susi]

Package: debian-installer
Version: 20210415

I just tried using the hd-media build to boot from an existing hard disk
and install without using removable media and was not able to do so
because I used btrfs on the hard disk, and most filesystems are packaged
as separate udebs rather than being built into the initrd.  I think it
was only iso9660, fat, and ext4 that were in there.  Please consider
moving btrfs and probably a few other filesystem modules into the
hd-media initrd so that it can be used outside of ext4 and fat.

Bug#987537: RM: scrollz -- RoQA unmaintained, dead upstream, has security issues

[Mike Markley]

On Sun, Apr 25, 2021 at 11:33:32AM +0200, Tobias Frost  wrote:
> Additionally, even if there was a new upstream version in 2016, it was never
> packaged for Debian. This lets me believe that the package is no longer
> maintained in Debian.
> 
> Due to the fact that the scrollz has an open security issue, is not maintained
> upstream and Debian, having a very low popcon value and ircii being available,
> I think it is probably best to remove the package from Debian at this point.
> 
> If there is no answer to this bug within 3 months, I will reassign this bug to
> ftp.debian.org for the actual removal.
> 
> If you disagree, just close the bug, but it would be great if the package 
> could
> be fixed into back into an releasble state.

Unfortunately, though I'm still listed as the maintainer, I haven't had
a key in the keyring since 1024-bit GPG keys were removed and am not in
a position to actively upload.

I do see that there's a recent PR upstream to fix this CVE:
https://github.com/ScrollZ/ScrollZ/pull/26

I pinged the upstream author last week on IRC and didn't get a response,
so I don't know what the chances are that it will be merged. He may pay
more attention to GitHub email these days, though.

I haven't looked at the state of debhelper and the rest of the packaging
toolchain since my last upload. I could take a look at the latest version
and this patch and see about updating the existing source package with
those, but I don't know how much time I'll have to put into updating
anything that's changed, and I would still need help uploading.

-- 
Mike Markley 

Bug#987570: openjdk-11-jre-headless: libawt_xawt.so still listed as part of this package instead of openjdk-11-jre

[Adrian Bunk]

Control: severity -1 serious

On Sun, Apr 25, 2021 at 10:23:09PM +0200, GuyXY wrote:
> Package: openjdk-11-jre-headless
> Severity: important
> 
> After installing the latest security updates, davmail stopped working.
> I looked into it and found out, that it required the file 
> '/usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so' which was now missing 
> even tho it's supposed to be installed as part of the openjdk-11-jre-headless 
> package, which is installed as one of davmail's dependencies.
> 
> I asked for help in the #debian IRC channel, and we came to the conclusion 
> that the file has been moved to the openjdk-11-jre package.
> The package content list do not reflect those changes yet. Please adjust the 
> list of the package contents for openjdk-11-jre-headless and openjdk-11-jre 
> in Buster to avoid further confusion.
> 
> PS: It may also be a good idea to change the dependency from davmail from 
> openjdk-11-jre-headless to openjdk-11-jre as well or add it as a recommended 
> or at least suggested package.
> 
> -- System Information:
> Debian Release: 10.9
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)


   * Move libawt_xawt.so, libjawt.so into the jre package. Closes: #908058.

Such changes should not happen in an update to stable.


cu
Adrian

Bug#987687: ruby-excon will FTBFS after Feb 1 2022

[Adrian Bunk]

Source: ruby-excon
Version: 0.79.0-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/ruby-excon.html

...
I: Current time: Thu May 26 06:05:02 -12 2022
...
  Excon basics verify_hostname (ssl)
+ returns true
response.status - returns 200
SSL_connect returned=1 errno=0 state=error: certificate verify failed 
(certificate has expired) (OpenSSL::SSL::SSLError) Unable to verify 
certificate. This may be an issue with the remote host or with Excon. Excon has 
certificates bundled, but these can be customized:

`Excon.defaults[:ssl_ca_path] = path_to_certs`
`ENV['SSL_CERT_DIR'] = path_to_certs`
`Excon.defaults[:ssl_ca_file] = path_to_file`
`ENV['SSL_CERT_FILE'] = path_to_file`
`Excon.defaults[:ssl_verify_callback] = callback`
(see OpenSSL::SSL::SSLContext#verify_callback)
or:
`Excon.defaults[:ssl_verify_peer] = false` (less secure).
 (Excon::Error::Certificate)
  /build/ruby-excon-0.79.0/lib/excon/ssl_socket.rb:131:in `connect_nonblock'
  /build/ruby-excon-0.79.0/lib/excon/ssl_socket.rb:131:in `initialize'
  /build/ruby-excon-0.79.0/lib/excon/connection.rb:471:in `new'
  /build/ruby-excon-0.79.0/lib/excon/connection.rb:471:in `socket'
  /build/ruby-excon-0.79.0/lib/excon/connection.rb:118:in `request_call'
  /build/ruby-excon-0.79.0/lib/excon/middlewares/mock.rb:57:in 
`request_call'
  /build/ruby-excon-0.79.0/lib/excon/middlewares/instrumentor.rb:34:in 
`request_call'
  /build/ruby-excon-0.79.0/lib/excon/middlewares/idempotent.rb:19:in 
`request_call'
  /build/ruby-excon-0.79.0/lib/excon/middlewares/base.rb:22:in 
`request_call'
  /build/ruby-excon-0.79.0/lib/excon/middlewares/base.rb:22:in 
`request_call'
  /build/ruby-excon-0.79.0/lib/excon/connection.rb:283:in `request'
  /build/ruby-excon-0.79.0/tests/basic_tests.rb:151:in `block (3 levels) in 
'
  
/usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo.rb:140:in 
`instance_eval'
  
/usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo.rb:140:in 
`assert'
  
/usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo.rb:112:in 
`returns'
  /build/ruby-excon-0.79.0/tests/basic_tests.rb:150:in `block (2 levels) in 
'
  /build/ruby-excon-0.79.0/tests/test_helper.rb:259:in `with_rackup'
  /build/ruby-excon-0.79.0/tests/basic_tests.rb:142:in `block in '
  /usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo.rb:79:in 
`instance_eval'
  /usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo.rb:79:in 
`tests'
  /usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo.rb:38:in 
`initialize'
  /usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo.rb:13:in 
`new'
  /usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo.rb:13:in 
`tests'
  /build/ruby-excon-0.79.0/tests/basic_tests.rb:141:in `'
  
/usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo/bin.rb:61:in 
`load'
  
/usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo/bin.rb:61:in 
`block (2 levels) in run_in_thread'
  
/usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo/bin.rb:58:in 
`each'
  
/usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo/bin.rb:58:in 
`block in run_in_thread'
...
  357 failed, 12 pending, 691 succeeded in 34.135392980134036 seconds

rake aborted!

/usr/share/rubygems-integration/all/gems/shindo-0.3.8/lib/shindo/rake.rb:11:in 
`block in initialize'
/usr/share/rubygems-integration/all/gems/rake-13.0.3/exe/rake:27:in `'
Tasks: TOP => default => tests
(See full trace by running task with --trace)
ERROR: Test "ruby2.7" failed. Exiting.
dh_auto_install: error: dh_ruby --install 
/build/ruby-excon-0.79.0/debian/ruby-excon returned exit code 1
make: *** [debian/rules:7: binary] Error 25

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

[Paul Gevers]

Source: webkit2gtk, balsa
Control: found -1 webkit2gtk/2.32.0-2
Control: found -1 balsa/2.6.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of webkit2gtk the autopkgtest of balsa fails in
testing when that autopkgtest is run with the binary packages of
webkit2gtk from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
webkit2gtk from testing2.32.0-2
balsa  from testing2.6.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of webkit2gtk to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found 
on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=webkit2gtk

https://ci.debian.net/data/autopkgtest/testing/amd64/b/balsa/11951071/log.gz

autopkgtest [11:13:01]: test screenshot: [---
working directory:
/tmp/autopkgtest-lxc.xger5btt/downtmp/screenshot-artifacts
xwd: error: No window with name Balsa exists!
gm convert: Improper image header (/tmp/gmxD2SKj).
gm compare: Request did not return an image.
autopkgtest [11:13:04]: test screenshot: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976114: Upstream fix

[Kim Christensen]

Hi

According to upstream the issue should have been fixed by version 0.7.1a4
of the library. See:
https://sourceforge.net/p/raspberry-gpio-python/tickets/191/#68c1

Any chance that it will make it into testing?

If a test build is available I'll be happy to test it on my rpi 4B 8GB.

Regards
Kim

-- 
Ideas don't stay in some minds very long because they don't like solitary
confinement. - Howard Aiken

Bug#987685: closed by Sebastian Ramacher (unblock raspi-firmware)

[Gunnar Wolf]

Debian Bug Tracking System dijo [Tue, Apr 27, 2021 at 06:45:03PM +]:
> #987685: unblock: raspi-firmware/1.20210303+ds-1
> 
> It has been closed by Sebastian Ramacher .

That was fast. Thanks!

Bug#983357: #983357: Netinst crashes xen domU when loading kernel

[Phillip Susi]

affects 983357 + debian-installer
severify 983357 serious
thanks

It appears that the root cause of this bug has been reported upstream
here:

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

It seems that there is an error trying to udev trigger the Xen virtual
keyboard, and this causes start-udev to bail out, which causes init to
bail out and the kernel to panic.  Removing the set -e from start-udev
appears to be a viable workaround that d-i might want to consider.

Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before the shell

[Étienne Mollier]

Hi Cyril,

Since the LVM result I caught seemed to contradict your own
findings, I did a few more tests in that configuration.  I'm
afraid I failed to identify any regular pattern, although I did
try hard to see whether things such as word wrapping might be
involved in some way, so I'm just putting a list of the locales,
VG and LV names I tested today:

Locale  Block device nameResult
--  ---  --
en_US   /dev/debian-vg/root  ok(default LVM config)
/dev/m/0 ok
/dev/vg/0ok
/dev/md/0blank (silly! for debug purpose)
/dev/mx/0blank
/dev/mm/0blank
/dev/mmx/0   ok
/dev/mmm/0   ok
/dev//0  ok
/dev//0  ok
/dev/m/0 ok
/dev/mm/0ok
--  ---  --
fr_FR   /dev/debian-vg/root  blank (default LVM config)
/dev/debian-vg/0 blank
/dev/xx-xx/0 blank
/dev/-/0 blank
/dev/x-xxx/0 blank
/dev/-/0 ok(!)
/dev/mm-mm/0 ok
/dev/x/0 ok
/dev/xxixx/0 ok
/dev/x-xx/0  ok
/dev/x-/0ok
/dev/x-x/0   ok
/dev/debianxvg/0 ok
/dev/vg/0ok
/dev//0  ok
/dev/mx/0ok
/dev/mm/0ok
/dev/debian-vg/operatingsystemblank

Thankfully, vgrename allowed me to change quickly between each
try.  I guess this is very long winded, but hope this helps.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#987685: unblock: raspi-firmware/1.20210303+ds-1

[Gunnar Wolf]

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

Please unblock package raspi-firmware

Upstream release for the Raspberry Pi non-free firmware, needed for
booting their systems with Linux

[ Reason ]

We would like to release Bullseye with the latest firmware, as it
often contains bugfixes. The contents of the firmware are opaque to
us.

[ Impact ]

No ill effects would stem from not approving this; we did upload
before the current freeze came into effect, but are applying only now
because I waited for the needed 20 days.

[ Tests ]

I have built and tested images with this firmware for all of the
Raspberry lineup (0W, 1 using armel; 2 using armhf; 3, 4 and p400
using arm64).

[ Risks ]

There is the always latent risk when using non-free software that this
change might break something. That is true, of course, also of the
currently present version. Version 2.20210303 has been used by
thousands of users, and no updates have been posted in close to two
months by the Raspberry foundation.

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

[ Other info ]

Please note that raspi-firmware is in *non-free*.

Not attaching debdiff as it is not relevant (i.e. the only nonbinary
change is in debian/changelog)

I have some pending changes in the Debian packaging side I will upload
(and apply for an unblock request, if we make it in time for Bullseye.

unblock raspi-firmware/1.20210303+ds-1

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

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

Bug#987467: autopkgtest library fails with: FAIL stderr: pkill: killing pid 1764 failed: Operation not permitted

[Gianfranco Costamagna]

control: fixed -1 2.0.10-6
control: close -1

thanks

On Sat, 24 Apr 2021 16:19:48 +0200 Chris Hofstaedtler  wrote:
> * Brian Thompson  [210424 14:04]:
> > > autopkgtest [21:45:54]: test library: [---
> > > pkill: killing pid 1764 failed: Operation not permitted
> [..]
> 
> > I'm not a maintainer, but I see that in the code the command does what
> > it intends to do, checks out with the man pages although I haven't read
> > it myself:
> > 
> > # Tell Mosquitto to reload certificates and configuration
> > pkill -HUP -x mosquitto
> 
> Not sure which code you were looking at, but my copy of
> debian/tests/library only has:
> 
> | pkill -x mosquitto
> | make -C test/lib test
> 
> That code seems irritating to me. It certainly does not work, see
> "Operation not permitted" above.
> 
> Chris
> 
> 

Bug#987684: php-horde-crypt: flaky autopkgtest: Could not obtain public key from the keyserver

[Paul Gevers]

Source: php-horde-crypt
Version: 2.7.12-5
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] and I noticed it fails regularly
lately.

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

By the way, if your test needs internet access, please mark that in the
restrictions with `needs-internet`.

Paul

[1] https://ci.debian.net/packages/p/php-horde-crypt/testing/amd64/

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-horde-crypt/11893421/log.gz

autopkgtest [14:12:26]: test phpunit: [---
PHPUnit 9.5.2 by Sebastian Bergmann and contributors.

Runtime:   PHP 7.4.15
Configuration:
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/phpunit.xml

Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/Pgp/BinaryTest.php
   Class name was 'Horde_Crypt_Pgp_BinaryTest', expected
'BinaryTest'
Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php
   Class name was 'Horde_Crypt_PgpKeyserverTest', expected
'PgpKeyserverTest'
Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpParseTest.php
   Class name was 'Horde_Crypt_PgpParseTest', expected
'PgpParseTest'
Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/SmimeTest.php
   Class name was 'Horde_Crypt_SmimeTest', expected 'SmimeTest'

...SSE26 /
26 (100%)

Time: 00:30.896, Memory: 6.00 MB

There was 1 error:

1) Horde_Crypt_PgpKeyserverTest::testBrokenKeyserver
Horde_Crypt_Exception: Could not obtain public key from the keyserver.

/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/lib/Horde/Crypt/Pgp/Keyserver.php:110
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/lib/Horde/Crypt/Pgp/Keyserver.php:230
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php:80

--

There were 2 skipped tests:

1) Horde_Crypt_PgpKeyserverTest::testKeyserverRetrieve
Problem with
http://pool.sks-keyservers.net:11371/pks/lookup?op=get=0x4DE5B969: 
fopen(http://pool.sks-keyservers.net:11371/pks/lookup?op=get=0x4DE5B969):
failed to open stream: HTTP request failed!

/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php:46

2) Horde_Crypt_PgpKeyserverTest::testKeyserverRetrieveByEmail
Problem with
http://pool.sks-keyservers.net:11371/pks/lookup?op=index=mr=jan%40horde.org:
fopen(http://pool.sks-keyservers.net:11371/pks/lookup?op=index=mr=jan%40horde.org):
failed to open stream: HTTP request failed!

/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php:62

ERRORS!
Tests: 26, Assertions: 62, Errors: 1, Skipped: 2.
autopkgtest [14:12:58]: test phpunit: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Antoine Beaupre]

Package: elpa-esup
Version: 0.7.1-3
Severity: grave
Tags: upstream

This package is unusable in Debian 11 bullseye in its current
state. In my Emacs 1:27.1+1-3.1 session, i run M-x esup and I get:

error in process sentinel: Wrong type argument: (or eieio-object class), nil, 
obj

*Messages* has this:

Loading /usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup-autoloads.el 
(source)...done
Starting esup...
esup process started on port 37851
at 1
error in process sentinel: slot-value: Wrong type argument: (or eieio-object 
class), nil, obj
error in process sentinel: Wrong type argument: (or eieio-object class), nil, 
obj

This is the upstream bug: https://github.com/jschaf/esup/issues/85

It looks like it is a packaging issue, since, according to the above
bug report, recompiling the .el files fixes the problem (haven't tested).

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 elpa-esup depends on:
ii  dh-elpa-helper  2.0.8
ii  emacsen-common  3.0.4

Versions of packages elpa-esup recommends:
ii  emacs  1:27.1+1-3.1
ii  emacs-gtk [emacs]  1:27.1+1-3.1

elpa-esup suggests no packages.

-- debconf-show failed

Bug#987649: unblock: libxcrypt/1:4.4.18-4

[Paul Gevers]

Control: tags -1 confirmed d-i

Hi kibi,

To be totally sure, I understood from our IRC chat yesterday that you're
OK with migrating udeb's like this one at this moment.

On 27-04-2021 00:47, Marco d'Itri wrote:
> Please unblock package libxcrypt
> 
> [ Reason ]
> This fixes some related issues which sometimes caused upgrades to fail, 

> by moving the library back from /usr/lib/ to /lib/ .
> 
> [ Impact ]
> Some upgrades to bullseye will randomly fail and we really do not want 
> this.
> 
> [ Tests ]
> autopkgtests passed.
> 
> [ Risks ]
> The actual change (moving the library back to /lib/) is trivial, and 
> since nothing broke spectacularly as soon as I uploaded the new package 

> then it very probably is fine.
> There are no changes at all to the udeb.
> 
> unblock libxcrypt/1:4.4.18-4

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987638: linux-image-5.10.0-6-arm64: Missing kernel modules for Pine64's Pinebook Pro (usb-c, battery gauge, audio)

[Lionel Fourquaux]

On Tue, Apr 27, 2021 at 06:28:15PM +0200, Vincent Blut wrote:

As it's not clear from your message, did you also enable CONFIG_TYPEC and
CONFIG_TYPEC_TCPM as modules?


Yes, these are required for enabling CONFIG_TYPEC_FUSB302.  (I should 
indeed have stated it explicitly.)


Best regards,

-- Lionel

Bug#987682: Netboot teres installer does not accept a local file mirror

[Karl Semich]

Package: installation-reports

Boot method: sd card
Image version: bullseye
http://ftp.nl.debian.org/debian/dists/bullseye/main/installer-arm64/20210415/images/netboot/SD-card-images/partition.img.gz
and firmware.teres_i.img.gz
Date: 2021-04-27

Machine: Teres I
Processor: arm
Memory: n/a
Partitions: n/a

Output of lspci -knn (or lspci -nn): n/a

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

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

Comments/Problems:

The installer is forcing me to configure a wireless network before
selecting a debian mirror, such that I cannot install without wifi.
As this is the only installer for teres, it's important to be able to
use a local file mirror.

Bug#987681: libtycho-java: please update tycho to new upstream version 2.0.0 or newer

[Joseph Nahmias]

Package: libtycho-java
Version: 1.6.0-2
Severity: wishlist
X-Debbugs-Cc: j...@nahmias.net

Hello,

I am trying to build some software that requires tycho 2.0.0, which was
release on 2020-08-03. Since then there have been a few more releases,
with 2.3.0 released on 2021-03-24. It would be great if Debian could
provide a newer version -- at least in unstable.

Thanks,
--Joe

Bug#987679: unblock: kongress/1.0.1-1

[Aurélien COUDERC]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Debian KDE Extras Team 

Dear Release Team,

please unblock package kongress.

[ Reason ]
This upload includes a minor upstream release with only targetted
fixes, and a trivial copyright fix.

The upstream fixes are the following:
- Fix display of talk time on notifications
- Prevent kongressac from crashing
- Fix grouping of talks into conference days
- Fix alarm schedule time
- Prevent duplicate conference entries from being displayed
- Do not display generic, multi-day calendar events on the daily schedule
- Fix translation congiguration

[ Impact ]
Users won’t get the above listed fixes.

[ Tests ]
I tested all main functionality manually.

[ Risks ]
None that I can see, individual upstream commits could be reverted if
need be.

[ 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 ]
<3 <3 <3

unblock kongress/1.0.1-1
diff -Nru kongress-1.0/AndroidManifest.xml kongress-1.0.1/AndroidManifest.xml
--- kongress-1.0/AndroidManifest.xml2021-01-25 16:45:58.0 +0100
+++ kongress-1.0.1/AndroidManifest.xml  2021-03-08 10:21:05.0 +0100
@@ -5,7 +5,7 @@
 -->
 http://schemas.android.com/apk/res/android;
   package="org.kde.kongress"
-  android:versionName="1.0.0"
+  android:versionName="1.0.1"
   android:versionCode="1"
   android:installLocation="auto">
 
diff -Nru kongress-1.0/changelog.md kongress-1.0.1/changelog.md
--- kongress-1.0/changelog.md   2021-01-25 16:45:58.0 +0100
+++ kongress-1.0.1/changelog.md 2021-03-08 10:21:05.0 +0100
@@ -1,3 +1,17 @@
+
+
+## Version 1.0.1
+- Fix display of talk time on notifications
+- Prevent kongressac from crashing
+- Fix grouping of talks into conference days
+- Fix alarm schedule time
+- Prevent duplicate conference entries from being displayed
+- Do not display generic, multi-day calendar events on the daily schedule
+- Fix translation congiguration
+
 ## Version 1.0
 - Display the schedule of a collection of conferences
 - Show the schedule of the talks by conference day
diff -Nru kongress-1.0/CMakeLists.txt kongress-1.0.1/CMakeLists.txt
--- kongress-1.0/CMakeLists.txt 2021-01-25 16:45:58.0 +0100
+++ kongress-1.0.1/CMakeLists.txt   2021-03-08 10:21:05.0 +0100
@@ -4,7 +4,7 @@
 
 cmake_minimum_required(VERSION 3.0)
 
-project(kongress VERSION "1.0")
+project(kongress VERSION "1.0.1")
 
 set(KF5_MIN_VERSION "5.63.0")
 set(QT_MIN_VERSION "5.7.0")
@@ -14,6 +14,7 @@
 
 option(REMINDERS_ENABLED "Build with reminders support" ON)
 
+include(CTest)
 include(FeatureSummary)
 
 find_package(ECM ${KF5_MIN_VERSION} REQUIRED NO_MODULE)
@@ -26,7 +27,7 @@
 include(KDECompilerSettings NO_POLICY_SCOPE)
 include(ECMPoQmTools)
 
-find_package(Qt5 ${QT_MIN_VERSION} REQUIRED NO_MODULE COMPONENTS DBus Core 
Quick Gui Svg Test Qml QuickControls2 Network)
+find_package(Qt5 ${QT_MIN_VERSION} REQUIRED NO_MODULE COMPONENTS DBus Core 
Quick Gui Svg Qml QuickControls2 Network)
 
 find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS Config Kirigami2 I18n 
CalendarCore CoreAddons)
 
@@ -37,7 +38,9 @@
 else()
 find_package(Qt5 ${QT_MIN_VERSION} REQUIRED COMPONENTS Widgets)
 endif()
-
+if (BUILD_TESTING)
+find_package(Qt5 ${QT_MIN_VERSION} REQUIRED NO_MODULE COMPONENTS Test)
+endif()
 if(NOT ANDROID AND REMINDERS_ENABLED)
 find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS DBusAddons 
Notifications Service)
 endif()
@@ -49,7 +52,7 @@
 endif()
 
 if (IS_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/po")
-ecm_install_po_files_as_qm(po)
+ki18n_install(po)
 endif()
 
 install(FILES org.kde.kongress.appdata.xml DESTINATION 
${KDE_INSTALL_METAINFODIR})
diff -Nru kongress-1.0/debian/changelog kongress-1.0.1/debian/changelog
--- kongress-1.0/debian/changelog   2021-01-26 16:26:16.0 +0100
+++ kongress-1.0.1/debian/changelog 2021-03-29 10:42:07.0 +0200
@@ -1,3 +1,17 @@
+kongress (1.0.1-1) unstable; urgency=medium
+
+  * New upstream release (1.0.1):
+- Fix display of talk time on notifications
+- Prevent kongressac from crashing
+- Fix grouping of talks into conference days
+- Fix alarm schedule time
+- Prevent duplicate conference entries from being displayed
+- Do not display generic, multi-day calendar events on the daily schedule
+- Fix translation congiguration
+  * Minor fixes to debian/copyright.
+
+ -- Aurélien COUDERC   Mon, 29 Mar 2021 10:42:07 +0200
+
 kongress (1.0-1) unstable; urgency=medium
 
   * Initial release. (Closes: #981109)
diff -Nru kongress-1.0/debian/copyright kongress-1.0.1/debian/copyright
--- kongress-1.0/debian/copyright   2021-01-26 15:28:23.0 +0100
+++ kongress-1.0.1/debian/copyright 2021-03-29 10:38:59.0 +0200
@@ -32,8 +32,7 @@
 License: 

Bug#987678: unblock: udisks2/2.9.2-2

[Michael Biebl]

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

Please unblock package udisks2

It fixes #987582:
udisks_client_get_block_for_drive() always returns the wrong block of eMMC

It's an upstream cherry-pick which ensure eMMC block devices are
detected correctly.

[ Tests ]
No automated tests for this code, but the fix was confirmed by the
original bug submitter.

[ Risks ]
udisks2 is a key package, but the change is rather small, see
https://github.com/storaged-project/udisks/commit/5d0ac7ebefb8b7aad73871936f5011545cc66344

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

unblock udisks2/2.9.2-2
diff --git a/debian/changelog b/debian/changelog
index fabe2505..51c3b887 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+udisks2 (2.9.2-2) unstable; urgency=medium
+
+  * udisksclient: Make get_block_for_drive deterministic.
+Fixes "udisks_client_get_block_for_drive() always returns the wrong
+block of eMMC". (Closes: #987582)
+
+ -- Michael Biebl   Mon, 26 Apr 2021 21:12:10 +0200
+
 udisks2 (2.9.2-1) unstable; urgency=medium
 
   * New upstream version 2.9.2
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index ..b5f3547a
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+udisksclient-Make-get_block_for_drive-deterministic.patch
diff --git 
a/debian/patches/udisksclient-Make-get_block_for_drive-deterministic.patch 
b/debian/patches/udisksclient-Make-get_block_for_drive-deterministic.patch
new file mode 100644
index ..e33737f0
--- /dev/null
+++ b/debian/patches/udisksclient-Make-get_block_for_drive-deterministic.patch
@@ -0,0 +1,71 @@
+From: Will Thompson 
+Date: Wed, 21 Apr 2021 10:56:30 +0100
+Subject: udisksclient: Make get_block_for_drive deterministic
+
+While any given Block object has at most one corresponding Drive, many
+Block objects may share the same Drive. One example is eMMC devices
+which provide a block device for the main data area (e.g. /dev/mmcblk0)
+as well as additional logical block devices for device partitions (e.g.
+/dev/mmcblk0boot0 and /dev/mmcblk0boot1).
+
+This behaviour was introduced in #834 to resolve issue #619 that these
+device partitions caused a phantom additional Drive object to be
+exposed. On that issue, I wrote:
+
+> I believe that Block.Drive on the boot partitions should point to the
+> same data area as the main data area (and its logical partitions);
+> udisks_client_get_block_for_drive() on the drive should return
+> /org/freedesktop/UDisks2/block_devices/mmcblk0.
+
+The first part is now true, but as described on #879 the second part is
+not true. It is now non-deterministic which Block will be returned,
+based only on the order of objects returned by
+g_dbus_object_manager_get_objects().
+
+Make the return value of udisks_client_get_block_for_drive()
+deterministic by sorting the list of candidate Block objects by their
+device path in lexicographic order. Since (e.g.) /dev/mmcblk0 sorts
+before /dev/mmcblk0boot0, this has the desirable side-effect that
+calling udisks_client_get_block_for_drive() on an eMMC Drive returns the
+'real' Block for the main data area.
+
+Fixes #879.
+
+(cherry picked from commit 5d0ac7ebefb8b7aad73871936f5011545cc66344)
+---
+ udisks/udisksclient.c | 15 +++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/udisks/udisksclient.c b/udisks/udisksclient.c
+index 463b15a..1855209 100644
+--- a/udisks/udisksclient.c
 b/udisks/udisksclient.c
+@@ -816,6 +816,20 @@ udisks_client_get_block_for_dev (UDisksClient *client,
+ 
+ /* 

 */
+ 
++static int
++compare_blocks_by_device (gconstpointer a,
++  gconstpointer b)
++{
++  UDisksBlock *block_a = udisks_object_get_block (UDISKS_OBJECT (a));
++  UDisksBlock *block_b = udisks_object_get_block (UDISKS_OBJECT (b));
++
++  g_assert (block_a != NULL);
++  g_assert (block_b != NULL);
++
++  return g_strcmp0 (udisks_block_get_device (block_a),
++udisks_block_get_device (block_b));
++}
++
+ static GList *
+ get_top_level_blocks_for_drive (UDisksClient *client,
+ const gchar  *drive_object_path)
+@@ -847,6 +861,7 @@ get_top_level_blocks_for_drive (UDisksClient *client,
+ }
+   g_object_unref (block);
+ }
++  ret = g_list_sort (ret, compare_blocks_by_device);
+   g_list_free_full (object_proxies, g_object_unref);
+   return ret;
+ }

Bug#987638: linux-image-5.10.0-6-arm64: Missing kernel modules for Pine64's Pinebook Pro (usb-c, battery gauge, audio)

[Vincent Blut]

Salut Lionel,

Le 2021-04-27 11:27, Lionel Fourquaux a écrit :
> On Mon, Apr 26, 2021 at 11:19:29PM +0200, Vincent Blut wrote:
> > A merge request [1] has been proposed today to improve support for the 
> > Pinebook
> > Pro.
> 
> Thanks! (The merge request and this report are related.)
> 
> Some additional information: I (finally) managed to (cross-)build a Debian
> kernel package and test this:
>  * the battery gauge is working!

Great.

>  * the usb-c port gets its FUSB302 driver, but hits an error later:
> [8.656555] OF: graph: no port node found in /i2c@ff3d/fusb30x@22
>(This may be related to this patch to the DTD:
>   
> https://patchwork.kernel.org/project/linux-rockchip/patch/20200924063042.41545-1-...@endlessos.org/
>which made the monitor work, or possibly another missing driver.)

As it's not clear from your message, did you also enable CONFIG_TYPEC and
CONFIG_TYPEC_TCPM as modules?

>  * pulseaudio starts correctly (unlike before), but no sound (note: the
> internal switch controlling the audio jack is set in "serial port"mode;
> I'm not sure whether this affects the speakers, I will tryflipping the
> switch later).
> 
> So this is clearly an improvement (especially the battery gauge), but not a
> complete solution.
>
> Best regards,
> 
>   -- Lionel

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#959812: Acknowledgement (munin-plugins-core: varnish_ plugin no output (X not part of varnishstat))

[Marco d'Itri]

On May 05, root  wrote:

> This bug applies to all "aspects" of the munnin "varnish_" plugin. None of 
> them produce any data in their graphs OOTB on Debian 10.

Yes, the varnish_ plugin in the Debian munin package is totally useless 
because it targets Varnish 3.
Debian uses Varnish 6, hence the varnish5_ plugin from munin-monitoring 
is needed:
https://github.com/munin-monitoring/contrib/tree/master/plugins/varnish

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#987677: bornagain: contains ccache prebuilt objects

[Yangfl]

Source: bornagain
Severity: important

Hi, the source tarball contains lots of ccache prebuilt objects under
.ccache. Please consider removing them.

Bug#987652: surf does not start

[Jochen Sprickerhof]

* Aymeric Agon-Rambosson  [2021-04-27 03:18]:

$ /usr/bin/surf

output :

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: the GVariant format 
string '(ii)' has a type of '(ii)' but the given value has a type of 'i'

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: g_variant_get: 
assertion 'valid_format_string (format_string, TRUE, value)' failed

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: the GVariant format 
string '(ii)' has a type of '(ii)' but the given value has a type of 'i'

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: g_variant_get: 
assertion 'valid_format_string (format_string, TRUE, value)' failed
web process terminated: crashed


Also, can you check if you have a custom webext-surf.so in your ~/.surf 
or elsewhere in your ld path?


signature.asc
Description: PGP signature

Bug#987673: mkdepend accesses the internet during the build

[Andrius Merkys]

Control: owner -1 !

Hi,

Thanks for the report. I have applied the patch, will try to get it into
bullseye (asked for unblock in #987676).

Best,
Andrius

Bug#987676: unblock: mkdepend/0.0~svn45-3

[Andrius Merkys]

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

Dear release-team,

I am seeking pre-approval to upload mkdepend/0.0~svn45-3.

[ Reason ]
mkdepend/0.0~svn45-2 tries to access the network during build due to
missing stylesheet (#987673). The fix is to depend on a package
containing the required stylesheets, docbook-xsl.

[ Impact ]
Without the fix, mkdepend will fail to build on builders with disabled
network access.

[ Tests ]
* Built on clean sid chroot;
* Autopkgtest passes;
* The same fix is applied in Ubuntu and works on their builders [1].

[ Risks ]
Most likely none. Currently mkdepend is a leaf package in Debian.

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

unblock mkdepend/0.0~svn45-3

[1]
https://launchpadlibrarian.net/522238692/mkdepend_0.0~svn45-2_0.0~svn45-2ubuntu1.diff.gz

Best,
Andrius
diff -Nru mkdepend-0.0~svn45/debian/changelog 
mkdepend-0.0~svn45/debian/changelog
--- mkdepend-0.0~svn45/debian/changelog 2020-12-07 05:10:15.0 -0500
+++ mkdepend-0.0~svn45/debian/changelog 2021-04-27 11:23:46.0 -0400
@@ -1,3 +1,10 @@
+mkdepend (0.0~svn45-3) unstable; urgency=medium
+
+  * Build-depend on docbook-xsl to remove the need to download the stylesheet
+using network (Closes: #987673).
+
+ -- Andrius Merkys   Tue, 27 Apr 2021 11:23:46 -0400
+
 mkdepend (0.0~svn45-2) unstable; urgency=medium
 
   * Adding autopkgtest.
diff -Nru mkdepend-0.0~svn45/debian/control mkdepend-0.0~svn45/debian/control
--- mkdepend-0.0~svn45/debian/control   2020-12-07 05:10:15.0 -0500
+++ mkdepend-0.0~svn45/debian/control   2021-04-27 11:23:46.0 -0400
@@ -6,6 +6,7 @@
  asciidoc-base,
  debhelper-compat (= 12),
  docbook-xml,
+ docbook-xsl,
  xsltproc,
 Standards-Version: 4.5.0
 Rules-Requires-Root: no

Bug#987618: petsc: please add some Breaks for smoother upgrades from buster

[Drew Parsons]

Source: petsc
Followup-For: Bug #987618


ACK.  Thanks for finding this, Andreas. I'll upload once the current
update (-3) is migrated.

Drew

Bug#987652: surf does not start

[Jochen Sprickerhof]

Control: severity -1 normal
Control: tags -1 = moreinfo unreproducible

Hi,

I was not able to reproduce this on testing nor unstable.

* Aymeric Agon-Rambosson  [2021-04-27 03:18]:

$ /usr/bin/surf

output :

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: the GVariant format 
string '(ii)' has a type of '(ii)' but the given value has a type of 'i'

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: g_variant_get: 
assertion 'valid_format_string (format_string, TRUE, value)' failed

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: the GVariant format 
string '(ii)' has a type of '(ii)' but the given value has a type of 'i'

(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: g_variant_get: 
assertion 'valid_format_string (format_string, TRUE, value)' failed
web process terminated: crashed


Can you attach a gdb and send a backtrace?


The problem can be traced back to this specific upstream commit : 
e92fd1aa5f38c399f8fc5d263026fbd9d34ddfbb

Which can be found at 
https://git.suckless.org/surf/commit/e92fd1aa5f38c399f8fc5d263026fbd9d34ddfbb.html


That is there since over a year and I'm not aware of any issues with it, 
probably a red herring. How did you test that?



-- Configuration Files:
/etc/apparmor.d/usr.bin.surf changed:


Probably unrelated but maybe a good idea to reset this to the default.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#987675: sensible-utils: select-editor misbehaves on missing HOME variable

[Guillem Jover]

Package: sensible-utils
Version: 0.0.14
Severity: normal

Hi!

The select-editor program misbehaves when the environment does not
contain the HOME variable set. For normal users this means the code
will be unable to write to «/.selected_editor», for root that means
the code will pollute the «/» directory.

Please check whether HOME is set, and otherwise initialize it with a
sensible value, f.ex. from «getent passwd $user|cut -d: -f6» or
similar.

An easy way to test this is with «env -i sensible-editor».

Thanks,
Guillem

Bug#987638: linux-image-5.10.0-6-arm64: Missing kernel modules for Pine64's Pinebook Pro (usb-c, battery gauge, audio)

[Vagrant Cascadian]

On 2021-04-27, Lionel Fourquaux wrote:
> On Mon, Apr 26, 2021 at 11:19:29PM +0200, Vincent Blut wrote:
>>A merge request [1] has been proposed today to improve support for the 
>>Pinebook
>>Pro.
>
> Thanks! (The merge request and this report are related.)
>
> Some additional information: I (finally) managed to (cross-)build 
> a Debian kernel package and test this:
>   * the battery gauge is working!
>   * the usb-c port gets its FUSB302 driver, but hits an error later:

I've tested that a usb-c dock works (for the most part) with this patch
applied, so that's pretty exciting. Charging also worked, though not
necessarily when using the dock... though sometimes.

I have the impression the orientation of the usb-c connector *should
not* matter, but after flipping it all the usb-3 devices and ports on
the dock consistently started working...


> [8.656555] OF: graph: no port node found in /i2c@ff3d/fusb30x@22

I didn't notice this in the logs, but didn't check... will look at next
boot.


> (This may be related to this patch to the DTD:
>
> https://patchwork.kernel.org/project/linux-rockchip/patch/20200924063042.41545-1-...@endlessos.org/
> which made the monitor work, or possibly another missing driver.)

Seems unlikely related to that...


>   * pulseaudio starts correctly (unlike before), but no sound (note: the 
> internal switch controlling the audio jack is set in "serial port" 
> mode; I'm not sure whether this affects the speakers, I will try 
> flipping the switch later).

I did get audio out working via the audio jack after fiddling
haphazardly with the dozens of audio control sliders, but was unable to
get the microphone to work. I think I had to unmute the left and right
headphone mux or something. I got some sign that the speakers were
enabled when muting or unmuting (a little pop sound each time), but no
working audio.


> So this is clearly an improvement (especially the battery gauge), but not 
> a complete solution.

Agreed!


Thanks for pointing us to enabling these features!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#987674: RFP: checkbox -- The checkbox project coordinates various testing and certification activities in Ubuntu

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: checkbox
  Version : ?
  Upstream Author : Checkbox developers https://launchpad.net/~checkbox-dev
* URL : https://launchpad.net/checkbox-project
* License : GPLv3
  Programming Lang: Python
  Description : The checkbox project coordinates various testing and 
certification activities in Ubuntu

https://checkbox.readthedocs.io/en/latest/

Checkbox is a flexible test automation software. It’s the main tool
used in Ubuntu Certification program.

You can use checkbox without any modification to check if your system
is behaving correctly or you can develop your own set of tests to
check your needs. See Checkbox tutorials for details.

Checkbox optionally generates test reports in different formats (JSON,
HTML, etc.) that can be used to easily share the results of a test
session.



This is an interesting program. It seems like Ubuntu has been using
this in their certification program for ages, yet it has never come
onto my radar, even though I've been working on a similar project
(called stressant, packaged in Debian) for years as well.

Stressant is much less fine-tuned, and flexible, so I'm thinking of
abandoning it in favor of making an effort to package this into Debian
directly.

This could presumably be packaged under the Python team, but I can't
help but think we could collaborate with Ubuntu on that one somehow,
or just treat it as an upstream and regularly import their
stuff. Confusingly, it seems the package has shipped only in Ubuntu
Xenial:

https://packages.ubuntu.com/search?keywords=checkbox

That's because they switch to snap-only packaging. The package was, in
fact, available in Debian (stretch) but was removed because of that
switch:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926953

I still think this would be a useful addition to Debian, regardless of
upstream's policy on packaging. Maybe water has passed under the
bridge enough that we can make a .deb out of this again? Or is this a
waste of time?

My primary use case for this would be to bundle it in something like
grml so I can do burn-ins on new boxes easily. It seems it would be
much harder to do this from a snap than a .deb.

a.

Bug#987673: mkdepend accesses the internet during the build

[Adrian Bunk]

Source: mkdepend
Version: 0.0~svn45-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/mkdepend.html

...
dh_auto_build -- man
make -j15 "INSTALL=install --strip-program=true" man
make[2]: Entering directory '/build/mkdepend-0.0~svn45'
a2x -d manpage -f manpage doc/mkcomdepend.txt
a2x -d manpage -f manpage doc/mktexdepend.txt
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam 
navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 
 "/etc/asciidoc/docbook-xsl/manpage.xsl" 
"/build/mkdepend-0.0~svn45/doc/mktexdepend.xml" returned non-zero exit status 5

make[2]: *** [Makelocal-manpages:7: doc/mktexdepend.1] Error 1
make[2]: *** Waiting for unfinished jobs
a2x: ERROR: "xsltproc"  --stringparam callout.graphics 0 --stringparam 
navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 
 "/etc/asciidoc/docbook-xsl/manpage.xsl" 
"/build/mkdepend-0.0~svn45/doc/mkcomdepend.xml" returned non-zero exit status 5

make[2]: *** [Makelocal-manpages:7: doc/mkcomdepend.1] Error 1
make[2]: Leaving directory '/build/mkdepend-0.0~svn45'
dh_auto_build: error: make -j15 "INSTALL=install --strip-program=true" man 
returned exit code 2
make[1]: *** [debian/rules:8: override_dh_auto_build] Error 25


The Ubuntu patch seems to contain a fix.

Bug#983357: #983357: Netinst crashes xen domU when loading kernel

[Phillip Susi]

reopen 983357
thanks

I don't know what happened, but it is back to not working, even with the
install.amd/xen/ kernel.

Phillip Susi writes:

> The netinst image I had contained the -3 kernel.  I rebuit the image
> with the current -6 kernel and it worked.  I downloaded the latest
> weekly netinst iso and it already contains the -6 kernel, so it appears
> that this has been fixed in -4, -5, or -6.

Bug#987672: designate accesses the internet during the build

[Adrian Bunk]

Source: designate
Version: 1:11.0.0-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/designate.html

...
==
FAIL: designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify
designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify
--
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/mock.py", line 1337, in patched
return func(*newargs, **newkeywargs)
  File "/build/designate-11.0.0/designate/tests/unit/mdns/test_handler.py", 
line 62, in test_notify
self.assertEqual(dns.rcode.NOERROR, tuple(response)[0].rcode())
  File "/build/designate-11.0.0/designate/mdns/handler.py", line 149, in 
_handle_notify
resolver = dns.resolver.Resolver()
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 695, in __init__
self.read_resolv_conf(filename)
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 781, in 
read_resolv_conf
raise NoResolverConfiguration
dns.resolver.NoResolverConfiguration: Resolver configuration could not be read 
or specified no nameservers.


==
FAIL: 
designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify_same_serial
designate.tests.unit.mdns.test_handler.MdnsHandleTest.test_notify_same_serial
--
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/mock.py", line 1337, in patched
return func(*newargs, **newkeywargs)
  File "/build/designate-11.0.0/designate/tests/unit/mdns/test_handler.py", 
line 90, in test_notify_same_serial
self.assertEqual(dns.rcode.NOERROR, tuple(response)[0].rcode())
  File "/build/designate-11.0.0/designate/mdns/handler.py", line 149, in 
_handle_notify
resolver = dns.resolver.Resolver()
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 695, in __init__
self.read_resolv_conf(filename)
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 781, in 
read_resolv_conf
raise NoResolverConfiguration
dns.resolver.NoResolverConfiguration: Resolver configuration could not be read 
or specified no nameservers.


==
FAIL: 
designate.tests.unit.agent.backends.test_bind9.Bind9AgentBackendTestCase.test_find_zone_serial
designate.tests.unit.agent.backends.test_bind9.Bind9AgentBackendTestCase.test_find_zone_serial
--
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/mock.py", line 1337, in patched
return func(*newargs, **newkeywargs)
  File 
"/build/designate-11.0.0/designate/tests/unit/agent/backends/test_bind9.py", 
line 43, in test_find_zone_serial
self.assertIsNotNone(self.backend.find_zone_serial('example.org.'))
  File "/build/designate-11.0.0/designate/backend/agent_backend/impl_bind9.py", 
line 42, in find_zone_serial
resolver = dns.resolver.Resolver()
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 695, in __init__
self.read_resolv_conf(filename)
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 781, in 
read_resolv_conf
raise NoResolverConfiguration
dns.resolver.NoResolverConfiguration: Resolver configuration could not be read 
or specified no nameservers.


==
FAIL: 
designate.tests.unit.agent.backends.test_bind9.Bind9AgentBackendTestCase.test_find_zone_serial_query_raises
designate.tests.unit.agent.backends.test_bind9.Bind9AgentBackendTestCase.test_find_zone_serial_query_raises
--
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/mock.py", line 1337, in patched
return func(*newargs, **newkeywargs)
  File 
"/build/designate-11.0.0/designate/tests/unit/agent/backends/test_bind9.py", 
line 48, in test_find_zone_serial_query_raises
self.assertIsNone(self.backend.find_zone_serial('example.org.'))
  File "/build/designate-11.0.0/designate/backend/agent_backend/impl_bind9.py", 
line 42, in find_zone_serial
resolver = dns.resolver.Resolver()
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 695, in __init__
self.read_resolv_conf(filename)
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 781, in 
read_resolv_conf
raise NoResolverConfiguration
dns.resolver.NoResolverConfiguration: Resolver configuration could not be read 
or specified no nameservers.


--
Ran 697 tests in 2341.967s

FAILED 

Bug#987320: dracut: Version is not included in --version, --help or initramfs runtime

[Scott Moser]

I'm not sure if its 100% OK to do it, but what we do in cloud-init
similarly is is just write the file in debian/rules, and reference
DEB_VERSION.  That way you even get the packaging number which could
be helpful.

https://github.com/canonical/cloud-init/blob/ubuntu/devel/debian/rules

On Tue, Apr 27, 2021 at 5:39 AM Thomas Lange  wrote:
>
> I can confirm this bug.
>
> I guess the dracut version is created during the build of the package
> extracted from some git tags if avalable. Since I have to do source
> only upload to Debian, the git information is missing and so
> the version information is empty
>
> # cat /usr/lib/dracut/dracut-version.sh
> DRACUT_VERSION=
>
> I'll try to work around this in the next version.
>
> --
> viele Grüße Thomas

Bug#987671: gnome-disk-utility: User could possibly erase/format the hard disk without giving any password

[Pascal]

Package: gnome-disk-utility
Version: 3.38.2-1
Severity: normal to critical
Tags: newcomer
X-Debbugs-Cc: pascal.mart...@gmx.fr

Dear Maintainer,

Problem: Very DANGEROUS BUG in gnome-disk-utility : USER COULD POSSIBLY
DELETE THE HARD DISK BY MISTAKE WITHOUT GIVING ANY PASSWORD.

Hi,

I have discovered a very dangerous bug in gnome-disk-utility.
I am now on debian 11 bullseye testing and that bug was already present on
debian 10 buster stable and probably before too.

Usage process :
- We use gnome-disk-utility (graphical interface) and we want to copy an
ISO image on a USB stick.
- We insert our USB stick, we click on USB on the left of the gnome-disk-
utility window.
- We then choose the "Restore Disk Image..." (translation of the french
"Restaurer l'image disque...".
- When we have chosen the ISO file to put on the USB stick, the software
comes with a window that says "Begin restoration..." (translation of the french
"Demarrer la restauration...".
- We click on "Demarrer la restauration" and then another window says
"Cancel/Restore" (french : "Annuler/Restaurer").
- We click on "Restore" (french "Restaurer") and the software asks us for
necessary authentification (password) (french "Authentification necessaire").

BUG :
At that point, EVEN IF WE CLICK "CANCEL" (french "ANNULER"), THE USB STICK
IS ERASED, it is formatted anyway.
And a big concern is : What would have happened if, by mistake we had
clicked on the hard disk (HDD) instead of the USB stick as a destination for
our ISO image ?? It would certainly have been erased too, without even having
given any password !! A child or inattentive, tired person could erase the hard
disk that way.
I tested that several times with a USB stic), but having just one computer,
I couldn't test that bug with the Hard Disk. And I don't know if there is a
protection for preventing the user to select the Hard Disk instead of a USB
stick.

Cordially,
Pascal.

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

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

Versions of packages gnome-disk-utility depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-11
ii  libcairo21.16.0-5
ii  libcanberra-gtk3-0   0.30-7
ii  libdvdread8  6.1.1-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-3
ii  liblzma5 5.2.5-2
ii  libnotify4   0.7.9-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpwquality11.4.4-1
ii  libsecret-1-00.20.4-2
ii  libsystemd0  247.3-3
ii  libudisks2-0 2.9.2-1
ii  udisks2  2.9.2-1

gnome-disk-utility recommends no packages.

gnome-disk-utility suggests no packages.

Bug#987670: jami: Fails to start on Wayland (also with XWayland available)

[Gard Spreemann]

Package: jami
X-Debbugs-Cc: g...@nonempty.org
Version: 20210104.4.dda80df~ds1-1
Severity: normal

Dear Maintainer,

jami-gnome fails to start under Wayland, even when XWayland is
available and other GTK applications run fine. Trying to start it
results in

 $ jami-gnome 
 ** Message: 15:59:46.531: Jami GNOME client version: 
f6d50ba8bd027d9d02964f0954b40275c472267b
 ** Message: 15:59:46.531: git ref: unknown
 
 (jami-gnome:88955): Clutter-Gtk-ERROR **: 15:59:46.535: *** Unsupported 
backend.
 zsh: trace trap  jami-gnome

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

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

Versions of packages jami depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
pn  jami-daemon  
ii  libayatana-appindicator3-1   0.5.5-2
ii  libc62.31-11
ii  libcairo21.16.0-5
pn  libcanberra-gtk3-0   
ii  libcanberra0 0.30-7
pn  libclutter-1.0-0 
pn  libclutter-gtk-1.0-0 
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-3
ii  libnm0   1.30.0-2
ii  libnotify4   0.7.9-3
ii  libpango-1.0-0   1.46.2-3
ii  libqrencode4 4.1.1-1
ii  libqt5core5a 5.15.2+dfsg-5
ii  libqt5dbus5  5.15.2+dfsg-5
ii  libqt5gui5   5.15.2+dfsg-5
ii  libqt5sql5   5.15.2+dfsg-5
ii  libqt5sql5-sqlite5.15.2+dfsg-5
ii  libstdc++6   10.2.1-6
ii  libwebkit2gtk-4.0-37 2.30.6-1
ii  libx11-6 2:1.7.0-2

jami recommends no packages.

jami suggests no packages.


signature.asc
Description: PGP signature

Bug#986623: tuxmath: Segfaults on startup

[Holger Levsen]

control: severity -1 serious
# justification: segfault on startup breaks the whole application...
thanks

Hi Yvan and Bernhard,

thanks for the bugreport and the patch, I'll try to get this fixed in
unstable ASAP, however I'd appreciate NMUs or similar direct help, like
git commits.

(Also btw, upstream needs help too. If you're interested...)


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

Bug#987448: webkit2gtk regression: liferea: CSS for the posts is broken

[Alberto Garcia]

On Sat, Apr 24, 2021 at 09:52:51AM +0800, Paul Wise wrote:
> The recent upgrade to webkit2gtk 2.32.0-2 broke the CSS that the
> liferea RSS reader uses to style the HTML it injects for post
> metadata.

So it seems that this is a problem in Liferea after all.

webkit2gtk is covered by security support and version 2.32 will
eventually make it into bullseye, so I guess we have to apply this
liferea fix there as well?

Berto

Bug#987669: kpartx: bashism in /bin/sh script (kpartx_id)

[Julien Cristau]

Package: kpartx
Version: 0.8.5-1
Severity: important

Apr 27 13:44:47 ubc-enc2bl10/ubc-enc2bl10 systemd-udevd[50553]: 'kpartx_id 254 
29 mpath-3600c0ff00027786c559a785d0100'(err) '/lib/udev/kpartx_id: 96: 
/lib/udev/kpartx_id: [[: not found'

/lib/udev/kpartx_id has a /bin/sh shebang, [[ is a bashism, so should
probably be replaced with the standard "test -n".

Cheers,
Julien

Bug#920667:

[Ronald Allen]

Bug#987331: ruby-mysql2: flaky autopkgtest

[duck]

Version: 0.5.3-3

I forgot to close it in the changelog, sorry.

--
Marc Dequènes

Bug#741450: iwlwifi: wifi failure to work after suspend with 7260AC

[duck]

Quack,

On 2021-04-25 06:36, Salvatore Bonaccorso wrote:


Is this still reproducible on current kernels?


I changed hardware last December and it's not the same chipset anymore 
thus I cannot tell, sorry.

The new one is also using iwlwifi though:
  00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi 
[Wireless-AC] (rev 30)
and I have not experienced any problem with it so far, but due to 
covid-19 I'm not using WIFI very often…


Regards.
\_o<

--
Marc Dequènes

Bug#987239: unblock: glance/21.0.0-2

[Thomas Goirand]

On 4/27/21 11:53 AM, Sebastian Ramacher wrote:
> Control: tags -1 + confirmed moreinfo
> 
> On 2021-04-26 21:37:56 +0200, Thomas Goirand wrote:
>> On 4/26/21 4:01 PM, Sebastian Ramacher wrote:
 The changelog goes like this:

   1* Add variables: DEB_BUILD_OPTIONS: nocheck DEB_BUILD_PROFILES: nocheck 
 in
 debian/salsa-ci.yml.
   2* Do not delete /etc/glance/rootwrap.conf, owned by 
 python3-glance-store.
 (Closes: #987193).
   3* mv /etc/glance/policy.json /etc/glance/disabled.policy.json.old 
 instead of
 deleting /etc/glance/policy.json.
   4* Tune glance-api-uwsgi.ini for performance.
>>>
>>> Regarding 3*: why isn't the old file not moved to the new location?
>>>
>>> Cheers
>>
>> I'm sorry, I'm too much into it, and forgot the main story.
>>
>> For a technical reason that would be long to explain, the old json
>> format is deprecated, and OpenStack users should stop using it as soon
>> as possible, otherwise, it may may create of issues. The new way of
>> doing things is to stop Json with every policy option declared, and
>> switch to a standard where everything commented-out in a yaml file,
>> describing what's in the python code as default.
>>
>> In Debian, we now generates a yaml file in
>> /etc/glance/policy.d/00_default-policy.yaml. I expect users to leave the
>> file as-is, and just add configuration fragments on the same folder,
>> rather than editing a unique policy.json like before.
>>
>> Therefore, the best thing we could do, was just move away .json format
>> API policy file, to make sure that it's not in use (because older
>> version of Glance may point to the old /etc/glance/policy.json). And
>> that's why I'm using such an explicit "disabled.policy.json.old" name.
>>
>> The thing is, deleting the old policy.json was a bad idea. Because
>> administrator may have edited that file to set various API policies in
>> previous releases of OpenStack. So best is to keep it, but renamed, and
>> tell the user to put what he edited as fragments in /etc/glance/policy.d
>> in yaml format only.
>>
>> Moving the policy.json in the policy.d is not a good idea either,
>> because it keeps the old JSON format, now deprecated by upstream, that
>> we explicitly require users to move away from.
>>
>> I hope it's more clear now.
> 
> I tried to find some documentation on that in the package and the
> releases notes, but I was unable to find any info on that. Please
> document that as users have to be aware of the steps they have to take.
> 
> Once that's done, please remove the moreinfo tag.
> 
> Cheers
> 

Hi,

I contributed this release note:
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/95

Is this enough to remove the moreinfo tag?

Cheers,

Thomas Goirand (zigo)

Bug#987668: [INTL:es] Spanish translation of the debconf template

[Camaleón]

Package: heat
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# heat po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the heat package.
# Camaleón , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: heat\n"
"Report-Msgid-Bugs-To: h...@packages.debian.org\n"
"POT-Creation-Date: 2019-12-22 23:06+0100\n"
"PO-Revision-Date: 2021-04-16 17:38+0200\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../heat-common.templates.in:1001
msgid "Configure Heat domain with debconf?"
msgstr "¿Desea configurar el dominio Heat con debconf?"

#. Type: boolean
#. Description
#: ../heat-common.templates.in:1001
msgid ""
"Heat domain must be configured to connect to Keystone. Specify this should "
"be configured through debconf."
msgstr ""
"Debe configurar el dominio Heat para que se conecte con Keystone. Indique si "
"debería configurarse a través de debconf."

#. Type: string
#. Description
#: ../heat-common.templates.in:2001
msgid "Heat domain administrator username:"
msgstr "Nombre del usuario administrador del dominio Heat:"

#. Type: string
#. Description
#: ../heat-common.templates.in:2001
msgid "Please enter the username of the Heat domain administrator."
msgstr ""
"Por favor, introduzca el nombre del usuario administrador del dominio Heat."

#. Type: password
#. Description
#: ../heat-common.templates.in:3001
msgid "Heat domain administrator password:"
msgstr "Contraseña del administrador del dominio Heat:"

#. Type: password
#. Description
#: ../heat-common.templates.in:3001
msgid "Please enter the password of the Heat domain administrator."
msgstr ""
"Por favor, introduzca la contraseña del administrador del dominio Heat."

#. Type: string
#. Description
#: ../heat-common.templates.in:4001
msgid "Heat domain:"
msgstr "Dominio Heat:"

#. Type: string
#. Description
#: ../heat-common.templates.in:4001
msgid "Please enter domain name which will be used as heat domain."
msgstr ""
"Por favor, introduzca el nombre de dominio que se utilizará como dominio Heat."

Bug#987667: [INTL:es] Spanish translation of the debconf template

[Camaleón]

Package: progress-linux
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# progress-linux po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the progress-linux package.
# Camaleón , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: progress-linux\n"
"Report-Msgid-Bugs-To: progress-li...@packages.debian.org\n"
"POT-Creation-Date: 2019-11-18 17:31+0100\n"
"PO-Revision-Date: 2021-04-16 17:45+0200\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: title
#. Description
#: ../progress-linux.templates:1001
msgid "Progress Linux: Setup"
msgstr "Progress Linux: Configuración"

#. Type: multiselect
#. Description
#: ../progress-linux.templates:2001
msgid "setup apt archives:"
msgstr "configurar archivos apt:"

#. Type: multiselect
#. Description
#: ../progress-linux.templates:2001
msgid "Please select the apt archives to setup."
msgstr "Por favor, indique los archivos apt que desea configurar."

#. Type: multiselect
#. Description
#: ../progress-linux.templates:3001
msgid "setup apt archive areas:"
msgstr "configurar áreas del archivo apt:"

#. Type: multiselect
#. Description
#: ../progress-linux.templates:3001
msgid "Please select the apt archive areas to setup."
msgstr "Por favor, indique las áreas del archivo apt que desea configurar."

#. Type: string
#. Description
#: ../progress-linux.templates:4001
msgid "enter apt mirror:"
msgstr "introduzca la réplica de apt:"

#. Type: string
#. Description
#: ../progress-linux.templates:4001
msgid "Please specify the mirror to download packages from."
msgstr "Por favor, indique la réplica desde donde descargar los paquetes."

#. Type: string
#. Description
#: ../progress-linux.templates:4001
msgid ""
"If unsure, leave empty which will use the default mirror (https://deb.;
"progress-linux.org/packages)."
msgstr ""
"Si no está seguro, puede dejarlo en blanco y se utilizará la réplica "
"predeterminada («https://deb.progress-linux.org/packages»)."

Bug#987666: [INTL:es] Spanish translation of the debconf template

[Camaleón]

Package: libcifpp
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# libcifpp po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the libcifpp package.
# Camaleón , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: libcifpp\n"
"Report-Msgid-Bugs-To: libci...@packages.debian.org\n"
"POT-Creation-Date: 2020-11-18 11:09+0100\n"
"PO-Revision-Date: 2021-04-16 17:27+0200\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../libcifpp1.templates:1001
msgid "Should mmcif_pdbx_v50 files be updated automatically?"
msgstr "¿Deberían actualizarse automáticamente los archivos de mmcif_pdbx_v50?"

#. Type: boolean
#. Description
#: ../libcifpp1.templates:1001
msgid ""
"The default mmcif_pdbx_v50.dic file may become out-of-date over time. Using "
"this option you can enable automatic weekly updating of this file."
msgstr ""
"Con el tiempo, el archivo predeterminado mmcif_pdbx_v50.dic puede quedar "
"obsoleto. Con esta opción, podrá activar la actualización automática semanal "
"de este archivo."

Bug#987664: [INTL:es] Spanish translation of the debconf template

[Camaleón]

Package: x2gothinclient
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# x2gothinclient po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the x2gothinclient package.
# Camaleón , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: x2gothinclient 1.5.0.0\n"
"Report-Msgid-Bugs-To: sub...@bugs.x2go.org\n"
"POT-Creation-Date: 2013-03-29 16:53+0100\n"
"PO-Revision-Date: 2021-04-16 17:18+0200\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Description
#: ../x2gothinclient-displaymanager.templates:1001
msgid "Default display manager:"
msgstr "Gestor de pantalla predeterminado:"

#. Type: select
#. Description
#: ../x2gothinclient-displaymanager.templates:1001
msgid ""
"On X2Go thin clients X2Go Client is sort of used as a display manager. For "
"this, X2Go Client gets started in TCE mode. The TCE acronym stands for thin "
"client environment. In TCE mode, X2Go Client manages the default display of "
"the X Window System."
msgstr ""
"En clientes ligeros X2Go, X2Go Client se utiliza en cierto modo como un gestor 
"
"de pantalla. Para ello, X2Go Client se inicia en modo TCE. El acrónimo de TCE "
"significa «Thin Client Environment» (Entorno de Cliente Ligero). En este modo, 
"
"X2Go Client gestiona la pantalla predeterminada del Sistema de Ventanas X."

#. Type: select
#. Description
#: ../x2gothinclient-displaymanager.templates:1001
msgid ""
"Generally, a display manager is a program that provides graphical login "
"capabilities for the X Window System. Other display managers for example are "
"GDM, KDM, etc. Login is--in most cases--granted to the local system."
msgstr ""
"Por lo general, el gestor de pantalla es un programa que proporciona un inicio 
"
"de sesión gráfico para el Sistema de Ventanas X. Otros gestores de pantalla 
son, "
"p. ej., GDM, KDM, etc. En la mayoría de los casos, permite iniciar una sesión "
"en el equipo local."

#. Type: select
#. Description
#: ../x2gothinclient-displaymanager.templates:1001
msgid ""
"However, X2Go Client in TCE mode does appear like a display manager, but it "
"will log you onto pre-defined X2Go sessions on remote servers."
msgstr ""
"Sin embargo, en el modo TCE X2Go Client parece un gestor de pantalla "
"convencional, pero le permitirá iniciar sesiones predefinidas de X2Go "
"en servidores remotos."

#. Type: select
#. Description
#: ../x2gothinclient-displaymanager.templates:1001
msgid ""
"As you are about to install X2Go Client in TCE mode on this machine and as "
"you already have other display managers installed on this machine, please "
"explicitly select which display manager is supposed to be the default for "
"your system."
msgstr ""
"Como va a instalar X2Go Client en modo TCE en este equipo, donde ya tiene "
"instalados otros gestores de pantalla, seleccione expresamente cuál debe ser "
"el gestor de pantalla predeterminado en este equipo."

Bug#987665: unblock: libcxl/1.7-2

[Frédéric Bonnard]

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

Please unblock package libcxl

The version in testing has bug #987636 which is a FTBFS because of a regression 
in
make 4.3 .
Upstream libcxl has implemented a workaround which I pulled as well a
cosmetic patch for debian/rules that was pushed previously in the git
tree by another Debian Developer.

The build now works fine :
https://buildd.debian.org/status/package.php?p=libcxl

See attached the debdiff for the changes.

unblock libcxl/1.7-2


Thanks!
Regards

F. 

diff -Nru libcxl-1.7/debian/changelog libcxl-1.7/debian/changelog
--- libcxl-1.7/debian/changelog 2018-05-17 16:31:53.0 +0200
+++ libcxl-1.7/debian/changelog 2021-04-27 13:25:03.0 +0200
@@ -1,3 +1,13 @@
+libcxl (1.7-2) unstable; urgency=medium
+
+  [ Ondřej Nový ]
+  * d/rules: Remove trailing whitespaces
+
+  [ Frédéric Bonnard ]
+  * Import upstream fix for make 4.3 use (Closes: #987636)
+
+ -- Frédéric Bonnard   Tue, 27 Apr 2021 13:25:03 +0200
+
 libcxl (1.7-1) unstable; urgency=medium
 
   * Remove unused d/patches effectively
diff -Nru 
libcxl-1.7/debian/patches/0001-Import-upstream-fix-Closes-987636.patch 
libcxl-1.7/debian/patches/0001-Import-upstream-fix-Closes-987636.patch
--- libcxl-1.7/debian/patches/0001-Import-upstream-fix-Closes-987636.patch  
1970-01-01 01:00:00.0 +0100
+++ libcxl-1.7/debian/patches/0001-Import-upstream-fix-Closes-987636.patch  
2021-04-27 13:25:03.0 +0200
@@ -0,0 +1,36 @@
+From: =?utf-8?b?RnLDqWTDqXJpYyBCb25uYXJk?= 
+Date: Tue, 27 Apr 2021 13:22:44 +0200
+Subject: Import upstream fix (Closes: #987636)
+
+https://github.com/ibm-capi/libcxl/commit/f10f957771a1ea7e6f52a48467bcf7ebf3cb1669
+---
+ Makefile | 13 ++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index b0626e8..8a07bac 100644
+--- a/Makefile
 b/Makefile
+@@ -18,12 +18,19 @@ all: check_cxl_header $(LIBSONAME) libcxl.so libcxl.a
+ HAS_WGET = $(shell /bin/which wget > /dev/null 2>&1 && echo y || echo n)
+ HAS_CURL = $(shell /bin/which curl > /dev/null 2>&1 && echo y || echo n)
+ 
+-# Update this to test a single feature from the most recent header we require:
+-CHECK_CXL_HEADER_IS_UP_TO_DATE = $(shell /bin/echo -e \\\#include $(1)\\\nint 
i = CXL_START_WORK_TID\; | \
++
++# Update this to test a single feature from the most recent header we require.
++#
++# Note that a backward-incompatible change in make 4.3 modified the
++# handling \# in a function invocation, so we define the test code in
++# a separate variable to work around it and keep consistent behavior
++# across all versions of make
++TEST_CODE = '\#include \nint i = CXL_START_WORK_TID;'
++CHECK_OCXL_HEADER_IS_UP_TO_DATE = $(shell /bin/echo -e $(TEST_CODE) | \
+  $(CC) $(CFLAGS) -Werror -x c -S -o /dev/null - >/dev/null 
2>&1 && echo y || echo n)
+ 
+ check_cxl_header:
+-ifeq ($(call CHECK_CXL_HEADER_IS_UP_TO_DATE,""),n)
++ifeq (${CHECK_CXL_HEADER_IS_UP_TO_DATE},n)
+   mkdir -p include/misc
+ ifeq (${HAS_WGET},y)
+   $(call Q,WGET include/misc/cxl.h, wget -O include/misc/cxl.h -q 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/include/uapi/misc/cxl.h)
diff -Nru libcxl-1.7/debian/patches/series libcxl-1.7/debian/patches/series
--- libcxl-1.7/debian/patches/series1970-01-01 01:00:00.0 +0100
+++ libcxl-1.7/debian/patches/series2021-04-27 13:25:03.0 +0200
@@ -0,0 +1 @@
+0001-Import-upstream-fix-Closes-987636.patch
diff -Nru libcxl-1.7/debian/rules libcxl-1.7/debian/rules
--- libcxl-1.7/debian/rules 2018-05-16 18:35:20.0 +0200
+++ libcxl-1.7/debian/rules 2021-04-27 13:25:03.0 +0200
@@ -5,7 +5,7 @@
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 %:
-   dh $@ 
+   dh $@
 
 override_dh_makeshlibs:
dh_makeshlibs -- -c4


signature.asc
Description: PGP signature

Bug#987663: [INTL:es] Spanish translation of the debconf template

[Camaleón]

Package: pwman3
Severity: wishlist
Tags: patch l10n

Hello,

You can find enclosed the Spanish translation template to be uploaded
with the latest package build.

Greetings,

-- 
Camaleón 
# pwman3 po-debconf translation to Spanish.
# Copyright (C) 2021
# This file is distributed under the same license as the pwman3 package.
# Camaleón , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: pwman3\n"
"Report-Msgid-Bugs-To: pwm...@packages.debian.org\n"
"POT-Creation-Date: 2020-01-07 08:39+\n"
"PO-Revision-Date: 2021-04-16 17:56+0200\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Description
#: ../templates:1001
msgid "Old database format detected"
msgstr "Se ha detectado un formato obsoleto de la base de datos"

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"It seems that you are trying to upgrade Pwman3 from version 0.5.x or older. "
"The database is not compatible with the new database format. Before "
"upgrading you need to export your database to a CSV with:"
msgstr ""
"Parece que está intentando actualizar Pwman3 desde la versión 0.5.x o "
"anterior. La base de datos no es compatible con el nuevo formato de base "
"de datos. Antes de actualizar, debe exportar su base de datos a un formato 
CSV, "
"con la orden:"

#. Type: select
#. Description
#: ../templates:1001
msgid "  pwman> export"
msgstr "  pwman> export"

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"That will create a CSV file located in $HOME/pwman-export.csv. Once "
"exported, you will have to rename your old database to keep a backup of it:"
msgstr ""
"Se creará un archivo CSV en «$HOME/pwman-export.csv». Una vez exportada, "
"tendrá que renombrar la base de datos antigua para mantener una copia de "
"seguridad, con la orden:"

#. Type: select
#. Description
#: ../templates:1001
msgid "  mv $HOME/pwman/pwman.db $HOME/pwman/pwman-old.db"
msgstr "  mv $HOME/pwman/pwman.db $HOME/pwman/pwman-old.db"

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"Then you can restart the package upgrade. Once the upgrade will be finished, "
"you will be able to import the CSV file previously generated:"
msgstr ""
"Entonces podrá reiniciar la actualización del paquete. Cuando termine la "
"actualización, podrá importar el archivo CSV creado anteriormente, con la "
"orden:"

#. Type: select
#. Description
#: ../templates:1001
msgid "  pwman3 -i $HOME/pwman-export.csv \\;"
msgstr "  pwman3 -i $HOME/pwman-export.csv \\;"

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"Don't forget to remove the CSV file when the import succeeded (the passwords "
"are stored in clear text in this file)."
msgstr ""
"No se olvide de eliminar el archivo CSV cuando la importación termine "
"correctamente (en este archivo, las contraseñas se almacenan en texto claro)."

Bug#597296: ooo-thumbnailer: Problem with space character

[Rpnpif]

This issue is still present (buster and sid).

Please fix it.

Regards.

Rpnpif



OpenPGP_0x9D37FFC5566FED61.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#987662: unblock: shibboleth-sp/3.2.2+dfsg1-1

[Ferenc Wágner]

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

Please unblock package shibboleth-sp

Dear Release Team,

The recent Shibboleth SP advisory
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987608) was fixed
upstream by a new patch level release: 3.2.2.  The release contains
nothing but two crash fixes: one affecting test setups only and the
remote unauthenticaed DoS fix referenced by the above advisory.
However, upstream upgraded to Autoconf 2.71 meanwhile, so the debdiff is
too big to fit in this bug report.  Here's the diffstat instead:

$ debdiff shibboleth-sp_3.2.1+dfsg1-1.dsc shibboleth-sp_3.2.2+dfsg1-1.dsc | 
diffstat 
 Makefile.in|3 
 aclocal.m4 |4 
 adfs/Makefile.in   |1 
 apache/Makefile.in |1 
 build-aux/compile  |6 
 build-aux/config.guess |  620 
 build-aux/config.sub   | 2585 +-
 build-aux/depcomp  |2 
 build-aux/install-sh   |  161 
 build-aux/missing  |2 
 config.h.in|   12 
 config_win32.h |6 
 configs/Makefile.in|1 
 configure  | 9133 
+-
 configure.ac   |2 
 debian/changelog   |8 
 debian/patches/Clean-up-cxxtest-configuration.patch|2 
 debian/patches/Use-runstatedir-from-future-Autoconf-2.70.patch |2 
 doc/Makefile.in|1 
 fastcgi/Makefile.in|1 
 m4/libtool.m4  |   13 
 memcache-store/Makefile.in |1 
 nsapi_shib/Makefile.in |1 
 odbc-store/Makefile.in |1 
 plugins/Makefile.in|1 
 schemas/Makefile.in|1 
 selinux/Makefile.in|1 
 shibboleth.spec|9 
 shibboleth.spec.in |7 
 shibd/Makefile.in  |1 
 shibsp/Makefile.am |4 
 shibsp/Makefile.in |5 
 shibsp/handler/impl/SAML2Logout.cpp|9 
 shibsp/handler/impl/SAML2NameIDMgmt.cpp|   10 
 shibsp/impl/StorageServiceSessionCache.cpp |8 
 shibsp/shibsp.rc   |4 
 shibsp/version.h   |2 
 unittests/Makefile.in  |1 
 util/Makefile.in   |1 
 39 files changed, 7044 insertions(+), 5589 deletions(-)

On the other hand, the shibboleth-sp package builds with Debhelper
compat level 12, which includes autoreconf, so the bulk of this is
inconsequential.  The actual code difference is pretty small:

$ git diff --stat 3.2.1 3.2.2
 config_win32.h |  6 +++---
 configure.ac   |  2 +-
 shibboleth.spec.in |  7 +--
 shibsp/Makefile.am |  4 ++--
 shibsp/handler/impl/SAML2Logout.cpp|  9 +
 shibsp/handler/impl/SAML2NameIDMgmt.cpp| 10 ++
 shibsp/impl/StorageServiceSessionCache.cpp |  8 +++-
 shibsp/shibsp.rc   |  4 ++--
 shibsp/version.h   |  2 +-
 util/resourceCommon.rci|  6 +++---
 10 files changed, 35 insertions(+), 23 deletions(-)

So here is the debdiff with the Autocruft omitted:

diff -Nru shibboleth-sp-3.2.1+dfsg1/configure.ac 
shibboleth-sp-3.2.2+dfsg1/configure.ac
--- shibboleth-sp-3.2.1+dfsg1/configure.ac  2021-03-16 14:33:31.0 
+0100
+++ shibboleth-sp-3.2.2+dfsg1/configure.ac  2021-04-23 00:18:15.0 
+0200
@@ -1,5 +1,5 @@
 AC_PREREQ([2.50])
-AC_INIT([shibboleth],[3.2.1],[https://issues.shibboleth.net/],[shibboleth-sp])
+AC_INIT([shibboleth],[3.2.2],[https://issues.shibboleth.net/],[shibboleth-sp])
 AC_CONFIG_SRCDIR(shibsp)
 AC_CONFIG_AUX_DIR(build-aux)
 

Bug#987661: python2.7: please add more Breaks against unversioned python packages

[Andreas Beckmann]

Source: python2.7
Version: 2.7.18-6
Severity: important
Tags: patch

Hi,

the previously added Breaks (against python-minimal and libpython-stdlib)
fixed many upgrade paths, but against unversioned 'python' there is only a
transitive conflict (due to unsatifiable strict versioned dependencies)
and that does not work out for all upgrade paths. So let's add
'python (<< 2.7.18)' to the list of Breaks to catch these cases as well.

Example: rambo-k

Bad (incomplete) upgrade:

  Starting 2 pkgProblemResolver with broken count: 6
  Investigating (0) python2.7:amd64 < 2.7.16-2+deb10u1 -> 2.7.18-6 @ii umU Ib >
  Broken python2.7:amd64 Breaks on libpython-stdlib:amd64 < 2.7.16-1 @ii mK Ib 
> (< 2.7.18)
Considering libpython-stdlib:amd64 3 as a solution to python2.7:amd64 14
Added libpython-stdlib:amd64 to the remove list
  Broken python2.7:amd64 Breaks on python-minimal:amd64 < 2.7.16-1 @ii mK Ib > 
(< 2.7.18)
Considering python-minimal:amd64 3 as a solution to python2.7:amd64 14
Added python-minimal:amd64 to the remove list
Fixing python2.7:amd64 via remove of libpython-stdlib:amd64
Fixing python2.7:amd64 via remove of python-minimal:amd64
  Investigating (0) python:amd64 < 2.7.16-1 @ii mK Ib >
  Broken python:amd64 PreDepends on python-minimal:amd64 < 2.7.16-1 @ii mR > (= 
2.7.16-1)
Considering python-minimal:amd64 3 as a solution to python:amd64 11
Added python-minimal:amd64 to the remove list
  Broken python:amd64 Depends on libpython-stdlib:amd64 < 2.7.16-1 @ii mR > (= 
2.7.16-1)
Considering libpython-stdlib:amd64 3 as a solution to python:amd64 11
Added libpython-stdlib:amd64 to the remove list
  Broken python:amd64 Depends on python2:amd64 < 2.7.16-1 -> 2.7.18-2 @ii umU > 
(= 2.7.16-1)
Considering python2:amd64 9 as a solution to python:amd64 11
Added python2:amd64 to the remove list
Fixing python:amd64 via keep of python-minimal:amd64
Fixing python:amd64 via keep of libpython-stdlib:amd64
Fixing python:amd64 via keep of python2:amd64
   Try to Re-Instate (0) python2:amd64
  Re-Instated python2:amd64 (6 vs 6)
  Investigating (0) libpython2.7-minimal:amd64 < 2.7.16-2+deb10u1 -> 2.7.18-6 
@ii umU Ib >
  Broken libpython2.7-minimal:amd64 Breaks on libpython-stdlib:amd64 < 2.7.16-1 
@ii mK Ib > (< 2.7.18)
Considering libpython-stdlib:amd64 3 as a solution to 
libpython2.7-minimal:amd64 9
Added libpython-stdlib:amd64 to the remove list
  Broken libpython2.7-minimal:amd64 Breaks on python-minimal:amd64 < 2.7.16-1 
@ii mK Ib > (< 2.7.18)
Considering python-minimal:amd64 3 as a solution to 
libpython2.7-minimal:amd64 9
Added python-minimal:amd64 to the remove list
Fixing libpython2.7-minimal:amd64 via remove of libpython-stdlib:amd64
Fixing libpython2.7-minimal:amd64 via remove of python-minimal:amd64
  Investigating (1) python:amd64 < 2.7.16-1 @ii mK Ib >
  Broken python:amd64 PreDepends on python-minimal:amd64 < 2.7.16-1 @ii mR > (= 
2.7.16-1)
Considering python-minimal:amd64 3 as a solution to python:amd64 11
Added python-minimal:amd64 to the remove list
  Broken python:amd64 Depends on libpython-stdlib:amd64 < 2.7.16-1 @ii mR > (= 
2.7.16-1)
Considering libpython-stdlib:amd64 3 as a solution to python:amd64 11
Added libpython-stdlib:amd64 to the remove list
  Broken python:amd64 Depends on python2:amd64 < 2.7.16-1 -> 2.7.18-2 @ii umU > 
(= 2.7.16-1)
Considering python2:amd64 9 as a solution to python:amd64 11
Added python2:amd64 to the remove list
Fixing python:amd64 via keep of python-minimal:amd64
Fixing python:amd64 via keep of libpython-stdlib:amd64
Fixing python:amd64 via keep of python2:amd64
  Investigating (1) python2:amd64 < 2.7.16-1 | 2.7.18-2 @ii umH Ib >
  Broken python2:amd64 PreDepends on python2-minimal:amd64 < 2.7.16-1 -> 
2.7.18-2 @ii umU > (= 2.7.16-1)
Considering python2-minimal:amd64 2 as a solution to python2:amd64 9
Added python2-minimal:amd64 to the remove list
  Broken python2:amd64 Depends on libpython2-stdlib:amd64 < 2.7.16-1 -> 
2.7.18-2 @ii umU > (= 2.7.16-1)
Considering libpython2-stdlib:amd64 2 as a solution to python2:amd64 9
Added libpython2-stdlib:amd64 to the remove list
Fixing python2:amd64 via keep of python2-minimal:amd64
Fixing python2:amd64 via keep of libpython2-stdlib:amd64
  Investigating (1) libpython2.7-minimal:amd64 < 2.7.16-2+deb10u1 -> 2.7.18-6 
@ii umU Ib >
  Broken libpython2.7-minimal:amd64 Breaks on libpython-stdlib:amd64 < 2.7.16-1 
@ii mK > (< 2.7.18)
Considering libpython-stdlib:amd64 3 as a solution to 
libpython2.7-minimal:amd64 9
Added libpython-stdlib:amd64 to the remove list
  Broken libpython2.7-minimal:amd64 Breaks on python-minimal:amd64 < 2.7.16-1 
@ii mK > (< 2.7.18)
Considering python-minimal:amd64 3 as a solution to 
libpython2.7-minimal:amd64 9
Added python-minimal:amd64 to the remove list
Fixing libpython2.7-minimal:amd64 via remove of libpython-stdlib:amd64
Fixing 

Bug#987660: gnupg: man page claims gpg always requires a keyring, but --no-keyring implies it does not

[Ansgar]

Package: gnupg
Version: 2.2.27-1
Severity: normal

The man page for gpg(1) states for `--no-default-keyring`:

| Note that GnuPG will not operate without any keyrings, so if you use
| this option and do not provide alternate keyrings via --keyring or
| --secret-keyring, then GnuPG will still use the default public or
| secret keyrings.

But the next option described is `--no-keyring`:

| Do not use any keyring at all.  This overrides the default and all
| options which specify keyrings.

This seems to be a contradiction to the claim that GnuPG will not
operate without any keyring from the `--no-default-keyring` option.

Ansgar

Bug#987659: release-notes: redmine not available, please wait backports

[duck]

Package: release-notes


Quack,

Sorry for the late request, I entirely forgot. I also hoped it would not 
be necessary in case 4.2 could work with a few patches but I just 
finished packaging it and that's not working.


If not too late, here is the message I wish to convey:
  Redmine is unfortunately late migrating over to newer Rails version 
despite end of upstream support soon (currently only severe security 
fixes). In Debian we had to update Rails for other applications thus 
Redmine is not provided in bullseye. We are following upstream closely 
and will be releasing a version via backports as soon as it is released 
and we have working packages. Until then you may wait before upgrading, 
or use a VM or container running Buster to isolate this specific 
application.


Regards.
\_o<

--
Marc Dequènes

Bug#986385: sympa: Package `wwsympa.service`

[Stefan Hornburg (Racke)]

On 4/4/21 11:30 PM, Paul Menzel wrote:
> Package: sympa
> Version: 6.2.60~dfsg-4
> Severity: normal
> 
> 
> Dear Debian folks,
> 
> 
> Thank you for maintaining the package *sympa*.
> 
> It’d be great, if you packaged the systemd service unit `wwsympa.service` so 
> the template [1] does not need to be adapted.
> 

Hello Paul,

added in 
https://salsa.debian.org/sympa-team/sympa/-/commit/067161653738894661404556f61a15d164d2ea8b,
 albeit as native
systemd service.

Regards
  Racke

> ```
> [Unit]
> Description=WWSympa - Web interface for Sympa mailing list manager
> After=syslog.target sympa.service
> 
> [Service]
> Type=forking
> PIDFile=--piddir--/wwsympa.pid
> ExecStart=/usr/bin/spawn-fcgi -F $FCGI_CHILDREN \
>    -P --piddir--/wwsympa.pid \
>    -s --piddir--/wwsympa.socket \
>    -u $FCGI_USER -g $FCGI_GROUP $FCGI_OPTS -- \
>    --execcgidir--/wwsympa.fcgi
> Environment="FCGI_CHILDREN=5"
> Environment="FCGI_USER=--USER--"
> Environment="FCGI_GROUP=--GROUP--"
> Environment="FCGI_OPTS=-M 0600 -U nginx"
> EnvironmentFile=-/etc/sysconfig/sympa
> Restart=always
> 
> [Install]
> WantedBy=multi-user.target
> ```
> 
> 
> Kind regards,
> 
> Paul
> 
> 
> [1]:
> https://github.com/sympa-community/sympa/blob/3f44b653a3c174a29920768e5bab530e76d245f4/src/etc/script/wwsympa.servicein
> 


-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.



OpenPGP_signature
Description: OpenPGP digital signature

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

[Emmanuel Bourg]

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

Please unblock package openjdk-11-jre-dcevm

openjdk-11-jre-dcevm/11.0.10+1-1 in testing is currently unusable, it
throws an error because the version isn't aligned with the openjdk-11
package (#984725).

This update is compatible with both versions of openjdk-11 in testing
(11.0.11+4-1) and unstable (11.0.11+9-1).

Thank you,

Emmanuel Bourg



unblock openjdk-11-jre-dcevm/11.0.11+9-1

Bug#987656: flent-gui fails to start (ModuleNotFoundError: No module named 'qtpy')

[Jaycee Santos]

Package: flent
Version: 2.0.0-2
Severity: important
X-Debbugs-Cc: jlsan...@protonmail.com

flent-gui fails to start. I expected a window to appear but nothing happens.

Running 'flent --gui --verbose --debug-error' outputs the following:

Started Flent 2.0.0 using Python 3.9.2.
ERROR: Unable to find a usable Qt version.
Traceback (most recent call last):
  File "/usr/share/flent/flent/gui.py", line 68, in 
import qtpy
ModuleNotFoundError: No module named 'qtpy'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/flent/flent/__init__.py", line 55, in run_flent
from flent.gui import run_gui
  File "/usr/share/flent/flent/gui.py", line 93, in 
raise RuntimeError("Unable to find a usable Qt version.")
RuntimeError: Unable to find a usable Qt version.


After doing a quick search for 'qtpy', I came across the python3-qtpy
package and installed it. flent-gui now starts as expected.



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

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

Versions of packages flent depends on:
ii  libjs-sphinxdoc  3.4.3-2
ii  python3  3.9.2-3

Versions of packages flent recommends:
ii  iputils-ping [ping]  3:20210202-1
ii  irtt 0.9.0-2+b14
ii  python3-matplotlib   3.3.4-1
ii  python3-pyqt55.15.2+dfsg-3

Versions of packages flent suggests:
ii  netperf  2.7.0-0.1

-- no debconf information

Bug#987656: [Pkg-netmeasure-discuss] Bug#987656: flent-gui fails to start (ModuleNotFoundError: No module named 'qtpy')

[Toke Høiland-Jørgensen]

Jaycee Santos  writes:

> Package: flent
> Version: 2.0.0-2
> Severity: important
> X-Debbugs-Cc: jlsan...@protonmail.com
>
> flent-gui fails to start. I expected a window to appear but nothing happens.
>
> Running 'flent --gui --verbose --debug-error' outputs the following:
>
> Started Flent 2.0.0 using Python 3.9.2.
> ERROR: Unable to find a usable Qt version.
> Traceback (most recent call last):
>   File "/usr/share/flent/flent/gui.py", line 68, in 
> import qtpy
> ModuleNotFoundError: No module named 'qtpy'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/usr/share/flent/flent/__init__.py", line 55, in run_flent
> from flent.gui import run_gui
>   File "/usr/share/flent/flent/gui.py", line 93, in 
> raise RuntimeError("Unable to find a usable Qt version.")
> RuntimeError: Unable to find a usable Qt version.
>
>
> After doing a quick search for 'qtpy', I came across the python3-qtpy
> package and installed it. flent-gui now starts as expected.
>
>
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages flent depends on:
> ii  libjs-sphinxdoc  3.4.3-2
> ii  python3  3.9.2-3
>
> Versions of packages flent recommends:
> ii  iputils-ping [ping]  3:20210202-1
> ii  irtt 0.9.0-2+b14
> ii  python3-matplotlib   3.3.4-1
> ii  python3-pyqt55.15.2+dfsg-3

Ah, looks like the "Recommends" needs to be updated to python3-qtpy
instead of python3-pyqt5; will fix and push an update... Thank you for
the report!

-Toke

Bug#987299: unblock: gstreamer1.0/1.18.4-1

[Laurent Bigonville]

Hello,

On Wed, 21 Apr 2021 09:31:12 +0300 =?utf-8?q?Sebastian_Dr=C3=B6ge?= 


 wrote:

> Please unblock package gstreamer1.0
>
> GStreamer 1.18.4 is a bugfix release on top of 1.18.3, which is 
currently in

> testing/unstable. 1.18.4 is currently waiting in experimental until the
> unblock request is accepted.
>
> This does not affect only the gstreamer1.0 source package but also:
> - gst-plugins-base1.0
> - gst-plugins-good1.0
> - gst-plugins-bad1.0

Yesterday, I uploaded src:gst-plugins-bad1.0 1.18.4-3 without knowing 
that the unblock was already requested.


My changes (see in the attached patch) are not impacting the release 
architectures, they are fixing issues with different ports.


Are my changes a problem for the release team? Should they be reverted?

Sorry for the disturbance,

Kind regards,

Laurent Bigonville

diff --git a/debian/changelog b/debian/changelog
index 3cf3095a..1b45bf3d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+gst-plugins-bad1.0 (1.18.4-3) unstable; urgency=medium
+
+  * Team upload.
+  * debian/control: Add more architectures to the opencv BD
+  * debian/control: Do not make libgstreamer-plugins-bad1.0-dev depend on
+opencv where it's not available (Closes: #987396)
+  * Do not try to install the sctp on non-linux architectures
+
+ -- Laurent Bigonville   Mon, 26 Apr 2021 17:07:50 +0200
+
 gst-plugins-bad1.0 (1.18.4-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --git a/debian/control b/debian/control
index e2dece74..de5bbf23 100644
--- a/debian/control
+++ b/debian/control
@@ -51,8 +51,8 @@ Build-Depends: debhelper,
libnice-dev (>= 0.1.14),
libofa0-dev (>= 0.9.3),
libopenal-dev (>= 1:1.14),
-   libopencv-dev (>= 3.0.0) [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x powerpc ppc64 riscv64],
-   opencv-data [amd64 arm64 armel armhf i386 mips64el mipsel 
ppc64el s390x powerpc ppc64 riscv64],
+   libopencv-dev (>= 3.0.0) [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha hppa hurd-i386 m68k powerpc ppc64 riscv64],
+   opencv-data [amd64 arm64 armel armhf i386 mips64el mipsel 
ppc64el s390x alpha hppa hurd-i386 m68k powerpc ppc64 riscv64],
libwpebackend-fdo-1.0-dev (>= 1.6.0) [amd64 arm64 armel 
armhf hppa i386 mipsel ppc64 ppc64el s390x sparc64 x32],
libwpewebkit-1.0-dev (>= 2.28.0) [amd64 arm64 armel armhf hppa i386 mipsel ppc64 ppc64el s390x sparc64 x32],
libopenexr-dev,
@@ -166,7 +166,7 @@ Description: GStreamer plugins from the "bad" set
  real live maintainer, or some actual wide use.
 
 Package: gstreamer1.0-opencv
-Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x 
powerpc ppc64 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x 
alpha hppa hurd-i386 m68k powerpc ppc64 riscv64
 Multi-Arch: same
 Depends: ${misc:Depends},
  ${shlibs:Depends},
@@ -248,7 +248,7 @@ Description: GStreamer libraries from the "bad" set
  is not guaranteed to be stable.
 
 Package: libgstreamer-opencv1.0-0
-Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x 
powerpc ppc64 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x 
alpha hppa hurd-i386 m68k powerpc ppc64 riscv64
 Section: libs
 Priority: optional
 Multi-Arch: same
@@ -279,11 +279,11 @@ Section: libdevel
 Priority: optional
 Depends: ${misc:Depends},
  libgstreamer-plugins-bad1.0-0 (= ${binary:Version}),
- libgstreamer-opencv1.0-0 (= ${binary:Version}),
+ libgstreamer-opencv1.0-0 (= ${binary:Version}) [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha hppa hurd-i386 m68k powerpc ppc64 riscv64],
  libgstreamer1.0-dev,
  libgstreamer-plugins-base1.0-dev,
  gir1.2-gst-plugins-bad-1.0 (= ${binary:Version}),
- libopencv-dev (>= 2.3.0)
+ libopencv-dev (>= 2.3.0) [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha hppa hurd-i386 m68k powerpc ppc64 riscv64]
 Conflicts: pitivi (<< 0.)
 Description: GStreamer development files for libraries from the "bad" set
  GStreamer is a streaming media framework, based on graphs of filters
diff --git a/debian/gstreamer1.0-plugins-bad.install b/debian/gstreamer1.0-plugins-bad.install
index 7949901b..fe627515 100644
--- a/debian/gstreamer1.0-plugins-bad.install
+++ b/debian/gstreamer1.0-plugins-bad.install
@@ -84,7 +84,6 @@ debian/tmp/usr/lib/*/gstreamer-1.0/libgstrtmp.so
 debian/tmp/usr/lib/*/gstreamer-1.0/libgstrtmp2.so
 debian/tmp/usr/lib/*/gstreamer-1.0/libgstrtponvif.so
 debian/tmp/usr/lib/*/gstreamer-1.0/libgstrtpmanagerbad.so
-debian/tmp/usr/lib/*/gstreamer-1.0/libgstsctp.so
 debian/tmp/usr/lib/*/gstreamer-1.0/libgstsdpelem.so
 debian/tmp/usr/lib/*/gstreamer-1.0/libgstsegmentclip.so
 debian/tmp/usr/lib/*/gstreamer-1.0/libgstshm.so
diff --git a/debian/rules b/debian/rules
index 

Bug#987264: git-el: fails to install with xemacs21

[Agustin Martin]

On Sat, 24 Apr 2021 02:59:40 +0300 Adrian Bunk  wrote:
> On Tue, Apr 20, 2021 at 05:10:16PM +0200, Andreas Beckmann wrote:
> > Package: git-el
> > Version: 1:2.30.2-1
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> >
> > Hi,
> >
> > during a test with piuparts I noticed your package failed to install if
> > xemacs21 is already installed.
>
> Most relevant is that emacs-common is *not* installed
> and neither any other package that ships /usr/share/emacs/site-lisp/

IIRC emacs-common is only for FSF Emacs packages.

The quickest workaround would be to add a debian/git-el.dirs file
containing usr/share/emacs/site-lisp. I wonder if emacsen-common
package should provide that dir for all emacs flavours.

-- 
Agustin

Bug#987239: unblock: glance/21.0.0-2

[Sebastian Ramacher]

Control: tags -1 + confirmed moreinfo

On 2021-04-26 21:37:56 +0200, Thomas Goirand wrote:
> On 4/26/21 4:01 PM, Sebastian Ramacher wrote:
> >> The changelog goes like this:
> >>
> >>   1* Add variables: DEB_BUILD_OPTIONS: nocheck DEB_BUILD_PROFILES: nocheck 
> >> in
> >> debian/salsa-ci.yml.
> >>   2* Do not delete /etc/glance/rootwrap.conf, owned by 
> >> python3-glance-store.
> >> (Closes: #987193).
> >>   3* mv /etc/glance/policy.json /etc/glance/disabled.policy.json.old 
> >> instead of
> >> deleting /etc/glance/policy.json.
> >>   4* Tune glance-api-uwsgi.ini for performance.
> > 
> > Regarding 3*: why isn't the old file not moved to the new location?
> > 
> > Cheers
> 
> I'm sorry, I'm too much into it, and forgot the main story.
> 
> For a technical reason that would be long to explain, the old json
> format is deprecated, and OpenStack users should stop using it as soon
> as possible, otherwise, it may may create of issues. The new way of
> doing things is to stop Json with every policy option declared, and
> switch to a standard where everything commented-out in a yaml file,
> describing what's in the python code as default.
> 
> In Debian, we now generates a yaml file in
> /etc/glance/policy.d/00_default-policy.yaml. I expect users to leave the
> file as-is, and just add configuration fragments on the same folder,
> rather than editing a unique policy.json like before.
> 
> Therefore, the best thing we could do, was just move away .json format
> API policy file, to make sure that it's not in use (because older
> version of Glance may point to the old /etc/glance/policy.json). And
> that's why I'm using such an explicit "disabled.policy.json.old" name.
> 
> The thing is, deleting the old policy.json was a bad idea. Because
> administrator may have edited that file to set various API policies in
> previous releases of OpenStack. So best is to keep it, but renamed, and
> tell the user to put what he edited as fragments in /etc/glance/policy.d
> in yaml format only.
> 
> Moving the policy.json in the policy.d is not a good idea either,
> because it keeps the old JSON format, now deprecated by upstream, that
> we explicitly require users to move away from.
> 
> I hope it's more clear now.

I tried to find some documentation on that in the package and the
releases notes, but I was unable to find any info on that. Please
document that as users have to be aware of the steps they have to take.

Once that's done, please remove the moreinfo tag.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#987320: dracut: Version is not included in --version, --help or initramfs runtime

[Thomas Lange]

I can confirm this bug.

I guess the dracut version is created during the build of the package
extracted from some git tags if avalable. Since I have to do source
only upload to Debian, the git information is missing and so
the version information is empty

# cat /usr/lib/dracut/dracut-version.sh
DRACUT_VERSION=

I'll try to work around this in the next version.

-- 
viele Grüße Thomas

Bug#987655: sbuild: Support zstd tarballs

[Johannes Schauer Marin Rodrigues]

Hi Vagrant,

Quoting Vagrant Cascadian (2021-04-27 09:08:38)
> The attached patch adds support for using zstd compressed tarballs.
> 
> sbuild will try to use ~/.cache/sbuild/sid-amd64.tar.zst but tar may not
> know what to do with it and so errors out:
> 
>   Unpacking /home/vagrant/.cache/sbuild/sid-amd64.tar.zst to 
> /tmp/tmp.sbuild.2ilJsfh49J...
>   tar: Archive is compressed. Use --zstd option
>   tar: Error is not recoverable: exiting now
>   E: ABORT: Received PIPE signal (requesting cleanup and shutdown)
> 
> 
> The patch passes the --zstd argument to tar, which seems to be available
> in versions of tar since buster. Alternately, "--use-compress-program
> zstd" worked as well.

cool, thanks! I'll apply your patch after the bullseye release.

> Really loving "--chroot-mode=unshare" !

Wow, it's really working for you? I'm not getting any feedback for the unshare
mode and never knew whether this was because nobody is using it or because
there are no problems. XD

Since sbuild-createchroot is only needed for the schroot setup I'm using this
command these days to create chroots:

mmdebstrap --variant=buildd unstable ~/.cache/sbuild/sid-amd64.tar.gz

As of #923747 being fixed, the above command will work in "unshare" mode by
default and that way the whole sbuild machinery can now be setup and run
without being root or suid root.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#964906: Same problem here, but not systematic

[Raphaël Plasson]

I have the same problem on two of my servers (both with similar 
configuration, debian buster with backports), both with a btrfs raid-1 
on /root.


In my case, initramfs indeed fails to mount /root, but performing a 
'btrfs device scan' followed by a manual mount to /root directly on the 
initramfs prompts solves the problem.


However, this problem is not systematically met. Even on the same 
server, the root may be correctly mounted after a reboot.


Maybe there is a race condition, so that the 
'/usr/share/initramfs-tools/scripts/local-premount/btrfs' may not be 
launched at the right moment?


Hoping this information can help.

Bug#987654: Adjusting severity

[Kunal Mehta]

severity 987654 serious
thanks

Upping priority to serious as this is technically a violation of policy 
that all software in main should be self-contained to main, and I 
believe there is a general acceptance in Debian that such privacy 
breaches are not acceptable (see also #726998).


I can also confirm that I finished testing the upstream patch and it 
worked as expected after running "sudo mailman-web collectstatic --clear 
&& sudo mailman-web compress".


-- Kunal

Bug#806929: X repeatedly gathers and logs modeline information, causing heavy CPU utilization

[Erez Shomron]

Package: xorg
Version: 1:7.7+22
Followup-For: Bug #806929
X-Debbugs-Cc: erezshom...@mykolab.com

Dear Maintainer,

I have a similar problem which might be related to this old issue. I've decided
to reply here because of the similarities I've found between the log files.

I can confirm xorg causes high CPU usage on my E480 Thinkpad laptop.

This started happening after I connected an external monitor via HDMI with a
VGA adapter (as the external monitor does not support HDMI).
High CPU usage loop happens occasionally after dragging a window from the
external monitor to the laptop monitor. This action does not always cause the
loop, but it appears to be one semi-consistent trigger.
It also appears to happen more often after coming back from suspension and
dragging a window between the monitors.

I solve this problem temporarily by killing xorg, which isn't ideal. I would
expect xorg to be able to handle two monitors on my hardware without entering a
high CPU usage loop.

I hope you find this report helpful.


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 
[8086:5917] (rev 07)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 266 Jun 28  2020 00-keyboard.conf

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

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

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 50380 Apr 27 10:14 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 55045 Apr 27 10:20 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[ 52615.443] 
X.Org X Server 1.20.10
X Protocol Version 11, Revision 0
[ 52615.443] Build Operating System: linux Debian
[ 52615.443] Current Operating System: Linux mandor 5.10.0-6-amd64 #1 SMP 
Debian 5.10.28-1 (2021-04-09) x86_64
[ 52615.443] Kernel command line: BOOT_IMAGE=/vmlinuz-5.10.0-6-amd64 
root=UUID=88ce1b03-a57d-46fe-b3b2-3a91beb4413e ro quiet splash 
resume=UUID=a7e6cd7a-f006-413f-a9a1-daef5189ff24
[ 52615.443] Build Date: 17 February 2021  09:17:43AM
[ 52615.443] xorg-server 2:1.20.10-3 (https://www.debian.org/support) 
[ 52615.443] Current version of pixman: 0.40.0
[ 52615.443]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 52615.443] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 52615.443] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Apr 27 10:20:03 
2021
[ 52615.443] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 52615.443] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 52615.444] (==) No Layout section.  Using the first Screen section.
[ 52615.444] (==) No screen section available. Using defaults.
[ 52615.444] (**) |-->Screen "Default Screen Section" (0)
[ 52615.444] (**) |   |-->Monitor ""
[ 52615.445] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 52615.445] (==) Automatically adding devices
[ 52615.445] (==) Automatically enabling devices
[ 52615.445] (==) Automatically adding GPU devices
[ 52615.445] (==) Max clients allowed: 256, resource mask: 0x1f
[ 52615.445] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 52615.445]Entry deleted from font path.
[ 52615.445] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 52615.445] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 52615.445] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 52615.445] (II) Loader magic: 0x55b4052c5e40
[ 52615.445] (II) Module ABI versions:
[ 52615.445]X.Org ANSI C Emulation: 0.4
[ 52615.445]X.Org Video Driver: 24.1
[ 52615.445]X.Org XInput driver : 24.1
[ 52615.445]X.Org Server Extension : 10.0
[ 52615.447] (++) using VT number 7

[ 52615.447] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[ 52615.449] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 52615.471] (--) PCI:*(0@0:2:0)