from:"Paul"


Hi

On 19-05-2024 6:25 a.m., 陈 晟祺 wrote:

I have made more adjustments, basically skipping some flaky tests in VM.
Now new version 2.2.4-1 is in the archive, please try that again when available.


I already noticed yesterday and had it run; it failed. (Currently) top 
one here: https://ci.debian.net/packages/z/zfs-linux/testing/amd64/


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071429: dpkg: `dpkg-db-backup.timer` starts `dpkg-db-backup.service` in hot path of boot

2024-05-18 Thread Paul Menzel


Package: dpkg
Version: 1.22.6
Severity: normal


Dear Debian folks,


Trying to decrease the boot time of a desktop system (pressing the power 
button to GDM login screen), I noticed `dpkg-db-backup.service` in the 
hotpath:


May 19 06:18:53.272044 abreu systemd[1]: Started 
dpkg-db-backup.timer - Daily dpkg database backup timer.

[…]
May 19 06:18:53.280049 abreu kernel: i915 :00:02.0: [drm] fb0: 
i915drmfb frame buffer device

[…]
May 19 06:18:53.313754 abreu systemd[1]: Starting dbus.service - 
D-Bus System Message Bus...

[…]
May 19 06:18:53.479594 abreu systemd[1]: Starting 
dpkg-db-backup.service - Daily dpkg database backup service...

[…]
May 19 06:18:53.974802 abreu systemd[1]: dpkg-db-backup.service: 
Deactivated successfully.

[…]
May 19 06:18:53.975072 abreu systemd[1]: Finished 
dpkg-db-backup.service - Daily dpkg database backup service.

[…]
May 19 06:18:53.985305 abreu systemd[1]: Reached target 
network.target - Network.

[…]
May 19 06:18:54.166818 abreu systemd[1]: Started gdm.service - 
GNOME Display Manager.


It’d be great if this could be moved out the hot path, for example, by 
running it at least ten(?) minutes after the system has been started.



Kind regards,

Paul


PS:

```
$ systemctl cat dpkg-db-backup.timer
# /usr/lib/systemd/system/dpkg-db-backup.timer
[Unit]
Description=Daily dpkg database backup timer
Documentation=man:dpkg(1)

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target
$ systemctl cat dpkg-db-backup.service
# /usr/lib/systemd/system/dpkg-db-backup.service
[Unit]
Description=Daily dpkg database backup service
Documentation=man:dpkg(1)

[Service]
Type=oneshot
ExecStart=/usr/libexec/dpkg/dpkg-db-backup
$ systemd-analyze blame
4.396s systemd-suspend.service
1.295s fwupd.service
 535ms cups.service
 517ms boot-efi.mount
 507ms NetworkManager.service
 495ms dpkg-db-backup.service
 489ms accounts-daemon.service
 478ms dev-mapper-nvme0n1p3_crypt.device
 456ms gnome-remote-desktop.service
 454ms udisks2.service
 446ms fwupd-refresh.service
 430ms strongswan.service
 418ms power-profiles-daemon.service
 399ms ssh.service
 390ms systemd-journal-flush.service
 377ms e2scrub_reap.service
 325ms avahi-daemon.service
 317ms upower.service
 304ms user@5272.service
 298ms xl2tpd.service
 295ms systemd-udev-trigger.service
 289ms systemd-tmpfiles-clean.service
 286ms systemd-logind.service
 250ms lm-sensors.service
 243ms switcheroo-control.service
 242ms etckeeper.service
 193ms smartmontools.service
 169ms systemd-journald.service
 161ms grub-common.service
 145ms apparmor.service
 140ms systemd-fsck@dev-disk-by\x2duuid-96BD\x2d5653.service
 128ms wpa_supplicant.service
 125ms systemd-cryptsetup@nvme0n1p3_crypt.service
 123ms systemd-udevd.service
 120ms polkit.service
 112ms gdm.service
 112ms systemd-backlight@backlight:intel_backlight.service
 108ms 
systemd-fsck@dev-disk-by\x2duuid-2d23fd4c\x2d5d03\x2d4e1a\x2d8a42\x2d0e859d1f00d8.service

 105ms dev-disk-by\x2ddiskseq-1\x2dpart4.swap
 104ms dbus.service
  91ms colord.service
  91ms nvmf-autoconnect.service
  90ms systemd-rfkill.service
  85ms systemd-hostnamed.service
  82ms dev-hugepages.mount
  79ms dev-mqueue.mount
  78ms systemd-tmpfiles-setup.service
  75ms sys-kernel-debug.mount
  68ms sys-kernel-tracing.mount
  67ms atop.service
  66ms systemd-modules-load.service
  64ms kmod-static-nodes.service
  60ms modprobe@configfs.service
  58ms systemd-timesyncd.service
  54ms systemd-remount-fs.service
  53ms systemd-backlight@leds:dell::kbd_backlight.service
  53ms modprobe@dm_mod.service
  52ms modprobe@drm.service
  51ms modprobe@efi_pstore.service
  45ms modprobe@fuse.service
  44ms systemd-tmpfiles-setup-dev-early.service
  42ms modprobe@loop.service
  42ms boot.mount
  39ms systemd-binfmt.service
  37ms modprobe@nvme_fabrics.service
  33ms systemd-udev-load-credentials.service
  32ms systemd-user-sessions.service
  25ms rtkit-daemon.service
  24ms systemd-random-seed.service
  24ms systemd-tmpfiles-setup-dev.service
  22ms user-runtime-dir@5272.service
  20ms systemd-sysctl.service
  20ms systemd-update-utmp-runlevel.service
  18ms systemd-update-utmp.service
  16ms proc-sys-fs-binfmt_misc.mount
  13ms sys-kernel-config.mount
  10ms alsa-restore.service
  10ms sys-fs-fuse-connections.mount
```

Bug#1071007:

2024-05-18 Thread Paul Pfeister

All --

::: Re: 1071007, ALL CONCERNED :::

I am associated with the upstream project.
This is a real bug. Discovered it some time last week. This seems to have
been introduced when we added the new pyproject file with a setuptools
backend.

For some unknown reason, the installed package would dump its files into
either the dist-packages/site-packages dir rather than a package-named
subdir, or it would for even more mysterious reasons dump the src files
into _both_ dirs at the same time. This behavior was present no matter the
install method -- whether pip, rpm, etc.

I have resolved this bug in upstream PR #2111 (below), with a switch from
setuptools to Poetry, among several other more minor tasks. This PR is
currently undergoing review, but I expect it to be merged shortly. Once
merged, the packager here can pull and repack (or they can patch to in the
interim).

https://github.com/sherlock-project/sherlock/pull/2111

::: FOR THE PKG MAINTAINER :::

Since Poetry doesn't support dynamic versioning in the same way setuptools
did, that part of the workflow has to change a bit once this PR is merged.

Dynamic versioning now occurs via `poetry build` with the
`poetry-version-plugin` plugin installed alongside. Since many automated
workflows rely on pip, you may need to adapt it slightly. Reference the
spec file here for an example of how I adapted the rpm build workflow for
this. L43 and L44 run a quick sed to fetch and populate the version number
from the __init__ as the single source of truth.

https://github.com/ppfeister/pkg/blob/3959a6ef6c8a2318ae183a8e5d85241eb8f756bf/sherlock/sherlock-project.spec

If you're able to use Poetry with plugins as part of your workflow, then
that change may be moot.

::: ALL /> :::

Feel free to reach out if you have any questions.

Bug#1071413: src:rust-debversion: fails to migrate to testing for too long: RC buggy Depends


Source: rust-debversion
Version: 0.2.2-1
Severity: serious
Control: close -1 0.3.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:rust-debversion has been trying to migrate 
for 70 days [2]. Hence, I am filing this bug. The version in unstable 
apparently has a new dependency chain that ends with rust-rsa which has 
an unresolved RC security issue and isn't migrating to testing.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=rust-debversion



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071412: src:tracker: fails to migrate to testing for too long: autopkgtest regression


Source: tracker
Version: 3.4.2-3
Severity: serious
Control: close -1 3.7.3-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1068468

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:tracker has been trying to migrate for 71 
days [2]. Hence, I am filing this bug. The version in unstable fails its 
own autopkgtest as reported in bug 1068468.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=tracker



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071410: src:diffoscope: fails to migrate to testing for too long: FTBFS and blocked by Build-Depends


Source: diffoscope
Version: 259
Severity: serious
Control: close -1 267
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:diffoscope has been trying to migrate for 
71 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build and is also blocked by apktool, which was removed from testing 
due to an unresolved RC bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=diffoscope



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071409: src:fakeroot: fails to migrate to testing for too long: FTBFS on armel, armhf


Source: fakeroot
Version: 1.33-1
Severity: serious
Control: close -1 1.34-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:fakeroot has been trying to migrate for 73 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on armel and armhf. On reproducible-builds, a build on i386, arm64 
and armhf today also failed (only amd64 passed).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=fakeroot



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071403: src:geoalchemy2: fails to migrate to testing for too long: B-D on mysql which isn't allowed to migrate


Source: geoalchemy2
Version: 0.13.3-2
Severity: serious
Control: close -1 0.14.6-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:geoalchemy2 has been trying to migrate for 
73 days [2]. Hence, I am filing this bug. The version in unstable build 
depends on mysql, which for security support isn't allowed to migrate 
(Debian has MariaDB).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=geoalchemy2



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071402: src:gnome-shell-extension-arc-menu: fails to migrate to testing for too long: unsatisfiable dependency


Source: gnome-shell-extension-arc-menu
Version: 49+forkv29-4
Severity: serious
Control: close -1 55-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:gnome-shell-extension-arc-menu has been 
trying to migrate for 75 days [2]. Hence, I am filing this bug. The 
version in unstable has unsatisfiable dependencies.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=gnome-shell-extension-arc-menu



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071401: src:cross-toolchain-base-mipsen: unsatisfied build dependency in testing: linux-source-6.6 (>= 6.6.11)


Source: cross-toolchain-base-mipsen
Version: 27
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071400: src:specutils: unsatisfied build dependency in testing: python3-spectral-cube


Source: specutils
Version: 1.14.0-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071399: src:ndcube: unsatisfied build dependency in testing: python3-sunpy


Source: ndcube
Version: 2.2.0-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071398: src:tea-cli: unsatisfied build dependency in testing: golang-github-go-git-go-git-dev


Source: tea-cli
Version: 0.9.2-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071397: src:ngspetsc: unsatisfied build dependency in testing: fenicsx


Source: ngspetsc
Version: 0.0~git20240318.f83b50a-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069329: fixed in diffoscope 266

2024-05-16 Thread Paul Wise

On Wed, 2024-05-15 at 10:58 +0100, Chris Lamb wrote:

> Ah, I foolishly didn't check back with the original test case. The
> root cause here, if I can call it that, is that we were calling "xz
> --list --verbose" and not specifying a second "--verbose".

That would explain it indeed.

> This has now been remedied in Git, which will most likely be released
> on Friday 17th May. I've used your original test case as a literal
> test fixture, and can confirm it now shows a difference.

Excellent, thanks!

> Given the extra verbose information, I did alas make a related
> change so that it will not show the "--verbose --verbose" output if
> there are differences between the files contained within the .xz.
> Otherwise every single .deb package would show a very lengthy and
> distracting output.

That seems like the right thing to do indeed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1062026: autopkgtest: add loongarch64 support

2024-05-16 Thread Paul Gevers

Control: tags -1 moreinfo

Hi Zhang,

(CC Dandan as loong64 porter)

On Wed, 31 Jan 2024 10:03:42 + Simon McVittie  wrote:

On Wed, 31 Jan 2024 at 01:28:43 +, Zhang Na wrote:
>   Add loongarch64 support, thanks!

Thanks, have you successfully tested this? Does it successfully test
packages under qemu?

> +elif self.qemu_architecture in ('arm', 'riscv64', 'loongarch64'):
>  argv.extend(['-machine', 'virt'])

Is this required? `qemu-system-loongarch64 -machine help` says virt is
the default anyway. We probably shouldn't be forcing particular options
if it isn't required.

(On arm there is no default, and on riscv64 qemu's default machine is
not virtio-based, so they do need this special case)

Without a reply, we can't handle this request. Can you please follow up?

Paul

OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive

2024-05-16 Thread Paul Gevers


Hi Ben (and all the rest),

On 15-05-2024 9:56 p.m., Ben Hutchings wrote:

Apologies for leaving this bug for so long.


NP, part of live I guess.


Is this bug still occurring?


I don't know. The problem was severe enough for us to abandon the idea 
of running the backport kernels on our arm64 hosts, so we went back to 
the stable kernel there.



I had a look for possibly related fixes,
and found:

commit 22e111ed6c83dcde3037fc81176012721bc34c0b


[...]


The fix went into
6.8-rc1 and was backported to 6.6.15, so Debian versions 6.6.15-1
onward should have it.



commit a8b0026847b8c43445c921ad2c85521c92eb175f


[...]


which went into 6.8 but was *not* backported.


If you think it worth enough knowing if either is the case, I can 
install the backports kernel again on the arm64 hosts, but obviously 
that will be annoying for us. Please let me know if I should pursue this 
(I would be expecting a bit quicker turn around on this bug if you say 
yes now ;) ).



If the bug is still occurring, can you say what type of filesystem
rsync is being run on?


I'm not sure if this is the answer you're looking for, we use ext4.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055370: consider adding security repos by default

2024-05-15 Thread Paul Gevers


Control: reassign -1 autopkgtest

Hi Mathias,

Sorry for letting this go unanswered for so long.

On Sat, 10 Feb 2024 20:39:12 + Mathias Gibbens 
wrote:
I suspect debci is either adding options or directly generating a 
sources.list that is injected into the container. The word "debug" 
doesn't appear anywhere within the debian template script and I'm not

sure how the "deb-src" lines could be introduced with the existing
template logic.

Maybe there's something else going on in lxc-templates, but I'm not 
seeing anything immediately obvious to explain where debci's 
sources.list is coming from.


I didn't check the autopkgtest code yet, but I trust your assessment 
it's not lxc-templates. Let's assign to autopkgtest for further checking


Paul
PS: this reply was triggered by bug 1071185


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071141: gnome-remote-desktop: `/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:2: Failed to resolve user 'gnome-remote-desktop': No such process`

2024-05-14 Thread Paul Menzel


Package: gnome-remote-desktop
Version: 46.1-3
Severity: normal


Dear Debian folks,


Upgrading to *gnome-shell* from the suite *experimental*

sudo apt install -t experimental gnome-shell

also upgrades *gnome-remote-desktop* from 44.2-8 to 46.1-3. The lines 
below were printed to the console:


gnome-remote-desktop (46.1-3) wird eingerichtet ...
/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:2: Failed to 
resolve user 'gnome-remote-desktop': No such process
/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:3: Failed to 
resolve user 'gnome-remote-desktop': No such process

Creating group 'gnome-remote-desktop' with GID 987.

The failure lines were printed in red.


Kind regards,

Paul

Bug#1069329: fixed in diffoscope 266

2024-05-14 Thread Paul Wise

On Fri, 2024-05-10 at 14:49 +, Chris Lamb wrote:

>    * Use "xz --list" to supplement the output when comparing .xz archives;
>  essential when some underlying metadata differs. (Closes: #1069329)
>    * Actually append the xz --list after the container differences, as it
>  simplifies tests and the output.

Hmm, I still get a hex diff with the test case I posted in the bug:

$ echo foo > foo
$ xz -0 < foo > foo.0.xz
$ xz -9 < foo > foo.9.xz
$ diffoscope foo.0.xz foo.9.xz
--- foo.0.xz
+++ foo.9.xz
│┄ Format-specific differences are supported for XZ compressed files but no 
file-specific differences were detected; falling back to a binary diff. file(1) 
reports: XZ compressed data, checksum CRC64
@@ -1,4 +1,4 @@
 : fd37 7a58 5a00 0004 e6d6 b446 0200 2101  .7zXZ..F..!.
-0010: 0c00  8f98 419c 0100 0366 6f6f 0a00  ..Afoo..
+0010: 1c00  10cf 58cc 0100 0366 6f6f 0a00  ..Xfoo..
 0020: ffd7 ac5a 3031 9cf2 0001 1c04 6f2c 9cc1  ...Z01..o,..
 0030: 1fb6 f37d 0100  0004 595a...}..YZ

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1071094: osc: SyntaxWarning: invalid escape sequence

2024-05-14 Thread Paul Wise

Package: osc
Version: 0.182.1-1
Severity: normal
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Upgrading osc gives Python 3.12 warnings,
the fix for this is to use raw strings:

https://docs.python.org/3/library/re.html#raw-string-notation

   Preparing to unpack .../archives/osc_0.182.1-1_all.deb ...
   Unpacking osc (0.182.1-1) over (0.169.1-2) ...
   Setting up osc (0.182.1-1) ...
   /usr/lib/python3/dist-packages/osc/commandline.py:7931: SyntaxWarning: 
invalid escape sequence '\('
 if re.match('^perl\(\w+(::\w+)*\)$', search_term):
   /usr/lib/python3/dist-packages/osc/commandline.py:7932: SyntaxWarning: 
invalid escape sequence '\)'
 search_term = re.sub('\)', '', re.sub('(::|\()', '-', search_term))
   /usr/lib/python3/dist-packages/osc/commandline.py:7932: SyntaxWarning: 
invalid escape sequence '\('
 search_term = re.sub('\)', '', re.sub('(::|\()', '-', search_term))
   /usr/lib/python3/dist-packages/osc/commandline.py:7953: SyntaxWarning: 
invalid escape sequence '\ '
 'or \'--bugowner\' or \'--maintainer\' or \'--limit-to-attribute \ ' 
\
   /usr/lib/python3/dist-packages/osc/commandline.py:9201: SyntaxWarning: 
invalid escape sequence '\*'
 if re.match('^\*\W+(.+\W+\d{1,2}\W+20\d{2})\W+(.+)\W+<(.+)>\W+(.+)$', 
titleline):
   /usr/lib/python3/dist-packages/osc/core.py:4124: SyntaxWarning: invalid 
escape sequence '\s'
 tag_pat = '(?P^%s)\s*:\s*(?P.*)'
   /usr/lib/python3/dist-packages/osc/core.py:4130: SyntaxWarning: invalid 
escape sequence '\s'
 section_pat = '^%s\s*?$'
   /usr/lib/python3/dist-packages/osc/core.py:6321: SyntaxWarning: invalid 
escape sequence '\['
 time_regex = re.compile('^\[[^\]]*\] ', re.M)
   /usr/lib/python3/dist-packages/osc/core.py:6324: SyntaxWarning: invalid 
escape sequence '\['
 time_regex = re.compile(b'^\[[^\]]*\] ', re.M)
   /usr/lib/python3/dist-packages/osc/core.py:7762: SyntaxWarning: invalid 
escape sequence '\s'
 mo = re.search('^([adrl])(?:\s+(-f)?\s*-m\s+(.*))?$', repl)
   /usr/lib/python3/dist-packages/osc/fetch.py:80: SyntaxWarning: invalid 
escape sequence '\.'
 n = re.sub(b'\.pkg\.tar\.(zst|.z)$', b'.arch', hdr.filename)
   /usr/lib/python3/dist-packages/osc/fetch.py:82: SyntaxWarning: invalid 
escape sequence '\.'
 n = re.sub(b'\.tar\.(zst|.z)$', b'.tar', hdr.filename)
   /usr/lib/python3/dist-packages/osc/util/archquery.py:166: SyntaxWarning: 
invalid escape sequence '\d'
 mo1 = re.match(b'(\d+)', ver1)
   /usr/lib/python3/dist-packages/osc/util/archquery.py:167: SyntaxWarning: 
invalid escape sequence '\d'
 mo2 = re.match(b'(\d+)', ver2)
   /usr/lib/python3/dist-packages/osc/util/debquery.py:94: SyntaxWarning: 
invalid escape sequence '\s'
 field, val = re.split(b':\s*', data.strip(), 1)
   /usr/lib/python3/dist-packages/osc/util/debquery.py:96: SyntaxWarning: 
invalid escape sequence '\s'
 while data and re.match(b'\s+', data):
   /usr/lib/python3/dist-packages/osc/util/debquery.py:127: SyntaxWarning: 
invalid escape sequence '\s'
 def _split_field_value(self, field, delimeter=b',\s*'):
   /usr/lib/python3/dist-packages/osc/util/debquery.py:208: SyntaxWarning: 
invalid escape sequence '\d'
 ver1 = re.sub(b'(\d+)', lambda m: (32 * b'0' + m.group(1))[-32:], ver1)
   /usr/lib/python3/dist-packages/osc/util/debquery.py:209: SyntaxWarning: 
invalid escape sequence '\d'
 ver2 = re.sub(b'(\d+)', lambda m: (32 * b'0' + m.group(1))[-32:], ver2)
   /usr/lib/python3/dist-packages/osc/util/rpmquery.py:344: SyntaxWarning: 
invalid escape sequence '\d'
 mo1 = re.match('(\d+)', ver1)
   /usr/lib/python3/dist-packages/osc/util/rpmquery.py:345: SyntaxWarning: 
invalid escape sequence '\d'
 mo2 = re.match('(\d+)', ver2)
   
-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), 
(790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), 
(690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages osc depends on:
ii  ca-certificates   20240203
ii  python3   3.11.8-1
ii  python3-m2crypto  0.40.1-3

Versions of packages osc recommends:
ii  bash-completion  1:2.13.0-1
ii  cpio 2.15+dfsg-1
pn  obs-build
ii  python3-keyring  25.2.0-1
ii  python3-rpm  4.19.1.1+dfsg-1
ii  rpm2cpio 4.19.1.1+dfsg-1
ii  sensible-utils   0.0.22

osc suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc

Bug#1071070: src:nbd: fails to migrate to testing for too long: autopkgtest failure


Source: nbd
Version: 1:3.25-1
Severity: serious
Control: close -1 1:3.26.1-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:nbd has been trying to migrate for 71 days 
[2]. Hence, I am filing this bug. You added an autopkgtest to your 
package (thank you for that), but it fails. This is blocking migration.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=nbd



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069447: gpaw: FTBFS on armhf: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" --test-pytest "--test-args=-v -m ci" returned exit code 13


Control: tags -1 moreinfo

Hi Lucas,

[Please CC me on replies, I'm not subscribed to the bug]

On Sat, 20 Apr 2024 15:09:56 +0200 Lucas Nussbaum  wrote:

During a rebuild of all packages in sid, your package failed to build
on armhf.


Do you have any idea why we don't see the same failure on 
reproducible-builds [1]?


Paul

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gpaw.html


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071069: src:prettytable: fails to migrate to testing for too long: FTBFS


Source: prettytable
Version: 3.6.0-1
Severity: serious
Control: close -1 3.6.0-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1066757

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:prettytable has been trying to migrate for 
72 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build as reported in bug 1066757.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=prettytable



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071067: src:sqlmodel: fails to migrate to testing for too long: FTBFS


Source: sqlmodel
Version: 0.0.8-5
Severity: serious
Control: close -1 0.0.8-6
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1066771

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:sqlmodel has been trying to migrate for 72 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build as reported in bug 1066771.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=sqlmodel



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055496: how-can-i-help: should detect that is run by unattended-upgrades & skip

2024-05-12 Thread Paul Wise

On Tue, 2023-11-07 at 12:10 +0100, Alexandre Detiste wrote:

> how-can-i-help: should detect that is run by unattended-upgrades & skip
> Possible solution: skip execution if STDIN is not a TTY.

I filter and then read my unattended-upgrades mails, so
this would break my normal usage of how-can-i-help output.

> When running unattended-upgrades (from it's .timer/.service),
> how-can-i-help will be called so many times
> and that will clutter logs.

unattended-upgrades should only call how-can-i-help once per upgrade,
unless you have the minimal steps option enabled?

The log clutter could be solved by not printing the header/footer
unless there are some help items to be printed too.

> But the next time apt is run interractively,
> it won't display new "tasks" again,
> becauses they are not considered new anymore.

Perhaps there could be options to mark or not mark the newly discovered
problems as new, then folks could customise the apt hook as needed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

Bug#1071003: src:audit: fails to migrate to testing for too long: piuparts regression


Source: audit
Version: 1:3.1.2-2
Severity: serious
Control: close -1 1:3.1.2-2.1
X-Debbugs-CC: vor...@debian.org
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1070327

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:audit has been trying to migrate for 74 
days [2]. Hence, I am filing this bug. The version in unstable has 
postrm issues as reported in 1070327.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=audit



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070995: src:eclib: fails to migrate to testing for too long: FTBFS on arm 32 bits


Source: eclib
Version: 20231212-1
Severity: serious
Control: close -1 20240408-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1069515

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:eclib has been trying to migrate for 74 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on armel and armhf, as reported in bug 106.9515


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=eclib



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070994: src:praat: fails to migrate to testing for too long: FTBFS on arm64, armel, armhf, ppc64el and riscv64


Source: praat
Version: 6.4.05+dfsg-1
Severity: serious
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:praat has been trying to migrate for 74 
days [2]. Hence, I am filing this bug. The version in unstabled failed 
to build on most architectures where it build before.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=praat



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070993: src:ukui-power-manager: fails to migrate to testing for too long: unresolved RC bug


Source: ukui-power-manager
Version: 3.1.1-1
Severity: serious
Control: close -1 4.0.0.1-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1070426

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:ukui-power-manager has been trying to 
migrate for 77 days [2]. Hence, I am filing this bug. The version in 
unstable is blocked by bug 1070426.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=ukui-power-manager



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070989: src:ruby-parslet: fails to migrate to testing for too long: triggers autopkgtest issues


Source: ruby-parslet
Version: 1.8.2-4
Severity: serious
Control: close -1 2.0.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:ruby-parslet has been trying to migrate 
for 79 days [2]. Hence, I am filing this bug. The version in unstable 
causes autopkgtest issues in src:ruby-toml (although from the log it's 
not clear why as all tests seem to pass but still exit code is 1).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=ruby-parslet



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070988: src:q2-feature-table: fails to migrate to testing for too long: autopkgtest regression


Source: q2-feature-table
Version: 2023.9.0+dfsg-1
Severity: serious
Control: close -1 2024.2.0+dfsg-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:q2-feature-table has been trying to 
migrate for 84 days [2]. Hence, I am filing this bug. The version in 
unstable fails its own autopkgtest.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=q2-feature-table



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070987: src:tiktoken: fails to migrate to testing for too long: autopkgtest regression


Source: tiktoken
Version: 0.4.0-2
Severity: serious
Control: close -1 0.6.0-3
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:tiktoken has been trying to migrate for 84 
days [2]. Hence, I am filing this bug. The version in unstable fails its 
own autopkgtest.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=tiktoken



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070982: src:click: fails to migrate to testing for too long: autopkgtest regression on !amd64


Source: click
Version: 0.5.0-10
Severity: serious
Control: close -1 0.5.2-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:click has been trying to migrate for 60 
days [2]. Hence, I am filing this bug. The autopkgtest of the version in 
unstable fails everywhere except on amd64.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=click



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068363: src:autopkgtest: flaky autopkgtest (host dependent?) on ppc64el


Control: tags -1 pending

Hi,

On 06-04-2024 9:58 p.m., Paul Gevers wrote:
Anyways, it looks like we could just lower the timeout to 1 second and 
hope were fine for some time to come.


No. 1 second is *too short* for the PodmanRunner.test_copy_timeout test 
on salsa. So I'll just disable the test for now.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070818: src:libcbor: fails to migrate to testing for too long: FTBFS on mips64el


Source: libcbor
Version: 0.10.2-1.1
Severity: serious
Control: close -1 0.10.2-1.2
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:libcbor has been trying to migrate for 83 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build from source on mips64el.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=libcbor



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070816: src:wsdd: fails to migrate to testing for too long: uploader built arch:all binaries


Source: wsdd
Version: 2:0.7.0-2.1
Severity: serious
Control: close -1 2:0.7.1-5
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:wsdd has been trying to migrate for 82 
days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=wsdd



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070814: src:snapraid: fails to migrate to testing for too long: FTBFS on mips64el


Source: snapraid
Version: 12.2-1
Severity: serious
Control: close -1 12.3-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:snapraid has been trying to migrate for 84 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on mips64el.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=snapraid



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070813: src:camelot-py: fails to migrate to testing for too long: autopkgtest failure on ppc64el


Source: camelot-py
Version: 0.11.0-3
Severity: serious
Control: close -1 0.11.0-4
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1063891

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:camelot-py has been trying to migrate for 
86 days [2]. Hence, I am filing this bug. As you noticed yourself (in 
bug 1063891) the autopkgtest fails on ppc64el. If you can't easily fix 
it, I suggest you make the test failure on ppc64el not blocking. You can 
do that by either using the Architecture field in d/t/control 
("!ppc64el" works), but I don't recommend that because changes to the 
results would go unnoticed and it would be harder to get a log. 
Alternatively you can annotate the test with the flaky restriction, but 
that would cause failure on !ppc64el to go unnoticed. So, I would 
recommend using the skippable restriction and "exit 77" when the test 
fails on ppc64el (but that's a bit more work to embed in the test).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=camelot-py



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070810: src:unattended-upgrades: fails to migrate to testing for too long: FTBFS


Source: unattended-upgrades
Version: 2.9.1+nmu4
Severity: serious
Control: close -1 2.10
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:unattended-upgrades has been trying to 
migrate for 87 days [2]. Hence, I am filing this bug. The version in 
unstable failed to build.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=unattended-upgrades



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070809: src:multiqc: fails to migrate to testing for too long: depends on package that doesn't migrate


Source: multiqc
Version: 1.14+dfsg-1.1
Severity: serious
Control: close -1 1.18+dfsg-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:multiqc has been trying to migrate for 87 
days [2]. Hence, I am filing this bug. The version in unstable has a new 
(Build-)Depends that's not ready to migrate yet (it needs a source-full 
upload).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=multiqc



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069389: kiwi: FTBFS on arm64: ImportError: sys.meta_path is None, Python is likely shutting down

2024-05-09 Thread John Paul Adrian Glaubitz

Hello,

On Sat, 2024-04-20 at 14:05 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on arm64.
> (...)
> The full build log is available from:
> http://qa-logs.debian.net/2024/04/20/kiwi_9.25.22-1_unstable-arm64.log
> 
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240420;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240420=lu...@debian.org=1=1=1=1#results
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please mark it as 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.

FWIW, I am already working on updating the kiwi package in Debian to the latest
upstream version. However, I ran into some testsuite issues that need to be 
sorted
out upstream first [1].

Thanks,
Adrian

> [1] https://github.com/OSInside/kiwi/issues/2548

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1070771: upgrade-reports: After updating with apt upgrade, writing dead keys in Portuguese stopped working


Hi

On 08-05-2024 10:27 p.m., Eduardo Rolim wrote:

After the upgrade, the system no longer recognizes Portuguese accents,
rendering typing of accents impossible.


Might this be related to 
https://lists.debian.org/debian-security-announce/2024/msg00094.html


If so, updating glib2.0 with the latest version in stable-security 
should solve the problem.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

2024-05-07 Thread Paul Gevers


Hi,

On 07-05-2024 7:49 p.m., Simon McVittie wrote:

The version in testing, 4.12.5+ds-3, has the same dependencies, so this
is not a regression.


Is it? It seems that the version in unstable depends on 
libpng16-16t64-udeb where the version in testing depends on 
libpng16-16-udeb. The later exists, the former not.



Is this requirement newly enforced by britney?


No.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070708: unblock: rust-chrono/0.4.38-2

2024-05-07 Thread Paul Gevers


Hi,

On 07-05-2024 5:55 p.m., plugwash wrote:

Can you figure out what is going wrong and either fix it or override the tests?


As noted on IRC, it's unclear what caused this. I retriggered the test 
and it's now picked up.


For those watching, britney2 would have done this by itself too after 5 
days:

https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py?ref_type=heads#L138

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069265: tzdata: Upgrade from 2023c-2 to 2024 corrupts zoneinfo files

2024-05-06 Thread Plasma (David Paul)

On Thu, 18 Apr 2024 23:39:14 + IvanAbs  wrote:
> On 2024-04-17 several of my servers running Debian 10 received an
> update for the tzdata package via Debian unattended-upgrade. However,
> this update resulted in corruption of files within the
> /usr/share/zoneinfo directory.

I, too, encountered a variation of this issue today while trying to
update the tzdata package on my system. I was eventually able to resolve
the issue with a little manual intervention. Details follow.

> I was using tzdata 2023c-2 package, and originally installed from an
> official Debian source

In my case, the installed version of the package was tzdata 2023c-5.

> I installed tzdata 2023c-2 with dpkg -i, because our severs needs the
> last-year updated data, but there were not a release for Debian 10,
> until yesterday.

Similarly, I had installed tzdata 2023c-5 on what is effectively Debian
Bullseye install (though what is actually an unabashed FrankenDevuan
install that is mostly composed of packages from Devuan's Chimaera
release). My motivation for doing so was similar: I wanted the
then-current timezone database and the package in chimaera/bullseye had
yet to be updated. I fully acknowledge this course of action is
actively frowned upon[1].

[1] https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian

> To resolve this issue, I had to completely remove the tzdata 2023
> version and perform a clean installation of the new tzdata 2024
> version.

Here's how I was able to resolve the issue. Using snapshot.debian.org,
I downloaded tzdata_2023d-1_all.deb which installed without issue over
2023c-5. Afterward, I was able to install tzdata 2024a-0+deb11u1
without issue.

As this issue only manifests on systems in explicitly unsupported
configurations, the severity of the bug should probably be reduced from
grave, but I will leave that decision to others.

I hope this was helpful,

-- 
Plasma

Bug#1054109: ocaml: lack of LoongArch support

2024-05-06 Thread John Paul Adrian Glaubitz

Hi LiXing,

> [0001-Add-LoongArch-support-for-ocaml.patch (text/plain, attachment)]

I'm afraid this patch is way too large to be included in a Debian package.

Please make sure these changes are being upstreamed, so that native LoongArch
support will be part of the next major Ocaml upstream release in Debian.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1069600: Fwd: dm-writeboost: isolation-machine autopkgtest fails: sudo: not found


Hi,

On 05-05-2024 8:04 p.m., Andreas Beckmann wrote:
167s autopkgtest [09:50:25]: test test-dm-writeboost.sh: 
[---

168s II: Checking for 14G available disk space...SKIP


How much disk space is used already by the time you get to this test? 
The root of the testbed has 25 GB total (starting off with 990 MB used), 
so your test has 24 GB to use (including installing test dependencies).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Hi Luca,

On 05-05-2024 10:04 p.m., Luca Boccassi wrote:

> Hence, I intend to apply these changes in the next src:systemd upload
> to unstable, probably next week.

In case anybody is aware of packages/programs needing an update to cope
with these changes, or any other issue, please let me know and I will
file bugs.

You filed MR341 against autopkgtest, thanks for that. Can you please 
hold off a bit longer than only one week to get the infrastructure 
updated? I'm confident that every test that has the needs-reboot 
restriction will start failing (which are only 21 tests according to 
codesearch). However, I fear that every test is at risk under common 
circumstances.

I don't want to be rushed into an autopkgtest update and an 
infrastructure update for something that we can plan (there's always 
risk involved and I want to have the time and peace to cope with the 
process). Having said that, maybe we will be ready next week.

Paul

OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070401: sqlite3 breaks tracker autopkgtest: killed by signal 6 SIGABRT


Control: reassign -1 src:tracker
Control: found -1 3.4.2-3
Control: affects -1 src:sqlite3

Hi László,

On 05-05-2024 11:24 a.m., László Böszörményi (GCS) wrote:

It's the tracker autopkg testing that needs fixing.


So, I'm inclined to agree with your assessment, so let's reassign this 
to src:tracker.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070422: src:intel-vc-intrinsics: unsatisfied build dependency in testing: llvm-14-dev


Source: intel-vc-intrinsics
Version: 0.18.0-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing. We have several version of src:llvm-toolchain-* in 
Debian, 14 is not going to come back into testing as it's too old. 
You'll have to use a newer version, ideally using the non-versioned 
default flavor: llvm-dev.


Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070421: src:mac-widgets: unsatisfied build dependency in testing: libjgoodies-forms-java-doc


Source: mac-widgets
Version: 0.10.0+svn416-dfsg1-3
Severity: serious
Tags: sid trixie ftbfs
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing. src:libjgoodies-forms-java stopped building 
libjgoodies-forms-java-doc in it's latest upload, so your package can no 
longer be build in unstable either.


Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070420: src:vagrant: unsatisfied build dependency in testing: ruby-net-ftp (>= 0.2) | ruby-net-ftp (>= 0.2)


Source: vagrant
Version: 2.3.6+dfsg-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing. ruby3.2 which provides these versions of 
ruby-net-ftp is currently blocked by three RC bugs. I also note that the 
runtime dependency of bin:vagrant is non-versioned.


Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070419: src:gnome-snapshot: unsatisfied build dependency in testing: librust-gst-plugin-gtk4-0.11-dev


Source: gnome-snapshot
Version: 46~beta-2
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing. It also currently prevents the migration of the 
version in unstable.


Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070418: rapiddisk: autopkgtest regression: Bad return status for module build on kernel: 6.7.12-rt-amd64 (x86_64)


Source: rapiddisk
Version: 9.1.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it recently started 
failing in unstable and testing. Can you please investigate the 
situation and fix it? I copied some of the output at the bottom of this 
report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/r/rapiddisk/unstable/amd64/46311856/

134s Failed command:
134s make -j64 KERNELRELEASE=6.7.12-rt-amd64 -C 
/lib/modules/6.7.12-rt-amd64/build 
M=/var/lib/dkms/rapiddisk-dkms/9.1.0/build
134s Error! Bad return status for module build on kernel: 
6.7.12-rt-amd64 (x86_64)
134s Consult /var/lib/dkms/rapiddisk-dkms/9.1.0/build/make.log for more 
information.

134s E: rapiddisk-dkms/9.1.0 failed to build for 6.7.12-rt-amd64
134s == /var/lib/dkms/rapiddisk-dkms/9.1.0/build/make.log ==
134s DKMS make.log for rapiddisk-dkms-9.1.0 for kernel 6.7.12-rt-amd64 
(x86_64)

134s Sun May  5 07:20:50 UTC 2024
134s make: Entering directory '/usr/src/linux-headers-6.7.12-rt-amd64'
134s   CC [M]  /var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk.o
134s   CC [M]  /var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.o
134s /var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.c: In 
function ‘dm_io_async_bvec’:
134s /var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.c:198:16: 
error: too few arguments to function ‘dm_io’

134s   198 | return dm_io(, num_regions, where, NULL);
134s   |^
134s In file included from 
/var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.c:46:
134s /usr/src/linux-headers-6.7.12-common-rt/include/linux/dm-io.h:82:5: 
note: declared here
134s82 | int dm_io(struct dm_io_request *io_req, unsigned int 
num_regions,

134s   | ^
134s /var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.c:199:1: 
error: control reaches end of non-void function [-Werror=return-type]

134s   199 | }
134s   | ^
134s cc1: some warnings being treated as errors
134s make[2]: *** 
[/usr/src/linux-headers-6.7.12-common-rt/scripts/Makefile.build:248: 
/var/lib/dkms/rapiddisk-dkms/9.1.0/build/rapiddisk-cache.o] Error 1

134s make[2]: *** Waiting for unfinished jobs
134s make[1]: *** 
[/usr/src/linux-headers-6.7.12-common-rt/Makefile:1936: 
/var/lib/dkms/rapiddisk-dkms/9.1.0/build] Error 2
134s make: *** [/usr/src/linux-headers-6.7.12-common-rt/Makefile:246: 
__sub-make] Error 2

134s make: Leaving directory '/usr/src/linux-headers-6.7.12-rt-amd64'


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070416: src:diffoscope: unsatisfied build dependency in testing: aapt


Source: diffoscope
Version: 259
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#965386: plasma-browser-integration: Please package Firefox extension

On Mon, 20 Jul 2020 20:24:38 +0200 Michael Weghorn wrote:

> Note: The file 'dev_README.txt' in the sources describes how to build the
> extension, but this probably cannot be followed as is, since it involves
> installing packages via "npm" in the first step (which is not in line with
> Debian's packaging practices).

None of that is actually needed, since you just can symlink the
directory into the Firefox and Chromium extension directories:

   sudo cp -a extension/ /usr/share/webext/plasma
   sudo ln -s /usr/share/webext/plasma 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/$(jq -r 
.applications.gecko.id < extension/manifest.json)
   sudo ln -s /usr/share/webext/plasma /usr/share/chromium/extensions/plasma

I have tested that this works on Debian firefox/firefox-esr/chromium.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#926618: RFP: webext-plasma-integration

On Mon, 6 Dec 2021 14:47:24 + Phil Morrell wrote:

> Would be nice to see this packaged, since the native part is already
> available, under the affects package name. Note, I'm not even using this
> under KDE, it works perfectly fine under XFCE.

As I mentioned in #965386, this is easy to add to the package:

   sudo cp -a extension/ /usr/share/webext/plasma
   sudo ln -s /usr/share/webext/plasma 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/$(jq -r 
.applications.gecko.id < extension/manifest.json)
   sudo ln -s /usr/share/webext/plasma /usr/share/chromium/extensions/plasma

I think this RFP should be closed in favour of #965386, which would
simply included the needed files in plasma-browser-integration itself.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1016957: remove kbd-chooser from the archive?

2024-05-04 Thread Paul Gevers


Hi

On 04-05-2024 3:36 p.m., Holger Wansing wrote:

I think Bastian's approach is, to remove kbd-chooser from the archive, since
it was stated (see below) that it's no longer in use.


It might be that udd assumes all packages that build a udeb are used.


d-i has switched away from it to console-setup 12 years ago with
https://salsa.debian.org/installer-team/debian-installer/-/commit/2575a669e91252a6253430020137154c995c9b38


I did check the d-i repository and there are still references to 
kbd-chooser, so I *assumed* it was still used.



Are there any ports maybe, that still use it somehow?
Or what about derivatives?
It's an udeb-only package, so the use in the installer is the only imaginable
scenario...
If you're sure it's not used, I can work around udd and have it at least 
removed from testing. I think a bug retitle (or separate bug) would have 
been better. The current bug isn't RC.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069755: libntlm0: broken symlink: README -> README.md

On Fri, 2024-05-03 at 13:35 +0200, Simon Josefsson wrote:

> I wonder why no QA tool reported this?

As implied by the usertags I used, the adequate tool found it:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

In addition, piuparts has a test for broken symlinks too, and as
well as that it runs adequate, which also found the broken symlink:

https://piuparts.debian.org/sid/pass/libntlm0_1.8-2.log

> Seems like a simple thing for lintian to discover?

For this specific case lintian could do something, but in the general
case that is impossible, because symlinks can point at files owned by
another package, which could be in depends, or recommends or suggests,
or even be something the sysadmin is expected to download later.

> Or did you use some tool to discover this that isn't linked from the PTS?

The piuparts pages are only linked from the PTS when there is an error,
but invalid symlinks and most adequate issues don't count as errors.

Perhaps it should change to always link piuparts in the right panel and
to raise minor TODO items when symlink and adequate issues are present.

> A patch like the one below seems to fix this.  But maybe we should raise
> a lintian wishlist bug report too.

Feel free to raise any extra bugs. Please XCC me if you do.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

Bug#1070351: fracatux: Homepage redirects to https://educajou.forge.apps.education.fr/fracatux/

Package: fracatux
Version: 1.5.2~rc0-1
Severity: minor

The Homepage for fracatux currently points to a URL that has a
JavaScript based redirect to this URL, which has fracatux info:

https://educajou.forge.apps.education.fr/fracatux/

Please update the Homepage for fracatux to the new URL.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1035474: src:libdmx Bug#1035474: Don't include in Bookworm?

2024-05-04 Thread Paul Gevers


clone 1035474 -1
block 1035474 by -1
reassign -1 xorg-dev
retitle -1 xorg-dev: drop dependency on libdmx-dev
found -1 1:7.7+23
thanks

On Wed, 31 May 2023 08:50:16 +0200 Moritz Muehlenhoff  
wrote:

On Wed, May 31, 2023 at 09:28:02AM +0300, Timo Aaltonen wrote:
> Moritz Muehlenhoff kirjoitti 3.5.2023 klo 20.44:
> > Source: libdmx
> > Version: 1:1.1.4-2
> > Severity: serious
> > 
> > The Xorg folks mentioned at https://www.openwall.com/lists/oss-security/2023/05/02/3:
> > 
> > | We have also announced that we plan to retire the following packages soon

> > | and while their gitlab repos are not yet archived, we expect they will be
> > | archived in the future, and encourage distros that still ship them to
> > | consider retiring them on your side as well:
> > |
> > | lib/libdmx:
> > |  The Xdmx server was removed from the xorg-server sources in
> > |  xorg-server 21 (released Oct. 2021), so this is only useful
> > |  for communicating with Xdmx from the 1.20 and older releases.
> > 
> > Given that Bookworm has xorg-server 21 and there are no rdeps in the archive,

> > let's exclude it from bookworm (and remove entirely eventually)?
> 
> sounds good


Unfortunately I missed that xorg-dev depends on libdmx-dev, so this will have to
wait until after the Bookworm release.


Let's make a bug for xorg-dev then. I'm *assuming* it's no longer needed.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070349: onionshare-cli: common.py: SyntaxWarning: invalid escape sequence '\s'

Package: onionshare-cli
Version: 2.6.2-1
Severity: normal
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Upgrading onionshare-cli gives Python 3.12 warnings,
the right way to fix this is to use raw strings:

https://docs.python.org/3/library/re.html#raw-string-notation

   Setting up onionshare-cli (2.6.2-1) ...
   /usr/lib/python3/dist-packages/onionshare_cli/common.py:487: SyntaxWarning: 
invalid escape sequence '\s'
 
"(obfs4\s+)?(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]):([0-9]+)(\s+)([A-Z0-9]+)(.+)$"
   /usr/lib/python3/dist-packages/onionshare_cli/common.py:490: SyntaxWarning: 
invalid escape sequence '\s'
 
"(obfs4\s+)?\[(([0-9a-fA-F]{1,4}:){7,7}[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,7}:|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|:((:[0-9a-fA-F]{1,4}){1,7}|:)|fe80:(:[0-9a-fA-F]{0,4}){0,4}%[0-9a-zA-Z]{1,}|::((:0{1,4}){0,1}:){0,1}((25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])|([0-9a-fA-F]{1,4}:){1,4}:((25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9]))\]:[0-9]+\s+[A-Z0-9]+(.+)$"
   /usr/lib/python3/dist-packages/onionshare_cli/common.py:493: SyntaxWarning: 
invalid escape sequence '\s'
 
"(meek_lite)(\s)+([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+:[0-9]+)(\s)+([0-9A-Z]+)(\s)+url=(.+)(\s)+front=(.+)"
   /usr/lib/python3/dist-packages/onionshare_cli/common.py:496: SyntaxWarning: 
invalid escape sequence '\s'
 "(snowflake)(\s)+([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+:[0-9]+)(\s)+([0-9A-Z]+)"

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages onionshare-cli depends on:
ii  cython3   3.0.10+dfsg-5
ii  python3   3.11.8-1
ii  python3-cffi  1.16.0-2
ii  python3-click 8.1.7-1
ii  python3-colorama  0.4.6-4
ii  python3-eventlet  0.35.1-1
ii  python3-flask 3.0.3-1
ii  python3-flask-compress1.4.0-5
ii  python3-flask-socketio5.3.6-2
ii  python3-gevent24.2.1-0.1+b1
ii  python3-gevent-websocket  0.10.1-5
ii  python3-nacl  1.5.0-4
ii  python3-packaging 24.0-1
ii  python3-pkg-resources 68.1.2-2
ii  python3-psutil5.9.8-2
ii  python3-qrcode7.4.2-5
ii  python3-requests  2.31.0+dfsg-1
ii  python3-socks 1.7.1+dfsg-1
ii  python3-stem  1.8.2-1
ii  python3-unidecode 1.3.8-1
ii  python3-urllib3   1.26.18-2
ii  python3-waitress  2.1.2-2
ii  python3-werkzeug  3.0.2-1
ii  python3-wheel 0.43.0-1
ii  tor   0.4.8.11-1

Versions of packages onionshare-cli recommends:
ii  obfs4proxy  0.0.14-1+b7

onionshare-cli suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1016957: kbd-chooser: please add support for riscv64

2024-05-03 Thread Paul Gevers

Hi Bastian,

On Sat, 9 Sep 2023 19:03:07 +0200 Bastian Germann  wrote:

Control: severity -1 serious

Can you please elaborate? I'm not seeing anything serious in this bug 
report.

On Wed, 10 Aug 2022 21:42:34 +0200 Holger Wansing  wrote:
> kbd-chooser is no longer in use, I think.
> Or am I missing something?

I am raising severity to serious then so that it can be autoremoved from 
testing.

This package is a key package (because of debian-installer), so it can't 
be autoremoved.

Paul

OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070163: socat: support duplicating data to multiple clients of listening socket?

2024-05-02 Thread Paul Wise

On Wed, 2024-05-01 at 11:48 +0200, Gerhard Rieger wrote:

> Socat is not able to do this, and there is currently no plan to 
> implement this feature.
> 
> However, due to the repeated requests, a script socat-mux.sh has been
> written and released with Socat 1.8.0.0 that is able to provide 
> many-to-one, one-to-all communications. Internally it utilizes two Socat 
> (parent) processes that use UDP broadcast on loopback interface for data 
> multiplication. Please note that this has a security risk because local 
> users are able to join the communications.

Thanks for the info!

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#661461: ITA: unadf -- Extract files from an Amiga Disk File dump (.adf)

2024-05-01 Thread John Paul Adrian Glaubitz

On Wed, 2024-05-01 at 23:36 +0200, Petter Reinholdtsen wrote:
> Hi,
> 
> [John Paul Adrian Glaubitz 2020-05-10]
> > I would like to adopt this package. There is a new upstream available and 
> > the
> > repository has been moved to Github with some recent activity [1].
> 
> What came out of this intent?
> 
> I just migrated the package to a git repository on
> https://salsa.debian.org/debian/unadf >.

I started working on this, but I got stuck because of the fact that the upstream
package is actually not just unadf but a whole library that might need different
treatment.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1070221: lintian: warn about help2man generated pages containing errors loading shared libraries

2024-05-01 Thread Paul Wise

Package: lintian
Severity: wishlist

For manual pages generated by tools like help2man that run binaries to
get usage statements for conversion to manual page format, please check
that the manual pages do not contain common text indicating that the
executable or script was not able to run successfully, so didn't output
any usage statement and so a useful manual page was not generated.

For example when running an ELF executable:

   $ ./src/jbig2
   jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot open 
shared object file: No such file or directory
   
   $ zcat /usr/share/man/man1/jbig2.1.gz
   .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.49.3.
   .TH JBIG2: "1" "February 2024" "jbig2: error while loading shared libraries: 
libjbig2enc.so.0: cannot open shared object file: No such file or directory" 
"User Commands"
   .SH NAME
   jbig2: \- encoder for JBIG2
   .SH DESCRIPTION
   src/jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot 
open shared object file: No such file or directory

For example when running a Python script:

   $ ./foo.py 
   Traceback (most recent call last):
 File "./foo.py", line 2, in 
   import bar
   ImportError: No module named bar
   
   $ help2man --no-discard-stderr ./foo.py 
   .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.49.3.
   .TH TRACEBACK "1" "May 2024" "Traceback (most recent call last):"
"User Commands"
   .SH NAME
   Traceback \- manual page for Traceback (most recent call last):
   .SH DESCRIPTION
   .SS "Traceback (most recent call last):"
   .IP
   File "./foo.py", line 2, in 
   .IP
   import bar
   .PP
   ImportError: No module named bar
   .IP
   File "./foo.py", line 2, in 
   .IP
   import bar
   .PP
   ImportError: No module named bar
   .SH "SEE ALSO"
   The full documentation for
   .B Traceback
   is maintained as a Texinfo manual.  If the
   .B info
   and
   .B Traceback
   programs are properly installed at your site, the command
   .IP
   .B info Traceback
   .PP
   should give you access to the complete manual.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1070220: jbig2: broken manual page: src/jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot open shared object file: No such file or directory

2024-05-01 Thread Paul Wise

Package: jbig2
Version: 0.29-2.1
Severity: normal
Usertags: help2man

The jbig2 manual page is broken. Looks like it was generated via
help2man using the binary in the build tree but without using
LD_LIBRARY_PATH so the binary could not find libraries it uses,
so jbig2 could not start, so it didn't print the usage statement
and help2man did not convert the usage statement to a manual page.
The help2man conversion in debian/rules may have some kind of problem.

   $ COLUMNS=80 man jbig2 | cat
   JBIG2:(1)User Commands   
JBIG2:(1)
   
   NAME
  jbig2: - encoder for JBIG2
   
   DESCRIPTION
  src/jbig2: error while loading shared libraries: libjbig2enc.so.0: 
can‐
  not open shared object file: No such file or directory
   
   jbig2: error while loading sh... February 2024   
JBIG2:(1)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1070219: python3-pyasn: init.py:201: SyntaxWarning: invalid escape sequence '\.'

2024-05-01 Thread Paul Wise

Package: python3-pyasn
Version: 1.6.1-3+b4
Severity: normal
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

When installing pyasn I get a syntax warning with Python 3.12,
the fix would be to use raw strings with Python regexes:

https://docs.python.org/3/library/re.html#raw-string-notation

   Selecting previously unselected package python3-pyasn.
   Preparing to unpack .../16-python3-pyasn_1.6.1-3+b4_amd64.deb ...
   Unpacking python3-pyasn (1.6.1-3+b4) ...
   Setting up python3-pyasn (1.6.1-3+b4) ...
   /usr/lib/python3/dist-packages/pyasn/__init__.py:201: SyntaxWarning: invalid 
escape sequence '\.'
 pattern = re.compile("^[AS]|[as]|[aS]|[As]][0-9]*(\.)?[0-9]+")

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages python3-pyasn depends on:
ii  libc62.37-19
ii  python3  3.11.8-1

python3-pyasn recommends no packages.

python3-pyasn suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1070163: socat: support duplicating data to multiple clients of listening socket?

2024-04-30 Thread Paul Wise

Package: socat
Severity: wishlist
X-Debbugs-Cc: so...@dest-unreach.org
Forwarded: so...@dest-unreach.org

socat does not appear to have a way to send data to multiple clients of
a listening socket, which would be useful to proxy data from overloaded
servers to multiple local clients.

For example:

   socat TCP-CONNECT:1.2.3.4:1234 UNIX-LISTEN:sock,unlink-early=1 &
   socat UNIX-CONNECT:out STDOUT &
   socat UNIX-CONNECT:out STDOUT &

The second client is not allowed to connect to the socket:

   2024/05/01 13:12:32 socat[957352] E connect(, AF=1 "out", 5): Connection 
refused

This can be achieved, by using this nmap ncat command:

   ncat --listen --unixsock out --keep-open --send-only

This appears to work by reading some data, then writing it
to all the client sockets, then repeating the process.

Unfortunately ncat breaks when one of the clients terminates,
so ncat currently does not appear to be useful for this yet.

   Ncat: Program bug: fd (4) not on list. QUITTING.

PS: some places on the web where people are looking for this feature,
for both local Unix domain stream sockets and local TCP ports:

https://serverfault.com/questions/747980/simpliest-unix-non-blocking-broadcast-socket
https://unix.stackexchange.com/questions/195880/socat-duplicate-stdin-to-each-connected-client
https://stackoverflow.com/questions/17480967/using-socat-to-multiplex-incoming-tcp-connection
https://gist.github.com/mathieue/3505472

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1070040: bookworm-pu: package dm-writeboost/???

2024-04-30 Thread Paul Gevers


Hi,

On 30-04-2024 8:54 a.m., Andreas Beckmann wrote:
Can you point me to the code that evaluates dpkg's Testsuite-Triggers to 
schedule these tests? Maybe it's possible to convert dpkg's Testsuite 
field to a (hardcoded) list of additional triggers ...


I think you mean this: 
https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/utils.py?ref_type=heads#L609


Or probably more something like this one: 
https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py?ref_type=heads#L615 
and where it's used.


Having said that, I'm not a great fan of teaching britney2 about 
autodep8 internal details.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070040: bookworm-pu: package dm-writeboost/???

2024-04-29 Thread Paul Gevers


Hi,

On 30-04-2024 12:43 a.m., Andreas Beckmann wrote:

Testsuite: autopkgtest-pkg-dkms


Right. I was talking about Testsuite-Triggers in the sources file 
generated by dpkg. Unfortunately the automation one gets with autodep8 
doesn't extend that far and the triggers you are interested in are 
missing. Currently in unstable dm-writeboost has:

Testsuite-Triggers: dkms, dmsetup, stress-ng

(The dependencies for the first test contain unreleased changes that 
will try to fix the isolation-machine test, so you might see fewer deps 
on the package currently in the archive.)


That will fix the problem at hand.

Perhaps you can spot what's wrong with this setup s.t. it does not 
trigger as intended.


I hope it's clear now. Related, for future reference, we also have the 
hint-testsuite-triggers [1] restriction in autopkgtest.


Paul

[1] 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070040: bookworm-pu: package dm-writeboost/???

2024-04-29 Thread Paul Gevers


Hi Andreas,

On 29-04-2024 10:52 a.m., Andreas Beckmann wrote:

These failures could show up as autopkgtest failures in bookworm-pu.
Are they flagged somewhere in your tooling s.t. they don't go unnoticed?


As I hinted at in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069600#25, once 
there's an *test* dependency relation with linux, this will be tested. 
Current regressions can be seen here: 
https://release.debian.org/proposed-updates/stable.html, look for "c-i".


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070018: ausweisapp: Mising dependency to libqt6svg6

2024-04-28 Thread John Paul Adrian Glaubitz

Hello Juergen,

On Sun, 2024-04-28 at 18:09 +0200, Juergen Bausa wrote:
> I run ausweisapp backport on bookworm. However, it doesnt display an icon in 
> the control panel of KDE. 
> Ausweisapp2 (which is actually a slightly older version) did display an icon. 
> While ausweisapp2 depended 
> on libqt6svg6, ausweisapp does not. Aftre installing libqt6svg6 manually the 
> icon is displayed in ausweisapp
> also. So I think the dependency on libqt6svg6 is just missing in ausweisapp.

This is a known issue and a result of a potential bug in Qt6 which results in 
dpkg-shlibdeps not adding
the runtime dependency for libqt6svg6 during build. While I could hardwire 
libqt6svg6 as a runtime
dependency into debian/control, this would cause problems when the ABI of the 
Qt6 SVG library is being
bumped resulting in the library package being renamed from libqt6svg6 to 
libqt6svg7.

Currently, the workaround is to install the missing libqt6svg6 package manually.

> In addition it seems to me that the window of AusweisApp looks extremely 
> clean (just white background).
> Ausweisapp2 was much more colourful. I guess that another lib is missing for 
> ausweisapp to display
> the intended look.

No, this is by design. The upstream developers have decided to make the user 
interface as minimalistic
as possible. I'm not such a fan of the new design either, but that's just how 
it looks now.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1069600: Fwd: dm-writeboost: isolation-machine autopkgtest fails: sudo: not found

2024-04-28 Thread Paul Gevers


Hi,

On 28-04-2024 9:34 a.m., Andreas Beckmann wrote:
What kernel is running inside the test environment and what is the best 
way to install its headers?


Can you help me find the answer? I guess you don't mean "the current 
kernel of the suite under test" but rather a flavor? We use 
autopkgtest-build-qemu, which uses vmdb2, to build the image. The kernel 
used is also logged in the autopkgtest log, so you can also look it up :).



Would Depends: linux-headers-generic work?


I don't know.


Or better in the test script to
   test -d /lib/modules/$(uname -r)/build || \
   apt-get install linux-headers-$(uname -r)


But I have a strong preference for (test) Depends over running $(apt-get 
install) inside the test for two reasons:
1) you get Autopkgtest-Triggers for the kernel (headers) for free, 
meaning that we'll know if the kernel breaks this package
2) the autopkgtest setup for migration is a bit weird and getting it 
right shouldn't be the responsibility of the test [1].


Paul

[1] 
https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices 
(under "Don't").


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#987017: release-notes: Giving many ways to do something is useful

2024-04-28 Thread Paul Gevers


Hi,

[Release Team member hat on]

On 27-04-2024 11:48 p.m., Manny wrote:

As an aptitude user, I was bothered by the lack of aptitude ways of
doing things in the upgrade guide.


I anything, I prefer the Release Notes to move to using one tool in the 
instructions, without insinuating that it's the only way. I think that 
tool should be apt nowadays. We've made steps in that direction during 
the last release cycle, i.e. we moved away from aptitude.



Whether someone wants to know a bit of many tools or be a master of
few tools is a matter of preference, but the docs would ideally
accommodate both kinds of users (though not necessarily in the same
doc… that’s another matter - but if the different methods are
side-by-side in the same doc it helps users learn about the
equivalences and makes it easier for them to settle on a preferred
method). But certainly it’s sensible to drop methods that have no
advantage of any kind.


I don't think it's the role of the Release Notes to do this. We should 
show a consistent document and use examples that work. Which also means 
we should ensure they remain working. Doing that work for multiple tools 
is extra work I don't want to spend.



The advice I was given early in my Debian years was that apt-get was a
more primitive command and aptitude was more complete/comprehensive,


I understood that that used to be the case in the past. apt is now much 
more apt.



that it logs or tracks more things and generally the better tool
according to folks giving IRC support. I think aptitude calls apt
IIRC, which makes it a higher level tool.


Both call libapt-pkg6.0(|t64), both are higher level tools using the 
same library, just like packagekit and synaptic and more.



I am not sure we should tell people to "remove any non-Debian package"
before the upgrade. They might have legitimate reasons to have
third-party package repositories...?


Concur. I’m not sure what the past release notes said, but the
Bookworm release notes simply bluntly direct users to “Remove
non-Debian packages”. This was frustrating for me. **Why?** I want to
know why I am doing something. The list of non-Debian packages
contained pkgs *I need*. Users need to know why they are directed to
destroy something they need.


Ok, so we should give more reason, see below and patches welcome.


Is there a real likeliness that a non-Debian pkg will make a mess or
disaster of the upgrade?  Or is this step a generic “we only
officially support our officially distributed software” scenario?


non-debian package can create situations where apt (the library) can't 
resolve the situation anymore or has more difficulty. And then yes, it 
should be clear you're on your own to solve the situation. I *think* 
that apt can opt for removal of packages in some situations. Normally 
for a pure Debian system, you would expect that to happen for things you 
still need (and a bug would be fair), while if it happens because on 
non-Debian packages, it's unfair to call that a Debian bug.



I decided to go against the guidance. There was one non-Debian pkg
that I no longer used, so removal was a trivial choice for that
one. But I left the other non-Debian pkgs alone. Some of them broke
and some survived.


Ack.


The guide should probably suggest removing any non-Debian pkgs that
are not needed to mitigate dependency complications, but simply warn
that non-Debian pkgs allowed to persist might not run correctly and
should be also treated with low priority if conflicts arise.


Agreed. Or might cause other packages to be removed, so extra care and 
attention during the upgrade is needed.



If the guide is intended to help train the user and advance their
Debian skills, then the CLI advice is probably favorable because it’s
more likely to improve the user’s knowledge than a UI that needs no
manual.


That's not the purpose of the Release Notes.


As an aptitude user, my temptation is to look for the aptitude
approach. So merely omitting aptitude from the guide only encumbers
aptitude users. If there is a good reason for omitting an aptitude
approach, the guide should state why. Otherwise users might question
the quality and comprehensiveness of the guide.


We could add a statement that while more tools exist. All automated 
testing of upgrades that I know of use apt-get, so that's the obvious 
choice. aptitude doesn't get as much testing.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069988: onboard: Onboard/Appearance.py: SyntaxWarning: invalid escape sequence '\w'

2024-04-27 Thread Paul Wise

Package: onboard
Version: 1.4.1-6
Severity: normal
File: /usr/lib/python3/dist-packages/Onboard/Appearance.py
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

The recent upgrade of onboard triggers Python 3.12 syntax warnings,
the correct fix is to use Python's "raw" strings feature with regexes.

https://docs.python.org/3/library/re.html#raw-string-notation

   Unpacking onboard (1.4.1-6) over (1.4.1-5+b7) ...
   Preparing to unpack .../7-onboard-common_1.4.1-6_all.deb ...
   Unpacking onboard-common (1.4.1-6) over (1.4.1-5) ...
   Setting up onboard-common (1.4.1-6) ...
   Setting up onboard (1.4.1-6) ...
   /usr/lib/python3/dist-packages/Onboard/Appearance.py:924: SyntaxWarning: 
invalid escape sequence '\w'
 _key_ids_pattern = re.compile('[\w-]+(?:[.][\w-]+)?', re.UNICODE)
   /usr/lib/python3/dist-packages/Onboard/Appearance.py:1066: SyntaxWarning: 
invalid escape sequence '\w'
 key_ids = [x for x in re.findall('\w+(?:[.][\w-]+)?', text) if x]
   Setting up onboard-data (1.4.1-6) ...
   Setting up onboard-dbgsym (1.4.1-6) ...

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'stable-updates'), (500, 'stable-security-debug'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages onboard depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-3+b3
ii  gir1.2-glib-2.0  1.78.1-15
ii  gir1.2-gtk-3.0   3.24.41-4
ii  gir1.2-pango-1.0 1.52.1+ds-1
ii  iso-codes4.16.0-1
ii  libc62.37-18
ii  libcairo21.18.0-1+b1
ii  libcanberra0 [libcanberra0t64]   0.30-15
ii  libdconf10.40.0-4+b2
ii  libgcc-s114-20240330-1
ii  libglib2.0-0t64  2.78.4-7
ii  libgtk-3-0t643.24.41-4
ii  libhunspell-1.7-01.7.2+really1.7.2-10+b2
ii  librsvg2-common  2.58.0+dfsg-1
ii  libstdc++6   14-20240330-1
hi  libudev1 254.5-1
ii  libx11-6 2:1.8.7-1
ii  libxi6   2:1.8.1-1
ii  libxkbfile1  1:1.1.0-1
ii  libxtst6 2:1.2.3-1.1
ii  onboard-common   1.4.1-6
ii  python3  3.11.6-1
ii  python3-cairo1.26.0-1
ii  python3-dbus 1.3.2-5+b1
ii  python3-gi-cairo 3.47.0-3

Versions of packages onboard recommends:
ii  gir1.2-atspi-2.0 2.52.0-1
pn  gir1.2-ayatanaappindicator3-0.1  
ii  onboard-data 1.4.1-6
ii  xdg-utils1.1.3-4.1

Versions of packages onboard suggests:
ii  mousetweaks  3.32.0-4

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1069928: thermald: conffiles not removed: /etc/thermald/thermal-conf.xml /etc/init.d/thermald /etc/dbus-1/system.d/org.freedesktop.thermald.conf

2024-04-27 Thread Paul Wise

Package: thermald
Version: 2.5.7-2
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ p=thermald ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep 
obsolete
thermald: obsolete-conffile /etc/thermald/thermal-conf.xml
thermald: obsolete-conffile /etc/init.d/thermald
thermald: obsolete-conffile /etc/dbus-1/system.d/org.freedesktop.thermald.conf
 /etc/thermald/thermal-conf.xml 44437e985216ab918a6d2362c8dd1905 obsolete
 /etc/init.d/thermald e977b21364e668ce76072606621d1a4b obsolete
 /etc/dbus-1/system.d/org.freedesktop.thermald.conf 
a66eb6bd22779a225b0c2c30a25e6f56 obsolete

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'stable-updates'), (500, 'stable-security-debug'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages thermald depends on:
ii  libc6 2.37-18
ii  libdbus-1-3   1.14.10-4+b1
ii  libdbus-glib-1-2  0.112-3+b2
ii  libevdev2 1.13.1+dfsg-1
ii  libgcc-s1 14-20240330-1
ii  libglib2.0-0t64   2.78.4-7
ii  libstdc++6    14-20240330-1
ii  libupower-glib3   1.90.2-8
ii  libxml2   2.9.14+dfsg-1.3+b2

thermald recommends no packages.

thermald suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1069871: netplan.io: flaky autopkgtest on s390x: eth42 interface already exists

2024-04-26 Thread Paul Gevers


Source: netplan.io
Version: 0.107.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails on s390x (and maybe on armel/armhf, but that's 
hard to tell because of the time_t fall-out).


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

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

e.g.
https://ci.debian.net/packages/n/netplan.io/testing/s390x/45071647/

272s ==
272s ERROR: test_rename_interfaces 
(__main__.TestNetworkd.test_rename_interfaces)

272s --
272s Traceback (most recent call last):
272s   File 
"/tmp/autopkgtest-lxc.ndthudlr/downtmp/build.hjS/src/tests/integration/base.py", 
line 177, in setUp

272s self.create_devices()
272s   File 
"/tmp/autopkgtest-lxc.ndthudlr/downtmp/build.hjS/src/tests/integration/base.py", 
line 120, in create_devices

272s raise SystemError('eth42 interface already exists')
272s SystemError: eth42 interface already exists


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069813: ca-certificates-java: autopkgtests ignore differences between source and target suite

2024-04-25 Thread Paul Gevers


Source: ca-certificates-java
Version: 20240118
Severity: important

Hi,

The migration of `apt` was blocked because of apparent regressions in 
ca-certificates-java. The test can-install-jre tries to install all 
available jre-headless packages, regardless of pinning, so it will try 
to install versions only available in unstable. It's discouraged to use 
apt inside the test [1], but if you really want to test all versions 
(instead of only the default via a test Depends), please make the test 
honor differences between source and target suite, i.e. only test 
versions from the target suite unless apt-pinning asks explicitly for 
versions from the source suite.


Paul

[1] https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069806: spyder: half hidden titles in "configuration per file" window

2024-04-25 Thread Paul Gevers


Package: spyder
Version: 5.5.1+ds-1
Severity: minor

While I was searching for some option, I stumbled upon the 
"Configuration per file" window (under the "Run" tab in the menu, or via 
-F6). The names of the sub windows are half hidden in my setup (I 
use KDE if that matters and I have adjusted the font size to something 
bigger than the default).


See attachment for clarity.

Paul

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages spyder depends on:
ii  python3 3.11.6-1
ii  python3-spyder  5.5.1+ds-1

spyder recommends no packages.

Versions of packages spyder suggests:
pn  python3-spyder-unittest  

Versions of packages python3-spyder depends on:
ii  ipython3 8.20.0-1
ii  libjs-jquery 3.6.1+dfsg+~3.5.14-1
ii  libjs-mathjax2.7.9+dfsg-1
ii  pyflakes33.2.0-1
ii  pylint   3.0.3-1
ii  python3 [python3-supported-min]  3.11.6-1
ii  python3-atomicwrites 1.4.1-1
ii  python3-autopep8 2.1.0-1
ii  python3-chardet  5.2.0+dfsg-1
ii  python3-cloudpickle  3.0.0-2
ii  python3-cookiecutter 2.6.0-1
ii  python3-diff-match-patch 20230430-1
ii  python3-docutils 0.20.1+dfsg-3
ii  python3-flake8   7.0.0-1
ii  python3-intervaltree 3.0.2-1.1
ii  python3-ipython  8.20.0-1
ii  python3-jedi 0.19.1+ds1-1
ii  python3-jellyfish0.10.0-3
ii  python3-jsonschema   4.19.2-2
ii  python3-keyring  25.1.0-1
ii  python3-mccabe   0.7.0-1
ii  python3-nbconvert6.5.3-5
ii  python3-numpydoc 1.6.0-2
ii  python3-parso0.8.3-1
ii  python3-pexpect  4.9-2
ii  python3-pickleshare  0.7.5-5
ii  python3-pkg-resources68.1.2-2
ii  python3-psutil   5.9.8-2
ii  python3-pycodestyle  2.11.1-1
ii  python3-pydocstyle   6.3.0-1.1
ii  python3-pygments 2.17.2+dfsg-1
ii  python3-pylint-venv  3.0.2-1
ii  python3-pyls-spyder  0.4.0-2
ii  python3-pylsp1.10.1-1
ii  python3-pylsp-black  2.0.0-4
ii  python3-pyqt55.15.10+dfsg-1
ii  python3-pyqt5.qtwebengine5.15.6-1
ii  python3-qdarkstyle   3.2.3+ds1-1
ii  python3-qstylizer0.2.2-2
ii  python3-qtawesome1.2.3+dfsg-1
ii  python3-qtconsole5.5.1-1
ii  python3-qtpy 2.4.1-2
ii  python3-rope 1.13.0-1
ii  python3-rtree1.2.0-1
ii  python3-setuptools   68.1.2-2
ii  python3-sphinx   7.2.6-6
ii  python3-spyder-kernels   2.5.0-2
ii  python3-textdistance 4.6.0-1
ii  python3-three-merge  0.1.1-4
ii  python3-watchdog 3.0.0-1
ii  python3-xdg  0.28-2
ii  python3-zmq  24.0.1-5+b1
ii  spyder-common5.5.1+ds-1
ii  yapf30.33.0-1

python3-spyder recommends no packages.

Versions of packages python3-spyder suggests:
pn  cython3 
ii  python3-matplotlib  3.6.3-1+b2
ii  python3-numpy   1:1.24.2-2
pn  python3-pandas  
ii  python3-pil 10.3.0-2
ii  python3-scipy   1.11.4-6
ii  python3-sympy   1.12-7

Versions of packages python3-pyqt5 depends on:
ii  libc6  2.37-18
ii  libgcc-s1  14-20240330-1
ii  libpython3.11  3.11.8-1
ii  libqt5core5a [qtbase-abi-5-15-10]  5.15.10+dfsg-7
ii  libqt5dbus55.15.10+dfsg-7
ii  libqt5designer55.15.10-6
ii  libqt5gui5 5.15.10+dfsg-7
ii  libqt5help55.15.10-6
ii  libqt5network5 5.15.10+dfsg-7
ii  libqt5printsupport55.15.10+dfsg-7
ii  libqt5test55.15.10+dfsg-7
ii  libqt5widgets5 5.15.10+dfsg-7
ii  libqt5xml5 5.15.10+dfsg-7
ii  libstdc++6 14-20240330-1
ii  python33.11.6-1
ii  python3-pyqt5.sip  12.13.0-1+b1

-- no debconf information


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069755: libntlm0: broken symlink: README -> README.md

2024-04-24 Thread Paul Wise

Package: libntlm0
Version: 1.8-2
Severity: normal
File: /usr/share/doc/libntlm0/README
User: debian...@lists.debian.org
Usertags: adequate broken-symlink

libntlm0 1.8-2 introduced a broken symlink:
   
   /usr/share/doc/libntlm0/README -> README.md

This appears to be because upstream switched README to a symlink to
README.md and debian/libntlm0.docs was not updated to use README.md.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'stable-updates'), (500, 'stable-security-debug'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'proposed-updates'), (500, 'buildd-proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages libntlm0:amd64 depends on:
ii  libc6  2.37-18

libntlm0:amd64 recommends no packages.

libntlm0:amd64 suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1069724: slurm-wlm: autopkgtest regression on !amd64: trying to overwrite '/usr/lib/-linux-gnu/slurm-wlm/accounting_storage_mysql.so'

2024-04-23 Thread Paul Gevers


Source: slurm-wlm
Version: 23.11.4-1.4
X-Debbugs-CC: bdr...@debian.org, vor...@debian.org, mckins...@debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
slurm-wlm  from testing23.11.4-1.4
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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

Paul

[1] https://qa.debian.org/excuses.php?package=3Dslurm-wlm

https://ci.debian.net/data/autopkgtest/testing/arm64/s/slurm-wlm/45786802/log.gz

 96s Unpacking slurm-wlm-mysql-plugin (23.11.4-1.4) ...
 96s dpkg: error processing archive 
/tmp/apt-dpkg-install-zn5wp3/17-slurm-wlm-mysql-plugin_23.11.4-1.4_arm64.deb 
(--unpack):
 96s  trying to overwrite 
'/usr/lib/aarch64-linux-gnu/slurm-wlm/accounting_storage_mysql.so', 
which is also in package slurm-wlm-basic-plugins 23.11.4-1.4


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069600: dm-writeboost: isolation-machine autopkgtest fails: sudo: not found

2024-04-22 Thread Paul Gevers


Hi,

On 22-04-2024 10:39 a.m., Andreas Beckmann wrote:
Nice. Is there a chance to get isolation-machine supported on salsa.d.o, 
too?


I don't know. I'm not involved with salsa.

For this concrete case it may be as simple as adding dependency on sudo. 
In case it is trivial for you to rerun the failing test with extra 
dependencies, could you try that? I'd like to avoid doing debugging NMUs 
with untested bugfixes ;-)


root@host:~# 
/tmp/autopkgtest.W4BpP1/build.hRn/src/debian/tests/test-dm-writeboost.sh 


/tmp/autopkgtest.W4BpP1/build.hRn/src/debian/tests/test-dm-writeboost.sh
II: Checking for 14G available disk space...OK
II: Creating loop files:
II: - backing-2083.img...OK
II: - cache-2083.img...OK
II: Connecting to loop devices:
II: - backing-2083.img -> /dev/loop0...[  404.085269] loop0: detected 
capacity change from 0 to 20971520

OK
II: - cache-2083.img -> /dev/loop1...[  404.106845] loop1: detected 
capacity change from 0 to 8388608

OK
II: Initialize cache...OK
II: Loading dm-writeboost module...modprobe: FATAL: Module dm-writeboost 
not found in directory /lib/modules/6.6.15-amd64

FAILED!
II: Detaching /dev/loop1...
II: Detaching /dev/loop0...
II: Deleting file images...
EE: FAIL

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069614: erfs: isolation-machine autopkgtest fails: sshfs failed

2024-04-22 Thread Paul Gevers


Control: severity -1 serious
Control: retitle -1 erfs: no longer functional, should be removed

Hi

On 22-04-2024 1:37 p.m., Skyper x wrote:

The erfs service was shut down and this tool is no longer functional. It should 
be removed.


Please file an RM bug against the ftp.debian.org pseudo package.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069417: upgrade procedure instructs users to run “apt update” but neglects upgrading

2024-04-22 Thread Paul Gevers


Hi Holger,

On 22-04-2024 9:05 a.m., Holger Wansing wrote:

A patch for above two issues is attached (against the bookworm branch; any
such changing needs to be ported to master/trixie as well).


Feel free to push. Bonus points if you remove the deleted text from 
translations too (where you're confident).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069626: fuse-zip: isolation-machine autopkgtest fails: times out without any logging


Source: fuse-zip
Version: 0.5.0-1
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report, albeit there is nothing to see as the test 
doesn't log anything.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/f/fuse-zip/testing/amd64/45706859/

46s autopkgtest [15:26:31]: test blackbox: [---
10046s autopkgtest [18:13:11]: ERROR: timed out on command "su -s 
/bin/bash debci -c set -e; exec /tmp/autopkgtest.aZzNr9/wrapper.sh 
--artifacts=/tmp/autopkgtest.aZzNr9/blackbox-artifacts 
--chdir=/tmp/autopkgtest.aZzNr9/build.mtV/src 
--env=DEB_BUILD_OPTIONS=parallel=2 --env=DEBIAN_FRONTEND=noninteractive 
--env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS 
--unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE 
--unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT 
--unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME 
--unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE 
--unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid 
--source-profile --stderr=/tmp/autopkgtest.aZzNr9/blackbox-stderr 
--stdout=/tmp/autopkgtest.aZzNr9/blackbox-stdout 
--tmp=/tmp/autopkgtest.aZzNr9/autopkgtest_tmp 
--make-executable=/tmp/autopkgtest.aZzNr9/build.mtV/src/debian/tests/blackbox 
-- /tmp/autopkgtest.aZzNr9/build.mtV/src/debian/tests/blackbox" (kind: test)

10047s autopkgtest [18:13:12]: test blackbox: ---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069623: ganeti-instance-debootstrap: isolation-machine autopkgtest fails: http://deb.debian.org/debian/dists/jessie doesn't exist


Source: ganeti-instance-debootstrap
Version: 0.16-8
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails. Can you please 
investigate the situation and fix it? I copied some of the output at the 
bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/packages/g/ganeti-instance-debootstrap/testing/amd64/45709257/

 27s autopkgtest [17:54:41]: test install-export-import: 
[---

 28s 512+0 records in
 28s 512+0 records out
 28s 536870912 bytes (537 MB, 512 MiB) copied, 0.487683 s, 1.1 GB/s
 28s Installing instance...
 29s Re-reading the partition table failed.: Invalid argument
 29s I: Retrieving InRelease
 29s I: Retrieving Release
 29s E: Failed getting release file 
http://deb.debian.org/debian/dists/jessie/Release
 30s autopkgtest [17:54:44]: test install-export-import: 
---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069622: firejail: isolation-machine autopkgtest fails: firefox doesn't exist in testing


Source: firejail
Version: 0.9.72-2
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Dear maintainer(s),

Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails if the test runs in 
testing; it passes when run in unstable. Can you please investigate the 
situation and fix it? I copied some of the output at the bottom of this 
report. It looks like the test Depends on packages that aren't available 
in testing. thunderbird and transmission-gtk should be temporarily, but 
firefox isn't going to migrate by design.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing, but because machine-isolation 
support by ci.debian.net is new I have not marked this bug as serious (yet).


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/f/firejail/45706858/log.gz

616s The following packages have unmet dependencies:
616s  autopkgtest-satdep : Depends: thunderbird but it is not installable
616s   Depends: firefox but it is not installable
616s   Depends: transmission-gtk but it is not 
installable


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069603: [Pkg-openssl-devel] Bug#1069603: openssl breaks libcrypt-smime-perl autopkgtest: Crypt::SMIME#setPublicKeyStore: failed to store the public cert


Hi

On 21-04-2024 5:56 p.m., Sebastian Andrzej Siewior wrote:

The problem is that libcrypt-smime-perl < 0.29 fails with openssl >= 3.2.0.
This was solved by the Perl team with their 0.29 upload. This and 0.30
didn't migrate to testing and in the meantime we got OpenSSL into
unstable which relies on that fix.
The migration was delayed by the time_t transition.


Ack. I figured that out too.


Could britney be hinted to migrate both at the same time? This should
solve the issue you pointed out.


There is no "please test together" knob if that's what you mean (is that 
what you mean?). I have triggered the test manually, so for now the 
lights are green. Because those expire, I have added a hint to ignore 
the failure of the old version in testing.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069614: erfs: isolation-machine autopkgtest fails: sshfs failed