date:20230512

On Wed, 10 May 2023 23:40:44 +0100 Luca Boccassi 
wrote:
> On Tue, 09 May 2023 00:31:20 +0100 Luca Boccassi 
> wrote:
> > On Mon, 08 May 2023 14:14:30 -0700 Russ Allbery 
> wrote:
> > > Guillem Jover  writes:
> > > > On Mon, 2023-05-08 at 08:48:49 -0700, Russ Allbery wrote:
> > > 
> > > >> […] I suspect Policy should say something stronger and more
> > general,
> > > >> namely that no package in Debian should divert a file from
> another
> > > >> package unless this is arranged cooperatively between the
> packages
> > to
> > > >> solve some specific (unusual) problem.
> > > 
> > > > ,--- §3.9 ---
> > > > You should not use "dpkg-divert" on a file belonging to another
> > > > package without consulting the maintainer of that package
first.
> > When
> > > > adding or removing diversions, package maintainer scripts must
> > provide
> > > > the "--package" flag to "dpkg-divert" and must not use "--
local".
> > > > `---
> > > 
> > > Oh, thank you!  I had completely forgotten that we said something
> > about
> > > this under maintainer scripts.
> > > 
> > > That doesn't entirely cover this case (because systemd and udev
may
> > not be
> > > "that package" in this sense), but it covers much of the general
> > case.
> > 
> > Would you like me to reword/move the new snippet?
> 
> Gentle ping. Any suggestion on how to reword/change the proposal?

With the only occurrence now removed, this policy change should now be
impactless: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035667

-- 
Kind regards,
Luca Boccassi


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

Bug#1036015: linux-image-6.3.0-0-amd64: Bluetooth mouse connect very delay after wake up from suspend

2023-05-12 Thread 肖盛文

Package: src:linux
Version: 6.3.1-1~exp1
Severity: normal
X-Debbugs-Cc: atzli...@sina.com

Dear Maintainer,
   * What led up to the situation?
When I close my notebook lid, the notebook will suspend to memory,then I open
the lid, the notebook will wake up from suspend, but my Bluetooth mouse can't
use immediately, must wait almost a minute before Bluetooth mouse connect.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
When I use Debian 11.6, the kernel is linux-image-5.10.0-21-rt-amd64,
there is not this bug.
After I upgrade to Debian 11.7, the kernel is linux-image-5.10.0-22-rt-amd64,
this bug take place.
I also test the kernel linux-image-6.1.0-0.deb11.6-amd64, it has this bug.

   * What outcome did you expect instead?
I hope my Bluetooth mouse can connect my notebook immediately.

-- Package-specific info:
** Version:
Linux version 6.3.0-0-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.3.1-1~exp1 (2023-05-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.3.0-0-amd64 
root=UUID=87418a96-d3eb-4767-8e25-620514307f9f ro quiet

** Not tainted

This time, it take 08:22:46 to 08:24:35, cost 109 seconds to connect.
There is one errro info:
[Sat May 13 08:24:29 2023] Bluetooth: hci0: ACL packet for unknown connection 
handle 3585

** Kernel log:
[Sat May 13 08:22:46 2023] CPU3 is up
[Sat May 13 08:22:46 2023] ACPI: PM: Waking up from system sleep state S3
[Sat May 13 08:22:46 2023] pcieport :00:1d.0: Intel SPT PCH root port ACS 
workaround enabled
[Sat May 13 08:22:46 2023] sd 1:0:0:0: [sda] Starting disk
[Sat May 13 08:22:46 2023] i915 :00:02.0: [drm] [ENCODER:94:DDI A/PHY A] is 
disabled/in DSI mode with an ungated DDI clock, gate it
[Sat May 13 08:22:46 2023] i915 :00:02.0: [drm] [ENCODER:102:DDI B/PHY B] 
is disabled/in DSI mode with an ungated DDI clock, gate it
[Sat May 13 08:22:46 2023] i915 :00:02.0: [drm] [ENCODER:117:DDI C/PHY C] 
is disabled/in DSI mode with an ungated DDI clock, gate it
[Sat May 13 08:22:46 2023] usb 1-3: reset full-speed USB device number 2 using 
xhci_hcd
[Sat May 13 08:22:46 2023] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 
300)
[Sat May 13 08:22:46 2023] ata1: SATA link down (SStatus 4 SControl 300)
[Sat May 13 08:22:46 2023] ata2.00: configured for UDMA/133
[Sat May 13 08:22:46 2023] ahci :00:17.0: port does not support device sleep
[Sat May 13 08:22:46 2023] usb 1-7: reset high-speed USB device number 3 using 
xhci_hcd
[Sat May 13 08:22:46 2023] OOM killer enabled.
[Sat May 13 08:22:46 2023] Restarting tasks ... 
[Sat May 13 08:22:46 2023] Bluetooth: hci0: Bootloader revision 0.0 build 2 
week 52 2014
[Sat May 13 08:22:46 2023] done.
[Sat May 13 08:22:46 2023] random: crng reseeded on system resumption
[Sat May 13 08:22:46 2023] Bluetooth: hci0: Device revision is 5
[Sat May 13 08:22:46 2023] Bluetooth: hci0: Secure boot is enabled
[Sat May 13 08:22:46 2023] Bluetooth: hci0: OTP lock is enabled
[Sat May 13 08:22:46 2023] Bluetooth: hci0: API lock is enabled
[Sat May 13 08:22:46 2023] Bluetooth: hci0: Debug lock is disabled
[Sat May 13 08:22:46 2023] Bluetooth: hci0: Minimum firmware build 1 week 10 
2014
[Sat May 13 08:22:46 2023] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-11-5.sfi
[Sat May 13 08:22:46 2023] Bluetooth: hci0: Found device firmware: 
intel/ibt-11-5.sfi
[Sat May 13 08:22:46 2023] PM: suspend exit
[Sat May 13 08:22:48 2023] Bluetooth: hci0: Waiting for firmware download to 
complete
[Sat May 13 08:22:48 2023] Bluetooth: hci0: Firmware loaded in 1500608 usecs
[Sat May 13 08:22:48 2023] Bluetooth: hci0: Waiting for device to boot
[Sat May 13 08:22:48 2023] Bluetooth: hci0: Device booted in 11679 usecs
[Sat May 13 08:22:48 2023] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-11-5.ddc
[Sat May 13 08:22:48 2023] Bluetooth: hci0: Found Intel DDC parameters: 
intel/ibt-11-5.ddc
[Sat May 13 08:22:48 2023] Bluetooth: hci0: Applying Intel DDC parameters 
completed
[Sat May 13 08:22:48 2023] Bluetooth: hci0: Firmware revision 0.0 build 14 week 
44 2021
[Sat May 13 08:22:48 2023] Bluetooth: MGMT ver 1.22
[Sat May 13 08:22:48 2023] Bluetooth: hci0: Bad flag given (0x1) vs supported 
(0x0)
[Sat May 13 08:22:52 2023] wlp1s0: authenticate with 44:f9:71:69:42:1e
[Sat May 13 08:22:52 2023] wlp1s0: 80 MHz not supported, disabling VHT
[Sat May 13 08:22:52 2023] wlp1s0: send auth to 44:f9:71:69:42:1e (try 1/3)
[Sat May 13 08:22:52 2023] wlp1s0: authenticated
[Sat May 13 08:22:52 2023] wlp1s0: associate with 44:f9:71:69:42:1e (try 1/3)
[Sat May 13 08:22:52 2023] wlp1s0: RX AssocResp from 44:f9:71:69:42:1e 
(capab=0x1411 status=0 aid=1)
[Sat May 13 08:22:52 2023] wlp1s0: associated
[Sat May 13 08:22:52 2023] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes 
ready
[Sat May 13 08:22:52 2023] wlp1s0: Limiting TX power to 35 (35 - 0) dBm as 
advertised by 44:f9:71:69:42:1e
[Sat May 13 08:24:05

Bug#1035645: closed by Debian FTP Masters (reply to Holger Levsen ) (Bug#1035645: fixed in reprotest 0.7.24)

2023-05-12 Thread stefanor

Control: reopen -1
Control: notfixed -1 reprotest/0.7.24

I'm afraid one more tweak is required to resolve the issue. The change I
made in dh-python to support tox 4 means you'll need to add a
Build-Depends on python3-wheel, to build the wheel that we give to tox
to test.

Stefano

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

Bug#1036014: unblock: amazon-ec2-utils/2.0.1-2

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

Dear Release Team,

As one of the owners of udev, and having an agreement with the
maintainer of amazon-ec2-utils, I'd like the following bug fixed in
Bookworm:

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

amazon-ec2-utils used to take over a file from udev, and this has been
fixed in the latest upload to unstable. For maintainability and
supportability reasons, we the systemd/udev maintainers prefer that
files from the udev package are not diverted. This is the only such
case distro-wide.

The change is very straightforward and restricted to the maintainer
scripts and the install file. Debdiff attached.

Thank you!

-- 
Kind regards,
Luca Boccassi
diff -Nru amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.install amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.install
--- amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.install	2022-12-23 22:15:25.0 +
+++ amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.install	2023-05-13 01:11:47.0 +0100
@@ -1,4 +1,4 @@
 ebsnvme-id /usr/sbin/
 ec2-metadata /usr/bin/
 ec2nvme-nsid /lib/udev/
-60-cdrom_id.rules 70-ec2-nvme-devices.rules /lib/udev/rules.d/
+70-ec2-nvme-devices.rules /lib/udev/rules.d/
diff -Nru amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postinst amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postinst
--- amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postinst	1970-01-01 01:00:00.0 +0100
+++ amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postinst	2023-05-13 01:11:47.0 +0100
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+set -e
+
+if [ "configure" = "$1" ]; then
+	# TODO: can be dropped in Trixie
+	diverter=$(dpkg-divert --listpackage /lib/udev/rules.d/60-cdrom_id.rules)
+	if [ "$diverter" = "amazon-ec2-utils" ]; then
+		dpkg-divert --package amazon-ec2-utils --remove --rename \
+			--divert /lib/udev/rules.d/60-cdrom_id.rules.disabled \
+			/lib/udev/rules.d/60-cdrom_id.rules
+	fi
+fi
+
+#DEBHELPER#
diff -Nru amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postrm amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postrm
--- amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postrm	2022-12-23 22:01:44.0 +
+++ amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.postrm	1970-01-01 01:00:00.0 +0100
@@ -1,11 +0,0 @@
-#!/bin/sh
-
-set -e
-
-if [ remove = "$1" -o abort-install = "$1" -o disappear = "$1" ]; then
-  dpkg-divert --package amazon-ec2-utils --remove --rename \
-  	   --divert /lib/udev/rules.d/60-cdrom_id.rules.disabled \
-	   /lib/udev/rules.d/60-cdrom_id.rules
-fi
-
-#DEBHELPER#
diff -Nru amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.preinst amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.preinst
--- amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.preinst	2022-12-23 22:01:44.0 +
+++ amazon-ec2-utils-2.0.1/debian/amazon-ec2-utils.preinst	1970-01-01 01:00:00.0 +0100
@@ -1,9 +0,0 @@
-#!/bin/sh
-
-set -e
-
-dpkg-divert --package amazon-ec2-utils --add --rename \
-	--divert /lib/udev/rules.d/60-cdrom_id.rules.disabled \
-	/lib/udev/rules.d/60-cdrom_id.rules
-
-#DEBHELPER#
diff -Nru amazon-ec2-utils-2.0.1/debian/changelog amazon-ec2-utils-2.0.1/debian/changelog
--- amazon-ec2-utils-2.0.1/debian/changelog	2022-12-23 22:17:54.0 +
+++ amazon-ec2-utils-2.0.1/debian/changelog	2023-05-13 01:11:47.0 +0100
@@ -1,3 +1,10 @@
+amazon-ec2-utils (2.0.1-2) unstable; urgency=medium
+
+  [ Luca Boccassi ]
+  * Remove diversion of udev rule 60-cdrom_id.rules (Closes: #1035667)
+
+ -- Noah Meyerhans   Fri, 12 May 2023 17:11:47 -0700
+
 amazon-ec2-utils (2.0.1-1) unstable; urgency=medium
 
   * New upstream release


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

Bug#1036013: intel-microcode: new upstream version

2023-05-12 Thread Christoph Anton Mitterer

Package: intel-microcode
Version: 3.20230214.1
Severity: normal
Tags: security
X-Debbugs-Cc: Debian Security Team 

Hey.

There's a new version 20230512 out which according to changelog
fixes an undisclosed security issues for numerous platforms.

Cheers,
Chris



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

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

Versions of packages intel-microcode depends on:
ii  iucode-tool  2.3.1-3

Versions of packages intel-microcode recommends:
ii  initramfs-tools  0.142

intel-microcode suggests no packages.

-- no debconf information

Bug#1036012: ITP: phosh-wallpapers -- Wallpapers for Phosh

2023-05-12 Thread Guido Günther

Package: wnpp
Severity: wishlist
Owner: Guido Günther 

* Package name: phosh-wallpapers
  Version : 0.27.0
  Upstream Contact: François Téchené 
* URL : https://gitlab.gnome.org/guidog/phosh-wallpapers
* License : cc-by-sa-4.0
  Programming Lang: none
  Description : Wallpapers for Phosh

 Wallpapers for Phosh intended for use on mobile phones as lockscreen
 background. For docked usage some typical desktop sizes are provided as well.
 .
 The wallpapers work on other mobile and desktop environments e.g. as desktop
 background too.

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

2023-05-12 Thread James Addison

On Fri, 12 May 2023 at 23:23, James Addison  wrote:
>
> On Fri, 12 May 2023 at 16:54, Thorsten Glaser  wrote:
> >
> > Yes, but given the usual ulimit, the new limit would be 4+ times
> > the old one, much much harder to reach.
>
> That does sound promising.
>
> I've followed up on this discussion with the relevant upstream NodeJS
> thread, and beyond there to the relevant V8 discussion group.  My
> sense from those, and given my own experience building NodeJS is that
> I don't feel an rlimit patch is straightforward or worthwhile -
> although it's possible that I didn't accurately understand or
> communicate the context.
>
> I'm going to stay involved with this thread, but I think that it is
> upon you to develop or provide further guidance towards a patch if
> it's something you'd like to have implemented, Thorsten.

Maybe my tone was unclear, but I'm not hugely keen to provide more
effort on this -- despite being interested -- because I feel like I've
been running errands to try to find a good path through, when in fact
I don't really understand the nature of the problem, nor am I likely
to benefit much from it.  But if improvement is possible, I'll do what
I can.

That said: perhaps it could be useful if someone could check whether
the following commit is relevant to this:
https://github.com/libuv/libuv/commit/18c7530a75d813801f819caae4dff47fc4a1d4a1

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

2023-05-12 Thread Brian May

Johannes Schauer Marin Rodrigues  writes:

> 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?

Can you please do this?

Thanks
-- 
Brian May @ Debian

Bug#1035976: [Aptitude-devel] Bug#1035976: aptitude dies with SEGV

2023-05-12 Thread Axel Beckert

Control: found -1 0.8.13-3
Control: tag -1 + moreinfo

Hi Harald,

Harald Dunkel wrote:
> Running aptitude without arguments in a ssh session to a remote
> host I see the "loading cache" message as usual, but then it dies
> with
> 
>   Ouch!  Got SIGSEGV, dying..
>   Segmentation fault
>
> aptitude update, upgrade etc work without problems, AFAICT.

I assume this happens primarily as root on the remote host.

> I can reproduce this on several remote hosts running Bullseye or
> Testing,

Marking as found in 0.8.13-3 then.

> so it must be related to my environment somehow (Testing
> on a desktop PC), but it doesn't tell.

Ack. Doesn't look like a repo issue. Except maybe, if there's a common
non-debian APT repo involved.

Oh, and since about when is this happening? I assume this showed up
only recently, not for years. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

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

2023-05-12 Thread James Addison

On Fri, 12 May 2023 at 16:54, Thorsten Glaser  wrote:
>
> Yes, but given the usual ulimit, the new limit would be 4+ times
> the old one, much much harder to reach.

That does sound promising.

I've followed up on this discussion with the relevant upstream NodeJS
thread, and beyond there to the relevant V8 discussion group.  My
sense from those, and given my own experience building NodeJS is that
I don't feel an rlimit patch is straightforward or worthwhile -
although it's possible that I didn't accurately understand or
communicate the context.

I'm going to stay involved with this thread, but I think that it is
upon you to develop or provide further guidance towards a patch if
it's something you'd like to have implemented, Thorsten.

Bug#1035960: All of sudden, the Spanish PO debconf templates is getting full of alien translators :-)

2023-05-12 Thread Laura Arjona Reina


Thanks everybody for the extra info and Cyril for the research

I have killed the spider jobs.
I have modified the crontab in tye.debian.org to disable cron.hourly job 
(spiderbts) for now.


I have removed the status files [1] and launched a job spiderinit [2] to 
re-create them.


[1] in /srv/i18n.debian.org/dl10n/data/spiderbts/data/status.??
[2] sudo -u debian-i18n /srv/i18n.debian.org/dl10n/git/cron/spiderinit &

Tomorrow I'll have a look at the logs of the spiderinit job [3] and 
launch the cron.hourly job once.


[3] /srv/i18n.debian.org/log/spiderinit/spiderinit.20230512-2134.[err|log]


Then I'll see how long does it take and if there is any issue.
If everything went well the webpages should show correct data. Then I'll 
set the "hourly" job to run 6 times a day and will keep an eye these days.


I agree that a lockfile is needed, I'll try to work on that too and when 
it's set, and the issue is fixed, I'll update the cron to run hourly again.


Kind regards


El 12/5/23 a las 12:04, Cyril Brulebois escribió:

Cyril Brulebois  (2023-05-12):

I'll keeping looking at what's supposed to happen on tye, but I'm not
sure I'll be able to get to the bottom of it on my own.


At least there's a HUGE red flag on tye. Load to the roof, RAM/swap
almost full, lots of dl10n-spider processes running for the same
language, some of them started May 9th.

 kibi@tye:~$ uptime
  10:02:58 up 12 days, 21:47,  2 users,  load average: 63.24, 64.57, 66.51

 kibi@tye:~$ free -h
totalusedfree  shared  buff/cache   
available
 Mem:   1.9Gi   1.7Gi69Mi   1.0Mi   125Mi   
 57Mi
 Swap:  511Mi   511Mi   0.0Ki

 kibi@tye:~$ ps faux|grep dl10n-spider|grep -o -- '--check-bts 
..'|sort|uniq -c
   4 --check-bts ca
   1 --check-bts cs
   1 --check-bts da
  51 --check-bts de
   7 --check-bts es
   2 --check-bts fr

 kibi@tye:~$ ps faux|awk '/CRON/ {print $9}'|sort|uniq -c
  11 May09
  23 May10
  23 May11
   1 00:15
   1 02:15
   1 03:15
   1 04:15
   1 05:15
   1 06:15
   1 07:15
   1 08:13
   1 08:15
   1 09:15
   2 10:00
   1 10:01

Note that many de.po occurrences appear in the status file for other
languages, looks like processes heavily stomping onto others' feet?


It looks to me there should be some locking at the very least to avoid
that amount of concurrency. And that it would probably be best to start
afresh, killing all those processes, maybe disabling the cron jobs,
cleaning temporary and maybe corrupted data files, and triggering a
single run manually to see if it works.

But then, I have 0 knowledge about the spider, and I'll leave that up to
someone else: I don't want to risk making the matter worse!


Cheers,


--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#1035899: (no subject)

2023-05-12 Thread Al Ma

I noticed now that I had unintentionally omitted the name of a package in my 
version list in my original post. It should read: “Here are the versions of 
some relevant installed packages: xorg  1:7.7+23, […].”

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

2023-05-12 Thread Pascal Hambourg


On 12/05/2023 at 07:07, Cyril Brulebois wrote:



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. :)


Thanks for spotting this.


-   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.


As you may have noticed previously, I have a tendency to insert 
unrelated trivial "cosmetic" fixes in my patches. My purpose here was to 
consistently make use of $MNT instead of /media like in the rest of the 
code.



-   if [ "$i" = 1 ]; then
+   if [ "$i" = 1 ]; then


Another cosmetic fix...


# 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.

Bug#1035899: org.gnome.Shell.desktop[…]: Unrecognized option: -initfd

2023-05-12 Thread Al Ma

Simon,
Thank you for a reply. I understand. On the machine in question, libmutter-10-0 
in version 42.3-2 is installed. The package libmutter-7-0 is not installed, and 
no other libmutters are known to aptitude.  At the moment, I cannot risk a full 
upgrade from Debian stable to Debian testing (it's a production machine), but I 
can certainly try to upgrade a package or two. To get rid of the particular 
error message, the solution would be to upgrade xwayland, wouldn't it?  Any 
hint on which version would do, at least roughly?
Gratefully,
Alma

Bug#1036011: unblock: slop/7.6-4

2023-05-12 Thread Jakob Haufe

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

Please unblock package slop

This fixes RC bug #1034953 which could affect users upgrading from
bullseye to bookworm.

I did manual installation and update tests to ensure the bugs is fixed
and everything works as expected.

unblock slop/7.6-4

-- 
ceterum censeo microsoftem esse delendam.


pgpsn37hccoGw.pgp
Description: OpenPGP digital signature

Bug#1036010: RFS: audacious/4.3.1-1~exp1 -- small and fast audio player which supports lots of formats

2023-05-12 Thread Mateusz Łukasik


Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : audacious
   Version  : 4.3.1-1~exp1
   Upstream contact : Audacious Development Team
 * URL  :https://www.audacious-media-player.org/
 * License  : ISC, BSD-3-clause, BSD-2-clause, CC0
 * Vcs  :https://salsa.debian.org/multimedia-team/audacious
   Section  : sound

The source builds the following binary packages:

  audacious - small and fast audio player which supports lots of formats
  audacious-dev - audacious development files
  libaudcore5 - audacious core engine library
  libaudgui5 - audacious media player (libaudgui shared library)
  libaudtag3 - audacious media player (libaudtag shared library)
  libaudqt2 - audacious media player (libaudqt shared library)

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

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

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/a/audacious/audacious_4.3.1-1~exp1.dsc

Changes since the last upload:

 audacious (4.3.1-1~exp1) experimental; urgency=medium
 .
   * New upstream release.
   * Use GTK3. (Closes: #967261)
   * Update symbols files.
   * Switch build method to meson.

Regards,
--
  Mateusz Łukasik

Bug#1036009: RFS: audacious-plugins/4.3.1-1~exp1 -- Base plugins for audacious

2023-05-12 Thread Mateusz Łukasik


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "audacious-plugins":

 * Package name : audacious-plugins
   Version  : 4.3.1-1~exp1
   Upstream contact : Audacious Development Team
 * URL  :https://www.audacious-media-player.org/
 * License  : LGPL-2.1+, Expat, Artistic, GPL-3+, BSD-2-clause, GPL-2+, 
ISC, public-domain, GPL-3, GPL-2 or GPL-3, LGPL-2, BSD-3-clause
 * Vcs  :https://salsa.debian.org/multimedia-team/audacious-plugins
   Section  : sound

The source builds the following binary packages:

  audacious-plugins - Base plugins for audacious
  audacious-plugins-data - Data files for Audacious plugins

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

  https://mentors.debian.net/package/audacious-plugins/

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/a/audacious-plugins/audacious-plugins_4.3.1-1~exp1.dsc

Changes since the last upload:

 audacious-plugins (4.3.1-1~exp1) experimental; urgency=medium
 .
   * New upstream release
   * Bump versioned depencencies.
   * Use GTK3. (Closes: #967262)
   * Switch buildsystem to meson.
   * Add pipeline support.

Regards,
--
  Mateusz Łukasik

Bug#1036008: RFS: volumeicon/0.5.1+git20230228-1 -- systray volume icon for alsa

2023-05-12 Thread Mateusz Łukasik


Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : volumeicon
   Version  : 0.5.1+git20230228-1
   Upstream contact : Mart G
 * URL  :http://nullwise.com/volumeicon.html
 * License  : Expat, GPL-3
 * Vcs  :https://github.com/mati75/volumeicon-debian.git
   Section  : sound

The source builds the following binary packages:

  volumeicon-alsa - systray volume icon for alsa

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

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

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/v/volumeicon/volumeicon_0.5.1+git20230228-1.dsc

Changes since the last upload:

 volumeicon (0.5.1+git20230228-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Trim trailing whitespace.
   * Use secure copyright file specification URI.
   * debian/copyright: use spaces rather than tabs to start continuation
 lines.
   * Bump debhelper from old 10 to 12.
   * Set debhelper-compat version in Build-Depends.
   * Drop unnecessary dependency on dh-autoreconf.
   * Drop unnecessary dh arguments: --parallel
 .
   [ Mateusz Łukasik ]
   * New upstream snapshot.
   * Bump debhelper to 13.
   * Bump Standards-Version to 4.6.2.
   * d/control: Update homepage.
   * d/copyright: Update homepage and dates.
   * d/watch: update to github.
   * d/control: Add Rules-Requires-Root

Regards,
--
  Mateusz Łukasik

Bug#1036007: unblock: opencv/4.6.0+dfsg-12

2023-05-12 Thread Jochen Sprickerhof

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

Please unblock package opencv

[ Reason ]
This upload fixes two bugs:

1. #1035886 that adds a single Breaks: against an old library version to
   easy the upgrade.

2. #1035954 that adds upstream patches for two CVEs.

[ Impact ]
For 1. users could have problems upgrading.
For 2. I'm not sure about the impact of the CVEs but I guess it is
better to get them fixed before the release.

[ Tests ]
The CVEs carry a test, I did not verify the Breaks: but I assume Andreas
tested it :).

[ Risks ]
The Breaks: means users can't keep the old version, I think that is
acceptable if apt finds a upgrade solution.
For the CVEs the patch looks reasonable but I'm not sure if there is any
risk to it. Given that it applied cleanly to the version in unstable and
that upstream accepted it, I think it is fine.

[ 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 ]
The patch carries a change to debian/gbp.conf which is not imported for
the package in the archive.

unblock opencv/4.6.0+dfsg-12
diff --git a/debian/changelog b/debian/changelog
index 35b4b87d7..6ddf7e440 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+opencv (4.6.0+dfsg-12) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Andreas Beckmann ]
+  * libopencv-core406: Add Breaks: libopencv-core4.5 for smoother upgrades 
from bullseye
+(Closes: #1035886)
+
+  [ Jochen Sprickerhof ]
+  * Add upstream patches for CVE-2023-2617 and CVE-2023-2618 (Closes: #1035954)
+
+ -- Jochen Sprickerhof   Fri, 12 May 2023 11:40:38 +0200
+
 opencv (4.6.0+dfsg-11) unstable; urgency=medium
 
   * Update d/rules.
diff --git a/debian/control b/debian/control
index 4b6a4c095..421f0eb14 100644
--- a/debian/control
+++ b/debian/control
@@ -168,6 +168,7 @@ Section: libs
 Depends: ${misc:Depends},
  ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
+Breaks: libopencv-core4.5 (<< 4.6),
 Description: computer vision core library
  This package contains the OpenCV (Open Computer Vision) core runtime 
libraries.
  .
diff --git a/debian/gbp.conf b/debian/gbp.conf
index b5d1dad92..f2905a065 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,3 +1,5 @@
+[DEFAULT]
+component = contrib
+
 [import-orig]
 pristine-tar = True
-component = contrib
diff --git 
a/debian/patches/0009-fix-wechat_qrcode-Init-nBytes-after-the-count-value-.patch
 
b/debian/patches/0009-fix-wechat_qrcode-Init-nBytes-after-the-count-value-.patch
new file mode 100644
index 0..879403e4b
--- /dev/null
+++ 
b/debian/patches/0009-fix-wechat_qrcode-Init-nBytes-after-the-count-value-.patch
@@ -0,0 +1,84 @@
+From: Nano 
+Date: Wed, 26 Apr 2023 15:09:52 +0800
+Subject: fix(wechat_qrcode): Init nBytes after the count value is determined
+ (#3480)
+
+* fix(wechat_qrcode): Initialize nBytes after the count value is determined
+
+* fix(wechat_qrcode): Incorrect count data repair
+
+* chore: format expr
+
+* fix(wechat_qrcode): Avoid null pointer exception
+
+* fix(wechat_qrcode): return when bytes_ is empty
+
+* test(wechat_qrcode): add test case
+
+-
+
+Co-authored-by: GZTime 
+---
+ .../src/zxing/qrcode/decoder/decoded_bit_stream_parser.cpp  | 13 +
+ contrib/modules/wechat_qrcode/test/test_qrcode.cpp  | 11 +++
+ 2 files changed, 20 insertions(+), 4 deletions(-)
+
+diff --git 
a/contrib/modules/wechat_qrcode/src/zxing/qrcode/decoder/decoded_bit_stream_parser.cpp
 
b/contrib/modules/wechat_qrcode/src/zxing/qrcode/decoder/decoded_bit_stream_parser.cpp
+index 05de793..b3a0a69 100644
+--- 
a/contrib/modules/wechat_qrcode/src/zxing/qrcode/decoder/decoded_bit_stream_parser.cpp
 
b/contrib/modules/wechat_qrcode/src/zxing/qrcode/decoder/decoded_bit_stream_parser.cpp
+@@ -65,7 +65,8 @@ void DecodedBitStreamParser::append(std::string& result, 
string const& in,
+ 
+ void DecodedBitStreamParser::append(std::string& result, const char* bufIn, 
size_t nIn,
+ ErrorHandler& err_handler) {
+-if (err_handler.ErrCode()) return;
++// avoid null pointer exception
++if (err_handler.ErrCode() || bufIn == nullptr) return;
+ #ifndef NO_ICONV_INSIDE
+ if (nIn == 0) {
+ return;
+@@ -190,16 +191,20 @@ void 
DecodedBitStreamParser::decodeByteSegment(Ref bits_, string& res
+CharacterSetECI* 
currentCharacterSetECI,
+ArrayRef >& 
byteSegments,
+ErrorHandler& err_handler) {
+-int nBytes = count;
+ BitSource& bits(*bits_);
+ // Don't crash trying to read more bits than we have available.
+ int available = bits.available();
+ // try to repair count data if count

Bug#1036006: unblock: postgresql-15/15.3-0+deb12u1

2023-05-12 Thread Christoph Berg

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

Please unblock package postgresql-15.

[ Reason ]
The new version fixes CVE-2023-2454 and CVE-2023-2455.

[ Impact ]
CVE-2023-2454 and CVE-2023-2455.

[ Tests ]
The package passes all the built-in regression tests and the
postgresql-common testsuite.

[ Risks ]
New PostgreSQL upstream releases are generally accepted.

[ Checklist ]
  (No changes in debian/ except for the changelog)
  [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

postgresql-15 (15.3-0+deb12u1) unstable; urgency=medium

  * New upstream version.

+ Prevent CREATE SCHEMA from defeating changes in search_path
  (Report and fix by Alexander Lakhin, CVE-2023-2454)

  Within a CREATE SCHEMA command, objects in the prevailing search_path,
  as well as those in the newly-created schema, would be visible even
  within a called function or script that attempted to set a secure
  search_path.  This could allow any user having permission to create a
  schema to hijack the privileges of a security definer function or
  extension script.

+ Enforce row-level security policies correctly after inlining a
  set-returning function (Report by Wolfgang Walther, CVE-2023-2455)

  If a set-returning SQL-language function refers to a table having
  row-level security policies, and it can be inlined into a calling query,
  those RLS policies would not get enforced properly in some cases
  involving re-using a cached plan under a different role. This could
  allow a user to see or modify rows that should have been invisible.

 -- Christoph Berg   Tue, 09 May 2023 19:05:02 +0200

unblock postgresql-15/15.3-0+deb12u1

Thanks,
Christoph


signature.asc
Description: PGP signature

Bug#1034824: tomcat9 should not be released with Bookworm

2023-05-12 Thread Paul Gevers


Hi Markus,

Thanks for the reply and sorry for my bit grumpy mail yesterday. I was 
tired and surprised.


On 11-05-2023 23:31, Markus Koschany wrote:

[...] (all good reply).

I'll check on Sunday on the proposal, unless somebody beats me to it. I 
don't have time before then.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034886: closed by Moritz Muehlenhoff (Re: Bug#1034886: docker.io: CVE-2022-37708)

2023-05-12 Thread Salvatore Bonaccorso

Hi,

On Thu, Apr 27, 2023 at 01:18:03PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:docker.io package:
> 
> #1034886: docker.io: CVE-2022-37708
> 
> It has been closed by Moritz Muehlenhoff .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Moritz Muehlenhoff 
>  by
> replying to this email.
> 
> 
> -- 
> 1034886: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034886
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> From: Moritz Muehlenhoff 
> User-Agent: Mutt/1.10.1 (2018-07-13)
> Date: Thu, 27 Apr 2023 15:14:47 +0200
> To: Shengjing Zhu 
> Cc: 1034886-d...@bugs.debian.org, Tianon Gravi 
> Subject: Re: Bug#1034886: docker.io: CVE-2022-37708
> Message-ID: <20230427131447.ga31...@inutil.org>
> 
> On Thu, Apr 27, 2023 at 04:21:21AM +0800, Shengjing Zhu wrote:
> > On Thu, Apr 27, 2023 at 1:39 AM Moritz Mühlenhoff  wrote:
> > >
> > > Source: docker.io
> > > X-Debbugs-CC: t...@security.debian.org
> > > Severity: important
> > > Tags: security
> > >
> > > Hi,
> > >
> > > The following vulnerability was published for docker.io.
> > >
> > > CVE-2022-37708[0]:
> > > | Docker version 20.10.15, build fd82621 is vulnerable to Insecure
> > > | Permissions. Unauthorized users outside the Docker container can
> > > | access any files within the Docker container.
> > >
> > > The only reference here seems to be
> > > upstream: https://github.com/thekevinday/docker_lightman_exploit
> > >
> > > Not sure if this was reported upstream
> > 
> > I have talked to Tianon on 2023-02-28, and we concluded that it's not
> > a security issue, just working as expected.
> 
> Yeah, it's hard to understand why this got a CVE assigned. 
> 
> > Tianon said he will ask someone inside the Docker company. Not sure if
> > they have successfully invalidated this CVE.
> 
> Sounds good, in the mean time I'll record it as a non-issue in the Security
> Tracker (independent of whether Docker Inc rejects it or not). We can also
> simply close the bug.

FWIW, the CVE got rejected.

Regards,
Salvatore

Bug#1035522: bullseye-pu: package debian-security-support/1:11+2023.05.04

2023-05-12 Thread Adam D. Barratt

Control: tags -1 + confirmed

On Fri, 2023-05-12 at 08:50 +, Holger Levsen wrote:
> hi,
> 
> friendly ping on this.
> 

It's only been a week, and one of the SRMs has been on a publicised
(fvo publicised being relevant to DDs) week away. It's a little soon to
be chasing. :-(

> On Thu, May 04, 2023 at 07:50:37PM +0200, Holger Levsen wrote:
> > this is a pre-approval request, I have not uploaded this yet
> > (except to
> > unstable). 
> 
> the package has migrated to bookworm now.
>  
> > [ Reason ]
> > 
> > unfortunatly debian-security-support in both bullseye and bookworm
> > are affected by - #1034077 
> > "debian-security-support: Lots of noise about DEBIAN_VERSION 12
> > being 
> > invalid when upgrading bullseye→bookworm"
> [...]
>  
> > [ Other info ]
> > As there will be no more bullseye point releases before the
> > bookworm
> > release, this probably needs to go in via bullseye-updates. Is
> > d/changelog
> > correct for this like it is?
> 
> I'm not quoting the full bug report but the above is reason why this
> should
> go into *bullseye* before the bookworm release...

I'm a bit confused here. Your own text above indicates that you're
aware that there won't be any more point releases before the release,
and that therefore the package *cannot* be in bullseye before the
release. Point releases are the mechanism by which packages get updated
in stable.

In any case, please go ahead.

Regards,

Adam

Bug#1035913: fixed in doc-debian 11.2

2023-05-12 Thread Johannes Schauer Marin Rodrigues

Hi,

Quoting Joost van Baal-Ilić (2023-05-12 09:12:23)
> TL;DR: I believe I can upload a fix to experimental & ask for unblock in the
> coming weekend.

cool!

> And I understand you want to be sure doc-debian in bookworm will ship the
> new-style /usr/share/doc-base/doc-debian.debian-constitution-text e.a. , not
> the old-style /usr/share/doc-base/debian-constitution-text .

I actually care little about which version it is and only want to know what it
will be so that I can adapt my package accordingly. But we already learned that
with current debhelper it will always be the former version.

> I am very sorry it took me so long to find some time to work on these long
> standing issues.  (In my defense: I've explicitly asked for more hands:
> https://lists.debian.org/msgid-search/20230201193812.gb28...@beskar.mdcc.cx .
> And: I'm am not the doc-debian maintainer; I'm merely an uploader.)

Sorry, I didn't want to come across as rude. I'm also just doing all this as a
volunteer in my limited free time just like you. Though it seems in practice
you have become the de-facto doc-debian maintainer now -- congratulations. :)

> Anyway, I'll likely have time to work on this during the coming weekend; I
> believe I can do a fixed upload then, thanks to your very helpful hints.
> (And, risking stating the obvious here: NMU's very welcome.)

If you want me to do something, just mail me what you need and I'll see whether
I can find some time to take care of it.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1036005: unblock: pcp/6.0.3-1.1

2023-05-12 Thread Andreas Metzler

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: p...@packages.debian.org, ametz...@bebt.de
Control: affects -1 + src:pcp

Hello,

Please unblock package pcp, this just adds missing Replaces: for
upgrades from stable to testing.

The NMU was originally uploaded to the delayed queue but I later got
the go ahead from the package maintainer(s) to move to 0-day.

unblock pcp/6.0.3-1.1

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru pcp-6.0.3/debian/changelog pcp-6.0.3/debian/changelog
--- pcp-6.0.3/debian/changelog	2023-02-23 00:52:31.0 +0100
+++ pcp-6.0.3/debian/changelog	2023-05-07 11:36:37.0 +0200
@@ -1,3 +1,18 @@
+pcp (6.0.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing replaces on pcp (<< 5.3.0):
++ pcp-export-pcp2elasticsearch Closes: #1034998
++ pcp-export-pcp2json Closes: #1034983
++ pcp-export-pcp2spark Closes: #1034932
++ pcp-export-pcp2xml Closes: #1034922
++ pcp-export-pcp2zabbix Closes: #1034973
++ pcp-doc Closes: #1034966
++ pcp-zeroconf Closes: #1034895
++ pcp-export-pcp2xlsx (unfiled)
+
+ -- Andreas Metzler   Sun, 07 May 2023 11:36:37 +0200
+
 pcp (6.0.3-1) unstable; urgency=low
 
   * New release (full details in CHANGELOG).
diff -Nru pcp-6.0.3/debian/control pcp-6.0.3/debian/control
--- pcp-6.0.3/debian/control	2023-02-23 00:52:31.0 +0100
+++ pcp-6.0.3/debian/control	2023-05-07 07:37:15.0 +0200
@@ -385,6 +385,7 @@
 Package: pcp-export-pcp2elasticsearch
 Depends: python3-pcp, python3-requests, ${python:Depends}, ${misc:Depends}, ${shlibs:Depends}
 Breaks: pcp (<< 5.3.0)
+Replaces: pcp (<< 5.3.0)
 Architecture: any
 Description: Tool for exporting data from PCP to Elasticsearch
  Performance Co-Pilot (PCP) front-end tool for exporting data from PCP
@@ -409,6 +410,7 @@
 Package: pcp-export-pcp2json
 Depends: python3-pcp, ${python:Depends}, ${misc:Depends}, ${shlibs:Depends}
 Breaks: pcp (<< 5.3.0)
+Replaces: pcp (<< 5.3.0)
 Architecture: any
 Description: Tool for exporting data from PCP to JSON
  Performance Co-Pilot (PCP) front-end tool for exporting data from PCP
@@ -417,6 +419,7 @@
 Package: pcp-export-pcp2spark
 Depends: python3-pcp, python3-requests, ${python:Depends}, ${misc:Depends}, ${shlibs:Depends}
 Breaks: pcp (<< 5.3.0)
+Replaces: pcp (<< 5.3.0)
 Architecture: any
 Description: Tool for exporting data from PCP to Apache Spark
  Performance Co-Pilot (PCP) front-end tools for exporting metric values
@@ -425,6 +428,7 @@
 Package: pcp-export-pcp2xml
 Depends: python3-pcp, ${python:Depends}, ${misc:Depends}, ${shlibs:Depends}
 Breaks: pcp (<< 5.3.0)
+Replaces: pcp (<< 5.3.0)
 Architecture: any
 Description: Tool for exporting data from PCP to XML
  Performance Co-Pilot (PCP) front-end tool for exporting data from PCP
@@ -433,6 +437,7 @@
 Package: pcp-export-pcp2zabbix
 Depends: python3-pcp, ${python:Depends}, ${misc:Depends}, ${shlibs:Depends}
 Breaks: pcp (<< 5.3.0)
+Replaces: pcp (<< 5.3.0)
 Architecture: any
 Description: Tool for exporting data from PCP to Zabbix
  Performance Co-Pilot (PCP) front-end tool for exporting data from PCP
@@ -449,7 +454,7 @@
 Section: doc
 Depends: ${misc:Depends}
 Breaks: pcp (<< 5.3.0), pcp-gui (<< 1.5.13)
-Replaces: pcp-gui (<< 1.5.13)
+Replaces: pcp (<< 5.3.0), pcp-gui (<< 1.5.13)
 Suggests: pcp, pcp-gui
 Architecture: all
 Description: Documentation and tutorial for the Performance Co-Pilot
@@ -462,6 +467,7 @@
 Package: pcp-zeroconf
 Depends: ${misc:Depends}, ${shlibs:Depends}, pcp (= ${binary:Version})
 Breaks: pcp (<< 5.3.0)
+Replaces: pcp (<< 5.3.0)
 Architecture: any
 Description: Performance Co-Pilot (PCP) Zeroconf Package
  Contains configuration tweaks and files that increase metrics gathering
@@ -511,6 +517,7 @@
 Package: pcp-export-pcp2xlsx
 Depends: ${python:Depends}, ${misc:Depends}, ${shlibs:Depends}
 Breaks: pcp (<< 5.3.0)
+Replaces: pcp (<< 5.3.0)
 Architecture: any
 Description: Tool for exporting data from PCP to Excel spreadsheets
  Performance Co-Pilot (PCP) front-end tool for exporting data from PCP


signature.asc
Description: PGP signature

Bug#1035971: linux-image-6.3.0-0-amd64: IRQ warnings from amdgpu Navi 33 / Radeon RX 7700S ...

2023-05-12 Thread Diederik de Haas

Control: clone -1 -2
Control: forwarded -2 https://bugzilla.kernel.org/show_bug.cgi?id=217336
Control: retitle -2 Strange keyboard issues on ASUS TUF Gaming A16 Advantage 
Edition, model FA617XT

On Friday, 12 May 2023 04:05:42 CEST Nathan Schulte wrote:
> I don't think it's related to the issue here, but it does involve
> interrupts: the PS/2 keyboard in the laptop does not work correctly or
> in the slightest, and a report about a sibling model exists already
> where the owner gave up:
> https://bugzilla.kernel.org/show_bug.cgi?id=217336

That seems a different issue indeed, so I'm cloning the bug to track
that separately.

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

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

2023-05-12 Thread Thorsten Glaser

James Addison dixit:

>So: a fix here won't achieve stack capacity equality across

No. The fix you proposed won’t achieve that but others would
improve the situation much more, so that equality across arches
won’t need to matter any more.

>Or, to put it another way: applying an increase (either static or
>dynamic, either ARM-specific or across all architectures) for stack
>size determination would move the problem, and another architecture
>would take the place of "architecture where RangeError can occur in
>code x that doesn't occur on other architectures".

Yes, but given the usual ulimit, the new limit would be 4+ times
the old one, much much harder to reach.

>it, though - and based on their current policy, NodeJS upstream seem
>unlikely to accept it since they don't want to modify their vendored
>V8.

AIUI that’s not necessary because you can already set the stack
limit with a nodejs command line option. The patch could just
set the limit, using the same facility that CLI option uses, if
that option isn’t given (or before it is processed).

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

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

On Fri, 12 May 2023 at 15:30, Steve McIntyre  wrote:
>
> On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> >On Fri, 12 May 2023 at 12:08, Steve McIntyre  wrote:
> >>
> >> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
> >> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
> >> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre  wrote:
> >> >>>
> >> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >> >>> >
> >> >>> >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.
> >> >>>
> >> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've
> >> >>> seen. The interpreter must *not* be changed willy-nilly.
> >> >>
> >> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of
> >> >>seemingly crazy options, as in, "what would _actually_ explode if we
> >> >>do this or do that?", on this very d-devel thread. I posted a longer
> >> >>version here some days ago:
> >> >>
> >> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html
> >> >
> >> >Oh holy fuck.
> >> >
> >> >You're talking about changing ABI by doing this. That *is* utterly
> >> >crazy. No.
> >>
> >> People have asked me to expand on this further...
> >>
> >> I've been involved in defining ABI before, specifically for
> >> armhf. It's not a quick and easy process. It needs buy-in from all
> >> sides to make things work, and people *really* value the
> >> interoperability that it enables.
> >>
> >> The interpreter path is one of the most important parts of the ABI
> >> spec, the bit that makes binaries compatible between all the various
> >> stakeholders: compiler/tools people, distros, software vendors,
> >> etc. Lots of the rest of the details downstream of this can be
> >> changed, and people do this all the time - compare multilib to
> >> multi-arch for example. That all works fine *so long as* the runtime
> >> linker can be located and started OK.
> >
> >The loader is still available via the old path, so external/third
> >party/local/other software works unchanged. This should negatively
> >only affect our 1st party packages, when running on a non-merged
> >distro.
>
> So why the hell do you want to break this in the first place? Does a
> symlink in the "wrong" place offend you for some reason? For that you
> want to change a core assumption in *every single binary* in Debian?
> Believe me, I've been here in the past when we made changes in armhf
> to accommodate earlier mistakes. That was just for one
> architecture. What possible benefit do you see in this change?

As it was mentioned on the list, because it makes bootstrapping
self-contained, that's a real and concrete benefit that some
developers like Helmut care greatly about, and that's why we are
talking about it. To me, it sounds very attractive to have a
self-contained and canonicalized distro-wide configuration. If the
canonical location where certain files are stored in /usr/bin or
/usr/lib, it seems sensible to me to configure Debian software to look
for it where we actually put it, while maintaining compatibility for
external/local software so that it keeps working. And it is also
unclear so far what would outright break - the externally defined ABI
in terms of where the loader can be accessed at, would still be
respected. Hence why questions are being asked. Nobody's being forced
to do anything, this is just a discussion.

> >And are _all_ our packages really 100% compatible with other distros
> >at all? Are they even supposed to be?
> >
> >For example, if I download efibootmgr from Bookworm on an Ubuntu Focal
> >machine, when I try to run it, it fails:
> >
> >root@focal:/tmp# wget
> >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
> >--2023-05-12 12:46:17--
> >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
> >Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4
> >Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... 
> >connected.
> >HTTP request sent, awaiting response... 200 OK
> >Length: 27572 (27K) [application/vnd.debian.binary-package]
> >Saving to: 'efibootmgr_17-2_amd64.deb'
> >
> >efibootmgr_17-2_amd64.deb
> >100%[===>]  26.93K
> >--.-KB/sin 0.04s
> >
> >2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved 
> >[27572/27572]
> >
> >root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm
> >root@focal:/tmp# ./ebm/bin/efibootmgr
> >./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version
> >`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr)
> >
> >Should I file a severity: serious bug against efibootmgr because it is
> >not interoperable?
>
> You're wilfully missing the point, and you know it.

I'm trying to determine

Bug#1029430: reposurgeon: FTBFS in bookworm (undeclared build-dependency on tzdata)

2023-05-12 Thread Santiago Vila


reopen 1029430
thanks

This is not a false positive.

Quoting Debian Policy:

--
If build-time dependencies are specified, it must be possible to build the 
package and produce working binaries on a system with only essential and 
build-essential packages installed and also those required to satisfy the 
build- time relationships (including any implied relationships).
--

If you build the package on a chroot without tzdata installed, the build fails.

I've double checked again right now. The build succeeds if you have tzdata 
installed
and does not if tzdata is missing. Because tzdata is not build-essential, this 
is
a violation of a must directive in Debian Policy.

The only reason the bug is not serious is that Release Managers have asked not 
to
report it as RC, and I'm already honoring such request, but other than that,
this is still a bug.

Moreover, I included the following paragraph in my bug report:

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If you have any difficulty to try the build on a chroot without tzdata,
the above offer still holds.

Thanks.

Bug#953997: obsolete conffiles after upgrade

2023-05-12 Thread Christoph Anton Mitterer

On Fri, 2023-05-12 at 14:27 +0200, Andrea Bolognani wrote:
> I think at this point we can assume that most people who have hit the
> issue on upgrade will have cleaned things up manually by now, so I'd
> be inclined to close the bug and move on.
> 
> Any objections?

Well not a strong objection from my side, but I think typically most
people will rather simply not even notice that they have leftover
files, so they'll stay there forever unless cleaned up properly.

Cheers,
Chris.

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

On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
>On Fri, 12 May 2023 at 12:08, Steve McIntyre  wrote:
>>
>> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
>> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
>> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre  wrote:
>> >>>
>> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>> >>> >
>> >>> >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.
>> >>>
>> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've
>> >>> seen. The interpreter must *not* be changed willy-nilly.
>> >>
>> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of
>> >>seemingly crazy options, as in, "what would _actually_ explode if we
>> >>do this or do that?", on this very d-devel thread. I posted a longer
>> >>version here some days ago:
>> >>
>> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html
>> >
>> >Oh holy fuck.
>> >
>> >You're talking about changing ABI by doing this. That *is* utterly
>> >crazy. No.
>>
>> People have asked me to expand on this further...
>>
>> I've been involved in defining ABI before, specifically for
>> armhf. It's not a quick and easy process. It needs buy-in from all
>> sides to make things work, and people *really* value the
>> interoperability that it enables.
>>
>> The interpreter path is one of the most important parts of the ABI
>> spec, the bit that makes binaries compatible between all the various
>> stakeholders: compiler/tools people, distros, software vendors,
>> etc. Lots of the rest of the details downstream of this can be
>> changed, and people do this all the time - compare multilib to
>> multi-arch for example. That all works fine *so long as* the runtime
>> linker can be located and started OK.
>
>The loader is still available via the old path, so external/third
>party/local/other software works unchanged. This should negatively
>only affect our 1st party packages, when running on a non-merged
>distro.

So why the hell do you want to break this in the first place? Does a
symlink in the "wrong" place offend you for some reason? For that you
want to change a core assumption in *every single binary* in Debian?
Believe me, I've been here in the past when we made changes in armhf
to accommodate earlier mistakes. That was just for one
architecture. What possible benefit do you see in this change?

>And are _all_ our packages really 100% compatible with other distros
>at all? Are they even supposed to be?
>
>For example, if I download efibootmgr from Bookworm on an Ubuntu Focal
>machine, when I try to run it, it fails:
>
>root@focal:/tmp# wget
>http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
>--2023-05-12 12:46:17--
>http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
>Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4
>Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... 
>connected.
>HTTP request sent, awaiting response... 200 OK
>Length: 27572 (27K) [application/vnd.debian.binary-package]
>Saving to: 'efibootmgr_17-2_amd64.deb'
>
>efibootmgr_17-2_amd64.deb
>100%[===>]  26.93K
>--.-KB/sin 0.04s
>
>2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved 
>[27572/27572]
>
>root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm
>root@focal:/tmp# ./ebm/bin/efibootmgr
>./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version
>`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr)
>
>Should I file a severity: serious bug against efibootmgr because it is
>not interoperable?

You're wilfully missing the point, and you know it.

>The answer is obviously not, because it would be absurd to expect a
>binary compiled against libraries from one distro to "just work" on an
>entirely different distro. Glibc itself is not forward compatible, and
>is allowed to add new symbols, that are not present in older versions,
>and packages are allowed to depend on them. Aren't those also ABI
>breakages? What about all the libraries that bump soname? What about
>binaries that rely on newer kernel interfaces, or IPC interfaces?
>
>So, what I am asking is, what actual, real difference does it make if,
>by default (and with an override available for example), packages
>built on Debian for Debian record the ld path to point to its (actual)
>location on Debian, via say a compiler spec file that is injected in a
>deb build?
>There very likely is some real difference and impact, and I am
>genuinely and honestly asking what it could be. If nothing else, it's
>an interesting topic, even if likely nothing comes out of it.

I have better things to do than argue about this. I refuse to engage
with this right now. You're talking about

Bug#1036003: unblock: adacgi/1.6-32 and 20 Ada libraries

2023-05-12 Thread Nicolas Boulenguez

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

Please unblock package adacgi

The -dev package for Ada libraries is renamed when the source changes.
So  libadacgi4-dev in bullseye
and libadacgi6-dev in bullseye have some conflicting files.

Each -dev package must Break/Replace previous -dev packages,
else the upgrade fails:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034975

(This issue has been known for long, but depending on non
 coinstallable gnat versions seemed sufficient until now)

The attached fix seems trivial and without risk.

As far as I understand, an unblock is necessary even if these packages
have autopkgtests because the freeze is planned in less than 20 days.

All Ada libraries are affected by the same issue.
Should I open several request?

Here are the relevant bug numbers (some sources build several libraries).
adacgi   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034975
adasockets   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034896
ahvenhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035011
anet https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035013
dbusada  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034914
gprbuild https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034913
libalog  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035004
libaunit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034934
libflorist   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035006
libgmpadahttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034960
libgnatcoll-bindings https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034917
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034919
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034928
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034940
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034974
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034991
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035002
libgnatcoll-db   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034946
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034964
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034981
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035010
libgnatcoll  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034920
libgtkadahttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034970
liblog4ada   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034916
libncursesadahttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034977
libtemplates-parser  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034985
libtexttools https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034979
libxmladahttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034918
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034926
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034937
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034944
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034952
libxmlezout  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034965
pcscada  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034927


A similar fix for plplot/5.15.0+dfsg2-6 has been unblocked a few days ago:
broken upgrade  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034936
unblock request https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035652
non-changelog part of the debdiff:
+Replaces: libplplotada3-dev (<< 5.15.0+dfsg-26)
+Breaks: libplplotada3-dev (<< 5.15.0+dfsg-26)

This fixes upgrades from bullseye (...3-dev), but not from testing (...4-dev).
Do you think that this is release-critical?
If so, should we report a separate unblock request, or extend this one?

unblock adacgi/1.6-32
unblock adasockets/1.12-8
unblock ahven/2.8-7
unblock anet/0.4.3-3
unblock dbusada/0.6.2-4
unblock gprbuild/2023.0.0-3
unblock libalog/0.6.2-3
unblock libaunit/23.0.0-3
unblock libflorist/2022.0.1~20220616-3
unblock libgmpada/1.5-7
unblock libgnatcoll-bindings/23.0.0-6
unblock libgnatcoll-db/23.0.0-4
unblock libgnatcoll/23.0.0-3
unblock libgtkada/23.0.0-4
unblock liblog4ada/1.3.1.b6dafb49-11
unblock libncursesada/6.3.20211021-8
unblock libtemplates-parser/23.0.0-3
unblock libtexttools/2.1.0-26
unblock libxmlada/23.0.0-3
unblock libxmlezout/1.06.2-10
unblock pcscada/0.7.7-4
diff -Nru adacgi-1.6/debian/changelog adacgi-1.6/debian/changelog
--- adacgi-1.6/debian/changelog	2022-12-26 23:54:23.0 +0100
+++ adacgi-1.6/debian/changelog

Bug#1036002: unblock: utf8-locale/1.0.0-2

2023-05-12 Thread Peter Pentchev

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: utf8-loc...@packages.debian.org, r...@debian.org
Control: affects -1 + src:utf8-locale

Please unblock package utf8-locale

Version 1.0.0-2 fixes the #1035441 RC bug (serious, missing dependency
that breaks functionality). The package does have an autopkgtest suite,
and https://tracker.debian.org/pkg/utf8-locale seems to think that
everything is going to be just fine, but... I uploaded the package on
2023-05-04, which means that the 20-day wait before the testing
migration would place it *just* after the 2023-05-24 full freeze.

Any assistance would be appreciated :)

[ Reason ]
The C library's -dev package was missing a dependency on the C library
package itself, making the -dev package practically unusable.

[ Impact ]
Anyone who installs the -dev package and does not also explicitly
install the shared library package would not be able to link C programs
against the shared library.

[ Tests ]
The bug was caught by a piuparts run that flagged a dangling symlink.
I missed it because my autopkgtest suite installs all the packages
anyway, so there is no missing package :/

[ Risks ]
None at all, I believe.

[ 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 utf8-locale/1.0.0-2

diff -Nru utf8-locale-1.0.0/debian/changelog utf8-locale-1.0.0/debian/changelog
--- utf8-locale-1.0.0/debian/changelog  2022-10-23 00:55:41.0 +0300
+++ utf8-locale-1.0.0/debian/changelog  2023-05-04 21:30:41.0 +0300
@@ -1,3 +1,12 @@
+utf8-locale (1.0.0-2) unstable; urgency=medium
+
+  * Add the forgotten -dev package dependency on the library one.
+Closes: #1035441
+  * Add the year 2023 to my debian/* copyright notice
+  * Declare compliance with Policy 4.6.2 with no changes
+
+ -- Peter Pentchev   Thu, 04 May 2023 21:30:41 +0300
+
 utf8-locale (1.0.0-1) unstable; urgency=medium
 
   * Declare compliance with Policy 4.6.1 with no changes.
diff -Nru utf8-locale-1.0.0/debian/control utf8-locale-1.0.0/debian/control
--- utf8-locale-1.0.0/debian/control2022-10-23 00:47:03.0 +0300
+++ utf8-locale-1.0.0/debian/control2023-05-04 21:26:59.0 +0300
@@ -9,7 +9,7 @@
  pybuild-plugin-pyproject,
  python3-all,
  python3-setuptools,
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Homepage: https://devel.ringlet.net/devel/utf8-locale/
 Rules-Requires-Root: no
 Vcs-Git: https://gitlab.com/ppentchev/utf8-locale.git -b debian/unstable
@@ -34,6 +34,7 @@
 Section: libdevel
 Architecture: any
 Depends:
+ libutf8-locale0 (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends},
 Description: Detect a UTF-8-capable locale for running programs in - 
development files
diff -Nru utf8-locale-1.0.0/debian/copyright utf8-locale-1.0.0/debian/copyright
--- utf8-locale-1.0.0/debian/copyright  2022-10-23 00:39:50.0 +0300
+++ utf8-locale-1.0.0/debian/copyright  2023-05-04 21:26:31.0 +0300
@@ -9,7 +9,7 @@
 License: BSD-2-clause
 
 Files: debian/*
-Copyright: Copyright (c) 2022  Peter Pentchev
+Copyright: Copyright (c) 2022, 2023  Peter Pentchev
 License: BSD-2-clause
 
 License: BSD-2-clause


signature.asc
Description: PGP signature

Bug#1036001: aespipe: FTFBS on arm64, ppc64el, s390x with LTO enabled

2023-05-12 Thread Heinrich Schuchardt

Package: aespipe
Version: 2.4d-1.1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

Dear Maintainer,

  * Disable LTO to avoid failing tests on arm64, ppc64el, s390x
(LP: #2019319)


Thanks for considering the patch.


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

Kernel: Linux 6.2.0-21-generic (SMP w/32 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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru aespipe-2.4d/debian/rules aespipe-2.4d/debian/rules
--- aespipe-2.4d/debian/rules   2022-12-08 18:14:21.0 +0100
+++ aespipe-2.4d/debian/rules   2023-05-12 15:21:16.0 +0200
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 #export DH_VERBOSE=1
 
-export DEB_BUILD_MAINT_OPTIONS=hardening=-pie 
reproducible=-fixfilepath,+fixdebugpath
+export DEB_BUILD_MAINT_OPTIONS=optimize=-lto hardening=-pie 
reproducible=-fixfilepath,+fixdebugpath
 
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk

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

2023-05-12 Thread Robert Pumphrey

On 12/05/2023 13:32, Francesco P. Lovergine wrote:

On Fri, May 12, 2023 at 01:01:24PM +0100, Robert Pumphrey wrote:

Thank you for the fast response.

On the NIS master, I have moved the domain directory /var/yp/domain
to a backup.

I then ran /usr/lib/yp/ypinit -m and added the IP addresses of the
NIS slaves. This ran successfully.

/usr/lib/yp/yphelper --hostname runs successfully on the master.

/usr/lib/yp/yphelper --maps nameofnismaster runs successfully on
the master and gives a list of maps.

This is quite strange, because in moving from bullseye to bookworm
no chages in the binary gdbm files have been required in my test. Test
done after generating maps in bullseye. Are your current maps older
than that?

Even, I'm assuming you are on a amd64 arch.

I am on amd64.

I have ensured that the slaves have the hostname of the NIS master in
/etc/hosts and it now works. On buster, this must not have been an
issue, but obviously is a hard requirement for bullseye.

I guess the only remaining problem really is that yphelper seg faults if
the names are not in /etc/hosts, which is not ideal, but also now not a
show stopper for me.

Thank you for helping me.

I have noticed that if the /etc/hosts file does not have an entry for
local machine, then /usr/lib/yp/yphelper --hostname seg faults.

This is expressly mandatory in NIS configuration, as by documentation.
Every hostname used must be resolved at /etc/hosts level.
Anyway that should not cause a segfault but an error, indeed. That seems
an upstream issue (or several for each tool).

All the other trials could be a direct consequence of that.

The NIS master now looks to be operating correctly.

On one of the NIS slaves, I moved the domain directory /var/yp/domain
to a backup.

I then ran /usr/lib/yp/ypinit -s nameofnismaster and I get a
segmentation fault, followed by Can't enumerate maps from name>. Please check that it is running.

/usr/lib/yp/yphelVper --hostname runs successfully on the slave
/usr/lib/yp/yphelper --maps nameofnismaster seg faults

So I have made some progress. Please let me know if there is anything
else I can tell you.

Regards

Rob

On 12/05/2023 10:09, Francesco P. Lovergine wrote:

tags 1035967 + moreinfo unreproducible
thanks

Hi Rob,

I just verified with a fresh installation of bookworm and it
perfectly works. My
first hypothesis could be about a gdbm-related breakage. It is
somethig already

seen in the past and even annotatedi at sect.9 of the Debian HOWTO.
NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing
changes in file formats due to external conditions

(e.g. changes in compiler/optimizations/ecc.)

Could you plese run yptest on your serveri and send anomalies in
result?
Is this a single NIS master or do you have slaves ? Could you please
regenerate gdbm stuff by ypinit -m after cleaning up maps?

Anywyay, my next step will be preparing an upgrading box to test
bullseye->bookworm, stay tuned.

On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote:

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 libnsl2 1.3.0-2
ii libsystemd0 247.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 ucf 3.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

--
Certus Technology Associates Limited.
http://www.certus-tech.com
Tel: +44 (0)114 272 5081

Bug#1033167: usrmerge: messes with /etc/shells

On Sun, 19 Mar 2023 17:22:11 +0100 Helmut Grohne 
wrote:
> I've prepared an update for debianutils and tested it in the
> following
> cases:
>  * Installation on a pre-merged chroot -> /usr/bin/sh is added to
>/etc/shells.
>  * Installation on a chroot merged by usrmerge -> no difference
>  * Installation on an unmerged system. Manual merge without
>convert-etc-shells. Manual update-shells. -> Looks the same as
> after
>convert-etc-shells.
> 
> Does anyone see any bugs?

Not an expert in update-shells, but cannot see anything obviously wrong
with the patch. Only comment I'd make is maybe to split the latter half
of the changes, which seems unrelated and adding previously missing
quotes, in a different patch.

-- 
Kind regards,
Luca Boccassi


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

Bug#944488: Bump?

2023-05-12 Thread Markus

This would *really* be an improvement and the patch is already there... What 
else can I do to support you?
--  
Markus Grunwald

Bug#1036000: unblock: sniproxy/0.6.0-2.1

2023-05-12 Thread Peter Pentchev

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: snipr...@packages.debian.org, snipr...@packages.debian.org, 
r...@debian.org
Control: affects -1 + src:sniproxy

Please unblock package sniproxy

Version 0.6.0-2.1 fixes the #1033752 RC bug (grave, security)
about a buffer overflow that may lead to arbitrary code
execution. I am in the process of adopting the package
(see #1035759), and I'm in communication with Thorsten
Alteholz, who did the NMU to fix the bug.

[ Reason ]
Security issue, arbitrary code execution due to a buffer overflow.
See #1033752 for details.

[ Impact ]
Systems where sniproxy is used are currently vulnerable to
remote code execution.

[ Tests ]
The next upstream version of sniproxy, 0.6.1, that was
released with a single change - to fix this bug - and that
I will soon upload to experimental, contains a test case that
makes sure sniproxy does not die on such a malformed request:
https://github.com/dlundquist/sniproxy/commit/f8d9a433fe22ab2fa15c00179048ab02ae23d583#diff-e1a0a6ea76cf301ec1fc8564ca08c0a20ae7fdc14f27355ab77a217e09efd833
(the bad_dns_request_test change)
The patch includes this change, although the tests are not
run during the Debian package build or afterwards; however,
a manual `make check` in the package build directory will
show the test passing.

I intend to try to run those tests both during the build and
as autopkgtests.

[ Risks ]
The fix is straightforward (for someone familiar with network
programming in C) and targeted. IMHO the risks are minimal,
if any at all. 

[ 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 sniproxy/0.6.0-2.1

diff -Nru sniproxy-0.6.0/debian/changelog sniproxy-0.6.0/debian/changelog
--- sniproxy-0.6.0/debian/changelog 2020-07-23 23:27:57.0 +0300
+++ sniproxy-0.6.0/debian/changelog 2023-04-29 20:03:02.0 +0300
@@ -1,3 +1,11 @@
+sniproxy (0.6.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2023-25076 (Closes: #1033752)
+fix buffer overflow while handling wildcard backend hosts
+
+ -- Thorsten Alteholz   Sat, 29 Apr 2023 19:03:02 +0200
+
 sniproxy (0.6.0-2) unstable; urgency=medium
 
   * Fix "ftbfs with GCC-10" by applying patch
diff -Nru sniproxy-0.6.0/debian/patches/CVE-2023-25076.patch 
sniproxy-0.6.0/debian/patches/CVE-2023-25076.patch
--- sniproxy-0.6.0/debian/patches/CVE-2023-25076.patch  1970-01-01 
02:00:00.0 +0200
+++ sniproxy-0.6.0/debian/patches/CVE-2023-25076.patch  2023-04-29 
20:03:02.0 +0300
@@ -0,0 +1,71 @@
+commit f8d9a433fe22ab2fa15c00179048ab02ae23d583
+Author: Dustin Lundquist 
+Date:   Thu Mar 16 20:42:20 2023 -0700
+
+address: fix buffer overflow
+
+Update tests to work on Debian 11.
+
+Index: sniproxy-0.6.0/src/address.c
+===
+--- sniproxy-0.6.0.orig/src/address.c  2023-04-29 19:26:00.397699547 +0200
 sniproxy-0.6.0/src/address.c   2023-04-29 19:26:00.397699547 +0200
+@@ -143,6 +143,8 @@
+ if (hostname_or_ip[0] == '[' &&
+ (port = strchr(hostname_or_ip, ']')) != NULL) {
+ len = (size_t)(port - hostname_or_ip - 1);
++if (len >= INET6_ADDRSTRLEN)
++return NULL;
+ 
+ /* inet_pton() will not parse the IP correctly unless it is in a
+  * separate string.
+Index: sniproxy-0.6.0/tests/Makefile.am
+===
+--- sniproxy-0.6.0.orig/tests/Makefile.am  2023-04-29 19:26:00.397699547 
+0200
 sniproxy-0.6.0/tests/Makefile.am   2023-04-29 19:26:25.017710380 +0200
+@@ -1,5 +1,7 @@
+ AM_CPPFLAGS = -I$(top_srcdir)/src -g $(LIBEV_CFLAGS) $(LIBPCRE_CFLAGS) 
$(LIBUDNS_CFLAGS)
+ 
++.NOTPARALLEL:
++
+ TESTS = address_test \
+ buffer_test \
+ cfg_tokenizer_test \
+Index: sniproxy-0.6.0/tests/bad_dns_request_test
+===
+--- sniproxy-0.6.0.orig/tests/bad_dns_request_test 2023-04-29 
19:26:00.397699547 +0200
 sniproxy-0.6.0/tests/bad_dns_request_test  2023-04-29 19:26:00.397699547 
+0200
+@@ -36,6 +36,11 @@
+ client => \_client,
+ },
+ {
++# Exceed hostname buffer size
++request => "GET / HTTP/1.1\r\nHost: [" . 'long.' x 60 . 
"example.com]\r\n\r\n",
++client => \_client,
++},
++{
+ # Test client aborting connection before DNS response received
+ request => "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n",
+ client => \_client_abort,
+Index: sniproxy-0.6.0/tests/slow_client_test
+===
+--- sniproxy-0.6.0.orig/tests/slow_client_test 2023-04-29 19:26:00.397699547 
+0200
 sniproxy-0.6.0/tests/slow_client_test  2023-04-29 19:26:00.397699547

Bug#1035831: tech-ctte: Reinstate merged-/usr file movement moratorium

2023-05-12 Thread Helmut Grohne

On Tue, May 09, 2023 at 01:26:10PM -0700, Sean Whitton wrote:
> I call for votes on the following resolution.
> Voting lasts for one week or until the outcome is no longer in doubt.
> Let me take this opportunity to thank Helmut for all his recent work on
> this topic.
> 
> === BEGIN
> 
> OPTION A:
> 
> Under Constitution 6.1.5, the Technical Committee recommends that the
> maintainers of individual packages should not proactively move files
> from the root filesystem to corresponding locations under /usr in the
> data.tar.* of packages.  So, /foo/bar should not move to /usr/foo/bar.
> 
> Files that are in /usr in the Debian 12 release should remain in /usr,
> while files that are in /bin, /lib* or /sbin in the Debian 12 release
> should remain in those directories.  If any files are moved from /bin,
> /lib* or /sbin into /usr after the Debian 12 release, they should be
> moved back to their Debian 12 locations.
> 
> This moratorium lasts until we vote to repeal it.  We expect to do that
> during the trixie development cycle, and sooner rather than later.
> We will continue to facilitate efforts to resolve the remaining issues
> that stand in the way of safely repealing the moratorium.
> 
> OPTION B:
> 
> As option A, except that only maintainers of essential and transitively
> essential packages should refrain from proactively moving files from the
> root filesystem to corresponding locations under /usr in the data.tar.*
> of packages.
> 
> OPTION N:
> 
> None of the above.
> 
> === END

I vote A > B > N.

Rationale

I was initially very unhappy about extending the moratorium, because it
poses a significant mental cost to the entire project. I subsequently
proposed to limit it to essential packages to reduce the impact.
However, that would increase the complexity of the rule to follow and
the essential set isn't static either. If we were to move files in
bookworm already (which has not been proposed), we could easily break
systemd as systemd-resolved and systemd-boot both replace systemd and
that would become exactly a situation as the one to be prevented by the
moratorium. In the bullseye -> bookworm upgrade, we have about 13
situations that would have been broken (in a /usr-merged bullseye
upgraded to bookworm) in the absence of the moratorium. I think it is
reasonable to expect that we'd encounter a similar amount in trixie.

Helmut

signature.asc
Description: PGP signature

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

On Fri, 12 May 2023 at 13:21, Simon Richter  wrote:
>
> Hi,
>
> On 5/12/23 02:51, Luca Boccassi wrote:
>
> > 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.
>
> For the context of this bug, the notice *is* the after-the-fact
> documentation of an interface change, i.e. the bare minimum.
>
> It would have been better to get input from derived distributions about
> this interface change before it happened, but given that the interface
> change was not caused by a change in dpkg code, but by the introduction
> of the usrmerge package, there was not much of a remedy available then.

Not really? This notice is new, and suggests something that will make
the downstream irreparably incompatible with Debian, which I thought
was a big no-no.
If negatively affecting downstreams is a problem, this needs to be
reverted. If it's enough to say somewhere else "actually, that is bad
advice, if you follow it you are on your own", then that's fine too by
me, but then it's fine for other changes as well.

Kind regards,
Luca Boccassi

Bug#1035998: unblock: cinnamon-settings-daemon/5.6.2-2

2023-05-12 Thread Fabio Fantoni


Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: cinnamon-settings-dae...@packages.debian.org, 
fantonifa...@tiscali.it

Control: affects -1 + src:cinnamon-settings-daemon

Please unblock package cinnamon-settings-daemon

5.6.2-2 Remove broken symlinks to csd-locate-pointer and
csd-list-wacom that was removed in a previous upstream version
but I missed to remove also symlinks in packaging.

I think is good to have in bookworm.


[ Risks ]
I consider the risk of regression very small

[ 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 cinnamon-settings-daemon/5.6.2-2diff --git a/debian/changelog b/debian/changelog
index f843ec7..1e1e385 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+cinnamon-settings-daemon (5.6.2-2) unstable; urgency=medium
+
+  * Remove broken symlinks to csd-locate-pointer and csd-list-wacom
+Thanks to Andreas Beckmann (Closes: #1035860)
+
+ -- Fabio Fantoni   Wed, 10 May 2023 22:15:56 +0200
+
 cinnamon-settings-daemon (5.6.2-1) unstable; urgency=medium
 
   * New upstream bugfix version 5.6.2
diff --git a/debian/cinnamon-settings-daemon.links 
b/debian/cinnamon-settings-daemon.links
index a4091cb..bb49c47 100644
--- a/debian/cinnamon-settings-daemon.links
+++ b/debian/cinnamon-settings-daemon.links
@@ -8,7 +8,6 @@ 
usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-settings-daemon/csd-datetime-mechanism us
 usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-settings-daemon/csd-housekeeping 
usr/bin/csd-housekeeping
 usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-settings-daemon/csd-input-helper 
usr/bin/csd-input-helper
 usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-settings-daemon/csd-keyboard 
usr/bin/csd-keyboard
-usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-settings-daemon/csd-locate-pointer 
usr/bin/csd-locate-pointer
 usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-settings-daemon/csd-media-keys 
usr/bin/csd-media-keys
 usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-settings-daemon/csd-power 
usr/bin/csd-power
 usr/lib/${DEB_HOST_MULTIARCH}/cinnamon-settings-daemon/csd-printer 
usr/bin/csd-printer
diff --git a/debian/rules b/debian/rules
index 2d8df78..4db072e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,8 +20,7 @@ override_dh_link:
dh_link
 ifeq ($(DEB_HOST_ARCH_OS),linux)
 ifneq (${DEB_HOST_ARCH},s390x)
-   dh_link -p cinnamon-settings-daemon 
usr/lib/$(DEB_HOST_MULTIARCH)/cinnamon-settings-daemon/csd-list-wacom 
usr/bin/csd-list-wacom \
-   usr/lib/$(DEB_HOST_MULTIARCH)/cinnamon-settings-daemon/csd-wacom 
usr/bin/csd-wacom
+   dh_link -p cinnamon-settings-daemon 
usr/lib/$(DEB_HOST_MULTIARCH)/cinnamon-settings-daemon/csd-wacom 
usr/bin/csd-wacom
 endif
 endif

Bug#1035794: debian-security-support: Please mark wpewebkit as unsupported in bookworm

control: clone -1 -2
control: retitle -2 "mark wpewebkit unsupported in bullseye once bullseye 
becomes LTS"
thanks

On Fri, May 12, 2023 at 12:06:59PM +, Alberto Garcia wrote:
> > > Note that wpewebkit is still supported in bullseye and will remain
> > > supported until the distro reaches EOL.
> > does that mean when the Debian security stops supporting bullseye
> Yes, that one (summer 2024). After that if it keeps building I can
> prepare the uploads for LTS if there's interest but I won't handle the
> DLAs myself (we are doing exactly that for WebKitGTK in buster).

ok, thanks!


-- 
cheers,
Holger

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

First they came for the journalists, we don't know what happened after that.


signature.asc
Description: PGP signature

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

2023-05-12 Thread Francesco P. Lovergine

On Fri, May 12, 2023 at 01:01:24PM +0100, Robert Pumphrey wrote:

Thank you for the fast response.

On the NIS master, I have moved the domain directory /var/yp/domain to
a backup.

I then ran /usr/lib/yp/ypinit -m and added the IP addresses of the NIS
slaves. This ran successfully.

/usr/lib/yp/yphelper --hostname runs successfully on the master.

/usr/lib/yp/yphelper --maps nameofnismaster runs successfully on the
master and gives a list of maps.

This is quite strange, because in moving from bullseye to bookworm
no chages in the binary gdbm files have been required in my test.
Test done after generating maps in bullseye.
Are your current maps older than that?

Even, I'm assuming you are on a amd64 arch.

I have noticed that if the /etc/hosts file does not have an entry for
local machine, then /usr/lib/yp/yphelper --hostname seg faults.

All the other trials could be a direct consequence of that.

The NIS master now looks to be operating correctly.

On one of the NIS slaves, I moved the domain directory /var/yp/domain
to a backup.

I then ran /usr/lib/yp/ypinit -s nameofnismaster and I get a
segmentation fault, followed by Can't enumerate maps from name>. Please check that it is running.

/usr/lib/yp/yphelVper --hostname runs successfully on the slave
/usr/lib/yp/yphelper --maps nameofnismaster seg faults

So I have made some progress. Please let me know if there is anything
else I can tell you.

Regards

Rob

On 12/05/2023 10:09, Francesco P. Lovergine wrote:

tags 1035967 + moreinfo unreproducible
thanks

Hi Rob,

I just verified with a fresh installation of bookworm and it
perfectly works. My
first hypothesis could be about a gdbm-related breakage. It is
somethig already

seen in the past and even annotatedi at sect.9 of the Debian HOWTO.
NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing
changes in file formats due to external conditions

(e.g. changes in compiler/optimizations/ecc.)

Could you plese run yptest on your serveri and send anomalies in result?
Is this a single NIS master or do you have slaves ? Could you please
regenerate gdbm stuff by ypinit -m after cleaning up maps?

Anywyay, my next step will be preparing an upgrading box to test
bullseye->bookworm, stay tuned.

On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote:

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

--
Certus Technology Associates Limited.
http://www.certus-tech.com
Tel: +44 (0)114 272 5081

--
Francesco P. Lovergine

Bug#953997: obsolete conffiles after upgrade

2023-05-12 Thread Andrea Bolognani

So, this affected upgrades from buster (libvirt 5.0.0) to bullseye
(libvirt 7.0.0).

We're now about to release bookworm (libvirt 9.0.0) and the
rm_conffile snippet is not even present in the package anymore.

I think at this point we can assume that most people who have hit the
issue on upgrade will have cleaned things up manually by now, so I'd
be inclined to close the bug and move on.

Any objections?

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

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

2023-05-12 Thread Simon Richter


Hi,

On 5/12/23 02:51, Luca Boccassi wrote:


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.


For the context of this bug, the notice *is* the after-the-fact 
documentation of an interface change, i.e. the bare minimum.


It would have been better to get input from derived distributions about 
this interface change before it happened, but given that the interface 
change was not caused by a change in dpkg code, but by the introduction 
of the usrmerge package, there was not much of a remedy available then.


   Simon

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

On Fri, 12 May 2023 at 12:08, Steve McIntyre  wrote:
>
> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre  wrote:
> >>>
> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >>> >
> >>> >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.
> >>>
> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've
> >>> seen. The interpreter must *not* be changed willy-nilly.
> >>
> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of
> >>seemingly crazy options, as in, "what would _actually_ explode if we
> >>do this or do that?", on this very d-devel thread. I posted a longer
> >>version here some days ago:
> >>
> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html
> >
> >Oh holy fuck.
> >
> >You're talking about changing ABI by doing this. That *is* utterly
> >crazy. No.
>
> People have asked me to expand on this further...
>
> I've been involved in defining ABI before, specifically for
> armhf. It's not a quick and easy process. It needs buy-in from all
> sides to make things work, and people *really* value the
> interoperability that it enables.
>
> The interpreter path is one of the most important parts of the ABI
> spec, the bit that makes binaries compatible between all the various
> stakeholders: compiler/tools people, distros, software vendors,
> etc. Lots of the rest of the details downstream of this can be
> changed, and people do this all the time - compare multilib to
> multi-arch for example. That all works fine *so long as* the runtime
> linker can be located and started OK.

The loader is still available via the old path, so external/third
party/local/other software works unchanged. This should negatively
only affect our 1st party packages, when running on a non-merged
distro.
And are _all_ our packages really 100% compatible with other distros
at all? Are they even supposed to be?

For example, if I download efibootmgr from Bookworm on an Ubuntu Focal
machine, when I try to run it, it fails:

root@focal:/tmp# wget
http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
--2023-05-12 12:46:17--
http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb
Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4
Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 27572 (27K) [application/vnd.debian.binary-package]
Saving to: 'efibootmgr_17-2_amd64.deb'

efibootmgr_17-2_amd64.deb
100%[===>]  26.93K
--.-KB/sin 0.04s

2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved [27572/27572]

root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm
root@focal:/tmp# ./ebm/bin/efibootmgr
./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version
`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr)

Should I file a severity: serious bug against efibootmgr because it is
not interoperable?

The answer is obviously not, because it would be absurd to expect a
binary compiled against libraries from one distro to "just work" on an
entirely different distro. Glibc itself is not forward compatible, and
is allowed to add new symbols, that are not present in older versions,
and packages are allowed to depend on them. Aren't those also ABI
breakages? What about all the libraries that bump soname? What about
binaries that rely on newer kernel interfaces, or IPC interfaces?

So, what I am asking is, what actual, real difference does it make if,
by default (and with an override available for example), packages
built on Debian for Debian record the ld path to point to its (actual)
location on Debian, via say a compiler spec file that is injected in a
deb build?
There very likely is some real difference and impact, and I am
genuinely and honestly asking what it could be. If nothing else, it's
an interesting topic, even if likely nothing comes out of it.

> Changing the interpreter path would mean moving to a Debian-specific
> ABI, breaking that compatibility. Hand-waving that away with (and I
> quote):
>
>   "The vast majority of distros today ship the loader in /usr/lib as
>   /lib is just a symlink, so it would be interoperable."
>
> is appalling arrogance. No. You do *not* get to break ABI with that
> argument. The point of the ABI spec is that *everybody* follows
> it. You don't change it just because you think it'll make your life a
> little easier when bootstrapping a system.

AFAIK there are at least 3 distros where the default interpreter path
is changed to follow distro-specific customizations: Gentoo, Nix,
Guix. So evidently, some people *do* get to "break

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

2023-05-12 Thread Robert Pumphrey

Thank you for the fast response.

On the NIS master, I have moved the domain directory /var/yp/domain to a
backup.

I then ran /usr/lib/yp/ypinit -m and added the IP addresses of the NIS
slaves. This ran successfully.

/usr/lib/yp/yphelper --hostname runs successfully on the master.

/usr/lib/yp/yphelper --maps nameofnismaster runs successfully on the
master and gives a list of maps.

I have noticed that if the /etc/hosts file does not have an entry for
local machine, then /usr/lib/yp/yphelper --hostname seg faults.

The NIS master now looks to be operating correctly.

On one of the NIS slaves, I moved the domain directory /var/yp/domain to
a backup.

I then ran /usr/lib/yp/ypinit -s nameofnismaster and I get a
segmentation fault, followed by Can't enumerate maps from name>. Please check that it is running.

/usr/lib/yp/yphelper --hostname runs successfully on the slave
/usr/lib/yp/yphelper --maps nameofnismaster seg faults

So I have made some progress. Please let me know if there is anything
else I can tell you.

Regards

Rob

On 12/05/2023 10:09, Francesco P. Lovergine wrote:

tags 1035967 + moreinfo unreproducible
thanks

Hi Rob,

I just verified with a fresh installation of bookworm and it perfectly
works. My
first hypothesis could be about a gdbm-related breakage. It is
somethig already

seen in the past and even annotatedi at sect.9 of the Debian HOWTO.
NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing changes
in file formats due to external conditions

(e.g. changes in compiler/optimizations/ecc.)

Could you plese run yptest on your serveri and send anomalies in result?
Is this a single NIS master or do you have slaves ? Could you please
regenerate gdbm stuff by ypinit -m after cleaning up maps?

Anywyay, my next step will be preparing an upgrading box to test
bullseye->bookworm, stay tuned.

On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote:

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

--
Certus Technology Associates Limited.
http://www.certus-tech.com
Tel: +44 (0)114 272 5081

Bug#1035794: debian-security-support: Please mark wpewebkit as unsupported in bookworm

2023-05-12 Thread Alberto Garcia

On Fri, May 12, 2023 at 08:27:49AM +, Holger Levsen wrote:
> > Note that wpewebkit is still supported in bullseye and will remain
> > supported until the distro reaches EOL.
> does that mean when the Debian security stops supporting bullseye

Yes, that one (summer 2024). After that if it keeps building I can
prepare the uploads for LTS if there's interest but I won't handle the
DLAs myself (we are doing exactly that for WebKitGTK in buster).

Berto

Bug#1035899: org.gnome.Shell.desktop[…]: Unrecognized option: -initfd

2023-05-12 Thread Simon McVittie

On Wed, 10 May 2023 at 20:35:14 +, Al Ma wrote:
> Package: gnome-shell
> Version: 42.3.1-2
...
> Here are the versions of some relevant installed packages:
> 1:7.7+23, xserver-xorg 1:7.7+23, xserver-xorg-core 2:1.20.11-1+deb11u6,
> and xwayland 2:1.20.11-1+deb11u6.

You're mixing (outdated) packages from Debian testing/unstable with
packages from stable, which is not something that can ever be considered
fully supported: there is a nearly unlimited number of possible
combinations of packages, and it is not feasible to test them all.

gnome-shell 43.4-1 is the current version in testing/unstable. 42.3.1-2
is a version from July 2022.

The bug here is that whichever package passes -initfd to Xwayland
(actually libmutter rather than gnome-shell) should have an explicit
dependency on a version of xwayland that has that option. That can
be fixed in a newer version of libmutter (perhaps it already was, I
haven't checked yet), but if you are not upgrading GNOME packages like
gnome-shell from version 42 to the current version in testing/unstable,
then you will never receive a fixed version.

smcv

Bug#1035996: unblock: apache-log4j-extras1.2/1.2.17-3

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: apache-log4j-extras...@packages.debian.org
Control: affects -1 + src:apache-log4j-extras1.2

Please unblock package apache-log4j-extras1.2

This package currently fails to build due to a javadoc (#1035992). This
update removes the unused -java-doc package which is causing this issue.

Thank you,

Emmanuel Bourg

unblock apache-log4j-extras1.2/1.2.17-3
diff --git a/debian/changelog b/debian/changelog
index 0c2656b..8cc7f9e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+apache-log4j-extras1.2 (1.2.17-3) unstable; urgency=medium
+
+  * Removed the -java-doc package (Closes: #1035992)
+  * Use salsa.debian.org Vcs-* URLs
+
+ -- Emmanuel Bourg   Fri, 12 May 2023 12:34:54 +0200
+
 apache-log4j-extras1.2 (1.2.17-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 6bbaa8a..8eefd91 100644
--- a/debian/control
+++ b/debian/control
@@ -6,34 +6,22 @@ Uploaders: Hilko Bengen 
 Build-Depends:
  debhelper (>= 10),
  default-jdk,
- default-jdk-doc,
  libapache-pom-java (>= 10),
  libgeronimo-jms-1.1-spec-java,
  libhsqldb-java,
  liblog4j1.2-java (>= 1.2.17-6~),
- liblog4j1.2-java-doc,
  libmaven-bundle-plugin-java,
- libmaven-javadoc-plugin-java,
  maven-debian-helper (>= 2.2)
 Standards-Version: 4.1.0
-Vcs-Git: https://anonscm.debian.org/git/pkg-java/apache-log4j-extras1.2.git
-Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-java/apache-log4j-extras1.2.git
+Vcs-Git: https://salsa.debian.org/java-team/apache-log4j-extras1.2.git
+Vcs-Browser: https://salsa.debian.org/java-team/apache-log4j-extras1.2
 Homepage: http://logging.apache.org/log4j/extras
 
 Package: liblog4j-extras1.2-java
 Architecture: all
 Depends: ${misc:Depends}, ${maven:Depends}
-Suggests: ${maven:OptionalDepends}, liblog4j-extras1.2-java-doc
+Suggests: ${maven:OptionalDepends}
 Description: Extras for Apache log4j
  This package provides additional appenders, filters and other capabilities
  for version 1.2 of Apache log4j. Several of these were backported from
  the abandoned log4j 1.3 development effort.
-
-Package: liblog4j-extras1.2-java-doc
-Architecture: all
-Section: doc
-Depends: ${misc:Depends}
-Recommends: ${maven:DocDepends}, ${maven:DocOptionalDepends}
-Suggests: liblog4j-extras1.2-java
-Description: Documentation for Extras for Apache log4j.
- This package contains the API documentation of liblog4j-extras1.2-java.

Bug#1035759: ITA: sniproxy -- Transparent TLS and HTTP layer 4 proxy with SNI support

2023-05-12 Thread Peter Pentchev

control: retitle -1 ITA: sniproxy -- Transparent TLS and HTTP layer 4 proxy 
with SNI support
control: owner -1 !

Thanks for your work on sniproxy over the years!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

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

2023-05-12 Thread Julian Gilbey

On Fri, May 12, 2023 at 11:54:30AM +0200, Pierre-Elliott Bécue wrote:
> Julian Gilbey  wrote on 12/05/2023 at 11:39:33+0200:
> [...]
> > Hi Pierre-Elliott,
> >
> > Thanks so much for the quick response, that's really helpful!
> >
> > Unfortunately, this doesn't seem to be the issue, though:
> > [...]

Hi Pierre-Elliott,

Thanks!  :-)

> What do you have in /etc/lxc/lxc-usernet ?

jdg veth lxcbr0 10

(But I'm trying to start the container as root, having su'd from jdg,
in case that's relevant.  And I have the subuid/subgid set up
correctly.)

> Also, what is your container config, please?

I assume you mean /var/lib/lxc/debian-sid/config?  Here's the content
of this file:

# Template used to create this container: /usr/share/lxc/templates/lxc-download
# Parameters passed to the template: -d debian -r sid -a amd64
# For additional config options, please look at lxc.container.conf(5)

# Uncomment the following line to support nesting containers:
#lxc.include = /usr/share/lxc/config/nesting.conf
# (Be aware this has security implications)


# Distribution configuration
lxc.include = /usr/share/lxc/config/common.conf
lxc.arch = linux64

# Container specific configuration
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
lxc.rootfs.path = dir:/var/lib/lxc/debian-sid/rootfs
lxc.uts.name = debian-sid

# Network configuration
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up


As a non-expert, this looks fine, but there may be something awry
here.  I've had numerous lxc problems with my machine, and have no
idea why :(

Best wishes,

   Julian

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

On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote:
>On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
>>On Fri, 12 May 2023 at 09:40, Steve McIntyre  wrote:
>>>
>>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>>> >
>>> >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.
>>>
>>> WTF? *Nobody* has been talking about breaking ABI like this, that I've
>>> seen. The interpreter must *not* be changed willy-nilly.
>>
>>Nothing's happening 'willy-nilly'. We are discussing a bunch of
>>seemingly crazy options, as in, "what would _actually_ explode if we
>>do this or do that?", on this very d-devel thread. I posted a longer
>>version here some days ago:
>>
>>https://lists.debian.org/debian-gcc/2023/05/msg00030.html
>
>Oh holy fuck.
>
>You're talking about changing ABI by doing this. That *is* utterly
>crazy. No.

People have asked me to expand on this further...

I've been involved in defining ABI before, specifically for
armhf. It's not a quick and easy process. It needs buy-in from all
sides to make things work, and people *really* value the
interoperability that it enables.

The interpreter path is one of the most important parts of the ABI
spec, the bit that makes binaries compatible between all the various
stakeholders: compiler/tools people, distros, software vendors,
etc. Lots of the rest of the details downstream of this can be
changed, and people do this all the time - compare multilib to
multi-arch for example. That all works fine *so long as* the runtime
linker can be located and started OK.

Changing the interpreter path would mean moving to a Debian-specific
ABI, breaking that compatibility. Hand-waving that away with (and I
quote):

  "The vast majority of distros today ship the loader in /usr/lib as
  /lib is just a symlink, so it would be interoperable."

is appalling arrogance. No. You do *not* get to break ABI with that
argument. The point of the ABI spec is that *everybody* follows
it. You don't change it just because you think it'll make your life a
little easier when bootstrapping a system.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#1035995: bazel-bootstrap: Depend on libgeronimo-annotation-1.3-spec-java instead of libtomcat9-java

Package: bazel-bootstrap
Version: 4.2.3+ds-8
Severity: serious

bazel-bootstrap depends on libtomcat9-java, only to use 
tomcat9-annotations-api.jar
which provides the javax.annotations package. Since libtomcat9-java is about
to be removed this needs to be replaced.

libtomcat10-java provides a new version of the annotations API but under
the jakarta.annotation package. It would involve patching bazel-bootstrap 
heavily.

The javax.annotations package is also provided by 
libgeronimo-annotation-1.3-spec-java,
it could be used as a replacement.

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

On Fri, 12 May 2023 at 11:40, Steve McIntyre  wrote:
>
> On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
> >On Fri, 12 May 2023 at 09:40, Steve McIntyre  wrote:
> >>
> >> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >> >
> >> >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.
> >>
> >> WTF? *Nobody* has been talking about breaking ABI like this, that I've
> >> seen. The interpreter must *not* be changed willy-nilly.
> >
> >Nothing's happening 'willy-nilly'. We are discussing a bunch of
> >seemingly crazy options, as in, "what would _actually_ explode if we
> >do this or do that?", on this very d-devel thread. I posted a longer
> >version here some days ago:
> >
> >https://lists.debian.org/debian-gcc/2023/05/msg00030.html
>
> Oh holy fuck.
>
> You're talking about changing ABI by doing this. That *is* utterly
> crazy. No.

It's a thought experiment on a mailing list. If we can't even have
those anymore, something went very wrong somewhere.

You seem to be aware of things that wouldn't work anymore (I think?).
If you have a couple of minutes to spare, may I please ask you to
reply to that thread with such examples? I am genuinely interested in
understanding and talking about it. Thank you.

Kind regards,
Luca Boccassi

Bug#1035994: heat-cfntools: package is missing main module 'heat_cfntools'

2023-05-12 Thread Benoit Plessis

Package: heat-cfntools
Version: 1.4.2-2.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The package only include the stubs executables and lack the main modules 
required to function:

# /usr/bin/cfn-init
Traceback (most recent call last):
  File "/usr/bin/cfn-init", line 22, in 
from heat_cfntools.cfntools import cfn_helper
ModuleNotFoundError: No module named 'heat_cfntools'

# dpkg -L heat-cfntools
/.
/usr
/usr/bin
/usr/bin/cfn-create-aws-symlinks
/usr/bin/cfn-get-metadata
/usr/bin/cfn-hup
/usr/bin/cfn-init
/usr/bin/cfn-push-stats
/usr/bin/cfn-signal
/usr/share
/usr/share/doc
/usr/share/doc/heat-cfntools
/usr/share/doc/heat-cfntools/changelog.Debian.gz
/usr/share/doc/heat-cfntools/changelog.gz
/usr/share/doc/heat-cfntools/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/cfn-create-aws-symlinks.1.gz
/usr/share/man/man1/cfn-get-metadata.1.gz
/usr/share/man/man1/cfn-hup.1.gz
/usr/share/man/man1/cfn-init.1.gz
/usr/share/man/man1/cfn-push-stats.1.gz
/usr/share/man/man1/cfn-signal.1.gz

And the package doesn't include dependencies that would solve that:

Depends: python3-boto (>= 2.12.0), python3-pbr (>= 0.6), python3-psutil (>= 
1.1.1), python3:any

-- 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-21-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages heat-cfntools depends on:
ii  python3 3.9.2-3
ii  python3-boto2.49.0-3
ii  python3-pbr 5.5.0-2
ii  python3-psutil  5.8.0-1

heat-cfntools recommends no packages.

heat-cfntools suggests no packages.

-- debconf-show failed

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

On Fri, 12 May 2023 at 06:01, Johannes Schauer Marin Rodrigues
 wrote:
>
> 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.

Good find, thanks!

Kind regards,
Luca Boccassi

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

On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
>On Fri, 12 May 2023 at 09:40, Steve McIntyre  wrote:
>>
>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>> >
>> >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.
>>
>> WTF? *Nobody* has been talking about breaking ABI like this, that I've
>> seen. The interpreter must *not* be changed willy-nilly.
>
>Nothing's happening 'willy-nilly'. We are discussing a bunch of
>seemingly crazy options, as in, "what would _actually_ explode if we
>do this or do that?", on this very d-devel thread. I posted a longer
>version here some days ago:
>
>https://lists.debian.org/debian-gcc/2023/05/msg00030.html

Oh holy fuck.

You're talking about changing ABI by doing this. That *is* utterly
crazy. No.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead

Bug#1035993: unblock: biojava-live/1:1.9.5+dfsg-3

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

Please unblock package biojava-live

It holds an unused dependency on libcommons-dbcp-java-doc which blocks
the transition of libcommons-dbcp-java/1.4-8 to testing. This is required
to complete the migration to Tomcat 10.

Thank you,

Emmanuel Bourg

unblock biojava-live/1:1.9.5+dfsg-3
diff --git a/debian/changelog b/debian/changelog
index 0c4726b..8878215 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+biojava-live (1:1.9.5+dfsg-3) unstable; urgency=medium
+
+  * Team upload.
+  * Removed the dependency on libcommons-dbcp-java-doc
+
+ -- Emmanuel Bourg   Fri, 12 May 2023 11:09:08 +0200
+
 biojava-live (1:1.9.5+dfsg-2) unstable; urgency=medium
 
   * Upload to unstable to start transition from libbiojava1.7-java to
diff --git a/debian/control b/debian/control
index 7ff66a2..ee197a4 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,6 @@ Build-Depends: debhelper-compat (= 13),
 Build-Depends-Indep: default-jdk,
  junit4 ,
  libcommons-dbcp-java,
- libcommons-dbcp-java-doc,
  libjaxb-api-java,
  libjgrapht0.8-java,
  libjgrapht0.8-java-doc,

Bug#1035992: apache-log4j-extras1.2: Error while generating Javadoc: Unable to write 'options' temporary file

Source: apache-log4j-extras1.2
Version: 1.2.17-2
Severity: serious
Tags: ftbfs

apache-log4j-extras1.2 fails to build with the following error:

  [INFO] 

  [INFO] BUILD FAILURE
  [INFO] 

  [INFO] Total time:  3.437 s
  [INFO] Finished at: 2023-05-12T10:19:16Z
  [INFO] 

  [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:jar (default-cli) on 
project apache-log4j-extras: MavenReportException: Error while generating 
Javadoc: Unable to write 'options' temporary file for command execution: Input 
length = 1 -> [Help 1]
  [ERROR]

Bug#1035991: ITP: fonts-chomsky -- New York Times masthead, reimagined as a full font

2023-05-12 Thread Gürkan Myczko


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

* Package name: fonts-chomsky
  Version : 2.3+ds
  Upstream Authors: Fredrick R. Brennan 
  URL : https://github.com/ctrlcctrlv/chomsky
* License : OFL-1.1
  Description : New York Times masthead, reimagined as a full font
 This is Chomsky, a newspaper masthead font in the style of the New York 
Times

 masthead.

Bug#1035960: All of sudden, the Spanish PO debconf templates is getting full of alien translators :-)

2023-05-12 Thread Cyril Brulebois

Cyril Brulebois  (2023-05-12):
> I'll keeping looking at what's supposed to happen on tye, but I'm not
> sure I'll be able to get to the bottom of it on my own.

At least there's a HUGE red flag on tye. Load to the roof, RAM/swap
almost full, lots of dl10n-spider processes running for the same
language, some of them started May 9th.

kibi@tye:~$ uptime
 10:02:58 up 12 days, 21:47,  2 users,  load average: 63.24, 64.57, 66.51

kibi@tye:~$ free -h
   totalusedfree  shared  buff/cache   
available
Mem:   1.9Gi   1.7Gi69Mi   1.0Mi   125Mi
57Mi
Swap:  511Mi   511Mi   0.0Ki

kibi@tye:~$ ps faux|grep dl10n-spider|grep -o -- '--check-bts ..'|sort|uniq 
-c
  4 --check-bts ca
  1 --check-bts cs
  1 --check-bts da
 51 --check-bts de
  7 --check-bts es
  2 --check-bts fr

kibi@tye:~$ ps faux|awk '/CRON/ {print $9}'|sort|uniq -c
 11 May09
 23 May10
 23 May11
  1 00:15
  1 02:15
  1 03:15
  1 04:15
  1 05:15
  1 06:15
  1 07:15
  1 08:13
  1 08:15
  1 09:15
  2 10:00
  1 10:01

Note that many de.po occurrences appear in the status file for other
languages, looks like processes heavily stomping onto others' feet?


It looks to me there should be some locking at the very least to avoid
that amount of concurrency. And that it would probably be best to start
afresh, killing all those processes, maybe disabling the cron jobs,
cleaning temporary and maybe corrupted data files, and triggering a
single run manually to see if it works.

But then, I have 0 knowledge about the spider, and I'll leave that up to
someone else: I don't want to risk making the matter worse!


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


signature.asc
Description: PGP signature

Bug#1035990: isc-dhcp-relay upgrade empty value of /etc/default/isc-dhcp-relay OPTIONS= line

2023-05-12 Thread Laurent GUERBY

Package: isc-dhcp-relay
Version: 4.4.3-P1-2
Severity: important

Hi,

This morning debian bookworm unattended-upgrades updated isc-dhcp-relay 
to 4.4.3-P1-2

This upgrade changed our /etc/default/isc-dhcp-relay as follows:


@@ -13,4 +13,4 @@
 INTERFACES="eth0.31 eth0.32"
 
 # Additional options that are passed to the DHCP relay daemon?
-OPTIONS="-iu eth0.16"
+OPTIONS=""

=> it emptied the value of OPTIONS, restarted isc-dhcp-relay and broke
DHCP on our network since -iu is necessary there.

The package postinst script does the following:

db_get isc-dhcp-relay/options || true
OPTIONS="${RET}"

TMPFILE=`mktemp -q /tmp/dhcp.config.XX`
sed -e "s/^[[:space:]]*OPTIONS[[:space:]]*=.*/OPTIONS=\"${OPTIONS}\"/"
\
<${INITCONFFILE} >${TMPFILE}
cp ${TMPFILE} ${INITCONFFILE}
rm ${TMPFILE}

Does not seem suspicious to me but I'm no .deb expert.

I don't know if this issue is specific to this version upgrade or if it
was there before.

Thanks for your help,

Sincerely,

Laurent

Bug#1035989: unblock: uima-as/2.3.1-11

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

Please unblock package uima-as

This package depends on libcommons-dbcp-java-doc which has been removed
in unstable. It blocks the migration of libcommons-dbcp-java/1.4-8 to
testing which is required to complete the transition to Tomcat 10.

This issue is addressed by removing the libuima-as-java-doc package
and its dependencies, including libcommons-dbcp-java-doc. The package
is unused and has a very low popcon.

Thank you,

Emmanuel Bourg


unblock uima-as/2.3.1-11
diff --git a/debian/changelog b/debian/changelog
index fc72c25..6a098db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+uima-as (2.3.1-11) unstable; urgency=medium
+
+  * Team upload.
+  * Removed the -java-doc package
+
+ -- Emmanuel Bourg   Fri, 12 May 2023 11:00:53 +0200
+
 uima-as (2.3.1-10) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index f2eebe1..130b247 100644
--- a/debian/control
+++ b/debian/control
@@ -14,14 +14,10 @@ Build-Depends:
  libbuild-helper-maven-plugin-java,
  libcommons-httpclient-java,
  libcommons-codec-java,
- libcommons-codec-java-doc,
  libcommons-dbcp-java,
- libcommons-dbcp-java-doc,
  libcommons-logging-java,
- libcommons-logging-java-doc,
  libcommons-net-java,
  libcommons-pool-java,
- libcommons-pool-java-doc,
  libgeronimo-j2ee-connector-1.5-spec-java,
  libgeronimo-j2ee-management-1.1-spec-java,
  libgeronimo-jms-1.1-spec-java,
@@ -30,7 +26,6 @@ Build-Depends:
  libmaven-bundle-plugin-java,
  libmaven-dependency-plugin-java,
  libmaven-install-plugin-java,
- libmaven-javadoc-plugin-java,
  libservlet-api-java,
  libspring-beans-java,
  libspring-context-java,
@@ -76,31 +71,3 @@ Description: Apache UIMA Asynch Scaleout framework
  .
  UIMA Asynch Scaleout (or UIMA AS) is an extension to the Apache UIMA
  framework and SDK, using JMS messaging to support scaleout.
-
-Package: libuima-as-java-doc
-Architecture: all
-Section: doc
-Depends:
- ${maven:DocDepends},
- ${misc:Depends}
-Recommends:
- ${maven:DocOptionalDepends}
-Suggests:
- libuima-as-java
-Description: Documentation for Apache UIMA Asynch Scaleout framework
- Apache UIMA is an implementation of the OASIS-UIMA specifications.
- .
- OASIS UIMA Committee: .
- .
- Unstructured Information Management applications are software systems
- that analyze large volumes of unstructured information in order to
- discover knowledge that is relevant to an end user.
- .
- An example UIM application might ingest plain text and identify
- entities, such as persons, places, organizations; or relations,
- such as works-for or located-at.
- .
- UIMA Asynch Scaleout (or UIMA AS) is an extension to the Apache UIMA
- framework and SDK, using JMS messaging to support scaleout.
- .
- This package contains the API documentation of libuima-as-java.
diff --git a/debian/libuima-as-java-doc.doc-base.api 
b/debian/libuima-as-java-doc.doc-base.api
deleted file mode 100644
index 78dde26..000
--- a/debian/libuima-as-java-doc.doc-base.api
+++ /dev/null
@@ -1,10 +0,0 @@
-Document: libuima-as-java
-Title: API Javadoc for UIMA AS: uima-as
-Author: UIMA AS: uima-as developers
-Abstract: This is the API Javadoc provided for the
- libuima-as-java library.
-Section: Programming
-
-Format: HTML
-Index: /usr/share/doc/libuima-as-java/api/index.html
-Files: /usr/share/doc/libuima-as-java/api/*
diff --git a/debian/libuima-as-java-doc.install 
b/debian/libuima-as-java-doc.install
deleted file mode 100644
index 00bb763..000
--- a/debian/libuima-as-java-doc.install
+++ /dev/null
@@ -1 +0,0 @@
-uima-as/target/site/apidocs/* usr/share/doc/libuima-as-java/api
diff --git a/debian/maven.ignoreRules b/debian/maven.ignoreRules
index 5192976..88393c4 100644
--- a/debian/maven.ignoreRules
+++ b/debian/maven.ignoreRules
@@ -31,4 +31,5 @@ xmlpull xmlpull * * * *
 org.springframework spring-asm * * * *
 
 org.apache.maven.plugins maven-deploy-plugin * * * *
+org.apache.maven.plugins maven-javadoc-plugin * * * *
 org.apache.rat apache-rat-plugin * * * *

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

2023-05-12 Thread Pierre-Elliott Bécue

Julian Gilbey  wrote on 12/05/2023 at 11:39:33+0200:

> On Thu, May 11, 2023 at 11:59:41PM +0200, Pierre-Elliott Bécue wrote:
>> 
>> Julian Gilbey  wrote on 11/05/2023 at 16:41:46+0200:
>> [...]
>> > 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:
>> > [...]
>
>> > 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.
>
> Hi Pierre-Elliott,
>
> Thanks so much for the quick response, that's really helpful!
>
> Unfortunately, this doesn't seem to be the issue, though:
>
> # systemctl status lxc-net.service 
> ● lxc-net.service - LXC network bridge setup
>  Loaded: loaded (/lib/systemd/system/lxc-net.service; enabled; preset: 
> enab>
>  Active: active (exited) since Thu 2023-05-11 20:35:48 BST; 13h ago
>Docs: man:lxc
> Process: 81843 ExecStart=/usr/libexec/lxc/lxc-net start (code=exited, 
> statu>
>Main PID: 81843 (code=exited, status=0/SUCCESS)
>   Tasks: 1 (limit: 76868)
>  Memory: 1.3M
> CPU: 70ms
>  CGroup: /system.slice/lxc-net.service
>  └─81884 dnsmasq --conf-file=/dev/null -u dnsmasq --strict-order 
> -->
>
> May 11 20:35:48 euler systemd[1]: Starting lxc-net.service - LXC network 
> bridge>
> May 11 20:35:48 euler dnsmasq[81884]: started, version 2.89 cachesize 150
> May 11 20:35:48 euler dnsmasq[81884]: compile time options: IPv6 GNU-getopt 
> DBu>
> May 11 20:35:48 euler dnsmasq-dhcp[81884]: DHCP, IP range 10.0.3.2 -- 
> 10.0.3.25>
> May 11 20:35:48 euler dnsmasq-dhcp[81884]: DHCP, sockets bound exclusively to 
> i>
> May 11 20:35:48 euler dnsmasq[81884]: reading /etc/resolv.conf
> May 11 20:35:48 euler dnsmasq[81884]: using nameserver 10.0.0.243#53
> May 11 20:35:48 euler dnsmasq[81884]: read /etc/hosts - 7 names
> May 11 20:35:48 euler systemd[1]: Finished lxc-net.service - LXC network 
> bridge>
>
> And with some details snipped:
>
> # ifconfig 
> enp5s0: flags=4163  mtu 1500
> inet [...]  netmask 255.255.255.0  broadcast 192.168.0.255
> inet6 [...]  prefixlen 64  scopeid 0x20
> ether [...]  txqueuelen 1000  (Ethernet)
> [...]
>
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> [...]
>
> lxcbr0: flags=4099  mtu 1500
> inet 10.0.3.1  netmask 255.255.255.0  broadcast 10.0.3.255
> ether 00:16:3e:00:00:00  txqueuelen 1000  (Ethernet)
> RX packets 0  bytes 0 (0.0 B)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 0  bytes 0 (0.0 B)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
> tun0: [...]
>
> wlp3s0: [...]
>
>
> # bridge vlan show
> port  vlan-id  
> lxcbr01 PVID Egress Untagged
>
>
>
> So lxc-net was established, and it still didn't work :(  (And yes,
> I've just checked that lxc-start still fails.)  But maybe the bridge
> is meant to be in the lxc container itself?
>
>
> So I'm still totally stumped.
>
> Any further ideas/suggestions/things to check would be welcomely
> received!
>
> Best wishes,

What do you have in /etc/lxc/lxc-usernet ?

Also, what is your container config, please?
-- 
PEB


signature.asc
Description: PGP signature

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

On Fri, 12 May 2023 at 09:40, Steve McIntyre  wrote:
>
> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >
> >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.
>
> WTF? *Nobody* has been talking about breaking ABI like this, that I've
> seen. The interpreter must *not* be changed willy-nilly.

Nothing's happening 'willy-nilly'. We are discussing a bunch of
seemingly crazy options, as in, "what would _actually_ explode if we
do this or do that?", on this very d-devel thread. I posted a longer
version here some days ago:

https://lists.debian.org/debian-gcc/2023/05/msg00030.html

Kind regards,
Luca Boccassi

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

2023-05-12 Thread Francesco P. Lovergine


severity 1035967 normal
thanks

On Fri, May 12, 2023 at 11:09:50AM +0200, Francesco P. Lovergine wrote:

tags 1035967 + moreinfo unreproducible
thanks

Hi Rob,

I just verified with a fresh installation of bookworm and it perfectly works. My
first hypothesis could be about a gdbm-related breakage. It is somethig already
seen in the past and even annotatedi at sect.9 of the Debian HOWTO.
NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing changes 
in file formats due to external conditions

(e.g. changes in compiler/optimizations/ecc.)

Could you plese run yptest on your serveri and send anomalies in result?
Is this a single NIS master or do you have slaves ? Could you please 
regenerate gdbm stuff by ypinit -m after cleaning up maps?


Anywyay, my next step will be preparing an upgrading box to test 
bullseye->bookworm, stay tuned.



... and as promised, I just tested an upgrade of a NIS server successfully. 
Services are all
operational and the pointed binaries do not issue a segfault.

In order to undestand your problem, I need to have details about your
configuration, and eventually also pinned packages, additional repos etc.

Feel free to send that stuff off-bugs.d.o to protect your site information, 
eventually.

Thanks.


On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote:

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



--
Francesco P. Lovergine



--
Francesco P. Lovergine

Bug#1035960: All of sudden, the Spanish PO debconf templates is getting full of alien translators :-)

2023-05-12 Thread Cyril Brulebois

Hi,

Laura Arjona Reina  (2023-05-12):
> Maybe this issue in the Spanish dashboards is related to the report
> #1035960 about issues in the German dashboards:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035960
> 
> I will try to investigate both issues but any help is welcome.
> 
> If any of you is sure about the last date when you saw things were
> working well, please tell, so I can try to learn what happened since
> then that could cause the issue.

Please pretend I don't know anything about i18/l10n, www, or how the
latter uses information published by the former…

It looks to me like at least the status.$LANG files exposed at [1] are
busted, with many references to different $LANG.po in some files.

 1. https://l10n.debian.org/coordination/00data/

For example, status.es has 5319 references to de.po…


Whether that's linked or not, I didn't find reassuring that the www
build output hundreds/thousands of warnings when running a local,
partial build of english/international…

I'll keeping looking at what's supposed to happen on tye, but I'm not
sure I'll be able to get to the bottom of it on my own.


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


signature.asc
Description: PGP signature

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

2023-05-12 Thread Julian Gilbey

On Thu, May 11, 2023 at 11:59:41PM +0200, Pierre-Elliott Bécue wrote:
> 
> Julian Gilbey  wrote on 11/05/2023 at 16:41:46+0200:
> [...]
> > 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:
> > [...]

> > 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.

Hi Pierre-Elliott,

Thanks so much for the quick response, that's really helpful!

Unfortunately, this doesn't seem to be the issue, though:

# systemctl status lxc-net.service 
● lxc-net.service - LXC network bridge setup
 Loaded: loaded (/lib/systemd/system/lxc-net.service; enabled; preset: enab>
 Active: active (exited) since Thu 2023-05-11 20:35:48 BST; 13h ago
   Docs: man:lxc
Process: 81843 ExecStart=/usr/libexec/lxc/lxc-net start (code=exited, statu>
   Main PID: 81843 (code=exited, status=0/SUCCESS)
  Tasks: 1 (limit: 76868)
 Memory: 1.3M
CPU: 70ms
 CGroup: /system.slice/lxc-net.service
 └─81884 dnsmasq --conf-file=/dev/null -u dnsmasq --strict-order -->

May 11 20:35:48 euler systemd[1]: Starting lxc-net.service - LXC network bridge>
May 11 20:35:48 euler dnsmasq[81884]: started, version 2.89 cachesize 150
May 11 20:35:48 euler dnsmasq[81884]: compile time options: IPv6 GNU-getopt DBu>
May 11 20:35:48 euler dnsmasq-dhcp[81884]: DHCP, IP range 10.0.3.2 -- 10.0.3.25>
May 11 20:35:48 euler dnsmasq-dhcp[81884]: DHCP, sockets bound exclusively to i>
May 11 20:35:48 euler dnsmasq[81884]: reading /etc/resolv.conf
May 11 20:35:48 euler dnsmasq[81884]: using nameserver 10.0.0.243#53
May 11 20:35:48 euler dnsmasq[81884]: read /etc/hosts - 7 names
May 11 20:35:48 euler systemd[1]: Finished lxc-net.service - LXC network bridge>

And with some details snipped:

# ifconfig 
enp5s0: flags=4163  mtu 1500
inet [...]  netmask 255.255.255.0  broadcast 192.168.0.255
inet6 [...]  prefixlen 64  scopeid 0x20
ether [...]  txqueuelen 1000  (Ethernet)
[...]

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
[...]

lxcbr0: flags=4099  mtu 1500
inet 10.0.3.1  netmask 255.255.255.0  broadcast 10.0.3.255
ether 00:16:3e:00:00:00  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: [...]

wlp3s0: [...]


# bridge vlan show
port  vlan-id  
lxcbr01 PVID Egress Untagged



So lxc-net was established, and it still didn't work :(  (And yes,
I've just checked that lxc-start still fails.)  But maybe the bridge
is meant to be in the lxc container itself?


So I'm still totally stumped.

Any further ideas/suggestions/things to check would be welcomely
received!

Best wishes,

   Julian

Bug#1034392: Acknowledgement (tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or greater)

2023-05-12 Thread Per Lundberg


FYI: An OpenJDK bug regarding this has now been opened as well:
https://bugs.openjdk.org/browse/JDK-8307977
--
Best regards,
Per

Bug#1035988: Please package newer upstream version

2023-05-12 Thread Άλκης Γεωργόπουλος


Source: netmiko
Version: 2.4.2-2
Severity: important

Hi, thank you very much for maintaining netmiko in Debian!
Unfortunately the current 2.4.2-2 is very old (from 2019) and it's 
lacking a lot of new features and fixes.

Would it be possible to package the newest 4.2 version?
https://github.com/ktbyers/netmiko/releases

Regards,
Alkis Georgopoulos

Bug#1035971: linux-image-6.3.0-0-amd64: IRQ warnings from amdgpu Navi 33 / Radeon RX 7700S ...

2023-05-12 Thread Diederik de Haas

On Friday, 12 May 2023 04:05:42 CEST Nathan Schulte wrote:
> amdgpu :03:00.0: andgpu: Fetched VBIOS from ATRM
> amdgpu: ATOM BIOS: 113-BRT112124.001

I don't know if (or how) that^ bios can be updated, but I did see:
BIOS FA617XT.303 03/23/2023
And I did see that a 307 BIOS is available, so my first suggestion would be to 
first update to that latest BIOS.

Since this seems to be a _very_ new device, keeping an eye on BIOS updates is 
recommended as this is the time most issues will be found and hopefully fixed.
And I expect that you would need a very new kernel and 6.1 probably won't work 
(also in the future), so trying out the latest kernels could help too.

At https://salsa.debian.org/diederik/linux/-/commits/update-to-6.3.2-rt13 I'm 
working on an update to 6.3.2 (+ 6.3.1-rt13) so if you know how to 'grab' that 
and build a 6.3.2 kernel, you could try that too.

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

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

2023-05-12 Thread Francesco P. Lovergine


tags 1035967 + moreinfo unreproducible
thanks

Hi Rob,

I just verified with a fresh installation of bookworm and it perfectly works. My
first hypothesis could be about a gdbm-related breakage. It is somethig already
seen in the past and even annotatedi at sect.9 of the Debian HOWTO.
NEVER CROSS THE STREAMS (cit.). 
GDBM is quite weak in managing changes in file formats due to external conditions

(e.g. changes in compiler/optimizations/ecc.)

Could you plese run yptest on your serveri and send anomalies in result?
Is this a single NIS master or do you have slaves ? 
Could you please regenerate gdbm stuff by ypinit -m after cleaning up maps?


Anywyay, my next step will be preparing an upgrading box to test 
bullseye->bookworm, stay tuned.

On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote:

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



--
Francesco P. Lovergine

Bug#1035972: isc-dhcp EOL'ed

On Fri, May 12, 2023 at 10:08:52AM +0200, Raphael Hertzog wrote:
> > ISC is not longer maintaing any of the components of isc-dhcp (client,
> > 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.
[...]
> It's not a service to our users to claim that we will not support them.
[...]
> But I'm afraid that we will have to keep maintaining those for the benefit
> of our stable/oldstable (and even ELTS) users. I'm pretty sure that all
> the other distributions will also continue to maintain those packages for
> the lifetime of their respective releases so that we will have
> opportunities to share the workload and patches.

Given what Raphael wrote, should this bug maybe be about marking isc-dhcp
unsupported in trixie?

If not, what else?

-- 
cheers,
Holger

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

So what CAN we actually do? Well, individual decisions (eating less meat,
taking public transport, buying less fast fashion) are all important, but we
also need to change the system. As you may know, just 100 companies are
responsible for 71% of global emissions. (@JessicaTheLaw)
https://www.theguardian.com/sustainable-business/2017/jul/10/100-fossil-fuel-companies-investors-responsible-71-global-emissions-cdp-study-climate-change

signature.asc
Description: PGP signature

Bug#1035987: unblock: ros-ros-comm/1.15.15+ds-2

2023-05-12 Thread Jochen Sprickerhof

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

Please unblock package ros-ros-comm

[ Reason ]
python3-rospy extends the Python logging system with it's own API,
overwriting the findCaller() function to get the filename and line
number where the logging function was called. This broke with Python
3.11, resulting in a dead lock and I fixed it by importing the Python
3.11 function back then. While this worked in a simple case, it showed
the wrong source code location when logging was called inside a
submodule. The new version in 1.15.15+ds-2 uses the code from
ros-ros-comm again, only fixing the deadlock.

This is done with two changes:

1. The while hasattr(f, "f_code") looping over the stack, gains a break
   once there is no more f.f_back to fix the deadlock.

2. The test to find "the right frame" does no longer work with 3.11 as
   the stack is different. Instead it is identified by the name
   "_base_logger", as it is used by the code later anyhow.

[ Impact ]
Wrong filenames and line numbers in logs.

[ Tests ]
Unit test that the function does not fail, manual tests that it returns
the correct value in different cases.

[ Risks ]
Minimal risk, the original code is part of the project for a long time and
the changes are minimal and make sure that it always terminates. The
only problem could be that it still prints the wrong value which would
be unfortunate but not a big problem as it is used for debugging only.

[ 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 ]
This was reported outside of Debian, thus no bug number.

unblock ros-ros-comm/1.15.15+ds-2
diff --git a/debian/changelog b/debian/changelog
index acd2cae..5193a76 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ros-ros-comm (1.15.15+ds-2) unstable; urgency=medium
+
+  * Properly fix rospy logging in Python 3.11
+
+ -- Jochen Sprickerhof   Wed, 10 May 2023 12:27:48 +0200
+
 ros-ros-comm (1.15.15+ds-1) unstable; urgency=medium
 
   * New upstream version 1.15.15+ds
diff --git a/debian/patches/0015-rosgraph-update-code-from-Python-3.11.patch 
b/debian/patches/0015-rosgraph-update-code-from-Python-3.11.patch
index dc20fa5..975aca1 100644
--- a/debian/patches/0015-rosgraph-update-code-from-Python-3.11.patch
+++ b/debian/patches/0015-rosgraph-update-code-from-Python-3.11.patch
@@ -3,102 +3,27 @@ Date: Sun, 13 Nov 2022 16:39:59 +0100
 Subject: rosgraph: update code from Python 3.11
 
 ---
- tools/rosgraph/src/rosgraph/roslogging.py | 72 ---
- 1 file changed, 47 insertions(+), 25 deletions(-)
+ tools/rosgraph/src/rosgraph/roslogging.py | 7 +++
+ 1 file changed, 3 insertions(+), 4 deletions(-)
 
 diff --git a/tools/rosgraph/src/rosgraph/roslogging.py 
b/tools/rosgraph/src/rosgraph/roslogging.py
-index 9ecc121..0a94b2b 100644
+index 9ecc121..2df2f22 100644
 --- a/tools/rosgraph/src/rosgraph/roslogging.py
 +++ b/tools/rosgraph/src/rosgraph/roslogging.py
-@@ -50,32 +50,58 @@ from rospkg.environment import ROS_LOG_DIR
- class LoggingException(Exception): pass
- 
- class RospyLogger(logging.getLoggerClass()):
--def findCaller(self, *args, **kwargs):
-+# copied from python3.11/logging/__init__.py
-+# _srcfile is only used in conjunction with sys._getframe().
-+# Setting _srcfile to None will prevent findCaller() from being called. 
This
-+# way, you can avoid the overhead of fetching caller information.
-+
-+# The following is based on warnings._is_internal_frame. It makes sure 
that
-+# frames of the import mechanism are skipped when logging at module level 
and
-+# using a stacklevel value greater than one.
-+@staticmethod
-+def _is_internal_frame(frame):
-+"""Signal whether the frame is a CPython or logging module 
internal."""
-+filename = os.path.normcase(frame.f_code.co_filename)
-+return filename == logging._srcfile or (
-+"importlib" in filename and "_bootstrap" in filename
-+)
-+
-+
-+def findCaller(self, stack_info=False, stacklevel=1):
- """
- Find the stack frame of the caller so that we can note the source
- file name, line number, and function name with class name if possible.
- """
--file_name, lineno, func_name = super(RospyLogger, 
self).findCaller(*args, **kwargs)[:3]
--file_name = os.path.normcase(file_name)
--
--f = inspect.currentframe()
--if f is not None:
--f = f.f_back
--while hasattr(f, "f_code"):
+@@ -62,13 +62,12 @@ class RospyLogger(logging.getLoggerClass()):
+ if f is not None:
+ f = f.f_back
+ while hasattr(f, "f_code"):
 -# Search for the right frame using the data already found by 
parent

Bug#1035522: bullseye-pu: package debian-security-support/1:11+2023.05.04

hi,

friendly ping on this.

On Thu, May 04, 2023 at 07:50:37PM +0200, Holger Levsen wrote:
> this is a pre-approval request, I have not uploaded this yet (except to
> unstable). 

the package has migrated to bookworm now.
 
> [ Reason ]
> 
> unfortunatly debian-security-support in both bullseye and bookworm
> are affected by - #1034077 
> "debian-security-support: Lots of noise about DEBIAN_VERSION 12 being 
> invalid when upgrading bullseye→bookworm"
[...]
 
> [ Other info ]
> As there will be no more bullseye point releases before the bookworm
> release, this probably needs to go in via bullseye-updates. Is d/changelog
> correct for this like it is?

I'm not quoting the full bug report but the above is reason why this should
go into *bullseye* before the bookworm release...


-- 
cheers,
Holger

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

When you’re used to privilege, equality feels like oppression.


signature.asc
Description: PGP signature

Bug#1035986: Built without GLESv2 support causing errors on machines only supporting GLES

2023-05-12 Thread Erik Inkinen

Package: qt6-base
Severity: normal

Qt5 packages had separate GLES versions packaged in Debian, but on Qt6
the rendering backend was revamped by Qt so that the same binaries can
support desktop GL and GLES.

For some reason, the current Debian packaging does not include libGLES
development headers in Build-Depends. When configuring the build, Qt
will not be able to enable GLESv2 support. These packages then cannot be
used to render anything on devices that do not support desktop GL, but
have GLES support.

I have confirmed that building with GLES packages indeed fixes the errors.

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

Kernel: Linux 4.4-0-volla-yggdrasil (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1035985: Built without GLESv2 support causing errors on machines only supporting GLES

2023-05-12 Thread Erik Inkinen

Package: qt6-base
Severity: normal

Qt5 packages had separate GLES versions packaged in Debian, but on Qt6
the rendering backend was revamped by Qt so that the same binaries can
support desktop GL and GLES.

For some reason, the current Debian packaging does not include libGLES
development headers in Build-Depends. When configuring the build, Qt
will not be able to enable GLESv2 support. These packages then cannot be
used to render anything on devices that do not support desktop GL, but
have GLES support.

I have confirmed that building with GLES packages indeed fixes the errors.

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

Kernel: Linux 4.4-0-volla-yggdrasil (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

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

On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>
>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.

WTF? *Nobody* has been talking about breaking ABI like this, that I've
seen. The interpreter must *not* be changed willy-nilly.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site..." -- Simon Booth

Bug#1035960: All of sudden, the Spanish PO debconf templates is getting full of alien translators :-)

2023-05-12 Thread Laura Arjona Reina

Hi

El 12 de mayo de 2023 9:52:02 CEST, "Camaleón"  escribió:
>Hello,
>
>It seems something is happeing on Spanish debconf templates.
>The stats page is showing a lot of alien translators and old bugs :-)
>
>https://www.debian.org/international/l10n/po-debconf/es
>
>Can someone please take a look on this?
>
>Thank you,
>

Maybe this issue in the Spanish dashboards is related to the report #1035960 
about issues in the German dashboards:

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

I will try to investigate both issues but any help is welcome.

If any of you is sure about the last date when you saw things were working 
well, please tell, so I can try to learn what happened since then that could 
cause the issue.

Kind regards

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Bug#1035984: libpopplerkit0: unhandled symlink to directory conversion: /usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources

2023-05-12 Thread Andreas Beckmann

Package: libpopplerkit0
Version: 0.0.20051227svn-11
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  testing -> unstable

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


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

1m20.3s ERROR: installs objects over existing directory symlinks:
  
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/Info-gnustep.plist
 (libpopplerkit0) != 
/usr/share/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Info-gnustep.plist
 (?)
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources -> 
../../../../../../share/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0


Excerpts from debdiff libpopplerkit0_0.0.20051227svn-10+b1_amd64.deb 
libpopplerkit0_0.0.20051227svn-11_amd64.deb

Files in first .deb but not in second
-
-rw-r--r--  root/root   
/usr/share/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Info-gnustep.plist
-rw-r--r--  root/root   /usr/share/doc/libpopplerkit0/changelog.Debian.amd64.gz
lrwxrwxrwx  root/root   
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources -> 
../../../../../../share/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0

Files in second .deb but not in first
-
-rw-r--r--  root/root   
/usr/lib/GNUstep/Frameworks/PopplerKit.framework/Versions/1.0/Resources/Info-gnustep.plist


Was the move of Info-gnustep.plist from /usr/share to /usr/lib
intentional?
The easies fix would be to move it back to /usr/share and let dpkg clean
up the unused and messed up paths/symlinks in /usr/lib.


cheers,

Andreas


libpopplerkit0_0.0.20051227svn-11.log.gz
Description: application/gzip

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

2023-05-12 Thread James Addison

On Thu, 11 May 2023 at 23:54, Thorsten Glaser  wrote:
>
> 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.

Ok, that's what I thought, but I'm not familiar with the details here.

So: a fix here won't achieve stack capacity equality across
architectures.  (I say this because I think we should be clear about
what the bugreport is about, and, where possible, the known
limitations of fixes)

Or, to put it another way: applying an increase (either static or
dynamic, either ARM-specific or across all architectures) for stack
size determination would move the problem, and another architecture
would take the place of "architecture where RangeError can occur in
code x that doesn't occur on other architectures".

Do those statements seem true?  (they make sense to me, but I also
think it's possible that I've misunderstood something here)

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

That makes sense, and I agree that dynamic stack-sizing could help
(perhaps quite a lot on some systems).  We'd need a patch to implement
it, though - and based on their current policy, NodeJS upstream seem
unlikely to accept it since they don't want to modify their vendored
V8.  But if it showed significant benefits then perhaps we could use
that to contribute to further discussion with either/both of those
projects.

Bug#1035983: libsoap3 (and libsoap2) autopkgtests are flaky: Address already in use: AH00072: make_sock: could not bind to address 127.0.0.1:47524

2023-05-12 Thread Michael Tokarev

Source: libsoup3
Version: 3.2.2-2
Severity: normal
X-Debbugs-Cc: pkg-samba-de...@lists.alioth.debian.org

Libsoap2 & libsoap3 triggers autopkgtest run when updating other packages,
such as samba. And on almost every samba upload, for quite some time, I
have to reschedule one or another libsoap autopkgtest run due to the same
failure, like in current version:

https://ci.debian.net/data/autopkgtest/testing/s390x/libs/libsoup3/33505300/log.gz

...
PASS: libsoup-3.0/session-test.test
Running test: libsoup-3.0/auth-test.test
# random seed: R02S312e10d03684417c83184f8cd3e1c8b1
# GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation gnutls 
(GTlsBackendGnutls) for ‘gio-tls-backend’
# [1375753.095277] enter apache_init
# Apache command: '/usr/sbin/apache2' '-d' 
'/usr/libexec/installed-tests/libsoup-3.0' '-f' 'httpd.conf' '-c' 'ErrorLog 
/tmp/test-tmp-libsoup-3.0_auth-test.test-JNCR41/error.log' '-c' 'PidFile 
/tmp/test-tmp-libsoup-3.0_auth-test.test-JNCR41/httpd.pid' '-k' 'start'
(98)Address already in use: AH00072: make_sock: could not bind to address 
127.0.0.1:47524
no listening sockets available, shutting down
AH00015: Unable to open logs
Could not start apache
# -> failed
FAIL: libsoup-3.0/auth-test.test (Child process exited with code 1)

And subsequent tests in the category fail too, due to the same issue.

Right now we can't migrate samba to testing due to this test failure.
Usually it is sufficient to reschedule the test once, sometimes it
goes on after second attempt.

Can you please take a look?

https://tracker.debian.org/pkg/samba

Bug#1035794: debian-security-support: Please mark wpewebkit as unsupported in bookworm

control: tags -1 + pending
thanks

hi Berto,

On Tue, May 09, 2023 at 11:41:38AM +0200, Alberto Garcia wrote:
> we won't be providing security updates of the wpewebkit package for
> bookworm. The package will be kept up-to-date in unstable and users
> will still be able to find the most recent versions there.
> 
> wpewebkit should be buildable in bookworm during its lifetime so users
> can create their own packages easily if they need to. However, some
> APIs will probably change so reverse dependencies can be affected.

thanks, I've just done the following change:

commit fb76bd1333c9a7251980b9f8810286f8a2421a87
Author: Holger Levsen 
Date:   Fri May 12 10:23:40 2023 +0200

Add wpewebkit to security-support-ended.deb12. Closes: #1035794. Thanks to 
Alberto Garcia.

Signed-off-by: Holger Levsen 

diff --git a/security-support-ended.deb12 b/security-support-ended.deb12
index cf24acb..198f5ff 100644
--- a/security-support-ended.deb12
+++ b/security-support-ended.deb12
@@ -11,3 +11,4 @@
 #In the program's output, this is prefixed with "Details:"
 
+wpewebkit  2.38.6-12023-05-09  https://bugs.debian.org/1035794

> Note that wpewebkit is still supported in bullseye and will remain
> supported until the distro reaches EOL.

does that mean when the Debian security stops supporting bullseye or
when LTS stops supporting bullseye (or when ELTS stops supporting
bullseye)? :)

and could you maybe inform src:debian-security-support when this is the
case?


-- 
cheers,
Holger

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

Stop saying that we are all in the same boat.
We’re all in the same storm. But we’re not all in the same boat.


signature.asc
Description: PGP signature

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

2023-05-12 Thread Thomas Dorner

Hi Hannes!

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

Looks good:

[...]
WARNING: lgetfilecon_raw failed for /var/opt/lxc/no-network: No such file or 
directory
WARNING: tried to read access ACL on /var/opt/lxc/no-network/sys but failed 
with: No such file or directory
WARNING: tried to read default ACL on /var/opt/lxc/no-network/sys but failed 
with: Invalid argument
WARNING: listxattrs failed for /var/opt/lxc/no-network/sys:No such file or 
directory
WARNING: lgetfilecon_raw failed for /var/opt/lxc/no-network/sys: No such file 
or directory
WARNING: readlink() failed for '/var/opt/lxc/no-network/lib64': No such file or 
directory
WARNING: listxattrs failed for /var/opt/lxc/no-network/lib64:No such file or 
directory
WARNING: lgetfilecon_raw failed for /var/opt/lxc/no-network/lib64: No such file 
or directory
WARNING: readlink() failed for '/var/opt/lxc/no-network/lib32': No such file or 
directory
WARNING: listxattrs failed for /var/opt/lxc/no-network/lib32:No such file or 
directory
WARNING: lgetfilecon_raw failed for /var/opt/lxc/no-network/lib32: No such file 
or directory
WARNING: readlink() failed for '/var/opt/lxc/no-network/bin': No such file or 
directory
WARNING: listxattrs failed for /var/opt/lxc/no-network/bin:No such file or 
directory
WARNING: lgetfilecon_raw failed for /var/opt/lxc/no-network/bin: No such file 
or directory
[...]

> Thanks for debugging.

You're welcome.

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

Bug#1035982: connman: failed to start connman-online-service when log out so i can not connect to internet after log out

2023-05-12 Thread dudy

Package: connman
Version: 1.41-3
Severity: important
X-Debbugs-Cc: dudyke...@yahoo.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages connman depends on:
ii  dbus   1.14.6-1
ii  init-system-helpers1.65.2
ii  iptables   1.8.9-2
ii  libc6  2.36-9
ii  libdbus-1-31.14.6-1
ii  libglib2.0-0   2.74.6-2
ii  libgnutls303.7.9-2
ii  libreadline8   8.2-1.3
ii  libxtables12   1.8.9-2
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages connman recommends:
ii  bluez  5.66-1
ii  ofono  1.31-3+b1
ii  wpasupplicant  2:2.10-12

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#1025161: LXD new version

2023-05-12 Thread Markus Brechtel

please don't. The 5.0 release is the LXD Long Term Support release, see 
https://discuss.linuxcontainers.org/t/lxd-5-0-2-lts-has-been-released/16211

Bug#1035927: unblock: samba/2:4.17.8+dfsg-1

2023-05-12 Thread Michael Tokarev


12.05.2023 11:05, Sebastian Ramacher пишет:

Control: tags -1 moreinfo

On 2023-05-11 12:58:00 +0300, Michael Tokarev wrote:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sa...@packages.debian.org, pkg-samba-ma...@lists.alioth.debian.org
Control: affects -1 + src:samba

Please unblock package samba


This uploaded caused the autpkgtests of libsoup2.4 and libsoup3 to
regress on s390x. Could you please check (with the libsoup maintainers)
if that is an issue in libsoup or samba? Thanks


Yeah I've seen it today already, - unfortunately it's common for libsoup
to sporadically fail here or there.  Here's the typical (from current log):

# Apache command: '/usr/sbin/apache2' '-d' '/usr/libexec/installed-tests/libsoup-3.0' '-f' 'httpd.conf' '-c' 'ErrorLog 
/tmp/test-tmp-libsoup-3.0_auth-test.test-049S41/error.log' '-c' 'PidFile /tmp/test-tmp-libsoup-3.0_auth-test.test-049S41/httpd.pid' '-k' 'start'

(98)Address already in use: AH00072: make_sock: could not bind to address 
127.0.0.1:47524
no listening sockets available, shutting down

Usually repeating a test does the "trick", but sure thing it'd be
nice if it worked by its own without a need for such babysitting.

Obviously this has exactly nothing to do with samba, they start
test apache instance on the same listening port and sometimes it
happens "too fast", or they don't stop it properly from the previous
test.

I'll ping libsoap folks once more.

Thanks,

/mjt

Bug#1035972: isc-dhcp EOL'ed

2023-05-12 Thread Raphael Hertzog

Hello Santiago,

On Thu, 11 May 2023, Santiago Ruano Rincón wrote:
> 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.

We are speaking of packages that are installed in the vast majority of
Debian systems:
https://qa.debian.org/popcon.php?package=isc-dhcp

It's not a service to our users to claim that we will not support them.
This is a reason for us to start moving away from them in
unstable/testing (but who will do that? You might want to raise the
discussion on -devel and get some bugs filed).

But I'm afraid that we will have to keep maintaining those for the benefit
of our stable/oldstable (and even ELTS) users. I'm pretty sure that all
the other distributions will also continue to maintain those packages for
the lifetime of their respective releases so that we will have
opportunities to share the workload and patches.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

signature.asc
Description: PGP signature

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

2023-05-12 Thread Sebastian Ramacher

Control: tags -1 moreinfo confirmed

On 2023-05-11 21:48:18 +0200, Fab Stz wrote:
> 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.

Please remove the moreinfo tag once the package is available in
unstable.

Cheers
-- 
Sebastian Ramacher

Bug#1035927: unblock: samba/2:4.17.8+dfsg-1

2023-05-12 Thread Sebastian Ramacher

Control: tags -1 moreinfo

On 2023-05-11 12:58:00 +0300, Michael Tokarev wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: sa...@packages.debian.org, 
> pkg-samba-ma...@lists.alioth.debian.org
> Control: affects -1 + src:samba
> 
> Please unblock package samba

This uploaded caused the autpkgtests of libsoup2.4 and libsoup3 to
regress on s390x. Could you please check (with the libsoup maintainers)
if that is an issue in libsoup or samba? Thanks

Best
Sebastian
-- 
Sebastian Ramacher

Bug#1035981: CVE-2023-2088 / OSSA-2023-003: Unauthorized volume access through deleted volume attachments

2023-05-12 Thread Thomas Goirand

Source: nova
Version: 2:26.1.0-2
Severity: grave
Tags: patch

Affects
~~~
- Cinder: <20.2.1, >=21.0.0 <21.2.1, ==22.0.0
- Glance_store: <3.0.1, >=4.0.0 <4.1.1, >=4.2.0 <4.3.1
- Nova: <25.1.2, >=26.0.0 <26.1.2, ==27.0.0
- Os-brick: <5.2.3, >=6.0.0 <6.1.1, >=6.2.0 <6.2.2


Description
~~~
An unauthorized access to a volume could occur when an iSCSI or FC
connection from a host is severed due to a volume being unmapped on
the storage system and the device is later reused for another volume
on the same host.

**Scope:** Only deployments with iSCSI or FC volumes are affected.
However, the fix for this issue includes a configuration change in
Nova and Cinder that may impact you on your next upgrade regardless
of what backend storage technology you use. See the *Configuration
change* section below, and item 4(B) in the *Patches and Associated
Deployment Changes* for details.

This data leak can be triggered by two different situations.

**Accidental case:** If there is a problem with network connectivity
during a normal detach operation, OpenStack may fail to clean the
situation up properly. Instead of force-detaching the compute node
device, Nova ignores the error, assuming the instance has already
been deleted. Due to this incomplete operation OpenStack may end up
selecting the wrong multipath device when connecting another volume
to an instance.

**Intentional case:** A regular user can create an instance with a
volume, and then delete the volume attachment directly in Cinder,
which neglects to notify Nova. The compute node SCSI plumbing (over
iSCSI/FC) will continue trying to connect to the original
host/port/LUN, not knowing the attachment has been deleted. If a
subsequent volume attachment re-uses the host/port/LUN for a
different instance and volume, the original instance will gain
access to it once the SCSI plumbing reconnects.

Configuration Change

To prevent the intentional case, the Block Storage API provided by
Cinder must only accept attachment delete requests from Nova for
instance-attached volumes. A complicating factor is that Nova
deletes an attachment by making a call to the Block Storage API on
behalf of the user (that is, by passing the user's token), which
makes the request indistinguishable from the user making this
request directly. The solution is to have Nova include a service
token along with the user's token so that Cinder can determine that
the detach request is coming from Nova. The ability for Nova to pass
a service token has been supported since Ocata, but has not been
required until now. Thus, deployments that are not currently sending
service user credentials from Nova will need to apply the relevant
code changes and also make configuration changes to solve the
problem.

Patches and Associated Deployment Changes
-
Given the above analysis, a thorough fix must include the following
elements:

1. The os-brick library must implement the ``force`` option for
   fibre channel, which which has only been available for iSCSI
   until now (covered by the linked patches).

2. Nova must call os-brick with the ``force`` option when
   disconnecting volumes from deleted instances (covered by the
   linked patches).

3. In deployments where Glance uses the cinder glance_store driver,
   glance must call os-brick with the ``force`` option when
   disconnecting volumes (covered by the linked patches).

4. Cinder must distinguish between safe and unsafe attachment delete
   requests and reject the unsafe ones. This part of the fix has two
   components:

   a. The Block Storage API will return a 409 (Conflict) for a
  request to delete an attachment if there is an instance
  currently using the attachment, **unless** the request is
  being made by a service (for example, Nova) on behalf of a
  user (covered by the linked patches).

   b. In order to recognize that a request is being made by a
  service on behalf of a user, Nova must be configured to send a
  service token along with the user token. If this configuration
  change is not made, the cinder change will reject **any**
  request to delete an attachment associated with a volume that
  is attached to an instance. Nova must be configured to send a
  service token to Cinder, and Cinder must be configured to
  accept service tokens. This is described in the following
  document and **IS NOT AUTOMATICALLY APPLIED BY THE LINKED
  PATCHES:** (Using service tokens to prevent long-running job
  failures)
  
https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html
  The Nova patch mentioned in step 2 includes a similar document
  more focused on Nova:
  doc/source/admin/configuration/service-user-token.rst

5. The cinder glance_store driver does not attach volumes to
   instances; instead, it attaches volumes directly to the Glance
   node. Thus, the Cinder change in step 4

Bug#1035980: unblock: tiles/3.0.7-5