Bug#1035042: wpewebkit: ftbfs riscv64 Error: open CFI at the end of file; missing .cfi_endproc directive

[sun min]

Hi, Alberto:

My host info are as follows:
uname -a
Linux Debian 5.10.102.1-microsoft-standard-WSL2+ #3 SMP Fri Apr 22 17:24:10 CST 
2022 x86_64 GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:unstable
Codename:   sid

My sbuild env is created using this command:
sudo sbuild-createchroot --debootstrap=mmdebstrap --arch=riscv64 \
--include=debian-ports-archive-keyring,ca-certificates  \
--make-sbuild-tarball=/srv/sid-riscv64-sbuild.tgz \
sid \
http://ftp.ports.debian.org/debian-ports/

I get the package source with below command:
dget http://deb.debian.org/debian/pool/main/w/wpewebkit/wpewebkit_2.38.6-1.dsc

And launch the sbuild:
sudo update-binfmts –enable
sudo sbuild --source --arch=riscv64 -c sid-riscv64-sbuild

My local build stopped around [1833/6141] while the
  buildd  finished at [6132/6132].

Best wishes,
--
sun min


From: Alberto Garcia 
Sent: Saturday, April 29, 2023 19:57
To: sun min; 1035...@bugs.debian.org
Subject: Re: Bug#1035042: wpewebkit: ftbfs riscv64 Error: open CFI at the end 
of file; missing .cfi_endproc directive

Control: tags -1 moreinfo

On Fri, Apr 28, 2023 at 05:57:34AM +, sun min wrote:
> Source: wpewebkit
> Version: 2.38.6-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
>
> Dear Maintainer,
>
> My sbuild for risv64 archtecture log says:

Hi, wpewebkit 2.38.x has been building fine in riscv64 for a while
without many problems:

   https://buildd.debian.org/status/logs.php?pkg=wpewebkit=riscv64

There was a failure in November 2022 seemingly because of a compiler
bug, but that's about it.

What is the exact environment that you are using to build webkit?

Berto

Bug#1034969: Fwd: Bug#1034969: terser: missing Breaks+Replaces for uglifyjs.terser when upgrading from bullseye

[Jonas Smedegaard]

Thanks for the patch, Yadd - and for the bugreport, Helmut.

I am quite busy elsewhere currently - if you have the time then I would
appreciate if you would handle this issue.

Otherwise I'll try make time for it the upcoming weekend.

 - Jonas

Quoting Yadd (2023-04-28 05:38:56)
> Hi Jonas,
> 
> it seems that "Breaks" fields needs to be duplicated in "Replaces":
> 
> diff --git a/debian/control b/debian/control
> index 6772ac76..3d8f1174 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -34,6 +34,9 @@ Depends:
>   Breaks:
>uglifyjs.terser (<< 4.8.0-1~),
>node-rollup-plugin-terser (<< 7.0.2+~5.0.1-3~)
> +Replaces:
> + uglifyjs.terser (<< 4.8.0-1~),
> + node-rollup-plugin-terser (<< 7.0.2+~5.0.1-3~)
>   Suggests:
>terser,
>   Multi-Arch: foreign
> @@ -87,6 +90,8 @@ Recommends:
>node-source-map-support,
>   Breaks:
>uglifyjs.terser (<< 4.8.0-1~),
> +Replaces:
> + uglifyjs.terser (<< 4.8.0-1~),
>   Suggests:
>node-acorn,
>   Multi-Arch: foreign
> 
> Cheers,
> Yadd
> 
>  Forwarded Message 
> Subject: [Pkg-javascript-devel] Bug#1034969: terser: missing 
> Breaks+Replaces for uglifyjs.terser when upgrading from bullseye
> Resent-Date: Thu, 27 Apr 2023 13:11:12 +
> Resent-From: Helmut Grohne 
> Resent-To: debian-bugs-dist@lists.debian.org
> Resent-CC: Debian Javascript Maintainers 
> 
> Date: Thu, 27 Apr 2023 14:59:55 +0200
> From: Helmut Grohne 
> Reply-To: Helmut Grohne , 1034...@bugs.debian.org
> To: sub...@bugs.debian.org
> 
> Package: terser
> Version: 5.16.4-1
> Severity: serious
> Justification: dpkg unpack error
> 
> Attempting to unpack terser/5.16.4-1 from Debian bookworm
> on a minimal Debian bullseye with uglifyjs.terser/4.1.2-8
> installed, causes an unpack error from dpkg due to
> /usr/share/nodejs/terser/bin/uglifyjs being contained in both packages.
> 
> | Selecting previously unselected package terser.
> | dpkg: considering deconfiguration of uglifyjs.terser, which would be 
> broken by installation of terser ...
> | dpkg: yes, will deconfigure uglifyjs.terser (broken by terser)
> | (Reading database ... 4922 files and directories currently installed.)
> | Preparing to unpack ./terser_5.16.4-1_all.deb ...
> | De-configuring uglifyjs.terser (4.1.2-8) ...
> | Unpacking terser (5.16.4-1) ...
> | dpkg: error processing archive ./terser_5.16.4-1_all.deb (--unpack):
> |  trying to overwrite '/usr/share/nodejs/terser/bin/uglifyjs', which is 
> also in package uglifyjs.terser 4.1.2-8
> | Errors were encountered while processing:
> |  ./terser_5.16.4-1_all.deb
> 
> 
> Please ensure that terser has sufficient Breaks and Replaces declarations.
> 
> Helmut
> 
> -- 
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#1034908: Processed: Please ship libgtest.so and libgmock.so for building libabsl-dev

[Steven Robbins]

On Friday, April 28, 2023 2:45:05 A.M. CDT Debian Bug Tracking System wrote:
> Processing control commands:
> > block 1034908 by -1
> 
> Bug #1034908 [libabsl-dev] Update libabsl-dev to new upstream
> version/snapshot for newer protobuf 1034908 was not blocked by any bugs.
> 1034908 was blocking: 1034668
> Added blocking bug(s) of 1034908: 1035045

The reported build error is:

dpkg-shlibdeps: error: cannot find library libgtest.so.1.12.1 needed by 
debian/libabsl20230125/usr/lib/x86_64-linux-gnu/
libabsl_per_thread_sem_test_common.so.20230125.0.0 
(ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')

How did libabsl20230125 get such a dependency?  Debian has never shipped 
libgtest.so -- was this built against a locally-built libgtest somehow?

My recommendation is to preferably build libgtest in your own build process -- 
this ensures gtest is built with the same compiler options as your test code; 
or else link against the provided static libgtest.a.

-Steve




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

Bug#1035332: grub-efi-arm64: "error: failed to install/update FDT." after bullseye upgrade

[Vagrant Cascadian]

Package: grub-efi-arm64
Version: 2.06-3~deb11u5
Severity: important
X-Debbugs-Cc: vagr...@debian.org

After updating to the latest point release, these apm mustang systems fail to 
boot the kernel, all I see is:

error: failed to install/update FDT.
Loading Linux 5.10.0-22-arm64 ...
Loading initial ramdisk ...

Press any key to continue...

Same result with two different machines. Both worked fine since before
the upgrade (although not entirely sure how long since they last were
rebooted, but surely since the previous point release).

I do not recall seeing the error message before when it was working;
it flashes by quite quickly... and if the boot was successful, I might
have never noticed.

Technically, the system details from this bug report are from a
machine I have not yet rebooted, but it is configured essentially
identically to the two machines that are failing to boot (mainly a
different amount of ram).

Will try to figure out how to boot these things into rescue mode and
see if an older grub still works...


Apparently this is "Vagrant files bugs on grub day." :/


live well,
  vagrant


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/mst0vg-mst00--root / ext4 rw,noatime,errors=remount-ro 0 0
/dev/sdb1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod lvm
insmod ext2
set 
root='lvmid/lN0djM-1VCP-W6Lg-coTr-sVKq-Orum-JlTxLx/STv12u-sENg-7TZu-28ge-IqjP-ya8c-QaYtKb'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/lN0djM-1VCP-W6Lg-coTr-sVKq-Orum-JlTxLx/STv12u-sENg-7TZu-28ge-IqjP-ya8c-QaYtKb'
  085e1704-07fe-4ef4-9bc7-7feb51411222
else
  search --no-floppy --fs-uuid --set=root 085e1704-07fe-4ef4-9bc7-7feb51411222
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-085e1704-07fe-4ef4-9bc7-7feb51411222' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod lvm
insmod ext2
set 
root='lvmid/lN0djM-1VCP-W6Lg-coTr-sVKq-Orum-JlTxLx/STv12u-sENg-7TZu-28ge-IqjP-ya8c-QaYtKb'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/lN0djM-1VCP-W6Lg-coTr-sVKq-Orum-JlTxLx/STv12u-sENg-7TZu-28ge-IqjP-ya8c-QaYtKb'
  085e1704-07fe-4ef4-9bc7-7feb51411222
else
  search --no-floppy --fs-uuid --set=root 
085e1704-07fe-4ef4-9bc7-7feb51411222
fi
echo'Loading Linux 5.10.0-22-arm64 ...'
linux   /boot/vmlinuz-5.10.0-22-arm64 
root=/dev/mapper/mst0vg-mst00--root ro  quiet
echo'Loading initial ramdisk ...'
  

Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[Cyril Brulebois]

Hi,

Diederik de Haas  (2023-04-30):
> I suggest we stick to `brcmfmac43455-sdio.raspberrypi,4-model-b.txt` as that 
> is its name in the upstream repo: 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

Yes please.

> > And a nitpick: the way this appears in the hw-detect prompt screen in the
> > installer is a bit odd, because spaces in the filenames are replaced with
> > newlines.  That might be nice to fix at the same time if we can.
> 
> AFAIC it's a bit more then a nitpick as it identified a/several bugs in the 
> script. Run it through `shellcheck` and you'll see a whole bunch of*:
> SC2086 (info): Double quote to prevent globbing and word splitting.
> https://www.shellcheck.net/wiki/SC2086
> 
> And that's exactly what happens or will happen. Even though the RPi4 filename 
> doesn't contain spaces, there are several in the `brcm` directory that do.
> I didn't check other directories, but I'd expect that filenames with a space 
> is 
> NOT an anomaly.
> 
> *) and several other warnings/suggestions

We won't rewrite hw-detect for bookworm, nor will we make it “shellcheck
compliant”. Now is definitely not the time to deal with such things, and
yes I'm going to call system files (e.g. package-shipped) with spaces an
anomaly.

People are much than welcome to put energy into making hw-detect more
robust in the future, but even knowing some bits about it, it's some
kind of a maze and I *really* don't want to lose any feature for the
generic cases (non-crazy filenames).

It's easy enough to just not use spaces in filenames in the first place.


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


signature.asc
Description: PGP signature

Bug#1035317: grub-pc: /boot on LVM fails if logical volume consists of multiple physical volumes

[Vagrant Cascadian]

On 2023-05-01, Steve McIntyre wrote:
> On Sun, Apr 30, 2023 at 04:28:01PM -0700, Vagrant Cascadian wrote:
>>On 2023-04-30, Steve McIntyre wrote:
>>> On Sun, Apr 30, 2023 at 12:56:29PM -0700, Vagrant Cascadian wrote:
When I tried extending the /dev/vvm/root partition to include more
space from the /dev/vdc1 physical volume, grub fails to load at boot,
unable to find the lvm volume.
>>...
>>> Can you give us a bit more detail about the system please? With
>>> /dev/vdc, this suggests you're in a VM and this is the third drive
>>> using virtio? How big is /dev/vdc? What's the partition type?
>>
>>The disk is about 2TB and the partition type is GPT.
>>
>>There is also a 1TB disk as /dev/vdb GPT, unused.
>>
>>The main boot disk is ~500GB /dev/vda MBR.
...
>>> If possible, on your system, could you also reboot and call up a grub
>>> command line (hit "c" from the grub menu)?
...
>>> From there, I'd love to see what you get if you run "ls" here...

"ls" from the grub prompt did not show the other disk...

...until I made the second disk bootable from libvirt!

Then grub now sees both disks, and boots fine!

So this is possibly a quirk of the way libvirt exposes boot disks.


> OK, I can reproduce with something like this:
>
> vda - small-ish dos-partitioned disk, fresh bullseye installation made
>   using LVM directly for the rootfs, no /boot
...
> *However*, using pvmove to move the root LV to vdc fails. I'd expect
> similar if you've just extended and grown the rootfs. I get an error:
>
>   error: disk `lvmid/' not found

That sounds consistent with the error message I got.


> and this is exactly the kind of thing I was looking for - maybe
> grub-pc can't access the drive due to BIOS limitations. *However*, I
> think I'm wrong and Pascal Hambourg is right here...!

I was able to reproduce with a simpler virtual machine (two disks,
lvm-backed, 10GB and 20GB)...


> I ran d-i in rescue mode to get into the system, simply ran
> dpkg-reconfigure grub-pc (which will run grub-install *and*
> update-grub), and the system now boots again. It looks like what we're
> seeing might be a limit in what's built in to the core image by
> default. grub-pc is deliberately designed to build minimal images
> here, to minimise the chance of the image being too large to embed.

Re-running grub-install /dev/vda from debian-installer rescue mode did
*not* fix the issue for me (though, now I am curious if dpkg-reconfigure
grub-pc would do anything more?)


> Being brutally honest, I think the problem is in your disk
> setup. You've found an edge case that *can* be accomodated and
> supported, but needs some extra effort to make it work.
>
> I'd *strongly* recommend re-thinking your setup here. If you're going
> to set up complicated storage here *for a VM*, then it would be
> trivial to set up a /boot partition which grub will never have
> problems finding and booting from. Make your life easier and just do
> that...

I only got into that situation due to a somewhat weird circumstance
(e.g. having a user on a system with libvirt access, but not root, and
libvirt helpfully re-owns files so that nobody else can mess with them).
Needed more space than originally planned, figured I could just add more
disks to LVM... and here we are.

I had used this sort of setup for at least a release or two of Debian
releases on real hardware without much trouble, so was inclined to go
all-in on LVM...

For the future, I guess I'll just resign myself to a split /boot.

Once I saw this bug I figured it was worth reporting, as it appeared
different enough from others I coudl see in the BTS.


Thanks for poking at this, hopefully someone else who stubs their toe on
this in the future will benefit. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1035317: grub-pc: /boot on LVM fails if logical volume consists of multiple physical volumes

[Steve McIntyre]

Control: severity -1 minor
Control: tags -1 wontfix
Control: retitle -1 grub-pc: needs reconfiguration with complex storage setup

On Sun, Apr 30, 2023 at 04:28:01PM -0700, Vagrant Cascadian wrote:
>On 2023-04-30, Steve McIntyre wrote:
>> On Sun, Apr 30, 2023 at 12:56:29PM -0700, Vagrant Cascadian wrote:
>>>When I tried extending the /dev/vvm/root partition to include more
>>>space from the /dev/vdc1 physical volume, grub fails to load at boot,
>>>unable to find the lvm volume.
>...
>> Can you give us a bit more detail about the system please? With
>> /dev/vdc, this suggests you're in a VM and this is the third drive
>> using virtio? How big is /dev/vdc? What's the partition type?
>
>The disk is about 2TB and the partition type is GPT.
>
>There is also a 1TB disk as /dev/vdb GPT, unused.
>
>The main boot disk is ~500GB /dev/vda MBR.
>
>> Why am I asking? grub-pc is limited by the platform underneath here
>> when it comes to assembling RAID or LVM volumes. If a complex disk
>> setup depends on a drive that can't be seen/read by grub at boot, it's
>> going to struggle. I'm wondering if this might be the underlying cause
>> of your issue.
>>
>> If possible, on your system, could you also reboot and call up a grub
>> command line (hit "c" from the grub menu)?
>
>At the moment, this is difficult as I am now doing some long-running
>builds on it... but will try when I get the chance or maybe reproduce
>the situation in another VM.
>
>
>> From there, I'd love to see what you get if you run "ls" here...

OK, I can reproduce with something like this:

vda - small-ish dos-partitioned disk, fresh bullseye installation made
  using LVM directly for the rootfs, no /boot

(all works)

Then add:

vdb - 8T GPT drive, qcow2, unused
vdc - 8T GPT drive, qcow2, a partition to add to the LVM VG

Rebooting straight away at this point still boots ok.

*However*, using pvmove to move the root LV to vdc fails. I'd expect
similar if you've just extended and grown the rootfs. I get an error:

  error: disk `lvmid/' not found

(not copying all of the UUID-style path by hand!)

and this is exactly the kind of thing I was looking for - maybe
grub-pc can't access the drive due to BIOS limitations. *However*, I
think I'm wrong and Pascal Hambourg is right here...!

I ran d-i in rescue mode to get into the system, simply ran
dpkg-reconfigure grub-pc (which will run grub-install *and*
update-grub), and the system now boots again. It looks like what we're
seeing might be a limit in what's built in to the core image by
default. grub-pc is deliberately designed to build minimal images
here, to minimise the chance of the image being too large to embed.

Being brutally honest, I think the problem is in your disk
setup. You've found an edge case that *can* be accomodated and
supported, but needs some extra effort to make it work.

I'd *strongly* recommend re-thinking your setup here. If you're going
to set up complicated storage here *for a VM*, then it would be
trivial to set up a /boot partition which grub will never have
problems finding and booting from. Make your life easier and just do
that...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Bug#1031401: postgrey.service %r specifier deprecated

[Jordi Mallach]

Hey,

El ds. 29 de 04 de 2023 a les 16:32 +, en/na Mathias Gibbens va
escriure:
>   As I upgrade systems, I'm encountering this warning as well. I
> haven't looked into what the fix would require, but I hope it could
> be
> a targeted fix appropriate for an upload during the hard freeze, so
> bookworm can ship with a version of postgrey that isn't emitting this
> message.

I noticed this myself a few weeks ago and have some fixes ready, just
pending some thorough testing.


I have now uploaded to unstable and filed an unblock request.

Thanks for your report!

Jordi

-- 
Jordi Mallach 
Debian Project

Bug#1035317: grub-pc: /boot on LVM fails if logical volume consists of multiple physical volumes

[Vagrant Cascadian]

On 2023-04-30, Steve McIntyre wrote:
> On Sun, Apr 30, 2023 at 12:56:29PM -0700, Vagrant Cascadian wrote:
>>When I tried extending the /dev/vvm/root partition to include more
>>space from the /dev/vdc1 physical volume, grub fails to load at boot,
>>unable to find the lvm volume.
...
> Can you give us a bit more detail about the system please? With
> /dev/vdc, this suggests you're in a VM and this is the third drive
> using virtio? How big is /dev/vdc? What's the partition type?

The disk is about 2TB and the partition type is GPT.

There is also a 1TB disk as /dev/vdb GPT, unused.

The main boot disk is ~500GB /dev/vda MBR.

> Why am I asking? grub-pc is limited by the platform underneath here
> when it comes to assembling RAID or LVM volumes. If a complex disk
> setup depends on a drive that can't be seen/read by grub at boot, it's
> going to struggle. I'm wondering if this might be the underlying cause
> of your issue.
>
> If possible, on your system, could you also reboot and call up a grub
> command line (hit "c" from the grub menu)?

At the moment, this is difficult as I am now doing some long-running
builds on it... but will try when I get the chance or maybe reproduce
the situation in another VM.


> From there, I'd love to see what you get if you run "ls" here...

Will do!

Thanks for the quick response!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1035331: jackd2: reproducible-builds: Locale and timezone dependent date in manpages

[Vagrant Cascadian]

Source: jackd2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps locale
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The manpages may contain a locale-translated month name, as well as a
different date based on the build environment timezone.

For jackd.1:

  .TH "JACKD" "1" "January 2023" "1.9.21" ""
  vs.
  .TH "JACKD" "1" "jaanuar 2023" "1.9.21" ""

  .TH "JACKD" "1" "2023-04-30" "1.9.21" ""
  vs.
  .TH "JACKD" "1" "2023-05-01" "1.9.21" ""

The attached patches fix this by using a numeric date specified with the
UTC timezone.

Thanks for maintaining jackd2!

live well,
  vagrant
From 5fe932e274c720b68aff40125f1069fde1490935 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 30 Apr 2023 15:44:21 -0700
Subject: [PATCH 1/5] man/fill_template: Use numeric year-month-date for
 manpage.

The month may be rendered for the locale of the build environment.

https://reproducible-builds.org/docs/locales/
---
 man/fill_template | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/man/fill_template b/man/fill_template
index 368cb1b..d1df18d 100644
--- a/man/fill_template
+++ b/man/fill_template
@@ -4,8 +4,8 @@ d=""
 
 if [ "$2" == "True" ]; then
   for i in *.0 ; do
-sed -e "s/!VERSION!/${1}/g" -e "s/!DATE!/`date $d '+%B %Y'`/g" < ${i} > ${i%%0}1
+sed -e "s/!VERSION!/${1}/g" -e "s/!DATE!/`date $d '+%Y-%m-%d'`/g" < ${i} > ${i%%0}1
   done
 else
-  sed -e "s/!VERSION!/${1}/g" -e "s/!DATE!/`date $d '+%B %Y'`/g" < jackd.0 > jackd.1
+  sed -e "s/!VERSION!/${1}/g" -e "s/!DATE!/`date $d '+%Y-%m-%d'`/g" < jackd.0 > jackd.1
 fi
-- 
2.39.2

From 021e05e61bc9ae982063d666de33473e391a0602 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 30 Apr 2023 15:52:22 -0700
Subject: [PATCH 2/5] man/fill_template: Use UTC date to avoid differences
 based on timezone.

https://reproducible-builds.org/docs/timezones/
---
 man/fill_template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/fill_template b/man/fill_template
index d1df18d..641cab8 100644
--- a/man/fill_template
+++ b/man/fill_template
@@ -1,6 +1,6 @@
 #!/bin/sh
 d=""
-[ -z "$SOURCE_DATE_EPOCH" ] || d=--date=@$SOURCE_DATE_EPOCH
+[ -z "$SOURCE_DATE_EPOCH" ] || d="--utc --date=@$SOURCE_DATE_EPOCH"
 
 if [ "$2" == "True" ]; then
   for i in *.0 ; do
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1035330: unblock: postgrey/1.37-2

[Jordi Mallach]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: postg...@packages.debian.org
Control: affects -1 + src:postgrey

Please unblock package postgrey

postgrey, in its current state in bookworm, is RC buggy because
among other things it does not install the default config files
due to a too zealous trim of its postinst script.

1.37-2 restores all the lost packaging bits that makes it
again acceptable for the release.

Attached is a debdiff that:

- restores ucf bits so configuration files will be installed
  again
- restores the creation of the postgrey user

[ Impact ]

Without this update, postgrey will be ok-ish for people upgrading
from bullseye, but will be completely broken for new installs.


[ Tests ]

I have manually tested upgrades from:
- 1.36-5.2 (in bullseye) → 1.37-1 (current broken) → 1.37-2 (proposed)
- 1.37-5.2 → 1.37-2

- The same as above, but with config changes, which were correctly handled
  by ucf.

[ Risks ]

The only changes are in packaging, no upstream code changes are
involved.


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

unblock postgrey/1.37-2
diff -Nru postgrey-1.37/debian/changelog postgrey-1.37/debian/changelog
--- postgrey-1.37/debian/changelog  2022-04-21 21:35:13.0 +0200
+++ postgrey-1.37/debian/changelog  2023-05-01 00:57:30.0 +0200
@@ -1,3 +1,14 @@
+postgrey (1.37-2) unstable; urgency=medium
+
+  * Use %H in the service file to set the hostname in the rejection message
+(closes: #1031401).
+  * Add missing ucf machinery so the default config file and whitelists get
+installed correctly (closes: #1033231).
+  * Reinstate creation of postgrey user.
+  * Ensure /var/lib/postgrey exists and is owned by postgrey.
+
+ -- Jordi Mallach   Mon, 01 May 2023 00:57:30 +0200
+
 postgrey (1.37-1) unstable; urgency=medium
 
   * New upstream release (closes: #851571).
diff -Nru postgrey-1.37/debian/postgrey.dirs postgrey-1.37/debian/postgrey.dirs
--- postgrey-1.37/debian/postgrey.dirs  2022-02-01 13:50:22.0 +0100
+++ postgrey-1.37/debian/postgrey.dirs  2023-05-01 00:27:12.0 +0200
@@ -1 +1,2 @@
 /etc/postgrey
+/var/lib/postgrey
diff -Nru postgrey-1.37/debian/postgrey.install 
postgrey-1.37/debian/postgrey.install
--- postgrey-1.37/debian/postgrey.install   2022-02-01 13:50:22.0 
+0100
+++ postgrey-1.37/debian/postgrey.install   2023-03-09 14:34:47.0 
+0100
@@ -1,6 +1,9 @@
-postgrey usr/sbin/
-policy-test  usr/sbin
-contrib/postgreyreport   usr/bin
-postgrey_whitelist_clients   usr/share/postgrey
-postgrey_whitelist_recipientsusr/share/postgrey
-debian/postgrey-default  usr/share/postgrey
+postgreyusr/sbin/
+policy-test usr/sbin
+contrib/postgreyreport  usr/bin
+postgrey_whitelist_clients  usr/share/postgrey
+postgrey_whitelist_recipients   usr/share/postgrey
+debian/postgrey-default usr/share/postgrey
+debian/postgrey-default.md5sum  usr/share/postgrey
+debian/postgrey_whitelist_clients.md5sumusr/share/postgrey
+debian/postgrey_whitelist_recipients.md5sum usr/share/postgrey
diff -Nru postgrey-1.37/debian/postgrey.service 
postgrey-1.37/debian/postgrey.service
--- postgrey-1.37/debian/postgrey.service   2022-02-26 14:07:46.0 
+0100
+++ postgrey-1.37/debian/postgrey.service   2023-03-08 17:22:52.0 
+0100
@@ -6,7 +6,7 @@
 
 [Service]
 Type=simple
-Environment=POSTGREY_TEXT="Greylisted, see 
https://postgrey.schweikert.ch/help/%r.html;
+Environment=POSTGREY_TEXT="Greylisted, see 
https://postgrey.schweikert.ch/help/%H.html;
 EnvironmentFile=-/etc/default/postgrey
 ExecStart=/usr/sbin/postgrey \
  $POSTGREY_OPTS \
diff -Nru postgrey-1.37/debian/postgrey.ucf postgrey-1.37/debian/postgrey.ucf
--- postgrey-1.37/debian/postgrey.ucf   1970-01-01 01:00:00.0 +0100
+++ postgrey-1.37/debian/postgrey.ucf   2023-03-09 16:26:18.0 +0100
@@ -0,0 +1,3 @@
+usr/share/postgrey/postgrey-default /etc/default/postgrey
+usr/share/postgrey/whitelist_clients/etc/postgrey/whitelist_clients
+usr/share/postgrey/whitelist_recipients /etc/postgrey/whitelist_recipients
diff -Nru postgrey-1.37/debian/postgrey_whitelist_clients.md5sum 
postgrey-1.37/debian/postgrey_whitelist_clients.md5sum
--- postgrey-1.37/debian/postgrey_whitelist_clients.md5sum  2022-02-01 
13:50:22.0 +0100
+++ postgrey-1.37/debian/postgrey_whitelist_clients.md5sum  2023-03-09 
14:39:18.0 +0100
@@ -15,3 +15,4 @@
 50848c8868cdc595592881c83f6b2250  1.31-1/postgrey_whitelist_clients
 cb7f6e25df39e1e05317a6dd344fc2c2  1.31-3/postgrey_whitelist_clients
 

Bug#1035329: jackd2: reproducible-builds: Missing manpages when /bin/sh -> dash

[Vagrant Cascadian]

Source: jackd2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Various manpages are missing when built with /bin/sh -> dash:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/jackd2.html

  alsa_in.1.gz jack_bufsize.1.gz jack_connect.1.gz jack_freewheel.1.gz
  jack_impulse_grabber.1.gz jack_iodelay.1.gz jack_load.1.gz
  jack_lsp.1.gz jack_metro.1.gz jack_monitor_client.1.gz
  jack_netsource.1.gz jack_property.1.gz jack_samplerate.1.gz
  jack_showtime.1.gz jack_simple_client.1.gz jack_transport.1.gz
  jack_unload.1.gz jack_wait.1.gz jackrec.1.gz

When built with /bin/sh -> bash, all of these manpages are built and
included in the package.

The attached patch fixes this by using a POSIX compatible comparison
operator (e.g. = vs. ==), which consistently works with both shells.

Thanks for maintaining jackd2!

live well,
  vagrant
From c4196d81e2f92f0664251a04834791952d59a023 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 30 Apr 2023 15:52:59 -0700
Subject: [PATCH 3/5] man/fill_template: Use POSIX compatible comparison.

Bash supports == comparison, but other /bin/sh implementations may
not.
---
 man/fill_template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/fill_template b/man/fill_template
index 641cab8..63642a3 100644
--- a/man/fill_template
+++ b/man/fill_template
@@ -2,7 +2,7 @@
 d=""
 [ -z "$SOURCE_DATE_EPOCH" ] || d="--utc --date=@$SOURCE_DATE_EPOCH"
 
-if [ "$2" == "True" ]; then
+if [ "$2" = "True" ]; then
   for i in *.0 ; do
 sed -e "s/!VERSION!/${1}/g" -e "s/!DATE!/`date $d '+%Y-%m-%d'`/g" < ${i} > ${i%%0}1
   done
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#989632: dash: remove unnecessary diversion of /bin/sh

[Luca Boccassi]

On Sat, 29 Apr 2023 16:32:23 +0100 Luca Boccassi 
wrote:
> 
> MR: https://salsa.debian.org/debian/dash/-/merge_requests/19
> 
> I think we should ship these changes in bookworm. Why?
> 
> - we get diversion-less essential package set already in bookworm
> - we get diversion-less uber-essential dash already in bookworm
> - we get maintainer-script free uber-essential dash in trixie
> - in case we need to go down the canonicalization-by-dh forced
> migration path in trixie to lift the moratorium on moving files, we
> don't have /bin/sh diversions as a blocker and the path remains open
> 
> Yes, I realize it is late, and I wish I had come across this ticket
> some months ago. But we still have time, and the benefits are great
:-)

Alright, this is now in experimental (thanks Andrej), please help with
testing if you can!

-- 
Kind regards,
Luca Boccassi


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

Bug#988127: neomutt hangs for minutes while checking S/MIME signed mails

[Nilesh Patra]

Control: found -1 20220429+dfsg1-4.1

On Thu, 6 May 2021 11:22:27 +0200 Stefano Zacchiroli  wrote:
> retitle 988127 neomutt hangs for minutes while checking S/MIME signed mails
> found 988127 20201127+dfsg.1-1.1
> thanks
> 
> Heya, I've cloned/reassigned this issue from mutt to neomutt, because it
> does happen to me with neomutt right now (version 20201127+dfsg.1-1.1 ),
> exactly as described in the original mutt bug report.

It happens for me also with latest version of neomutt. @Antonio, could
you please consider to investigate this?

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1032899: unblock: rocm-hipamd/5.2.3-6

[Christian Kastner]

Hi Paul,

On 2023-04-30 07:59, Paul Gevers wrote:
> Please go ahead with your 04_ proposal and please remove the moreinfo
> tag once the upload happened.

In -7, there was a typo that broke installability for hipcc,
specifically a version contained a second colon where a dot was expected:

> [...] | libclang-rt-15-dev (>= 1:15:0.6-5~exp1),
^^^
I went ahead with an -8 upload that changes just that one typo, and I
successfully tested all install/upgrade paths for hipcc:
  bookworm: none -> -8
  bookworm:  -1  -> -8
  unstable: none -> -8
  unstable:  -7  -> -8

I'm sorry for the noise. I'm more than puzzled how this could have snuck
in, as I tested the above upgrade paths before proposing the change.

Best,
Christian

Bug#1035328: unblock: redis/5:7.0.11-1

[Chris Lamb]

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

Dear Release Team,

Please consider unblocking redis 5:7.0.11-1 for testing. It fixes a
single a CVE; the refreshing of patches listed in the changelog below
are merely changes to the "index 80a95aa..e8ffe7d 100644" in order to
keep gbp-pq happy:

§
  
  redis (5:7.0.11-1) unstable; urgency=high
  
* New upstream security release: 
  - CVE-2023-28856: Authenticated users could have used the HINCRBYFLOAT
command to create an invalid hash field that would have crashed the 
Redis
server on access. (Closes: #1034613)  

  For more information, please see:  
https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES
  
* Refresh patches.

§

The full debdiff is attached.


Regards,

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


debdiff
Description: Binary data

Bug#1035327: installation-reports: Cannot boot installer with grub2: out of memory

[Marie Janssen]

Package: installation-reports
Severity: important
Tags: d-i
X-Debbugs-Cc: jamu...@debian.org

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/bookworm_di_rc2/amd64/iso-cd/debian-bookworm-DI-rc2-amd64-netinst.iso,
 then eventually 
https://cdimage.debian.org/cdimage/archive/10.0.0-live/amd64/iso-hybrid/debian-live-10.0.0-amd64-standard.iso
Date: 2023 April 27 to 30

Machine: Lenovo Slim 9 14IAP7
Partitions: 
Filesystem Type 1K-blocks Used Available Use% Mounted on
udev   devtmpfs  162725400  16272540   0% /dev
tmpfs  tmpfs  3257784 2428   3255356   1% /run
/dev/nvme0n1p2 ext4 950110932 12509196 889264996   2% /
tmpfs  tmpfs 16288920   195320  16093600   2% /dev/shm
tmpfs  tmpfs 5120   12  5108   1% /run/lock
/dev/nvme0n1p1 vfat52324814164509084   3% /boot/efi
tmpfs  tmpfs  3257784   20   3257764   1% /run/user/1000


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

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

Comments/Problems:

During attempt to install Bookworm RC2 on a new laptop, the bootloader
would not boot with "error: Out of memory." after the initial Grub
screen.

This seems to be related to the size of the initrd and the video being
4K.  It has been present for at least all of Debian 11 as well, as I
moved back in the live USBs and installers to try and find a version
which would boot.  Eventually 10.0 liveusb would work to install
(the second URL above), and then by changing the GRUB_GFXMODE to
'640x480' it would boot after install.

I then upgraded through stable, testing, and finally unstable.

When upgrading, I encountered the bug again, and ended up fixing it
by chaning `MODULES=most` to `MODULES=dep` in
/etc/initramfs-tools/initramfs.conf

>From what I can gather, this is a grub2 bug, and detailed here:
 - https://bugs.launchpad.net/oem-priority/+bug/1842320

The issue seems to be fixed in upstream grub2 later in 2.12 from memory
management, or there are some patches referenced in:
 - https://bugs.launchpad.net/oem-priority/+bug/1842320/comments/96

It was quite frustrating so I am dropping a note here as if it can be
fixed for bookworm it would be wonderful.

-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190702"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux iris 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4641] 
(rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:3804]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:46a6] (rev 0c)
lspci -knn: Subsystem: Lenovo Device [17aa:3803]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Device [8086:461d] (rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:3803]
lspci -knn: 00:05.0 Multimedia controller [0480]: Intel Corporation Device 
[8086:465d] (rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:3806]
lspci -knn: 00:06.0 PCI bridge [0604]: Intel Corporation Device [8086:464d] 
(rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.0 PCI bridge [0604]: Intel Corporation Device [8086:463f] 
(rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.2 PCI bridge [0604]: Intel Corporation Device [8086:462f] 
(rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.3 PCI bridge [0604]: Intel Corporation Device [8086:461f] 
(rev 02)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Device 
[8086:464f] (rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:380d]
lspci -knn: 00:0a.0 Signal processing controller [1180]: Intel Corporation 
Device [8086:467d] (rev 01)
lspci -knn: Subsystem: Lenovo Device [17aa:380f]
lspci -knn: 00:0d.0 USB controller [0c03]: Intel Corporation Device [8086:461e] 
(rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:3810]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:0d.2 USB controller [0c03]: Intel 

Bug#1028290: libreoffice-impress-nogui cannot convert to PNG

[Rene Engelhard]

Hi,

Am 12.01.23 um 17:38 schrieb Rene Engelhard:

This one also works but only with the binary in the instdir-nogui, *not*
if I install the resulting .debs:


Ah, hmm, so that really points to a packaging problem or a problem which 
only exhibitx due to packaging.


 From looking at the initial straces briefly I have an idea but that 
might just be a red herring...


While debugging another issue boiling down to a missing .ui file[1] I 
looked at this one.


It *seems* to be this in your nogui-strace:

94919 21:08:29.439478 openat(AT_FDCWD, 
"/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui/tabviewbar.ui", 
O_RDONLY) = -1 ENOENT (No such file or directory)
94919 21:08:29.439573 --- SIGSEGV {si_signo=SIGSEGV, 
si_code=SEGV_MAPERR, si_addr=NULL} ---
94919 21:08:29.439478 openat(AT_FDCWD, 
"/usr/lib/libreoffice/share/config/soffice.cfg/modules/simpress/ui/tabviewbar.ui", 
O_RDONLY) = -1 ENOENT (No such file or directory)
94919 21:08:29.439573 --- SIGSEGV {si_signo=SIGSEGV, 
si_code=SEGV_MAPERR, si_addr=NULL} ---


And indeed, for libreoffice-*-nogui we do

find 
debian/libreoffice-*-nogui/$(OODIR)/share/config/soffice.cfg -name 
"*.ui" -exec rm {} \;


since those are files for the UI (and thus shoud not(tm) needed if 
there's no (G)UI...)


Now the question is whether we start shipping those UI-Files in nogui 
(which sounds awkward) or try to ship enough that a --convert-to works...


Regards,

Rene

[1] 
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/64bef88bf381d7cce8914bcc7bdd7259dde0ca02

Bug#1035317: grub-pc: /boot on LVM fails if logical volume consists of multiple physical volumes

[Steve McIntyre]

Hi Vagrant!

On Sun, Apr 30, 2023 at 12:56:29PM -0700, Vagrant Cascadian wrote:
>Package: grub-pc
>Version: 2.06-12
>Severity: important
>X-Debbugs-Cc: vagr...@debian.org
>
>When I tried extending the /dev/vvm/root partition to include more
>space from the /dev/vdc1 physical volume, grub fails to load at boot,
>unable to find the lvm volume.
>
>I tried re-installing grub from the debian-installer rescue image, but
>that did not help.
>
>Removing /dev/vdc1 from the volume group fixed the issue, but
>significantly limits the benefit of LVM...
>
>A workaround is, of course, using a separate boot partition, or
>maybe keeping to only a single physical volume for the logical
>volume on which /boot resides.

Can you give us a bit more detail about the system please? With
/dev/vdc, this suggests you're in a VM and this is the third drive
using virtio? How big is /dev/vdc? What's the partition type?

Why am I asking? grub-pc is limited by the platform underneath here
when it comes to assembling RAID or LVM volumes. If a complex disk
setup depends on a drive that can't be seen/read by grub at boot, it's
going to struggle. I'm wondering if this might be the underlying cause
of your issue.

If possible, on your system, could you also reboot and call up a grub
command line (hit "c" from the grub menu)?

>From there, I'd love to see what you get if you run "ls" here...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?

Bug#1035326: greetd: Refers to nonexistent wlgreet package

[Marie Janssen]

Package: greetd
Version: 0.9.0-3
Severity: normal
X-Debbugs-Cc: jamu...@debian.org

Hi Marc:

The greetd package suggests: wlgreet but it is not available, causing
the confusing situation where it's recommended (and seems likely to be
preferred, given the lightdm situation that caused greetd to be added)
but not available.

I'd recommend removing it from Suggests: until #1010248 is resolved.

(filing this against greetd as a breadcrumb for others)

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

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

Versions of packages greetd depends on:
ii  adduser3.132
ii  libc6  2.36-9
ii  libgcc-s1  12.2.0-14
ii  libpam0g   1.5.2-6

greetd recommends no packages.

Versions of packages greetd suggests:
pn  wlgreet  

-- no debconf information

Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[Diederik de Haas]

On Sunday, 30 April 2023 20:25:50 CEST James Addison wrote:
> Do we _need_ to retain the vendor name and model name in the firmware
> filename?
> 
> My guess (without being too familiar with the firmware loading process yet)
> is that it'd be easier to ship a concisely-named file that omit the vendor
> and model strings, so we'd want a way to map:
> 
>   brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt
> 
> To the corresponding, already-packaged[4] filename:
> 
>   brcmfmac43455-sdio.txt
> 
> ...while preferably avoiding adding custom scripting for too many other
> firmware filenames in future.  Where does the long-format filename originate
> from?

I suggest we stick to `brcmfmac43455-sdio.raspberrypi,4-model-b.txt` as that 
is its name in the upstream repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

> And a nitpick: the way this appears in the hw-detect prompt screen in the
> installer is a bit odd, because spaces in the filenames are replaced with
> newlines.  That might be nice to fix at the same time if we can.

AFAIC it's a bit more then a nitpick as it identified a/several bugs in the 
script. Run it through `shellcheck` and you'll see a whole bunch of*:
SC2086 (info): Double quote to prevent globbing and word splitting.
https://www.shellcheck.net/wiki/SC2086

And that's exactly what happens or will happen. Even though the RPi4 filename 
doesn't contain spaces, there are several in the `brcm` directory that do.
I didn't check other directories, but I'd expect that filenames with a space is 
NOT an anomaly.

*) and several other warnings/suggestions

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

Bug#1035325: prctl(2): PR_SET_CHILD_SUBREAPER description is misleading in relation to PID namespaces

[Michael Gold]

Package: manpages-dev
Version: 6.03-1
Severity: minor

Dear Maintainer,

The prctl manual page says:
PR_SET_CHILD_SUBREAPER (since Linux 3.4)
[…]
A subreaper fulfills the role of init(1) for its descendant pro‐
cesses.  When a process becomes orphaned  (i.e.,  its  immediate
parent  terminates), then that process will be reparented to the
nearest still living ancestor subreaper.  […]

Part of the role of init(1) is to remain running while any child process
needs to be running: the kernel will panic if the global init goes away,
and will send SIGKILL to all processes of the namespace whose init dies.
The reference to a "still living" subreaper, however, suggests that this
does not apply to subreapers, and a test program confirms it; therefore,
subreapers do not fulfill the full role of init(1).  That's overly vague
anyway; "man 1 init" references many things a subreaper wouldn't have to
do, and POSIX has only a few passing references to init or PID 1.

Also, the text contradicts pid_namespaces(7), which says:
   When a child process becomes orphaned, it is reparented to the "init"
   process  in the PID namespace of its parent (unless one of the nearer
   ancestors of the parent employed the prctl(2)  PR_SET_CHILD_SUBREAPER
   command […]

A process that dies in a PID namespace could be reparented to its PID 1,
even if "the nearest still living ancestor subreaper" is another process
outside the namespace.

- Michael


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

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

Versions of packages manpages-dev depends on:
ii  manpages  6.03-1

manpages-dev recommends no packages.

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

-- no debconf information


signature.asc
Description: PGP signature

Bug#1035324: shaderc: reproducible-builds: Differences when /bin/sh -> bash

[Vagrant Cascadian]

Source: shaderc
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When /bin/sh points to bash (instead of dash), the behavior of "echo"
differs in the rendering of "\n":

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/shaderc.html

  /usr/bin/glslc

  shaderc·2023.2-1\nspirv-tools·2023.1-2
  vs.
  shaderc·2023.2-1   
  spirv-tools·2023.1-2

The attached patch to debian/rules fixes this by switching to use
printf, which appears to behave consistently regardless of the shell (at
least with my quick testing).

Thanks for maintaining shaderc!

live well,
  vagrant
From 2cc141000791790054677b339e675c2cef150ac0 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 30 Apr 2023 13:51:49 -0700
Subject: [PATCH] debian/rules: Use "printf" instead of "echo" for reproducible
 builds.

The echo implementations of bash and dash may differ, using printf
works around this.
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 4424963..5051e82 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,7 +16,7 @@ override_dh_auto_configure:
 		-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
 
 override_dh_auto_build:
-	echo "\"shaderc $(DEB_VERSION)\\\n\"" > obj-${DEB_HOST_GNU_TYPE}/build-version.inc
+	printf "\"shaderc $(DEB_VERSION)\\\n\"" > obj-${DEB_HOST_GNU_TYPE}/build-version.inc
 	dpkg-query -f '"spirv-tools $${Version}\\n"\n' -W spirv-tools >> obj-${DEB_HOST_GNU_TYPE}/build-version.inc
 	dpkg-query -f '"glslang $${Version}\\n"' -W glslang-dev >> obj-${DEB_HOST_GNU_TYPE}/build-version.inc
 	dh_auto_build
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1035310: bullseye-pu: package xz-utils/5.2.11-0~deb11u1

[Sebastian Andrzej Siewior]

On 2023-04-30 18:43:18 [+0200], Helge Kreutzmann wrote:
> Hello Sebastian,
Hi Helge,

> > - the backport package of manpages-de and manpages-fr provides a
> >   man page for xz. These files conflict with the one provided by
> >   xz-utils package. The bpo package and xz-utils in Bookworm have proper
> >   Breaks: and Replaces: relation to allow smooth upgrades.
> >   This update of xz does not provide such a relation since the current
> >   version of manpages-{de|fr} in Bullseye does not provide this
> >   man page. As per testing, the Breaks: in manpages-{de|fr} forbids
> >   installing of this xz-utils. My understanding is that once these
> >   man pages are visible in Bullseye via xz-utils, the bpo packages of
> >   manpages-l10n stops creating them as part of the build process. They
> >   are not present in testing/ Bookworm version of the package.
> 
> No, we need to coordinate about this. You previously considered doing
> a backport and I asked you several if this is still the case; since
> you did not respond, I did not remove the conflicting pages in my
> bullseye packport. 

I added you to Cc: for reason of coordination. I always intended to do
-pu instead of a bpo. I intended to respond earlier but didn't manage to
do it until now. Sorry for that.

> As bookworm is about to release, I just wonder if that is really
> necessary to introduce the translation files in your backport. I'm all
> about translations, but this is a bit fragile with two backports with
> all the upgrade paths. So hopefully we get this right.

Stable Bullseye, no bpo.

> If you still feel this is necessary for your users, then please
> contact me and I can perform another upload with the file removed and
> appropriate package relationships. (This implies you tell me the
> version which introduces the files.)

I'm waiting for the stable team to confirm or deny my request. Once that
is clear we can see how to move forward.

> Please tell me as well which translated man pages you ship, as there
> are also Danish and Ukrainian ones in my backports.
> 
> Please not that I will not perform uploads to bullseye once bookworm
> has been released.

Only DE and FR made it into the 5.2 series.

> Greetings
> 
>Helge

Sebastian

Bug#1035323: vim: CVE-2023-2426

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for vim.

CVE-2023-2426[0]:
| Use of Out-of-range Pointer Offset in GitHub repository vim/vim prior
| to 9.0.1499.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-2426
https://www.cve.org/CVERecord?id=CVE-2023-2426
[1] https://huntr.dev/bounties/3451be4c-91c8-4d08-926b-cbff7396f425
[2] https://github.com/vim/vim/commit/caf642c25de526229264cab9425e7c9979f3509b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1035320: pdftotext: Manual page incorrectly lists PDF-file as an optional argument

[Michael Gold]

Package: poppler-utils
Version: 22.12.0-2+b1
Severity: minor

Dear Maintainer,

The pdftotext manual page shows the synopsis:
  pdftotext [options] [PDF-file [text-file]]

But it looks like this should be:
  pdftotext [options] PDF-file [text-file]

If run with no PDF-file argument, the program exits with status 99 after
printing a usage message (in which it's not shown as optional).

- Michael


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

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

Versions of packages poppler-utils depends on:
ii  libc6  2.36-9
ii  libcairo2  1.16.0-7
ii  libfreetype6   2.12.1+dfsg-5
ii  liblcms2-2 2.14-2
ii  libpoppler126  22.12.0-2+b1
ii  libstdc++6 12.2.0-14

poppler-utils recommends no packages.

poppler-utils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#940960: ITP: linenoise -- Minimal replacement for readline

[Blair Noctis]

Hi Jeremy,

It's been a few years since this ITP was filed. Do you still plan to package it?
I'm packaging osquery which depends on this. Happy to help ;)

-- 
Sdrager,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035321: parsing of 'git log' seems to break when commits are signed

[John Scott]

Package: dh-make-golang
Version: 0.6.0-2+b5
Severity: normal
Control: block 1035318 by -1

It looks like dh-make-golang fails when the commits are signed, and this
makes me unable to package the rtltcp library:

$ dh-make-golang make -type "library" github.com/bemasher/rtltcp
2023/04/30 15:46:18 Starting "dh-make-golang v0.6.0 linux/amd64"
2023/04/30 15:46:18 Downloading "github.com/bemasher/rtltcp/..."
2023/04/30 15:46:21 Determining upstream version number
2023/04/30 15:46:21 Could not create a tarball of the upstream source: get 
package version from Git: parse last commit date: strconv.ParseInt: parsing 
"gpg: Signature made Sun 30 Apr 2023 03:27:39 PM EDT\ngpg:using 
RSA key 4AEE18F83AFDEB23\ngpg: Good signature from \"GitHub (web-flow commit 
signing) \" [marginal]\ngpg: nore...@github.com: Verified 
120 signatures in the past 2 years.  Encrypted\n 0 messages.\ngpg: Warning: 
you have yet to encrypt a message to this key!\ngpg: WARNING: This key is not 
certified with sufficiently trusted signatures!\ngpg:  It is not 
certain that the signature belongs to the owner.\n  
5DE3E0509C47EA3CF04A42D34AEE18F83AFDEB23\n1682882859": invalid syntax

If this is not a trivial fix, if anyone knows of a workaround so I can
do my packaging, that would be nice.

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

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

Versions of packages dh-make-golang depends on:
ii  git   1:2.39.2-1.1
ii  git-buildpackage  0.9.30
ii  golang-any    2:1.19~1
ii  libc6 2.36-8
ii  pristine-tar  1.50

Versions of packages dh-make-golang recommends:
ii  golang-golang-x-tools 1:0.5.0+ds-1
ii  msmtp-mta [mail-transport-agent]  1.8.23-1

dh-make-golang suggests no packages.

-- no debconf information



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


smime.p7s
Description: S/MIME cryptographic signature

Bug#1035319: coreutils: pr: -d ejects extraneous line at last page

[наб]

Package: coreutils
Version: 9.1-1
Severity: normal

Dear Maintainer,

Correct (minimised example):
-- >8 --
% echo a | pr -f | cat -A | tr -s ' '
$
$
2023-04-30 22:09 Page 1$
$
$
a$
^L
-- >8 --

Incorrect:
-- >8 --
% echo a | pr -fd | cat -A | tr -s ' '
$
$
2023-04-30 22:10 Page 1$
$
$
a$
$
$
^L
-- >8 --

POSIX mandates that -d doubles any ejected newline.
pr(1) uses the same description as the posix short-name.

Correct output would be:
-- >8 --
% echo a | out/cmd/pr -fdm   | cat -A | tr -s ' '
$
$
2023-04-30 22:11 Page 1$
$
$
a$
$
^L
-- >8 --
i.e. the original newline + another empty line, then page feed.

Best,
наб

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b5

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1035318: ITP: golang-github-bemasher-rtltcp -- Go library interface to an rtltcp daemon

[John Scott]

Package: wnpp
Severity: wishlist
Owner: John Scott 
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: block 1025210 by -1

* Package name: golang-github-bemasher-rtltcp
* URL : https://github.com/bemasher/rtltcp
* License : AGPLv3
  Programming Lang: Go
  Description : Go library interface to an rtltcp daemon

This is a Go library that allows programs a high-level means of
interacting with rtltcp, a daemon that allows for remote control of an
RTL-SDR (if you're familiar with SoapyRemote, it's similar).

This is the last remaining dependency for packaging rtlamr, a program
from the same author.

Note that this library is under the AGPLv3, not the ordinary GPL, so
applications that use it need to be AGPL-compatible (generally means
AGPL or GPL), and then the final binary is subject to the AGPL. I'm
aware of the recent discussions around Berkeley DB and how problematic
this can be for programs that aren't traditionally thought of as being
network-facing, but since rtlamr is by the same author under the same
license and thought to be its only user, my opinion is that this is
pretty insignificant. If other programs use this library someday, of
course, we'll have to check that they are respectful of the license.

I will maintain this in the Debian Go Team's umbrella and in accordance
with their practices because it's written in Go, but it will be used
mostly by ham radio folks. I'm not a Debian Developer or Maintainer, so
I'm grateful to have already identified a possible sponsor who is
knowledgeable in both areas.


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#1035316: [pre-approval request] unblock: firmware-nonfree/20230210-5

[Salvatore Bonaccorso]

Hi,

On Sun, Apr 30, 2023 at 09:53:25PM +0200, Salvatore Bonaccorso wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: firmware-nonf...@packages.debian.org, k...@debian.org, 
> debian-b...@lists.debian.org, debian-ker...@lists.debian.org, 
> car...@debian.org
> Control: affects -1 + src:firmware-nonfree
> 
> Dear release team,
> 
> Please unblock package firmware-nonfree
> 
> [ Reason ]
> A piuparts run from Andreas found that we had broken symlink for
> two firmware files in firmware-brcm80211, cf. #1035282. The reason was
> that we missed a rename back in upstream 20220411, included in the
> upload in Debian as 20210208-1.

Might be obvious, but I got the versions wrong for this unblock
request. Should be the rename was done in upstream 20220411 and so
included first in 20220913-1.

Regards,
Salvatore

Bug#1035316: [pre-approval request] unblock: firmware-nonfree/20230210-5

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: firmware-nonf...@packages.debian.org, k...@debian.org, 
debian-b...@lists.debian.org, debian-ker...@lists.debian.org, car...@debian.org
Control: affects -1 + src:firmware-nonfree

Dear release team,

Please unblock package firmware-nonfree

[ Reason ]
A piuparts run from Andreas found that we had broken symlink for
two firmware files in firmware-brcm80211, cf. #1035282. The reason was
that we missed a rename back in upstream 20220411, included in the
upload in Debian as 20210208-1.

[ Impact ]
Loading of firmware for Rock960 Cypress 4356 WiFi, and those using
VIM2 4356 WiFi devices would not work.

[ Tests ]
None additional done specifically to the change apart the packaging
build pipeline and verifying that the links are now correctly placed.

[ Risks ]
Adds the missing symlinks for the firmware files.

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

[ Other info ]
As beeing the firmware-nonfree package, I'm explicitly CC'ing as well
Cyril on this pre-approval request.

Furthermore the attached debdiff still contains the UNRELEASED
changelog entry, which will be switched for the upload.

The upload adds as well one further additional link for
brcmfmac4356-sdio.firefly,firefly-rk3399.txt to mirror all changes
upstream did with
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=4ffcf980a535c1f26aa994ecf64a1b9d1ed6216e
.

unblock firmware-nonfree/20230210-5

Regards,
Salvatore
diff -Nru firmware-nonfree-20230210/debian/changelog 
firmware-nonfree-20230210/debian/changelog
--- firmware-nonfree-20230210/debian/changelog  2023-03-11 15:15:03.0 
+0100
+++ firmware-nonfree-20230210/debian/changelog  2023-04-30 07:31:54.0 
+0200
@@ -1,3 +1,11 @@
+firmware-nonfree (20230210-5) UNRELEASED; urgency=medium
+
+  * brcm80211: brcm: rename Rock960 NVRAM to AP6356S and link devices to it
+(Closes: #1035282)
+  * Update to linux-support 6.1.0-8
+
+ -- Salvatore Bonaccorso   Sun, 30 Apr 2023 07:31:54 +0200
+
 firmware-nonfree (20230210-4) unstable; urgency=medium
 
   * iwlwifi: Add missing files entry for iwlwifi-so-a0-hr-b0-72.ucode.
diff -Nru firmware-nonfree-20230210/debian/config/brcm80211/defines 
firmware-nonfree-20230210/debian/config/brcm80211/defines
--- firmware-nonfree-20230210/debian/config/brcm80211/defines   2023-03-11 
14:25:34.0 +0100
+++ firmware-nonfree-20230210/debian/config/brcm80211/defines   2023-04-30 
07:30:52.0 +0200
@@ -59,8 +59,10 @@
  brcm/brcmfmac4356-pcie.clm_blob
  brcm/brcmfmac4356-sdio.bin
  brcm/brcmfmac4356-sdio.clm_blob
- brcm/brcmfmac4356-sdio.vamrs,rock960.txt
+ brcm/brcmfmac4356-sdio.AP6356S.txt
+ brcm/brcmfmac4356-sdio.firefly,firefly-rk3399.txt
  brcm/brcmfmac4356-sdio.khadas,vim2.txt
+ brcm/brcmfmac4356-sdio.vamrs,rock960.txt
  brcm/brcmfmac4358-pcie.bin
  brcm/brcmfmac43602-pcie.ap.bin
  brcm/brcmfmac43602-pcie.bin
@@ -192,8 +194,8 @@
 [brcm/brcmfmac4356-pcie.gpd-win-pocket.txt_base]
 desc: Broadcom BCM4356-PCIe NVRAM for GPD Pocket and Win
 
-[brcm/brcmfmac4356-sdio.vamrs,rock960.txt_base]
-desc: Rock960 Cypress 4356 WiFi 
+[brcm/brcmfmac4356-sdio.AP6356S.txt_base]
+desc: Broadcom AP6356S WiFi module NVRAM
 
 [brcm/brcmfmac4358-pcie.bin_base]
 desc: Broadcom BCM4358 firmware
diff -Nru firmware-nonfree-20230210/debian/control 
firmware-nonfree-20230210/debian/control
--- firmware-nonfree-20230210/debian/control2023-03-11 15:15:03.0 
+0100
+++ firmware-nonfree-20230210/debian/control2023-04-30 07:31:54.0 
+0200
@@ -1407,6 +1407,11 @@
   * Broadcom BCM43569 firmware (brcm/brcmfmac43569.bin)
   * Broadcom BCM4356-PCIe NVRAM for GPD Pocket and Win
 (brcm/brcmfmac4356-pcie.gpd-win-pocket.txt)
+  * Broadcom AP6356S WiFi module NVRAM
+(brcm/brcmfmac4356-sdio.AP6356S.txt,
+brcm/brcmfmac4356-sdio.firefly,firefly-rk3399.txt,
+brcm/brcmfmac4356-sdio.khadas,vim2.txt,
+brcm/brcmfmac4356-sdio.vamrs,rock960.txt)
   * Broadcom BCM4358 firmware (brcm/brcmfmac4358-pcie.bin)
   * Broadcom BCM43602 AP-mode firmware (brcm/brcmfmac43602-pcie.ap.bin)
   * Broadcom BCM43602 firmware (brcm/brcmfmac43602-pcie.bin)
diff -Nru firmware-nonfree-20230210/debian/control.md5sum 
firmware-nonfree-20230210/debian/control.md5sum
--- firmware-nonfree-20230210/debian/control.md5sum 2023-03-11 
15:15:03.0 +0100
+++ firmware-nonfree-20230210/debian/control.md5sum 2023-04-30 
07:31:54.0 +0200
@@ -1,5 +1,5 @@
 756f19279d2cfa999df58e6455f10465  debian/bin/gencontrol.py
-2ef82c26fcd61901f230fcbd975e12c5  debian/build/version-info
+292ee54d1efa3dd0e5f82b863b8c46c6  debian/build/version-info
 29c8d86cbba7d798701946b1d990539e  debian/templates/control.binary.in
 c03e4b00d7d344da35e815e921d78018  debian/templates/control.extra.in
 

Bug#1035317: grub-pc: /boot on LVM fails if logical volume consists of multiple physical volumes

[Vagrant Cascadian]

Package: grub-pc
Version: 2.06-12
Severity: important
X-Debbugs-Cc: vagr...@debian.org

When I tried extending the /dev/vvm/root partition to include more
space from the /dev/vdc1 physical volume, grub fails to load at boot,
unable to find the lvm volume.

I tried re-installing grub from the debian-installer rescue image, but
that did not help.

Removing /dev/vdc1 from the volume group fixed the issue, but
significantly limits the benefit of LVM...

A workaround is, of course, using a separate boot partition, or
maybe keeping to only a single physical volume for the logical
volume on which /boot resides.

live well,
  vagrant

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/vvm-root / ext4 rw,noatime,errors=remount-ro 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod part_msdos
insmod lvm
insmod ext2
set 
root='lvmid/17euUh-PdVv-AWIZ-DlB4-K7Ti-b3bC-vMeyGx/wV7IZ1-sDuZ-S8Ew-nHdx-8n9j-Nm8o-FN58ZV'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/17euUh-PdVv-AWIZ-DlB4-K7Ti-b3bC-vMeyGx/wV7IZ1-sDuZ-S8Ew-nHdx-8n9j-Nm8o-FN58ZV'
  f8de7cbd-35ba-4c27-bc8d-97cbde5bffc4
else
  search --no-floppy --fs-uuid --set=root f8de7cbd-35ba-4c27-bc8d-97cbde5bffc4
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=C
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-f8de7cbd-35ba-4c27-bc8d-97cbde5bffc4' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod part_msdos
insmod lvm
insmod ext2
set 
root='lvmid/17euUh-PdVv-AWIZ-DlB4-K7Ti-b3bC-vMeyGx/wV7IZ1-sDuZ-S8Ew-nHdx-8n9j-Nm8o-FN58ZV'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/17euUh-PdVv-AWIZ-DlB4-K7Ti-b3bC-vMeyGx/wV7IZ1-sDuZ-S8Ew-nHdx-8n9j-Nm8o-FN58ZV'
  f8de7cbd-35ba-4c27-bc8d-97cbde5bffc4
else
  search --no-floppy --fs-uuid --set=root 
f8de7cbd-35ba-4c27-bc8d-97cbde5bffc4
fi
echo'Loading Linux 6.1.0-8-amd64 ...'
linux   /boot/vmlinuz-6.1.0-8-amd64 root=/dev/mapper/vvm-root ro  quiet
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-6.1.0-8-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-f8de7cbd-35ba-4c27-bc8d-97cbde5bffc4' {
menuentry 'Debian GNU/Linux, with Linux 6.1.0-8-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-6.1.0-8-amd64-advanced-f8de7cbd-35ba-4c27-bc8d-97cbde5bffc4' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_gpt
insmod part_msdos
insmod lvm
insmod ext2
set 

Bug#1035315: virtualbox: clicking minimize button while fullscreen causes mouse to stop being able to click

[Andres Salomon]

Package: virtualbox
Version: 7.0.6-dfsg-1~fto11+1

On my wife's laptop which is running bullseye (very recently updated to 
the 11.7 point release), a new bug seems to have been introduced 
somewhere. She's got a Windows 10 VM inside of Virtualbox, and is using 
virtualbox-dkms and virtualbox-guest-additions-iso packages to do real 
full screen. When in fullscreen mode, if she clicks on the *virtualbox* 
minimize button that's at the bottom of the screen, she's no longer 
able to click on anything inside of the windows VM window. If she 
instead clicks Ctrl-F to exit fullscreen and then clicks on the *gnome* 
minimize button at the top of the VM window, it successfully minimizes 
without breaking mouse clicks.


Once the bug is triggered and she can no longer click on anything, the 
only way to restore functionality is by shutting down the windows VM 
(clicking on the VM window's close button to either force power off or 
save machine state, navigating by keyboard since she can't click 
anything inside of that window), and then starting up windows again. 
After it restarts (or restores the machine state), things are clickable 
again.


This is a pretty stock 11.7 gnome environment under wayland, with 
linux-image-5.10.0-22-amd64 5.10.178-3. I'm unclear if this issue 
started with the newer kernel upgrade during the point release (11.6 -> 
11.7), or if it was with a virtualbox upgrade (she was previously 
running the 7.0.5 package that you uploaded to fasttrack). When she was 
using the laptop yesterday, this bug was not present.


I'm happy to have her test 7.0.8 if you have a version that's built for 
bullseye fto if you think that this regression is already fixed.

Bug#1035314: cron:i386 : PreDepends: cron-daemon-common:i386 but it is not installable

[Marc Lehmann]

Package: cron
Version: 3.0pl1-137
Severity: normal

Dear Maintainer,

* What led up to the situation?

Updating a multiarch (amd64 & i386) system from bullseye to bookworm.

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

cron was the only package that dist-upgrade didn't upgrade, so I tried:

   apt upgrade cron:i386

* What was the outcome of this action?

   The following packages have unmet dependencies:
cron:i386 : PreDepends: cron-daemon-common:i386 but it is not installable

* What outcome did you expect instead?

cron gets upgraded, along with any dependent packages.

-- Package-specific info:
--- EDITOR:
not set

--- /usr/bin/editor:
/usr/bin/vim.nox

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 43568 Feb 22  2021 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 1 root root 42 Dec 23  2019 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 1 root crontab 24 Aug  5  2021 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 1 root root 264 Feb 15 06:16 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 1 root root 508 Feb 23 06:27 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 1 root root 24 Aug 15  2021 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 1 root root 46 Aug 20  2021 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 1 root root 152 Aug 15  2021 /etc/cron.weekly

Bug#1035313: pstricks causes gray output of xdvi

[Al Ma]

Package: texlive-pstricks
Version: 2022.20221123-1
Control: affects -1 ghostscript
Feed mwe.tex containing
\documentclass{article}
\usepackage{pstricks}
\begin{document}
Test
\end{document}
to `latex`, then issue `xdvi mwe` from an xterm under X11+gnome, and finally 
observe the visual output https://i.stack.imgur.com/UYZKG.png 
https://i.stack.imgur.com/UYZKG.png.
On the console,
gs:
gs:  WARNING: Transparency operations ignored - need to use 
-dALLOWPSTRANSPARENCY
gs:
gs:
is printed.
This is strange. The input file has no transparency whatsoever. In fact, 
pstricks is not even used. Further, there's IMHO no way for xdvi to pass the 
option `-dALLOWPSTRANSPARENCY` to gs. Finally, the graphical output should be 
black, and not gray.
Presumably, updating texlive-pstricks or ghostscript might solve the problem, 
but which versions of which packages would be the smallest to have the fix? 
Versions used in this question:
• Debian package texlive 2022.20221123-1,
• Debian package texlive-binaries 2022.20220321.62855-4+b1,
• Debian package ghostscript 9.53.3~dfsg-7+deb11u4,
• `latex` has version `pdfTeX 3.141592653-2.6-1.40.24 (TeX Live 2022/Debian)`,
• `xdvi` has version 22.87.06,
• `pstricks.sty` has version 2022/19/23 v0.72, and
• `gs` has version 9.53.3.
I don't wish to update the machine in this very bug report myself without being 
advised because this might trigger newer bugs, and rollbacks sometimes failed 
in the past.

Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[James Addison]

Followup-For: Bug #1029843
X-Debbugs-Cc: a.dalm2...@googlemail.com, p...@akeo.ie, 
debian-b...@lists.debian.org
Control: reassign -1 hw-detect
Control: merge -1 1030519
Control: affects -1 raspi-firmware
Control: title -1  check-missing-firmware: patch for files with space 
characters, mediamount and more (with code)

Hi Alexander,

Thanks for these reports - I was attempting a netboot of the Bookworm RC 2
installer on a Raspberry Pi and ran into the same problem: hw-detect attempting
to load firmware files that contain spaces in the filename.

I've added Pete on cc - he noticed this issue too a few years ago, while
documenting how to install regular Debian 11 on a RPi.

Quoting some notes from his guide[1]:

>  Also, if you did install the Wifi firmware blobs, you may find that you get 
> the following error during boot:
...
> To fix that, simply rename /lib/firmware/brcm/brcmfmac43455-sdio.Raspberry to 
> /lib/firmware/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 
> Model B.txt.


Let's merge this with your linked bug #1030519 - I agree that the hw-detect
package seems to be the location of the relevant scripting[2].  Do you have an
account on Salsa[3] to offer fixes back to Debian git repositories?


I have some code review / comments about the patches, focusing only on the
filename problem to begin with:

Do we _need_ to retain the vendor name and model name in the firmware filename?

My guess (without being too familiar with the firmware loading process yet)
is that it'd be easier to ship a concisely-named file that omit the vendor and
model strings, so we'd want a way to map:

  brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt

To the corresponding, already-packaged[4] filename:

  brcmfmac43455-sdio.txt

...while preferably avoiding adding custom scripting for too many other
firmware filenames in future.  Where does the long-format filename originate
from?

It seems unlikely that this should be fixed for Bookworm, but I can offer some
assistance with further testing, and hopefully we can improve this for Trixie.

And a nitpick: the way this appears in the hw-detect prompt screen in the
installer is a bit odd, because spaces in the filenames are replaced with
newlines.  That might be nice to fix at the same time if we can.

Thanks,
James

[1] - https://forums.raspberrypi.com/viewtopic.php?t=282839

[2] - 
https://salsa.debian.org/installer-team/hw-detect/-/blob/f76d36b65aa14a14497f5ef57c9721f313ea98e6/check-missing-firmware.sh#L154-187

[3] - https://salsa.debian.org/

[4] - https://packages.debian.org/bookworm/all/raspi-firmware/filelist

Bug#948674: Any news on the otter browser packaging?

[Martin Quinson]

Hello Gürkan,

Le samedi 29 avril 2023 à 23:18 +0200, Gürkan Myczko a écrit :
> 
> Here's what I have, best to use dget on it:
> http://sid.ethz.ch/debian/otter-browser/

It looks very good to me. Would you consider uploading it to the archive,
either directly or through the mentoring system, maybe ?

Thanks for your work,
Mt


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

Bug#1035312: minetest: New upstream version available (5.7.0)

[Nelson A. de Oliveira]

Source: minetest
Severity: wishlist
X-Debbugs-Cc: nao...@gmail.com

Hi!

When possible, could we have the latest upstream version (5.7.0)
packaged, please?

Thank you!

Best regards,
Nelson

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

Kernel: Linux 6.1.0-8-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#1035295: RFS: gl4es/1.1.4-1 -- GL4ES - OpenGL 2.1/1.5 to GLES 2.0/1.1 translation library

[Bastian Germann]

Control: tags -1 moreinfo

Please file an ITP to the wnpp pseudo package first. When that is done, please reference it in debian/changelog and 
untag moreinfo.

Bug#1034639: unblock: spamassassin/4.0.0-5

[Noah Meyerhans]

Control: tags -1 - moreinfo

On Sun, Apr 30, 2023 at 08:08:55AM +0200, Paul Gevers wrote:
> > Please go ahead and remove the moreinfo tag once the upload happened.
> 
> Already several years we don't accept uploader built binaries in testing.
> Unfortunately, we can't binNMU arch:all binaries, so please upload a
> no-change *source only* version 4.0.0-6.

*sigh* Done, with apologies.

Bug#1035310: bullseye-pu: package xz-utils/5.2.11-0~deb11u1

[Helge Kreutzmann]

Hello Sebastian,
On Sun, Apr 30, 2023 at 06:23:20PM +0200, Sebastian Andrzej Siewior wrote:
> Package: release.debian.org
> Control: affects -1 + src:xz-utils
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: bullseye
> Severity: normal
> 
> This is a stable update of the xz-utils package as provide project's
> upstream (fixes only, no new features).
> A user visible change is that more localized man-pages (de, fr) and
> translations (es, pt, ro, …) for xz are available. The german man pages
> were provided by the manpages-de package (manpages-l10n source package)
> but were dropped shortly before the Bullseye release.

Correct, we discussed this in the past when we reviewed the
appropriate package relationships.

> xz-utils v5.2.7 to v5.2.9 was uploaded to unstable. Lessons learned:

> - the backport package of manpages-de and manpages-fr provides a
>   man page for xz. These files conflict with the one provided by
>   xz-utils package. The bpo package and xz-utils in Bookworm have proper
>   Breaks: and Replaces: relation to allow smooth upgrades.
>   This update of xz does not provide such a relation since the current
>   version of manpages-{de|fr} in Bullseye does not provide this
>   man page. As per testing, the Breaks: in manpages-{de|fr} forbids
>   installing of this xz-utils. My understanding is that once these
>   man pages are visible in Bullseye via xz-utils, the bpo packages of
>   manpages-l10n stops creating them as part of the build process. They
>   are not present in testing/ Bookworm version of the package.

No, we need to coordinate about this. You previously considered doing
a backport and I asked you several if this is still the case; since
you did not respond, I did not remove the conflicting pages in my
bullseye packport. 

As bookworm is about to release, I just wonder if that is really
necessary to introduce the translation files in your backport. I'm all
about translations, but this is a bit fragile with two backports with
all the upgrade paths. So hopefully we get this right.

If you still feel this is necessary for your users, then please
contact me and I can perform another upload with the file removed and
appropriate package relationships. (This implies you tell me the
version which introduces the files.)

Please tell me as well which translated man pages you ship, as there
are also Danish and Ukrainian ones in my backports.

Please not that I will not perform uploads to bullseye once bookworm
has been released.

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1032899: unblock: rocm-hipamd/5.2.3-6

[Christian Kastner]

Control: tags -1 - moreinfo

Hi Paul,

On 2023-04-30 07:59, Paul Gevers wrote:
>> I may be misunderstanding something here. I interpreted your t-p-u hint
>> for the case where a fix via unstable wouldn't be possible because of
>> the dependency issue. The proposal, however would work via unstable.
> 
> It was for *me*. I reviewed the version in unstable and had some
> concerns. Due to the size of the debdiff, it's easier to look at the
> proposed delta to unstable (that I reviewed), than to review from scratch.

Got it.

> Please go ahead with your 04_ proposal and please remove the moreinfo
> tag once the upload happened.
Best,
Christian

Bug#1034986: xmorph: missing Breaks+Replaces for libmorph when upgrading from bullseye

[Andreas Metzler]

On 2023-04-29 Andreas Metzler  wrote:
[...]

> Trivial patch:
[...]

I will fix this.

cu Andreas

Bug#1035309: unblock: debian-cd/3.2.1

[Cyril Brulebois]

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

Hi,

[ Reason ]
[ Impact ]
While not absolutely needed to have in bookworm, it looks like a good
idea to ship the tooling that's making the release possible.

[ Tests ]
We appear to have built D-I Bookworm RC 1 with the proposed changes
minus the last one (zstd), and D-I Bookworm RC 2 with the proposed
changes, and I think it worked OK! :)

[ Risks ]
We're mostly removing references to old tools, and pulling an extra
package on installation images (that was being pulled later on during
the installation process so that's not a huge change anyway).

The remaining one (symlinks vs. hardlinks) could have been worrying. The
aim is to support people doing weird things with the images we produce,
and it could possibly regress for people who don't. Needless to say,
firmware support is getting extensively tested with various machines,
including laptops pulling up to 5 firmware packages, and there were no
regressions spotted there.

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

[ Other info ]
Thanks for all your hard work.

unblock debian-cd/3.2.1


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru debian-cd-3.2.0/debian/changelog debian-cd-3.2.1/debian/changelog
--- debian-cd-3.2.0/debian/changelog2023-02-24 17:04:14.0 +0100
+++ debian-cd-3.2.1/debian/changelog2023-04-30 18:11:17.0 +0200
@@ -1,3 +1,20 @@
+debian-cd (3.2.1) unstable; urgency=medium
+
+  [ James Addison ]
+  * firmware: use hard links rather than symlinks. Closes: #1031696
+
+  [ Steve McIntyre ]
+  * Kill loadlin, nobody has DOS any more. Also Stop copying the
+/tools directory from the mirror, as that's all that's left there
+now.
+
+  [ Cyril Brulebois ]
+  * tools/generate_di+k_list: Add zstd alongside initramfs-tools and
+busybox, since it's now getting installed by base-installer (starting
+with 1.212).
+
+ -- Cyril Brulebois   Sun, 30 Apr 2023 18:11:17 +0200
+
 debian-cd (3.2.0) unstable; urgency=medium
 
   [ Cyril Brulebois — high-level summary ]
diff -Nru debian-cd-3.2.0/docs/makefile.html debian-cd-3.2.1/docs/makefile.html
--- debian-cd-3.2.0/docs/makefile.html  2021-04-23 04:39:28.0 +0200
+++ debian-cd-3.2.1/docs/makefile.html  2023-04-01 00:15:03.0 +0200
@@ -38,10 +38,6 @@
 ok:
 Simple sanity checking.
 
-$(MIRROR)/doc:, $(MIRROR)/tools: and
-need-complete-mirror
-Ensure that we have all the needed pieces of the archive.
-
 General initialisation and cleanup
 
 init:
diff -Nru debian-cd-3.2.0/tools/boot/bookworm/boot-x86 
debian-cd-3.2.1/tools/boot/bookworm/boot-x86
--- debian-cd-3.2.0/tools/boot/bookworm/boot-x862023-02-24 
17:01:54.0 +0100
+++ debian-cd-3.2.1/tools/boot/bookworm/boot-x862023-04-01 
00:15:03.0 +0200
@@ -157,15 +157,6 @@
 cp -lf $disk $CDDIR/$INSTALLDIR/$dir
 fi
 done
-
-if [ -e "$MIRROR/tools" ] && \
-   [ ! -e $CDDIR/tools ] && \
-   [ "$OMIT_DOC_TOOLS" != "1" ] ; then
-echo "Adding tools to CD1"
-$BASEDIR/tools/add_files $CDDIR $MIRROR tools
-# Remove the win32-loader/ subdirectory from tools, as d-i 
already installs setup.exe
-rm -Rf $CDDIR/tools/win32-loader
-fi
 fi
 
 case "$DESKTOP" in
@@ -187,9 +178,6 @@
 mkdir -p $CDDIR/$INSTALLDIR
 cp -lf cdrom/vmlinuz $CDDIR/$INSTALLDIR/
 cp -lf cdrom/initrd.gz $CDDIR/$INSTALLDIR/
-if [ -e $CDDIR/tools/loadlin.exe ]; then
-echo "\\tools\\loadlin.exe vmlinuz initrd=initrd.gz" | todos > 
$CDDIR/$INSTALLDIR/install.bat
-fi
 
 # In case of a multi-arch CD the script will be called two times. The
 # first time the isolinux dir gets set up for single arch; if it is
diff -Nru debian-cd-3.2.0/tools/boot/kali-dev/boot-x86 
debian-cd-3.2.1/tools/boot/kali-dev/boot-x86
--- debian-cd-3.2.0/tools/boot/kali-dev/boot-x862023-02-24 
17:01:54.0 +0100
+++ debian-cd-3.2.1/tools/boot/kali-dev/boot-x862023-04-01 
00:15:03.0 +0200
@@ -157,15 +157,6 @@
 cp -lf $disk $CDDIR/$INSTALLDIR/$dir
 fi
 done
-
-if [ -e "$MIRROR/tools" ] && \
-   [ ! -e $CDDIR/tools ] && \
-   [ "$OMIT_DOC_TOOLS" != "1" ] ; then
-echo "Adding tools to CD1"
-$BASEDIR/tools/add_files $CDDIR $MIRROR tools
-# Remove the win32-loader/ subdirectory from tools, as d-i 
already installs setup.exe
-rm -Rf $CDDIR/tools/win32-loader
-fi
 fi
 
 case "$DESKTOP" in
@@ -187,9 +178,6 @@
 mkdir -p $CDDIR/$INSTALLDIR
 cp -lf cdrom/vmlinuz 

Bug#1035308: jackd2: missing man page for alsa_in/alsa_out (alsa_io)

[Francesco Poli (wintermute)]

Package: jackd2
Version: 1.9.21~dfsg-2
Severity: minor

Hello!

I've recently found out about alsa_in and alsa_out, which seem to be
useful tools to support additional sound cards.

But where's the man page for these two tools?
There seems to be [one] in Debian/bullseye (jackd2/1.9.17~dfsg-1)

[one]: 

But, apparently, package jackd2 somehow lost this man page since the
time bullseye was released as stable...

Was this man page intentionally dropped?
Why? I cannot find any trace in /usr/share/doc/jackd2/changelog.Debian.gz

Or was the man page dropped by accident?
If so, please re-enable it. The man page seems to be included in
the [source] package, but not in the binary package:

  $ dpkg -L jackd2 | grep man/
  /usr/share/man/man1
  /usr/share/man/man1/jackd.1.gz

[source]: 


I am not sure whether this fix is considered an [appropriate] change during
the hard freeze: maybe it is a documentation fix?!?
In case it is not, it's anyway OK, if you fix this bug after bookworm is out.

[appropriate]: 



Thanks for your time and dedication!


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

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

Versions of packages jackd2 depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libasound2 1.2.8-1+b1
ii  libc6  2.36-9
ii  libdbus-1-31.14.6-1
ii  libexpat1  2.5.0-1
ii  libgcc-s1  12.2.0-14
ii  libjack-jackd2-0   1.9.21~dfsg-2
ii  libopus0   1.3.1-3
ii  libreadline8   8.2-1.3
ii  libsamplerate0 0.2.2-3
ii  libsndfile11.2.0-1
ii  libstdc++6 12.2.0-14
ii  libsystemd0252.6-1
ii  libzita-alsa-pcmi0 0.6.1-1
ii  libzita-resampler1 1.8.0-2
ii  python33.11.2-1+b1
ii  python3-dbus   1.3.2-4+b1

Versions of packages jackd2 recommends:
pn  jackd2-firewire  
ii  libpam-modules   1.5.2-6
ii  qjackctl 0.9.9-1

Versions of packages jackd2 suggests:
pn  jack-tools   
pn  meterbridge  

-- debconf information excluded

Bug#1035305: Bugs on Debian 12 RC2

[Cyril Brulebois]

Control: retitle -1 Bugs on Debian 12 RC2
Control: submitter -1 pham...@bluewin.ch

Hi Philippe,

pham...@bluewin.ch  (2023-04-29):
> Configure network: [ X]
> 
> - WAP3 support from the installer is required. My Laptop (Dell XPS
> 9520) does not have an RJ-45 connection, it only has Wifi available
> like many machines today. My router is configured in WAP3 only... This
> complicates things a lot during installation.

To reiterate my answer from debian-boot@ earlier[1], we don't support
WPA3 in the installer yet (now tracked via #1035306[2]). Be it within the
installer or outside it, a custom workaround when native connectivity
isn't working (for whatever reason) is using an USB-to-Ethernet adapter.

  1. https://lists.debian.org/debian-boot/2023/04/msg00351.html
  2. https://bugs.debian.org/1035306

> - The problem to solve which is present in all intermediate versions
> of Debian is related to sources.list. It lacks the following
> information :
> 
> # Bookworm base repository
> deb https://deb.debian.org/debian bookworm main non-free-firmware
> deb-src https://deb.debian.org/debian bookworm main non-free-firmware
> #
> # Bookworm-updates
> deb https://deb.debian.org/debian bookworm-updates main non-free-firmware
> deb-src https://deb.debian.org/debian bookworm-updates main non-free-firmware
> # 
> # Security updates
> deb https://deb.debian.org/debian-security/ bookworm-security main 
> non-free-firmware
> deb-src https://deb.debian.org/debian-security/ bookworm-security main 
> non-free-firmware
> #
> # Proposed-updates (versions intermédiaires)
> # deb https://deb.debian.org/debian bookworm-proposed-updates main contrib 
> non-free-firmware
> # deb-src https://deb.debian.org/debian bookworm-proposed-updates main 
> contrib non-free-firmware

I suspect this is a “just” a side-effect of having no network in the
installer (lack of WPA3 and no alternative connectivity); the problem I
was alluding to earlier was the absence of bookworm-updates specifically
(fixed in RC 2), and that's indeed a separate topic.

> - Under Cinnamon if I deactivate the Wifi network via the taskbar, at
> the next boot it is automatically reactivated (installation on an
> external hard drive for testing). After an installation on the
> internal ssd of my laptop, the problem no longer occurs !?

I'll let others comment here, this seems weird to me.

> Install boot loader: [ X]

Dual-/multi-booting isn't my area.

> Overall install: [X ]
> 
> - After testing RC2 on my workstation, I have problems installing
> Nvidia graphics drivers for my RTX 3080. Nvidia detect does not seem
> to be present and Nvidia-drivers refuses to install, it only shows the
> available version n c isn't the right one ??
> 
> - The 'reboot' command does not work in simple user, only in root ;-(

Those are definitely not installer-related topics; the former should
probably be a bug report against one of the nvidia package; the latter
isn't a bug.


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


signature.asc
Description: PGP signature

Bug#1035306: netcfg: Investigate WPA 3 support

[Cyril Brulebois]

Package: netcfg
Severity: normal

Hi,

It appears we have users with networking set up only allowing WPA 3.
Combined with laptops that only come with a wireless interface means
no onboard connectivity.

See https://bugs.debian.org/1035305

USB-to-Ethernet adapters are (somewhat) cheap and should be easy to
find, but it'd be better to have WPA 3 support from the get-go…


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

Bug#1035305: Bugs on Debian 12 RC2 - Configure network: [ X] - Install boot loader: [ X] - Overall install: [X ]

[Cyril Brulebois]

Package: debian-installer
X-Debbugs-Cc: pham...@bluewin.ch

[Retrying submit@ with a Package pseudo-header…]

pham...@bluewin.ch  (2023-04-29):
> I speak French so it's more complicated for me to communicate in
> English...
> 
> Configure network: [ X]
> 
> - WAP3 support from the installer is required. My Laptop (Dell XPS
> 9520) does not have an RJ-45 connection, it only has Wifi available
> like many machines today. My router is configured in WAP3 only... This
> complicates things a lot during installation.
> 
> - The problem to solve which is present in all intermediate versions
> of Debian is related to sources.list. It lacks the following
> information :
> 
> # Bookworm base repository
> deb https://deb.debian.org/debian bookworm main non-free-firmware
> deb-src https://deb.debian.org/debian bookworm main non-free-firmware
> #
> # Bookworm-updates
> deb https://deb.debian.org/debian bookworm-updates main non-free-firmware
> deb-src https://deb.debian.org/debian bookworm-updates main non-free-firmware
> # 
> # Security updates
> deb https://deb.debian.org/debian-security/ bookworm-security main 
> non-free-firmware
> deb-src https://deb.debian.org/debian-security/ bookworm-security main 
> non-free-firmware
> #
> # Proposed-updates (versions intermédiaires)
> # deb https://deb.debian.org/debian bookworm-proposed-updates main contrib 
> non-free-firmware
> # deb-src https://deb.debian.org/debian bookworm-proposed-updates main 
> contrib non-free-firmware
> 
> Lack of this configuration prevents updates from working as well as
> installing additional software except from the installation media ;-(
> 
> It is likely that some users will drop Debian directly for this sad
> reason, without trying to solve it by hand...
> 
> - Under Cinnamon if I deactivate the Wifi network via the taskbar, at
> the next boot it is automatically reactivated (installation on an
> external hard drive for testing). After an installation on the
> internal ssd of my laptop, the problem no longer occurs !?
> 
> 
> Install boot loader: [ X]
> 
> - In case of dual installation Debian 12 / Windows 11, the Debian
> bootloader does not install on its own hard disk but it squats the
> Windows /boot/efi partition. This does not allow the Debian system to
> boot if a Windows disk crashes or is deleted. Moreover, by default the
> partition /boot/efi of Windows is very small (100 Mo) this poses
> problems of remaining available space... In my case the Windows
> /boot/efi partition was almost full, I had another version of Linux
> installed (Ubuntu 22.10), plus Windows 11, my Laptop's bios update
> system and now Debian 12. As a result, it is no longer possible to
> install another OS without making room and the TRIM function of my SSD
> on this almost full partition is struggling to work...
> 
> Overall install: [X ]
> 
> - After testing RC2 on my workstation, I have problems installing
> Nvidia graphics drivers for my RTX 3080. Nvidia detect does not seem
> to be present and Nvidia-drivers refuses to install, it only shows the
> available version n c isn't the right one ??
> 
> - The 'reboot' command does not work in simple user, only in root ;-(


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


signature.asc
Description: PGP signature

Bug#1034814: debian-installer: bootable flag not toggling

[Cyril Brulebois]

Pascal Hambourg  (2023-04-30):
> On 30/04/2023 at 10:16, Matt Taggart wrote:
> > IMO "hide the bootable option if GPT" (but maybe that is non-trivial).
> 
> It should not be too hard. I can work on a patch against
> partman-partitioning if the d-i developers agree with this solution.

I'm happy to defer to Steve's expertise and yours on those topics.


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


signature.asc
Description: PGP signature

Bug#1035304: bullseye-pu: package systemd/247.3-7+deb11u3

[Luca Boccassi]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org

Dear release team,

I have uploaded two new bugfixes for systemd in bullseye. One fixes a
regression introduced by a security fix in udev rules, that has been
reported by a bullseye user. The other fixes an old memory leak.

The source debdiff is attached.

Kind regards,
Luca Boccassi


debdiff
Description: Binary data

Bug#1026635: [Pkg-rust-maintainers] Bug#1026635: rust-packed-simd: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

[Alexander Kjäll]

Hi

I noticed that the upstream project seem to have regained access and
started to publish new versions of packed_simd again:
https://crates.io/crates/packed_simd

I don't have a strong opinion regarding deleting this or not, but I
checked and it wasn't hard to get it building, so I pushed a commit
with the new version:

https://salsa.debian.org/rust-team/debcargo-conf/-/commit/f7a718c857cb5d62053b90e0ad6c88d70aba0ab7

//Alex

Bug#697821: ppsspp dependencies

[matthias . geiger1024]

Hi all,

upon doing some quick packaging for cityhash and udis86 I discovered there is 
*a lot* more missing.

1) gason: just 2 cpp headers, did some quick packaging 
https://github.com/vivkin/gason

2) SFMT: https://github.com/MersenneTwister-Lab/SFMT
3) two headers taken from 
https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator
4) xxHash: https://github.com/Cyan4973/xxHash looks doable

5) xBRZ: https://github.com/janisozaur/xbrz looks doable

6) https://github.com/richgel999/jpeg-compressor  looks doable

7) https://github.com/MersenneTwister-Lab/SFMT looks doable

8) kirk-engine/libkirk: I think this is 
https://github.com/ProximaV/kirk-engine-full but it mentions it's also an 
update, not sure where the original source comes from

https://github.com/hrydgard/ppsspp/blob/master/ext/disarm.cpp is apparently 
also needed, but the website mentioned is a dead link and I couldn't find a 
source for it.

4-7 look doable, the rest looks like it will be more work imho. Maybe I can 
make some time at mini debconf hamburg for 4- 7 , but I won't promise anything. 
Feel free to reply here if you find something I missed/have any clues where the 
missing sources are. I also don't know if ppssspp will compile if all libraries 
are provided as debian packages instead of embedded copies. While I strongly 
tend to the former as packaging practice, it might not be possible to fully 
devendor ppsspp. As of now I already had to extensively patch cmakelists to 
force it to look for the debian libraries. 

regards,
 

---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1033538: chkrootkit: Chkrootkit reports a false positive?

[Richard Lewis]

control: clone -1 -2
control: retitle -2 spurious warnings if no sniffers (ifpromisc needs a
proper exit status to fix this)
thanks

On Sun, 30 Apr 2023, 11:33 Red Omen,  wrote:

> Package: chkrootkit
> Version: 0.57-2+b1
> Followup-For: Bug #1033538
>

Thanks - this should be in a separate bug report though!

Checking `sniffer'...   WARNING
>
> WARNING: Output from ifpromisc:
> lo: not promisc and no packet sniffer sockets
> eth0: not promisc and no packet sniffer sockets
>
>
> If this is working correctly and there is no issue should it still be
> sending an alert mail?
>

Technically it should, because you are not using diff more (and are not
asking for 'quiet' output): ifpromisc then reports on every interface. The
test (even before debians many patches) just gives the output if ifpromisc.

It is very unusual these days not to have any dhcp or some network manager
running anywhere!

There are several ways you can work round this:
1. I would recommend you edit /etc/chkrootkit/chkrootkit.conf and set
DIFF_MODE to true - then  you will get one email with instructions on how
to suppress repeat mails.

2. Alternatively, in the same file is RUN_DAILY_OPTS -- and in that you can
set chkrootkit options including
a)  -q (affects all tests, including this one) - it is passed through to
ifpromisc which will then give you no output.
b)   -s to filter the output of ifpromisc (doesnt affect any other tests)
eg RUN_DAILY_OPTS="-s 'no packet sniffer'" should work (the arg for -s is
passed to 'grep -Ev')

both 2a and 2b can be used with or without diff_mode of course.



Having said all that there is a minor bug here:
It is a minor inaccuracy to have a  'warning' in the output when the only
output is no promisc interfaces at all - the best way to fix this would be
if ifpromisc set an exit status of 1 if anything was found - patches for
that welcome!

(ckrootkit could then use that status to suppress the 'WARNING' bit )

Bug#947388: anki: Bug seems to be resolved in Debian Bullseye

[Julian Gilbey]

Thanks Rahul, that's great to hear!

Best wishes,

   Julian

On Sat, Apr 29, 2023 at 03:12:53PM +0100, Rahul Amaram wrote:
> Package: anki
> Followup-For: Bug #947388
> 
> Dear Maintainer,
> 
> This bug seems to be resolved in Debian Bullseye.
> 
> Thanks,
> Rahul.

Bug#1035059: dpdk 20.11.8-1~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1035059 = 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: dpdk
Version: 20.11.8-1~deb11u1

Explanation: new upstream stable release

Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[Andreas Metzler]

On 2023-04-27 Simon Josefsson  wrote:
> > I have spent a little bit of effort on packaging 2.4.0. I have pushed
> > this to salsa (sans tags) into 3 temporary branches that could be
[...]
> Hi,

> What do you think about uploading these to experimental, to allow
> testing?

> I have built your branch and there appears to be community interest in
> having binary packages hosted somewhere, and I'm exploring options.  My
> fairly limited testing suggests they work, and resolve many fixed issues
> that I've had with the 2.2.x series so I will use these myself going
> forward.

> https://lists.gnupg.org/pipermail/gnupg-users/2023-April/066490.html
> https://lists.gnupg.org/pipermail/gnupg-users/2023-April/066500.html

Hello Simon,

I do not indend to hijack/adopt gnupg2, so I am very reluctant to upload
without some kind of go from Daniel or Eric. (Even to experimental.)

However I have updated the GIT branches to 2.4.1 today.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1035301: gdm3/bullseye: logging in to Plasma and then Xfce fails

[Simon McVittie]

Package: gdm3,plasma-desktop,xfce4-session
Tags: bullseye
Control: found -1 gdm3/3.38.2.1-1
Control: fixed -1 gdm3/43.0-3
Control: found -1 plasma-desktop/4:5.20.5-4
Control: fixed -1 plasma-desktop/4:5.27.2-1
Control: found -1 xfce4-session/4.16.0-1
Control: fixed -1 xfce4-session/4.18.1-1
Severity: normal

While we were testing install media for the Debian 11.7 point release,
Emyr Williams found an issue with installing multiple desktop environments.
This appears to have been fixed, worked around or otherwise avoided in
bookworm, but still affects bullseye. It's not yet clear whether this is a
result of a bug in gdm3, Plasma or Xfce.

Original steps to reproduce:

* Install Debian 11.7 on real or virtual hardware
* At the tasksel stage, choose to install every desktop environment
* If you are asked to choose a display manager, choose GNOME's gdm3
  (this was the default when I tried it)
* Finish the installation and boot the installed system
* At the gdm3 login prompt, choose the (single) user account
* Do not enter the password yet
* In the cog wheel menu in the bottom right corner, choose Plasma
* Enter the password and log in
* Log out from Plasma but do not reboot or shut down
* Back at the gdm3 login prompt, choose the user account again
* In the cog wheel menu in the bottom right corner, choose Xfce
* Enter the password and log in

Slightly simpler steps to reproduce:

* Install Debian 11 in a VM (I used autopkgtest-build-qemu)
* Log in as root
* Create a user account with a non-empty password, or set a non-empty
  password on an existing user account
* apt install gdm3 plasma-desktop xfce4-session
* Reboot
* At the gdm3 login prompt, choose the user account
* Continue as above

Parts of this that work as expected:

* gdm3's greeter runs on tty1. It's a Wayland compositor (gnome-shell in
  a special mode), with Xwayland on a high-numbered display, normally :1024.
* When you log in to Plasma (in X11 mode), gdm starts a new Xorg server
  on the next available virtual console, normally tty2, normally with
  X11 display :0. It works as you'd hope.
* When you log out from Plasma, you're taken back to tty1 as before,
  again with a Wayland compositor and a high-numbered Xwayland display.

Expected result:

* When you log in to Xfce, gdm starts a new Xorg server on tty2 or maybe
  tty3, with X11 display :0 or maybe :1. Xfce works correctly.

Actual result:

* Xfce doesn't start, and after a brief flash of black screen and/or old
  framebuffer contents from Plasma, you're sent back to the gdm greeter.

Workarounds:

* After leaving Plasma, reboot the system. Xfce will work correctly in a
  clean boot.
* Or, use a different pair of desktop environments (all others seemed OK,
  it seemed to be specifically Plasma -> Xfce that is the problem case).

Possible workarounds (not yet tested, these are the next things to try):

* Choosing a different display manager like lightdm
* KillUserProcesses=yes in /etc/systemd/logind.conf

Journal log attached from following the simpler steps, from reboot onwards,
with annotations added via `logger -t NOTE "about to log in to Plasma"` and
similar commands from a root ssh session.


journal.log.gz
Description: application/gzip

Bug#969203: Merging *-avr with existing binutils & gcc packages

[Gregor Riepl]

Is there any reason why https://tracker.debian.org/pkg/gcc-12-cross-ports
and https://tracker.debian.org/pkg/binutils can't be used to
produce gcc-avr avr-libc & binutils-avr packages?
Of course we still need to add a few dependencies (e.g. core-avr).


See the discussion in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989 - a switch from 
the Atmel/Microchip toolchain to mainstream gcc was already up for 
discussion, but Ardö has mentioned that he lacks the time to do it.


There is no mention of AVR on the GCC 11 and 12 changelog:

https://gcc.gnu.org/gcc-11/changes.html
https://gcc.gnu.org/gcc-12/changes.html

So, I'm not sure if the announced deprecation of the AVR target has 
actually happened. As I understand, there's at least the Arduino 
community who has an active interest in keeping AVR support alive.


If you're up for it, please take a shot at upgrading the packages to the 
mainstream versions. I can't contribute a lot of time either, but I'd be 
happy to support you with bug fixing and testing.

Bug#1034713: php-guzzlehttp-psr7 1.7.0-1+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1034713 = 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: php-guzzlehttp-psr7
Version: 1.7.0-1+deb11u2

Explanation: fix improper input validation [CVE-2023-29197]

Bug#1035105: distro-info-data 0.51+deb11u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1035105 = 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: distro-info-data
Version: 0.51+deb11u4

Explanation: add Debian 14 "forky"; correct Ubuntu 23.04 release date; add 
Ubuntu 23.10 Mantic Minotaur; add the planned release date for Debian bookworm

Bug#1034736: pev 0.81-3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1034736 = 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: pev
Version: 0.81-3+deb11u1

Explanation: fix buffer overflow issue [CVE-2021-45423]

Bug#1034714: php-nyholm-psr7 1.3.2-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1034714 = 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: php-nyholm-psr7
Version: 1.3.2-2+deb11u1

Explanation: fix improper input validation issue [CVE-2023-29197]

Bug#1035300: unblock: manpages/6.03-2

[Dr. Tobias Quathamer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: manpa...@packages.debian.org
Control: affects -1 + src:manpages

Please unblock package manpages

[ Reason ]
The upgrade of manpages-dev from bullseye fails due to missing 
Break/Replaces. See RC bug #1034958.


[ Impact ]
Failing upgrade of manpages-dev from bullseye to bookworm.

[ Tests ]
No automated tests.

[ Risks ]
The only (trivial) change is the addition of Breaks/Replaces for 
inn2-dev. This has been coordinated with the maintainer of inn2, see bug 
#1034958.


As this is a trivial fix for an RC bug, I've already uploaded the 
package to unstable.


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


unblock manpages/6.03-2


Regards,
Tobias
diff -Nru manpages-6.03/debian/changelog manpages-6.03/debian/changelog
--- manpages-6.03/debian/changelog	2023-02-15 17:45:03.0 +0100
+++ manpages-6.03/debian/changelog	2023-04-30 12:42:06.0 +0200
@@ -1,3 +1,10 @@
+manpages (6.03-2) unstable; urgency=medium
+
+  * Add Breaks/Replaces for inn2-dev (<< 2.7.0-1).
+Thanks to Helge Kreutzmann  (Closes: #1034958)
+
+ -- Dr. Tobias Quathamer   Sun, 30 Apr 2023 12:42:06 +0200
+
 manpages (6.03-1) unstable; urgency=medium
 
   * New upstream version 6.03
diff -Nru manpages-6.03/debian/control manpages-6.03/debian/control
--- manpages-6.03/debian/control	2023-02-15 17:45:03.0 +0100
+++ manpages-6.03/debian/control	2023-04-30 12:40:09.0 +0200
@@ -35,7 +35,8 @@
 Multi-Arch: foreign
 Depends: manpages, ${misc:Depends}
 Suggests: man-browser
-Breaks: manpages (<< 6.01-1)
+Replaces: inn2-dev (<< 2.7.0-1)
+Breaks: manpages (<< 6.01-1), inn2-dev (<< 2.7.0-1)
 Priority: optional
 Description: Manual pages about using GNU/Linux for development
  These man pages describe the Linux programming interface, including


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035298: pre-approval: unblock: Lazarus/2.2.6+dfsg1-2

[Graham Inggs]

Control: tags -1 + confirmed moreinfo

Hi Abou

Please go ahead and upload to unstable, and remove the moreinfo tag
once the package is built.

Regards
Graham

Bug#1033538: chkrootkit: Chkrootkit reports a false positive?

[Red Omen]

Package: chkrootkit
Version: 0.57-2+b1
Followup-For: Bug #1033538

Hi, I also seem to be getting a false positive but without any process details:

Checking `sniffer'...   WARNING

WARNING: Output from ifpromisc:
lo: not promisc and no packet sniffer sockets
eth0: not promisc and no packet sniffer sockets


If this is working correctly and there is no issue should it still be sending 
an alert mail?

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

Kernel: Linux 6.1.12a (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chkrootkit depends on:
ii  libc6  2.36-9

Versions of packages chkrootkit recommends:
ii  binutils   2.40-2
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
ii  cron [cron-daemon] 3.0pl1-162
ii  exim4-daemon-light [mail-transport-agent]  4.96-14
ii  iproute2   6.1.0-2
ii  net-tools  2.10-0.1
ii  procps 2:4.0.2-3
ii  systemd-sysv   252.6-1

chkrootkit suggests no packages.

-- no debconf information

Bug#1032857: please consider adding the jgrpp patches

[Matthijs Kooijman]

Hey Toni,

> please consider packaging the jgrpp patches, too.

Thanks for your suggestion. What did you have in mind exactly?

I won't include third-party patches in the main build, since that
affects multiplayer compatibility (i.e. a patched build will be
incompatible with other people playing unpatched builds).

I could consider including a non-patched and a patched build
side-to-side (i.e.  in two different binary packages), but I'm not sure
I want to go down this path either (this is just one set of patches, but
I'm pretty sure there's others and before we know it we'll be packaging
a dozen of different patch sets...).

IMHO the right path to making these patches more accessible, is to
submit them for inclusion upstream (possibly after improving the patch
quality).

So I'm inclined to close this as wontfix.

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#1035299: O: rbdoom3bfg -- Doom3 BFG edition game engine

[Tobias Frost]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rbdoom3...@packages.debian.org
Control: affects -1 + src:rbdoom3bfg

I intend to orphan the rbdoom3bfg package.

The package description is:
 RBDoom3BFG 3 is a Doom 3 BFG GPL source modification. The goal of RBDoom3BFG 3
 is to bring Doom 3 BFG with the help of SDL to all suitable platforms. Bugs
 present in the original DOOM 3 will be fixed (when identified) without altering
 the original game-play.
 .
 Note, to play the original game, you'll need a copy of the game data.
 .
 The package can also be used with free map data, like the demomap from
 OpenTechBFG.

Upstream is unfortunatly not very supportive in terms of the needs of an 
distribution
like Debian and openly said that their Linux port this is not their priority, 
so the
effort required to keep this package in Debian will be beyond what I'm willing
to provide.

For documentation, the major reason where upstream is disagreeing with e.g
Debian policies embedding 3rd party libraries. While they accepted in the past
at least changes to the build system to be able to build against system 
libraries,
their take on distributions policy about embedded libraries is that that will
"hold back (their) development" and it is not their priority to design changes
e.g to those embedded libraries in a way that are distribution friendly.

The upstream position on 3rd party libraries is problematic for Debian long
term, for example they still ship very ancient libpng and libjpeg versions with
many known security vulnerabilities; Despite wanting to enable the engine to be
used more easily by modders, they disagree this is a security issue.
(There were pull requests upstream to update the versions, however, never 
merged.)

The new upstream version 1.5 will increase the problem space significantly,
as there are several new embedded code libraries, some with modifications, like
Nvidia's NVRHI.

The new upstream version will also require additional software packaged for 
Debian,
like Microsoft's DXC (DirectXShaderCompiler), which also has several
not packaged dependencies (pulled in via git submodules in DXC's repo)


(Note: I'll request removal of the package, if it has not been adopted by that 
time,
before the release of Trixie. rbdoom3bfg 1.4.0 is usable, and should be part of 
bookworm.)

--
tobi

Bug#1035076: plymouth: Plymouth package has defective hard-dependency on systemd

[Laurent Bigonville]

Le 29/04/23 à 15:37, Faulk Johnny a écrit :
I am not saying to remove the systemd dependency. I am saying that 
changing "systemd," to "systemd | elogind" under the control section 
for the plymouth package in particular, NOT the build dependencies, 
thus allowing installation on (and forcing a dependency on) either one 
of them. Those who use a no-systemd system know full well there is a 
risk, seeing as it's a pretty deliberate act to begin with in Debian. 
Changing it as described above would have no affect at all on systemd 
systems, as it would still pull in systemd and enforce that need. 
Please reconsider this course of action.


The fact that plymouth package is depending on systemd has nothing to do 
with the fact that it requires (e)logind (it actually doesn't, plymouth 
runs at early boot and has nothing to do with a user session).


As said the dependency is needed because plymouth requires some udev 
rules (namely /usr/lib/udev/rules.d/71-seat.rules) and tags to properly 
detect the framebuffer/drm devices.


So as long at the rules file is shipped, in systemd package, plymouth 
will have that dependency.




On Sat, Apr 29, 2023 at 6:25 AM, Laurent Bigonville

Like explained in bug #1035076, the fact that systemd is pulled by
the
plymouth package doesn't mean you cannot use it with an other
initsystem
on debian, the package that actually changes the default
initsystem is
"systemd-sysv", not "systemd"

Removing the dependency might break plymouth at it requires some udev
rules files that are shipped by the systemd package (the rules are
used
to tag the framebuffer devices/heads installed on the machines).

So removing that could break some setup

Kind regards,

Laurent Bigonville

Bug#1034814: debian-installer: bootable flag not toggling

[Pascal Hambourg]

On 30/04/2023 at 10:16, Matt Taggart wrote:

On 4/25/23 01:59, Pascal Hambourg wrote:


If this should be fixed, not sure how.
- Set/unset the "esp" flag at the same time as the "boot" flag if GPT ?
- Hide the "bootable" option if GPT
- Map the "bootable" option to the "legacy_boot" parted flag instead of
"boot" if GPT ? (AFAIK only syslinux/extlinux uses this flag)


IMO "hide the bootable option if GPT" (but maybe that is non-trivial).


It should not be too hard. I can work on a patch against 
partman-partitioning if the d-i developers agree with this solution.

Bug#1035297: unblock: qemu/1:7.2+dfsg-6

[Michael Tokarev]

30.04.2023 11:07, Michael Tokarev пишет:
...

branch, and also includes the forgotten .desktop file which
results in a missing icon file for qemu-system processes.


And as I found out later, I should not ship debian-specific qemu.desktop
file, since upstream provides its own, I just forgot to include it into
the binary package. In the next qemu release I removed d/qemu.desktop
amd added a line to d/qemu-system-common.install instead, but forgot
to do the same for bookworm.

/mjt

Bug#1034825: translation updated

[Luca Monducci]

Hello,

please find attached the translation after review.

Thanks,

Luca
# Italian (it) translation of debconf templates for grub2
# This file is distributed under the same license as the grub2 package.
# Luca Monducci , 2007-2023.
#
msgid ""
msgstr ""
"Project-Id-Version: grub2 2.02~beta3-4 italian debconf templates\n"
"Report-Msgid-Bugs-To: gr...@packages.debian.org\n"
"POT-Creation-Date: 2023-04-23 20:27+\n"
"PO-Revision-Date: 2023-04-29 21:20+0200\n"
"Last-Translator: Luca Monducci \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "Chainload from menu.lst?"
msgstr "Effettuare il caricamento in cascata da menu.lst?"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub."
msgstr ""
"Gli script di aggiornamento hanno rilevato una installazione di GRUB Legacy "
"in /boot/grub."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"In order to replace the Legacy version of GRUB in your system, it is "
"recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image "
"from your existing GRUB Legacy setup. This step can be automatically "
"performed now."
msgstr ""
"Per sostituire la versione Legacy di GRUB sul proprio sistema si raccomanda "
"di modificare il file /boot/grub/menu.lst in modo da caricare l'immagine di "
"avvio di GRUB 2 dall'attuale installazione di GRUB Legacy. Questa modifica "
"può essere effettuata automaticamente adesso."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"It's recommended that you accept chainloading GRUB 2 from menu.lst, and "
"verify that the new GRUB 2 setup works before it is written to the MBR "
"(Master Boot Record)."
msgstr ""
"Si raccomanda di accettare il caricamento in cascata di GRUB 2 da menu.lst e "
"di verificare che la nuova installazione di GRUB 2 funzioni prima di "
"procedere con l'installazione diretta sul MBR (Master Boot Record)."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"Whatever your decision, you can replace the old MBR image with GRUB 2 later "
"by issuing the following command as root:"
msgstr ""
"Qualsiasi sia la decisione, in seguito sarà possibile sostituire la vecchia "
"immagine sul MBR con GRUB 2 eseguendo da root il seguente comando:"

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid "GRUB install devices:"
msgstr "Installare GRUB sui device:"

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"The grub-pc package is being upgraded. This menu allows you to select which "
"devices you'd like grub-install to be automatically run for, if any."
msgstr ""
"È in corso l'aggiornamento del pacchetto grub-pc. Questo menu permette di "
"scegliere su quali device, se specificati, si vuole eseguire automaticamente "
"grub-install."

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"Running grub-install automatically is recommended in most situations, to "
"prevent the installed GRUB core image from getting out of sync with GRUB "
"modules or grub.cfg."
msgstr ""
"Nella maggioranza dei casi si raccomanda l'esecuzione automatica di grub-"
"install in modo da prevenire la perdita di sincronia dell'immagine "
"principale di GRUB con i moduli di GRUB o con grub.cfg."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"If you're unsure which drive is designated as boot drive by your BIOS, it is "
"often a good idea to install GRUB to all of them."
msgstr ""
"Se non si è sicuri di quale sia il disco impostato come disco di avvio nel "
"BIOS, è consigliabile installare GRUB su tutti i device."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"Note: it is possible to install GRUB to partition boot records as well, and "
"some appropriate partitions are offered here. However, this forces GRUB to "
"use the blocklist mechanism, which makes it less reliable, and therefore is "
"not recommended."
msgstr ""
"Nota: è possibile installare GRUB anche nei boot record delle partizioni e "
"qui sono elencate alcune partizioni  appropriate. Però questo obbliga GRUB a "
"usare il meccanismo del \"blocklist\", che lo rende meno affidabile e di "
"conseguenza non è raccomandato."

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:4001
msgid ""
"The GRUB boot loader was previously installed to a disk that is no longer "
"present, or whose unique identifier has changed for some reason. It is "
"important to make sure that the installed GRUB core image stays in sync with "
"GRUB modules 

Bug#1034814: debian-installer: bootable flag not toggling

[Matt Taggart]

On 4/25/23 01:59, Pascal Hambourg wrote:

On 25/04/2023 at 03:24, Matt Taggart wrote:


When in the partitioning and editing a partition, if I am on the 
"bootable" option and select, it does not toggle but remains "no". The 
screen flashes, bot no change. I have not yet checked what ends up in 
the partition table after the install.


Is it a GPT partition table ?


Yes, GPT and EFI, 512gb nvme drive.

GPT is the default partition table type with EFI boot or disk size above 
2 TiB. In GPT, "boot" and "esp" parted flags are equivalent and both 
represent the "EFI system partition" type (IMO this is a big mess).


Being used to doing non-GPT/EFI installs for so long, I did what I have 
always done and toggled the bootable flag on the /boot partition. When 
it didn't change, I tried again and it still didn't change. So it was 
less a bug of it not functioning that it was confusing for the user.



If this should be fixed, not sure how.
- Set/unset the "esp" flag at the same time as the "boot" flag if GPT ?
- Hide the "bootable" option if GPT > - Map the "bootable" option to the 
"legacy_boot" parted flag instead of
"boot" if GPT ? (AFAIK only syslinux/extlinux uses this flag)


IMO "hide the bootable option if GPT" (but maybe that is non-trivial).
Alternatively the value could be displayed as "GPT" and not change when 
toggled.


Thanks,

--
Matt Taggart
m...@lackof.org

Bug#1035096: installation-report Bookworm RC2 GRUB not installed

[Pascal Hambourg]

On 30/04/2023 at 01:47, Peter Ehlert wrote:


On 4/29/23 15:41, Pascal Hambourg wrote:

On 29/04/2023 at 16:02, Peter Ehlert wrote:


reboot gave me the Old GRUB menu, not including my new system.


What do you mean by "old GRUB menu" ? The GRUB which was previously 
installed on /dev/sdb ? 


the GRUB that was on the only disk with a bios_grub flagged partition.


Thank you for the clarification. If I understand correctly,
- the machine usually boots with some GRUB on disk X,
- you installed a new Debian system with GRUB on disk Y,
- then the machine rebooted on disk X as usual.

The Debian installer will not add the newly installed system to another 
existing OS GRUB menu; it will only add other existing OS's to the new 
installed system GRUB menu, which will be displayed only if the machine 
boots from the disk containing the new GRUB. So what you describe is 
normal behaviour.


If you want to add the newly installed system to another OS GRUB menu, 
you need to run update-grub from that other OS. If you want to boot with 
the new installed GRUB, you need to set up the BIOS to boot from the 
disk which contains it.

Bug#1035297: unblock: qemu/1:7.2+dfsg-6

[Michael Tokarev]

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

Please unblock package qemu

This debian release has the following:

1. sync with upstream qemu stable/bugfix 7.2.1 release, by removing
   all patches in debian/patches/master/ and replacing them all with
   single debian/patches/v7.2.1.diff which is a diff between upstream
   qemu 7.2.0 and 7.2.1 releases.  This is a bulk of the changes in there.
   See "Other info" section below for more information.

2. Includes upstream qemu stable/bugfix 7.2.2 release.
   Upstream 7.2.2 needs its own comment.  Historically, qemu stable
   were managed up until next major release is out.  Here, 7.2.2
   was planned to be tagged the next day after 8.0.0 has been
   released (8.0 release didn't follow its schedule because of the
   amount of bugfixes needed there).  So by the historical practice
   7.2.2 should not be released. But I plan to change this practice,
   by providing a bit more support for previous major release of
   qemu, past the next major release date, and also plan to perform
   at least one more 7.2 upstream stable/bugfix release. We're
   discussing this on the qemu side.  Either way, 7.2.2 is officially
   tagged in the upstream qemu git tree:
  https://gitlab.com/qemu-project/qemu/-/tags/v7.2.2
   so it's only matter of making a tarball out of it and making
   an official announcement.

3. Includes a few more fixes which are taken from the upstream
   development mailing list, targetting next upstream releases
   (including stable), which fixes known issues.

4. Includes minor changes in the debian packaging, like fixing
   FTBFS due to unportable usage of \n escapes with echo and
   switching gbp.conf from master branch to debian-bookworm
   branch, and also includes the forgotten .desktop file which
   results in a missing icon file for qemu-system processes.

The whole thing seems quite large, and when you look at the diffstat
it is large: >3k LOC changed. But this is mostly due to the conversion
from debian/patches/master/* to debian/patches/v7.2.1.diff.

[ Reason ]

This debian release has numerous bug fixes which affects many aspects
of qemu functionality within debian.  I will be targetting bookworm
proposed updates with the same functionality if it misses initial
bookworm release.  This also includes a fix for relatively old issue
which is more specific to debian: aptitude segfaulted within qemu-user
environments, #811087.

[ Tests ]

The release is well-tested, as it is usual for all qemu stable releases,
due to qemu excellent CI/testsuite.  I verified it, together with extra
changes, wihin my set of tests too.  The extra changes (on top of 7.2.2)
has also been discussed and tested.

[ Risks ]

As usual, the risk of breaking something do exists.  Some unusual use
case or guest which we didn't cover by testing and don't yet know about.
Still, the amount of real, actual fixes included is much more than possible
breakage.

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

[ Other info ]

Since the direct diff between 1:7.2+dfsg-5 and 1:7.2+dfsg-6 is quite large,
it's difficult to review.  So I'm including 2 diffs instead.

1. 7.2+dfsg-6~no-v7.2.2.diff - I made an intermediate "syncing point"
debian "release", which is just a sync with upstream 7.2.1. This diff
is a difference in *source* (excluding debian/ but including d/patches
parts) between extracted 7.2+dfsg-5 and 7.2+dfsg-6 but without the v7.2.2.diff
and the extra 7.2+dfsg-6 patches.  This diff shows just the sync between
debian qemu and 7.2.1 upstream qemu release, plus the changes in d/patches
which made it. The change in here is just 4 commits:
  version bump to 7.2.1
  block: Handle curl 7.55.0, 7.85.0 version changes
  build-sys: fix crlf-ending C code (only affects win32 builds)
  tests/tcg: fix unused variable in linux-test (fix test failure)
all can be found here: https://gitlab.com/qemu-project/qemu/-/commits/v7.2.1

2. From 7.2+dfsg~6-no-v7.2.2, there's another diff to the final 7.2+dfsg-6
release, now comparing debian/ parts only.  This includes addition of
v7.2.2.diff (and removal of CVE-2022-1050.patch), addition of 3 other
patches to the source fixing more bugs, and other changes to debian/.
All individual changes in v7.2.2.diff are available at
https://gitlab.com/qemu-project/qemu/-/commits/v7.2.2 - it contains
a bunch of various bugfixes in individual commits with descriptions.


If this is too difficult for the release team to handle, I'm open to
changing it somehow. All changes, in my opinion, are worth to have in
bookworm, each and all were thought about with care.

unblock qemu/1:7.2+dfsg-6

=== begin changelog
qemu (1:7.2+dfsg-6) unstable; urgency=medium

  [ Michael Tokarev ]
  * sync with upstream v7.2.1 stable release, into 

Bug#1035296: kicad: Program crashes

[Carsten Schoenert]

Hello Serkan,

Am 30.04.23 um 08:32 schrieb Serkan:

Dear Maintainer,

The program crashes when clicking the "Select item(s)" button with the
simulation probe selected. When I run the program from the terminal, the phrase
"Sharding failure" appears.

Short summary:
After completing the simulation calculations, selecting the wire in the
"Schematic Editor" and clicking the "Select item(s)" (arrow) button at the top
right to see the waveform in a node crashes the program.


this sounds like some issue related to libngspice.

You might try to install the libngspice0 package from experimental 
release and retry your steps.



https://packages.debian.org/experimental/libngspice0
If this does not help at least some down striped KiCad project files 
would be needed so we can try to re-adjust your setup. Without any data 
it's impossible to see the issue on my side.


Please provide some more information (data, logs, steps etc.) what you 
are doing.


Extra note:
Debian is now quite short before the full freeze of the bookworm 
release, unfortunately the KiCad 7 release did happen to late by 
upstream to make it available in bookworm. Even if your issue is a 
upstream issue no fixup for the old 6.x release will happen. It's also 
possible that your issue isn't happen within KiCad 7. KiCad 7 is in 
Debian available also in the experimental release. It's build on top of 
unstable so you should be able to simply install the packages on the CLI 
after a potential modification of your sources.list data.


--
Regards
Carsten

Bug#1035296: kicad: Program crashes

[Serkan]

Package: kicad
Version: 6.0.11+dfsg-1
Severity: normal
X-Debbugs-Cc: ssser...@yahoo.com

Dear Maintainer,

The program crashes when clicking the "Select item(s)" button with the
simulation probe selected. When I run the program from the terminal, the phrase
"Sharding failure" appears.

Short summary:
After completing the simulation calculations, selecting the wire in the
"Schematic Editor" and clicking the "Select item(s)" (arrow) button at the top
right to see the waveform in a node crashes the program.

Debian 12
Gnome Desktop


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=tr_TR.UTF-8, LC_CTYPE=tr_TR.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 kicad depends on:
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libcurl4 7.88.1-9
ii  libgcc-s112.2.0-14
ii  libgl1   1.6.0-1
ii  libglew2.2   2.2.0-4+b1
ii  libglib2.0-0 2.74.6-2
ii  libglu1-mesa [libglu1]   9.0.2-1.1
ii  libgtk-3-0   3.24.37-2
ii  libngspice0  39.3+ds-1
ii  libocct-data-exchange-7.67.6.3+dfsg1-5
ii  libocct-foundation-7.6   7.6.3+dfsg1-5
ii  libocct-modeling-algorithms-7.6  7.6.3+dfsg1-5
ii  libocct-modeling-data-7.67.6.3+dfsg1-5
ii  libocct-ocaf-7.6 7.6.3+dfsg1-5
ii  libpixman-1-00.42.2-1
ii  libpython3.113.11.2-6
ii  libstdc++6   12.2.0-14
ii  libwxbase3.2-1   3.2.2+dfsg-2
ii  libwxgtk-gl3.2-1 3.2.2+dfsg-2
ii  libwxgtk3.2-13.2.2+dfsg-2
ii  python3  3.11.2-1+b1
ii  python3-wxgtk4.0 4.2.0+dfsg-3
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages kicad recommends:
ii  kicad-demos  6.0.11+dfsg-1
ii  kicad-libraries  6.0.11+dfsg-1
ii  xsltproc 1.1.35-1

Versions of packages kicad suggests:
pn  extra-xdg-menus   
ii  kicad-doc-en  6.0.11+dfsg-1
ii  kicad-packages3d  6.0.10-1

-- no debconf information

Bug#1035295: RFS: gl4es/1.1.4-1 -- GL4ES - OpenGL 2.1/1.5 to GLES 2.0/1.1 translation library

[Cheng Li]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : gl4es
Version : 1.1.4-1
Upstream contact : https://github.com/ptitSeb/gl4es/issues
* URL : https://github.com/ptitSeb/gl4es
* License : MIT
* Vcs : pending
Section : libs

The source builds the following binary packages:

libgl4es - GL4ES - OpenGL 2.1/1.5 to GLES 2.0/1.1 translation library
libgl4es-dev - GL4ES - OpenGL 2.1/1.5 to GLES 2.0/1.1 translation library

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/gl4es/gl4es_1.1.4-1.dsc


Changes for the initial release:

gl4es (1.1.4-1) unstable; urgency=medium
.
* Initial release

Regards,

Bug#1034639: unblock: spamassassin/4.0.0-5

[Paul Gevers]

Control: tags -1 moreinfo

Hi Noah

On 27-04-2023 07:41, Paul Gevers wrote:

On 20-04-2023 18:22, Noah Meyerhans wrote:

This is a targeted change that addresses #1034347,


Please go ahead and remove the moreinfo tag once the upload happened.


Already several years we don't accept uploader built binaries in 
testing. Unfortunately, we can't binNMU arch:all binaries, so please 
upload a no-change *source only* version 4.0.0-6.


Paul

Migration status for spamassassin (4.0.0-4 to 4.0.0-5): BLOCKED: 
Rejected/violates migration policy/introduces a regression

Issues preventing migration:
∙ ∙ Not built on buildd: arch all binaries uploaded by noahm, a new 
source-only upload is needed to allow migration

∙ ∙ Not built on buildd: arch amd64 binaries uploaded by noahm


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032899: unblock: rocm-hipamd/5.2.3-6

[Paul Gevers]

Control: tags -1 confirmed moreinfo

Hi Christian,

On 29-04-2023 00:17, Christian Kastner wrote:

I asked you to *also* provide the diff between *current* unstable and
your proposal (via unstable), because "I was about to propose to upload
it to tpu" (2023-04-20).


Sure, the 04_ attachment is the debdiff between unstable -6 and the
proposed update -7, which removes all of the less important changes that
I marked with (+) in my previous log.

I may be misunderstanding something here. I interpreted your t-p-u hint
for the case where a fix via unstable wouldn't be possible because of
the dependency issue. The proposal, however would work via unstable.


It was for *me*. I reviewed the version in unstable and had some 
concerns. Due to the size of the debdiff, it's easier to look at the 
proposed delta to unstable (that I reviewed), than to review from scratch.


Please go ahead with your 04_ proposal and please remove the moreinfo 
tag once the upload happened.


Paul


OpenPGP_signature
Description: OpenPGP digital signature