Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Ansgar]

On Wed, 2023-05-10 at 19:01 -0700, Sean Whitton wrote:
> On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote:
> > Cool, then let's ask tech-ctte.
> > 
> > Dear ctte, please consider overruling the dpkg maintainer to
> > include
> > the patch from #994388[1].
> > 
> > Thanks,
> > Ansgar
> > 
> >   [1]: https://bugs.debian.org/994388#397
> 
> This would require a new, maintainer-overruling vote.
> Our existing decisions do not apply, so far as I can tell.

Yes, I agree.

> I have written a separate message to the bug and to debian-dpkg with
> a proposal to avoid having to have such a vote.

That seems to be about an implementation detail on how to apply the
patch. I don't think that is the core of the issue?

The core issue as I see it is as follows:

- Debian has decided to support only merged-/usr, including possibly
  moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
  as the interpreter in binaries.

- This change breaks on non-merged-/usr systems, including derivatives
  that do not revert *all* relevant changes. (Do you know one that
  does this or plans to do so?)

- dpkg recommends derivative users to move to non-merged-/usr.

I think this contradiction is not good and the core conflict. For me a
distribution should have some coherence. It is not just a distribution
of unrelated parts (like linux, libc, dpkg, dash, ...), but also
integrates them to work together.

And this also means not one package telling users to do X which breaks
other packages. Or (if other packages would do similar things as dpkg)
one package asking users to do X and the other asking users to do the
opposite of X. Just imagine dpkg asking users to move to split-/usr and
then another package starting to warn users to move back to merged-
/usr. Would that be a good state? I think not which is why this bug
exists.

Do you think this summary of the issue is right?

Is there some consensus about how this issue should be solved or do we
need a longer discussion to explore the solution space?

Ansgar

Bug#1035974: unblock: dkimpy/1.1.3-1

[Scott Kitterman]

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

Please age days package dkimpy

[ Reason ]
Upstream (me) just released a new bugfix update that fixes a regression
from bullseye, so I would like to get that update in before release.  At
the same time, the currently pending upload has a bunch of fixes that I
don't want to reset the clock on.

If you adjust the days required, so 1.1.3-1 migrates, I think I just
have time to get the other fixes in.

[ Impact ]
Ultimately, if I can't get 1.1.4 in, users will get tracebacks if there
is a DNS timeout, which can cause things to crash.

[Tests ]
The package has an extensive test suite which is run during autopkgtest.
Specific bug fixes were tested by me.

[ Risks ]
Adjusting the age days for 1.1.3-1 should be negligible risk.  There are
no regressions reported either upstream or in Debian.  It's all pretty
straightforward fixes.

[ 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 ]
Ultimately I plan to get the fixes from 1.1.4 into Bookworm.  I think
it's better to do it now than wait for a stable update and this will
help.

unblock dkimpy/1.1.3-1 (actually adjust the days needed).

Scott K

Bug#1035841: fixed in amavisd-new 1:2.13.0-3

[Johannes Schauer Marin Rodrigues]

Hi,

On Thu, 11 May 2023 23:52:00 + Debian FTP Masters 
 wrote:
> Changes:
>  amavisd-new (1:2.13.0-3) unstable; urgency=medium
>  .
>* Fix failure to purge without adduser. Closes: #1035841.

thank you! Would you like me to take care of filing the unblock request with
release.debian.org or would you like to take care of that yourself?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1035913: fixed in doc-debian 11.2

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Joost van Baal-Ilić (2023-05-12 07:01:45)
> A!  That explains!  Thanks a lot.  I now have a plan again; will get to it
> within a week.

can we finish this a bit quicker than that? The full freeze is at 2023-05-24
and my package is also broken by dash in experimental, so the upload of my
package has to be coordinated with dash and doc-debian. The earlier you are
ready, the earlier not only my package but also dash can be unblocked.

Sorry, this would've been much more relaxed if the doc-debian upload did not
happen during hard freeze...

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1029962: check-missing-firmware fails to find firmware file or package on partitioned removable media

[Cyril Brulebois]

And before I forget…

Pascal Hambourg  (2023-04-01):
> The current algorithm mounts only the first "suitable" disk or partition
> when searching for loose firmware files or packages.
> If it mounts the wrong devices, firmware files are not found.
> 
> This patch adds the following subcommands to mountmedia:
> mountmedia list [floppy]: list devices
> mountmedia mounted: test if /media is mounted
> mountmedia mount : mount device (ro) or directory on /media
> 
> The behaviour when no subcommand is passed is unchanged.
> 
> The "mount" subcommand loads the ext4 module to be able to mount media
> with ext* filesystems in addition to vfat. It may be useful in cases
> such as bug#1033498 when some loose firmware files are symlinks, which
> are not supported by vfat. However it may increase the search time if
> there are many ext* partitions.
> 
> Additionally, the "list" subcommand adds /hd-media to the device list
> if it exists for compatibility with the current behaviour.
> 
> These subcommands are intended to be used by check-missing-firmware
> from package hw-media in order to search firmware files or packages
> on all available media.

This should be hw-detect, rather than hw-media. :)

> ---
>  mountmedia | 55 --
>  1 file changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/mountmedia b/mountmedia
> index 6013579..7181ac5 100755
> --- a/mountmedia
> +++ b/mountmedia
> @@ -1,6 +1,18 @@
>  #!/bin/sh
>  set -e
>  
> +# parse sub-commands
> +if [ "$1" = list ]; then
> + CMD_LIST=1
> + # shift to parse optional parameter "floppy"
> + shift
> +elif [ "$1" = mounted ]; then
> + CMD_MOUNTED=1
> +elif [ "$1" = mount ]; then
> + CMD_MOUNT=1
> + dev="$2"
> +fi
> +
>  if [ "$1" = driver ]; then
>   WANTDRIVER=1
>  elif [ "$1" = floppy ]; then
> @@ -59,10 +71,49 @@ checkcontents() {
>   fi
>  }
>  
> +# execute sub-commands
> +
> +if [ "$CMD_LIST" ]; then
> + if [ -d /hd-media ]; then
> + # for compatibility with default behaviour
> + echo /hd-media
> + fi
> + devlist
> + exit 0
> +fi
> +
> +if [ "$CMD_MOUNTED" ]; then
> + media_mounted
> + exit
> +fi
> +
> +if [ "$CMD_MOUNT" ]; then
> + if [ -d "$dev" ]; then # directory -> bind mount
> + mount --bind $dev $MNT
> + exit
> + elif [ -b "$dev" ]; then # block device -> normal mount
> + modprobe -q vfat || true
> + # allow to mount ext2/3/4 too, may be useful in some cases (see 
> #1033498)
> + modprobe -q ext4 || true
> + if [ $dev = /dev/fd0 ]; then
> + # for compatibility with default behaviour
> + # useless if floppy support is dropped
> + log-output -t mountmedia modprobe -q floppy || true
> + log-output -t mountmedia modprobe -q ide-floppy || true
> + update-dev --settle
> + fi
> + mount -r -t auto $dev $MNT
> + exit
> + fi
> + exit 1
> +fi
> +
> +# default operation when no subcommand is passed
> +
>  if ! ( media_mounted && checkcontents $MNT ); then
>   # Special case for an already mounted /hd-media.
>   if [ -d /hd-media ] && checkcontents /hd-media; then
> - mount --bind /hd-media /media
> + mount --bind /hd-media $MNT

Since new subcommands are supposed to have run and exited before, I
would expect the default operation to require no changes at all, so the
/media → $MNT update seems weird.

>   exit 0
>   fi
>  
> @@ -79,7 +130,7 @@ if ! ( media_mounted && checkcontents $MNT ); then
>   fi
>   done
>   
> - if [ "$i" = 1 ]; then   
> + if [ "$i" = 1 ]; then
>   # Give USB time to settle, make sure all devices are
>   # seen next time though.
>   sleep 5

This part could have been dropped too, even if it's very minor compared
to the question above.


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


signature.asc
Description: PGP signature

Bug#1035913: fixed in doc-debian 11.2

[Joost van Baal-Ilić]

Hi,

On Fri, May 12, 2023 at 06:50:55AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Joost van Baal-Ilić (2023-05-11 15:35:24)
> > On Thu, May 11, 2023 at 01:55:48PM +0200, Joost van Baal-Ilić wrote:
> > > On Thu, May 11, 2023 at 12:38:17PM +0200, Johannes Schauer Marin 
> > > Rodrigues wrote:
> > > > On Thu, 11 May 2023 09:49:47 + Debian FTP Masters 
> > > >  wrote:
> > > > > Changes:
> > > > >  doc-debian (11.2) experimental; urgency=high
> > > > >  .
> > > > >* This release is targeted for Debian 12 bookworm: changes with 
> > > > > what is
> > > > >  in testing now are minimal and suitable for an upload late in the
> > > > >  release cycle.
> > > > >* debian/TODO: added
> > > > >* Revert changes which are too intrusive for an upload during 
> > > > > freeze.
> > > > >  (Closes: #1035913) Thanks Johannes Schauer Marin Rodrigues: 
> > > > > "changed
> > > > >  /usr/share/doc-base/ paths".
> > > > 
> > > > I do not understand that last changelog entry. Reverting "changes which 
> > > > are too
> > > > intrusive for an upload during freeze" sounds like you are going back 
> > > > to this:
> > > > 
> > > > /usr/share/doc-base/debian-constitution-text
> > > > /usr/share/doc-base/debian-mailing-lists
> > > > /usr/share/doc-base/debian-manifesto
> > > > /usr/share/doc-base/debian-reporting-bugs
> > > > /usr/share/doc-base/debian-social-contract
> > > > 
> > > > But the package in experimental is shipping this:
> > > > 
> > > > $ curl --silent 
> > > > https://incoming.debian.org/debian-buildd/pool/main/d/doc-debian/doc-debian_11.2_all.deb
> > > >  | dpkg-deb -c - | grep doc-base
> > > > drwxr-xr-x root/root 0 2023-05-11 09:08 ./usr/share/doc-base/
> > > > -rw-r--r-- root/root   578 2020-12-31 08:50 
> > > > ./usr/share/doc-base/doc-debian.debian-constitution-text
> > > > -rw-r--r-- root/root   238 2020-12-31 08:50 
> > > > ./usr/share/doc-base/doc-debian.debian-mailing-lists
> > > > -rw-r--r-- root/root   502 2020-12-31 08:50 
> > > > ./usr/share/doc-base/doc-debian.debian-manifesto
> > > > -rw-r--r-- root/root   278 2020-12-31 08:50 
> > > > ./usr/share/doc-base/doc-debian.debian-reporting-bugs
> > > > -rw-r--r-- root/root   550 2020-12-31 08:50 
> > > > ./usr/share/doc-base/doc-debian.debian-social-contract
> > > > 
> > > > So the paths actually did *not* get reverted to how they were before 
> > > > 11.0?
> > > 
> > > Thanks for this.  Apparently the buildengine used gives different results 
> > > than
> > > the one I used locally to check before uploading.  This bug should get
> > > reopened.  I'll investigate.
> > 
> > ok this is not trivial.  even in a sid chroot it installs
> > usr/share/doc-base/doc-debian.debian-constitution-text , and does not 
> > install
> > usr/share/doc-base/debian-constitution-text .  changing dh compat level to 
> > the
> > current one does not fix it.  dh_installdocs(1) does not help me.  i'll
> > investigate more...
> 
> you cannot go back to the old doc-base paths. The package name is part of the
> path since this debhelper commit from 2021:
> 
> https://salsa.debian.org/debian/debhelper/-/commit/8eac421c260e62bcecd571af225438e107b33157

( fixing bug https://bugs.debian.org/980903 . )

A!  That explains!  Thanks a lot.  I now have a plan again; will get to it
within a week.

Bye,

Joost

Bug#1035745: unblock: dash/0.5.12-4 (preapproval)

[Johannes Schauer Marin Rodrigues]

Hi,

On Mon, 08 May 2023 16:54:32 +0100 Luca Boccassi  wrote:
> This cleanup has been uploaded last week to experimental with dash/0.5.12-3.
> We have tested it and cannot see any issues with it.

dash in experimental breaks the autopkgtest of mmdebstrap. I've fixed these
problems already and uploaded the fixed version of mmdebstrap to unstable.

I can also confirm that dash in experimental does not break my work on
chrootless bootstrap.

I will file the unblock request for mmdebstrap as soon as the breakages with
the recent doc-debian upload are resolved.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1035913: fixed in doc-debian 11.2

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Joost van Baal-Ilić (2023-05-11 15:35:24)
> On Thu, May 11, 2023 at 01:55:48PM +0200, Joost van Baal-Ilić wrote:
> > On Thu, May 11, 2023 at 12:38:17PM +0200, Johannes Schauer Marin Rodrigues 
> > wrote:
> > > On Thu, 11 May 2023 09:49:47 + Debian FTP Masters 
> > >  wrote:
> > > > Changes:
> > > >  doc-debian (11.2) experimental; urgency=high
> > > >  .
> > > >* This release is targeted for Debian 12 bookworm: changes with what 
> > > > is
> > > >  in testing now are minimal and suitable for an upload late in the
> > > >  release cycle.
> > > >* debian/TODO: added
> > > >* Revert changes which are too intrusive for an upload during freeze.
> > > >  (Closes: #1035913) Thanks Johannes Schauer Marin Rodrigues: 
> > > > "changed
> > > >  /usr/share/doc-base/ paths".
> > > 
> > > I do not understand that last changelog entry. Reverting "changes which 
> > > are too
> > > intrusive for an upload during freeze" sounds like you are going back to 
> > > this:
> > > 
> > > /usr/share/doc-base/debian-constitution-text
> > > /usr/share/doc-base/debian-mailing-lists
> > > /usr/share/doc-base/debian-manifesto
> > > /usr/share/doc-base/debian-reporting-bugs
> > > /usr/share/doc-base/debian-social-contract
> > > 
> > > But the package in experimental is shipping this:
> > > 
> > > $ curl --silent 
> > > https://incoming.debian.org/debian-buildd/pool/main/d/doc-debian/doc-debian_11.2_all.deb
> > >  | dpkg-deb -c - | grep doc-base
> > > drwxr-xr-x root/root 0 2023-05-11 09:08 ./usr/share/doc-base/
> > > -rw-r--r-- root/root   578 2020-12-31 08:50 
> > > ./usr/share/doc-base/doc-debian.debian-constitution-text
> > > -rw-r--r-- root/root   238 2020-12-31 08:50 
> > > ./usr/share/doc-base/doc-debian.debian-mailing-lists
> > > -rw-r--r-- root/root   502 2020-12-31 08:50 
> > > ./usr/share/doc-base/doc-debian.debian-manifesto
> > > -rw-r--r-- root/root   278 2020-12-31 08:50 
> > > ./usr/share/doc-base/doc-debian.debian-reporting-bugs
> > > -rw-r--r-- root/root   550 2020-12-31 08:50 
> > > ./usr/share/doc-base/doc-debian.debian-social-contract
> > > 
> > > So the paths actually did *not* get reverted to how they were before 11.0?
> > 
> > Thanks for this.  Apparently the buildengine used gives different results 
> > than
> > the one I used locally to check before uploading.  This bug should get
> > reopened.  I'll investigate.
> 
> ok this is not trivial.  even in a sid chroot it installs
> usr/share/doc-base/doc-debian.debian-constitution-text , and does not install
> usr/share/doc-base/debian-constitution-text .  changing dh compat level to the
> current one does not fix it.  dh_installdocs(1) does not help me.  i'll
> investigate more...

you cannot go back to the old doc-base paths. The package name is part of the
path since this debhelper commit from 2021:

https://salsa.debian.org/debian/debhelper/-/commit/8eac421c260e62bcecd571af225438e107b33157

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1035973: unblock: linux/6.1.27-1

[Cyril Brulebois]

Hi everyone,

Salvatore Bonaccorso  (2023-05-12):
> The upload was announced in
> https://lists.debian.org/debian-release/2023/05/msg00287.html and
> summarizing consists of importing new stable series. But in particular
> addressing recent CVEs, covering CVE-2023-31436 and CVE-2023-2002.
> Additionally the fix for CVE-2023-32233 is cherry-picked.
> 
> The package has been only 3 days, but I'm asking for an unblock and
> aging due to CVE-2023-32233 in particular.
> 
> *Unless* it is going to block d-i RC3 release, then let's wait after
> that.

I'm happy with an unblock from a d-i perspective.

> Not attaching the debdiff.

:D


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


signature.asc
Description: PGP signature

Bug#1034586: always reports inactive/expired certificate on armhf

[gs-bugs . debian . org]

Macro, please review my previous messages and try to help provide
additional information.

Thank you.  Glenn

Bug#1035926: lighttpd conf-enabled files cannot override IPV6 port number

[gs-bugs . debian . org]

On Thu, May 11, 2023 at 11:49:21AM +0200, Michael Moore wrote:
...
> Issue and suggested fix:
> ===
> In lighttpd.conf the includes for conf-enabled/*.conf happens after passing
> server.port to the use-ipv6.pl script. Re-ordering these lines so that the
> conf files are included first allows the server.port value to be
> overridden.
> 
> include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
> include_shell "/usr/share/lighttpd/create-mime.conf.pl"
> include "/etc/lighttpd/conf-enabled/*.conf"

Thank you for the thorough description.
Yes, I agree with your suggestion.

use-ipv6.pl is simple and its output can be placed anywhere in
lighttpd.conf.  Therefore, it should be safe to move to follow
conf-enabled/*.conf

I'll mark this fixed once the change is included in a release.

Cheers, Glenn

Bug#1035973: unblock: linux/6.1.27-1

[Salvatore Bonaccorso]

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

Hi Release team, hi Cyril for debian-boot/d-i,

Please unblock package linux

The upload was announced in
https://lists.debian.org/debian-release/2023/05/msg00287.html and
summarizing consists of importing new stable series. But in particular
addressing recent CVEs, covering CVE-2023-31436 and CVE-2023-2002.
Additionally the fix for CVE-2023-32233 is cherry-picked.

The package has been only 3 days, but I'm asking for an unblock and
aging due to CVE-2023-32233 in particular.

*Unless* it is going to block d-i RC3 release, then let's wait after
that.

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

Not attaching the debdiff.

Regards,
Salvatore

Bug#1029962: check-missing-firmware fails to find firmware file or package on partitioned removable media

[Cyril Brulebois]

Hi Pascal,

Pascal Hambourg  (2023-04-01):
> Please find attached a patch for mountmedia 0.27 and two patches for
> hw-detect 1.155 implementing a possible solution.

Thanks for your work on this. As for the other bug report, that's been on
my todo list since you submitted those patches, but time is running out
and I'm very much not thrilled with risking anything on the firmware
front, even if the existing situation regarding “loose material” isn't
ideal. I really looked at those patches, but I'm feeling much too nervous
about them, and that's definitely not a feeling I'm going to ignore.

At this stage, I'll err on the side of caution, and keep the “suboptimal”
support for loose firmware files/packages as it is. Some patches touch the
“main code” and that's definitely a red flag, days away from the upcoming
releases (RC 3, RC 4, and 12.0).


As you noted a while back, the search has been problematic for a very long
while, so Bookworm isn't regressing from Bullseye as far as I understand
(even if it did at some point, when I fumbled the condition guarding the
mountmedia calls…). If anything, Bookworm is expected to be *far better*
at firmware support, thanks to official non-free-firmware support, and
thanks to improvements like the “address resolution” for USB/MHI.

I'm open to the following compromise: look into those patches once the
next development cycle opens, test them, get them into some Alpha release,
run as many tests as we like given we'll have plenty of time… And once
we're absolutely convinced they're helping, and not triggering some nasty
regression (breaking support for “official” firmware packages, slowing
down the installation because of inefficient searches, or infinite loops,
or whatever), then only consider backporting them to stable via a point
release.

For the time being, I'm adding a reference to this topic to my list of
things for 12.1 (even if it's likely to be shifted to some later 12.x
point release, since 12.1 is very likely to happen before the D-I Trixie
Alpha 1 release).

  https://salsa.debian.org/installer-team/debian-installer/-/issues/3


I hope this all makes sense and isn't too much of a disappointment.


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


signature.asc
Description: PGP signature

Bug#1033679: hw-detect/check-missing-firmware: add fallback module lookup by modalias and firmware

[Cyril Brulebois]

Hi Pascal,

Pascal Hambourg  (2023-03-30):
> Please find attached 3 patches adding fallback module detection when
> dmesg does not provide the actual module name and device driver
> symlink is missing. I tried to keep them as clear, short and little
> invasive as possible in order to ease review and avoid regressions.

Thanks for doing so. It's been on my todo list for a while but I'm
little concerned about the risk/benefit ratio at this stage; we can
consider those for inclusion at the beginning of the next development
cycle.


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


signature.asc
Description: PGP signature

Bug#1035972: isc-dhcp EOL'ed

[Santiago Ruano Rincón]

Source: debian-security-support
Version: 1:12+2023.05.04
Severity: normal
X-Debbugs-Cc: secur...@debian.org, debian-...@lists.debian.org

Dear security and LTS teams,

ISC is not longer maintaing any of the components of isc-dhcp (client,
relay or server):
https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html
https://www.isc.org/blogs/isc-dhcp-eol/

I propose to mark it as unsupported. Or at least, limited, if we still
have hope in those security update exceptions they claim they could do.

Cheers,

 -- Santiago

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 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

-- debconf information excluded


signature.asc
Description: PGP signature

Bug#1001440: /usr/bin/foo2zjs: fails to load firmware into printer

[Kevin Goodsell]

I'm not sure if it's the same issue, but I'm also seeing firmware failing
to load on my LaserJet 1020 using foo2zjs. My guess is that there's a
conflict between the firmware loading script and udev-configure-printer
trying to access the printer at the same time.

Here is a snippet from journalctl when the printer was turned on:

  May 11 18:02:34 cyclops kernel: usb 2-14: new high-speed USB device
number 14 using xhci_hcd
  May 11 18:02:34 cyclops kernel: usb 2-14: New USB device found,
idVendor=03f0, idProduct=2b17, bcdDevice= 1.00
  May 11 18:02:34 cyclops kernel: usb 2-14: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
  May 11 18:02:34 cyclops kernel: usb 2-14: Product: HP LaserJet 1020
  May 11 18:02:34 cyclops kernel: usb 2-14: Manufacturer: Hewlett-Packard
  May 11 18:02:34 cyclops kernel: usb 2-14: SerialNumber: JL1K941
  May 11 18:02:34 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 14 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 18:02:40 cyclops kernel: usblp1: removed
  May 11 18:02:40 cyclops /lib/udev/hplj1020[162068]: foo2zjs: loading HP
LaserJet 1020 firmware /lib/firmware/hp/sihp1020.dl to CUPS USB device ...
  May 11 18:02:40 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 14 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 18:02:40 cyclops kernel: usblp1: removed
  May 11 18:02:40 cyclops systemd[1]: Started Configure Plugged-In Printer.
  May 11 18:02:40 cyclops udev-configure-printer[162071]: add usb-002-014
  May 11 18:02:40 cyclops udev-configure-printer[162071]: device devpath is
/devices/pci:00/:00:14.0/usb2/2-14
  May 11 18:02:40 cyclops udev-configure-printer[162071]: Device
vendor/product is 03F0:2B17
  May 11 18:02:41 cyclops udev-configure-printer[162071]: failed to claim
interface
  May 11 18:02:41 cyclops systemd[1]: configure-printer@usb-002-014.service:
Main process exited, code=exited, status=1/FAILURE
  May 11 18:02:41 cyclops systemd[1]: configure-printer@usb-002-014.service:
Failed with result 'exit-code'.

And here's a snippet of the same scenario with a work-around in place:

  May 11 17:58:15 cyclops kernel: usb 2-14: new high-speed USB device
number 13 using xhci_hcd
  May 11 17:58:15 cyclops kernel: usb 2-14: New USB device found,
idVendor=03f0, idProduct=2b17, bcdDevice= 1.00
  May 11 17:58:15 cyclops kernel: usb 2-14: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
  May 11 17:58:15 cyclops kernel: usb 2-14: Product: HP LaserJet 1020
  May 11 17:58:15 cyclops kernel: usb 2-14: Manufacturer: Hewlett-Packard
  May 11 17:58:15 cyclops kernel: usb 2-14: SerialNumber: JL1K941
  May 11 17:58:15 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 17:58:21 cyclops kernel: usblp1: removed
  May 11 17:58:21 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 17:58:21 cyclops /lib/udev/hplj1020[161939]: foo2zjs: loading HP
LaserJet 1020 firmware /lib/firmware/hp/sihp1020.dl to CUPS USB device ...
  May 11 17:58:21 cyclops kernel: usblp1: removed
  May 11 17:58:31 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 17:58:31 cyclops /lib/udev/hplj1020[161944]: foo2zjs:
usb://HP/LaserJet%201020?serial=JL1K941... download successful.
  May 11 17:58:31 cyclops systemd[1]: Started Configure Plugged-In Printer.
  May 11 17:58:31 cyclops udev-configure-printer[161953]: add usb-002-013
  May 11 17:58:31 cyclops udev-configure-printer[161953]: device devpath is
/devices/pci:00/:00:14.0/usb2/2-14
  May 11 17:58:31 cyclops udev-configure-printer[161953]:
MFG:Hewlett-Packard MDL:HP LaserJet 1020 SERN:- serial:JL1K941
  May 11 17:58:36 cyclops kernel: usblp1: removed
  May 11 17:58:36 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 17:58:37 cyclops kernel: usblp1: removed
  May 11 17:58:37 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 17:58:38 cyclops udev-configure-printer[161953]: URI contains USB
serial number
  May 11 17:58:38 cyclops udev-configure-printer[161953]: URI match:
usb://HP/LaserJet%201020?serial=JL1K941
  May 11 17:58:38 cyclops udev-configure-printer[161953]: URI of detected
printer: usb://HP/LaserJet%201020?serial=JL1K941, normalized: laserjet 1020
serial jl1k941
  May 11 17:58:38 cyclops udev-configure-printer[161953]: URI of print
queue: usb://HP/LaserJet%201020?serial=JL1K941, normalized: laserjet 1020
serial jl1k941
  May 11 17:58:38 cyclops udev-configure-printer[161953]: Queue
ipp://localhost/printers/HP_LaserJet_1020 has matching device URI
  May 11 17:58:38 cyclops udev-configure-printer[161953]: Re-enabled
printer ipp://localhost/printers/HP_LaserJet_1020
  May 11 17:58:38 cyclops systemd[1]: 

Bug#1035056: (no subject)

[Patrick Franz]

Hi,

we've uploaded Plasma 5.27.5 to experimental and this is the version 
that we would prefer to have in bookworm instead of 5.27.2.

I can only iterate what hefee said before: This is merely a bugfix 
release and does not add new (build) dependencies or functionality.
Plasma 5.27.5 fixes over 100 (!!) bugs that currently exist in bookworm.
Backporting bugfixes one by one is not really an option as this would put 
too much work on both the Qt/KDE and the release team.

I hereby ask kindly for approval to upload Plasma 5.27.5 to unstable 
such that it can and will migrate to bookworm.

Plasma 5.27.5 is a suite of 56 source packages in total and we would 
like to avoid sending 56 unblock/approval requests. The affected 
packages are:

bluedevil
breeze
breeze-grub
breeze-gtk
breeze-plymouth
drkonqi
flatpak-kcm
kactivitymanagerd
kde-cli-tools
kdecoration
kde-gtk-config
kdeplasma-addons
kgamma5
khotkeys
kinfocenter
kmenuedit
kpipewire
kscreen
kscreenlocker
ksshaskpass
ksystemstats
kwallet-pam
kwayland-integration
kwin
kwrited
layer-shell-qt
libkscreen
libksysguard
milou
oxygen
oxygen-sounds
plasma-bigscreen
plasma-browser-integration
plasma-desktop
plasma-discover
plasma-disks
plasma-firewall
plasma-integration
plasma-nano
plasma-nm
plasma-pa
plasma-remotecontrollers
plasma-sdk
plasma-systemmonitor
plasma-thunderbolt
plasma-vault
plasma-welcome
plasma-workspace
plasma-workspace-wallpapers
plymouth-kcm
polkit-kde-agent-1
powerdevil
qqc2-breeze-style
sddm-kcm
systemsettings
xdg-desktop-portal-kde


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1018730: More info

[Melvin Vermeeren]

To add to the previous briefly, as I didn't explicitly mention this.

Early initramfs should:

* Activate the resume device (one of the swap) for resume handling.
* Activate the rootfs.

Once rootfs is there, remaining PVs etc will cascade activate through the 
setup from late-stage boot process onwards.

Early initramfs should NOT call vgchange and activate things it doesn't need 
to activate, specific lvchange is better in my opinion.

Thanks,

-- 
Melvin Vermeeren
Systems engineer

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

Bug#1035810: closed by Sebastian Ramacher (unblock btrfsmaintenance)

[Nicholas D Steeves]

"Debian Bug Tracking System"  writes:

> 1035810: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035810
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> From: Sebastian Ramacher 
> Subject: unblock btrfsmaintenance
> To: 1035810-d...@bugs.debian.org
> Date: Thu, 11 May 2023 17:59:58 +
>
> Unblocked.

Thank you Sebastian!


signature.asc
Description: PGP signature

Bug#1034824: tomcat9 should not be released with Bookworm

[Emmanuel Bourg]

Hi Paul,

Le 2023-05-11 21:44, Paul Gevers a écrit :


From a quick look at the key packages:

It seems you didn't follow up (86 days) on libcommons-dbcp-java which
can't migrate to bookworm because it would make libbiojava-java-doc
uninstallable (no fix there, no bug report filed).


I have to apology for this one, I forgot to check the transition of
libcommons-dbcp-java. Is it still possible to remove libbiojava-java-doc
to fix this (very low popcon and unused like the other -java-doc 
package)?




src:tiles also build-depends on libtomcat9-java, with no bug filed for
the migration to tomcat10 *and* it having it's own FTBFS bug. (It's
key because of src:libspring-java)


I remember pulling my hair on src:tiles to make it build with OpenJDK 
17,

without success unfortunately (#1011597). The project is dead upstream,
that doesn't help. Patching src:libspring-java and removing src:tiles
is likely the next step.



On IRC carnil and jmm_ suggested that src:tomcat9 could be left in
bookworm but have it's server component stripped. Would that help the
situation?


I agree, this is a good compromise.


Emmanuel Bourg

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Thorsten Glaser]

James Addison dixit:

>On Thu, 11 May 2023 at 02:43, Andres Salomon  wrote:

>> For ARM64, he says that raising the stack limit is not safe for v8
>> *embedded inside WebView*, and therefore not appropriate for upstream
>> v8. But then he says it could/should be safe for v8 *embedded inside
>> NodeJS*.
>>
>> Based on that, I suggest patching Debian's NodeJS with the patch to
>> adjust armhf/arm64 stack limit size

That would be a good thing (huh, wasn’t armhf good?), but…

>I have a question: if we apply the patch and begin using the same
>constant stack size of 984kb on 32-bit ARM and 64-bit ARM as is
>defined for other architectures, then does NodeJS on those platforms
>begin supporting exactly the same stack frame capacity (maximum call
>depth for any given recursive function, for example) as a build of the
>same NodeJS source on x86 and amd64 respectively?

… no, because both stack usage and other stuff on stack differ.

Which is why I’d rather have the getrlimit-based one for nodejs.
That would give us twice to four times the limit.

>> (As chromium maintainer, which also embeds v8, I haven't heard of any
>> issues and hadn't planned on touching stacks limits. It sure would be

Yes, yes, definitely don’t change it outside of nodejs.

>> javascript code that is triggering this bug should really be fixed to
>> not be so stack-intensive, of course. Perhaps this bug cloned at a
>> lower severity, filed against those packages that this bug is affecting?

That’s got a dependency chain so long that don’t hold your breath
for ALL those to be changed is true. Besides, how would the
respective maintainers be aware of this in the first place?

Short of failing with an arbitrary nesting limit on all arches,
in upstream nodejs, I doubt you’d get half of the upstream code
maintainers to care… if they even care about their code any more
at all. I am not a friend of such limits either, in addition.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#1018730: closed by Bastian Blank (Re: Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure)

[Melvin Vermeeren]

Hi,

My wording might be a bit over the top, apologies in advance. I do really mean 
the best, just a bit baffled at the wontfix reply and lack of acknowledgement 
of the problem.

I'm not really understanding the "Half VG was never a real thing" approach and 
general dismissal of this bug, I think it should be reopened still and this 
use case handled properly or at least further discussion. I consider it to be 
a regression and quite a nasty one at that especially for servers without BMC.



LVM officially support activation of any LV in a VG as long as specific PVs 
needed for this LV are present. Specifying --activationmode is something else 
entirely and should never be done (unless disaster recovery).

>From lvchange(8) man page about this option:

> Determines if LV activation is allowed when PVs are missing, e.g. because of
> a device failure. ...

Meaning that --activationmode decides whether LV with missing PVs may be 
activated or not. This is not the case in my setup and in many other server 
setups. To make sure: *only* the PVs for the *exact* LV in question need to be 
present, PVs for *other* LVs in the same VG may be missing.

What LVM does not support, unless you force it, is actually changing a VG when 
PVs of this VG are missing, as to my knowledge VG metadata is stored on each 
and every PV independently. LV activation does not count as VG modification.



The entire reason to have a single VG for many things is because of 
flexibility LVM provides within a VG. Almost all of the features *require* PVs 
within the same VG. Snapshots, thin LVM, cache, etc. Even basic feature like 
resizing require a nice PV - VG - LV structure.

As a PV can only be in one VG, what refusal of this bug is suggesting is that 
one has to manually partition (GPT) drives for root-related stuff, with their 
own PVs and VGs and LVs, so it can boot. And then create other partitions with 
PVs on the same disk for the additional stuff. This literally defeats the 
entire purpose of LVM, easy volume management, and means you have to resize 
the physical disk partitions to extend things. Good luck with that!

A few examples: root filesystem on some NVMe SSD and a bunch of HDDs connected 
for persistent storage. Now let's say I want to:
* When running backups, copy-on-write snapshot on the SSD PV so the HDD array 
PVs performance remains in good condition instead of COW on the HDDs.
* Implement LVM caching for this HDD array PVs on fast SSD PV.
* Thin pool on HDDs and store the metadata on the SSD PV for performance.
* Reminder: simply having a /etc/luks.key on rootfs used to open other PVs 
(HDD array) will result in boot failure if they're in the same VG!

All totally reasonable use cases. But if you are requiring split VG for "root 
stuff needed during booting" this is all not supported, because HDDs are only 
activated later. Maybe these HDD PVs are actually on a networked file system 
(NBD, NFS) are only available later. LVM can do all of this safely no problem.
(I have used many of the above in production environments with great results.)



Anyway, the main problem is that the udev rules are currently coded to only do 
activation when LVM_VG_NAME_COMPLETE aka a VG has all the PVs used for all the 
LVs within the VG. This is not suitable for early stage boot processes and 
activation of LV for root, swap and other early required fs. It *is* suitable 
for auto-activation of LVs during late stage boot process or during runtime.

On my workstation, opening mail of this issue, a typical boot is as follows:

# The PV (SSD) containing root and swap is unlocked (LUKS, manual input pw).
# Manual initramfs hack that "lvchange -aay -y root swap".
lvm: WARNING: VG verm-r4e is missing PV HDD_ARRAY_1...
lvm: WARNING: VG verm-r4e is missing PV HDD_ARRAY_2...
# Rootfs get mounted, late-stage boot lvm cryptsetup etc run.
# It notices verm-r4e VG is incomplete.
lvm[1535]: PV /dev/dm-2 online, VG verm-r4e incomplete (need 2).
# The /etc/luks.key is used to open HDD array PVs.
lvm[2387]: PV /dev/dm-17 online, VG verm-r4e incomplete (need 1).
lvm[2534]: PV /dev/dm-19 online, VG verm-r4e is complete.
# Now the all PVs are there, the remainder LVs get auto-activated.
lvm[2540]:   9 logical volume(s) in volume group "verm-r4e" now active
# As a result, my HDD pool LV is on and gets fsck + mounted cleanly.

This is working very well and is by design and very normal way of using LVM. 
Both startup and shutdown works perfectly with clean mount/unmount etc.



Also, if system configuration somehow triggers raid rebuilds every boot then 
sysadmin will get mail from tooling (if properly configured at least). Pretty 
sure it also only syncs dirty pages in such a case anyway, which is very 
quick. In any case I'd rather have a system mail root with some issue than 
hard fail in initramfs for no good reason.

This strongly feels like removing upstream supported use cases to "protect" 
sysadmin from wrongly configuring their system, at the 

Bug#1035289: merecat: diff for NMU version 2.31+git20220513+ds-4.1

[gregor herrmann]

On Thu, 11 May 2023 21:28:17 +0200, Joost van Baal-Ilić wrote:

> Awesome, thanks a lot!  (And no need to delay longer.)

Thanks, rescheduled to 0-day.

Cheers,
gregor
 
-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1035970: unblock: qt6-datavis3d/6.4.2-3

[Patrick Franz]

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

Please unblock package qt6-datavis3d

[ Reason ]
A cmake-file in qt6-datavisualization-dev references a plugin in a package
that is not a dependency of qt6-datavisualization-dev, hence potentially 
resulting in build errors if qt6-datavisualization-dev is used a   
dependency.
The fix (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035791)
prevents installing a number of cmake-files as those are not needed
and should not have been installed in the first place.

[ Impact ]
Potential build failures if the package is used a build dependnecy.

[ Tests ]
Manual inspection of the generated deb-packages confirms the cmake-files
in question are not installed anymore.

[ Risks ]
Changes are rather trivial.

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

[ Other info ]

unblock qt6-datavis3d/6.4.2-3
diffstat for qt6-datavis3d-6.4.2 qt6-datavis3d-6.4.2

 changelog |7 +++
 not-installed |   14 ++
 qt6-datavisualization-dev.install |6 --
 3 files changed, 17 insertions(+), 10 deletions(-)

diff -Nru qt6-datavis3d-6.4.2/debian/changelog 
qt6-datavis3d-6.4.2/debian/changelog
--- qt6-datavis3d-6.4.2/debian/changelog2023-01-28 18:01:33.0 
+0100
+++ qt6-datavis3d-6.4.2/debian/changelog2023-05-11 12:34:27.0 
+0200
@@ -1,3 +1,10 @@
+qt6-datavis3d (6.4.2-3) unstable; urgency=medium
+
+  [ Patrick Franz ]
+  * Do not install cmake-files for Qml plugins (Closes: #1035791).
+
+ -- Patrick Franz   Thu, 11 May 2023 12:34:27 +0200
+
 qt6-datavis3d (6.4.2-2) unstable; urgency=medium
 
   [ Patrick Franz ]
diff -Nru qt6-datavis3d-6.4.2/debian/not-installed 
qt6-datavis3d-6.4.2/debian/not-installed
--- qt6-datavis3d-6.4.2/debian/not-installed2022-08-15 18:52:08.0 
+0200
+++ qt6-datavis3d-6.4.2/debian/not-installed2023-05-11 12:28:29.0 
+0200
@@ -1,10 +1,16 @@
-usr/include/${DEB_HOST_MULTIARCH}/qt6/QtDataVisualization/*/QtDataVisualization/private/*.h
 
usr/include/${DEB_HOST_MULTIARCH}/qt6/QtDataVisualizationQml/*/QtDataVisualizationQml/private/*.h
-usr/lib/${DEB_HOST_MULTIARCH}/qt6/mkspecs/modules/qt_lib_datavisualization_private.pri
-usr/lib/${DEB_HOST_MULTIARCH}/qt6/mkspecs/modules/qt_lib_datavisualizationqml_private.pri
+usr/include/${DEB_HOST_MULTIARCH}/qt6/QtDataVisualization/*/QtDataVisualization/private/*.h
 
usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQml2AdditionalTargetInfo.cmake
 
usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQml2Config.cmake
 
usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQml2ConfigVersion.cmake
 
usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQml2ConfigVersionImpl.cmake
-usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQml2Targets-none.cmake
 
usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQml2Targets.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQml2Targets-none.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQmlpluginAdditionalTargetInfo.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQmlpluginConfig.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQmlpluginConfigVersion.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQmlpluginConfigVersionImpl.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQmlpluginTargets.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQmlpluginTargets-none.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/qt6/mkspecs/modules/qt_lib_datavisualization_private.pri
+usr/lib/${DEB_HOST_MULTIARCH}/qt6/mkspecs/modules/qt_lib_datavisualizationqml_private.pri
diff -Nru qt6-datavis3d-6.4.2/debian/qt6-datavisualization-dev.install 
qt6-datavis3d-6.4.2/debian/qt6-datavisualization-dev.install
--- qt6-datavis3d-6.4.2/debian/qt6-datavisualization-dev.install
2022-10-05 00:00:28.0 +0200
+++ qt6-datavis3d-6.4.2/debian/qt6-datavisualization-dev.install
2023-05-11 12:28:35.0 +0200
@@ -102,12 +102,6 @@
 
usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6DataVisualizationQml/Qt6DataVisualizationQmlTargets-none.cmake
 
usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6DataVisualizationQml/Qt6DataVisualizationQmlTargets.cmake
 
usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6DataVisualizationQml/Qt6DataVisualizationQmlVersionlessTargets.cmake
-usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6DataVisualizationQmlpluginAdditionalTargetInfo.cmake

Bug#1035969: unblock: qt6-charts/6.4.2-3

[Patrick Franz]

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

Please unblock package qt6-charts

[ Reason ]
A cmake-file in qt6-charts-dev references a plugin in a package
that is not a dependency of qt6-charts-dev, hence potentially 
resulting in build errors if qt6-charts-dev is used a 
dependency.
The fix (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035792)
prevents installing a number of cmake-files as those are not needed
and should not have been installed in the first place.

[ Impact ]
Potential build failures if the package is used a build dependnecy.

[ Tests ]
Manual inspection of the generated deb-packages confirms the cmake-files
in question are not installed anymore.

[ Risks ]
Changes are rather trivial.

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

[ Other info ]

unblock qt6-charts/6.4.2-3
diffstat for qt6-charts-6.4.2 qt6-charts-6.4.2

 changelog  |7 +++
 not-installed  |6 ++
 qt6-charts-dev.install |6 --
 3 files changed, 13 insertions(+), 6 deletions(-)

diff -Nru qt6-charts-6.4.2/debian/changelog qt6-charts-6.4.2/debian/changelog
--- qt6-charts-6.4.2/debian/changelog   2023-02-01 21:43:24.0 +0100
+++ qt6-charts-6.4.2/debian/changelog   2023-05-11 12:25:19.0 +0200
@@ -1,3 +1,10 @@
+qt6-charts (6.4.2-3) unstable; urgency=medium
+
+  [ Patrick Franz ]
+  * Do not install cmake-files for Qml plugins (Closes: #1035792).
+
+ -- Patrick Franz   Thu, 11 May 2023 12:25:19 +0200
+
 qt6-charts (6.4.2-2) unstable; urgency=medium
 
   [ Patrick Franz ]
diff -Nru qt6-charts-6.4.2/debian/not-installed 
qt6-charts-6.4.2/debian/not-installed
--- qt6-charts-6.4.2/debian/not-installed   2021-11-17 06:06:49.0 
+0100
+++ qt6-charts-6.4.2/debian/not-installed   2023-05-11 12:20:36.0 
+0200
@@ -1,4 +1,10 @@
 usr/include/*/qt6/QtCharts/6.*
 usr/include/*/qt6/QtChartsQml/6.*
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2AdditionalTargetInfo.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Config.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2ConfigVersion.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2ConfigVersionImpl.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Targets.cmake
+usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Targets-none.cmake
 usr/lib/*/qt6/mkspecs/modules/qt_lib_charts_private.pri
 usr/lib/*/qt6/mkspecs/modules/qt_lib_chartsqml_private.pri
diff -Nru qt6-charts-6.4.2/debian/qt6-charts-dev.install 
qt6-charts-6.4.2/debian/qt6-charts-dev.install
--- qt6-charts-6.4.2/debian/qt6-charts-dev.install  2022-10-05 
00:08:05.0 +0200
+++ qt6-charts-6.4.2/debian/qt6-charts-dev.install  2023-05-11 
12:20:14.0 +0200
@@ -134,12 +134,6 @@
 usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6ChartsQml/Qt6ChartsQmlTargets-none.cmake
 usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6ChartsQml/Qt6ChartsQmlTargets.cmake
 
usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6ChartsQml/Qt6ChartsQmlVersionlessTargets.cmake
-usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2AdditionalTargetInfo.cmake
-usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Config.cmake
-usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2ConfigVersion.cmake
-usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2ConfigVersionImpl.cmake
-usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Targets-none.cmake
-usr/lib/${DEB_HOST_MULTIARCH}/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Targets.cmake
 usr/lib/${DEB_HOST_MULTIARCH}/libQt6Charts.prl
 usr/lib/${DEB_HOST_MULTIARCH}/libQt6Charts.so
 usr/lib/${DEB_HOST_MULTIARCH}/libQt6ChartsQml.prl

Bug#1010469: [pkg-lxc-devel] Bug#1010469: Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Pierre-Elliott Bécue]

Julian Gilbey  wrote on 11/05/2023 at 16:41:46+0200:

> On Mon, Feb 06, 2023 at 11:56:51PM +0100, Pierre-Elliott Bécue wrote:
>> 
>> Julian Gilbey  wrote on 08/08/2022 at 15:47:08+0100:
>> 
>> > On Mon, Aug 01, 2022 at 10:44:16PM +0200, Pierre-Elliott Bécue wrote:
>> >> Julian Gilbey  wrote on 08/06/2022 at 10:50:18+0200:
>> 
>> Hrmpf, this one slipped out of my todolist, I'm sorry for this, this is
>> bad.
>> 
>> When you indeed reinstalled your system, which version of Debian did you
>> install?
>> 
>> Did you do anything specific before things turned bad again?
>
> Hi Pierre-Elliott,
>
> I was using debian testing (whatever state it was in at the time).
>
> I've just tried reinstalling lxc from scratch with the current debian
> testing.  I haven't been able to get as far as reproducing this error,
> as I've hit a different snag:
>
> # lxc-create -n debian-sid -t download -- -d debian -r sid -a amd64
> # lxc-start -n debian-sid --logfile /tmp/lxc.log --logpriority DEBUG
> lxc-start: debian-sid: ../src/lxc/lxccontainer.c: wait_on_daemonized_start: 
> 878 Received container state "ABORTING" instead of "RUNNING"
> lxc-start: debian-sid: ../src/lxc/tools/lxc_start.c: main: 306 The container 
> failed to start
> lxc-start: debian-sid: ../src/lxc/tools/lxc_start.c: main: 309 To get more 
> details, run the container in foreground mode
> lxc-start: debian-sid: ../src/lxc/tools/lxc_start.c: main: 311 Additional 
> information can be obtained by setting the --logfile and --logpriority options
>
> The resulting log file contains the cryptic error messages:
>
> lxc-start debian-sid 20230511122856.360 ERROR network -
> ../src/lxc/network.c:netdev_configure_server_veth:711 - No such file
> or directory - Failed to attach "vethQ4rt4x" to bridge "lxcbr0",
> bridge interface doesn't exist
>
> That's super-weird; I have no idea what "vethQ4rt4x" is meant to mean.

It's the name the hosts give randomly to the interface it creates for
the LXC container to get network.

Inside the container it'll be eth0, outside it's a veth intervace, named
veth$RANDOM stuff.

The issue is in the message: you configured the container to bind this
interface on a bridge named lxcbr0 that doesn't seem to exist on the
host.

> I think this should probably be a separate bug report, though.
> Despite some web searching, I have no idea how to fix this problem,
> but I now can't use lxc at all :( I think it's something about lxc-net
> not connecting the bridging device to the correct network device
> (which in my case is enp5s0).

enp5s0 is a physical interface, bridging a container directly on it
might not achieve what you expect.

The usual way is to either use the lxc-net service, or to create a
manual bridge (with network/interfaces or systemd-networkd config),
allow forwarding on it and the physical interface, and bind the
containers on it.

You will find some doc on LXC network configuration on LXC's website. :)
-- 
PEB


signature.asc
Description: PGP signature

Bug#1035857: texlive-fonts-extra: broken font symlinks for junicode

[Preuße]

On 10.05.2023 11:18, Andreas Beckmann wrote:

Hi again,


during a test with piuparts I noticed your package ships (or creates)
broken symlinks:


OK, had a closer look: the "Debian Fonts Task Force" replaced the
"Junicode 1" by "Junicode 2" although they may behave differently

"Users of the various versions of Junicode 1 need to be aware that
documents originally set in Junicode 1 may reflow when set in Junicode
2. Further, documents that use the OpenType features of Junicode 1
(aside from basics like kerning and standard ligatures) may not be
displayed properly when changed over to Junicode 2."

I guess it would have been better to create fonts-junicode2 and then
slowly phase out fonts-junicode, when v2 left beta stage.

I could simply fix the links and point them to the v2 OTF fonts. This
could be even done now. This would give Debian users the v2 fonts but I
don't know if they are compatible to the Junicode related files in
texlive-fonts-extra. Junicode v2 wasn't even uploaded to CTAN yet. I
guess it is a better idea to stay with Junicode 1 for now and
re-integrate them into tfe after bookworm..


fonts-alegreya-sans will not be in bookworm (and hasn't been in
bullseye), thus
   /usr/share/texlive/texmf-dist/fonts/opentype/huerta/alegreya
also contains broken symlinks.


Well, I tend to say "this is not my fault". I may revert my decision
after bookworm.

H.
--
sigfault

Bug#1035917: chromium: libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed

[Mathias Behrle]

* Andres Salomon: " Re: Bug#1035917: chromium: libva error:
  /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed" (Thu, 11 May 2023
  14:03:51 -0400):

> Okay, so an older CPU that the newer intel vaapi driver is broken on. 
> If you just uninstall intel-media-va-driver and 
> intel-media-va-driver-non-free, does chromium work? You'd be relying on 
> the older driver from i965-va-driver at that point.

Tried that already, didn't work either.

Bug#1034824: tomcat9 should not be released with Bookworm

[Markus Koschany]

Hello Paul,

Am Donnerstag, dem 11.05.2023 um 21:44 +0200 schrieb Paul Gevers:
> Hi Markus,
> 
> On Tue, 25 Apr 2023 16:04:09 +0200 Markus Koschany  wrote:
> > We can only support one major Tomcat version per release. Tomcat9 has
> > been part of Buster and Bullseye already and is superseded by Tomcat
> > 10 in Bookworm. I wanted to wait with the removal request until the
> > issues in [resteasy3.0] and [tomcatjss] have been resolved but to make
> > it more obvious I am filing this bug report now.
> 
> Release Team member here. I'll note that I'm not impressed by the 
> communication and timing of this bug. We're in Full Freeze for bookworm. 
> This is no time for transitions, let alone for *uncoordinated* ones.

This bug report was merely intended as a reminder. I assumed that tomcatjss
(#1031816) and resteasy3.0 were the only two issues left to resolve. I agree
that we should have filed the bug report earlier. I was under the impression
that all affected packages are maintained by the Java team. IMHO it doesn't
make much sense to maintain a Tomcat plugin outside of it, which is by
definition tightly coupled with the web server.

Still, there was plenty of time and I have pointed to several possible ways to
resolve this problem but there was no response. [1] 

> 
> You should have raised the issue earlier and brought it to the release 
> team. tomcat9 and tomcat10 are both key packages so neither can easily 
> be removed.
> 
>  From a quick look at the key packages:
> 
> It seems you didn't follow up (86 days) on libcommons-dbcp-java which 
> can't migrate to bookworm because it would make libbiojava-java-doc 
> uninstallable (no fix there, no bug report filed).

I did not upload libcommons-dbcp-java and I was not aware of the problem. I
will take care of it. 

> src:tiles also build-depends on libtomcat9-java, with no bug filed for 
> the migration to tomcat10 *and* it having it's own FTBFS bug. (It's key 
> because of src:libspring-java)

Again I was not aware of src:tiles, probably because there was an RC bug
already. This problem seems solvable too.

> On IRC carnil and jmm_ suggested that src:tomcat9 could be left in 
> bookworm but have it's server component stripped. Would that help the 
> situation?

Yes, that was one of my suggestions. 

> Everything in this transition would still need an unblock by the release 
> team, as we're now very close to the hard freeze (24 May) and nearly 
> ready to release.

I suggest we just drop all tomcat9 binary packages except libtomcat9-java and I
fix tiles and libcommons-dbcp-java. That seems to be the easiest solution right
now.

Regards,

Markus



[1] https://bugs.debian.org/1031816#37


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

Bug#1035717: closed by Sebastian Ramacher (unblock binoculars)

[picca]

thanks a lot

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

On Thu, 11 May 2023 at 02:43, Andres Salomon  wrote:
>
> On Sat, 11 Mar 2023 11:04:15 + James Addison 
> wrote:
>  > Package: nodejs
>  > Followup-For: Bug #1030284
>  > X-Debbugs-Cc: t...@debian.org
>  >
>  > Guidance received from the V8 project (a vendored dependency in the
> upstream
>  > NodeJS codebase) on the v8-dev mailing list is, in
> summary/interpretation:
>  >
>  >   * It is not yet safe to increase the stack size limit on ARM64
> systems.
> [...]
>  > Sidenotes:
>  >
>  > A patch for 32-bit architectures could apparently be acceptable,
> although may
>  > be best offered to NodeJS rather than V8.  For what it's worth:
> NodeJS seems
>  > to have a policy of not accepting patches to their vendored
> dependencies.
>  >
>
> In reading Jakob's response
> (https://groups.google.com/g/v8-dev/c/7ZI3vxtabcU/m/c9qvHkOBBAAJ), I'm
> interpreting it slightly differently-
>
> He says that raising the stack limit *is* safe for 32-bit ARM, even
> inside of the V8 upstream source tree.
>
> For ARM64, he says that raising the stack limit is not safe for v8
> *embedded inside WebView*, and therefore not appropriate for upstream
> v8. But then he says it could/should be safe for v8 *embedded inside
> NodeJS*.
>
> Based on that, I suggest patching Debian's NodeJS with the patch to
> adjust armhf/arm64 stack limit size to 984kb. With the caveat that the
> javascript code that is triggering this bug should really be fixed to
> not be so stack-intensive, of course. Perhaps this bug cloned at a
> lower severity, filed against those packages that this bug is affecting?
>
> (As chromium maintainer, which also embeds v8, I haven't heard of any
> issues and hadn't planned on touching stacks limits. It sure would be
> nice to have just one copy of V8 in the archive, though..)

I have a question: if we apply the patch and begin using the same
constant stack size of 984kb on 32-bit ARM and 64-bit ARM as is
defined for other architectures, then does NodeJS on those platforms
begin supporting exactly the same stack frame capacity (maximum call
depth for any given recursive function, for example) as a build of the
same NodeJS source on x86 and amd64 respectively?

Bug#1034424: buildd.debian.org: Please use predictible build paths

[Aurelien Jarno]

Hi,

On 2023-05-11 22:10, Philipp Kern wrote:
> On 2023-05-11 07:11, Johannes Schauer Marin Rodrigues wrote:
> > I think the main purpose for the log filtering is to make log files
> > easily
> > grep-able despite the build path having random components.
> 
> I'd say it's also to allow diffing. That might be a lost cause when
> parallelism is involved, though.

Yes, I agree with that, I definitely remember doing so to understand why
a new upload with minimal changes fails to build or produce broken
binaries. In such cases <> is slightly different as the
version is not the same, even with a fixed build directory.

Also it should be noticed that the log filtering feature also filters
<> and <>, although I don't think it provides any
help here.

Cheers
Aurelien 

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

Bug#1035968: fonts-junicode: Wrong package description

[Hilmar Preusse]

Package: fonts-junicode
Version: 2+git20230104+ds-1
Severity: normal

Dear Maintainer,

the package description reads:

"This is a TrueType Unicode font targeted at medievalists..."

However the package just contains OpenType fonts since one of the
latest uploads.  Not sure if this is intended.

Hilmar

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

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

fonts-junicode depends on no packages.

Versions of packages fonts-junicode recommends:
ii  fontconfig  2.14.1-4

Versions of packages fonts-junicode suggests:
ii  fontforge  1:20230101~dfsg-1

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1034424: buildd.debian.org: Please use predictible build paths

[Philipp Kern]

On 2023-05-11 07:11, Johannes Schauer Marin Rodrigues wrote:
I think the main purpose for the log filtering is to make log files 
easily

grep-able despite the build path having random components.


I'd say it's also to allow diffing. That might be a lost cause when 
parallelism is involved, though.


Kind regards
Philipp Kern

Bug#1034248: release-notes: Document that GTK4 apps are not accessible with screen reader

[Paul Gevers]

Control: tags -1 pending

Hi,

For final review:

https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/167

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035947: fresh build from git fails with cannot access local variable 'new_file'

[Mike Hommey]

severity 1035947 normal
thanks

This would be serious if it failed to build with the sources in the
Debian archive, which is what counts.

Note that using uscan doesn't get you all the sources.

On Thu, May 11, 2023 at 10:32:40AM -0400, Antoine Beaupre wrote:
> Source: firefox
> Severity: serious
> Tags: patch ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> I'm trying to build Firefox 113 from the git repository. I have pulled
> the package with:
> 
> debcheckout firefox
> 
> Then tried to download the latest tarballs with:
> 
> uscan --download-current

> 
> This crashes with a Python exception:
> 
> anarcat@angela:firefox$ uscan --download-current
> Newest version of firefox on remote site is 113.0, specified download version 
> is 113.0
> uscan warn: Possible OpenPGP signature found at:
>
> https://archive.mozilla.org/pub/firefox/releases/113.0/source/firefox-113.0.source.tar.xz.asc
>  * Add opts=pgpsigurlmangle=s/$/.asc/ or opts=pgpmode=auto to debian/watch
>  * Add debian/upstream/signing-key.asc.
>  See uscan(1) for more details
> Successfully symlinked ../firefox-113.0.source.tar.xz to 
> ../firefox_113.0.orig.tar.xz.
> Traceback (most recent call last):
>   File "/home/anarcat/dist/firefox/debian/repack.py", line 217, in 
> main()
>   File "/home/anarcat/dist/firefox/debian/repack.py", line 205, in main
> if not new_file:
>
> UnboundLocalError: cannot access local variable 'new_file' where it is not 
> associated with a value
> uscan: error: python3 debian/repack.py --upstream-version 113.0 
> ../firefox_113.0.orig.tar.xz subprocess returned exit status 1
> anarcat@angela:firefox[1]$ 
> 
> I believe the following patch fixes the issue somehow:
> 
> diff --git i/debian/repack.py w/debian/repack.py
> index 00d20928f6e..4f04ea200fb 100755
> --- i/debian/repack.py
> +++ w/debian/repack.py
> @@ -199,6 +199,8 @@ def main():
>  
>  if options.new_file:
>  new_file = options.new_file
> +else:
> +new_file = None
>  
>  if os.path.islink(args[0]):
>  orig = os.path.realpath(args[0])
> 
> a.
> 
> -- Package-specific info:
> 
> 
> -- Addons package information
> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
> 'stable-security'), (500, 'testing'), (500, 'stable'), (1, 'experimental'), 
> (1, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-8-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> -- no debconf information
> 

Bug#1035913: reopen / Re: Bug#1035913: fixed in doc-debian 11.2

[Joost van Baal-Ilić]

reopen 1035913
thanks

On Thu, May 11, 2023 at 01:55:48PM +0200, Joost van Baal-Ilić wrote:

> 
> This bug should get reopened.

Doing so.

Bye,

Joost

Bug#1035967: ypserv: yphelper, yppush fail to run with segmentation fault

[Rob Pumphrey]

Package: ypserv
Version: 4.1-2
Severity: important

Dear Maintainer,

Recently upgraded our NIS master from buster to bullseye. 
when I run
cd /var/yp; make 
several apps fail to run and seg fault, for example

/usr/lib/yp/yphelper  --hostname
Segmentation fault


yppush -d example.com ypservers
Segmentation fault

makedbm does appear to make valid files when run from the cmd line



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

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

Versions of packages ypserv depends on:
ii  hostname   3.23
ii  libc6  2.31-13+deb11u6
ii  libcrypt1  1:4.4.18-4
ii  libgdbm6   1.19-2
ii  libnsl21.3.0-2
ii  libsystemd0247.3-7+deb11u2
ii  libtirpc3  1.3.1-1+deb11u1
ii  lsb-base   11.1.0
ii  make   4.3-4.1
ii  rpcbind [portmap]  1.2.5-9
ii  ucf3.0043

Versions of packages ypserv recommends:
ii  yp-tools  4.2.3-3

Versions of packages ypserv suggests:
pn  krb5-kdc   
ii  ypbind-mt  2.7.2-2

-- no debconf information

Bug#1035710: closing / Re: unblock: doc-debian/11.1

[Joost van Baal-Ilić]

Closing this request.  11.2 which is in experimental [11.2] is better suited
for bookworm: it has a smaller diff with what's in stable now.  However, since
11.2 has some other problems ( #1035913 ), I'll do more work in the coming days
and hope to come up with an ever better candidate for bookworm.  Sorry for the
noise.

Bye,

Joost


[11.2] 
https://tracker.debian.org/news/1430982/accepted-doc-debian-112-source-into-experimental/

Bug#1035966: unblock: google-android-installers/1675172738

[Fab Stz]

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

Please unblock package google-android-installers

At the time of writing this, I'm waiting for my sponsor to upload the latest 
version to unstable. It is also tagged in the VCS if you want to upload it 
yourself. See:

https://salsa.debian.org/google-android-tools-team/google-android-installers

https://salsa.debian.org/google-android-tools-team/google-android-installers/-/tags/debian%2F1675172738

[ Reason ]
(Explain what the reason for the unblock request is.)
A RC bug was filed towards the package: #1035713

[ Impact ]
(What is the impact for the user if the unblock isn't granted?)

[ Tests ]
(What automated or manual tests cover the affected code?)

- I tested that the binary package doesn't have any broken symbolic links, and 
that the symbolic links target the correct file.
- I tested that the change didn't break installation with the other binary 
packages.

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)

No particular risk AFAIK.

[ 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 ]
(Anything else the release team should know.)

At the time of writing this, I'm waiting for my sponsor to upload the latest 
version to unstable. It is also tagged in the VCS if you want to upload it 
yourself.

unblock google-android-installers/1675172738
diff -Nru google-android-installers-1675172737/debian/changelog google-android-installers-1675172738/debian/changelog
--- google-android-installers-1675172737/debian/changelog	2023-04-09 22:31:58.0 +0200
+++ google-android-installers-1675172738/debian/changelog	2023-05-09 17:35:00.0 +0200
@@ -1,3 +1,9 @@
+google-android-installers (1675172738) unstable; urgency=medium
+
+  * Makefile: fix broken symbolic links (Closes: #1035713)
+
+ -- Fab Stz   Tue, 09 May 2023 17:35:00 +0200
+
 google-android-installers (1675172737) unstable; urgency=medium
 
   * cmdline-tools: set Architecture to 'amd64 i386'
diff -Nru google-android-installers-1675172737/for-postinst/default/Makefile google-android-installers-1675172738/for-postinst/default/Makefile
--- google-android-installers-1675172737/for-postinst/default/Makefile	2023-04-09 22:31:58.0 +0200
+++ google-android-installers-1675172738/for-postinst/default/Makefile	2023-05-09 17:35:00.0 +0200
@@ -49,6 +49,34 @@
 	  cd $(DL_DIR) && unzip -ouq $(DL_DIR)/$(PKG_SOURCE); \
 	fi
 
+# Search for broken symbolic links & fix them
+	@if [ $$(unzip -Z -1 $(DL_DIR)/$(PKG_SOURCE) | cut -d '/' -f1 | sort -u | wc -l) -gt 1 ]; then \
+	  ZIP_ROOT_DIR=$(TRG_DIR) ;\
+	else \
+	  ZIP_ROOT_DIR=$$(unzip -Z -1 $(DL_DIR)/$(PKG_SOURCE) | head -1 | cut -d '/' -f 1) ;\
+	fi && \
+	BROKEN_SYMLINKS=$$(cd $(DL_DIR)/$$ZIP_ROOT_DIR && find -xtype l -exec ls {} \;) && \
+	if [ -n "$$BROKEN_SYMLINKS" ]; then \
+	  echo "\n  Fixing broken symbolic links."; \
+	fi && \
+	for file in $$BROKEN_SYMLINKS; do \
+	  cd $(DL_DIR)/$$ZIP_ROOT_DIR && \
+	  LINK_TARGET=$$(readlink "$$file") && \
+	  REL_PATH_TO_TARGET=$$(echo "$$LINK_TARGET" | sed "s|.*$$ZIP_ROOT_DIR/\(.*\)|\1|") && \
+	  echo "Replacing symbolic link: $$file" && \
+	  echo "  Original target: $$LINK_TARGET" && \
+	  echo "  New target: $$REL_PATH_TO_TARGET" && \
+	  ln -fsr "$$REL_PATH_TO_TARGET" "$$file"; \
+	done; \
+	BROKEN_SYMLINKS_AFTER=$$(cd $(DL_DIR)/$$ZIP_ROOT_DIR && find -xtype l -exec ls {} \;) && \
+	if [ -n "$$BROKEN_SYMLINKS_AFTER" ]; then \
+	  echo "\n  Some files have broken symbolic links. Please report a bug to the package maintainer\n"; \
+	  for item in $$BROKEN_SYMLINKS_AFTER; do \
+	echo "$$item"; \
+	  done && \
+	  exit 1 ;\
+	fi
+
 $(DL_DIR)/$(PKG_SOURCE):
 	cd $(DL_DIR) && \
 		su nobody -s /bin/sh -c "wget --continue $(PKG_SOURCE_URL) -O $(PKG_SOURCE).tmp && mv $(PKG_SOURCE).tmp $(PKG_SOURCE)"

Bug#1035965: python-ansible-pygments: Autopkgtest fails against pygments 2.15

[Olivier Gayot]

Package: python-ansible-pygments
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

Dear Maintainer,

Since the move to pygments 2.15, the autopkgtest testsuite fails with
the following error:

Traceback (most recent call last):
  File "/home/olivier/dev/canonical/ansible-pygments/tests/lexer_test.py", line 
131, in 
test_ansible_output_lexer()
  File "/home/olivier/dev/canonical/ansible-pygments/tests/lexer_test.py", line 
78, in test_ansible_output_lexer
assert result == R"""ok: [windows] = 
{
   
^^
AssertionError

The bug was fixed upstream by
https://github.com/ansible-community/ansible-pygments/pull/34.

In Ubuntu, the attached patch was applied to achieve the following:

  * Add patch from upstream to fix test suite against pygments 2.15
Added patch:
debian/patches/Make-lexer-test-compare-tokens.patch
(LP: #2019237)

Thanks for considering the patch.


-- System Information:
Debian Release: bookworm/sid
  APT prefers lunar-updates
  APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
python-ansible-pygments-0.1.1/debian/patches/Make-lexer-test-compare-tokens.patch
 
python-ansible-pygments-0.1.1/debian/patches/Make-lexer-test-compare-tokens.patch
--- 
python-ansible-pygments-0.1.1/debian/patches/Make-lexer-test-compare-tokens.patch
   1970-01-01 01:00:00.0 +0100
+++ 
python-ansible-pygments-0.1.1/debian/patches/Make-lexer-test-compare-tokens.patch
   2023-05-11 21:30:42.0 +0200
@@ -0,0 +1,342 @@
+Description: Make lexer test compare tokens
+ With new releases of `pygments`, this test was getting broken again
+ and again because it originally relied on HTML the formatted text
+ output. Hence, it was prone to external influence for no good reason.
+ .
+ This patch rewrites it to solely rely on the underlying tokens that
+ our lexer produces, therefore reducing the dependence on unrelated
+ changes in the `pygments` library.
+Author: Sviatoslav Sydorenko 
+Origin: upstream, https://github.com/ansible-community/ansible-pygments/pull/34
+Bug: https://github.com/ansible-community/ansible-pygments/issues/33
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2019237
+Applied-Upstream: 
https://github.com/ansible-community/ansible-pygments/commit/179c74e9f1a5dc870dec6d4db6cab60d2dca1ed2
+Last-Update: 2023-05-11
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/tests/lexer_test.py b/tests/lexer_test.py
+index 5b700a9..a842a7c 100644
+--- a/tests/lexer_test.py
 b/tests/lexer_test.py
+@@ -1,26 +1,24 @@
+ # Author: Felix Fontein 
+ # License: BSD-2-Clause
+ # Copyright: Felix Fontein , 2021
+-"""Tests for Pygments lexers."""
++"""Tests for Pygments lexers.
+ 
+-from pygments import highlight
+-# pylint: disable=no-name-in-module
+-# Ref: https://github.com/PyCQA/pylint/issues/491
+-from pygments.formatters import HtmlFormatter
+-
+-from ansible_pygments.lexers import AnsibleOutputLexer
++They rely on token comparison for stability reasons. Relying on
++additional style formatting is known to break with updates to
++the pygments library itself.
++"""
+ 
++from pygments import __version__ as _pygments_version
++from pygments.lexers import get_lexer_by_name as _get_lexer_by_name
++from pygments.token import Token
+ 
+-def run_test(data, lexer):
+-"""Format the data snippet as HTML using a given lexer."""
+-formatter = HtmlFormatter()
+-result = highlight(data, lexer, formatter)
+-return formatter.get_style_defs('.highlight'), result
++PYGMENTS_VERSION_INFO = tuple(map(int, _pygments_version.split('.')))
++IS_OLD_PYGMENTS_PRE_2_14 = PYGMENTS_VERSION_INFO <= (2, 14, 0)
+ 
+ 
+ def test_ansible_output_lexer():
+-"""Test that AnsibleOutputLexer produces expected HTML output."""
+-data = R"""
++"""Test that ``AnsibleOutputLexer`` produces expected tokens."""
++ansible_play_output_example = R"""
+ ok: [windows] => {
+ "account": {
+ "account_name": "vagrant-domain",
+@@ -71,58 +69,226 @@ Sunday 11 November 2018  20:19:25 +0100 (0:00:00.607) 
  0:10:36.974 ***
+ 
+ changed: [localhost]
+ """
+-_, result = run_test(data, AnsibleOutputLexer())
+-print(result)
+-
+-# pylint: disable=line-too-long
+-assert result == R"""ok: [windows] = 
{
+-account: {
+-account_name: vagrant-domain,
+-

Bug#1034824: tomcat9 should not be released with Bookworm

[Paul Gevers]

Hi Markus,

On Tue, 25 Apr 2023 16:04:09 +0200 Markus Koschany  wrote:

We can only support one major Tomcat version per release. Tomcat9 has
been part of Buster and Bullseye already and is superseded by Tomcat
10 in Bookworm. I wanted to wait with the removal request until the
issues in [resteasy3.0] and [tomcatjss] have been resolved but to make
it more obvious I am filing this bug report now.


Release Team member here. I'll note that I'm not impressed by the 
communication and timing of this bug. We're in Full Freeze for bookworm. 
This is no time for transitions, let alone for *uncoordinated* ones.


You should have raised the issue earlier and brought it to the release 
team. tomcat9 and tomcat10 are both key packages so neither can easily 
be removed.


From a quick look at the key packages:

It seems you didn't follow up (86 days) on libcommons-dbcp-java which 
can't migrate to bookworm because it would make libbiojava-java-doc 
uninstallable (no fix there, no bug report filed).


src:tiles also build-depends on libtomcat9-java, with no bug filed for 
the migration to tomcat10 *and* it having it's own FTBFS bug. (It's key 
because of src:libspring-java)


On IRC carnil and jmm_ suggested that src:tomcat9 could be left in 
bookworm but have it's server component stripped. Would that help the 
situation?


Everything in this transition would still need an unblock by the release 
team, as we're now very close to the hard freeze (24 May) and nearly 
ready to release.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035289: merecat: diff for NMU version 2.31+git20220513+ds-4.1

[Joost van Baal-Ilić]

Hi gregor,

Awesome, thanks a lot!  (And no need to delay longer.)

Bye,

Joost


On Thu, May 11, 2023 at 08:54:27PM +0200, gregor herrmann wrote:
> Control: tags 1035289 + patch
> Control: tags 1035289 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for merecat (versioned as 2.31+git20220513+ds-4.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> 
> 
> -- 
>  .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
>  : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
>  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
>`-   

> diff -Nru merecat-2.31+git20220513+ds/debian/changelog 
> merecat-2.31+git20220513+ds/debian/changelog
> --- merecat-2.31+git20220513+ds/debian/changelog  2023-02-23 
> 07:09:58.0 +0100
> +++ merecat-2.31+git20220513+ds/debian/changelog  2023-05-11 
> 20:47:24.0 +0200
> @@ -1,3 +1,13 @@
> +merecat (2.31+git20220513+ds-4.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix "postinst uses /usr/share/doc content (Policy 12.3):
> +/usr/share/doc/merecat/examples/merecat.conf":
> +Install example config files to /usr/share/merecat and symlink them from
> +/usr/share/doc/merecat/examples. (Closes: #1035289)
> +
> + -- gregor herrmann   Thu, 11 May 2023 20:47:24 +0200
> +
>  merecat (2.31+git20220513+ds-4) unstable; urgency=medium
>  
>* Upload to unstable.
> diff -Nru merecat-2.31+git20220513+ds/debian/install 
> merecat-2.31+git20220513+ds/debian/install
> --- merecat-2.31+git20220513+ds/debian/install2023-02-17 
> 09:47:41.0 +0100
> +++ merecat-2.31+git20220513+ds/debian/install2023-05-11 
> 20:47:24.0 +0200
> @@ -1 +1,3 @@
>  merecat.service lib/systemd/system
> +throttle.conf   usr/share/merecat
> +merecat.confusr/share/merecat
> diff -Nru merecat-2.31+git20220513+ds/debian/merecat.examples 
> merecat-2.31+git20220513+ds/debian/merecat.examples
> --- merecat-2.31+git20220513+ds/debian/merecat.examples   2022-05-05 
> 09:52:36.0 +0200
> +++ merecat-2.31+git20220513+ds/debian/merecat.examples   1970-01-01 
> 01:00:00.0 +0100
> @@ -1,2 +0,0 @@
> -throttle.conf
> -merecat.conf
> diff -Nru merecat-2.31+git20220513+ds/debian/merecat.links 
> merecat-2.31+git20220513+ds/debian/merecat.links
> --- merecat-2.31+git20220513+ds/debian/merecat.links  1970-01-01 
> 01:00:00.0 +0100
> +++ merecat-2.31+git20220513+ds/debian/merecat.links  2023-05-11 
> 19:58:06.0 +0200
> @@ -0,0 +1,2 @@
> +usr/share/merecat/throttle.conf usr/share/doc/merecat/examples/throttle.conf
> +usr/share/merecat/merecat.conf  usr/share/doc/merecat/examples/merecat.conf

Bug#1035615: xz-utils: Fix hurd-amd64 build

[Sebastian Andrzej Siewior]

On 2023-05-09 22:58:43 [+0200], Samuel Thibault wrote:
> My patch is not a nop. Previously to Lasse's commit, the
> --enable-assembler=x86_64 option would make no difference from
> --enable-assembler=no. With Lasse's commit, --enable-assembler=x86_64
> is now *refused* by ./configure. And thus amd64 builds break... But
> only on hurd, because that's only where debian/rules passes an
> --enable-assembler option at all.

It also passes it on amd64 but this gets filtered out due to linux as
the host os. Eitherway, I'm going to stash for an upload post release.

> Samuel

Sebastian

Bug#1035289: merecat: diff for NMU version 2.31+git20220513+ds-4.1

[gregor herrmann]

[2nd try, I forgot to adjust the postinst, sorry for the blunder.]

Dear maintainer,

I've prepared an NMU for merecat (versioned as 2.31+git20220513+ds-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru merecat-2.31+git20220513+ds/debian/changelog merecat-2.31+git20220513+ds/debian/changelog
--- merecat-2.31+git20220513+ds/debian/changelog	2023-02-23 07:09:58.0 +0100
+++ merecat-2.31+git20220513+ds/debian/changelog	2023-05-11 20:47:24.0 +0200
@@ -1,3 +1,15 @@
+merecat (2.31+git20220513+ds-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "postinst uses /usr/share/doc content (Policy 12.3):
+/usr/share/doc/merecat/examples/merecat.conf":
+Install example config files to /usr/share/merecat, symlink them from
+/usr/share/doc/merecat/examples, and use the ones from /usr/share/merecat
+in the postinst.
+(Closes: #1035289)
+
+ -- gregor herrmann   Thu, 11 May 2023 20:47:24 +0200
+
 merecat (2.31+git20220513+ds-4) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru merecat-2.31+git20220513+ds/debian/install merecat-2.31+git20220513+ds/debian/install
--- merecat-2.31+git20220513+ds/debian/install	2023-02-17 09:47:41.0 +0100
+++ merecat-2.31+git20220513+ds/debian/install	2023-05-11 20:47:24.0 +0200
@@ -1 +1,3 @@
 merecat.service lib/systemd/system
+throttle.conf   usr/share/merecat
+merecat.confusr/share/merecat
diff -Nru merecat-2.31+git20220513+ds/debian/merecat.examples merecat-2.31+git20220513+ds/debian/merecat.examples
--- merecat-2.31+git20220513+ds/debian/merecat.examples	2022-05-05 09:52:36.0 +0200
+++ merecat-2.31+git20220513+ds/debian/merecat.examples	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-throttle.conf
-merecat.conf
diff -Nru merecat-2.31+git20220513+ds/debian/merecat.links merecat-2.31+git20220513+ds/debian/merecat.links
--- merecat-2.31+git20220513+ds/debian/merecat.links	1970-01-01 01:00:00.0 +0100
+++ merecat-2.31+git20220513+ds/debian/merecat.links	2023-05-11 19:58:06.0 +0200
@@ -0,0 +1,2 @@
+usr/share/merecat/throttle.conf usr/share/doc/merecat/examples/throttle.conf
+usr/share/merecat/merecat.conf  usr/share/doc/merecat/examples/merecat.conf
diff -Nru merecat-2.31+git20220513+ds/debian/merecat.postinst merecat-2.31+git20220513+ds/debian/merecat.postinst
--- merecat-2.31+git20220513+ds/debian/merecat.postinst	2023-02-17 09:56:29.0 +0100
+++ merecat-2.31+git20220513+ds/debian/merecat.postinst	2023-05-11 20:47:24.0 +0200
@@ -5,8 +5,8 @@
 
 case "$1" in
   configure)
-ucf usr/share/doc/merecat/examples/merecat.conf /etc/merecat.conf
-ucf usr/share/doc/merecat/examples/throttle.conf /etc/throttle.conf
+ucf usr/share/merecat/merecat.conf /etc/merecat.conf
+ucf usr/share/merecat/throttle.conf /etc/throttle.conf
   ;;
   abort-upgrade|abort-remove|abort-deconfigure)
   ;;


signature.asc
Description: Digital Signature

Bug#1035964: emacs-common: Is dependency to emacs-el necessary?

[Dirk Lehmann]

Package: emacs-common
Version: 1:28.2+1-14
Severity: normal

Dear Maintainer,

since some months emacs-common is depending on emacs-el.  I am weak
remembering that this dependency should be just temporarily.  On my
side it is not important, but the Lisp-compiling during runtime feels
stressful.  I am not sure if that issue is related to
emacs-bin-common.

Can you leave this report open, until the emacs-el dependency is
removed from emacs-common?

Greets,
Dirk Lehmann




-- 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.0-8-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to de_DE.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages emacs-common depends on:
ii  emacs-el 1:28.2+1-14
ii  emacsen-common   3.0.5
ii  init-system-helpers  1.65.2
ii  install-info 6.8-6+b1

emacs-common recommends no packages.

Versions of packages emacs-common suggests:
pn  emacs-common-non-dfsg  
ii  ncurses-term   6.4-2

-- no debconf information

Bug#1035289: merecat: diff for NMU version 2.31+git20220513+ds-4.1

[gregor herrmann]

Control: tags 1035289 + patch
Control: tags 1035289 + pending


Dear maintainer,

I've prepared an NMU for merecat (versioned as 2.31+git20220513+ds-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru merecat-2.31+git20220513+ds/debian/changelog merecat-2.31+git20220513+ds/debian/changelog
--- merecat-2.31+git20220513+ds/debian/changelog	2023-02-23 07:09:58.0 +0100
+++ merecat-2.31+git20220513+ds/debian/changelog	2023-05-11 20:47:24.0 +0200
@@ -1,3 +1,13 @@
+merecat (2.31+git20220513+ds-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "postinst uses /usr/share/doc content (Policy 12.3):
+/usr/share/doc/merecat/examples/merecat.conf":
+Install example config files to /usr/share/merecat and symlink them from
+/usr/share/doc/merecat/examples. (Closes: #1035289)
+
+ -- gregor herrmann   Thu, 11 May 2023 20:47:24 +0200
+
 merecat (2.31+git20220513+ds-4) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru merecat-2.31+git20220513+ds/debian/install merecat-2.31+git20220513+ds/debian/install
--- merecat-2.31+git20220513+ds/debian/install	2023-02-17 09:47:41.0 +0100
+++ merecat-2.31+git20220513+ds/debian/install	2023-05-11 20:47:24.0 +0200
@@ -1 +1,3 @@
 merecat.service lib/systemd/system
+throttle.conf   usr/share/merecat
+merecat.confusr/share/merecat
diff -Nru merecat-2.31+git20220513+ds/debian/merecat.examples merecat-2.31+git20220513+ds/debian/merecat.examples
--- merecat-2.31+git20220513+ds/debian/merecat.examples	2022-05-05 09:52:36.0 +0200
+++ merecat-2.31+git20220513+ds/debian/merecat.examples	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-throttle.conf
-merecat.conf
diff -Nru merecat-2.31+git20220513+ds/debian/merecat.links merecat-2.31+git20220513+ds/debian/merecat.links
--- merecat-2.31+git20220513+ds/debian/merecat.links	1970-01-01 01:00:00.0 +0100
+++ merecat-2.31+git20220513+ds/debian/merecat.links	2023-05-11 19:58:06.0 +0200
@@ -0,0 +1,2 @@
+usr/share/merecat/throttle.conf usr/share/doc/merecat/examples/throttle.conf
+usr/share/merecat/merecat.conf  usr/share/doc/merecat/examples/merecat.conf


signature.asc
Description: Digital Signature

Bug#1035639: git-imerge: FTBFS with tox 4

[Stefano Rivera]

Hi Paul (2023.05.07_18:28:34_-0400)
> For the dh-python side, to allow tox 4 to work with packages that have
> install_requires set, I've had to change the way we drive tox a little.
> https://salsa.debian.org/python-team/tools/dh-python/-/commit/d86475ab1097fa91d2332eb1bc65e123192ea14d
> 
> This will require an additional Build-Depends on python3-wheel for
> git-imerge.
> 
> I'll upload that new dh-python to experimental, in a day or two.

That's uploaded as dh-python 5.20230510.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1029201: openbox-menu: do not release with bookworm

[Mateusz Łukasik]

On 9.05.2023 at 14:47 +0200, Bastian Germann wrote:

On Thu, 19 Jan 2023 15:17:26 +0100 mat...@linuxmint.pl wrote:

openbox-menu should not be shipped in bookworm.
Will you also file a RM bug or are you going to update the package for 
later releases?



I found new place of source https://github.com/fabriceT/openbox-menu but 
is also dead, so I will create RM bug after bookworm release.


--
.''`.  Mateusz Łukasik
: :' :  l0calh0st.pl
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Paul Gevers]

Control: tags -1 patch pending

Hi,

Please review my proposal here:

https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035916: unblock: node-source-map/0.7.0++dfsg2+really.0.6.1-14

[Sebastian Ramacher]

On 2023-05-11 19:22:36 +0200, Paul Gevers wrote:
> Hi Sebastian,
> 
> On 11-05-2023 19:06, Sebastian Ramacher wrote:
> > So you're going back to a directory. That would require a symlink_to_dir
> > in the maintscript. Do you want to have symlinks or not?
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035916#12

Ah, thanks. Somehow missed that message in the bug.

Cheers
-- 
Sebastian Ramacher

Bug#1035917: chromium: libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed

[Andres Salomon]

Okay, so an older CPU that the newer intel vaapi driver is broken on. 
If you just uninstall intel-media-va-driver and 
intel-media-va-driver-non-free, does chromium work? You'd be relying on 
the older driver from i965-va-driver at that point.



On Thu, May 11 2023 at 07:50:22 PM +02:00:00, Mathias Behrle 
 wrote:

* Andres Salomon: " Re: Bug#1035917: chromium: libva error:
  /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed" (Thu, 
11 May 2023

  11:48:48 -0400):

Hi Andres,

thanks for your feedback.


 I'm guessing that the following is also broken for you:

 vainfo


Not really broken, but

libva info: VA-API version 1.17.0
libva info: Trying to open 
/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so

libva info: Found init function __vaDriverInit_1_17
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init 
failed

libva info: va_openDriver() returns 1
libva info: Trying to open 
/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so

libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.17 (libva 2.12.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Haswell 
Desktop - 2.4.1

vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Simple: VAEntrypointEncSlice
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileH264MultiviewHigh  : VAEntrypointVLD
  VAProfileH264MultiviewHigh  : VAEntrypointEncSlice
  VAProfileH264StereoHigh : VAEntrypointVLD
  VAProfileH264StereoHigh : VAEntrypointEncSlice
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc
  VAProfileJPEGBaseline   : VAEntrypointVLD

 You could also try the following to see if the other intel driver 
isn't

 broken:

 LIBVA_DRIVER_NAME=i965 vainfo

 Did this used to work for you? If so, you could try downgrading
 intel-media-va-driver using snapshot.debian.org (or upgrading to the
 version that's in unstable, and hasn't migrated to bookworm yet).


Ok, will try that besides evtl. downgrading chromium.

 Either way, chromium uses vaapi by default; so if the vaapi driver 
for

 your specific hardware is broken, you'll have to figure out which
 combination of flags to disable it work for you (eg,
 
https://www.reddit.com/r/archlinux/comments/tc5379/if_you_have_trouble_getting_vaapi_hardware_video/

 ) until you get vaapi working with your hardware.

 Out of curiosity, what is the GPU and CPU that you're seeing this 
iHD

 driver failure on?


mathiasb@monsterix:~$ cat /proc/cpuinfo
...
GenuineIntel cpu family  : 6 model   : 60 model name  
:

Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz
...

mathiasb@monsterix:~$ glxinfo
...
Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel 
(0x8086)
Device: Mesa Intel(R) HD Graphics 4600 (HSW GT2) (0x412) Version: 
22.3.6
Accelerated: yes Video memory: 1536MB Unified memory: yes Preferred 
profile:
core (0x1) Max core profile version: 4.6 Max compat profile version: 
4.6 Max
GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL 
vendor
string: Intel OpenGL renderer string: Mesa Intel(R) HD Graphics 4600 
(HSW GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.3.6 
OpenGL core

profile shading language version string: 4.60
...


--

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 
0xD6D09BE48405BBF6

AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Luca Boccassi]

On Thu, 11 May 2023 21:16:34 +0900 Simon Richter 
wrote:
> Hi,
> 
> On 5/11/23 10:59, Sean Whitton wrote:
> 
> >> Dear ctte, please consider overruling the dpkg maintainer to
include
> >> the patch from #994388[1].
> 
> > Currently dpkg contains code to emit the merged-/usr warning,
that's
> > dead code on Debian, but which becomes active when packages from
the
> > Debian archive are copied unmodified into derivatives.
> 
> The way I see it (but I'm not a dpkg maintainer), the current 
> implementation is correct, as dpkg does not support aliased
directories, 
> but Debian has decided to use it in such an environment nonetheless.
The 
> tech-ctte decision not to roll back usrmerge accepts responsibility
for 
> this decision, so silencing the warning on Debian is correct, but no
one 
> has accepted that responsibility for derived distributions.
> 
> Any derived distribution can easily go on record and request
inclusion 
> in the list of distributions where this warning is suppressed, by
typing 
> the phrase "Yes, I understand that this is a bad idea." into an email
> client.

The crux of the issue is that we are hearing how negatively affecting
derivatives in any way, even purely theoretically, is a big no-no, in
this very same thread and topic. Reaching out and asking for
directions/help/whatever is not enough in that context. So it follows
that it cannot be enough in this context either, and it must be fixed
instead.

Or alternatively, we can establish that a documentation/post-facto
approach is enough for derivatives, and then that's valid for all
changes and transitions.

Either of these are valid approaches.

What I cannot find acceptable is that some changes get a free pass, and
some get roadblocks after roadblocks thrown at them.

-- 
Kind regards,
Luca Boccassi


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

Bug#1035917: chromium: libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed

[Mathias Behrle]

* Andres Salomon: " Re: Bug#1035917: chromium: libva error:
  /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed" (Thu, 11 May 2023
  11:48:48 -0400):

Hi Andres,

thanks for your feedback.

> I'm guessing that the following is also broken for you:
> 
> vainfo

Not really broken, but

libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.17 (libva 2.12.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Desktop - 2.4.1
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Simple: VAEntrypointEncSlice
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileH264MultiviewHigh  : VAEntrypointVLD
  VAProfileH264MultiviewHigh  : VAEntrypointEncSlice
  VAProfileH264StereoHigh : VAEntrypointVLD
  VAProfileH264StereoHigh : VAEntrypointEncSlice
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc
  VAProfileJPEGBaseline   : VAEntrypointVLD

> You could also try the following to see if the other intel driver isn't 
> broken:
> 
> LIBVA_DRIVER_NAME=i965 vainfo
> 
> Did this used to work for you? If so, you could try downgrading 
> intel-media-va-driver using snapshot.debian.org (or upgrading to the 
> version that's in unstable, and hasn't migrated to bookworm yet).

Ok, will try that besides evtl. downgrading chromium.
 
> Either way, chromium uses vaapi by default; so if the vaapi driver for 
> your specific hardware is broken, you'll have to figure out which 
> combination of flags to disable it work for you (eg,  
> https://www.reddit.com/r/archlinux/comments/tc5379/if_you_have_trouble_getting_vaapi_hardware_video/
>  
> ) until you get vaapi working with your hardware.
> 
> Out of curiosity, what is the GPU and CPU that you're seeing this iHD 
> driver failure on?

mathiasb@monsterix:~$ cat /proc/cpuinfo
...
GenuineIntel cpu family  : 6 model   : 60 model name  :
Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz 
...

mathiasb@monsterix:~$ glxinfo
...
Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel (0x8086)
Device: Mesa Intel(R) HD Graphics 4600 (HSW GT2) (0x412) Version: 22.3.6
Accelerated: yes Video memory: 1536MB Unified memory: yes Preferred profile:
core (0x1) Max core profile version: 4.6 Max compat profile version: 4.6 Max
GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL vendor
string: Intel OpenGL renderer string: Mesa Intel(R) HD Graphics 4600 (HSW GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.3.6 OpenGL core
profile shading language version string: 4.60 
...


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#1035286: dnssec-trigger: diff for NMU version 0.17+repack-5.1

[gregor herrmann]

Control: tags 1035286 + patch
Control: tags 1035286 + pending


Dear maintainer,

I've prepared an NMU for dnssec-trigger (versioned as 0.17+repack-5.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -Nru dnssec-trigger-0.17+repack/debian/changelog dnssec-trigger-0.17+repack/debian/changelog
--- dnssec-trigger-0.17+repack/debian/changelog	2021-01-12 06:30:22.0 +0100
+++ dnssec-trigger-0.17+repack/debian/changelog	2023-05-11 19:40:04.0 +0200
@@ -1,3 +1,14 @@
+dnssec-trigger (0.17+repack-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing Depends: openssl":
+Add runtime dependency on openssl.
+/usr/sbin/dnssec-trigger-control-setup, which is also called from the
+postinst, runs the openssl binary.
+(Closes: #1035286)
+
+ -- gregor herrmann   Thu, 11 May 2023 19:40:04 +0200
+
 dnssec-trigger (0.17+repack-5) unstable; urgency=medium
 
   * Recommend e2fsprogs (Closes: #887231) dnssec-trigger tries to call
diff -Nru dnssec-trigger-0.17+repack/debian/control dnssec-trigger-0.17+repack/debian/control
--- dnssec-trigger-0.17+repack/debian/control	2021-01-12 06:30:22.0 +0100
+++ dnssec-trigger-0.17+repack/debian/control	2023-05-11 19:39:30.0 +0200
@@ -27,6 +27,7 @@
 	 python3-gi,
 	 python3-lockfile,
 	 gir1.2-nm-1.0 (>= 1.2) [linux-any],
+	 openssl,
  sensible-utils,
 	 unbound
 Recommends: e2fsprogs


signature.asc
Description: Digital Signature

Bug#1011475: mirror submission for mirror.xtx.cloud #1035928

[Callum White]

Hello,

mirror.xtx.cloud has been fully rebuild and has now become mirror.vinehost.net 


Supported protocols are HTTP, HTTPS and RSYNC

Please refer to new request #1035928

Latest version of ftpsync is in use too

Thank you,
Callum :)

> On 17 Sep 2022, at 15:14, Julien Cristau  wrote:
> 
> Another thing:
> 
> o The tracefile
>  http://mirrors.m247.com/debian/project/trace/mirrors.m247.com
>  suggests that the ftpsync version you are using is very old.  Please upgrade.
> 
>  Using a modern ftpsync ensures updates are done in the correct order
>  so apt clients don't get confused.   In particular, it processes
>  translations, contents, and more files that have been added to the
>  archive in recent years in the correct stage.  It also should produce
>  trace files that contain more information that is useful for us and helps
>  downstream mirrors sync better.
> 
>  http://mirrors.m247.com/debian/project/ftpsync/ftpsync-current.tar.gz
> 
> Cheers,
> Julien
> 
> On Sat, Sep 17, 2022 at 04:12:42PM +0200, Julien Cristau wrote:
>> Control: tag -1 moreinfo
>> 
>> Hi,
>> 
>> I notice there is no tracefile matching your site name mirror.xtx.cloud
>> in http://mirror.xtx.cloud/debian/project/trace/
>> We expect the trace file name to match the mirror name we list, so we
>> can monitor it.
>> You can either change MIRRORNAME in ftpsync.conf, or list the mirror as
>> mirrors.m247.com (which seems to be the current trace file name?).
>> 
>> Cheers,
>> Julien
>> 
>> On Mon, May 23, 2022 at 06:45:14PM +, Mirror Admin wrote:
>>> Package: mirrors
>>> Severity: wishlist
>>> User: mirr...@packages.debian.org
>>> Usertags: mirror-submission
>>> 
>>> Submission-Type: new
>>> Site: mirror.xtx.cloud
>>> Type: leaf
>>> Archive-architecture: amd64 arm64 armhf i386
>>> Archive-http: /debian/
>>> Maintainer: Mirror Admin 
>>> Country: GB United Kingdom
>>> Location: Dorset, UK
>>> Sponsor: XTX Cloud https://www.xtx.cloud
>>> Comment: Hosted with love on a 1Gbit connection
>>> 
>>> 
>>> 
>>> 
>>> Trace Url: http://mirror.xtx.cloud/debian/project/trace/
>>> Trace Url: 
>>> http://mirror.xtx.cloud/debian/project/trace/ftp-master.debian.org
>>> Trace Url: http://mirror.xtx.cloud/debian/project/trace/mirror.xtx.cloud

Bug#1035916: unblock: node-source-map/0.7.0++dfsg2+really.0.6.1-14

[Paul Gevers]

Hi Sebastian,

On 11-05-2023 19:06, Sebastian Ramacher wrote:

So you're going back to a directory. That would require a symlink_to_dir
in the maintscript. Do you want to have symlinks or not?


See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035916#12

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035916: unblock: node-source-map/0.7.0++dfsg2+really.0.6.1-14

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-05-11 10:57:27 +0400, Yadd wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: node-source-...@packages.debian.org
> Control: affects -1 + src:node-source-map
> 
> Please unblock package node-source-map
> 
> [ Reason ]
> There was an error in maintscript, then updates from Bullseye dropped
> the copyright.
> 
> [ Impact ]
> Missing copyright
> 
> [ Risks ]
> No risk
> 
> [ 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
> 
> Cheers,
> Yadd
> 
> unblock node-source-map/0.7.0++dfsg2+really.0.6.1-14

> diff --git a/debian/changelog b/debian/changelog
> index 524ef9d..0de8d6b 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +node-source-map (0.7.0++dfsg2+really.0.6.1-14) unstable; urgency=medium
> +
> +  * Team upload
> +  * Fix maintscript (Closes: #1035805). Thanks to Andreas Beckmann.
> +
> + -- Yadd   Thu, 11 May 2023 06:30:12 +0400
> +
>  node-source-map (0.7.0++dfsg2+really.0.6.1-13) unstable; urgency=medium
>  
>* Team upload
> diff --git a/debian/node-source-map.maintscript 
> b/debian/node-source-map.maintscript
> index 45938e9..dcfb513 100644
> --- a/debian/node-source-map.maintscript
> +++ b/debian/node-source-map.maintscript
> @@ -1 +1 @@
> -dir_to_symlink /usr/share/doc/node-source-map ../libjs-source-map 
> 0.7.0++dfsg2+really.0.6.1-9~
> +dir_to_symlink /usr/share/doc/node-source-map libjs-source-map 
> 0.7.0++dfsg2+really.0.6.1-9~
> diff --git a/debian/rules b/debian/rules
> index 55b4534..540fff9 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -15,6 +15,3 @@ override_dh_auto_build:
>  
>  override_dh_auto_clean:
>   rm -rf dist node_modules/.cache
> -
> -override_dh_installdocs:
> - dh_installdocs --link-doc=libjs-source-map

So you're going back to a directory. That would require a symlink_to_dir
in the maintscript. Do you want to have symlinks or not?

Cheers
-- 
Sebastian Ramacher

Bug#1035960: www.debian.org: Language trackinng broken or gone

[Helge Kreutzmann]

Package: www.debian.org
Severity: important
Tags: l10n

The translation robot feeds the langauge tracking on Debians web pages.
This is very important to monitor for new or outdated translations (or
for long running review rounds).

When I just refreshed the web pages to see todays status, many status
are gone or broken.

For German the following pages are affected:
https://www.debian.org/international/l10n/po/de

https://www.debian.org/international/l10n/po-debconf/de

https://www.debian.org/international/l10n/po4a/de

I can give you numerous examples for broken entries, but in the last link
all entries are "empty", while they all should have a sensible status.

Kindly restore them soon, as I'm monitor if any translation needs to
be updated for bookworm (last minute updates).

Thanks!

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#1035938: Workaround to the problem

[Kamil Wilczek]

Installing the 6.1.X kernel from the bullseye-backports
apparently solves the problem, so this might be a temporary
solution to affected systems (if applicable).

Kind regards,
--
Kamil Wilczek [https://keys.openpgp.org/]
[6C4BE20A90A1DBFB3CBE2947A832BF5A491F9F2A]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure

[Bastian Blank]

On Thu, May 11, 2023 at 06:25:00PM +0200, Guilhem Moulin wrote:
> On Thu, 11 May 2023 at 18:12:52 +0200, Bastian Blank wrote:
> > Nope, not really.  Half VG was never a real thing.  It might work in
> > some cases.
> And these use-cases are unbootable since 2.03.15…

Those still have access to an old kernel and initramfs, so can be fixed
without special knowledge.  The fix is then to use vgsplit to have
complete VG available.

Why it worked in the past: there was a block activation script that just
looked into the "root" parameter and enabled exactly that LV.  That was
a fallback to the udev activation.

Bastian

-- 
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3

Bug#1015915: pipewire-pulse leaking memory

[Alban Browaeys]

Can you reproduce with current pipewire?

I am running 0.3.70 from experimental but have pipewire rss at 30.0M
and pipewire-pulse at 116.9M after 16 hours.
You meant pipewire or pipewire-pulse was leaking?


Cheers,
Alban

On Sat, 23 Jul 2022 19:52:44 + Witold Barylulk
 wrote:
> Package: pipewire-pulse
> Version: 0.3.56-1
> Severity: normal
> X-Debbugs-Cc: witold.bary...@gmail.com
> 
> Starts okish, with rss at around 35MB. But grows about 20MB per hour.
> After few days was 2.1GB and didn't stop growing.
> 
> I do not have any special custom configuration.
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.19.0-rc5 (SMP w/32 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages pipewire-pulse depends on:
> ii  init-system-helpers  1.64
> ii  pipewire 0.3.56-1
> 
> pipewire-pulse recommends no packages.
> 
> Versions of packages pipewire-pulse suggests:
> ii  libspa-0.2-bluetooth  0.3.56-1
> ii  pulseaudio-utils  15.0+dfsg1-4+b1
> 
> -- no debconf information
> 
> 

Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure

[Guilhem Moulin]

On Thu, 11 May 2023 at 18:12:52 +0200, Bastian Blank wrote:
> Nope, not really.  Half VG was never a real thing.  It might work in
> some cases.

And these use-cases are unbootable since 2.03.15…

> Then, degraded is the default activation mode, so overriding that would
> not be appropriate.  But forcefully enabling stuff like an incomplete
> raid will trigger rebuilds every time.  So no, this can't be the default
> option.

If that's a concern then ‘--activationmode complete’ can be used instead
(although the boot scripts used the default mode from lvm.conf).  That's
enough to fix the systems rapported here, because the required LVs are
actually complete.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1035959: unblock: jmol/14.32.83+dfsg-1

[Pierre Gruet]

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

Dear Release Team,

I would like to ask for an unblock of package jmol.

[ Reason ]

I fixed RC bug #1035484 which was just a dangling symlink causing piuparts
errors. This was done by removing a line in debian/jmol.links.

[ Impact ]

No impact for the user, only piuparts is affected.

[ Tests ]

I did no test as I only removed a symlink, of which target has not been in the
package for many months.

[ Risks ]

No risk, as no rdep is using the deleted symlink.

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

If the unblock is not granted, the users won't notice anything as there would
only be a void symlink shipped in the package. I would also be fine with it.

Thanks a lot in any case,

-- 
Pierre

unblock jmol/14.32.83+dfsg-1
diff -Nru jmol-14.32.83+dfsg/debian/changelog 
jmol-14.32.83+dfsg/debian/changelog
--- jmol-14.32.83+dfsg/debian/changelog 2023-02-02 16:43:13.0 +0100
+++ jmol-14.32.83+dfsg/debian/changelog 2023-05-04 14:24:33.0 +0200
@@ -1,3 +1,10 @@
+jmol (14.32.83+dfsg-2) unstable; urgency=medium
+
+  * Removing symlink to non-existing /usr/share/java/JSpecView.jar
+(Closes: #1035484)
+
+ -- Pierre Gruet   Thu, 04 May 2023 14:24:33 +0200
+
 jmol (14.32.83+dfsg-1) unstable; urgency=medium
 
   * New upstream version 14.32.83+dfsg
diff -Nru jmol-14.32.83+dfsg/debian/jmol.links 
jmol-14.32.83+dfsg/debian/jmol.links
--- jmol-14.32.83+dfsg/debian/jmol.links2022-10-15 22:47:37.0 
+0200
+++ jmol-14.32.83+dfsg/debian/jmol.links2023-05-04 14:23:08.0 
+0200
@@ -1,6 +1,5 @@
 /usr/share/jmol/icon.png/usr/share/pixmaps/jmol-icon.png
 /usr/share/java/Jmol.jar/usr/share/jmol/Jmol.jar
 /usr/share/java/JmolData.jar/usr/share/jmol/JmolData.jar
-/usr/share/java/JSpecView.jar   /usr/share/jmol/JSpecView.jar
 /usr/share/java/Jvxl.jar/usr/share/jmol/Jvxl.jar
 /usr/bin/jmol   /usr/share/jmol/jmol

Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure

[Bastian Blank]

On Wed, May 10, 2023 at 03:09:04AM +0200, Guilhem Moulin wrote:
> There might be a better way to detect an initramfs-tools environment
> than checking whether ‘/run/initramfs’ exists (and ‘/run/systemd/system’
> doesn't).

The only acceptable way would be a different udev rules file for the
initramfs.

Then, degraded is the default activation mode, so overriding that would
not be appropriate.  But forcefully enabling stuff like an incomplete
raid will trigger rebuilds every time.  So no, this can't be the default
option.

Bastian

-- 
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown

Bug#1035958: ITP: node-types-chrome -- Typescript definitions for Chrome extension development

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: node-types-chrome
  Version : 0.0.235
  Upstream Contact: https://github.com/DefinitelyTyped/DefinitelyTyped/issues
* URL : https://github.com/DefinitelyTyped/DefinitelyTyped
* License : Expat
  Programming Lang: JavaScript
  Description : Typescript definitions for Chrome extension development

Modern JavaScript libraries provides their Typescript definitions to
permits to use them in JavaScript softwares written in Typescript.
When those definitions are missing, instead of writing custom
definitions in each program, some people provides external Typescript
definitions to be reused (definitions for module "foo" are exposed in
@types/foo). In Debian, we chose to embed them inside the node package.
For example, @types/braces is embedded in node-braces.

But @types/* are also used to define anything that can be used in
JavaScript (like @types/filesystem).

This package provides @types/chrome and its generic dependencies:
@types/filesystem and @types/filewriter.

node-types-chrome a dependency of some advanced Node.js modules and will
be a dependency of some Node.js modules needed to build JupyterLab.
It'll be maintained under JS Team umbrella.

Bug#1034816: aide aborts with error "realloc: failed to allocate memory", exit code 22

[Hannes von Haugwitz]

tags 1034816 - moreinfo unreproducible
thanks

Hi Thomas,

On Thu, May 11, 2023 at 05:52:01PM +0200, Thomas Dorner wrote:
> I narrowed it further down with some more fprintfs.  The problem is not
> in do_md.c but the call in hsymlnk in gen_list.c.

Yes, yesterday I was able to reproduce your issue.

Please try the patch available upstream[0] and report back if it fixes
the memory allocation errors.

Thanks for debugging.

Best regards

Hannes

[0] https://github.com/aide/aide/commit/61778cdb42b88ab9591e43bf8de39693d545a278

Bug#1034816: aide aborts with error "realloc: failed to allocate memory", exit code 22

[Thomas Dorner]

Dear maintainers,

I narrowed it further down with some more fprintfs.  The problem is not
in do_md.c but the call in hsymlnk in gen_list.c.  Here the critical
part of the output:

gen_list.c: hsymlnk: '/var/opt/lxc/no-network/lib64', ''
gen_list.c: hsymlnk: len+1 == 0
checked_realloc(0x7fe4f1117290, 0)
failed to reallocate 0 bytes
  ERROR: realloc: failed to allocate memory

The variables in the first fprintf are line->fullpath and
line->linkname.

At the beginning of the aide run /var/opt/lxc/no-network/lib64 is the
following symbolic link (basically an identical copy of the root
/lib64):

lrwxrwxrwx 1 ... /var/opt/lxc/no-network/lib64 -> usr/lib64/

Later (about 30 minutes after the start of dailyaidecheck) the whole
"no-network" tree is deleted.  This apparently leads to an empty
linkname, readlink returns -1, which then results in a call to realloc
with size 0.

(I think the rest is now up to you. ;-)

Best regards, Thomas
-- 
퓣퓱퓸퓶퓪퓼 퓓퓸퓻퓷퓮퓻

Bug#1035917: chromium: libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed

[Andres Salomon]

Control: severity -1 normal



On Thu, May 11 2023 at 09:29:55 AM +02:00:00, Mathias Behrle 
 wrote:

Package: chromium
Version: 113.0.5672.63-2
Severity: important

Dear Maintainer,

I am currently out of luck to guess the correct addressee for this
problem, so please advise.

chromium doesn't start any more since some days with
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init 
failed





I'm guessing that the following is also broken for you:

vainfo

You could also try the following to see if the other intel driver isn't 
broken:


LIBVA_DRIVER_NAME=i965 vainfo

Did this used to work for you? If so, you could try downgrading 
intel-media-va-driver using snapshot.debian.org (or upgrading to the 
version that's in unstable, and hasn't migrated to bookworm yet).


Either way, chromium uses vaapi by default; so if the vaapi driver for 
your specific hardware is broken, you'll have to figure out which 
combination of flags to disable it work for you (eg,  
https://www.reddit.com/r/archlinux/comments/tc5379/if_you_have_trouble_getting_vaapi_hardware_video/ 
) until you get vaapi working with your hardware.


Out of curiosity, what is the GPU and CPU that you're seeing this iHD 
driver failure on?

Bug#1035957: openjdk-17: CVE-2023-21930 CVE-2023-21937 CVE-2023-21938 CVE-2023-21939 CVE-2023-21954 CVE-2023-21967 CVE-2023-21968

[Moritz Mühlenhoff]

Source: openjdk-17
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for openjdk-17.

CVE-2023-21930[0]:
| Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition
| product of Oracle Java SE (component: JSSE). Supported versions that
| are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6,
| 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1.
| Difficult to exploit vulnerability allows unauthenticated attacker
| with network access via TLS to compromise Oracle Java SE, Oracle
| GraalVM Enterprise Edition. Successful attacks of this vulnerability
| can result in unauthorized creation, deletion or modification access
| to critical data or all Oracle Java SE, Oracle GraalVM Enterprise
| Edition accessible data as well as unauthorized access to critical
| data or complete access to all Oracle Java SE, Oracle GraalVM
| Enterprise Edition accessible data. Note: This vulnerability applies
| to Java deployments, typically in clients running sandboxed Java Web
| Start applications or sandboxed Java applets, that load and run
| untrusted code (e.g., code that comes from the internet) and rely on
| the Java sandbox for security. This vulnerability can also be
| exploited by using APIs in the specified Component, e.g., through a
| web service which supplies data to the APIs. CVSS 3.1 Base Score 7.4
| (Confidentiality and Integrity impacts). CVSS Vector:
| (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).


CVE-2023-21937[1]:
| Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition
| product of Oracle Java SE (component: Networking). Supported versions
| that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18,
| 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and
| 22.3.1. Difficult to exploit vulnerability allows unauthenticated
| attacker with network access via multiple protocols to compromise
| Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks
| of this vulnerability can result in unauthorized update, insert or
| delete access to some of Oracle Java SE, Oracle GraalVM Enterprise
| Edition accessible data. Note: This vulnerability applies to Java
| deployments, typically in clients running sandboxed Java Web Start
| applications or sandboxed Java applets, that load and run untrusted
| code (e.g., code that comes from the internet) and rely on the Java
| sandbox for security. This vulnerability can also be exploited by
| using APIs in the specified Component, e.g., through a web service
| which supplies data to the APIs. CVSS 3.1 Base Score 3.7 (Integrity
| impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).


CVE-2023-21938[2]:
| Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition
| product of Oracle Java SE (component: Libraries). Supported versions
| that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18,
| 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and
| 22.3.0. Difficult to exploit vulnerability allows unauthenticated
| attacker with network access via multiple protocols to compromise
| Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks
| of this vulnerability can result in unauthorized update, insert or
| delete access to some of Oracle Java SE, Oracle GraalVM Enterprise
| Edition accessible data. Note: This vulnerability applies to Java
| deployments, typically in clients running sandboxed Java Web Start
| applications or sandboxed Java applets, that load and run untrusted
| code (e.g., code that comes from the internet) and rely on the Java
| sandbox for security. This vulnerability does not apply to Java
| deployments, typically in servers, that load and run only trusted code
| (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7
| (Integrity impacts). CVSS Vector:
| (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).


CVE-2023-21939[3]:
| Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition
| product of Oracle Java SE (component: Swing). Supported versions that
| are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6,
| 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and 22.3.1.
| Easily exploitable vulnerability allows unauthenticated attacker with
| network access via HTTP to compromise Oracle Java SE, Oracle GraalVM
| Enterprise Edition. Successful attacks of this vulnerability can
| result in unauthorized update, insert or delete access to some of
| Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data.
| Note: This vulnerability applies to Java deployments, typically in
| clients running sandboxed Java Web Start applications or sandboxed
| Java applets, that load and run untrusted code (e.g., code that comes
| from the internet) and rely on the Java sandbox for security. This
| vulnerability can also be exploited by using APIs in the specified
| Component, e.g., through a web service which 

Bug#1035956: docker-registry: CVE-2023-2253

[Moritz Mühlenhoff]

Source: docker-registry
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for docker-registry.

CVE-2023-2253[0]:
https://www.openwall.com/lists/oss-security/2023/05/09/1
https://github.com/distribution/distribution/commit/521ea3d973cb0c7089ebbcdd4ccadc34be941f54
https://github.com/distribution/distribution/security/advisories/GHSA-hqxw-f8mx-cpmw

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-2253
https://www.cve.org/CVERecord?id=CVE-2023-2253

Please adjust the affected versions in the BTS as needed.

Bug#1035955: vim: CVE-2023-2610

[Moritz Mühlenhoff]

Source: vim
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for vim.

CVE-2023-2610[0]:
| Integer Overflow or Wraparound in GitHub repository vim/vim prior to
| 9.0.1532.

https://huntr.dev/bounties/31e67340-935b-4f6c-a923-f7246bc29c7d
https://github.com/vim/vim/commit/ab9a2d884b3a4abe319606ea95a5a6d6b01cd73a 
(v9.0.1532)


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-2610
https://www.cve.org/CVERecord?id=CVE-2023-2610

Please adjust the affected versions in the BTS as needed.

Bug#1035954: opencv: CVE-2023-2617 CVE-2023-2618

[Moritz Mühlenhoff]

Source: opencv
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerabilities were published for opencv.

CVE-2023-2617[0]:
| A vulnerability classified as problematic was found in OpenCV
| wechat_qrcode Module up to 4.7.0. Affected by this vulnerability is
| the function DecodedBitStreamParser::decodeByteSegment of the file
| qrcode/decoder/decoded_bit_stream_parser.cpp. The manipulation leads
| to null pointer dereference. The attack can be launched remotely. The
| exploit has been disclosed to the public and may be used. It is
| recommended to apply a patch to fix this issue. The associated
| identifier of this vulnerability is VDB-228547.

https://github.com/opencv/opencv_contrib/pull/3480
https://github.com/opencv/opencv_contrib/commit/ccc277247ac1a7aef0a90353edcdec35fbc5903c

CVE-2023-2618[1]:
| A vulnerability, which was classified as problematic, has been found
| in OpenCV wechat_qrcode Module up to 4.7.0. Affected by this issue is
| the function DecodedBitStreamParser::decodeHanziSegment of the file
| qrcode/decoder/decoded_bit_stream_parser.cpp. The manipulation leads
| to memory leak. The attack may be launched remotely. The name of the
| patch is 2b62ff6181163eea029ed1cab11363b4996e9cd6. It is recommended
| to apply a patch to fix this issue. The identifier of this
| vulnerability is VDB-228548.

https://github.com/opencv/opencv_contrib/pull/3484
https://github.com/opencv/opencv_contrib/commit/2b62ff6181163eea029ed1cab11363b4996e9cd6

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-2617
https://www.cve.org/CVERecord?id=CVE-2023-2617
[1] https://security-tracker.debian.org/tracker/CVE-2023-2618
https://www.cve.org/CVERecord?id=CVE-2023-2618

Please adjust the affected versions in the BTS as needed.

Bug#1035951: yasm: CVE-2023-29579

[Moritz Mühlenhoff]

Source: yasm
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for yasm.

CVE-2023-29579[0]:
| yasm 1.3.0.55.g101bc was discovered to contain a stack overflow via
| the component yasm/yasm+0x43b466 in vsprintf.

https://github.com/yasm/yasm/issues/214

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-29579
https://www.cve.org/CVERecord?id=CVE-2023-29579

Please adjust the affected versions in the BTS as needed.

Bug#1035953: odoo: CVE-2021-23166 CVE-2021-23176 CVE-2021-23178 CVE-2021-23186 CVE-2021-23203 CVE-2021-26263 CVE-2021-26947 CVE-2021-44476 CVE-2021-44775 CVE-2021-45071 CVE-2021-45111

[Moritz Mühlenhoff]

Source: odoo
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for odoo.

CVE-2021-23166[0]:
| A sandboxing issue in Odoo Community 15.0 and earlier and Odoo
| Enterprise 15.0 and earlier allows authenticated administrators to
| read and write local files on the server.


CVE-2021-23176[1]:
| Improper access control in reporting engine of l10n_fr_fec module in
| Odoo Community 15.0 and earlier and Odoo Enterprise 15.0 and earlier
| allows remote authenticated users to extract accounting information
| via crafted RPC packets.


CVE-2021-23178[2]:
| Improper access control in Odoo Community 15.0 and earlier and Odoo
| Enterprise 15.0 and earlier allows attackers to validate online
| payments with a tokenized payment method that belongs to another user,
| causing the victim's payment method to be charged instead.


CVE-2021-23186[3]:
| A sandboxing issue in Odoo Community 15.0 and earlier and Odoo
| Enterprise 15.0 and earlier allows authenticated administrators to
| access and modify database contents of other tenants, in a multi-
| tenant system.


CVE-2021-23203[4]:
| Improper access control in reporting engine of Odoo Community 14.0
| through 15.0, and Odoo Enterprise 14.0 through 15.0, allows remote
| attackers to download PDF reports for arbitrary documents, via crafted
| requests.


CVE-2021-26263[5]:
| Cross-site scripting (XSS) issue in Discuss app of Odoo Community 14.0
| through 15.0, and Odoo Enterprise 14.0 through 15.0, allows remote
| attackers to inject arbitrary web script in the browser of a victim,
| by posting crafted contents.


CVE-2021-26947[6]:
| Cross-site scripting (XSS) issue Odoo Community 15.0 and earlier and
| Odoo Enterprise 15.0 and earlier, allows remote attackers to inject
| arbitrary web script in the browser of a victim, via a crafted link.


CVE-2021-44476[7]:
| A sandboxing issue in Odoo Community 15.0 and earlier and Odoo
| Enterprise 15.0 and earlier allows authenticated administrators to
| read local files on the server, including sensitive configuration
| files.


CVE-2021-44775[8]:
| Cross-site scripting (XSS) issue in Website app of Odoo Community 15.0
| and earlier and Odoo Enterprise 15.0 and earlier, allows remote
| attackers to inject arbitrary web script in the browser of a victim,
| by posting crafted contents.


CVE-2021-45071[9]:
| Cross-site scripting (XSS) issue Odoo Community 15.0 and earlier and
| Odoo Enterprise 15.0 and earlier, allows remote attackers to inject
| arbitrary web script in the browser of a victim, via crafted uploaded
| file names.


CVE-2021-45111[10]:
| Improper access control in Odoo Community 15.0 and earlier and Odoo
| Enterprise 15.0 and earlier allows remote authenticated users to
| trigger the creation of demonstration data, including user accounts
| with known credentials.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-23166
https://www.cve.org/CVERecord?id=CVE-2021-23166
[1] https://security-tracker.debian.org/tracker/CVE-2021-23176
https://www.cve.org/CVERecord?id=CVE-2021-23176
[2] https://security-tracker.debian.org/tracker/CVE-2021-23178
https://www.cve.org/CVERecord?id=CVE-2021-23178
[3] https://security-tracker.debian.org/tracker/CVE-2021-23186
https://www.cve.org/CVERecord?id=CVE-2021-23186
[4] https://security-tracker.debian.org/tracker/CVE-2021-23203
https://www.cve.org/CVERecord?id=CVE-2021-23203
[5] https://security-tracker.debian.org/tracker/CVE-2021-26263
https://www.cve.org/CVERecord?id=CVE-2021-26263
[6] https://security-tracker.debian.org/tracker/CVE-2021-26947
https://www.cve.org/CVERecord?id=CVE-2021-26947
[7] https://security-tracker.debian.org/tracker/CVE-2021-44476
https://www.cve.org/CVERecord?id=CVE-2021-44476
[8] https://security-tracker.debian.org/tracker/CVE-2021-44775
https://www.cve.org/CVERecord?id=CVE-2021-44775
[9] https://security-tracker.debian.org/tracker/CVE-2021-45071
https://www.cve.org/CVERecord?id=CVE-2021-45071
[10] https://security-tracker.debian.org/tracker/CVE-2021-45111
https://www.cve.org/CVERecord?id=CVE-2021-45111

Please adjust the affected versions in the BTS as needed.

Bug#1035952: apache-jena: CVE-2023-22665

[Moritz Mühlenhoff]

Source: apache-jena
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for apache-jena.

CVE-2023-22665[0]:
| There is insufficient checking of user queries in Apache Jena versions
| 4.7.0 and earlier, when invoking custom scripts. It allows a remote
| user to execute arbitrary javascript via a SPARQL query.

https://lists.apache.org/thread/s0dmpsxcwqs57l4qfs415klkgmhdxq7s

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-22665
https://www.cve.org/CVERecord?id=CVE-2023-22665

Please adjust the affected versions in the BTS as needed.

Bug#1035674: pre-approval: unblock: puppetserver/7.9.5-2

[Jérôme Charaoui]

Le 2023-05-11 à 04 h 23, Paul Gevers a écrit :

Control: tags -1 confirmed moreinfo

Hi Jérôme,

On 07-05-2023 17:47, Jérôme Charaoui wrote:
I would like to request an unblock to upload puppetserver/7.9.5-2 
which fixes two bugs using targeted fixes.


- #1032241  puppetserver - service unit fails to realize the main 
process died

- #1035541 puppetserver: CVE-2023-1894


Please go ahead.


Uploaded to unstable. Thanks!

-- Jérôme

Bug#1035950: dav1d: CVE-2023-32570

[Moritz Mühlenhoff]

Source: dav1d
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for dav1d.

CVE-2023-32570[0]:
| VideoLAN dav1d before 1.2.0 has a thread_task.c race condition that
| can lead to an application crash, related to dav1d_decode_frame_exit.

https://code.videolan.org/videolan/dav1d/-/commit/cf617fdae0b9bfabd27282854c8e81450d955efa
 (1.2.0)

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-32570
https://www.cve.org/CVERecord?id=CVE-2023-32570

Please adjust the affected versions in the BTS as needed.

Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system

[Oliver Reiche]

Dear Hilmer,

If you look at that page you see a few points, which needs to be
> addressed. Please fix at least the lintian errors and warnings.
>
> The initial upload should not go to testing, either use unstable or
> experimental.
>

I updated the package to fix the lintian issues and moved it to unstable.

Many thanks for your help and quick response.

Kind regards,
Oliver

>

Bug#1035872: tuxmath-data: broken symlink: /usr/share/tuxmath/fonts/AndikaDesRevG.ttf -> ../../fonts/truetype/andika/Andika-R.ttf

[Andreas Beckmann]

On 11/05/2023 15.53, Holger Levsen wrote:

why are those suddenly serious?


My guess is that fonts-sil-andika renamed that file, thus breaking some 
users of the font. Otherwise they should have shown up in the past


There is a depends on the font and a symlink (that no longer works), I 
have no idea how bad this is. It's in the "code" part, not in the "docs" 
part of the package.



Andreas

PS: as usual, I have no idea what the package is good for :-)

Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed

[Andreas Beckmann]

Source: mariadb
Version: 1:10.11.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + zoph

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'bullseye'.
It installed fine in 'bullseye', then the upgrade to 'bookworm' fails.

This failure is observable while testing the zoph package.
Since timing is unfortunate and upgrading zoph causes db accesses while
the db is temporarily down, I tried to first upgrade
default-mysql-server (as I usually do in this case) by running
  apt-get install default-mysql-server
immediately after switching sources.list to bookworm (and running
apt-get update to refresh the lists.)

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

  Upgrading early: default-mysql-server
...
  Starting 2 pkgProblemResolver with broken count: 0
  Done
  The following packages were automatically installed and are no longer 
required:
libaio1 libsnappy1v5
  Use 'sudo apt autoremove' to remove them.
  The following additional packages will be installed:
gcc-12-base libc-bin libc6 libdaxctl1 libkmod2 libndctl6 libpmem1 libssl3
libstdc++6 liburing2 libzstd1 mariadb-client mariadb-client-core
mariadb-common mariadb-server mariadb-server-core
  Suggested packages:
glibc-doc libc-l10n locales libnss-nis libnss-nisplus mailx mariadb-test
netcat-openbsd
  Recommended packages:
manpages libdbd-mariadb-perl | libdbd-mysql-perl libterm-readkey-perl
libhtml-template-perl mariadb-plugin-provider-bzip2
mariadb-plugin-provider-lz4 mariadb-plugin-provider-lzma
mariadb-plugin-provider-lzo mariadb-plugin-provider-snappy pv
  The following packages will be REMOVED:
mariadb-client-10.5 mariadb-client-core-10.5 mariadb-server-10.5
mariadb-server-core-10.5
  The following NEW packages will be installed:
gcc-12-base libdaxctl1 libkmod2 libndctl6 libpmem1 libssl3 liburing2
mariadb-client mariadb-client-core mariadb-server mariadb-server-core
  The following packages will be upgraded:
default-mysql-server libc-bin libc6 libstdc++6 libzstd1 mariadb-common
  6 upgraded, 11 newly installed, 4 to remove and 189 not upgraded.
  Need to get 21.1 MB of archives.
...
  Preparing to unpack .../libc6_2.36-9_amd64.deb ...
  Unpacking libc6:amd64 (2.36-9) over (2.31-13+deb11u6) ...
  Setting up libc6:amd64 (2.36-9) ...
  Preparing to unpack .../libc-bin_2.36-9_amd64.deb ...
  Unpacking libc-bin (2.36-9) over (2.31-13+deb11u6) ...
  Setting up libc-bin (2.36-9) ...
  Preparing to unpack .../mariadb-common_1%3a10.11.2-1_all.deb ...
  Unpacking mariadb-common (1:10.11.2-1) over (1:10.5.19-0+deb11u2) ...
  Preparing to unpack .../default-mysql-server_1.1.0_all.deb ...
  Unpacking default-mysql-server (1.1.0) over (1.0.7) ...
  dpkg: mariadb-client-10.5: dependency problems, but removing anyway as you 
requested:
   mariadb-server-10.5 depends on mariadb-client-10.5 (>= 1:10.5.19-0+deb11u2).
   dbconfig-mysql depends on default-mysql-client | virtual-mysql-client; 
however:
Package default-mysql-client is not installed.
Package virtual-mysql-client is not installed.
Package mariadb-client-10.5 which provides virtual-mysql-client is to be 
removed.

  Removing mariadb-client-10.5 (1:10.5.19-0+deb11u2) ...
  Removing mariadb-client-core-10.5 (1:10.5.19-0+deb11u2) ...
  dpkg: mariadb-server-10.5: dependency problems, but removing anyway as you 
requested:
   zoph depends on default-mysql-server | virtual-mysql-server; however:
Package default-mysql-server is not configured yet.
Package virtual-mysql-server is not installed.
Package mariadb-server-10.5 which provides virtual-mysql-server is to be 
removed.

  Removing mariadb-server-10.5 (1:10.5.19-0+deb11u2) ...
  invoke-rc.d: could not determine current runlevel
  Stopping MariaDB database server: mariadbd [ESC][31mfailed![ESC][39;49m
  invoke-rc.d: initscript mariadb, action "stop" failed.
  dpkg: error processing package mariadb-server-10.5 (--remove):
   installed mariadb-server-10.5 package pre-removal script subprocess returned 
error exit status 1
  dpkg: too many errors, stopping
  Errors were encountered while processing:
   mariadb-server-10.5
  Processing was halted because there were too many errors.
  E: Sub-process /usr/bin/dpkg returned an error code (1)


Here apt choses a suboptimal removal order: mariadb-server-10.5 gets
removed (and therefore stopped, but that fails) only after
mariadb-client-10.5 and mariadb-client-core-10.5 are already gone.

I have tried the early upgrade scenario only with one other package that
needs it (icinga2-ido-mysql), and there it worked flawless.
Some bits from the log:

...
  Preparing to unpack .../mariadb-common_1%3a10.11.2-1_all.deb ...
  Unpacking mariadb-common (1:10.11.2-1) over (1:10.5.19-0+deb11u2) ...
  Preparing to unpack .../default-mysql-server_1.1.0_all.deb ...
  Unpacking default-mysql-server (1.1.0) over (1.0.7) ...
  Removing mariadb-server-10.5 (1:10.5.19-0+deb11u2) ...
  

Bug#1010469: [pkg-lxc-devel] Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Julian Gilbey]

On Mon, Feb 06, 2023 at 11:56:51PM +0100, Pierre-Elliott Bécue wrote:
> 
> Julian Gilbey  wrote on 08/08/2022 at 15:47:08+0100:
> 
> > On Mon, Aug 01, 2022 at 10:44:16PM +0200, Pierre-Elliott Bécue wrote:
> >> Julian Gilbey  wrote on 08/06/2022 at 10:50:18+0200:
> 
> Hrmpf, this one slipped out of my todolist, I'm sorry for this, this is
> bad.
> 
> When you indeed reinstalled your system, which version of Debian did you
> install?
> 
> Did you do anything specific before things turned bad again?

Hi Pierre-Elliott,

I was using debian testing (whatever state it was in at the time).

I've just tried reinstalling lxc from scratch with the current debian
testing.  I haven't been able to get as far as reproducing this error,
as I've hit a different snag:

# lxc-create -n debian-sid -t download -- -d debian -r sid -a amd64
# lxc-start -n debian-sid --logfile /tmp/lxc.log --logpriority DEBUG
lxc-start: debian-sid: ../src/lxc/lxccontainer.c: wait_on_daemonized_start: 878 
Received container state "ABORTING" instead of "RUNNING"
lxc-start: debian-sid: ../src/lxc/tools/lxc_start.c: main: 306 The container 
failed to start
lxc-start: debian-sid: ../src/lxc/tools/lxc_start.c: main: 309 To get more 
details, run the container in foreground mode
lxc-start: debian-sid: ../src/lxc/tools/lxc_start.c: main: 311 Additional 
information can be obtained by setting the --logfile and --logpriority options

The resulting log file contains the cryptic error messages:

lxc-start debian-sid 20230511122856.360 ERRORnetwork - 
../src/lxc/network.c:netdev_configure_server_veth:711 - No such file or 
directory - Failed to attach "vethQ4rt4x" to bridge "lxcbr0", bridge interface 
doesn't exist

That's super-weird; I have no idea what "vethQ4rt4x" is meant to mean.
I think this should probably be a separate bug report, though.
Despite some web searching, I have no idea how to fix this problem,
but I now can't use lxc at all :( I think it's something about lxc-net
not connecting the bridging device to the correct network device
(which in my case is enp5s0).

Best wishes,

   Julian

Bug#1035948: veyon-service: fullscreen demo mode and fullscreen switching for lock widget don't work

[Raphael Dannecker]

Package: veyon-service
Version: 4.7.5+repack1-1
Severity: normal
X-Debbugs-Cc: rdannec...@gmx.de

Dear Maintainer,

- Demo-Mode with Linux-to-Linux don't work¬
- Screen-Locking don't work.¬
¬
in Upstream Version 4.8.0 this bug seems to be fixed¬
See: https://github.com/veyon/veyon/releases¬

Please update package to 4.8.0


-- 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-8-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 veyon-service depends on:
ii  adduser 3.132
ii  libc6   2.36-9
ii  libpam0g1.5.2-6
ii  libqca-qt5-22.3.5-2
ii  libqt5core5a5.15.8+dfsg-7
ii  libqt5gui5  5.15.8+dfsg-7
ii  libqt5network5  5.15.8+dfsg-7
ii  libqt5widgets5  5.15.8+dfsg-7
ii  libssl3 3.0.8-1
ii  libstdc++6  12.2.0-14
ii  libveyon-core   4.7.5+repack1-1
ii  x11vnc  0.9.16-9

veyon-service recommends no packages.

Versions of packages veyon-service suggests:
ii  veyon-configurator  4.7.5+repack1-1

-- no debconf information

Bug#1035947: fresh build from git fails with cannot access local variable 'new_file'

[Antoine Beaupre]

Source: firefox
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

I'm trying to build Firefox 113 from the git repository. I have pulled
the package with:

debcheckout firefox

Then tried to download the latest tarballs with:

uscan --download-current

This crashes with a Python exception:

anarcat@angela:firefox$ uscan --download-current
Newest version of firefox on remote site is 113.0, specified download version 
is 113.0
uscan warn: Possible OpenPGP signature found at:
   
https://archive.mozilla.org/pub/firefox/releases/113.0/source/firefox-113.0.source.tar.xz.asc
 * Add opts=pgpsigurlmangle=s/$/.asc/ or opts=pgpmode=auto to debian/watch
 * Add debian/upstream/signing-key.asc.
 See uscan(1) for more details
Successfully symlinked ../firefox-113.0.source.tar.xz to 
../firefox_113.0.orig.tar.xz.
Traceback (most recent call last):
  File "/home/anarcat/dist/firefox/debian/repack.py", line 217, in 
main()
  File "/home/anarcat/dist/firefox/debian/repack.py", line 205, in main
if not new_file:
   
UnboundLocalError: cannot access local variable 'new_file' where it is not 
associated with a value
uscan: error: python3 debian/repack.py --upstream-version 113.0 
../firefox_113.0.orig.tar.xz subprocess returned exit status 1
anarcat@angela:firefox[1]$ 

I believe the following patch fixes the issue somehow:

diff --git i/debian/repack.py w/debian/repack.py
index 00d20928f6e..4f04ea200fb 100755
--- i/debian/repack.py
+++ w/debian/repack.py
@@ -199,6 +199,8 @@ def main():
 
 if options.new_file:
 new_file = options.new_file
+else:
+new_file = None
 
 if os.path.islink(args[0]):
 orig = os.path.realpath(args[0])

a.

-- Package-specific info:


-- Addons package information

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

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

-- no debconf information

Bug#1034566: unblock: isc-dhcp/4.4.3-P1-1.1

[Santiago R.R.]

El 07/05/23 a las 10:53, Paul Gevers escribió:
> Hi,
> 
> On 18-04-2023 14:11, Santiago R.R. wrote:
> > unblock isc-dhcp/4.4.3-P1-1.1
> 
> done and aged. Thanks.

Thanks to you!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1035872: tuxmath-data: broken symlink: /usr/share/tuxmath/fonts/AndikaDesRevG.ttf -> ../../fonts/truetype/andika/Andika-R.ttf

[Holger Levsen]

control: tags -1 + moreinfo
control: severity -1 important
thanks

Hi Andreas,

as usual: thanks for this bug report and all the other piuparts bug reports you
are filing! \o/

On Wed, May 10, 2023 at 02:03:17PM +0200, Andreas Beckmann wrote:
> Package: tuxmath-data
> Severity: serious
 
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.

why are those suddenly serious?
 
> 0m19.3s ERROR: FAIL: Broken symlinks:
>   /usr/share/tuxmath/fonts/AndikaDesRevG.ttf -> 
> ../../fonts/truetype/andika/Andika-R.ttf (tuxmath-data)
> 
> /usr/share/fonts/truetype/andika/Andika-Regular.ttf might be an
> alternative target. (May need a versioned fonts-sil-andika dependency.) 

from debian/control:

Package: tuxmath-data
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends},
 fonts-sil-andika


-- 
cheers,
Holger

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

"Climate change" is an euphenism. "Global warming" as well.


signature.asc
Description: PGP signature

Bug#1035913: fixed in doc-debian 11.2

[Joost van Baal-Ilić]

Hi again,

On Thu, May 11, 2023 at 01:55:48PM +0200, Joost van Baal-Ilić wrote:
> On Thu, May 11, 2023 at 12:38:17PM +0200, Johannes Schauer Marin Rodrigues 
> wrote:
> > On Thu, 11 May 2023 09:49:47 + Debian FTP Masters 
> >  wrote:
> > > Changes:
> > >  doc-debian (11.2) experimental; urgency=high
> > >  .
> > >* This release is targeted for Debian 12 bookworm: changes with what is
> > >  in testing now are minimal and suitable for an upload late in the
> > >  release cycle.
> > >* debian/TODO: added
> > >* Revert changes which are too intrusive for an upload during freeze.
> > >  (Closes: #1035913) Thanks Johannes Schauer Marin Rodrigues: "changed
> > >  /usr/share/doc-base/ paths".
> > 
> > I do not understand that last changelog entry. Reverting "changes which are 
> > too
> > intrusive for an upload during freeze" sounds like you are going back to 
> > this:
> > 
> > /usr/share/doc-base/debian-constitution-text
> > /usr/share/doc-base/debian-mailing-lists
> > /usr/share/doc-base/debian-manifesto
> > /usr/share/doc-base/debian-reporting-bugs
> > /usr/share/doc-base/debian-social-contract
> > 
> > But the package in experimental is shipping this:
> > 
> > $ curl --silent 
> > https://incoming.debian.org/debian-buildd/pool/main/d/doc-debian/doc-debian_11.2_all.deb
> >  | dpkg-deb -c - | grep doc-base
> > drwxr-xr-x root/root 0 2023-05-11 09:08 ./usr/share/doc-base/
> > -rw-r--r-- root/root   578 2020-12-31 08:50 
> > ./usr/share/doc-base/doc-debian.debian-constitution-text
> > -rw-r--r-- root/root   238 2020-12-31 08:50 
> > ./usr/share/doc-base/doc-debian.debian-mailing-lists
> > -rw-r--r-- root/root   502 2020-12-31 08:50 
> > ./usr/share/doc-base/doc-debian.debian-manifesto
> > -rw-r--r-- root/root   278 2020-12-31 08:50 
> > ./usr/share/doc-base/doc-debian.debian-reporting-bugs
> > -rw-r--r-- root/root   550 2020-12-31 08:50 
> > ./usr/share/doc-base/doc-debian.debian-social-contract
> > 
> > So the paths actually did *not* get reverted to how they were before 11.0?
> 
> Thanks for this.  Apparently the buildengine used gives different results than
> the one I used locally to check before uploading.  This bug should get
> reopened.  I'll investigate.

ok this is not trivial.  even in a sid chroot it installs
usr/share/doc-base/doc-debian.debian-constitution-text , and does not install
usr/share/doc-base/debian-constitution-text .  changing dh compat level to the
current one does not fix it.  dh_installdocs(1) does not help me.  i'll
investigate more...

Thanks again, Bye,

Joost

Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system

[Hilmar Preuße]

On 5/11/23 15:11, Oliver Reiche wrote:

Hi,


The source builds the following binary packages:

   justbuild - Justbuild generic build system

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

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


If you look at that page you see a few points, which needs to be
addressed. Please fix at least the lintian errors and warnings.

The initial upload should not go to testing, either use unstable or
experimental.

H.
--
Testmail

Bug#1035941: linux-image-amd64: too much space needed to build

[Diederik de Haas]

Control: reassign -1 debian-kernel-handbook 1.0.21
Control: severity -1 wishlist
Control: retitle -1 debian-kernel-handbook: Paragraph 4.5.1.1. Disk space 
requirements needs an update (from 2018 numbers)?

On Thursday, 11 May 2023 14:33:40 CEST Claude Heiland-Allen wrote:
> I freed up more space, but even with 53GB available it ran out.
> 
>* What outcome did you expect instead?
> 
> The build process to use a reasonable amount of space,
> perhaps by cleaning up artifacts after each output deb
> before starting to build the next output deb.
> 
> Documentation of the required amount of disk space would be nice.

The kernel is a big package and if you don't restrict what's getting build via
f.e. build profiles then it will need a lot of space. Especially debug packages
can get rather large. But it could be that the numbers mentioned in the 
debian-kernel-handbook are a bit too optimistic.

"Building binary packages for a single kernel flavour requires up to 15 GB 
space"
could be technically correct, but unless you're 'deep' into Debian kernel
building, you likely won't spot the importance of the chosen words.
IOW: newbies likely assume they need 15GB of disk space, while that's only
true in specific circumstances (as described in 4.5.5).


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

Bug#1035944: mariadb: upgrade issue: mariadb-server-10.5 fails to restart after upgrading mariadb-common

[Andreas Beckmann]

On 11/05/2023 14.58, Otto Kekäläinen wrote:

Thanks for reporting!

Is this sporadic or does it reproduce every time?


Just reran it with the same result, so seems deterministic.

If you tell me what information to collect, I can easily enter the 
chroot and test things after the failure occurred.



We have this upgrade scenario in CI without issues, thus asking about
reproducibility.


Do you use mariadb-plugin-gssapi-server?


Andreas

Bug#1035946: RFS: justbuild/1.1.0-1 [ITP] -- Justbuild generic build system

[Oliver Reiche]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : justbuild
   Version  : 1.1.0-1
   Upstream contact : Oliver Reiche 
 * URL  : https://github.com/just-buildsystem/justbuild
 * License  : Apache-2.0
 * Vcs  : https://github.com/just-buildsystem/justbuild
   Section  : devel

The source builds the following binary packages:

  justbuild - Justbuild generic build system

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/j/justbuild/justbuild_1.1.0~beta1+1683736997-1.dsc

Please note that this is currently a preliminary package (version
1.1.0~beta1+1683736997-1) for initial sponsor review. We plan to release
the final upstream version 1.1.0 within the next days. Once a sponsor is
found, we will address any possible issues and prepare an updated
package ASAP.

Changes for the initial release:

 justbuild (1.1.0~beta1+1683736997-1) testing; urgency=medium
 .
   * Initial release. (Closes: #1035930)

Regards,
--
  Oliver Reiche

Bug#1035659: jami fails to start on a wayland session if qt6-wayland is not installed

[user]

Package: jami
Version: 20230206.0~ds2-1.1
Followup-For: Bug #1035659
X-Debbugs-Cc: nore...@spam4.me

Dear Maintainer,

> Since the bugreporter didn't mention which window manager is in play,
> this bugreport cannot sensibly be reassigned.

The failure was found using a "gnome-session --session=phosh".

Bug#1035944: mariadb: upgrade issue: mariadb-server-10.5 fails to restart after upgrading mariadb-common

[Otto Kekäläinen]

Thanks for reporting!

Is this sporadic or does it reproduce every time?

We have this upgrade scenario in CI without issues, thus asking about
reproducibility.

Bug#1034633: binutils: add the binutils-loongarch64 package to the control file

[zhangdandan]

Control: tags 1034633 patch

Hi binutils maintainers,

    Thanks for Helmut's reply. I have added patch for the generator.

在 2023/5/8 下午3:57, Helmut Grohne 写道:

Control: tags -1 - patch

On Thu, Apr 20, 2023 at 06:06:20PM +0800, zhangdandan wrote:

Refer to the method provided by debian/README.cross file [2].
-Terminal Command:
binutils/binutils-2.40# debian/rules stamps/control TARGET=loong64
-Terminal Output:
sed -n -e 's/@dpkg_dev@/dpkg-dev (>= 1.19.0.5),/;/^Package:
binutils-for-build$/q;p' \
     < debian/control.in > debian/control
sed -e "s/@target@/loongarch64-linux-gnu/g" \
     -e "s/@host_archs@/any/" \
     -e 's/@binutils_alt_triplet@//' \
     < debian/control.cross.in >> debian/control
touch stamps/control

This applies for building dedicated cross binutils and not to cross
build native binutils. The patch is wrong. debian/control is generated.

- Binutils-add-loongarch64-support.patch
Adding patch to the generator.

- Generated-control ( Optionally )
The debian/control is generated. when applying the patch ( 
Binutils-add-loongarch64-support.patch ).

The file Generated-control is for reference only.

- Diff-original-and-generated-control ( Optionally )
Compare the original debian/control with the generated debian/control.
The file Diff-original-and-generated-control is for reference only.

Your opinions are welcome.


thanks,
Dandan Zhang
>From 05561bf0e918d66eac808b4ff52ed3e70409ef97 Mon Sep 17 00:00:00 2001
From: Dandan Zhang 
Date: Thu, 11 May 2023 19:24:21 +0800
Subject: [PATCH] Add loongarch64 support

---
 debian/rules | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 2e1eac2c..5f5a8b27 100755
--- a/debian/rules
+++ b/debian/rules
@@ -118,7 +118,7 @@ install_script = install -m 755
 install_binary = install -m 755 -s --strip-program="$(STRIP)"
 
 NATIVE_ARCHS ?= amd64 i386 arm64 armhf armel ppc64el s390x
-NATIVE_ARCHS += alpha arc hppa ia64 m68k powerpc ppc64 \
+NATIVE_ARCHS += alpha arc hppa ia64 loong64 m68k powerpc ppc64 \
 	riscv64 sh4 sparc64 x32
 NATIVE_ARCHS += hurd-i386 kfreebsd-amd64 kfreebsd-i386
 #NATIVE_ARCHS += nios2 or1k s390 sparc
@@ -139,7 +139,7 @@ ifeq ($(DEB_SOURCE),binutils)
 # DEB_HOST_ARCH is filtered-out later anyway, do not test here.
 CROSS_ARCHS ?= amd64 i386 x32 \
s390x ppc64el arm64 armhf armel \
-   alpha arc hppa m68k \
+   alpha arc hppa loong64 m68k \
powerpc ppc64 sh4 sparc64 \
ia64 riscv64 \
kfreebsd-amd64 kfreebsd-i386 hurd-i386
@@ -228,6 +228,8 @@ HOST_ARCHS_kfreebsd-amd64 = amd64 i386 x32
 HOST_ARCHS_kfreebsd-i386 = amd64 i386 x32
 HOST_ARCHS_hurd-i386 = amd64 i386 x32
 
+HOST_ARCHS_loong64 = amd64 i386 x32 arm64 ppc64el
+
 # Map a Debian architecture alias to a GNU type or a multiarch path component.
 run_dpkg_arch = $(or $(dpkg_arch_$1),$(eval \
   dpkg_arch_$1 := $(shell dpkg-architecture -f -a$1))$(dpkg_arch_$1))
@@ -740,6 +742,7 @@ multiarch_targets = \
 	hppa-linux-gnu \
 	i686-linux-gnu \
 	ia64-linux-gnu \
+	loongarch64-linux-gnu \
 	m32r-linux-gnu \
 	m68k-linux-gnu \
 	m68k-rtems \
-- 
2.39.1

diff --git a/debian/control b/debian/control
index e5ab9d8e..81ce117a 100644
--- a/debian/control
+++ b/debian/control
@@ -537,6 +537,32 @@ Depends: binutils-ia64-linux-gnu (= ${binary:Version})
 Description: GNU binary utilities, for ia64-linux-gnu target (debug symbols)
  This package provides debug symbols for binutils-ia64-linux-gnu.
 
+Package: binutils-loongarch64-linux-gnu
+Priority: optional
+Architecture: loong64 amd64 i386 x32 arm64 ppc64el
+Multi-Arch: allowed
+Depends: binutils-common (= ${binary:Version}),
+  ${shlibs:Depends}, ${extraDepends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Breaks: binutils (<< 2.29-6), binutils-dev (<< 2.38.50.20220609-2)
+Replaces: binutils (<< 2.29-6), binutils-dev (<< 2.38.50.20220609-2)
+Description: GNU binary utilities, for loongarch64-linux-gnu target
+ This package provides GNU assembler, linker and binary utilities
+ for the loongarch64-linux-gnu target.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for loongarch64-linux-gnu and loongarch64-linux-gnu is not your native 
platform.
+
+Package: binutils-loongarch64-linux-gnu-dbg
+Section: debug
+Priority: optional
+Architecture: loong64 amd64 i386 x32 arm64 ppc64el
+Multi-Arch: foreign
+Depends: binutils-loongarch64-linux-gnu (= ${binary:Version})
+Description: GNU binary utilities, for loongarch64-linux-gnu target (debug 
symbols)
+ This package provides debug symbols for binutils-loongarch64-linux-gnu.
+
 Package: binutils-m68k-linux-gnu
 Priority: optional
 Architecture: m68k amd64 i386 x32
Source: binutils
Section: devel
Priority: optional
Maintainer: Matthias Klose 
Uploaders: James Troup 
Standards-Version: 4.6.2
Build-Depends: autoconf (>= 2.64), dpkg-dev (>= 1.19.0.5),
  bison, flex, gettext, texinfo, dejagnu, 

Bug#1035945: unblock: cyrus-sasl2/2.1.28+dfsg-11

[Bastian Germann]

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

Please unblock package cyrus-sasl2.

[ Reason ]
Missing systemd service: #981438. There are some other minor changes because
originally this was supposed to get in bookworm before the full freeze.
I am not very keen to get this into bookworm but this was long requested and
it would be nice to have it available in bookworm.

[ Impact ]
The systemd generated sysv compatibility service has to be used.

[ Tests ]
Use systemctl to run sasl2-bin's service.

[ Risks ]
postfix had a chroot-based configuration in its autopkgtest that had
problems with the service change: #1032306. Users might have similar
configurations which would stop working with a bookworm update.
The change is in unstable for over 70 days by now and there were no
bug reports about it.

[ 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 ]
cyrus-sasl2 is a key package because of libsasl2-2.
That binary package is not touched by the changes.

unblock cyrus-sasl2/2.1.28+dfsg-11diff -Nru cyrus-sasl2-2.1.28+dfsg/debian/changelog 
cyrus-sasl2-2.1.28+dfsg/debian/changelog
--- cyrus-sasl2-2.1.28+dfsg/debian/changelog2022-11-22 17:48:33.0 
+0100
+++ cyrus-sasl2-2.1.28+dfsg/debian/changelog2023-03-01 00:52:04.0 
+0100
@@ -1,3 +1,19 @@
+cyrus-sasl2 (2.1.28+dfsg-11) unstable; urgency=medium
+
+  [ Debian Janitor ]
+  * Apply multi-arch hints. + cyrus-sasl2-doc: Add Multi-Arch: foreign.
+
+  [ Bastian Germann ]
+  * Add Romanian translation (Closes: #1031499)
+  * Fix lintian depends-on-obsolete-package (lsb-base)
+  * Add saslauthd.service (Closes: #981438)
+  * Remove dh_installinit params
+  * Install saslauthd.service similar to saslauthd.init
+  * Drop old NEWS
+  * Fix systemd-service-file-missing-documentation-key
+
+ -- Bastian Germann   Wed, 01 Mar 2023 00:52:04 +0100
+
 cyrus-sasl2 (2.1.28+dfsg-10) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru cyrus-sasl2-2.1.28+dfsg/debian/control 
cyrus-sasl2-2.1.28+dfsg/debian/control
--- cyrus-sasl2-2.1.28+dfsg/debian/control  2022-11-22 17:48:33.0 
+0100
+++ cyrus-sasl2-2.1.28+dfsg/debian/control  2023-02-28 19:06:06.0 
+0100
@@ -36,7 +36,6 @@
 Pre-Depends: ${misc:Pre-Depends}
 Depends: db-util,
  libsasl2-2 (>= ${binary:Version}),
- lsb-base,
  ${misc:Depends},
  ${perl:Depends},
  ${shlibs:Depends}
@@ -52,6 +51,7 @@
 Architecture: all
 Depends: ${misc:Depends},
  sphinx-rtd-theme-common
+Multi-Arch: foreign
 Description: Cyrus SASL - documentation
  This is the Cyrus SASL API implementation, version 2.1. See package
  libsasl2-2 and RFC  for more information.
diff -Nru cyrus-sasl2-2.1.28+dfsg/debian/libsasl2-2.README.Debian 
cyrus-sasl2-2.1.28+dfsg/debian/libsasl2-2.README.Debian
--- cyrus-sasl2-2.1.28+dfsg/debian/libsasl2-2.README.Debian 2022-11-22 
17:48:33.0 +0100
+++ cyrus-sasl2-2.1.28+dfsg/debian/libsasl2-2.README.Debian 2023-02-28 
19:39:25.0 +0100
@@ -43,7 +43,7 @@
 
 Use dpkg-statoverride to change the permission and the ownership of the
 saslauthd socket /var/run/saslauthd and the sasldb user database /etc/sasldb2.
-For more information on saslauthd, see the README.Debian in the sasl2-bin
+For more information on saslauthd, see README.Debian.gz in the sasl2-bin
 package.
 
 Also see the following RFC
diff -Nru cyrus-sasl2-2.1.28+dfsg/debian/NEWS 
cyrus-sasl2-2.1.28+dfsg/debian/NEWS
--- cyrus-sasl2-2.1.28+dfsg/debian/NEWS 2022-11-22 17:48:33.0 +0100
+++ cyrus-sasl2-2.1.28+dfsg/debian/NEWS 1970-01-01 01:00:00.0 +0100
@@ -1,19 +0,0 @@
-cyrus-sasl2 (2.1.25.dfsg1-5) unstable; urgency=low
-
-As of version 2.1.25.dfsg1-5, configuration of SQL engine backends have
-changed from database specific configuration (e.g. 'mysql') to generic
-'sql' auxprop plugin.
-
-You will need to change your configuration f.e. from:
-
-auxprop_plugin: mysql
-
-to
-
-auxprop_plugin: sql
-sql_engine: mysql
-
-Also the SQL query (if used) needs to have '%u' replaced with '%u@%r'
-because now user and realm is provided separately.
-
- -- Ondřej Surý   Mon, 06 Aug 2012 13:12:22 +0200
diff -Nru cyrus-sasl2-2.1.28+dfsg/debian/po/ro.po 
cyrus-sasl2-2.1.28+dfsg/debian/po/ro.po
--- cyrus-sasl2-2.1.28+dfsg/debian/po/ro.po 1970-01-01 01:00:00.0 
+0100
+++ cyrus-sasl2-2.1.28+dfsg/debian/po/ro.po 2023-02-28 19:06:06.0 
+0100
@@ -0,0 +1,162 @@
+# Mesajele în limba română pentru pachetul cyrus-sasl2.
+# Romanian translation of cyrus-sasl2.
+# Copyright © 2023 THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the cyrus-sasl2 package.
+#
+# Remus-Gabriel Chelu , 2023.

Bug#1035944: mariadb: upgrade issue: mariadb-server-10.5 fails to restart after upgrading mariadb-common

[Andreas Beckmann]

Source: mariadb
Version: 1:10.11.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + mariadb-plugin-gssapi-server

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'bullseye'.
It installed fine in 'bullseye', then the upgrade to 'bookworm' fails.

This test was planned to do a 2-stage upgrade:
  apt-get upgrade && apt-get distupgrade
(the first part does not install any new packages, that will happen in
the second part) but the first part already failed.

I try to summarize what seems to happen:

* In a bullseye chroot (which alles starting services) install
  mariadb-plugin-gssapi-server
* switch sources.list to bookworm, run 'apt-get update'
* run 'apt-get upgrade'
  - this only upgrades mysql-common and mariadb-common
  - this triggers a mariadb-server-10.5 restart which fails

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

...
  Preparing to unpack .../24-mysql-common_5.8+1.1.0_all.deb ...
  Unpacking mysql-common (5.8+1.1.0) over (5.8+1.0.7) ...
  Preparing to unpack .../25-mariadb-common_1%3a10.11.2-1_all.deb ...
  Unpacking mariadb-common (1:10.11.2-1) over (1:10.5.19-0+deb11u2) ...
...
  Setting up mysql-common (5.8+1.1.0) ...
...
  Setting up mariadb-common (1:10.11.2-1) ...
...
  Processing triggers for mariadb-server-10.5 (1:10.5.19-0+deb11u2) ...
  invoke-rc.d: could not determine current runlevel
  Stopping MariaDB database server: mariadbd.
  Starting MariaDB database server: mariadbd . . . . . . . . . . . . . . . . . 
. . . . . . . . . . . . . [ESC][31mfailed![ESC][0m
  invoke-rc.d: initscript mariadb, action "restart" failed.
  dpkg: error processing package mariadb-server-10.5 (--configure):
   installed mariadb-server-10.5 package post-installation script subprocess 
returned error exit status 1
  Processing triggers for debianutils (5.7-0.4) ...
  Processing triggers for libc-bin (2.36-9) ...
  Errors were encountered while processing:
   mariadb-server-10.5


This might indicate that mariadb-common needs a Breaks: mariadb-server-10.5

I cannot reproduce this by testing default-mariadb-server in
the same way, so mariadb-plugin-gssapi-server seems to be needed to
trigger that bug.


cheers,

Andreas


mariadb-plugin-gssapi-server_1:10.11.2-1.log.gz
Description: application/gzip

Bug#1035943: ITP: fonts-tt2020 -- typewriter font

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: fonts-tt2020
  Version : 0.2.1+ds
  Upstream Authors: Fredrick R. Brennan 
  URL : https://github.com/ctrlcctrlv/TT2020
* License : OFL-1.1
  Description : typewriter font
 This is an advanced, open source, hyperrealistic, multilingual 
typewriter font

 for a new decade.

Bug#1035942: unblock: libretro-bsnes-mercury/094+git20220807-8

[Jonathan McDowell]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libretro-bsnes-merc...@packages.debian.org
Control: affects -1 + src:libretro-bsnes-mercury

Please consider unblocking libretro-bsnes-mercury. The upload fixes the
incorrect location of the buttonmap.xml file for the Kodi libretro
plugins, without which it is not possible to use game controllers with
the emulator.

[ Tests ]

Manually confirmed generated kodi-game-* debs have buttonmap.xml in
resources/ subdirectory, confirmed correct operation of game controller
with package.

[ Risks ]

This is a trivial fix that just corrects the location of the button map
for the Kodi plugins.

[ 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 libretro-bsnes-mercury/094+git20220807-8

git show --stat:

commit 8fa1fad276c3ede227c0c70037a486e2ef23fa96 (HEAD -> master, tag: 
debian/094+git20220807-8)
Author: Jonathan McDowell 
Date:   Thu May 11 10:48:30 2023 +

Fix Kodi plugins buttonmap.xml location (Closes: #1034583)

The buttonmap.xml file needs to live in the resources subdirectory, not
the parent plugin directory.

 debian/changelog   
| 7 +++
 debian/kodi-game/game.libretro.bsnes-mercury-accuracy/{ => 
resources}/buttonmap.xml| 0
 debian/kodi-game/game.libretro.bsnes-mercury-balanced/{ => 
resources}/buttonmap.xml| 0
 debian/kodi-game/game.libretro.bsnes-mercury-performance/{ => 
resources}/buttonmap.xml | 0
 4 files changed, 7 insertions(+)

J.

-- 
I'm not allowed to talk to you any more.
diff -Nru libretro-bsnes-mercury-094+git20220807/debian/changelog 
libretro-bsnes-mercury-094+git20220807/debian/changelog
--- libretro-bsnes-mercury-094+git20220807/debian/changelog 2023-04-19 
08:49:56.0 +
+++ libretro-bsnes-mercury-094+git20220807/debian/changelog 2023-05-11 
10:47:35.0 +
@@ -1,3 +1,10 @@
+libretro-bsnes-mercury (094+git20220807-8) unstable; urgency=medium
+
+  * Team upload
+  * Fix Kodi plugins buttonmap.xml location (Closes: #1034583)
+
+ -- Jonathan McDowell   Thu, 11 May 2023 10:47:35 +
+
 libretro-bsnes-mercury (094+git20220807-7) unstable; urgency=medium
 
   * Team upload
diff -Nru 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
--- 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
  2023-01-22 15:29:27.0 +
+++ 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/buttonmap.xml
  1970-01-01 00:00:00.0 +
@@ -1,17 +0,0 @@
-
-
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-
diff -Nru 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
--- 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
1970-01-01 00:00:00.0 +
+++ 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-accuracy/resources/buttonmap.xml
2023-05-11 10:47:35.0 +
@@ -0,0 +1,17 @@
+
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
diff -Nru 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
--- 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
  2023-01-22 15:29:27.0 +
+++ 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/buttonmap.xml
  1970-01-01 00:00:00.0 +
@@ -1,17 +0,0 @@
-
-
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-
diff -Nru 
libretro-bsnes-mercury-094+git20220807/debian/kodi-game/game.libretro.bsnes-mercury-balanced/resources/buttonmap.xml
 

Bug#1034424: buildd.debian.org: Please use predictible build paths

[Holger Levsen]

On Thu, May 11, 2023 at 07:11:17AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> I don't think it would be lying. It would be saying: "I'm trying to verify
> something that was built on a buildd by reproducing its environment."

exactly.
 
[...] 
> make[1]: Leaving directory '/build/0ad-0.0.26-3_i386'
> So maybe fixed build paths combined with disabled log filtering can actually
> improve the readability of log files?

I think so, indeed.

Thanks!


-- 
cheers,
Holger

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

Privacy is a Human Right. (Universal Declaration of Human Rights, article 12.)


signature.asc
Description: PGP signature

Bug#1035941: linux-image-amd64: too much space needed to build

[Claude Heiland-Allen]

Package: linux-image-amd64
Severity: normal
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I tried to build locally-patched kernel debs:

sudo apt build-dep linux-image-6.1.0-8-amd64-unsigned
apt source linux-image-6.1.0-8-amd64-unsigned
cd linux-6.1.25
# make changes to source code
debuild -i -us -uc -b

   * What was the outcome of this action?

I ran out of disk space.

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

I freed up more space, but even with 53GB available it ran out.

   * What outcome did you expect instead?

The build process to use a reasonable amount of space,
perhaps by cleaning up artifacts after each output deb
before starting to build the next output deb.

Documentation of the required amount of disk space would be nice.

Thanks for your work on this package,


Claude


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

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

Versions of packages linux-image-amd64 depends on:
pn  linux-image-6.1.0-8-amd64  

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.