Bug#995498: FP? missing-build-dependency-for-dh-addon python3

[Felix Lechner]

Hi,

On Sat, Oct 2, 2021 at 1:45 AM Julien Puydt  wrote:
>
> so I think it's a false positive.

Actually, Lintian has required the ':any' for Python prerequisites
since 2013 [1] but the implementation was defective. [2] You are now
seeing an accurate picture of Lintian's settings [3][4][5][6][7]
because the diagnostics were fixed. [8] That being said, the current
settings are probably wrong.

There appears to have been no bootstrapping reason to require the
':any' for Python across the board. The setting is also not correct
for all cases. It will probably be removed in the near future.

I am still researching my recent commit [8] in the context of the
rationale presented in 2013. [9] My position is that "python:any"
implies the ability to satisfy "python".

> If it's not, both lintian's output and the error description in
> /usr/share/lintian/tags/m/missing-build-dependency-for-dh-addon.tag
> fail to explain what the matter really is.

Thank you for the pointer. For the sake of consistency, I recently
adjusted several tag descriptions [10] but apparently missed that one.
Either way, the documentation changes will probably be reverted when
the ':any' is dropped from the Python prerequisites.

Thank you for bringing the matter to our attention!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/beb1094db955fd99b693fca1e4c87958676dfe74
[2] https://bugs.debian.org/994902
[3] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Debhelper.pm#L90
[4] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Debian/Rules.pm#L41-50
[5] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Testsuite.pm#L58-59
[6] 
https://salsa.debian.org/lintian/lintian/-/blob/master/data/scripts/interpreters#L80-81
[7] 
https://salsa.debian.org/lintian/lintian/-/blob/master/data/scripts/versioned-interpreters#L77-78
[8] 
https://salsa.debian.org/lintian/lintian/-/commit/9bc560a62571f2f1a70ce7044093c42ff14e3efa
[9] 
https://salsa.debian.org/lintian/lintian/-/commit/153961ead4ea6c7d38951f36852e43d110b8db30
[10] 
https://salsa.debian.org/lintian/lintian/-/commit/ec728f427a2aa4f1d2451117448e79979a106f07

Bug#995606: lintian: non-free font packages and {truetype,opentype}-font-prohibits-installable-embedding

[Paul Wise]

On Sat, 2021-10-02 at 22:15 -0700, Felix Lechner wrote:

> I too would like to see variable visibilities, but we do not currently
> offer them. The traditional solution has been to introduce new tags.

Splitting the tag up would also allow having different advice for
packages in main vs non-free, which I guess is not an option for a
single tag either, so splitting them is probably a good idea anyway.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#995606: lintian: non-free font packages and {truetype,opentype}-font-prohibits-installable-embedding

[Felix Lechner]

Hi Paul,

On Sat, Oct 2, 2021 at 10:03 PM Paul Wise  wrote:
>
> downgrade the embedding tags to either info or pedantic
> for non-free packages.

I too would like to see variable visibilities, but we do not currently
offer them. The traditional solution has been to introduce new tags.

Maybe I will take it as an opportunity to give the matter some thought.

Kind regards
Felix Lechner

Bug#995427: RFA: mrtg -- multi router traffic grapher

[Eriberto Mota]

Control: retitle 995427 ITA: mrtg -- multi router traffic grapher
Control: owner 995427 !

Hi Sandro,

I confirm that I will adopt mrtg. I will upload a new revision with some
initial changes in a few hours. This upload will close this bug. After this,
in a few days I will import the new upstream release and I will make several
other changes.

Have a good Sunday.

Regards,

Eriberto

Bug#995606: lintian: non-free font packages and {truetype,opentype}-font-prohibits-installable-embedding

[Paul Wise]

Package: lintian
Severity: wishlist

For non-free fonts, prohibiting embedding is often consistent with the
license, so the two lintian warnings often don't really apply. On the
other hand prohibiting embedding is particularly user hostile so Debian 
should probably try to discourage it. On balance I think the right
solution is to downgrade the embedding tags to either info or pedantic
for non-free packages. The openboard-extras-nonfree package is already
overriding this tag, probably due to the warning vs pedantic level.

truetype-font-prohibits-installable-embedding
opentype-font-prohibits-installable-embedding

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#982835: installation-report: doesn't set needed rootflags for flash-kernel when btrfs is used as rootfs

[Vagrant Cascadian]

On 2021-10-02, Vagrant Cascadian wrote:
> On 2021-02-15, Vieno Hakkerinen wrote:
>> I created a ext2 for /boot and luks+lvm+btrfs for /. As d-i defaults
>> to use a @rootfs subvolume for btrfs the linux bootargs need to have
>> set "rootflags=subvol=@rootfs". This was not set during configuration
>> of flash-kernel. Without this argument debian failed to boot with an
>> error that no init was found.
>
>>* What outcome did you expect instead?
>>
>> debian-installer should set "rootflags=subvol=@rootfs" in 
>> /etc/default/flash-kernel when btrfs is used for /
>
>>* What did you do to solve the problem?
>>
>> 1. I ran "setenv bootargs rootflags=subvol=@rootfs" in u-boot
>> 2. I ran "boot" in u-boot
>> 3. debian found init successfully
>> 4. I added "rootflags=subvol=@rootfs" to LINUX_KERNEL_CMDLINE_DEFAULTS in 
>> /etc/default/flash-kernel
>> 5. I ran flash-kernel
>> 6. I rebooted
>> 7. debian booted successfully
>
> So, flash-kernel-installer has a debconf question that might be useable
> for this purpose:
>
> flash-kernel-installer.postinst.in:echo flash-kernel 
> flash-kernel/linux_cmdline string $kopt_params | \
> flash-kernel-installer.postinst.in- chroot /target debconf-set-selections
>
> I'm curious how other systems handle btrfs (e.g. grub on amd64); are
> there any configuration options passed via debian-installer to set
> "rootflags=subvol=@rootfs", or does grub have any configuration that are
> set from update-grub or whatever ... or autodetected when rootfs is on
> btrfs?

To answer my own question, looks like it's autodetected in
/etc/grub.d/10_linux:

case x"$GRUB_FS" in
xbtrfs)
rootsubvol="`make_system_path_relative_to_its_root /`"
rootsubvol="${rootsubvol#/}"
if [ "x${rootsubvol}" != x ]; then
GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol}
${GRUB_CMDLINE_LINUX}"
fi;;


I suspect the way to handle this would be to have flash-kernel-installer
do something similar and pass it into the debconf option ... unless
someone can find a sane place to put that into flash-kernel at
run-time...

It might be easier to adapt other code, such as u-boot-menu and install
u-boot-menu instead of, or in addition to, flash-kernel... or at least,
that would be another case where this could be supported.


live well,
  vagrant




signature.asc
Description: PGP signature

Bug#982835: installation-report: doesn't set needed rootflags for flash-kernel when btrfs is used as rootfs

[Vagrant Cascadian]

On 2021-02-15, Vieno Hakkerinen wrote:
> I created a ext2 for /boot and luks+lvm+btrfs for /. As d-i defaults
> to use a @rootfs subvolume for btrfs the linux bootargs need to have
> set "rootflags=subvol=@rootfs". This was not set during configuration
> of flash-kernel. Without this argument debian failed to boot with an
> error that no init was found.

>* What outcome did you expect instead?
>
> debian-installer should set "rootflags=subvol=@rootfs" in 
> /etc/default/flash-kernel when btrfs is used for /

>* What did you do to solve the problem?
>
> 1. I ran "setenv bootargs rootflags=subvol=@rootfs" in u-boot
> 2. I ran "boot" in u-boot
> 3. debian found init successfully
> 4. I added "rootflags=subvol=@rootfs" to LINUX_KERNEL_CMDLINE_DEFAULTS in 
> /etc/default/flash-kernel
> 5. I ran flash-kernel
> 6. I rebooted
> 7. debian booted successfully

So, flash-kernel-installer has a debconf question that might be useable
for this purpose:

flash-kernel-installer.postinst.in:echo flash-kernel flash-kernel/linux_cmdline 
string $kopt_params | \
flash-kernel-installer.postinst.in- chroot /target debconf-set-selections

I'm curious how other systems handle btrfs (e.g. grub on amd64); are
there any configuration options passed via debian-installer to set
"rootflags=subvol=@rootfs", or does grub have any configuration that are
set from update-grub or whatever ... or autodetected when rootfs is on
btrfs?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#995425: linux-image-amd64: kernel BUG at fs/ext4/ext4_extents.h:199! (fast_commit feature)

[ng]

It fixes the issue!   Works correctly with that patch.


El 2/10/21 a las 3:52 a. m., Salvatore Bonaccorso escribió:

Control: tags -1 + moreinfo

On Thu, Sep 30, 2021 at 08:26:38PM -0500, Nelson G wrote:

Package: linux-image-amd64
Version: 5.10.46-5
Severity: normal

Hello,

There's a bug for the ext4 filesystem, when the fast_commit flag is enabled and
you use fallocate or any other task that allocates space.


You can easily reproduce this bug on a VM or raw hardware by doing the
following:

1° You'll need a drive formatted with ext4 of course.
2° Enable fast_commit in that drive:  tune2fs -O fast_commit /dev/yourdrive
3° mount 'yourdrive', and inside 'yourdrive' try the following: fallocate -l
2000MB file

Can you check if the following fixes your issue?

https://lore.kernel.org/linux-ext4/20210820044505.474318-1-hout...@huawei.com/

https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev=a2c2f0826e2b75560b31daf1cd9a755ab93cf4c6

Regards,
Salvatore

Bug#995598: RFP: rtw89 -- Driver for Realtek 8852AE, an 802.11ax device

[briaguya]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: briag...@mailfence.com

* Package name: rtw89
  Version : git
  Upstream Author : lwfinger 
* URL : https://github.com/lwfinger/rtw89
* License : GPL2
  Programming Lang: C
  Description : Driver for Realtek 8852AE, an 802.11ax device

drivers for the following card: Realtek 8852AE

Bug#995267: devhelp doesn't load the selected content

[Rinat Ibragimov]

Looks like it's sufficient to remove 
~/.local/share/mime/application/x-extension-html.xml
and then to regenerate database:

update-mime-database ~/.local/share/mime

More information is available in bug #722279, which is very similar to this 
one. In short,
libwebkit2gtk doesn't like "application/x-extension-html" and decides to not 
render such
documents.

Bug#995452: libpam-ssh breaks the agent-forwarding of normal ssh

[Matti Kurkela]

The workaround/fix for this would be to not let pam-auth-update add 
pam_ssh.so into common-auth and common-session, but add the necessary 
lines *selectively* only to services that handle local logins like 
/etc/pam.d/login and /etc/pam.d/*dm, but *not* to /etc/pam.d/sshd.


That should allow libpam-ssh to start the agent on initial login, but 
leave the SSH sessions and their agent forwarding alone.


If you need the "authentication by SSH key passphrase" functionality on 
SSH connections, you could add only the "auth optional pam_ssh.so 
try_first_pass" line to /etc/pam.d/sshd. (Note that this line should not 
be the first authentication module, to prevent an information leak, as 
described in the pam_ssh(8) man page.)

Bug#995604: ntfs-3g: mount.ntfs stuck in D state

[sylvain]

Package: ntfs-3g
Version: 1:2021.8.22-2
Severity: normal

Dear Maintainer,

mount.ntfs gets stuck in D state, i'm running latest SID kernel, 5.14.6-3. 
here's the stack trace:

[ 1209.682705] INFO: task kworker/3:0:3972 blocked for more than 604 seconds.
[ 1209.682728]   Tainted: P   OE 5.14.0-1-amd64 #1 Debian 
5.14.6-3
[ 1209.682729] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 1209.682731] task:kworker/3:0 state:D stack:0 pid: 3972 ppid: 2 
flags:0x4000
[ 1209.682735] Workqueue: usb_hub_wq hub_event [usbcore]
[ 1209.682759] Call Trace:
[ 1209.682762]  __schedule+0x2f0/0x910
[ 1209.682768]  schedule+0x44/0xa0
[ 1209.682769]  rwsem_down_read_slowpath+0x342/0x390
[ 1209.682772]  get_super+0x93/0xe0
[ 1209.682779]  fsync_bdev+0x11/0x60
[ 1209.682783]  delete_partition+0x13/0x80
[ 1209.682788]  blk_drop_partitions+0x4a/0x90
[ 1209.682790]  del_gendisk+0x44/0x1c0
[ 1209.682793]  sd_remove+0x3d/0x80 [sd_mod]
[ 1209.682797]  __device_release_driver+0x17a/0x230
[ 1209.682802]  device_release_driver+0x24/0x30
[ 1209.682804]  bus_remove_device+0xd8/0x140
[ 1209.682806]  device_del+0x18b/0x3e0
[ 1209.682811]  ? ata_tlink_match+0x30/0x30 [libata]
[ 1209.682831]  ? attribute_container_device_trigger+0x69/0xf0
[ 1209.682834]  __scsi_remove_device+0x118/0x150 [scsi_mod]
[ 1209.682851]  scsi_forget_host+0x54/0x60 [scsi_mod]
[ 1209.682859]  scsi_remove_host+0x72/0x100 [scsi_mod]
[ 1209.682868]  usb_stor_disconnect+0x46/0xc0 [usb_storage]
[ 1209.682872]  usb_unbind_interface+0x8a/0x270 [usbcore]
[ 1209.682885]  ? kernfs_find_ns+0x35/0xd0
[ 1209.682889]  __device_release_driver+0x17a/0x230
[ 1209.682891]  device_release_driver+0x24/0x30
[ 1209.682893]  bus_remove_device+0xd8/0x140
[ 1209.682895]  device_del+0x18b/0x3e0
[ 1209.682897]  ? kobject_put+0x91/0x1d0
[ 1209.682900]  usb_disable_device+0xc6/0x1e0 [usbcore]
[ 1209.682911]  usb_disconnect.cold+0x7b/0x207 [usbcore]
[ 1209.682922]  hub_event+0xbf2/0x1810 [usbcore]
[ 1209.682932]  ? __switch_to_asm+0x42/0x70
[ 1209.682936]  process_one_work+0x1ec/0x390
[ 1209.682939]  worker_thread+0x53/0x3e0
[ 1209.682941]  ? process_one_work+0x390/0x390
[ 1209.682942]  kthread+0x127/0x150
[ 1209.682945]  ? set_kthread_struct+0x40/0x40
[ 1209.682948]  ret_from_fork+0x22/0x30

I didn't have this issue with the previous 5.10 kernel. Please let me know if 
you need more information.

Thank you
Sylvain

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

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

Versions of packages ntfs-3g depends on:
ii  fuse3 [fuse]  3.10.5-1
ii  libc6 2.32-4
ii  libgcrypt20   1.9.4-3+b1
ii  libgnutls30   3.7.2-2
ii  libntfs-3g89  1:2021.8.22-2

ntfs-3g recommends no packages.

ntfs-3g suggests no packages.

-- no debconf information

Bug#994910: Uploading ASAP

[Alberto Gonzalez Iniesta]

tags 994910 + pending
thanks

Hi, I'll make an upload to unstable ASAP.

Thanks,

Alberto

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#995592: RFS: urlwatch/2.23-2 -- monitors webpages for you

[Adam Borowski]

On Sat, Oct 02, 2021 at 08:41:54PM +0200, Maxime Werlen wrote:
>  * Package name: urlwatch
>Version : 2.23-2

>  urlwatch (2.23-2) unstable; urgency=medium
>  .
>* Updated Standards-Version to 4.6.0
>* Upload to unstable after Bullseye release

E: urlwatch source: missing-build-dependency-for-dh-addon python3 => 
python3:any | python3-all:any | python3-dev:any | python3-all-dev:any | 
dh-sequence-python3

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ “Exegi monumentum aere perennius” -- “I made a monument more
⢿⡄⠘⠷⠚⠋⠀ durable than bronze”.
⠈⠳⣄   -- Horace (65-8 BC), leaving the loo, constipated

Bug#995588: RFS: rumur/2021.09.29-1 -- model checker for the Murphi language

[Adam Borowski]

On Sat, Oct 02, 2021 at 11:26:19AM -0700, Matthew Fernandez wrote:
> * Package name: rumur
>Version : 2021.09.29-1

> rumur (2021.09.29-1) unstable; urgency=medium


E: rumur: python3-script-but-no-python3-dep usr/bin/rumur-run python3

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#995601: additional data

[Mike Kupfer]

I just realized that Bullseye also has mate-panel 1.24.1-1.  But I don't
see the compression problem with my Bullseye VM, just with the systems
that are running Bookworm.

Also, on my Bookwork VM, if I tell the applet to display the workspaces
in 2 rows, they have the correct dimensions.  If I go back to displaying
the workspaces in 1 row, they go back to being taller than wide.

regards,
mike

Bug#995599: libopenmpi3: segfault in mca_btl_vader.so on 32-bit arches

[Drew Parsons]

On 2021-10-03 00:51, Drew Parsons wrote:

Manually debugging isolates the point in the dolfinx code at
mesh/graphbuild.cpp l.144

  graph::AdjacencyList recvd_buffer
  = dolfinx::MPI::all_to_all(comm, send_buffer);

https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/blob/experimental/cpp/dolfinx/mesh/graphbuild.cpp#L144

I think that supports the argument that the segfault is in openmpi
rather than dolfinx. Unless it's related to the use of int64_t when
handling the mpi communication buffers. I'll flag that for upstream
dolfinx review.




Query raised at https://github.com/FEniCS/dolfinx/issues/1735

Bug#635172: non-UTF8 is declared an unthing!

[Adam Borowski]

In bookworm, ancient locales are no longer supported, thus this bug stopped
being relevant.

Bug#995591: RFS: minidb/2.0.5-2 -- simple SQLite3-based store for Python objects

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: minidb
   Version : 2.0.5-2
   Upstream Author : Thomas Perl 
 * URL : https://thp.io/2010/minidb/
 * License : ISC
 * Vcs : https://salsa.debian.org/mwerlen/minidb
   Section : python

It builds those binary packages:

  python3-minidb - simple SQLite3-based store for Python objects

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/minidb/minidb_2.0.5-2.dsc

Changes since the last upload:

 minidb (2.0.5-2) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Remove obsolete field Name from debian/upstream/metadata
 .
   [ Maxime Werlen ]
   * Remove .github folder from this repo
   * Remove duplicated lines in copyright (Thanks to Tobias Frost)
   * Deduplicate build dependency on dh and dh-compat (Thanks to Tobias Frost)
   * Updated Standards-Version to 4.6.0
   * Upload to unstable after Bullseye release

Regards,
-- 
Maxime Werlen

Bug#995592: RFS: urlwatch/2.23-2 -- monitors webpages for you

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: urlwatch
   Version : 2.23-2
   Upstream Author : Thomas Perl 
 * URL : https://thp.io/2008/urlwatch/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/mwerlen/urlwatch
   Section : web

It builds those binary packages:

  urlwatch - monitors webpages for you

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/urlwatch/urlwatch_2.23-2.dsc

Changes since the last upload:

 urlwatch (2.23-2) unstable; urgency=medium
 .
   * Updated Standards-Version to 4.6.0
   * Upload to unstable after Bullseye release

Regards,
-- 
Maxime Werlen

Bug#995599: libopenmpi3: segfault in mca_btl_vader.so on 32-bit arches

[Drew Parsons]

Manually debugging isolates the point in the dolfinx code at
mesh/graphbuild.cpp l.144

  graph::AdjacencyList recvd_buffer
  = dolfinx::MPI::all_to_all(comm, send_buffer);

https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/blob/experimental/cpp/dolfinx/mesh/graphbuild.cpp#L144

I think that supports the argument that the segfault is in openmpi 
rather than dolfinx. Unless it's related to the use of int64_t when 
handling the mpi communication buffers. I'll flag that for upstream 
dolfinx review.


Drew

Bug#993492: cyrus-imapd 3.0.8-6+deb10u6 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993492 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: cyrus-imapd
Version: 3.0.8-6+deb10u6

Explanation: fix denial-of-service issue [CVE-2021-33582]

Bug#989494: http-parser 2.8.1-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 989494 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: http-parser
Version: 2.8.1-1+deb10u1

Explanation: fix HTTP request smuggling issue [CVE-2019-15605]

Bug#584726: rdiff-backup: preserve_atime option

[Pablo Mestre]

Hi Clint Adams

Thank you very much for reporting this error.

I would like to ask you if this error is still present in the most
recent versions of rdiff-backup. Currently after a series of
improvements and bug fixes, rdiff-backup is at version 2.0.5 [1]

It would be very helpful if you checked again if this bug is still present. 
Otherwise we can agree to close the bug,

[1] https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.5 


-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#995601: mate-panel: workspace switcher applet is compressed horizontally

[Mike Kupfer]

Package: mate-panel
Version: 1.24.1-1+b1
Severity: normal
X-Debbugs-Cc: mkup...@alum.berkeley.edu

Dear Maintainer,

I have a display that is wider than tall, but the workspace switcher
applet shows it as taller than wide.  Similar, a mate-terminal window
that is wider than tall gets shown as taller than wide.

The dimensions of the pop-up workspace switcher are fine.

I see this on both a VirtualBox guest and a baremetal system (Dell
Latitude E7250).

I am currently using the Blue Menta theme, but I see this with other
themes as well.

Output from xdpyinfo:

-8<-8<-
name of display::0.0
version number:11.0
vendor string:The X.Org Foundation
vendor release number:12011000
X.Org version: 1.20.11
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:32, LSBFirst, 32
image byte order:LSBFirst
number of supported pixmap formats:7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:minimum 8, maximum 255
focus:  window 0x3e00156, revert to PointerRoot
number of extensions:29
BIG-REQUESTS
Composite
DAMAGE
DOUBLE-BUFFER
DPMS
DRI2
DRI3
GLX
Generic Event Extension
MIT-SCREEN-SAVER
MIT-SHM
Present
RANDR
RECORD
RENDER
SECURITY
SHAPE
SYNC
VMWARE_CTRL
X-Resource
XC-MISC
XFIXES
XFree86-DGA
XFree86-VidModeExtension
XINERAMA
XInputExtension
XKEYBOARD
XTEST
XVideo
default screen number:0
number of screens:1

screen #0:
  dimensions:1920x1098 pixels (508x291 millimeters)
  resolution:96x96 dots per inch
  depths (7):24, 1, 4, 8, 15, 16, 32
  root window id:0x182
  depth of root window:24 planes
  number of colormaps:minimum 1, maximum 1
  default colormap:0x20
  default number of colormap cells:256
  preallocated pixels:black 0, white 16777215
  options:backing-store WHEN MAPPED, save-unders NO
  largest cursor:64x64
  current input event mask:0xfa8033
KeyPressMask KeyReleaseMask   EnterWindowMask  
LeaveWindowMask  ExposureMask StructureNotifyMask  
SubstructureNotifyMask   SubstructureRedirectMask FocusChangeMask  
PropertyChangeMask   ColormapChangeMask   
  number of visuals:108
  default visual id:  0x21
  visual:
visual id:0x21
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x22
class:DirectColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x118
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x119
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x11a
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x11b
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x11c
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x11d
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x11e
class:TrueColor
depth:24 planes
available colormap entries:256 per subfield
red, green, blue masks:0xff, 0xff00, 0xff
significant bits in color specification:8 bits
  visual:
visual id:0x11f
class:TrueColor
depth:24 planes
available colormap 

Bug#994486: cryptsetup-initramfs: include askpass only when needed?

[Guilhem Moulin]

On Sun, 03 Oct 2021 at 00:03:17 +0200, Christoph Anton Mitterer wrote:
> It's like you say in the other bugs... people cannot rely on non-
> documented features, and you're right there - otherwise you could
> barely make any changes.

We could also rename internal functions, variables, and paths to random
strings to force people to stick to the documented API, but we don't and
that is intentional.  It's all about trade off here.  In our mind the
big refactoring that caused you to report #901795 outweigh the downsides
at the time.  Sometimes we've also caused unforeseen breakage and didn't
balance the benefit until it was too late. But actively trying to break
setups relying on undocumented internals for no stated benefits is not
something we do.

So there is only 1) in my mind.  Need to think whether saving these 2kiB
is really worth the trouble.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#995600: FTBFS: error: format not a string literal and no format arguments

[Adam Borowski]

Source: omega-rpg
Version: 1:0.90-pa9-16
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid that your package fails to build with:

scr.c: In function ‘print1’:
scr.c:351:5: error: format not a string literal and no format arguments 
[-Werror=format-security]
  351 | wprintw(Msg1w,s);
  | ^~~
scr.c: In function ‘nprint1’:
scr.c:361:7: error: format not a string literal and no format arguments 
[-Werror=format-security]
  361 |   wprintw(Msg1w,s);
  |   ^~~
scr.c: In function ‘print2’:
scr.c:374:5: error: format not a string literal and no format arguments 
[-Werror=format-security]
  374 | wprintw(Msg2w,s);
  | ^~~
(repeated elebenty times)


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-rc2-00041-g794e5d9c562d (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#995498: FP? missing-build-dependency-for-dh-addon python3

[Nilesh Patra]

On Sat, 02 Oct 2021 10:40:14 +0200 Julien Puydt  wrote:
> E: python-anyio source: missing-build-dependency-for-dh-addon python3
> => python3:any | python3-all:any | python3-dev:any | python3-all-
> dev:any | dh-sequence-python3
> 
> but in d/control:
> Build-Depends: debhelper-compat (= 13),
>dh-python,
>python3,

I just got bit error by this as well. Adding a :any in front of python3
fixed it for me, but I am not sure if this is a right thing to do for
every package that might use python in dh process.

All the more, I don't really see why this should emit a lintian "error" at all, 
because
clearly, the build-deps are satisfied.
Unless I misunderstand, a missing :any should be demoted to something else and 
at the very least,
not be an error.

Nilesh


signature.asc
Description: PGP signature

Bug#995586: Lack of /usr/lib/tmpfiles.d/podman.conf

[IB Development Team]

Package: podman
Version: 3.0.1+dfsg1-3+b2

Just was hit by

https://github.com/containers/podman/issues/3759

in bullseye.

Podman was generating "Error adding network: failed to allocate for 
range 0..." errors and containers were not starting.


Manually creating /usr/lib/tmpfiles.d/podman.conf from 
libpod-3.0.1+dfsg1/contrib/tmpfile/podman.conf and rebooting resolved 
the issue.


Please verify and cosider adding /usr/lib/tmpfiles.d/podman.conf to package.

--
Regards,
Paweł Bogusławski

IB Development Team
E: d...@ib.pl

Bug#994486: cryptsetup-initramfs: include askpass only when needed?

[Christoph Anton Mitterer]

On Sat, 2021-10-02 at 22:39 +0200, Guilhem Moulin wrote:
> What does “would be nice” means concretely, is there anything else
> than
> the slightly smaller initramfs image?

Well I guess there are mainly two beneficial points, IMO:

1) The actually saved space.
Sure it's not extremely much, but if everyone thinks that way all that
bits and pieces add up to quite something, which are of course no
problem for a normal desktop system, but embedded systems may really
want/need something that stays small.
So if we can't to something to improve it, why not?


2) Is that the problem you refer to (i.e. not knowing what already
silently depends on this) gets just worse and worse.
I recently learned that e.g. sed is not included per se, but only
because cryptroot does it and I always had cryptroot in place.

I think people shouldn't get too sloppy an just assume that whatever
they need will be in place in the initramfs, unless someone really made
such promise.
And I guess the only really proper promise is that klibc-utils stuff is
there.
busybox stuff is also just there because cryptsetup itself needs it and
sets BUSYBOX=Y, but if that should ever change, we shouldn't trap and
force ourself to include it forever, just because someone who doesn’t
include his own deps relies on it.



> Personally I'm not against doing
> what you propose, but the gain has to outweigh potential regressions
> and at the moment this is not obvious to me.

I think the possible regressions are that any keyscripts who silently
dependent on askpass without caring to include it themselves will fail.

This sounds like a big regression at first, but:
- it would only happen to people with custom keyscripts

- a NEWS.Debian entry could tell about it, anyone not reading this is
IMO on his own

- anyone who run a FDE system, and doesn't keep backups of e.g. the
most recent working kernel/initramfs... well, same as above,... on his
own...
I once had the case that I depended on some fs kernel module to read
the key and it used to be included in dep but then no longer... I
didn't care to properly include it myself, so I got stuck (of course I
had the previously working initramfs)... but I couldn't blame whoever
removed that module from the included ones

- Having askpass included was never "promised"... in a way it's the
same when I personally used some internal features back then before I
reported #901795, and you guys changed it... it was my own
responsibility if I use undocumented stuff.

It's like you say in the other bugs... people cannot rely on non-
documented features, and you're right there - otherwise you could
barely make any changes.



Cheers,
Chris.

Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Holger Wansing]

Hi,

I'm thinking about (long overdue) updating chapter 
https://d-i.debian.org/doc/installation-guide/en.amd64/ch04s03.html
"Preparing Files for USB Memory Stick Booting".


Additionally to the issues mentioned in related bugreports
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604839
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988472
I had some understanding issues, mostly in chapter
"Manually copying files to the USB stick — the flexible way"


Therefore, I would welcome some help/review, to make sure I got everything
right.
I have prepared a patch (attached).

I have already tested everything documented in this chapter so far, and it works
(at least for me) as documented in my patched version, so it doesn't look that 
bad IMO, but double-checking might be good.

Notes:
- I would not call files like vmlinuz or initrd.gz an "image" (to not be
  confused with the installation ISO images); so I changed such occurrences
  into "files".
- I have fixed missing content/commands on several places.
- #988472 proposes to no longer use "install-mbr" to install an MBR on the
  stick, but use 'cat /usr/lib/syslinux/mbr.bin >/dev/sdX' instead.
  Any objections or comments on this?
  (Works fine for me so far.)
- Because a long time has passed by since the last overhaul of this chapter,
  maybe there is some more, that could be changed, for example because of
  changed/new technology or experience?


If someone wants to read a complete html page, instead of the patch, I have
uploaded my version to https://people.debian.org/~holgerw/
(Reading the html might be easier; I have swapped some sentences around, to
get a better understandable and intuitive order. 
That makes the diff a lot more complex.)
See
https://people.debian.org/~holgerw/installation-guide_2021-10-02/amd64/ch04s03.html
or
https://people.debian.org/~holgerw/installation-guide_2021-10-02/arm64/ch04s03.html


Thanks a lot

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/en/install-methods/boot-usb-files.xml b/en/install-methods/boot-usb-files.xml
index 64aeb0aff..f1d61392b 100644
--- a/en/install-methods/boot-usb-files.xml
+++ b/en/install-methods/boot-usb-files.xml
@@ -23,23 +23,25 @@ The procedures described in this section will destroy anything already
 on the device! Make very sure that you use the correct device name for
 your USB stick. If you use the wrong device the result could be that all
 information on for example a hard disk could be lost.
 
 
 
   
   Preparing a USB stick using a hybrid CD/DVD image
 
 
-Debian installation images can now be written directly to a USB stick,
-which is a very easy way to make a bootable USB stick. Simply choose
-an image (such as the netinst, CD, DVD-1, or netboot) that will fit
+Debian installation images for this architecture are created using the
+isohybrid technology;
+that means they can be written directly to a USB stick,
+which is a very easy way to make an installation media. Simply choose
+an image (such as the netinst, CD or DVD-1) that will fit
 on your USB stick. See
  to get an installation image.
 
 
 
 Alternatively, 
 for very small USB sticks, only a few megabytes in size, you can download
 the  image from the netboot
 directory (at the location mentioned in ).
 
@@ -75,73 +77,79 @@ people with specialised needs.
 
 
 The hybrid image on the stick does not occupy all the storage space, so
 it may be worth considering using the free space to hold firmware files
 or packages or any other files of your choice. This could be useful if
 you have only one stick or just want to keep everything you need on one
 device.
 
 
 
-Create a second, FAT partition on the stick, mount the partition
-and copy or unpack the firmware onto it. For example:
+To do so, use cfdisk or any other partitioning tool to create an additional
+partition on the stick. Then create a (FAT) filesystem on the partition,
+mount it and copy or unpack the firmware onto it, for example with:
 
 
-# mount /dev/sdX2 /mnt
+# mkdosfs -n FIRMWARE /dev/sdX3
+# mount /dev/sdX3 /mnt
 # cd /mnt
 # tar zxvf /path/to/firmware.tar.gz
 # cd /
 # umount /mnt
 
 
-
+Take care that you use the correct device name for your USB stick. The
+mkdosfs command is contained in the
+dosfstools  package.
 
-You might have written the mini.iso to the USB
-stick. In this case the second partition doesn't have to be created as,
-very nicely, it will already be present. Unplugging and replugging the
+
+
+If you have chosen the mini.iso to be written the USB
+stick, the second partition doesn't have to be created, as -
+very nice - it will already be present. Unplugging and replugging the
 USB stick should make the two partitions visible.
 
-
+
 
 
 
   
 
   
   Manually copying files to the USB stick
 
 
 An alternative way to set up your USB stick is to manually copy
 the installer files, and also an installation image to it.
 Note that the USB stick should be at least 1 GB in size (smaller

Bug#967990: FTBFS for real now

[Adam Borowski]

Control: tags -1 +ftbfs
Control: severity -1 serious

Bookworm has glibc 2.32, thus this fail happens in unstable and testing.

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ How to exploit the Bible for weight loss:
⢿⡄⠘⠷⠚⠋⠀ Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
⠈⠳⣄

Bug#967987: FTBFS for real now

[Adam Borowski]

Control: tags -1 +ftbfs
Control: severity -1 serious

Bookworm has glibc 2.32, thus this fail happens in unstable and testing.

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Yo momma uses IPv4!
⢿⡄⠘⠷⠚⠋⠀ But why should you?
⠈⠳⣄ https://ipv4flagday.net/

Bug#995599: libopenmpi3: segfault in mca_btl_vader.so on 32-bit arches

[Drew Parsons]

Package: libopenmpi3
Version: 4.1.2~rc1-4
Severity: important
Control: affects -1 src:fenics-dolfinx

fenics-dolfinx FTBFS on 32-bit arches, i386, armel, armhf, see
https://buildd.debian.org/status/package.php?p=fenics-dolfinx=experimental
https://buildd.debian.org/status/fetch.php?pkg=fenics-dolfinx=i386=1%3A0.3.0-3=1633022115=0

(ignore the 2021-10-02 failed builds using libhdf5-mpi-dev
1.10.7+repack-2, they need libcurl-dev, i.e. libcurl4-openssl-dev, see
Bug##995594 )

The symptom in dolfinx build logs is
  signal number 11 SEGV: Segmentation Violation, probably memory access out of 
range
when running demo_poisson_mpi_2

PETSc suggests running with -start_in_debugger. When I do that on i386
porterbox and run demo_poisson manually with 2 processes, it gives a
more detailed backtrace:

(experimental_i386-dchroot)barriere$ mpiexec -n 2 ./demo_poisson 
-start_in_debugger 
PETSC: Attaching gdb to ./demo_poisson of pid 5638 on display :0.0 on machine 
barriere
PETSC: Attaching gdb to ./demo_poisson of pid 5639 on display :0.0 on machine 
barriere
Unable to start debugger in xterm: No such file or directory
Unable to start debugger in xterm: No such file or directory
[0]PETSC ERROR: 

[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably 
memory access out of range
[0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
[0]PETSC ERROR: or see 
https://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
[0]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to 
find memory corruption errors
[0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run 
[0]PETSC ERROR: to get more information on the crash.
[0]PETSC ERROR: PetscAbortErrorHandler: User provided function() line 0 in  
unknown file (null)
  To prevent termination, change the error handler using PetscPushErrorHandler()
[barriere:05638] *** Process received signal ***
[barriere:05638] Signal: Aborted (6)
[barriere:05638] Signal code:  (-6)
[barriere:05638] [ 0] linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xf7f32090]
[barriere:05638] [ 1] linux-gate.so.1(__kernel_vsyscall+0x9)[0xf7f32069]
[barriere:05638] [ 2] /lib/i386-linux-gnu/libc.so.6(gsignal+0xc6)[0xf5f00f36]
[barriere:05638] [ 3] /lib/i386-linux-gnu/libc.so.6(abort+0x125)[0xf5ee9312]
[barriere:05638] [ 4] 
/usr/lib/petscdir/petsc3.14/i386-linux-gnu-real/lib/libpetsc_real.so.3.14(+0x153d26)[0xf653dd26]
[barriere:05638] [ 5] 
/usr/lib/petscdir/petsc3.14/i386-linux-gnu-real/lib/libpetsc_real.so.3.14(PetscError+0xd0)[0xf653a3b0]
[barriere:05638] [ 6] 
/usr/lib/petscdir/petsc3.14/i386-linux-gnu-real/lib/libpetsc_real.so.3.14(PetscSignalHandlerDefault+0x1a0)[0xf653e790]
[barriere:05638] [ 7] 
/usr/lib/petscdir/petsc3.14/i386-linux-gnu-real/lib/libpetsc_real.so.3.14(+0x154979)[0xf653e979]
[barriere:05638] [ 8] linux-gate.so.1(__kernel_sigreturn+0x0)[0xf7f32080]
[barriere:05638] [ 9] 
/fenics/fenics-dolfinx-0.3.0/debian/tmp-real/usr/lib/i386-linux-gnu/libdolfinx_real.so.0.3(_ZN7dolfinx4mesh16build_dual_graphEP19ompi_communicator_tRKNS_5graph13AdjacencyListIxEEi+0xd7f)[0xf7ead68f]
[barriere:05638] [10] 
/fenics/fenics-dolfinx-0.3.0/debian/tmp-real/usr/lib/i386-linux-gnu/libdolfinx_real.so.0.3(_ZN7dolfinx4mesh21partition_cells_graphEP19ompi_communicator_tiiRKNS_5graph13AdjacencyListIxEENS0_9GhostModeERKSt8functionIFNS4_IiEES2_iS7_ibEE+0x21d)[0xf7ebeb9d]
[barriere:05638] [11] 
/fenics/fenics-dolfinx-0.3.0/debian/tmp-real/usr/lib/i386-linux-gnu/libdolfinx_real.so.0.3(_ZN7dolfinx4mesh21partition_cells_graphEP19ompi_communicator_tiiRKNS_5graph13AdjacencyListIxEENS0_9GhostModeE+0x59)[0xf7ebece9]
[barriere:05638] [12] 
/fenics/fenics-dolfinx-0.3.0/debian/tmp-real/usr/lib/i386-linux-gnu/libdolfinx_real.so.0.3(_ZNSt17_Function_handlerIFKN7dolfinx5graph13AdjacencyListIiEEP19ompi_communicator_tiiRKNS2_IxEENS0_4mesh9GhostModeEEPFS3_S6_iiS9_SB_EE9_M_invokeERKSt9_Any_dataOS6_OiSK_S9_OSB_+0x35)[0xf7dff8b5]
[barriere:05638] [13] 
/fenics/fenics-dolfinx-0.3.0/debian/tmp-real/usr/lib/i386-linux-gnu/libdolfinx_real.so.0.3(_ZN7dolfinx4mesh11create_meshEP19ompi_communicator_tRKNS_5graph13AdjacencyListIxEERKNS_3fem17CoordinateElementERKN2xt17xtensor_containerINSC_7uvectorIdSaIdEEELj2ELNSC_11layout_typeE1ENSC_22xtensor_expression_tagEEENS0_9GhostModeERKSt8functionIFKNS4_IiEES2_iiS7_SM_EE+0x163)[0xf7e96d63]
[barriere:05638] [14] 
/fenics/fenics-dolfinx-0.3.0/debian/tmp-real/usr/lib/i386-linux-gnu/libdolfinx_real.so.0.3(+0x10fdab)[0xf7dfedab]
[barriere:05638] [15] 
/fenics/fenics-dolfinx-0.3.0/debian/tmp-real/usr/lib/i386-linux-gnu/libdolfinx_real.so.0.3(_ZN7dolfinx10generation13RectangleMesh6createEP19ompi_communicator_tRKSt5arrayIS4_IdLj3EELj2EES4_IjLj2EENS_4mesh8CellTypeENSA_9GhostModeERKSt8functionIFKNS_5graph13AdjacencyListIiEES3_iiRKNSF_IxEESC_EERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0xb8)[0xf7dff7c8]
[barriere:05638] [16] 

Bug#967988: FTBFS for real now

[Adam Borowski]

Control: severity -1 serious
Control: tags -1 +ftbfs

We have glibc 2.32 in bookworm already, the package fails to build.

-- 
⢀⣴⠾⠻⢶⣦⠀ < thunder> perhaps we can just call rude people "attitudinally
⣾⠁⢠⠒⠀⣿⡁challenged", designate them as disabled, and then
⢿⡄⠘⠷⠚⠋⠀object to any criticism towards them on the basis
⠈⠳⣄that it would violate the CoC...

Bug#995597: FTBFS: error: format not a string literal and no format arguments

[Adam Borowski]

Source: bsdgames
Version: 2.17-28
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid that your package fails to build:

canfield/canfield/canfield.c: In function ‘instruct’:
canfield/canfield/canfield.c:1650:3: error: format not a string literal and no 
format arguments [-Werror=format-security]
 1650 |   printw(*cp);
  |   ^~
canfield/canfield/canfield.c:1663:3: error: format not a string literal and no 
format arguments [-Werror=format-security]
 1663 |   printw(*cp);
  |   ^~

The obvious fix is to either add "%s" or use a function that doesn't do 
formatting.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-rc2-00041-g794e5d9c562d (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#994914: 994914: status update

[Thomas Goirand]

On 10/1/21 9:43 AM, Andrius Merkys wrote:
> Hello,
> 
> I have managed to update the package and get build time tests passing in
> a fork of its repository [1]. However, to update python-autobahn I need
> a newer version of python-cryptography, opened #995431 for that.
> 
> [1] https://salsa.debian.org/merkys/python-autobahn
> 
> Andrius

Hi,

Thanks, both for the fork and the bug on python-cryptography. I'll have
a look. However, cryptography isn't the only module that will need to be
updated. I started to work on these updates already. It really is on my
todo list, so please be patient and allow me the time to do things properly.

Cheers,

Thomas Goirand (zigo)

Bug#995596: xorg-server: /dev/dri/card0 fd leak switching VTs, leads to lockup

[Spiky Caterpillar]

Source: xorg-server
Version: 2:1.20.11-1
Severity: normal
Tags: patch
X-Debbugs-Cc: spikycaterpillar_debian...@deekoo.net

Dear Maintainer,

The X server repeatedly opens /dev/dri/card0 on VT switch, but doesn't
close it. Eventually this leads to FD exhaustion and a wedged X server.

To replicate:
Login on a console
startx
start an xterm
lsof -n|grep -c /dev/dri/card0
control-alt-functionkey to change to another vt
control-alt-functionkey to change back to X
lsof -n|grep -c /dev/dri/card0


The patch I'm using at the moment:

### BEGIN PATCH ###
diff --git a/hw/xfree86/os-support/linux/systemd-logind.c 
b/hw/xfree86/os-support/linux/systemd-logind.c
index 13784d1..9f196ef 100644
--- a/hw/xfree86/os-support/linux/systemd-logind.c
+++ b/hw/xfree86/os-support/linux/systemd-logind.c
@@ -417,9 +417,10 @@ message_filter(DBusConnection * connection, DBusMessage * 
message, void *data)
 /* info->vt_active gets set by systemd_logind_vtenter() */
 info->active = TRUE;
 
-if (pdev)
+if (pdev) {
+close(fd);
 pdev->flags &= ~XF86_PDEV_PAUSED;
-else
+} else
 systemd_logind_set_input_fd_for_all_devs(major, minor, fd,
  info->vt_active);
### END PATCH ###

I do not know if the bug applies to the latest upstream version of X,
though the patch does apply.


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

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

Bug#995463: geeqie: doesn't save preferences

[Emilian Nowak]

On 2021-10-02, at 15:40:55 Andreas Ronnquist wrote:

> Thanks for your report - as you can see I have forwarded the bug to
> upstream, 
Thanks :-)

> and they claim it is intended for the print mechanism, which
> is redundant when using the standard GTK method for printing.
> 
> So, if I interpret upstream correctly, they will probably remove the
> option. 
Sad thing :/

> I guess it is only this specific option that doesn't stick, and not any
> others?
> 
> Please report back if other options doesn't stick for you (I can
> reproduce it for this one).
Only this one, I didn't notice any other.


-- 
Regards.

Bug#995594: libhdf5[-openmpi]-dev: missing Depends: libcurl-dev

[Drew Parsons]

Package: libhdf5-openmpi-dev
Version: 1.10.7+repack-2
Severity: serious
Justification: FTBFS
Control: affects -1 src:fenics-dolfinx

The hdf5 compiler wrappers declare -lcurl as a linked library
e.g. 
$ h5cc -showconfig | grep curl
Extra libraries: -lcrypto -lcurl -lpthread -lsz -lz -ldl -lm 
$ h5pcc -showconfig | grep curl
Extra libraries: -lcrypto -lcurl -lsz -lz -ldl -lm 


But libcurl-dev is not declared as a Dependency for libhdf5-openmpi-dev.
This means that compiling with h5pcc (or h5cc) fails unless [a]
libcurl-dev is installed.

This affects client packages using cmake that check HDF5
configuration using find_package(hdf5),
e.g. a trivial sample CMakeLists.txt

--
project(TEST_hdf5)

set(HDF5_PREFER_PARALLEL TRUE)
find_package(HDF5 REQUIRED COMPONENTS C)
--

gives the result,

  -- HDF5 C compiler wrapper is unable to compile a minimal HDF5 program.
  CMake Error at 
/usr/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS C) (found
version "")


A current example is the broken build of fenics-dolfinx on i386,
https://buildd.debian.org/status/fetch.php?pkg=fenics-dolfinx=i386=1%3A0.3.0-3=1633198410=0


cmake is desparately opaque, but with enough sweat and tears
(ultimately, by compiling the cmake hdf5 test file manually with
h5pcc) one can eventually discover that the problem is the -lcurl flag
in h5pcc,

  CMakeFiles/hdf5$ h5pcc cmake_hdf5_test.c
  /usr/bin/ld: cannot find -lcurl



I'm filing this bug against libhdf5-openmpi-dev, providing h5pcc, 
since I want to use hdf5-mpi, but the problem also affects libhdf5-dev
(providing h5cc).

Since h5pcc and h5cc invoke -lcurl, libhdf5-openmpi-dev, libhdf5-dev (and
probably libhdf5-mpich-dev also) should declare Depends: libcurl-dev

Finally, since libcurl-dev is virtual, the actual declaration should be
(following hdf5's Build-Depends)

  Depends: libcurl4-openssl-dev

or possibly Depends: libcurl4-openssl-dev | libcurl-dev
(the libcurl variants seem to be interchangeable)


Why h5cc needs -lcurl is a separate question! What is it trying to
download?


Drew


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

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

Versions of packages libhdf5-openmpi-dev depends on:
ii  libaec-dev 1.0.6-1
ii  libhdf5-openmpi-103-1  1.10.7+repack-2
ii  libhdf5-openmpi-cpp-103-1  1.10.7+repack-2
ii  libhdf5-openmpi-fortran-1021.10.7+repack-2
ii  libhdf5-openmpi-hl-100 1.10.7+repack-2
ii  libhdf5-openmpi-hl-cpp-100 1.10.7+repack-2
ii  libhdf5-openmpi-hl-fortran-100 1.10.7+repack-2
ii  libjpeg-dev1:2.0.6-4
ii  libjpeg62-turbo-dev [libjpeg-dev]  1:2.0.6-4
ii  libopenmpi-dev 4.1.2~rc1-4
ii  zlib1g-dev 1:1.2.11.dfsg-2

libhdf5-openmpi-dev recommends no packages.

Versions of packages libhdf5-openmpi-dev suggests:
pn  libhdf5-doc  

-- no debconf information

Bug#995122: LLVM change

[Raul Tambre]

An upstream Clang change () has been merged to 
make symlinking /usr/lib/cuda/include to /usr/include work.


The shim header approach would still have the benefit of being smaller and thus 
Clang being able to parse the version from it faster.

Bug#994486: cryptsetup-initramfs: include askpass only when needed?

[Guilhem Moulin]

Hi,

On Thu, 16 Sep 2021 at 17:41:17 +0200, Christoph Anton Mitterer wrote:
> I think it would be nice if askpass was only included when actually
> needed.

What does “would be nice” means concretely, is there anything else than
the slightly smaller initramfs image?  Personally I'm not against doing
what you propose, but the gain has to outweigh potential regressions
and at the moment this is not obvious to me.

/lib/cryptsetup/askpass is 18kiB and, from a minimal sid VM, removing it
from an initramfs image created with default settings (MODULES=most,
COMPRESS=gzip) reduces its size by only 0.019% (37342kiB → 37335kiB);
doing the same with space-saving settings (MODULES=dep, COMPRESS=xz)
gives a 0.026% gain (7646kiB → 7644kiB).

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#995410: breezy: FTBFS:

[Jelmer Vernooij]

Hi Steve,

On Thu, Sep 30, 2021 at 12:21:53PM -0700, Steve Langasek wrote:
> While tracking a build failure of breezy 3.2.1 in Ubuntu, I found that it is
> currently also reproducible in Debian unstable:

Thanks for the bug report.

> [...]
> ==
> ERROR: 
> breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)
> --
> Traceback (most recent call last):
> testtools.testresult.real._StringException: log: {{{
> 763.552  creating repository in 
> file:///tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path%28WorkingTreeFormat4%29/work/tree/.bzr/.
> 763.553  creating branch  0x7f323de98100> in 
> file:///tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path%28WorkingTreeFormat4%29/work/tree/
> 763.558  trying to create missing lock 
> '/tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)/work/tree/.bzr/checkout/dirstate'
> 763.558  opening working tree 
> '/tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)/work/tree'
> }}}
> 
> Traceback (most recent call last):
>   File "/tmp/breezy-3.2.1/breezy/tests/per_workingtree/test_workingtree.py", 
> line 1253, in test_bad_fs_path
> with open(b'tree/subdir/m\xb5', 'wb') as f:
> OSError: [Errno 84] Invalid or incomplete multibyte or wide character: 
> b'tree/subdir/m\xb5'

This looks like a behaviour change on the Python side; it should be
possible to use bytestrings for paths on Linux without those being
valid in the current locale..

> [...]
> ==
> ERROR: 
> breezy.tests.test_plugins.TestPlugins.test_1_2_3__version__with_version_info
> --
> Traceback (most recent call last):
> testtools.testresult.real._StringException: log: {{{
> 853.935  loading plugins!
> 853.935  using _Path('breezy.testingplugins', [], [], ['.'])
> 853.935  Traceback (most recent call last):
>   File "/tmp/breezy-3.2.1/breezy/plugin.py", line 429, in _load_plugin_module
> __import__(_MODULE_PREFIX + name)
> ModuleNotFoundError: No module named 'breezy.testingplugins.plugin'
> 
> 853.935  Unable to load plugin 'plugin' from '.': No module named 
> 'breezy.testingplugins.plugin'
>  WARNING  Unable to load plugin 'plugin' from '.': No module named 
> 'breezy.testingplugins.plugin'
> 853.936  removed breezy.testingplugins from sys.modules
> }}}
> 
> Traceback (most recent call last):
>   File "/tmp/breezy-3.2.1/breezy/tests/test_plugins.py", line 468, in 
> test_1_2_3__version__with_version_info
> plugin = breezy.plugin.plugins()['plugin']
> KeyError: 'plugin'
> 
> [...]
> 
> (There are multiple errors of these two classes in the log, but this seems to
> be the gist of it.)

I've seen one earlier reference to this error - I think it had to do
with a regression introduced by a new version of Python.

Cc'ing Martin, who has more background on the plugin code.

Cheers,

Jelmer

Bug#994822: confirmed and exploring alternate binary names

[Federico Grau]

Thank you Andreas for the notice.  The bug has been confirmed and we're
exploring alternate binary names.  

donfede

Control: tags -1 + confirmed



signature.asc
Description: PGP signature

Bug#994910: tripwire segfaults while reading files in /etc

[Christoph Kling]

Package: tripwire
Version: 2.4.3.7-3+b3
Followup-For: Bug #994910

Hi,

Same problem here. My strace also shows that opening /etc/nsswitch.conf was the
last before segfault. The package is completely useless. The only thing I can
still run is tripwire --help, but any tripwire -m operation fails.

Best,
Christoph


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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tripwire depends on:
ii  debconf [debconf-2.0]   1.5.77
ii  postfix [mail-transport-agent]  3.5.6-1+b1

tripwire recommends no packages.

tripwire suggests no packages.

-- Configuration Files:
/etc/cron.daily/tripwire [Errno 2] No such file or directory: 
'/etc/cron.daily/tripwire'
/etc/tripwire/twpol.txt changed [not included]

-- debconf information:
* tripwire/site-passphrase-again: (password omitted)
* tripwire/site-passphrase: (password omitted)
* tripwire/local-passphrase-again: (password omitted)
* tripwire/local-passphrase: (password omitted)
  tripwire/change-in-default-policy:
* tripwire/use-localkey: true
  tripwire/upgrade: true
  tripwire/email-report:
  tripwire/broken-passphrase:
* tripwire/use-sitekey: true
* tripwire/installed:
* tripwire/rebuild-policy: true
  tripwire/local-passphrase-incorrect: false
* tripwire/rebuild-config: true
* tripwire/site-passphrase-incorrect: true

Bug#995593: HTML sanitizing in 6.4-6.4.3 breaks user styling

[Thomas Viehmann]

Package: jupyter-notebook
Version: 6.4.3
Severity: important
Tags: fixed-upstream

Hello,

thank you for maintaining Jupyter Notebook, I am using it every day!
With the upgrade to 6.4, the Jupyter Notebook html sanitizing got overly 
strict and throws out all style formatting[1].


This is quite bad people relying on styles in essential ways lose the 
ability to render their notebooks (eg many of my notebooks crucially set 
image widths with the style attribute and are unreadable now).
The good news is that upstream has fixed it in 6.4.4. I would much 
appreciate if I could get the upgrade from Debian.


Thank you again for doing the hard work of packaging Jupyter!

Best regards

Thomas

1: https://github.com/jupyter/notebook/issues/6172

Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing

[Hannah Rittich]

Hi Nicholas,
hi Alexandre,

Am 27.09.21 um 03:27 schrieb Nicholas D Steeves:
> By the way, is this your first Debian contribution?  If so, welcome! :-)

It is, indeed, besides some bug reports. Thank you.

> So option #1 is patching the library, and not using a different package
> name at the dpkg level.  I wonder about namespacing the dependencies'
> names at the dpkg level, without patching the library?  Eg:
> src:marchus-cpp-utilities (which generates
> bin:marchus-libc++utilities5).  What do you think?  I think this would
> be less confusing to users/devs, and I feel like it's likely that there
> will be a cpp-utilities from glibc or LLVM somewhere in the future.
> What I mean by "confusing" is I really don't think that it's appropriate
> for a helper library to grab such an authoritative name, except in
> Flatpaks, and such containerised packages, of course! ;-)  If #3 ever
> becomes a real issue, I hope that our popcon stats will help convince
> upstream to DTRT.

So. I managed to get the configuration name feature that the upstream
author mentioned in the GitHub issue to work. It is possible to add
arbitrary suffixes to the library name, the include directories and the
CMake config files. This should avoid any name conflicts. The sources
are on Salsa.

I think a prefix would be nicer, and I think it should not be too hard
to add configuration name prefix switch. I would like to check if this
is a feasible option. In case it is not too much work and the upstream
author is willing to merge those changes, we could get a proper prefix
to the package name. Otherwise, I would suggest to stick with a suffix
for ease of maintenance.

> Wow!  Yes, I will definitely sponsor your work :-)  How do you feel
> about comaintaining these packages in the "debian" group (used to be
> called collab-maint)?

I am happy to share the responsibility with a team. Would that mean any
additional obligations for me?

> Syncthing for Debian tends to lag behind upstream, and we'll need to 
> ignore or remove the embedded copy of libsyncthing in Syncthing
> Tray. In terms of long-term maintenance it looks like Syncthing Tray
> updates will need to block for Syncthing (and its new deps) uploads.
> I forget if I uploaded the packages or not, but at some point I
> worked on packaging new Golang deps for Syncthing, and it wasn't as
> difficult as I had expected.  I'll wait for Alexandre's ACK before
> asking you if you're also interested in Golang packaging ;-)

I am a bit confused here. I though libsyncthing is a part of Syncthing
Tray. I could not find the sources anywhere else. Are they actually part
of some other package? Where do I find the sources?

> Your work looks excellent, and I don't expect to find any issues, but
> I'll need to take time to carefully examine everything, do some QA
> tests, and make sure the paperwork-type stuff is all in order.  Also,
> we don't need to wait to unbundle libsyncthing before uploading
> cpp-utilities and qtutilities (ideally prefixed with 'martchus-' at
> the dpkg level), and those packages will need to migrate through the
> NEW queue before Syncthing Tray can be uploaded.
As I have mentioned above. I'll try to brush up the package with respect
to the naming. I'll keep you updated.

Regards,

Hannah

Bug#995341: Highly inappropriate behavior which the RT should be aware of

[Chuck Zmudzinski]

On 10/1/2021 5:48 AM, Diederik de Haas wrote:

Hi Release Team,

I want to make sure that you're aware of what I consider HIGHLY inappropriate
behavior by Chuck where he is trying to sidestep/override the Xen maintainers
by filing this bug directly to the release.debian.org pseudo package.

This only appeared on the Debian Xen maintainers' ML because Chuck went on a
severity-dance where he *also* changed the severity of bug #994899, which _is_
assigned to the Xen package and therefor the Xen maintainers could see it.

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899#10 I tried to
steer the efforts to getting the issue fixed in a more constructive manner.
I failed at that.

We've already identified a possible fix, which I can point to if so desired, but
I don't think the RT should be bothered with this (dispute).


I respectfully disagree, because as I have mentioned repeatedly both
in this report and in #994899 that the process of migrating the
stable package of the xen hypervisor for amd64 broke because when
bullseye was released on August, 14, 2021, that package still contained
patches from the unstable upstream Xen 4.16 branch, whereas the
version advertised by Debian for the stable release was, and still
is, the stable upstream of Xen, version 4.14.


It may be news to Chuck, but not the RT, but a package maintainer has the
prerogative to include additional patches in the package that gets uploaded to
the Debian archive. (It happens all the time)
And that can introduce bugs. Shit happens. You learn from that. And then you
go on fixing those bugs *in coordination with* the package maintainers.


Perhaps it may be news to Diederik that the Release Team does have
the prerogative to review and either accept or reject a series of
patches from an unstable upstream branch into the stable release
and respond to a request from a user/volunteer to review such
patches that obviously can and in fact did cause bug #994899 in
this case.

It may have just been an oversight, but in this case, IMO, the package
maintainers *should* have notified the release team of the unstable
patches from Xen 4.16 that were in the supposedly stable 4.14 xen
hypervisor package for amd64 sometime BEFORE bullseye was released
as the new stable version on August 14, 2021, so the Release Team
could decide if the unstable patches could stay in the formal release of
bullseye. IMHO, it is up to the Release Team, not the package maintainers,
to decide if Debian specific patches from an UNSTABLE upstream branch can
remain in a package of the STABLE upstream version at the time of the stable
release. The package maintainers never gave the Release Team a chance to
review the upstream unstable patches before bullseye was released.

It is also for the Release Team, not the package maintainers, to
decide if those unstable patches can remain after a user/volunteer
requests that they be removed as the appropriate way to fix a bug
in the stable release that is caused by the presence of the unstable
patches in the stable release.

I would be much less inclined to request that the Release Team review
the unstable patches that are causing #994899 if there was some
evidence that upstream plans to eventually backport those patches from
Xen 4.16 to Xen 4.14. At present no such evidence exists, and perhaps
a way to resolve this controversy is for Debian to submit a pull
request to the Xen project to merge the unstable patches in Debian's
current Xen 4.14 packages into Xen's stable Xen 4.14 branch. If upstream
endorses the unstable patches as suitable for their 4.14 stable release and
eventully commits them to their 4.14 branch and subsequent upstream
point releases, then I would also accept them as appropriate for the Debian
package of the upstream stable 4.14 version of Xen that targets the stable
version, currently bullseye.

Regards,

Chuck Zmudzinski



What you don't do, is try to go above/around them by addressing the RT
directly.
One should have at least the decency to directly To/CC the package maintainer
when you do, which in 99.99+% of cases you REALLY should not do.

Regards,
   Diederik

Bug#994273: Example

[Jeremy Sowden]

Can you provide an example?

For instance, if I have the following rule-set:

  $ sudo nft list ruleset
  table ip filter {
  counter c {
  packets 85081 bytes 125160849
  }

  quota q {
  1048576 mbytes used 125160849 bytes
  }

  chain input {
  type filter hook input priority filter; policy accept;
  counter name "c"
  counter packets 85083 bytes 125160851
  quota name "q"
  quota 1048576 mbytes used 125160849 bytes
  }
  }

With the `-s` flag, I get the following:

  $ sudo nft -s list ruleset
  table ip filter {
  counter c {
  packets 0 bytes 0   }

  quota q {
  1048576 mbytes
  }

  chain input {
  type filter hook input priority filter; policy accept;
  counter name "c"
  counter
  quota name "q"
  quota 1048576 mbytes
  }
  }

The state for named quotas and counter and quota rules are suppressed,
and the state for named counters is replaced with zeroes.

J.


signature.asc
Description: PGP signature

Bug#995590: RM: peframe -- RoQA; Depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove peframe, it depends on Python 2 and current versions
are blocked by licence and dependency issues. Acked by the maintainer
in #937269.

Cheers,
 Moritz

Bug#995589: xdg-utils: xdg-open: Fails to interpret 'man:' URIs

[Alejandro Colomar]

Package: xdg-utils
Version: 1.1.3-4.1
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear Maintainer,

   * What led up to the situation?

Discussing about adding a feature to groff, to add 'clickable' links
(see ),
and reading uri(7), which states that  and 
are valid URIs, and that any tool accepting URIs should be able to
handle them.

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

I tried to run `open man:less` and `open 'man:less(1)'`, but both failed.

   * What was the outcome of this action?

A pop-up window with the following lines:

Failed to open URI.
The specified location is not supported.
man:less

   * What outcome did you expect instead?

Since (almost?) every system has man(1) installed, I'd expect xdg-open
to be able to handle these URIs by calling man(1).


Thanks,

Alex



-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=XFCE

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

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

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.30-1
ii  libnet-dbus-perl   1.2.0-1+b1
ii  libx11-protocol-perl   0.56-7.1
ii  x11-utils  7.7+5
ii  x11-xserver-utils  7.7+8

xdg-utils suggests no packages.

-- no debconf information

Bug#995588: RFS: rumur/2021.09.29-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2021.09.29-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   Section : devel

It builds those binary packages:

  rumur - model checker for the Murphi language

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2021.09.29-1.dsc

Changes since the last upload:

rumur (2021.09.29-1) unstable; urgency=medium
.
   * New upstream release.
.
   * Update Standards-Version from 4.5.1 to 4.6.0.1.

Regards,
Matt

Bug#995587: transition: ruby3.0-add

[Antonio Terceiro]

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

We would like to add support for ruby3.0 in ruby-defaults.

Ben file:

title = "ruby3.0-add";
is_affected = (.depends ~ /ruby2.7 | .depends ~ /ruby3.0/) & !.source ~ 
/^(ruby2.7|ruby3.0|ruby-defaults)$/);
is_good = .depends ~ /ruby3.0/;
is_bad = .depends ~ /ruby2.7/ & !.depends ~ /ruby3.0/;

We already did a mass rebuild some time ago, and the results don't look
bad. We should be doing a new one soon, and will come up with a list of
binNMUs


signature.asc
Description: PGP signature

Bug#994870: [Pkg-xen-devel] Bug#994870: Bug#994870: Bug#994870: Memory allocation problem for VM after xen security update

[Alexander Dahl]

Hei hei,

On Thu, Sep 30, 2021 at 01:13:54PM +0200, Hans van Kranenburg wrote:
> Hi!
> 
> On 9/30/21 12:45 AM, Andy Smith wrote:
> > Hi Alex,
> > 
> > On Thu, Sep 30, 2021 at 12:10:32AM +0200, Alexander Dahl wrote:
> >> Am 22.09.21 um 20:54 schrieb Hans van Kranenburg:
> >>> At this point I would really recommend to not wait for a fix to arrive
> >>> which makes it start again, but change your VM to use a 64-bit kernel.
> >>
> >> How?
> > 
> > This was answered in earlier comments on this bug; please see:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994870#15
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994870#20
> > 
> > The brief summary is, "start out like a crossgrade, but only do the
> > kernel". Very simple and quite safe.
> > 
> > You haven't said how you boot your guest though (show us your
> > /etc/xen/guest.cfg file). If it's pvgrub, that has a 32-bit and a
> > 64-bit version so you'll need to change those as well. If it's
> > pygrub you probably don't need to do anything, though pygrub has its
> > own issues outside the scope of this bug.
> > 
> >> FWIW, Debian 10 VMs with 32 bit running with PVH work fine. My important VM
> >> is still Debian 9 however due to a software I can not simply upgrade.
> > 
> > I've found PVH needs at least 4.19 guest kernel to work, which can
> > be achieved in Debian 9 (stretch) today by using kernel from
> > stretch-backports, so perhaps that is an option for you.
> 
> You can certainly do that and then run PVH.

This actually works.  I'm running 4.19 i686 kernel in the stretch VM
now with PVH, at least for the Debian stretch VM (I had to permanently
disable some old OpenWRT VMs, where I get no updates anymore).  Was a
little tricky to install it, because I had to install that kernel
without the vm being able to start, but it worked like this:

- mount the root filesystem of the vm in the host, e.g. to /mnt
- bind mount /dev, /sys to /mnt/dev and /mnt/sys
- mount procfs to /mnt/proc
- mount a tmpfs to /mnt/run and create /run/lock
- chroot into /mnt
- install the needed kernel with apt
- leave chroot, umount the things from above
- change domU config to PVH
- when in grub, edit the cmdline and change root= if it was changed by
  update-grub (might have been changed to the mount point from the
  chroot)
- in the now booted system, run update-grub again

> Since stretch-backports is not used any more since stretch became
> oldoldstable, new 4.19 backports kernels for Stretch are released
> through the security updates channel. Be aware of this.
> 
> https://lists.debian.org/debian-lts-announce/2020/08/msg00019.html
> 
> Latest in stretch-backports (frozen) is 4.19.118, and stretch security
> is now at 4.19.194. So double check you end up following the right one.

Thanks for all your hints. I really have to migrate my virtual
machines. :-/

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
 X  AGAINST  | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)


signature.asc
Description: PGP signature

Bug#995341: Highly inappropriate behavior which the RT should be aware of

[Chuck Zmudzinski]

On 10/1/2021 5:48 AM, Diederik de Haas wrote:

Hi Release Team,

I want to make sure that you're aware of what I consider HIGHLY inappropriate
behavior by Chuck where he is trying to sidestep/override the Xen maintainers
by filing this bug directly to the release.debian.org pseudo package.


I consider it also highly inappropriate for one volunteer to criticize
a newcomer volunteer without at least a Cc to the volunteer he is
criticizing, to give the volunteer under attack an opportunity to
respond and defend herself/himself.



This only appeared on the Debian Xen maintainers' ML because Chuck went on a
severity-dance where he *also* changed the severity of bug #994899, which _is_
assigned to the Xen package and therefor the Xen maintainers could see it.

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899#10 I tried to
steer the efforts to getting the issue fixed in a more constructive manner.
I failed at that.

We've already identified a possible fix, which I can point to if so desired, but
I don't think the RT should be bothered with this (dispute).
It may be news to Chuck, but not the RT, but a package maintainer has the
prerogative to include additional patches in the package that gets uploaded to
the Debian archive. (It happens all the time)
And that can introduce bugs. Shit happens. You learn from that. And then you
go on fixing those bugs *in coordination with* the package maintainers.


I agree package maintainers must have a say. and as far as I can tell the
Release Team has the final say on what goes into the stable release.
I have tried to cooperate with volunteers for the package maintainers,
but they refused to cooperate with me. When volunteers for the
package maintainers are uncooperative and excessively critical and
unfair to a newcomer volunteer, what is a newcomer to do?
Does Debian really consider this the best way to sustain the community
and acquire new developers as veterans move on or quit? IMHO, following
Diederik's approach toward newcomers will result in a slow and painful
death for Debian as competent developers move on and no one is there
to replace them because it is just not worth the personal attacks one
must endure when trying to contribute to Debian.



What you don't do, is try to go above/around them by addressing the RT
directly.
One should have at least the decency to directly To/CC the package maintainer
when you do, which in 99.99+% of cases you REALLY should not do.


One should also have the decency to Cc a person one is criticizing,
something i have done by sending a Cc to the person I am criticizing
(in my defense of his attack on me). Diederik did not have this decency
when he criticized me.

Respectfully,

Chuck Zmudzinski



Regards,
   Diederik

Bug#995124: [Re: error_log say 'E...[cups-driverd] Bad driver information file...' with indexbraille-*.defs files]

[yg2709]

Package: printer-driver-indexbraille
Version: 1.2.3-3
Followup-For: Bug #995124
X-Debbugs-Cc: yg2...@hotmail.com

Dear Maintainer,


After today's update (1.2.3-3), same results at /var/log/error_log:

E [02/Oct/2021:14:36:21 +0200] [cups-driverd] Bad driver information file 
\"/usr/share/cups/drv/indexbraille-filter.defs\"!
E [02/Oct/2021:14:36:21 +0200] [cups-driverd] Bad driver information file 
\"/usr/share/cups/drv/indexbraille-media.defs\"!

The files continue to come with the same path
...
/usr/share/cups/drv/indexbraille-filter.defs
/usr/share/cups/drv/indexbraille-media.defs
/usr/share/cups/drv/indexbraille.drv
...

Doing the same two commands of message #5, those lines disappear in error_log.

Thanks in advance.


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 printer-driver-indexbraille depends on:
ii  libc6  2.32-4

Versions of packages printer-driver-indexbraille recommends:
ii  cups  2.3.3op2-7

printer-driver-indexbraille suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: missing file /usr/share/cups/drv/indexbraille-filter.defs (from 
printer-driver-indexbraille package)
debsums: missing file /usr/share/cups/drv/indexbraille-media.defs (from 
printer-driver-indexbraille package)
debsums: changed file /usr/share/cups/drv/indexbraille.drv (from 
printer-driver-indexbraille package)

Bug#981142: closed by Bastian Germann (Re: RFS: hello/3.1-4 [ITP] -- dayon)

[Fensterkitt Computer Support]

Yes, the links are outdated - more than eight months later..

Am 01.10.21 um 12:51 schrieb Debian Bug Tracking System:

This is an automatic notification regarding your Bug report
which was filed against the sponsorship-requests package:

#981142: RFS: dayon/1.10.3 -- Remote Assistance Service

It has been closed by Bastian Germann .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Bastian Germann 
 by
replying to this email.

Bug#995341: Highly inappropriate behavior which the RT should be aware of

[Diederik de Haas]

On Saturday, 2 October 2021 15:56:33 CEST Chuck Zmudzinski wrote:
> I agree package maintainers must have a say. and as far as I can tell the
> Release Team has the final say on what goes into the stable release.

The reason I responded at all was that AFAIK the RT indeed has the right to 
make such a change. In hindsight I should've only responded like this:
"This action is taken without the knowledge or the consent of the Debian Xen 
package maintainers."

Just like I learned I shouldn't respond (on the internet) before I've had at 
least my first cup of coffee, I've now learned that writing an email while 
angry 
is a similar bad idea.

I will not spend any time responding to the rest of your statements.

Bye.

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

Bug#971783: mate-volume-control-status-icon dies here too

[Mike Gabriel]

Hi Maxime,

On  Mi 22 Sep 2021 14:20:23 CEST, Maxime G. wrote:


Hi.

What's the status of the ticket? Someone to update or push up to the project?

Tx.



Without a patch (either contributed by someone or taken from upstream)  
there is not much a Debian maintainer can do on this. Except from  
digging into the code myself which I am not available for at the  
moment due to ENOTIME (busy with other work).


In second half of Oct I will start preparing uploads of the MATE 1.26  
series. Let's see if that fixes this issue. If yes, then we likely  
have a patch in 1.26.x that can be backported to bullseye's 1.24.x  
version.


Mike
--

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

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



pgpovGvsFmeSX.pgp
Description: Digitale PGP-Signatur

Bug#995125: linux: Realtek ethernet driver r8169 lacks support for chip chip XID 54b

[Wright, Randy (HPE Servers Linux)]

> The upstream commit which appears to add the support is 
> https://git.kernel.org/linus/e6d6ca6e12049dfbff6ac8b029678d2d2c55c34f
> Is this enough?

The nominated patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=e6d6ca6e12049dfbff6ac8b029678d2d2c55c34f
appears from inspection to support the chip 0x54b that I reported.

If your question is whether this patch alone suffices, I found
it will not apply cleanly on the version of 
drivers/net/ethernet/realtek/r8169_main.c 
found in the bullseye 5.10.46 kernel.  I will attach the log from:

debian/bin/test-patches -f amd64 -j 6 
./389cb1ecc86e6c6f210424017cf930a81ddfbf2d..e6d6ca6e12049dfbff6ac8b029678d2d2c55c34f.patch
 

I will attempt to identify a small set of predecessor patches that permit the 
nominated
patch to be installed.

- Randy Wright - rwri...@hpe.comPYTHONHASHSEED=0 debian/bin/gencontrol.py
md5sum debian/bin/gencontrol.py debian/build/version-info 
debian/templates/control.config.in debian/templates/control.docs.in 
debian/templates/control.docs.meta.in debian/templates/control.extra.in 
debian/templates/control.headers.featureset.in 
debian/templates/control.headers.in debian/templates/control.headers.meta.in 
debian/templates/control.image-dbg.in 
debian/templates/control.image-dbg.meta.in debian/templates/control.image.in 
debian/templates/control.image.meta.in 
debian/templates/control.image-unsigned.in debian/templates/control.libc-dev.in 
debian/templates/control.main.in debian/templates/control.signed-template.in 
debian/templates/control.sourcebin.in 
debian/templates/control.sourcebin.meta.in debian/templates/control.source.in 
debian/templates/control.tools-unversioned.in 
debian/templates/control.tools-versioned.in 
debian/templates/control.tools-versioned.meta.in 
debian/templates/docs.meta.maintscript.in 
debian/templates/headers.meta.maintscript.in 
debian/templates/headers.postinst.in 
debian/templates/image-dbg.lintian-overrides.in 
debian/templates/image-dbg.meta.lintian-overrides.in 
debian/templates/image-dbg.meta.maintscript.in 
debian/templates/image.meta.bug-presubj.in 
debian/templates/image.meta.maintscript.in debian/templates/image.postinst.in 
debian/templates/image.postrm.in debian/templates/image.preinst.in 
debian/templates/image.prerm.in debian/templates/perf.lintian-overrides.in 
debian/templates/perf.meta.maintscript.in 
debian/templates/sourcebin.meta.maintscript.in 
debian/templates/tests-control.image.in debian/templates/tests-control.main.in 
debian/config/defines debian/config/alpha/defines debian/config/amd64/defines 
debian/config/arm64/defines debian/config/arm64ilp32/defines 
debian/config/armel/defines debian/config/armhf/defines 
debian/config/featureset-rt/defines debian/config/hppa/defines 
debian/config/i386/defines debian/config/ia64/defines 
debian/config/m68k/defines debian/config/mips64/defines 
debian/config/mips64el/defines debian/config/mips64r6/defines 
debian/config/mips64r6el/defines debian/config/mips/defines 
debian/config/mipsel/defines debian/config/mipsn32/defines 
debian/config/mipsn32el/defines debian/config/mipsn32r6/defines 
debian/config/mipsn32r6el/defines debian/config/mipsr6/defines 
debian/config/mipsr6el/defines debian/config/powerpc/defines 
debian/config/ppc64/defines debian/config/ppc64el/defines 
debian/config/riscv64/defines debian/config/s390/defines 
debian/config/s390x/defines debian/config/sh3/defines debian/config/sh4/defines 
debian/config/sparc64/defines debian/config/sparc/defines 
debian/config/x32/defines debian/config/amd64/none/defines 
debian/config/amd64/rt/defines debian/config/arm64/none/defines 
debian/config/arm64/rt/defines debian/config/armhf/none/defines 
debian/config/armhf/rt/defines debian/config/i386/none/defines 
debian/config/i386/rt/defines debian/config/riscv64/none/defines 
debian/installer/kernel-versions debian/installer/package-list > 
debian/control.md5sum

This target is made to fail intentionally, to make sure
that it is NEVER run during the automated build. Please
ignore the following error, the debian/control file has
been generated SUCCESSFULLY.

exit 1
make: *** [debian/rules:122: debian/control-real] Error 1
dh_testdir
rm -rf debian/build debian/stamps debian/lib/python/debian_linux/*.pyc 
debian/lib/python/debian_linux/__pycache__ $(find debian -maxdepth 1 -type d 
-name 'linux-*') debian/*-modules-*-di* debian/kernel-image-*-di* debian/*-tmp 
debian/*.substvars
dh_clean
mkdir -p debian/build
printf >debian/build/version-info 'Source: %s\nVersion: %s\n' linux 
5.10.46-5a~test
md5sum --check debian/control.md5sum --status || \
/usr/bin/make -f debian/rules debian/control-real
dh_testdir
/usr/bin/make -f debian/rules.gen source
make[1]: Entering directory '/usr/src/linux-5.10.46'
/usr/bin/make -f debian/rules.real source-featureset ABINAME='5.10.0-8' 
FEATURESET='none' SOURCEVERSION='5.10.46-5a~test' SOURCE_BASENAME='linux' 
SOURCE_SUFFIX='' UPSTREAMVERSION='5.10' VERSION='5.10'

Bug#995387: dpkg: remove-on-upgrade deletes symlink targets owned by another package

[Guillem Jover]

Hi!

On Thu, 2021-09-30 at 16:21:21 +0200, Andreas Beckmann wrote:
> Package: dpkg
> Version: 1.20.6
> Severity: grave
> Justification: breaks unrelated packages by removing their conffiles
> 
> attached is a small package demonstrating the misbehavior of
> remove-on-upgrade which may delete symlink targets. It builds foo.deb
> (which has 'remove-on-upgrade /etc/old-conffile') and bar.deb (which
> has /etc/old-conffile -> /etc/new-conffile).

Thanks for the reproducer. I'm looking how to best fix this, ideally
with a minimal amount of code that might be sensible to add into a
stable release.

> The actual bug where I encountered this misbehavior is
>   #994971: OpenCL not working with latest Nvidia driver
> and it was an error of debhelper converting rm_conffile to remove-on-upgrade
> but dpkg played its part by deleting the symlink target instead of the
> symlink itself, but it should rather do nothing (or print a diagnostic) if
> the to-be-removed file is not a plain file.

Actually I think there's just a problem here with remove-on-upgrade not
taking into account ownership from other packages. But the conffile
dereferencing is an "expected" behavior (although I think is more of a
misfeature than anything else TBH, and I'm not sure it even behaves
sanely in all cases, which might require additional tests and fixes),
which does the same as with normal purging and unpacking. If there's a
symlink then what it points to will be used instead for its contents and
for removals etc.

> Simplified, the nvidia use case the following:
> 
> Long ago, /etc/conffile was a conffile
> That was later removed with rm_conffile
> and since then the different co-installable drivers ship 
> /etc/conffile-$driver_version instead
> and a slave alternative exists as /etc/conffile pointing to the corresponding 
> file of
> the activated driver variant.
> (The different drivers may require slightly different conffile content.)

So given the above, the ownership fix is needed to protect the user, but I
don't think it would have helped you anyway, as the alternative is not
owned in a way that dpkg knows. So it would consider it a local
symlink that can be overwritten. :/

I guess the remove-on-upgrade directive needs a possibly optional
version restriction like dpkg-maintscript-helper. :/

Thanks,
Guillem

Bug#995585: magit-annex build-depends on removed transitional package.

[peter green]

Package: magit-annex
Version: 1.7.1+git20200427.01.ef5dce62-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid

magit-annex build-depends on the dash-el binary package which is no longer 
built by the
dash-el source package. It is still present in unstable as a cruft package but
is completely gone from testing.

Please update your build-dependency.

Bug#995584: ht-el build-depends on removed transitional package.

[peter green]

Package: ht-el
Version: 2.3-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid

ht-el build-depends on the dash-el binary package which is no longer built by 
the
dash-el source package. It is still present in unstable as a cruft package but
is completely gone from testing.

Please update your build-dependency.

Bug#995583: dpkg-depcheck: use mktemp to replace obsolete tempfile

[Daichi Fukui]

Package: devscripts
Version: 2.21.4
Severity: important
Tags: patch
X-Debbugs-Cc: daichi.fuku...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?

The debmake command, which internally uses dpkg-depcheck, fails
as follows in the bookworm/sid environment.

$ debmake -j -a package.tar.gz
...
Can't exec "tempfile": No such file or directory at
/usr/bin/dpkg-depcheck line 375.
...

I was just following an instruction written here:
https://www.debian.org/doc/manuals/debmake-doc/ch06.en.html#joption

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

The error log mentioned above reveals that dpkg-depcheck went
wrong for some reason. After some investigation, I found that
tempfile command is still used in the dpkg script file, though 
the tempfile command has been obsolete since debianutils (5.0-1).

To address this issue, I created a simple patch, which just
replaces tempfile with mktemp, following the guideline shown in
the BUGS section in its manpage:
https://manpages.debian.org/unstable/debianutils/tempfile.1.en.html

For the created patch, please kindly see the attachment.

   * What was the outcome of this action?

Without any modification, dpkg-depcheck fails with the latest
debianutils package (5.5-1) provided.

$ dpkg-depcheck ls
Can't exec "tempfile": No such file or directory at
/usr/bin/dpkg-depcheck line 375.
Use of uninitialized value $file in scalar chomp at
/usr/bin/dpkg-depcheck line 377.
Use of uninitialized value $file in substitution (s///) at
/usr/bin/dpkg-depcheck line 378.
Use of uninitialized value $strace_cmd[6] in system at
/usr/bin/dpkg-depcheck line 384.
strace: Can't fopen '': No such file or directory
Use of uninitialized value $strace_cmd[6] in join or string at
/usr/bin/dpkg-depcheck line 385.
Running strace failed (command line:
strace -e trace=open,openat,execve -f -q -o  ls

   * What outcome did you expect instead?

The dpkg-depcheck successfully determine packages used to run a
command in the latest sid environment as of filing this report.

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


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

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

Kernel: Linux 4.15.0-144-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages devscripts depends on:
ii  dpkg-dev  1.20.9
ii  fakeroot  1.26-1
ii  file  1:5.39-3
ii  gnupg 2.2.27-2
ii  gpgv  2.2.27-2
ii  libc6 2.32-4
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.12-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.005004-2
ii  libwww-perl   6.53-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-6
ii  python3   3.9.2-3
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.3.9
ii  curl7.74.0-1.3+b1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2021.09.25
ii  dput1.1.0
ii  equivs  2.3.1
ii  libdistro-info-perl 1.0
ii  libdpkg-perl1.20.9
ii  libencode-locale-perl   1.05-1.1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.26-1
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 5.08-1
ii  licensecheck3.1.1-2
ii  lintian 2.104.0
ii  man-db  2.9.4-2
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.2.1
ii  python3-debian  0.1.39
ii  python3-magic   2:0.4.24-1
ii  python3-requests2.25.1+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.27-2
ii  strace  5.10-1
ii  unzip   6.0-26
ii  wget1.21-1+b1
ii  xz-utils5.2.5-2

Versions of packages 

Bug#995582: epl build-depends on removed transitional package.

[peter green]

Package: epl
Version: 0.9-4
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"

epl build-depends on the dash-el binary package which is no longer built by the
dash-el source package. It is still present in unstable as a cruft package but
is completely gone from testing.

Please update your build-dependency.

Bug#995567: Can't handle cross-signed Let's Encrypt CA

[Wiebe Cazemier]

Package: lftp
Version: 4.7.4-1
Severity: important
Tags: upstream

LFTP implements a certificate verification that can't handle
cross-singing when the cross-sign CA expires. The result is that you
can't use lftp to access ftp servers that use Let's Encrypt
certificates, with the recent expiration of DST root CA X3.

All Debian versions are affected (don't mind my oldoldstable version).

Fix is not ready, but is pending. It needs back-porting (in supported
Debian versions).

https://github.com/lavv17/lftp/issues/641

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

Kernel: Linux 4.9.0-16-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_ALL to default 
locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages lftp depends on:
ii  libc6 2.24-11+deb9u4
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgnutls30   3.5.8-5+deb9u6
ii  libidn11  1.33-1+deb9u1
ii  libreadline7  7.0-3
ii  libstdc++66.3.0-18+deb9u1
ii  libtinfo5 6.0+20161126-1+deb9u2
ii  netbase   5.4
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages lftp recommends:
ii  openssh-client [ssh-client]  1:7.4p1-10+deb9u7

lftp suggests no packages.

-- debconf information:

Bug#995581: ITP: python-oauthenticator -- OAuth authenticator for JupyterHub

[Diego M. Rodriguez]

Package: wnpp
X-Debbugs-Cc: lola...@debian.org

Owner: "Diego M. Rodriguez" 
Severity: wishlist

* Package name: python-oauthenticator
  Version : 14.2.0
  Upstream Author : Jupyter Development Team 
* URL : https://github.com/jupyterhub/oauthenticator
* License : BSD-3-clause
  Programming Lang: Python
  Description : OAuth authenticator for JupyterHub

Provides plugins for JupyterHub to use common OAuth providers, as well
as base classes for writing custom authenticators with any OAuth 2.0
provider.

This package is an optional dependency of ITP "jupyterhub" [1]. My
intent is to package this software under the umbrella of the Debian
Python Team.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988775
-- 
Diego M. Rodriguez

Bug#995580: wine build-depends on unicode-data (< 14) but testing/unstable has 14.0.0-1

[peter green]

Package: wine
Version: 5.0.3-3
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid

wine build-depends on unicode-data (< 14) but testing/unstable has 14.0.0-1, 
therefore your
packages build-dependencies are unsatisfiable in testing and unstable.

Bug#772637: poppler-utils: pdftotext keeps ligatures from the PDF file instead of converting them

[Vincent Lefevre]

There's an upstream bug:

  https://bugs.freedesktop.org/show_bug.cgi?id=7002

"pdftotext and copy-n-paste from a document should expand ligatures
such as fi to the letters f and i."

Exactly this. But it was fixed in 2012. What happens with Debian?

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

Bug#995579: utf8proc build-depends onunicode-data (< 13.1) but testing/unstable has 14.0.0-1

[peter green]

Package: utf8proc
Version: 21.0.0-4
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid

utf8proc build-depends onunicode-data (< 13.1) but testing/unstable has 
14.0.0-1, therefore your
packages build-dependencies are unsatisfiable in testing and unstable.

Bug#995578: libxmlada build-depends onunicode-data (< 14~) but testing/unstable has 14.0.0-1

[peter green]

Package: libxmlada
Version: 21.0.0-4
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid

libxmlada build-depends onunicode-data (< 14~) but testing/unstable has 
14.0.0-1, therefore your
packages build-dependencies are unsatisfiable in testing and unstable.

Bug#995577: readline-common: let Ctrl-Left/Right in bash move between shell words not words

[Christoph Anton Mitterer]

Package: readline-common
Version: 8.1-2
Severity: wishlist


Hey.

The default /etc/inputrc has:
# mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving
"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word

which moves forward/backward between words (which in that sense "are
composed of alphanumeric characters (letters and digits)").

This is nice for any normal program using readline, but for bash in
particular it would be IMO much more useful if it moves between shell
tokens.
Otherwise, the cursor stops at every / , - = etc. of which there are
typically many in shell command lines.


The following seem to provide just that:
   shell-forward-word
  Move forward to the end of the next word.  Words  are  delimited
  by non-quoted shell metacharacters.
   shell-backward-word
  Move  back  to the start of the current or previous word.  Words
  are delimited by non-quoted shell metacharacters.


and you could made it *affect only bash* very easy:
$if Bash
"\e[1;5C": shell-forward-word
"\e[1;5D": shell-backward-word
$endif

(Yes the name is "Bash" not "bash" here.)


(Not sure why you need to map "\e[5C", "\e[5D", "\e\e[C" and "\e\e[D"
as well.
For me only "\e[1;5C" and "\e[1;5D" seems to be enough to get Ctrl-Left
and Ctrl-Right.


Thanks,
Chris.

Bug#995576: knot: Zone transfer from dnsmasq fails due to broken IXFR to AXFR fallback

[Daniel Gröber]

Package: knot
Version: 3.0.5-1

Dear Maintainer,

when using knot as a slave it currently has a bug where it doesn't properly
fall back to AXFR zone transfer if an IXFR request is answered with what
amounts to an empty response. Dnsmasq's AXFR functionality triggers this
behavour preventing all but the first XFR from occurring.

Upstream discussion of this problem and a proposed fix can be found here:

https://lists.nic.cz/pipermail/knot-dns-users/2021-September/002121.html

I have submitted the proposed patch for Debian on Salsa here:

https://salsa.debian.org/dns-team/knot-dns/-/merge_requests/10

--Daniel

Bug#504793: /etc/inputrc, once installed, is never replaced by newer versions

[Christoph Anton Mitterer]

Hey.

Anything new on this? It's in fact quite unfortunate that this is never
updated and people even don't get notified, that there would be changes
available.

Couldn't the file simply be handled as a conffile?
Most people which stick to the defaults would never notice, and those
who change the file are properly asked what they want to do.

Cheers,
Chris.

Bug#995575: colmap: FTBFS on hurd-i386: wrong reference to the build directory

[Pino Toscano]

Source: colmap
Version: 3.6+really3.6-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Control: found -1 colmap/3.6+really3.6+git20210519-1

Hi,

currently colmap fails to build on hurd-i386 [1].

The problem is that, in the colmap.install, the "obj-*-*-*" glob pattern
is used to refer to the build directory. The default build directory for
cmake is "obj-$DEB_HOST_GNU_TYPE", and considering that
DEB_HOST_GNU_TYPE for hurd-i386 is "i686-gnu", then the pattern does not
match the build directory.

The fix is simple: simply use "obj-*" to refer to the build directory.
Patch attached for this.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=colmap=hurd-i386=3.6%2Breally3.6-1=1632952345=0

Thanks,
-- 
Pino
--- a/debian/colmap.install
+++ b/debian/colmap.install
@@ -1,2 +1,2 @@
-obj-*-*-*/src/exe/colmap usr/bin
+obj-*/src/exe/colmap usr/bin
 doc/COLMAP.desktop usr/share/applications

Bug#995574: googletest: please support GNU/Hurd

[Pino Toscano]

Source: googletest
Version: 1.11.0-2
Severity: important
Tags: upstream patch fixed-upstream
User: debian-h...@lists.debian.org
Usertags: hurd
Control: forwarded -1 https://github.com/google/googletest/pull/3200

Hi,

a couple of months ago, thanks to the effort of Mattias Ellert,
GoogleTest got support for GNU/Hurd [1], merged as commit
05e9fa23f7 [2].

Can you please backport it to the Debian package? This way, all the
sources that use GoogleTest from the system will benefit from it.
Attached there is a git format-patch version of the commit, which
applies almost cleanly (only with offsets in one file).

[1] https://github.com/google/googletest/pull/3200
[2] 
https://github.com/google/googletest/commit/05e9fa23f74a4766294f858c16e87a1560261340

Thanks,
-- 
Pino
>From 05e9fa23f74a4766294f858c16e87a1560261340 Mon Sep 17 00:00:00 2001
From: Mattias Ellert 
Date: Wed, 30 Dec 2020 13:50:04 +0100
Subject: [PATCH] Port to GNU/Hurd

---
 googletest/include/gtest/internal/gtest-port-arch.h | 2 ++
 googletest/include/gtest/internal/gtest-port.h  | 9 ++---
 googletest/src/gtest-port.cc| 2 +-
 googletest/test/googletest-port-test.cc | 2 +-
 googletest/test/gtest_help_test.py  | 3 ++-
 5 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/googletest/include/gtest/internal/gtest-port-arch.h 
b/googletest/include/gtest/internal/gtest-port-arch.h
index 813bf2c6..a75cd5bb 100644
--- a/googletest/include/gtest/internal/gtest-port-arch.h
+++ b/googletest/include/gtest/internal/gtest-port-arch.h
@@ -78,6 +78,8 @@
 # define GTEST_OS_FREEBSD 1
 #elif defined __Fuchsia__
 # define GTEST_OS_FUCHSIA 1
+#elif defined(__GNU__)
+# define GTEST_OS_GNU_HURD 1
 #elif defined(__GLIBC__) && defined(__FreeBSD_kernel__)
 # define GTEST_OS_GNU_KFREEBSD 1
 #elif defined __linux__
diff --git a/googletest/include/gtest/internal/gtest-port.h 
b/googletest/include/gtest/internal/gtest-port.h
index 6b66362f..f62f5876 100644
--- a/googletest/include/gtest/internal/gtest-port.h
+++ b/googletest/include/gtest/internal/gtest-port.h
@@ -116,6 +116,7 @@
 //   GTEST_OS_DRAGONFLY - DragonFlyBSD
 //   GTEST_OS_FREEBSD  - FreeBSD
 //   GTEST_OS_FUCHSIA  - Fuchsia
+//   GTEST_OS_GNU_HURD - GNU/Hurd
 //   GTEST_OS_GNU_KFREEBSD - GNU/kFreeBSD
 //   GTEST_OS_HAIKU- Haiku
 //   GTEST_OS_HPUX - HP-UX
@@ -543,7 +544,7 @@ typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION;
   (GTEST_OS_LINUX || GTEST_OS_MAC || GTEST_OS_HPUX || GTEST_OS_QNX ||  
\
GTEST_OS_FREEBSD || GTEST_OS_NACL || GTEST_OS_NETBSD || GTEST_OS_FUCHSIA || 
\
GTEST_OS_DRAGONFLY || GTEST_OS_GNU_KFREEBSD || GTEST_OS_OPENBSD ||  
\
-   GTEST_OS_HAIKU)
+   GTEST_OS_HAIKU || GTEST_OS_GNU_HURD)
 #endif  // GTEST_HAS_PTHREAD
 
 #if GTEST_HAS_PTHREAD
@@ -603,7 +604,8 @@ typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION;
  (GTEST_OS_WINDOWS_DESKTOP && _MSC_VER) || GTEST_OS_WINDOWS_MINGW ||  \
  GTEST_OS_AIX || GTEST_OS_HPUX || GTEST_OS_OPENBSD || GTEST_OS_QNX || \
  GTEST_OS_FREEBSD || GTEST_OS_NETBSD || GTEST_OS_FUCHSIA ||   \
- GTEST_OS_DRAGONFLY || GTEST_OS_GNU_KFREEBSD || GTEST_OS_HAIKU)
+ GTEST_OS_DRAGONFLY || GTEST_OS_GNU_KFREEBSD || GTEST_OS_HAIKU || \
+ GTEST_OS_GNU_HURD)
 # define GTEST_HAS_DEATH_TEST 1
 #endif
 
@@ -623,7 +625,8 @@ typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION;
 
 // Determines whether test results can be streamed to a socket.
 #if GTEST_OS_LINUX || GTEST_OS_GNU_KFREEBSD || GTEST_OS_DRAGONFLY || \
-GTEST_OS_FREEBSD || GTEST_OS_NETBSD || GTEST_OS_OPENBSD
+GTEST_OS_FREEBSD || GTEST_OS_NETBSD || GTEST_OS_OPENBSD ||   \
+GTEST_OS_GNU_HURD
 # define GTEST_CAN_STREAM_RESULTS_ 1
 #endif
 
diff --git a/googletest/src/gtest-port.cc b/googletest/src/gtest-port.cc
index 3f39f71c..989c59ae 100644
--- a/googletest/src/gtest-port.cc
+++ b/googletest/src/gtest-port.cc
@@ -98,7 +98,7 @@ const int kStdOutFileno = STDOUT_FILENO;
 const int kStdErrFileno = STDERR_FILENO;
 #endif  // _MSC_VER
 
-#if GTEST_OS_LINUX
+#if GTEST_OS_LINUX || GTEST_OS_GNU_HURD
 
 namespace {
 template 
diff --git a/googletest/test/googletest-port-test.cc 
b/googletest/test/googletest-port-test.cc
index 4a87df0b..e3ad4dde 100644
--- a/googletest/test/googletest-port-test.cc
+++ b/googletest/test/googletest-port-test.cc
@@ -280,7 +280,7 @@ TEST(FormatCompilerIndependentFileLocationTest, 
FormatsUknownFileAndLine) {
 
 #if GTEST_OS_LINUX || GTEST_OS_MAC || GTEST_OS_QNX || GTEST_OS_FUCHSIA || \
 GTEST_OS_DRAGONFLY || GTEST_OS_FREEBSD || GTEST_OS_GNU_KFREEBSD || \
-GTEST_OS_NETBSD || GTEST_OS_OPENBSD
+GTEST_OS_NETBSD || GTEST_OS_OPENBSD || GTEST_OS_GNU_HURD
 void* ThreadFunc(void* data) {
   internal::Mutex* mutex = static_cast(data);
   mutex->Lock();
diff --git a/googletest/test/gtest_help_test.py 
b/googletest/test/gtest_help_test.py
index 8d953bbd..54d45047 100755
--- a/googletest/test/gtest_help_test.py
+++ 

Bug#995463: geeqie: doesn't save preferences

[Andreas Ronnquist]

On Fri, 01 Oct 2021 16:44:30 +0200
Emilian Nowak  wrote:

>Dear Maintainer,
>Each time I uncheck option
>Edit -> Preferences -> Image -> Convenience -> "Auto rotate proofs
>using Exif information"
>after restart of geeqie it is still checked.
>Seems like this preferece is not saved.
>There is no error about that in console, neither in UI.
>
>

Thanks for your report - as you can see I have forwarded the bug to
upstream, and they claim it is intended for the print mechanism, which
is redundant when using the standard GTK method for printing.

So, if I interpret upstream correctly, they will probably remove the
option. 

I guess it is only this specific option that doesn't stick, and not any
others?

Please report back if other options doesn't stick for you (I can
reproduce it for this one).

/Andreas
gus...@debian.org

Bug#995573: Bug - Known Issue : xRDP connection results in Oh No ! something has gone wrong..Logout when Gnome Desktop used

[C-Nergy]

Package: xorgxrdp
Version: 0.2.12

I'm using Debian 11 bulleyes

We are installing xrdp package on top of Debian using

sudo apt-get install xrdp command

Installation is going through and no errors is thrown

After installing the xrdp package (and xorgxrdp package) on Debian 11, users 
are not able to perform
remote connections. The remote connection process but users end up on white 
screen where the message (see screenshot)
Oh No ! Something has gone wrong. Logout and try again

Expected result : the user should have access to the Gnome Desktop Interface 
via the Remote Desktop protocol

Possible root cause :
Based on the information found on the github of the software maintainer (see 
), this is a known issue 
with version xorgxrdp-0.2.12.
The proposed solution is to upgrade to a newer version of the xrdp/xorgxrdp 
packages

We have compiled the xrdp (0.9.17) and xorgxrdp (0.2.15) and the expected 
result is achieved. Users can perform remote connection to their Gnome Desktop 
interface


Hope this help

Griffon

Bug#797315: workaround available

[Thomas Lange]

There's a workaround available
See https://bugs.debian.org/992351
-- 

Bug#995572: gitlab: update to new upstream version 14.1.7

[Pirate Praveen]

Package: gitlab
Version: 14.0.10-2
Severity: important

While trying to update gitlab to 14.1.7 (using the deb from salsa)

Webpacking...
IncrementalWebpackCompiler: Status – disabled
/var/lib/gitlab/node_modules/webpack-cli/bin/cli.js:281
   throw err;
   ^

Error: Cannot find module 
'vs/editor/contrib/inlayHints/inlayHintsController'

Require stack:
- /var/lib/gitlab/node_modules/monaco-editor-webpack-plugin/out/index.js
- /etc/gitlab/plugins/monaco_webpack.js
- /etc/gitlab/webpack.config.js
- /var/lib/gitlab/node_modules/webpack-cli/bin/utils/convert-argv.js
- /var/lib/gitlab/node_modules/webpack-cli/bin/cli.js
- /usr/share/nodejs/webpack/node_modules/import-local/index.js
- /usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js
- /usr/share/nodejs/webpack/bin/webpack.js
   at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:880:15)
   at Function.resolve 
(/var/lib/gitlab/node_modules/v8-compile-cache/v8-compile-cache.js:164:2

3)
   at resolveMonacoPath 
(/var/lib/gitlab/node_modules/monaco-editor-webpack-plugin/out/index.js

:33:28)
   at 
/var/lib/gitlab/node_modules/monaco-editor-webpack-plugin/out/index.js:185:63

   at Array.map ()
   at createLoaderRules 
(/var/lib/gitlab/node_modules/monaco-editor-webpack-plugin/out/index.js

:185:43)
   at MonacoEditorWebpackPlugin.apply 
(/var/lib/gitlab/node_modules/monaco-editor-webpack-plugi

n/out/index.js:91:23)
   at webpack 
(/var/lib/gitlab/node_modules/webpack/lib/webpack.js:51:13)
   at processOptions 
(/var/lib/gitlab/node_modules/webpack-cli/bin/cli.js:272:16)

   at /var/lib/gitlab/node_modules/webpack-cli/bin/cli.js:364:3
   at Object.parse (/var/lib/gitlab/node_modules/yargs/yargs.js:576:18)
   at /var/lib/gitlab/node_modules/webpack-cli/bin/cli.js:49:8
   at Object. 
(/var/lib/gitlab/node_modules/webpack-cli/bin/cli.js:366:3)

   at Module._compile (internal/modules/cjs/loader.js:1063:30)
   at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:1092:10)

   at Module.load (internal/modules/cjs/loader.js:928:32)
   at Function.Module._load (internal/modules/cjs/loader.js:769:14)
   at Module.require (internal/modules/cjs/loader.js:952:19)
   at require (internal/modules/cjs/helpers.js:88:18)
   at module.exports 
(/usr/share/nodejs/webpack/node_modules/import-local/index.js:16:66)
   at 
/usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js:15:6
   at Object. 
(/usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js:366:3)

   at Module._compile (internal/modules/cjs/loader.js:1063:30)
   at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:1092:10)

   at Module.load (internal/modules/cjs/loader.js:928:32)
   at Function.Module._load (internal/modules/cjs/loader.js:769:14)
   at Module.require (internal/modules/cjs/loader.js:952:19)
   at require (internal/modules/cjs/helpers.js:88:18)
   at Object. 
(/usr/share/nodejs/webpack/bin/webpack.js:156:2)

   at Module._compile (internal/modules/cjs/loader.js:1063:30)
   at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:1092:10)

   at Module.load (internal/modules/cjs/loader.js:928:32)
   at Function.Module._load (internal/modules/cjs/loader.js:769:14)
   at Function.executeUserEntryPoint [as runMain] 
(internal/modules/run_main.js:72:12)

   at internal/main/run_main_module.js:17:47 {
 code: 'MODULE_NOT_FOUND',
 requireStack: [
   
'/var/lib/gitlab/node_modules/monaco-editor-webpack-plugin/out/index.js',

   '/etc/gitlab/plugins/monaco_webpack.js',
   '/etc/gitlab/webpack.config.js',
   
'/var/lib/gitlab/node_modules/webpack-cli/bin/utils/convert-argv.js',

   '/var/lib/gitlab/node_modules/webpack-cli/bin/cli.js',
   '/usr/share/nodejs/webpack/node_modules/import-local/index.js',
   '/usr/share/nodejs/webpack/node_modules/webpack-cli/bin/cli.js',
   '/usr/share/nodejs/webpack/bin/webpack.js'
 ]
}
dpkg: error processing package gitlab (--configure):

Bug#992693: glibc 2.31-13+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 992693 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: glibc
Version: 2.31-13+deb11u2

Explanation: do not try to detect if debconf is available when the debconf 
frontend has already been loaded

Bug#995007: gnustep-base ftbfs with updated autoconf/automake

[Peter Green]

Hi

I see a fix for this issue has been uploaded to mentors, do you want me to 
sponsor it?

Bug#995484: dhcpy6d: AttributeError: 'Transaction' object has no attribute 'UserClass'

[Axel Beckert]

Control: retitle -1 dhcpy6d: PXE support broken ("AttributeError: 'Transaction' 
object has no attribute 'UserClass'")

Axel Beckert wrote:
> > Just found log after upgrading another production system to
> > Bullseye. Seems to be related to boot files. As far as I can see, the
> > UserClass was renamed to user_class is Transaction which is the only
> > problem here.
> 
> The actual impact is though currently unclear to me (current Debian
> package maintainer of dhcpy6d) and it doesn't seem to show up in a setup
> with a minimal diff to the default configuration as I use for testing.

Ok, upstream clarified the issue: "boot files" in the upstream bug
report refers to dhcpy6d's support for PXE boot parameters. So the PXE
support seems to be broken in currently Bullseye, Bookworm and Sid.

> Depending on the actual impact, this might be a candidate for a stable
> update, though. Nevertheless setting the severity to "important" as it is
> causing a Python syntax error under some circumstances.
> 
> The complete upstream patch is available at
> https://github.com/HenriWahl/dhcpy6d/commit/72c7e2a9fdfafde014b99b805817b2eb68a0cc47.patch

The fix seems not invasive, the syntax error is obvious and PXE is not
an unimportant feature, so I'll prepare a stable update for this as well.

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

Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1

[Aurelien Jarno]

Hi,

On 2021-09-30 22:16, Adam D. Barratt wrote:
> On Mon, 2021-09-27 at 12:38 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed d-i
> > 
> 
> To confirm some IRC conversations - given the closeness of the freeze
> for 11.1, please feel free to upload and kibi can review the package
> from stable-new.
> 

Unfortunately Cyril has found an issue while testing, the query to debconf
doesn't work when the libc6.preinst script is re-executed by the debconf
frontend:

| ...
| Preparing to unpack .../libc6_2.31-13+deb11u1_amd64.deb ...
| debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by 
another process: Resource temporarily unavailable
| Unpacking libc6:amd64 (2.31-13+deb11u1) over (2.31-13+deb11u1) .
| ...

This message is harmless in most cases, but can cause a switch to text
mode while debconf is able to fallback to another frontend. It is also
very worrying for users.

As discussed on IRC, I have uploaded glibc 2.31-13+deb11u2 that fixes
that issue by not trying to detect if debconf is available when the 
debconf frontend has already been loaded. You will find the
corresponding debdiff attached.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff --git a/debian/changelog b/debian/changelog
index dd5370af..7c23c790 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+glibc (2.31-13+deb11u2) bullseye; urgency=medium
+
+  [ Aurelien Jarno ]
+  * debian/debhelper.in/libc.preinst: do not try to detect if debconf is
+available when the debconf frontend has already been loaded.
+
+ -- Aurelien Jarno   Sat, 02 Oct 2021 14:47:40 +0200
+
 glibc (2.31-13+deb11u1) bullseye; urgency=medium
 
   [ Aurelien Jarno ]
diff --git a/debian/debhelper.in/libc.preinst b/debian/debhelper.in/libc.preinst
index f0285832..ff59ad9a 100644
--- a/debian/debhelper.in/libc.preinst
+++ b/debian/debhelper.in/libc.preinst
@@ -23,7 +23,11 @@ if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
 then
 # Check if the debconf module is available and usable
 USE_DEBCONF=
-if [ -f /usr/share/debconf/confmodule ]; then
+if [ "$DEBIAN_HAS_FRONTEND" ]; then
+# Debconf is already loaded, so we already checked if the frontend
+# is usable or not
+USE_DEBCONF=1
+elif [ -f /usr/share/debconf/confmodule ]; then
 # cdebconf has a working fallback mechanism in case dialog
 # is not usable, so do not try to do anything smart here
 if [ "$DEBCONF_USE_CDEBCONF" ] ; then


signature.asc
Description: PGP signature

Bug#432575: replacement not possible

[Thomas Lange]

fai-make-nfsroot cannot be replaced by fai dirinstall, because
it supports options, which can't easily mapped to FAI classes.
And it's not possible to pass options to fai dirinstall.

But fai-make-nfsroot can use "fai dirinstall" internally.
-- 
viele Grüße Thomas

Bug#995571: boost1.74: autopkgtest failure on !amd64 architectures

[Graham Inggs]

Source: boost1.74
Version: 1.74.0-10
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

The 'context' autopkgtest of boost1.74 fails on non-amd64 architectures [1].
I've copied what I hope is the relevant output below.

Regards
Graham


[1] https://ci.debian.net/packages/b/boost1.74/


autopkgtest [05:13:49]: test context: [---
-- The CXX compiler identification is GNU 10.3.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Boost:
/usr/lib/aarch64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found
version "1.74.0") found components: context
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/tmp.eZLeJKi6Y5/build
Scanning dependencies of target demo2
[ 50%] Building CXX object CMakeFiles/demo2.dir/demo2.cpp.o
/tmp/tmp.eZLeJKi6Y5/src/demo2.cpp:11:10: fatal error: emmintrin.h: No
such file or directory
   11 | #include 
  |  ^
compilation terminated.
make[2]: *** [CMakeFiles/demo2.dir/build.make:82:
CMakeFiles/demo2.dir/demo2.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:95: CMakeFiles/demo2.dir/all] Error 2
make: *** [Makefile:103: all] Error 2
autopkgtest [05:13:50]: test context: ---]
autopkgtest [05:13:50]: test context:  - - - - - - - - - - results - -
- - - - - - - -
context  FAIL non-zero exit status 2
autopkgtest [05:13:50]: test context:  - - - - - - - - - - stderr - -
- - - - - - - -
/tmp/tmp.eZLeJKi6Y5/src/demo2.cpp:11:10: fatal error: emmintrin.h: No
such file or directory
   11 | #include 
  |  ^
compilation terminated.
make[2]: *** [CMakeFiles/demo2.dir/build.make:82:
CMakeFiles/demo2.dir/demo2.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:95: CMakeFiles/demo2.dir/all] Error 2
make: *** [Makefile:103: all] Error 2

Bug#990210: fixed in cups-pdf 3.0.1-12

[Martin-Éric Racine]

A similar bug report was filed at Ubuntu. The user there has been able
to verify that merely downgrading 3 GS packages (ghostscript, libgs9,
libgs9-common) to 9.53 restored operation.

Can users here at Debian perform the same check? If downgrading these
3 Ghostscript packages fixes it, we'll know for sure that GS is what
causes this.

Martin-Éric

Bug#995570: wget: Bogus certificate errors, certificate is valid

[php4...@gmail.com]

Package: wget
Version: 1.20.1-1.1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
wget https://matteosistisette.com/generatore-strofe-bolero-baglioni/

   * What was the outcome of this action?

ERROR: certificate is not trusted
ERROR: certificate is expired

(I'm writing by memory, so the wording might not be 100% exact)

   * What outcome did you expect instead?

Should have downloaded the page with no error. The certificate is
trusted and not expired.
curl downloads the exact same url without error, and so does my browser.

Note that the server serving the url is the very same machine I'm using
wget from. I'm not sure whether the issue happens at the client or the
server level, but it's the same machine.

I suspect this is due to a CA certificate having recently expired and
being wrongly used due to a misconfiguration in the distribution.
Given that I did not install or choose the root certificates but used
the package manager, this is a bug in the distribution or the
distributed packages. Perhaps not in wget, please reassign to whatever
the culprit is.


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


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

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

Versions of packages wget depends on:
ii  libc6 2.28-10
ii  libgnutls30   3.6.7-4
ii  libidn2-0 2.0.5-1
ii  libnettle63.4.1-1
ii  libpcre2-8-0  10.32-5
ii  libpsl5   0.20.2-2
ii  libuuid1  2.33.1-0.1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages wget recommends:
ii  ca-certificates  20190110

wget suggests no packages.

-- no debconf information

Bug#860751: win32-loader: FTBFS on i386: segmentation fault

[Bernhard Übelacker]

Control: fixed -1 1.3.4.20200120-1

Dear Maintainer,
I just wondered why this bug not gets archived.
Due to [1], it is fixed in unstable and testing,
is installed for all architectures [2],
and is not release-critical.
So I guess it might be the version that existed
just in experimental, therefore adding the
fixed version 1.3.4.20200120-1.

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowtoUseBTS#Version_tracking
[2] https://buildd.debian.org/status/package.php?p=mawk

Bug#995569: debhelper: act on service files placed in usr/lib/systemd/system

[Ferenc Wágner]

Package: debhelper
Version: 13.5.2
Severity: normal

Dear Maintainer,

If some upstream install procedure places service files under
/usr/lib/systemd/system, dh_installsystemd won't notice those in
debian/tmp during package build, thus such units won't be enabled and
started on the installation of the resulting package.

I think this could (and should) be done irrespective of the usrmerge
transition and whether maintainer-provided unit files are installed into
/usr/lib or /lib, because this has little chance to change anything
automatically (unless some packages have been shipping unit files under
/usr/lib with the very purpose of not activating and starting them).
-- 
Thanks for your consideration,
Feri.

Bug#772637: poppler-utils: pdftotext keeps ligatures from the PDF file instead of converting them

[Vincent Lefevre]

Control: retitle -1 poppler-utils: pdftotext keeps ligatures from the PDF file 
instead of converting them to usual text

Better title.

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

Bug#772637: poppler-utils: pdftotext generates ligatures in some cases

[Vincent Lefevre]

Control: found -1 20.09.0-3.1
Control: severity -1 important

Issue still present. According to Ghostscript developers, ps2pdf
behaves correctly, and it is up to the PDF consumer to handle the
ligatures.

FYI, the PDF viewer atril does recognize the ligature, and a search
for the 2 characters "ff" matches.

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

Bug#995568: Upgrade fails

[Nigel Horne]

Package: x11proto-dev
Version: 2021.5-1

Package fails to upgrade:

# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 libxau-dev : Depends: x11proto-dev but it is not installed
 libxdamage-dev : Depends: x11proto-dev but it is not installed
 libxext-dev : Depends: x11proto-dev but it is not installed
 libxfixes-dev : Depends: x11proto-dev but it is not installed
 x11proto-core-dev : Depends: x11proto-dev but it is not installed
 x11proto-dri2-dev : Depends: x11proto-dev but it is not installed
 x11proto-gl-dev : Depends: x11proto-dev but it is not installed
 x11proto-input-dev : Depends: x11proto-dev but it is not installed
 x11proto-kb-dev : Depends: x11proto-dev but it is not installed
 x11proto-xext-dev : Depends: x11proto-dev but it is not installed
 x11proto-xf86vidmode-dev : Depends: x11proto-dev but it is not installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).
root@netgate2:/home/njh# apt --fix-broken install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  gnupg-l10n libblas-common libexporter-lite-perl libfile-copy-recursive-perl
  libgfortran3 libglew2.0 libio-capture-perl libncurses5-dev
  libnetwork-ipv4addr-perl libset-scalar-perl libstrictures-perl libxcb-util0
  ruby-nokogiri ruby-pkg-config ruby-rgen ruby-safe-yaml x11proto-damage-dev
  x11proto-fixes-dev x11proto-xext-dev
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  x11proto-dev
The following NEW packages will be installed:
  x11proto-dev
0 upgraded, 1 newly installed, 0 to remove and 483 not upgraded.
677 not fully installed or removed.
Need to get 0 B/599 kB of archives.
After this operation, 1,720 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
(Reading database ... 19 files and directories currently installed.)
Preparing to unpack .../x11proto-dev_2021.5-1_all.deb ...
Unpacking x11proto-dev (2021.5-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/x11proto-dev_2021.5-1_all.deb (--unpack):
 trying to overwrite '/usr/include/X11/extensions/damageproto.h', which is also 
in package x11proto-damage-dev 1:1.2.1-2
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/x11proto-dev_2021.5-1_all.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[‍小太]

Since the offending code seems to be present upstream in the
glibmm-2-66 branch, I've also reported it upstream:
https://gitlab.gnome.org/GNOME/glibmm/-/issues/96

Bug#993492: buster-pu: package cyrus-imapd/3.0.8-6+deb10u6

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2021-09-02 at 08:00 +0200, Yadd wrote:
> cyrus-imapd before 3.0.16 allows remote attackers to cause a denial
> of
> service (multiple-minute daemon hang) via input that is mishandled
> during hash-table interaction. Because there are many insertions into
> a single bucket, strcmp becomes slow. This is fixed in 3.4.2, 3.2.8,
> and 3.0.16.
> 

Please go ahead.

Regards,

Adam

Bug#995482: request-tracker4 4.4.3-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995482 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: request-tracker4
Version: 4.4.3-2+deb10u1

Explanation: fix login timing side-channel attack issue [CVE-2021-38562]

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[‍小太]

I can also confirm this issue also happens to me, and that downgrading
glibmm from 2.66.1-1 to 2.64.2-2 successfully resolves the issue.

I followed similar debugging steps as r...@thoryk.com above which
produced the same backtrace, before finding this bug already reported.

What I can add is from reading the documentation of g_quark_from_static_string()
(https://docs.gtk.org/glib/func.quark_from_static_string.html)
is these particular lines seem to be of importance:

> It can be used with statically allocated strings in the main program,
> but not with statically allocated memory in dynamically loaded
> modules, if you expect to ever unload the module again

However, jackd will load jack_firewire.so three times (which means
loading and unloading its glibmm dependency three times) from the
following backtraces:

> Breakpoint 1, __dlopen (file=0x7fffd400 
> "/tmp/jackd2/lib/jack/jack_firewire.so", mode=258) at dlopen.c:75
> 75dlopen.c: No such file or directory.
> (gdb) bt
> #0  __dlopen (file=0x7fffd400 "/tmp/jackd2/lib/jack/jack_firewire.so", 
> mode=258) at dlopen.c:75
> #1  0x77f73f9b in check_symbol (sofile=0x555720f3 
> "jack_firewire.so", symbol=0x77f9b528 "jack_internal_initialize", 
> driver_dir=0x77f9b4de "/tmp/jackd2/lib/jack", res_dllhandle=0x0) at 
> ../common/JackDriverLoader.cpp:432
> #2  0x77f7430d in jack_drivers_load (drivers=0x0) at 
> ../common/JackDriverLoader.cpp:602
> #3  0x77f795ff in jackctl_drivers_load (server_ptr=0x5556fbb0) at 
> ../common/JackControlAPI.cpp:390
> #4  0x77f7a4b6 in jackctl_server_create2 (on_device_acquire=0x0, 
> on_device_release=0x0, on_device_reservation_loop=0x0) at 
> ../common/JackControlAPI.cpp:935
> #5  0x6d7d in main (argc=3, argv=0x7fffdfa8) at 
> ../common/Jackdmp.cpp:334


> Thread 1 "jackd" hit Breakpoint 1, __dlopen (file=0x7fffcfa0 
> "/tmp/jackd2/lib/jack/jack_firewire.so", mode=258) at dlopen.c:75
> 75in dlopen.c
> (gdb) bt
> #0  __dlopen (file=0x7fffcfa0 "/tmp/jackd2/lib/jack/jack_firewire.so", 
> mode=258) at dlopen.c:75
> #1  0x77f73f9b in check_symbol(file_char_t const*, char const*, 
> file_char_t const*, void**) (sofile=0x555720f3 "jack_firewire.so", 
> symbol=0x77f9b541 "driver_get_descriptor", driver_dir=0x77f9b4de 
> "/tmp/jackd2/lib/jack", res_dllhandle=0x7fffd3e8)
> at ../common/JackDriverLoader.cpp:432
> #2  0x77f740b0 in jack_get_descriptor(JSList*, file_char_t const*, 
> char const*, file_char_t const*) (drivers=0x0, sofile=0x555720f3 
> "jack_firewire.so", symbol=0x77f9b541 "driver_get_descriptor", 
> driver_dir=0x77f9b4de "/tmp/jackd2/lib/jack")
> at ../common/JackDriverLoader.cpp:465
> #3  0x77f74339 in jack_drivers_load(_JSList*) (drivers=0x0) at 
> ../common/JackDriverLoader.cpp:606
> #4  0x77f795ff in jackctl_drivers_load(jackctl_server*) 
> (server_ptr=0x5556fbb0) at ../common/JackControlAPI.cpp:390
> #5  0x77f7a4b6 in jackctl_server_create2(bool (*)(char const*), void 
> (*)(char const*), void (*)()) (on_device_acquire=0x0, on_device_release=0x0, 
> on_device_reservation_loop=0x0) at ../common/JackControlAPI.cpp:935
> #6  0x6d7d in main(int, char**) (argc=3, argv=0x7fffdfa8) at 
> ../common/Jackdmp.cpp:334


> Thread 1 "jackd" hit Breakpoint 1, __dlopen (file=0x7fffd400 
> "/tmp/jackd2/lib/jack/jack_firewire.so", mode=258) at dlopen.c:75
> 75in dlopen.c
> (gdb) bt
> #0  __dlopen (file=0x7fffd400 "/tmp/jackd2/lib/jack/jack_firewire.so", 
> mode=258) at dlopen.c:75
> #1  0x77f73f9b in check_symbol(file_char_t const*, char const*, 
> file_char_t const*, void**) (sofile=0x555e5ab3 "jack_firewire.so", 
> symbol=0x77f9b528 "jack_internal_initialize", driver_dir=0x77f9b4de 
> "/tmp/jackd2/lib/jack", res_dllhandle=0x0)
> at ../common/JackDriverLoader.cpp:432
> #2  0x77f74511 in jack_internals_load(_JSList*) (internals=0x0) at 
> ../common/JackDriverLoader.cpp:723
> #3  0x77f797c1 in jackctl_internals_load(jackctl_server*) 
> (server_ptr=0x5556fbb0) at ../common/JackControlAPI.cpp:459
> #4  0x77f7a4cb in jackctl_server_create2(bool (*)(char const*), void 
> (*)(char const*), void (*)()) (on_device_acquire=0x0, on_device_release=0x0, 
> on_device_reservation_loop=0x0) at ../common/JackControlAPI.cpp:941
> #5  0x6d7d in main(int, char**) (argc=3, argv=0x7fffdfa8) at 
> ../common/Jackdmp.cpp:334


So the issue here seems like glibmm should not be using
g_quark_from_static_string(), but g_quark_from_string() instead

Bug#995481: request-tracker4 4.4.4+dfsg-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 995481 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: request-tracker4
Version: 4.4.4+dfsg-2+deb11u1

Explanation: fix login timing side-channel attack issue [CVE-2021-38562]

Bug#994710: nautilus 3.38.2-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994710 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nautilus
Version: 3.38.2-1+deb11u1

Explanation: 

Bug#994709: gnome-maps 3.38.6-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 994709 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: gnome-maps
Version: 3.38.6-0+deb11u1

Explanation: new upstream stable release; fix a crash when starting up with 
last-used map type being aerial, and no aerial tile definition is found; don't 
sometimes write broken last view position on exit; fix hang when dragging 
around route markers