Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Paul Gevers]

Hi

On 14-01-2024 18:46, Guillem Jover wrote:

I think that would be great, I guess the message from the hook could
give some very basic and generic guidance, and point to this page for
more in-depth explanation of what to do, what else to check etc. But in
any case an initial version sounds good, as that can always be tuned,
or extended/improved later on. :)


Initial version. Please consider the name too, moving now is easier than 
later:

https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Paul Gevers]

Hi,

On 14-01-2024 17:43, Guillem Jover wrote:

   https://wiki.debian.org/Teams/ReleaseTeam/Transitions

but it looks like that one is targeted more to maintainers that start
or drive the transitions instead of someone that might upload a
package which is part or affected by that transition?


Indeed. I had the same idea when I replied earlier, but I think we'd 
need a new (wiki) page for this. If we happen to agree here, I'm fine 
with creating an initial version.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Paul Gevers]

Hi Guillem

On 10-01-2024 02:23, Guillem Jover wrote:

I've had for a while a new hook for dupload that adds a transitions
check for Debian hosts, for sourceful uploads targeting unstable (to
avoid disrupting buildd or porter uploads, or uninteresting suites).
I've just finished polishing it, and the main lingering question I've
had all along has been whether you think this would actually be useful
and/or desired at all, see below.

The hook is currently using
https://release.debian.org/transitions/export/packages.yaml, and
prompting in case that source package is part of any ongoing
transition.


Cool.


I wondered also whether checking
https://ftp-master.debian.org/transitions.yaml would be useful,
but I'm not sure whether that is or has ever been used?


It still works, but it's hardly used. I do have some vague ideas to use 
it again in the future, but that's not going to happen soon I guess.



So I guess my questions would be whether you think this is helpful or
useful at all?


Yes, I do.


If so, whether the criteria is adequate or it needs to
be changed? Whether this should be a prompt, or maybe only an info or
warning? And any other comment or suggestion you might have!


I'm mostly wondering if the information shown is enough to help people. 
I'm actually surprised how many people don't know how transitions work. 
What is your opinion on the length of the text you could provide? Maybe 
a link to a wiki page with more info particularly for this case?


Maybe Sebastian can comment on how often he sees interfering uploads to 
judge if it should be a warning or a prompt. If you make this only a 
warning, what are the options of the uploader, canceling?


Paul

PS: if you're happy with this, should we file wish list bugs against 
dput and dput-ng too?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060783: src:rasdaemon: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: rasdaemon
Version: 0.6.8-1.1
Severity: serious
Control: close -1 0.8.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1059484

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:rasdaemon has been trying to migrate for 
50 days [2]. Hence, I am filing this bug. The version in unstable has an 
autopkgtest that fails as reported in bug 1059484.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060782: src:i2pd: fails to migrate to testing for too long: FTBFS on armel

[Paul Gevers]

Source: i2pd
Version: 2.45.1-1
Severity: serious
Control: close -1 2.49.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:i2pd has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on armel.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060781: src:gitlab-shell: fails to migrate to testing for too long: Build-Depends not ready to migrate

[Paul Gevers]

Source: gitlab-shell
Version: 14.20.0+ds1-2
Severity: serious
Control: close -1 14.23.0+ds1-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:gitlab-shell has been trying to migrate 
for 32 days [2]. Hence, I am filing this bug. The version in unstable 
Build-Depends on binaries from src:gitaly, which isn't ready to migrate 
at this moment. The version in unstable also fails its piuparts tests.


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=gitlab-shell



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060780: src:terminado: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: terminado
Version: 0.17.1-1
Severity: serious
Control: close -1 0.18.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:terminado has been trying to migrate for 
31 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=terminado



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060779: src:mesa: fails to migrate to testing for too long: unavailable Build-Depends on mips64el

[Paul Gevers]

Source: mesa
Version: 23.2.1-1
Severity: serious
Control: close -1 23.3.3-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1056116

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:mesa has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable build 
depends on binaries from llvm-toolchain-17, which haven't been built on 
mips64el yet (reported in bug 1056116).


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060777: django-filter: build dependency missing in testing: python3-django-crispy-forms

[Paul Gevers]

Source: django-filter
Version: 23.5-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertag: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting issues with your packages. Normally your build 
dependencies shouldn't be removed from testing without removal all 
reverse build dependencies too, nor should a package be allowed to 
migrate unless all build dependencies are candidate for migration too. 
However, somehow we ended up in the current state and your source 
package is missing some Build-Depends for some while now. Not being able 
to build from source in a suite is an RC bug in that suite.


Can you please solve the situation by either helping the maintainer of 
your Build-Depends to enable migration to testing, or by working around 
the lack of this build dependency?


Paul

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


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060776: collectd: build dependency missing in testing: libvarnishapi-dev

[Paul Gevers]

Source: collectd
Version: 5.12.0-15
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertag: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting issues with your packages. Normally your build 
dependencies shouldn't be removed from testing without removal all 
reverse build dependencies too, nor should a package be allowed to 
migrate unless all build dependencies are candidate for migration too. 
However, somehow we ended up in the current state and your source 
package is missing some Build-Depends for some while now. Not being able 
to build from source in a suite is an RC bug in that suite.


Can you please solve the situation by either helping the maintainer of 
your Build-Depends to enable migration to testing, or by working around 
the lack of this build dependency?


Paul

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


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060775: tmuxp: flaky autopkgtest: assert pane.capture_pane()[1] -> IndexError

[Paul Gevers]

Source: tmuxp
Version: 1.31.0-2
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. I'm seeing a pattern that it happens more often 
on our amd64 host ci-worker13 and often on our s390x which are rather 
powerful hosts. The test fails in different locations, but as far as I 
saw always on a line that asserts capture_pane (see example below). 
Could it be that the code (either the real code or the test code) should 
wait a bit until the "pane" has been substantiated? Or maybe that 
comment earlier is of interest: Give slow shells some time to settle as 
otherwise tests might fail.


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

From
https://ci.debian.net/packages/t/tmuxp/testing/s390x/41364351/

 59s @pytest.mark.skipif(
 59s has_lt_version("3.0"),
 59s reason="needs -e flag for new-window and split-window 
introduced in tmux 3.0",

 59s )
 59s def test_environment_variables(session: Session) -> None:
 59s workspace = ConfigReader._from_file(
 59s 
test_utils.get_workspace_file("workspace/builder/environment_vars.yaml")

 59s )
 59s workspace = loader.expand(workspace)
 59s
 59s builder = WorkspaceBuilder(session_config=workspace, 
server=session.server)

 59s builder.build(session)
 59s # Give slow shells some time to settle as otherwise tests 
might fail.

 59s time.sleep(0.3)
 59s
 59s assert session.getenv("FOO") == "SESSION"
 59s assert session.getenv("PATH") == "/tmp"
 59s
 59s no_overrides_win = session.windows[0]
 59s pane = no_overrides_win.panes[0]
 59s pane.send_keys("echo $FOO")
 59s assert pane.capture_pane()[1] == "SESSION"
 59s
 59s window_overrides_win = session.windows[1]
 59s pane = window_overrides_win.panes[0]
 59s pane.send_keys("echo $FOO")
 59s assert pane.capture_pane()[1] == "WINDOW"
 59s
 59s pane_overrides_win = session.windows[2]
 59s pane = pane_overrides_win.panes[0]
 59s pane.send_keys("echo $FOO")
 59s assert pane.capture_pane()[1] == "PANE"
 59s
 59s both_overrides_win = session.windows[3]
 59s pane = both_overrides_win.panes[0]
 59s pane.send_keys("echo $FOO")
 59s >   assert pane.capture_pane()[1] == "WINDOW"
 59s E   IndexError: list index out of range
 59s


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059553: fixed in minicoredumper 2.0.7-3

[Paul Gevers]

Hurray,

On 13-01-2024 21:39, Debian Bug Tracking System wrote:

  minicoredumper (2.0.7-3) unstable; urgency=medium
  .
* Fix autopackage test due to stderr output (Closes: #1059553)


That worked. The test now passes nicely.

Thank you.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060189: [Pkg-pascal-devel] Bug#1060189: Bug#1060189: lazarus-src-3.0: diversion handling seems wrong (it works, but after an error)

[Paul Gevers]

Hi Abou,

On 12-01-2024 22:44, Abou Al Montacir wrote:

Well, maybe I just didn't spot this issue before. But because of the
/usr-merged work of helmut, I'm much more aware of diversions so they'd
trigger me much more then they used to.


Makes sense, but I'm not sure I understand why diverted files should be 
the same? Isn't diversion is used to enable a package to supersede 
another shipping a different version of the same file?


Indeed, diverted files are supposed to be different, otherwise it 
doesn't make sense to use diversions. To I think the error message is 
trying to say something else, but I don't know what it means exactly. I 
suspect it's saying that the file is already diverted and that we're 
trying to divert it a second time. Or something in that direction.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060189: [Pkg-pascal-devel] Bug#1060189: lazarus-src-3.0: diversion handling seems wrong (it works, but after an error)

[Paul Gevers]

Hi Abou,

On 11-01-2024 20:40, Abou Al Montacir wrote:
But this is the case of all lpk files where the binary package provide a 
Manually compilable package while the source one provides a Compile As  > Needed package file.


Don't we want them to be the same? Why do we even ship the files twice?


This was the case since many years now.


Well, maybe I just didn't spot this issue before. But because of the 
/usr-merged work of helmut, I'm much more aware of diversions so they'd 
trigger me much more then they used to.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059553: closed by Debian FTP Masters (reply to John Ogness ) (Bug#1059553: fixed in minicoredumper 2.0.7-2)

[Paul Gevers]

Hi,

On 12-01-2024 08:51, Debian Bug Tracking System wrote:

  minicoredumper (2.0.7-2) unstable; urgency=medium
  .
* Fix autopackage test due to missing dependency (Closes: #1059553)


https://ci.debian.net/data/autopkgtest/testing/amd64/m/minicoredumper/41783082/log.gz

 40s Starting minicoredumper (via systemctl): minicoredumper.service.
 40s Segmentation fault (core dumped)
 40s core
 40s   Type:  CORE (Core file)
 40s Stopping minicoredumper (via systemctl): minicoredumper.service.
 40s autopkgtest [15:27:31]: test coredump: ---]
 41s autopkgtest [15:27:32]: test coredump:  - - - - - - - - - - 
results - - - - - - - - - -

 41s coredump FAIL stderr: Segmentation fault (core dumped)

By default, autopkgtest considers output on stderr a failure. You 
probably want to set the allow-stderr restriction.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Paul Gevers]

Hi,

On 12-01-2024 12:36, Chris Hofstaedtler wrote:

can you confirm two additional things please:

1) this happens only on the large host?


https://ci.debian.net/packages/p/pdns/testing/s390x/41650331/

Seems it happens on our s390x host too (which has 10 debci workers 
running in parallel).



2) this does not or does happen with other packages also requesting
the same settings from systemd, e.g. dnsdist or pdns-recursor?


https://ci.debian.net/packages/d/dnsdist/ -> Page not found.

pdns-recursor seems to be flaky as well on amd64 and all passing tests 
were on one of the smaller hosts. pdns-recursor passes on s390x though.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059553: closed by Debian FTP Masters (reply to John Ogness ) (Bug#1059553: fixed in minicoredumper 2.0.7-1)

[Paul Gevers]

Hi,

On 10-01-2024 11:24, Debian Bug Tracking System wrote:

  minicoredumper (2.0.7-1) unstable; urgency=medium



* Fix autopackage test due to missing dependency (Closes: #1059553)


Now it fails with:
 37s /tmp/autopkgtest.iUO3a9/build.Ta0/src/debian/tests/coredump: 23: 
/etc/init.d/minicoredumper: not found


Paul

https://ci.debian.net/packages/m/minicoredumper/testing/amd64/41726183/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060414: src:libextractor: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: libextractor
Version: 1:1.11-8
Severity: serious
Control: close -1 1:1.13-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:libextractor has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version in unstable 
failed to build on s390x.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060413: src:emacs-posframe: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Source: emacs-posframe
Version: 1.1.7-3
Severity: serious
Control: close -1 1.4.2-1
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:emacs-posframe has been trying to migrate 
for 33 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=emacs-posframe



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060412: src:emacs-wgrep: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: emacs-wgrep
Version: 3.0.0-1
Severity: serious
Control: close -1 3.0.0-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:emacs-wgrep has been trying to migrate for 
33 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=emacs-wgrep



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060202: glibc - autopkgtest flacky on arm64

[Paul Gevers]

Hi,

On 08-01-2024 01:45, Aurelien Jarno wrote:

I am still not sure why it got killed on arm64 and not on other debci
workers, there as still swap available. Actually looking at the munin
plot, it seems that the arm64 debci workers stopped using swap around
September 2023 contrary to the other architectures.


This does seem to align with us upgrading from the bookworm kernel to 
the backports kernel because of bug 1050256.


That still doesn't explain while the problem with glibc seems to 
have started one week ago.

Indeed, but 4 GB of swap looks like it would help.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060202: glibc - autopkgtest flacky on arm64

[Paul Gevers]

Hi all,

On 08-01-2024 19:50, Paul Gevers wrote:
Can you tell me how you saw that? I neither spotted that, nor is not 
having swap a conscious act, so rather a mistake.


I just checked and it seems that on ci-worker-arm64-08 was not having 
swap. We did have /swap created as our other workers, but apparently 
that was never made a swap file and mounted.


After fixing, now $(cat /proc/meminfo | grep SwapTotal) says:
  ci-worker-arm64-02: SwapTotal:   4084220 kB
  ci-worker-arm64-03: SwapTotal:   4084220 kB
  ci-worker-arm64-04: SwapTotal:   4084220 kB
  ci-worker-arm64-06: SwapTotal:   4084220 kB
  ci-worker-arm64-05: SwapTotal:   4084220 kB
  ci-worker-arm64-07: SwapTotal:   4084220 kB
  ci-worker-arm64-11: SwapTotal:   4084220 kB
  ci-worker-arm64-10: SwapTotal:   4084220 kB
  ci-worker-arm64-08: SwapTotal:   4084220 kB
  ci-worker-arm64-09: SwapTotal:   4084220 kB

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060202: glibc - autopkgtest flacky on arm64

[Paul Gevers]

Hi,

On 08-01-2024 01:45, Aurelien Jarno wrote:

I am still not sure why it got killed on arm64 and not on other debci
workers, there as still swap available. Actually looking at the munin
plot, it seems that the arm64 debci workers stopped using swap around
September 2023 contrary to the other architectures.


Can you tell me how you saw that? I neither spotted that, nor is not 
having swap a conscious act, so rather a mistake.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060202: glibc - autopkgtest flacky on arm64

[Paul Gevers]

Hi,

On 07-01-2024 18:21, Aurelien Jarno wrote:

Timeout while building:
https://ci.debian.net/packages/g/glibc/unstable/arm64/41516611/


There are indeed many failures with cc1 getting killed, it seems that it
started around 2024-01-02. I haven't spotted any change to the toolchain
nor kernel version.

I am not able to reproduce the issue, so it is very likely linked to
debci. Would it be possible to now why cc1 get killed? OOM? timeout?


I extracted the attached journal piece indicating OOM.


Failed test:
https://ci.debian.net/packages/g/glibc/testing/arm64/40439311/


This one is too old, the date is not in the journal anymore.

Paul
Jan 03 22:53:54 ci-worker-arm64-03 kernel: dpkg-query invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
Jan 03 22:53:54 ci-worker-arm64-03 kernel: CPU: 1 PID: 2152163 Comm: dpkg-query Tainted: GW  6.4.0-0.deb12.2-arm64 #1  Debian 6.4.4-3~bpo12+1
Jan 03 22:53:54 ci-worker-arm64-03 kernel: Hardware name: OpenStack Foundation OpenStack Nova, BIOS 0.0.0 02/06/2015
Jan 03 22:53:54 ci-worker-arm64-03 kernel: Call trace:
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  dump_backtrace+0xa0/0x128
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  show_stack+0x20/0x38
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  dump_stack_lvl+0x48/0x60
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  dump_stack+0x18/0x28
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  dump_header+0x4c/0x218
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  oom_kill_process+0x148/0x308
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  out_of_memory+0xec/0x5a0
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  __alloc_pages+0xca0/0xde8
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  alloc_pages+0xb4/0x160
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  folio_alloc+0x24/0x68
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  filemap_alloc_folio+0x144/0x160
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  __filemap_get_folio+0xf0/0x2f8
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  filemap_fault+0x49c/0x998
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  __do_fault+0x44/0x230
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  __handle_mm_fault+0xb8c/0x1238
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  handle_mm_fault+0x160/0x290
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  do_page_fault+0x270/0x490
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  do_translation_fault+0x54/0x70
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  do_mem_abort+0x4c/0xa8
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  el0_ia+0x70/0x148
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  el0t_64_sync_handler+0xc4/0x120
Jan 03 22:53:54 ci-worker-arm64-03 kernel:  el0t_64_sync+0x190/0x198
Jan 03 22:53:54 ci-worker-arm64-03 kernel: Mem-Info:
Jan 03 22:53:54 ci-worker-arm64-03 kernel: active_anon:644290 inactive_anon:541258 isolated_anon:0
active_file:488 inactive_file:211 isolated_file:0
unevictable:0 dirty:10 writeback:0
slab_reclaimable:84360 slab_unreclaimable:712733
mapped:536 shmem:947 pagetables:3927
sec_pagetables:0 bounce:0
kernel_misc_reclaimable:0
free:31884 free_pcp:100 free_cma:0
Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 active_anon:2577160kB inactive_anon:2165032kB active_file:1952kB inactive_file:844kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:2144kB dirty:40kB writeback:0kB shmem:3788kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 6144kB writeback_tmp:0kB kernel_stack:4512kB pagetables:15708kB sec_pagetables:0kB all_unreclaimable? no
Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 DMA free:36984kB boost:0kB min:17152kB low:21440kB high:25728kB reserved_highatomic:0KB active_anon:1498272kB inactive_anon:1194072kB active_file:792kB inactive_file:436kB unevictable:0kB writepending:4kB present:3145728kB managed:3080192kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
Jan 03 22:53:54 ci-worker-arm64-03 kernel: lowmem_reserve[]: 0 0 4929 4929
Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 Normal free:90552kB boost:0kB min:27900kB low:34872kB high:41844kB reserved_highatomic:0KB active_anon:1078488kB inactive_anon:971360kB active_file:28kB inactive_file:1176kB unevictable:0kB writepending:36kB present:5242880kB managed:5047724kB mlocked:0kB bounce:0kB free_pcp:364kB local_pcp:0kB free_cma:0kB
Jan 03 22:53:54 ci-worker-arm64-03 kernel: lowmem_reserve[]: 0 0 0 0
Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 DMA: 1014*4kB (UME) 1017*8kB (UME) 304*16kB (UME) 327*32kB (UME) 95*64kB (UME) 28*128kB (UME) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 37184kB
Jan 03 22:53:54 ci-worker-arm64-03 kernel: Node 0 Normal: 219*4kB (E) 994*8kB (UE) 1709*16kB (UE) 1672*32kB (UE) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 

Bug#1060190: src:pyflakes: fails to migrate to testing for too long: unresolved RC issue

[Paul Gevers]

Source: pyflakes
Version: 2.5.0-1
Severity: serious
Control: close -1 3.1.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1058335

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:pyflakes has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable has a 
behavior regression that's reported in bug 1058335.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060189: lazarus-src-3.0: diversion handling seems wrong (it works, but after an error)

[Paul Gevers]

Package: lazarus-src-3.0
Version: 3.0+dfsg1-5
Severity: normal

Hi,

I just did my daily update of my trixie system and spotted the error 
below. The fallback works, but that "error" is highlighted in red, so it 
catches the eye.


Paul

Unpacking lazarus-src-3.0 (3.0+dfsg1-5) over (3.0+dfsg1-3) ...
Removing 'diversion of 
/usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk to 
/usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk.orig by 
lazarus-src-3.0'
dpkg-divert: error: rename involves overwriting 
'/usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk' with
  different file 
'/usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk.orig', 
not allowed
dpkg: warning: old lazarus-src-3.0 package post-removal script 
subprocess returned error exit status 2

dpkg: trying script from the new package instead ...
dpkg: ... it looks like that went OK




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

Kernel: Linux 6.5.0-5-amd64 (SMP w/8 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

lazarus-src-3.0 depends on no packages.

lazarus-src-3.0 recommends no packages.

Versions of packages lazarus-src-3.0 suggests:
iu  lazarus-ide-3.0  3.0+dfsg1-5

-- no debconf information


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060149: src:extrepo: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Hi Wouter,

On 06-01-2024 20:51, Wouter Verhelst wrote:

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:extrepo has been trying to migrate for 33 days [2].


This should have been fixed with the recent upload of extrepo-offline-data?


Doesn't that mean that there is a versioned relation or a Breaks needed 
somewhere? Or is this a test problem only? I note that extrepo-data 
passed in testing which passed (so with the old extrepo, so no versioned 
Breaks needed), so I *guess* that indeed this is a test only problem.


With versioned breaks or versioned dependencies, britney2 will schedule 
combined tests as it knows that things migrate together (somewhat) 
anyways. I don't think so this time, but autopkgtest catches a lot of 
missing versioned relations this way.



If that didn't happen yet, can you try to trigger another autopkgtest run?


Mostly depending on the answer above. Failing migration tests are 
rescheduled after a day, so if we don't do anything, once extrepo-data 
migrates (it's not blocked by anything now), I expect things to be fine.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060151: src:compyle: fails to migrate to testing for too long: autopkgtest issues

[Paul Gevers]

Source: compyle
Version: 0.8.1-4
Severity: serious
Control: close -1 0.8.1-6
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:compyle has been trying to migrate for 34 
days [2]. Hence, I am filing this bug. The version in unstable fails its 
own autopkgtest on armel, ppc64el and s390x and shows failure in pysph 
(albeit that *might* be due to Python 3.12).


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060149: src:extrepo: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: extrepo
Version: 0.11
Severity: serious
Control: close -1 0.12
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:extrepo has been trying to migrate for 33 
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=extrepo



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060148: src:liblouis: fails to migrate to testing for too long: triggers autopkgtest failures

[Paul Gevers]

Source: liblouis
Version: 3.27.0-1
Severity: serious
Control: close -1 3.28.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1058514

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:liblouis has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. The version in unstable triggers 
autopkgtest failures in liblouisutdml which is related to bug 1058514.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060147: src:libei: fails to migrate to testing for too long: FTBFS on amd64/i386

[Paul Gevers]

Source: libei
Version: 1.1.0-1
Severity: serious
Control: close -1 1.2.0-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1058218

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:libei has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on amd64 and i386 which has been reported in bug 1058218.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

[Paul Gevers]

Hi Simon

On 06-01-2024 12:48, Simon McVittie wrote:

On Sat, 06 Jan 2024 at 10:16:28 +0100, Paul Gevers wrote:
If an explicit dependency on steam-libs:i386 would be valid, I'd be happy
to use that, and remove the steam-libs-i386 binary package as redundant.


We're not there yet, so please hold your horses. Although I tend to 
think we should allow this too for the use cases you describe. So unless 
it's really the intent of a (source) package or small (source) package 
set to be meant to be used in a multi architecture environment I think 
we should demand that dependencies are not be exclusively fulfilled by 
packages from another architecture (:any is OK, :$arch is not). So 
indeed, each should require manual review. While writing this that 
*could* mean that britney2 grows support for cross-architecture 
dependencies while still blocking them if not forced.



packages being blocked for useful use cases (that we could hint
through, but that britney2 would consider non-installable, so not protected
from then on)

and ...


I think this bug report is one of only a couple over the years
that requested anything on this front


I specifically ment these sentences in the broader discussion we started 
having.



This bug #1059929 involving gobject-introspection_1.78.1-9 is different
from things like steam-installer and nss-mdns: 


Ack. I consider that just a bug in britney2: if apt, dpkg and dose3 
allow this, so should britney2. My previous message was about the more 
generic case (including :$arch qualifiers instead of only :any (this bug 
being about :any on virtual packages)).



in the steam-installer case
I had to ask the release team (a while ago) to apply some force to work
around a known limitation in britney2, but in the gobject-introspection
case, my hope is that it can be resolved (possibly by a bug fix
in britney2, or possibly by changing gobject-introspection) without
forcing the installability check to be ignored.


Absolutely.

Thanks for being elaborate in your reply, it matches what I was 
thinking. (I wasn't aware of the other examples though).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

[Paul Gevers]

Hi,

On 06-01-2024 08:21, Johannes Schauer Marin Rodrigues wrote:

I think it's a bit more complicated than that. Currently, the tool creates 8624
package relationships. If I remember correctly, britney is unable to analyze
cross-architecture relationships?


At least by lack of implementation. But thinking about pure 
cross-architecture relations (I mean those that are *only* satisfied 
using multiple architectures) a bit, what is it that we'd want at the 
archive level? I guess there are exceptions we could accept like from 
src:steam-installer (which doesn't use :i386 or :amd64 at the moment if 
I'm correct) or src:wine (which only uses it in alternatives and IIUC 
could equally well use :any), but do we really want to allow pure 
cross-architecture relations in general? I don't think so. What kind of 
complexity would that add for architecture qualification and efforts to 
remove an architecture from the archive later on? (steam-installer if it 
were using architecture qualifiers now would probably be handled 
somewhat because it could be accepted once manually and then afterwards 
it's accepted by britney2 because the non-installability doesn't go up).



In that case that number goes down to 2352.
One could reduce that number even further and only check those cases where apt,
dpkg and dose3 agree on a solution but that would then rather be a
documentation of the status quo than a list of the intended ground truth. Maybe
it would make sense to analyze the archive and only add those cases that
currently exist as real package relationships?


As far as I can tell (I checked testing/main/source, 
testing/main/(amd64|i386) and testing/contrib/(amd64|i386) for 
(:i386|:amd64)) there is no package that does this for Depends or 
Build-Depends (excluding alternatives in src:wine and 
src:build-essential). So I think we can reduce it to :any in Depends and 
:any and :native in Build-Depends. Not sure how far your number goes 
down then.



What the tool never received since its inception was somebody to look over
these cases and write down what the ground-truth actually is supposed to look
like. For the britney tests you likely want some kind of ground-truth and I
fear that tool can give you the status quo but not necessarily the truth as
intended by the spec.


Ack.


If that is fine for you, do you still want to add thousands of test-cases? Or
do you want to hand-pick them?


It depends on the route we take and what we envision as useful cases to 
support. What I want to avoid is two things, highest prio first:


1) something that we don't want to migrate migrates (I think the current 
*lack* of support achieves that mostly already) albeit *maybe* my 
current fix for this bug is going to change that unintentionally in the 
wrong direction.


2) (lots of) packages being blocked for useful use cases (that we could 
hint through, but that britney2 would consider non-installable, so not 
protected from then on) I think this bug report is one of only a couple 
over the years that requested anything on this front (I think all were 
from Simon), so I wonder how many (legitimate) use cases there are that 
people would want to use and don't because of lack of support on our side.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

[Paul Gevers]

Control: tags -1 pending

Hi,

On 03-01-2024 20:40, Paul Gevers wrote:

On 03-01-2024 20:22, Simon McVittie wrote:

I think all of those are correct?


I think that if apt allows you to install it, chances are that it's a 
britney2 bug. I'll try to debug it tomorrow.


I have a first proposal for a fix in 
https://salsa.debian.org/release-team/britney2/-/merge_requests/89


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Paul Gevers]

Hi Steve,

On 05-01-2024 17:36, Rene Engelhard wrote:
Also a problem is that experimental also might already contain totally 
unrelated updates like new upstream versions...


I share this worry. Have you thought about how to handle the cases where 
you don't have experimental to upload to? How big is this problem?


Another worry, how will you provide the required changes to the 
maintainers of the packages? Via BTS? For those working on salsa: MR? 
Both? Something else? Obviously we should not end in the situation that 
a new upload goes back to the old name (or are the ftp-masters so keen 
on this transition that that won't happen? But what about newer versions 
with the old name already in experimental, conform the former worry?). 
I've seen NMU's being ignored by subsequent uploads by the maintainer, 
even when they fixed RC issues which were then reintroduced.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

[Paul Gevers]

Hi,

Thanks for reaching out.

On 05-01-2024 07:45, Johannes Schauer Marin Rodrigues wrote:

It would generate the following two stubs (shortened here for brevity):

Package: pkga
Version: 1
Architecture: amd64
Depends: pkgc:any
Multi-Arch: no

Package: pkgb
Version: 1
Architecture: amd64
Provides: pkgc
Multi-Arch: allowed


For britney2, the Sources stanza would also be needed; then we could use 
this to generate britney2 testcases. I created 10 of those yesterday by 
hand [1].


The simplest for of tests is a tree with
var/data/unstable/Sources
# i386 is the default archive of the testsuite, which can be overruled
# if that makes sense
var/data/unstable/Packages_i386
var/data/testing/Sources (may be empty)
var/data/testing/Packages_i386
expected

expected is in Heidi format (if I understand correctly) of what britney2 
will allow to be in testing after the run, it will only migrate packages 
that are installable.


Would it make sense to you to generate a branch in that archive with a 
bunch of tests that you know the answer too?


Paul

[1] 
https://salsa.debian.org/debian/britney2-tests/-/commit/5ab98de685e15a654227e9b188a48e44857f9d11


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Paul Gevers]

Hi,

On 04-01-2024 17:28, Chris Hofstaedtler wrote:

On Thu, Jan 04, 2024 at 03:37:21PM +0100, Paul Gevers wrote:

Hi,

On 04-01-2024 15:08, Chris Hofstaedtler wrote:

It would seem that the host runs out of IPC space?


What is IPC space?


https://manpages.debian.org/bookworm/manpages/sysvipc.7.en.html
https://manpages.debian.org/bookworm/manpages/ipc_namespaces.7.en.html


And when does a host run out of it? As I said, this is
one of our most powerful hosts, so I would expect it to run out of things
last.


Does it run more tests in parallel than other workers, or so?


Yes, this host (like most of our host, but a bit more) runs multiple lxc
based debci workers.


My guess: the default limits are static, and if LXC doesn't do
anything special, the limits are probably shared with the whole
host.
kernel.shmmax, kernel.msgmax are I think the limits (but I'm not
entirely sure).


Can you figure out decent numbers for these? Below I printed the output 
of lsipc and AFAICT SHMMAX is already pretty big ;) (and the same on all 
our hosts, which is also true for MSGMAX).


On the other hand, $(ipcs -a) doesn't show anything on the host, not 
even if I let it run in a while-loop (1 second interval) while I 
schedule the test of pdns. So, could this be a bug in systemd (which you 
claim below should be handeling this) or is this just not really 
supported in lxc and do you need a full VM. Because it works elsewhere, 
I feel more like a bug, and it would not be the first instance where 
code fails to properly handle 64 cores or 256GB or RAM.



I wouldn't know what to do about this, its not really under the
control of src:pdns.


Well, maybe check for it and fail gracefully?


But how? systemd sets up the IPC namespace.


exit with 77 when you detect problems and add the skippable restriction.


Or, since a couple of days, if
qemu VM don't run out of IPC space, we could run them in qemu always.


I imagine a fully separated VM would not run out of IPC space,
indeed.


I just ran the test in qemu on ci-worker13 and it PASSed.

Paul

root@ci-worker13:~# lsipc
RESOURCE DESCRIPTION  LIMIT 
USED  USE%
MSGMNI   Number of message queues 32000 
  0 0.00%
MSGMAX   Max size of message (bytes) 8K 
  - -
MSGMNB   Default max size of queue (bytes)  16K 
  - -
SHMMNI   Shared memory segments4096 
  0 0.00%
SHMALL   Shared memory pages   18446744073692774399 
  0 0.00%
SHMMAX   Max size of shared memory segment (bytes)  16E 
  - -
SHMMIN   Min size of shared memory segment (bytes)   1B 
  - -
SEMMNI   Number of semaphore identifiers  32000 
  0 0.00%
SEMMNS   Total number of semaphores  102400 
  0 0.00%
SEMMSL   Max semaphores per semaphore set.32000 
  - -
SEMOPM   Max number of operations per semop(2)  500 
  - -
SEMVMX   Semaphore max value  32767 
  - -


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Paul Gevers]

Hi,

On 04-01-2024 15:08, Chris Hofstaedtler wrote:

It would seem that the host runs out of IPC space?


What is IPC space? And when does a host run out of it? As I said, this 
is one of our most powerful hosts, so I would expect it to run out of 
things last.



Does it run more tests in parallel than other workers, or so?


Yes, this host (like most of our host, but a bit more) runs multiple lxc 
based debci workers.



I wouldn't know what to do about this, its not really under the
control of src:pdns.


Well, maybe check for it and fail gracefully? Or, since a couple of 
days, if qemu VM don't run out of IPC space, we could run them in qemu 
always.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Paul Gevers]

Source: pdns
Version: 4.8.3-2
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. The failures seem related on the host that runs 
the test. ci-worker13 is a beefy machine [1] and test seem to fail 
consistently there, while the other amd64 workers are much more moderate 
[2] and tests pass there.


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

[1] https://metal.equinix.com/product/servers/m3-large/
[2] https://aws.amazon.com/ec2/instance-types/m5/

https://ci.debian.net/packages/p/pdns/testing/amd64/

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pdns/41325109/log.gz

268s + service pdns restart
269s Job for pdns.service failed because the control process exited with 
error code.
269s See "systemctl status pdns.service" and "journalctl -xeu 
pdns.service" for details.

269s + journalctl _SYSTEMD_UNIT=pdns.service -n 10 --no-pager
269s Dec 25 16:13:20 ci-359-77591125 (s_server)[3766]: pdns.service: 
Failed to set up IPC namespacing: Resource temporarily unavailable
269s Dec 25 16:13:20 ci-359-77591125 (s_server)[3766]: pdns.service: 
Failed at step NAMESPACE spawning /usr/sbin/pdns_server: Resource 
temporarily unavailable
269s Dec 25 16:13:21 ci-359-77591125 (s_server)[3852]: pdns.service: 
Failed to set up IPC namespacing: Resource temporarily unavailable
269s Dec 25 16:13:21 ci-359-77591125 (s_server)[3852]: pdns.service: 
Failed at step NAMESPACE spawning /usr/sbin/pdns_server: Resource 
temporarily unavailable
269s Dec 25 16:13:23 ci-359-77591125 (s_server)[3876]: pdns.service: 
Failed to set up IPC namespacing: Resource temporarily unavailable
269s Dec 25 16:13:23 ci-359-77591125 (s_server)[3876]: pdns.service: 
Failed at step NAMESPACE spawning /usr/sbin/pdns_server: Resource 
temporarily unavailable
269s Dec 25 16:13:24 ci-359-77591125 (s_server)[3886]: pdns.service: 
Failed to set up IPC namespacing: Resource temporarily unavailable
269s Dec 25 16:13:24 ci-359-77591125 (s_server)[3886]: pdns.service: 
Failed at step NAMESPACE spawning /usr/sbin/pdns_server: Resource 
temporarily unavailable
269s Dec 25 16:13:25 ci-359-77591125 (s_server)[3915]: pdns.service: 
Failed to set up IPC namespacing: Resource temporarily unavailable
269s Dec 25 16:13:25 ci-359-77591125 (s_server)[3915]: pdns.service: 
Failed at step NAMESPACE spawning /usr/sbin/pdns_server: Resource 
temporarily unavailable

269s ++ mktemp
269s + TMPFILE=/tmp/tmp.jah1Y5TJIa
269s + trap cleanup EXIT
269s + tee /tmp/tmp.jah1Y5TJIa
269s + sdig 127.0.0.1 53 smoke.pgsql.example.org A
279s Fatal: Timeout waiting for data
279s + grep -c '127\.0\.0\.222' /tmp/tmp.jah1Y5TJIa
279s 0
279s + echo smoke.pgsql.example.org could not be resolved
279s smoke.pgsql.example.org could not be resolved
279s + exit 1
279s + cleanup


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050024: upgrade-reports: Massive lags in X, apt, writing to disk, starting applications

[Paul Gevers]

Hi Benjamin,

Sorry for the tremendous delay.

On 18-08-2023 14:56, Benjamin Lotter wrote:

- Did any packages fail to upgrade?
KDE as always kind of broke, but could be reinstalled


I guess you don't have more details? If you do, you might want to file 
that information against kde-baseapps.



- Were there any problems with the system after upgrading?
Massive lags when using X/wayland, apt was slow to unpack files while X was
open, felt like IO was "blocked".
Rollling back from Kernel 6.1 to 5.10 fixed the issue


Have you tried later kernels after this? If you have experienced more 
issues, it makes sense to reassign this bug to src:linux. They will 
probably ask more questions.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056594: [Pkg-privacy-maintainers] Bug#1056594: mat2: test failure

[Paul Gevers]

Hi,

On 03-01-2024 14:02, Georg Faerber wrote:

Thanks for the upload, although I would have appreciated communication
about this upfront.


Of course. As a Release Manager, I would have appreciated a more timely 
handeling of an RC issue that blocks other packages. I followed DevRef 
guidance:

"""
Upload fixing only release-critical bugs older than 7 days, with no 
maintainer activity on the bug for 7 days and no indication that a fix 
is in progress: 0 days

"""


Could you please push the relevant changes to git?


I doubt I have access. Also, it's probably easier for you to just apply 
my diff than it is for me to do it. I don't have your archive checked 
out, I used dgit [1].


With kind regards,
Paul

[1] https://browse.dgit.debian.org/mat2.git/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059898: unblock: steam-installer/1:1.0.0.78~ds-4

[Paul Gevers]

Hi Simon,

On 03-01-2024 10:34, Simon McVittie wrote:

In the HTML output, under "Additional info" (which if I understand
correctly is meant to be for notes that do not affect migration),


That's the idea, yes.


it
says:

- Additional info:
 - uninstallable on arch amd64, not running autopkgtest there
 - uninstallable on arch i386, not running autopkgtest there


I recently (some weeks/months ago) enhanced britney2 to take the results 
of the InstallabilityPolicy into account before scheduling autopkgtests, 
to prevent failures due to "can't install". By the looks of it, the 
passing of data goes wrong, because I wouldn't expect this autopkgtest 
info *without* a negative verdict from the InstallabilityPolicy. 
Obviously it's not the task of the AutopkgtestPolicy to prevent 
migration due to non-installability.



but in the YAML output, I see that actually this might be the reason why
it isn't migrating:

 autopkgtest:
   verdict: REJECTED_TEMPORARILY
   ...
   reason:
   - autopkgtest

I find this confusing, because steam-installer doesn't have any autopkgtest
coverage at all.


Well, the AutopkgtestPolicy also schedules tests for reverse 
dependencies and this check happens *before* britney even calculated those.



The steam-installer:amd64 contrib binary package is uninstallable if you
don't have an i386 foreign architecture added, because Valve's proprietary
code has hard dependencies on both amd64 and i386 libraries.


Hmm, interesting. Probably my new code doesn't deal with this 
possibility at all, while apparently the InstallabilityPolicy is smarter.



Is this
perhaps what the migration software is unhappy about? But I thought we
could have uninstallable packages as long as they are not a regression?


Well, I suspect this is in new code. It probably just doesn't support 
this corner case (because I wasn't aware of it and I might have made 
wrong assumptions).



Similarly, the steam:i386 contrib binary package is uninstallable unless
you are actually on an amd64 system.


Ack.


The other binary packages (in main) should be installable on their
appropriate architectures with no special measures.


The AutopkgtestPolicy looks at the joined installability of all binaries 
on an arch.


Thanks for letting us know. I prefer to keep the status quo for a day 
such that I can debug this tomorrow. I hope to add a hint at the end of 
the day (if I don't forget, feel free to ping me if I do).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

[Paul Gevers]

Hi Simon,

On 03-01-2024 20:22, Simon McVittie wrote:

I think all of those are correct?


I think that if apt allows you to install it, chances are that it's a 
britney2 bug. I'll try to debug it tomorrow.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059903: autopkgtest: Add Incus support

[Paul Gevers]

Hi

On 03-01-2024 12:44, Colin Watson wrote:

While at some point you might want to do a bit more abstraction to
reduce code duplication, I think the simplest approach would be to copy
autopkgtest-{build,virt}-lxd to autopkgtest-{build,virt}-incus and do a
little bit of search-and-replace.  I've filed
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/272 for
this.  To help with review, here's the diff against the LXD versions.


Yes, please let's not do this. src:autopkgtest already has a huge 
technical dept, I don't want to add such a copy/paste thing to it. I 
suggest you declare a variable at the start and use that everywhere 
where you now have a diff. And suggest a way how that script can take 
the option (e.g. make the current script a wrapper to a new cloned 
script with the behavior it gets lxd, while the new script requires you 
to define it, or something).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059840: please bump --ram-size for qemu

[Paul Gevers]

Hi,

On 03-01-2024 12:55, Antonio Terceiro wrote:

I think that sound reasonable, but I don't know how to sufficiently judge
this. Maybe my co-maintainers have ideas about it?


I think we can use use the smaller of [4GB, 50% of the host RAM], to
avoid killing a host where 4GB is more than what the host could
reasonably afford.


Maybe also check *free* RAM then?

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059881: autopkgtest: Automatically parsing the summary file in error conditions

[Paul Gevers]

Hi Stefano,

On 02-01-2024 21:54, Stefano Rivera wrote:

It would be great if you could provide a specification for this file
format, so tools like Debusine can have some confidence that they're
parsing it correctly.


$(man autopkgtest) has a section on OUTPUT FORMAT, isn't that what 
you're after?


If not, I think that by now you are the most knowledgeable person on 
this topic. Could you provide a proposal?


Also, as (particularly) startup, reboot and timeout errors can be 
thrown, I'm not sure that can be spec-ed appropriately, but maybe you're 
already fine then because there will not be a summary file?


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059840: please bump --ram-size for qemu

[Paul Gevers]

Control: reassign -1 autopkgtest

Hi Michael,

On 02-01-2024 22:27, Michael Biebl wrote:
You raise an interesting point though by framing this as an autopkgtest 
issue: Maybe the default in autopkgtest-virt-qemu should be bumped.
This value was set in 2014 and systems have significantly more RAM 
nowadays. This way, one wouldn't have to remember to always pass 
--ram-size= when running autopkgtest by hand.

A value of 2G or even 4G seems reasonable. WDYT?


I think that sound reasonable, but I don't know how to sufficiently 
judge this. Maybe my co-maintainers have ideas about it?


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059875: src:rjava: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Hi Dirk,

On 02-01-2024 20:42, Dirk Eddelbuettel wrote:

| 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

I noticed that too over the last few weeks as I tend to keep an eye on my
aggregation at https://qa.debian.org/developer.php?login=e...@debian.org


Nice. I wish every DD did that.


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

Sure. Though that might be harsh / might affect other packages.


They will be notified of the autoremoval automatically and can help you 
fix the situation. If there's work in progress, you can delay the 
autoremoval by pinging this bug, that resets the timer.



We may want to consider exempting i386 as a build arch if that is possible.


Well, if you really can't support i386 anymore (we expect from DD to 
support as many architectures as is *reasonably* possible), you should 
arrange for the removal of the i386 package, including all reverse i386 
dependencies. It would be good to coordinate this with your reverse 
dependencies (at least inform them). In the end removal happens by 
filing appropriate RM bugs against the ftp.debian.org pseudo package.



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

:wave:


FTBFS of your own package is what I consider to be in your control (this 
text is part of the template I use). Either you fix the issue, or you 
decide to no long support i386 with your package, but you'll need to 
coordinate with your reverse dependencies. The removal happens by 
ftp-master once you file the appropriate bugs.



This is an R package, and R no longer releases on i386 meaning upstream may
not have checked / may not be receptive. See eg [1] for the CRAN state of the
package. No i386 there.

I am not sure what else to do besides simply saying 'no longer builds on i386'.


Maybe contact i386 porters for help creating a patch? (We have one: 
Adrian Bunk).


Having said all that, most of our upstreams don't support (for some 
value of support) all the architectures that we support. Still we expect 
from DD to put in *reasonable* effort to support their packages on our 
architectures. So, the call to drop an architecture from the supported 
list is yours to make as a maintainer.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059878: src:devicexlib: fails to migrate to testing for too long: FTBFS on ppc64el

[Paul Gevers]

Source: devicexlib
Version: 0.1.0-2
Severity: serious
Control: close -1 0.8.2-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:devicexlib has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build on ppc64el.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059876: src:mopac: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: mopac
Version: 22.0.6+dfsg-1
Severity: serious
Control: close -1 22.1.0-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:mopac has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on i386.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059875: src:rjava: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: rjava
Version: 1.0-6-1
Severity: serious
Control: close -1 1.0-10-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:rjava has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on i386.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059840: please bump --ram-size for qemu

[Paul Gevers]

Hi Michael,

On 02-01-2024 11:04, Michael Biebl wrote:

we are currently trying to get the systemd upstream autopkgtest suite pass
in Debian sid/trixie with qemu and I'm thrilled to see that qemu support
for debci is currently evaluated.


I think you mean for ci.debian.net (debci is a source package).


There is one failing test remaining, specifically TEST-13-NSPAWN [1],
which requires more then the default 1024M of ram size.
E.g. running it with --ram-size=2048 makes the tests pass successfully.

We thus would like to see the RAM limits be bumped globally to say 2048M
for debci or have a way how individual packages can set the qemu
--ram-size parameter.


I don't mind if debci grew a way to tell autopkgtest for more, but the 
default is set in autopkgtest. However, ...



The discussion on #debian-devel showed, that systemd is not the only
package currently affected by this ram limitation.
It was mentioned that apt also fails when run with virt-qemu.


... I didn't plan to change the default of any package, but I wanted to 
change it in the infrastructure configuration, similar like we do with 
other autopkgtest options [2]. If you agree, I think we can close this 
bug. Otherwise, I think it should be reassigned to autopkgtest.


Paul

[2] 
https://salsa.debian.org/ci-team/debian-ci-config/-/blob/master/config/production/nodes.d/amd64.yaml?ref_type=heads#L14


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059765: linux: isolation-machine autopkgtest fails for multiple reasons

[Paul Gevers]

Hi

On 01-01-2024 22:33, Bastian Blank wrote:

Do we have serial of the machines?


Do you mean of the system where the VM's run, or of the VM itself? IIRC 
the qemu backend of autopkgtest is talking to the VM over serial, but if 
you want to be sure, I'll need to check.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059808: ocfs2-tools: isolation-machine autopkgtest fails: Internal logic failure while mounting /dev/loop0 on /mnt

[Paul Gevers]

Source: ocfs2-tools
Version: 1.8.7-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.


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
PS: I'm going to retry the exercise with /tmp on tmpfs soon again. Be 
warned if ocfs2-tools fails for the same reason as bug 994418.


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

https://ci.debian.net/packages/o/ocfs2-tools/testing/amd64/41429834/

 47s === mount ===
 47s mount.ocfs2: Internal logic failure while mounting /dev/loop0 on 
/mnt. Check 'dmesg' for more information on this error 22.

 47s umount: /mnt: not mounted.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057911: mark libjs-jquery-tablesorter Multi-Arch: foreign

[Paul Gevers]

Control: tags -1 pending

Hi Helmut,

On 10-12-2023 16:15, Helmut Grohne wrote:

Packages (such as erlang-cowboy) that have libjs-jquery-tablesorter in
their dependency tree cannot satisfy their cross Build-Depends, because
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign or annotated :native. In this case, the
foreign marking is reasonable, because we are looking at a pure
javascript library and all of its dependencies are already marked
Multi-Arch: foreign (which implies that none of them is a native
extension). Consider applying the attached patch.


The janitor already made the same change (albeit on a different line), 
so this bug is pending an upload. Feel free to NMU if you want this 
before an other upload happens naturally.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057205: systemtap: version 5.0-1 FTBFS on i386, ppc64el, riscv64

[Paul Gevers]

Control: found -1 4.9-1
Control: severity -1 important

On Fri, 1 Dec 2023 16:53:50 +0100 Emanuele Rocca  wrote:

Package: systemtap
Version: 5.0-1
Severity: serious


I have lowered the severity to enable migration, given that 5.0-2 works 
around the problem.


The builds on r-b [1] show that i386 fails in the same way in trixie 
already, hence I added a found version.


Paul

[1] https://tests.reproducible-builds.org/debian/rb-pkg


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059788: src:tracker-miners: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: tracker-miners
Version: 3.4.6-1
Severity: serious
Control: close -1 3.4.6-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1057617

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-miners has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version in unstable 
fails to build as reported in bug 1057617.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059787: src:xfce4-power-manager: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: xfce4-power-manager
Version: 4.18.2-1
Severity: serious
Control: close -1 4.18.3-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:xfce4-power-manager has been trying to 
migrate for 31 days [2]. Hence, I am filing this bug. The version in 
unstable has arch:all binaries built by the uploader. Unfortunately the 
binNMU infrastructure doesn't support binNMU'ing arch:all (and DAK still 
doesn't throw away uploaded binaries). Hence, a source-only upload is 
required. Normally I do that (a no-change source-only NMU) for packages 
in this state, but given the large amount of open bugs, I don't feel 
comfortable taking that responsibility.


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=xfce4-power-manager



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055370: debci setup should include security repositories

[Paul Gevers]

Control: reassign -1 lxc-templates
Control: retitle -1 consider adding security repos by default
Control: affects -1 debci autopkgtest

Hi all,

On 05-11-2023 03:41, Santiago Ruano Rincón wrote:

Is there any reason why `debci setup ...` doen't configure the security
repostories inside the lxc containers? This is the sources.list of a
just created autopkgtest-bookworm-amd64 container:

 deb http://deb.debian.org/debian bookworm main contrib non-free 
non-free-firmware
 deb-src http://deb.debian.org/debian bookworm main contrib non-free 
non-free-firmware
 deb http://deb.debian.org/debian-debug bookworm-debug main contrib 
non-free non-free-firmware
 deb-src http://deb.debian.org/debian-debug bookworm-debug main contrib 
non-free non-free-firmware


As debci with the lxc backend just uses lxc-templates to set-up the 
containers, I think this is something for lxc-templates to consider.


Having said that, I'm unsure if *I* (with my ci.debian.net maintainer 
and my Release Team member hat on) would want that. For lxc users it's 
easier to *add* repositories than it is to remove them for the use case 
where you don't want the security archive installed (e.g. for Release 
Team's testing of proposed-updates against stable). So, for 
ci.debian.net I'd want an easy way to opt-out of the security archive in 
case it gets added by default.


debci supports the user (both via the API as well as via the 
self-service) to easily add repositories once debci is configured to 
support those additional repositories (as ci.debian.net does).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056594: mat2: test failure

[Paul Gevers]

Control: tags -1 pending

On 01-01-2024 09:50, Paul Gevers wrote:
I'm going to NMU with this patch shortly. @gregor, any reason why you 
didn't the upload to DELAYED after you built it already?


I have uploaded the attached changes.

Paul
diff --git a/debian/changelog b/debian/changelog
index 2713ce6..426d0a2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+mat2 (0.13.4-2.1) unstable; urgency=medium
+
+  [ jvoisin ]
+  * Fix the CI on Debian
+
+ -- Paul Gevers   Mon, 01 Jan 2024 10:12:38 +0100
+
 mat2 (0.13.4-2) unstable; urgency=medium
 
   * debian/patches:
diff --git a/debian/patches/fix-the-ci-on-debian.patch 
b/debian/patches/fix-the-ci-on-debian.patch
new file mode 100644
index 000..7a33457
--- /dev/null
+++ b/debian/patches/fix-the-ci-on-debian.patch
@@ -0,0 +1,20 @@
+From: jvoisin 
+Date: Wed, 8 Nov 2023 15:28:08 +0100
+X-Dgit-Generated: 0.13.4-2.1 dc2618f8783397cf03cce6360e8bf90f5f75b284
+Subject: Fix the CI on Debian
+
+
+---
+
+diff --git a/tests/test_libmat2.py b/tests/test_libmat2.py
+index ee43fba..c64e4cb 100644
+--- a/tests/test_libmat2.py
 b/tests/test_libmat2.py
+@@ -508,6 +508,7 @@ class TestCleaning(unittest.TestCase):
+ 'TrackID': 1,
+ 'TrackLayer': 0,
+ 'TransferCharacteristics': 'BT.709',
++'VideoFullRangeFlag': 0,
+ },
+ },{
+ 'name': 'wmv',
diff --git a/debian/patches/series b/debian/patches/series
index 3a61826..f802c78 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 0001-setup.py-drop-data-files.patch
+fix-the-ci-on-debian.patch


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056594: mat2: test failure

[Paul Gevers]

Dear all,

On Thu, 23 Nov 2023 18:03:45 +0100 gregor herrmann 
wrote:

Currently mat2's test suite fails, maybe due to newer libimage-exiftool-perl
releases. This can be seen on ci.debian.net, but the same failures
occur during the build tests, so the package FTBFS.

I've locally added upstream commit
https://0xacab.org/jvoisin/mat2/-/commit/bbd5b2817c9d64013e2f5ed670aca8d4738bb484
as a quilt patch, and the tests pass both during build and
autopkgtest.


I'm going to NMU with this patch shortly. @gregor, any reason why you 
didn't the upload to DELAYED after you built it already?


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059785: benchmark breaks ABI without SONAME bump

[Paul Gevers]

Source: benchmark
Control: found -1 benchmark/1.8.3-1
Severity: serious
Tags: sid trixie

Dear maintainer(s),

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


   passfail
benchmark  from testing1.8.3-1
pytorchfrom testing2.0.1+dfsg-5
all others from testingfrom testing

I copied some of the output at the bottom of this report. This looks 
very much like benchmark dropped a symbol from its shared library 
without a SONAME bump. Can you please investigate and clarify? Currently 
this is blocking the migration of benchmark to testing, as I reported in 
bug 1056202, but because benchmark is a key package, that didn't lead to 
its removal.


The release team has also received a request to rebuild 
ros2-performance-test-fixture (bug 1057304), so it seems more packages 
are affected.


Paul

[1] https://qa.debian.org/excuses.php?package=benchmark

https://ci.debian.net/data/autopkgtest/testing/arm64/p/pytorch/41359814/log.gz

1276s /usr/lib/libtorch-test/c10_intrusive_ptr_benchmark: symbol lookup 
error: /usr/lib/libtorch-test/c10_intrusive_ptr_benchmark: undefined 
symbol: _ZN9benchmark8internal9BenchmarkC2EPKc
1276s autopkgtest [08:27:24]: test 
44_of_98__cpptest__c10_intrusive_ptr_benchmark




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059765: linux: isolation-machine autopkgtest fails for multiple reasons

[Paul Gevers]

Hi Bastian,

On 31-12-2023 18:33, Bastian Blank wrote:

Do you have a handy script available to try this by hand?  I was just
looking at this test (to unravel the loop logic and replace it with one
test per kernel), but I'm not sure if this ever worked before.


It was nearly completely attached at the bottom of the e-mail. Writing 
it out and providing a patch (from memory, so untested) as well.


# in path with src:linux unpacked
# Apply patch
export ADT_REBOOT_MARK=step0 # or whatever number matches your kernel
export AUTOPKGTEST_TMP=$(mktemp -d)
chmod a+x debian/tests/selftests
debian/tests/selftests

Paul
diff --git a/debian/tests/selftests b/debian/tests/selftests
index 02cc29372e..ff12a0cd17 100644
--- a/debian/tests/selftests
+++ b/debian/tests/selftests
@@ -1,4 +1,4 @@
-#!/bin/bash -eu
+#!/bin/bash -eux
 
 PATH=/usr/sbin:/sbin:/usr/bin:/bin
 
@@ -81,8 +81,8 @@ step=$((step + 1))
 if [ "$step" -lt "$steps" ]; then
 # Load the next kernel
 ver=$abiname${localversion[$step]}
-kexec -l /boot/vmlinuz-$ver --initrd /boot/initrd.img-$ver --reuse-cmdline
-/tmp/autopkgtest-reboot step$step
+#kexec -l /boot/vmlinuz-$ver --initrd /boot/initrd.img-$ver --reuse-cmdline
+#/tmp/autopkgtest-reboot step$step
 fi
 
 exit 0


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059767: aptfs: isolation-machine autopkgtest fails: find: ‘target/bash’: Invalid argument

[Paul Gevers]

Source: aptfs
Version: 2:1.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.


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/unstable/amd64/a/aptfs/41401338/log.gz

 72s lr-xrwSrwt 3 root root 0 Jan  1  1970 zypper-common -> zypper
 72s lr-xrwSrwt 3 root root 0 Jan  1  1970 zypper-doc -> zypper
 72s dr-x-wSr-t 3 root root 0 Jan  1  1970 zytrax
 72s dr-x-wSr-t 3 root root 0 Jan  1  1970 zziplib
 72s lr-xrwSrwt 3 root root 0 Jan  1  1970 zziplib-bin -> zziplib
 72s dr-x-wSr-t 3 root root 0 Jan  1  1970 zzuf
 72s dr-x-wSr-t 3 root root 0 Jan  1  1970 zzz-to-char
 72s dr-x-wSr-t 3 root root 0 Jan  1  1970 zzzeeksphinx
 72s find: ‘target/bash’: Invalid argument
 72s target/bash
 73s autopkgtest [17:05:06]: test 0001-smoketest: ---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052557: [Pkg-pascal-devel] Bug#1052557: Bug#1052557: fpc: Compiler bootstrap for more release architectures

[Paul Gevers]

Hi,

On 30-12-2023 11:17, Abou Al Montacir wrote:
I've checked support of both architecture by FPC and it seems they are 
only supported in non released development branch.*
As Debian is shipping 3.2.2, there is no support for any of these 
architectures there.

So we will need to wait until new FPC major release is out.


Not claiming we should do that now, but in the past we supported arm64 
in Debian well before we had an fpc version from upstream that supported it.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059765: linux: isolation-machine autopkgtest fails for multiple reasons

[Paul Gevers]

Source: linux
Version: 6.6.8-1
Severity: normal

Dear linux maintainers,

Recently I added some isolation-machine support to ci.debian.net and one 
of the first packages I tried to run the test for is src:linux. 
Unfortunately, the isolation-machine based test (selftests) fails (the 
reboot that autopgtest schedules just hangs until it times out). I 
haven't used kexec before in my life, so I'm not totally sure what to 
expect from $(kexec -l ...) but I *suspect* (after reading the 
autopkgtest spec [1]) that the call after kexec in selftests is wrong:

"""
In some cases your test needs to do the reboot by itself, e. g. through
kexec, or a reboot command that is hardcoded in the piece of software
that you want to test. To support those, you need to call
/tmp/autopkgtest-reboot-prepare my_mark at a point as close as
possible to the reboot instead; this will merely save the state but not
issue the actual reboot by itself
"""
(so /tmp/autopkgtest-reboot-prepare instead of /tmp/autopkgtest-reboot, 
and maybe it should be *before* the kexec call)
On the other hand, when I run $(uname -a) after a $(manual kexec -l ..) 
call, it looks like I'm still running the "old" kernel, so I'm not sure 
if that line does what I would hope it to do either (it's extremely 
quick too).


When I play a bit and finally can get the test to run for the current 
kernel (manually passing the right step number in ADT_REBOOT_MARK for 
the current kernel and an appropriate AUTOPKGTEST_TMP [2]) I also notice 
that $(make headers_install) ends with:

"""
/bin/sh: 1: rsync: not found
"""
so that's a missing test dependency.

After all that, the test (for the rt kernel) runs nice although it seems 
to hang on (maybe just a very long running test with no output, I waited 
several minutes, is that timeout referenced in seconds or minutes?):

"""
ok 7 selftests: cgroup: test_cpuset
# timeout set to 45
# selftests: cgroup: test_zswap
"""
Second time I ran this was for the regular kernel used by 
autopkgtest-build-qemu and that passed that stage with ease and seemed 
to run to the end (with failures, but those you can iron out once we get 
decent logs).


Also, I suspect the total test will timeout (after 2:47) if we test all 
desired kernel flavors in one test. So instead of squeezing everything 
in one autopkgtest (stanza) it's probably smarter to generate a stanza 
per kernel you want to run (because then you're only limited by the 
overall timeout of 8.5 hours).


Paul

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



[2] # emacs debian/tests/selftests # to disable kexec and 
/tmp/autopkgtest-reboot call and to set -x

chmod a+x debian/tests/selftests
# export ADT_REBOOT_MARK=step0
# export root@host:/tmp/autopkgtest.Y35OYd/build.rih/src# export 
AUTOPKGTEST_TMP=$(mktemp -d)

# debian/tests/selftests # testing the default installed kernel


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059725: autopkgtest: isolation-machine test fails: nearly all tests in podman-init fail

[Paul Gevers]

Source: autopkgtest
Version: 5.31.2
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Hi,

I recently added support for isolation-machine testing on ci.d.n and 
when I ran the autopkgtest of src:autopkgtest, it failed. It failed the 
podman-init test and out of 44 tests, only 2 passed 
(PodmanInitRunner.test_user and PodmanInitRunner.test_user_needs_root)


That's not very hopeful for the --podman --init flavor of 
autopkgtest-virt-docker.


Nearly all of them fail in the way quoted below, I haven't figured out 
where these log errors come from: """logger: send message failed: 
Operation not permitted""" while running `create-normal-user`.


Currently a full log lives here: 
https://ci.debian.net/data/autopkgtest/testing/amd64/a/autopkgtest/41372619/log.gz


The quote below is from me running the test inside a qemu testbed.

Paul

19:22:05 I: Started ./tests/autopkgtest 
PodmanInitRunner.test_skippable_success
19:22:06 O: test_skippable_success 
(__main__.PodmanInitRunner.test_skippable_success)

19:22:09 O: A skippable test succeeds ... FAIL
19:22:09 O:
19:22:09 O: 
==
19:22:09 O: FAIL: test_skippable_success 
(__main__.PodmanInitRunner.test_skippable_success)

19:22:09 O: A skippable test succeeds
19:22:09 O: 
--

19:22:09 O: Traceback (most recent call last):
19:22:09 O:   File 
"/tmp/autopkgtest.BNQ3Xt/build.9s6/real-tree/./tests/autopkgtest", line 
455, in test_skippable_success

19:22:09 O: self.assertEqual(code, 0, err)
19:22:09 O: AssertionError: 20 != 0 : autopkgtest: DBG: autopkgtest 
options: Namespace(override_control=None, only_tests=[], 
skip_tests=None, built_binaries=False, 
packages=['/tmp/autopkgtest.test.e19zee88/testpkg'], output_dir=None, 
logfile=None, summary=None, verbosity=2, setup_commands=[], 
setup_commands_boot=[], add_apt_sources=[], add_apt_releases=[], 
pin_packages=[], apt_pocket=[], apt_default_release=None, 
enable_apt_fallback=True, copy=[], env=[], ignore_restrictions=[], 
user=None, gainroot=None, shell_fail=False, shell=False, timeout=0, 
timeout_short=None, timeout_copy=None, timeout_install=None, 
timeout_test=None, timeout_build=None, timeout_factor=1.0, 
set_lang=None, auto_control=True, build_parallel=None, 
needs_internet='run', validate=False)
19:22:09 O: autopkgtest: DBG: virt-runner arguments: ['podman', 
'--init', 'autopkgtest/systemd/debian:testing']
19:22:09 O: autopkgtest: DBG: actions: [('unbuilt-tree', 
'/tmp/autopkgtest.test.e19zee88/testpkg', False)]

19:22:09 O: autopkgtest: DBG: build binaries: False
19:22:09 O: autopkgtest: DBG: testbed init
19:22:09 O: autopkgtest [19:22:06]: starting date and time: 2023-12-30 
19:22:06+

19:22:09 O: autopkgtest [19:22:06]: version 5.31.2
19:22:09 O: autopkgtest [19:22:06]: host host; command line: 
/usr/bin/autopkgtest -d --no-built-binaries 
/tmp/autopkgtest.test.e19zee88/testpkg -- podman --init 
autopkgtest/systemd/debian:testing

19:22:09 O: autopkgtest: DBG: got reply from testbed: ok
19:22:09 O: autopkgtest: DBG: testbed open, scratch=None
19:22:09 O: autopkgtest: DBG: sending command to testbed: open
19:22:09 O: autopkgtest: DBG: got reply from testbed: ok 
/tmp/autopkgtest-virt-docker.shared.3sui98zn/downtmp
19:22:09 O: autopkgtest: DBG: sending command to testbed: 
print-execute-command
19:22:09 O: autopkgtest: DBG: got reply from testbed: ok 
podman,exec,-i,2afe2dad7c01b2607f2184eb63ee03dee0172a73a104bee26d971fd1092a81df,env,-i,bash,-c,set%20-a%3B%20%5B%20-r%20/etc/environment%20%5D%20%26%26%20.%20/etc/environment%202%3E/dev/null%20%7C%7C%20true%3B%20%5B%20-r%20/etc/default/locale%20%5D%20%26%26%20.%20/etc/default/locale%202%3E/dev/null%20%7C%7C%20true%3B%20%5B%20-r%20/etc/profile%20%5D%20%26%26%20.%20/etc/profile%202%3E/dev/null%20%7C%7C%20true%3B%20set%20%2Ba%3B%22%24%40%22%3B%20RC%3D%24%3F%3B%20%5B%20%24RC%20%21%3D%20255%20%5D%20%7C%7C%20RC%3D253%3B%20set%20-e%3Bmyout%3D%24%28readlink%20/proc/%24%24/fd/1%29%3Bmyerr%3D%24%28readlink%20/proc/%24%24/fd/2%29%3Bmyout%3D%22%24%7Bmyout/%5B/%5C%5C%5B%7D%22%3B%20myout%3D%22%24%7Bmyout/%5D/%5C%5C%5D%7D%22%3Bmyerr%3D%22%24%7Bmyerr/%5B/%5C%5C%5B%7D%22%3B%20myerr%3D%22%24%7Bmyerr/%5D/%5C%5C%5D%7D%22%3BPS%3D%24%28ls%20-l%20/proc/%5B0-9%5D%2A/fd/%2A%202%3E/dev/null%20%7C%20sed%20-nr%20%27%5C%23%28%27%22%24myout%22%27%7C%27%22%24myerr%22%27%29%23%20%7B%20s%23%5E.%2A/proc/%28%5B0-9%5D%2B%29/.%2A%24%23%5C1%23%3B%20p%7D%27%7Csort%20-u%29%3BKILL%3D%22%22%3Bfor%20pid%20in%20%24PS%3B%20do%20%20%20%20%5B%20%24pid%20-ne%20%24%24%20%5D%20%26%26%20%5B%20%24pid%20-ne%20%24PPID%20%5D%20%7C%7C%20continue%3B%20%20%20%20KILL%3D%22%24KILL%20%24pid%22%3Bdone%3B%5B%20-z%20%22%24KILL%22%20%5D%20%7C%7C%20kill%20-9%20%24KILL%20%3E/dev/null%202%3E%261%20%7C%7C%20true%3Bexit%20%24RC,--

19:22:09 O: autopkgtest: DBG: sending command to testbed: capabilities
19:22:09 O: autopkgtest: DBG: got reply from testbed: ok 

Bug#1059444: LXD: cython3 autopkgtest hangs forever due to stall in copyup

[Paul Gevers]

Hi Stefano,

On 29-12-2023 02:26, stefa...@debian.org wrote:

Hi Debian (2023.12.25_17:20:25_+)

This reproduces reliably, but I haven't got to the bottom of it. It
looks like a stalled pipeline somewhere.


Caught it again, the tee from lib/in-testbed/wrapper.sh is trying to
write to stdout, but buffer is full.


"The" tee? Did you happen to know which one?


And autopkgtest isn't reading the buffer, it's busy waiting for a write
to complete.


Which after a very quick check *hints* that we may want to add real (or 
/dev/null) stderr and stdout here:
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/lib/adt_testbed.py?ref_type=heads#L1198 
?


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059559: runit: isolation-machine autopkgtest fails: this is a protected package; it should not be removed

[Paul Gevers]

Source: runit
Version: 2.1.2-54+usrmerge
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/r/runit/testing/amd64/41372611/

 39s autopkgtest [10:32:33]: test init-switch: [---
 39s testbed is running with systemd
 39s installing runit-init
 39s dpkg: error processing package init (--remove):
 39s  this is a protected package; it should not be removed
 39s Errors were encountered while processing:
 39s  init
 40s autopkgtest [10:32:34]: test init-switch: ---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059555: src:rust-wasmtime: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: rust-wasmtime
Version: 10.0.1+dfsg-7
Severity: serious
Control: close -1 15.0.0+dfsg-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1057198

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-wasmtime has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version in unstable 
failed to build as reported in bug 1057198.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059553: minicoredumper: isolation-machine autopkgtest fails: stdio.h: No such file or directory

[Paul Gevers]

Source: minicoredumper
Version: 2.0.3-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.


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/m/minicoredumper/testing/amd64/41366840/

 65s autopkgtest [21:25:59]: test coredump: [---
 65s coredump.c:1:10: fatal error: stdio.h: No such file or directory
 65s 1 | #include 
 65s   |  ^
 65s compilation terminated.
 66s autopkgtest [21:26:00]: test coredump: ---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059552: bilibop: isolation-machine autopkgtest (lockfs) fails on bookworm and newer

[Paul Gevers]

Source: bilibop
Version: 0.6.3
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 on bookworm, trixie 
and unstable (it passes on buster). 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/b/bilibop/testing/amd64/41366843/

135s autopkgtest [21:30:14]: test lockfs: [---
135s # grep -E ' / |overlay|lockfs|aufs' /proc/mounts
135s /dev/vda1 / ext4 rw,relatime,errors=remount-ro 0 0
135s
135s # lsblk --output=name,ro,mountpoint
135s NAME   RO MOUNTPOINT
135s fd0 0
135s sr0 0
135s vda 0
135s └─vda1  0 /
135s
135s # df --output=source,fstype,target
135s Filesystem Type Mounted on
135s udev   devtmpfs /dev
135s tmpfs  tmpfs/run
135s /dev/vda1  ext4 /
135s tmpfs  tmpfs/dev/shm
135s tmpfs  tmpfs/run/lock
135s autopkgtest9p   /run/autopkgtest/shared
135s tmpfs  tmpfs/run/user/0
135s
135s STAGE 0: root filesystem is not locked.
135s STAGE 0: enable bilibop-lockfs and reboot.
135s
135s # echo BILIBOP_LOCKFS='true' | tee /etc/bilibop/bilibop.conf
135s BILIBOP_LOCKFS=true
135s
135s # sync
135s
135s Killed
136s autopkgtest [21:30:15]: test process requested reboot with marker 
lockfs

154s # grep -E ' / |overlay|lockfs|aufs' /proc/mounts
154s tmpfs /overlay tmpfs rw,relatime,mode=755,inode64 0 0
154s /dev/vda1 /overlay/ro ext4 ro,relatime 0 0
154s overlay / overlay 
rw,relatime,lowerdir=/overlay/ro,upperdir=/overlay/rw,workdir=/overlay/.rw 
0 0

154s
154s # lsblk --output=name,ro,mountpoint
154s NAME   RO MOUNTPOINT
154s fd0 0
154s sr0 0
154s vda 1
154s └─vda1  1 /overlay/ro
154s
154s # df --output=source,fstype,target
154s Filesystem Type Mounted on
154s udev   devtmpfs /dev
154s tmpfs  tmpfs/run
154s tmpfs  tmpfs/overlay
154s /dev/vda1  ext4 /overlay/ro
154s overlayoverlay  /
154s tmpfs  tmpfs/dev/shm
154s tmpfs  tmpfs/run/lock
154s autopkgtest9p   /run/autopkgtest/shared
154s tmpfs  tmpfs/run/user/0
154s
154s mount: /overlay/ro: cannot remount /dev/vda1 read-write, is 
write-protected.
154sdmesg(1) may have more information after failed mount system 
call.

154s STAGE 1: root filesystem is successfully locked with hard policy.
154s STAGE 1: change lockfs settings and reboot.
154s
154s # blockdev -v --setrw /dev/vda1
154s set read-write succeeded.
154s
154s # mount -v -o remount,rw /overlay/ro
155s autopkgtest [21:30:34]: test lockfs: ---]
155s autopkgtest [21:30:34]: test lockfs:  - - - - - - - - - - results - 
- - - - - - - - -

155s lockfs   FAIL non-zero exit status 32



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058018: libadios2-common-core-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/cmake/adios2/adios2-config.cmake

[Paul Gevers]

Hi Drew,

On Mon, 11 Dec 2023 20:24:01 +0100 Drew Parsons  wrote:

Control: severity -1 important


Helmut disagreed with your call here and asked the Release Team on IRC 
to have a check.



Call it teething issues. This is a new package, so I'm trying to avoid
making debian/control more verbose than it needs to be by not crowding
the fields with the strict specifications needed to avoid this error.


I agree with Helmut that under normal circumstances this bug is an RC 
issue and I think you agree too. I think that adding a versioned 
Breaks/Replaces that you can drop after the release of trixie isn't too 
much to ask for something that has been part of trixie already. Having 
said that, I'm not going to overrule you.



Once the new version migrates to testing, I'll close this bug and we
can pretend it never happened.


For next time, I ask you to consider either using experimental to iron 
out things like this and/or ensure your package doesn't migrate to 
testing until you believe you're done. Having said that, unstable does 
have users. E.g. our derivatives often pull from unstable, so even for 
those it's nice to do the right thing. I'm sure you don't know of all 
our derivatives when they freeze, and hence if they happened to have 
released to their stable the thing that now breaks.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059509: release-notes: script -t is deprecated, should we recommend --log-timing?

[Paul Gevers]

Package: release-notes
Severity: minor

Note to self. I just stumbled upon $(man script):
"""
   -t[file], --timing[=file]
   Output timing data to standard error, or to file when given. 
This option is deprecated in favour of --log-timing where the file

   argument is not optional.
"""

We use the -t option in the "4.4.1. Recording the session" section, so 
we should probably revisit that.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059506: /u/s/d/ovmf/NEWS.Debian.gz: link misses compression extension

[Paul Gevers]

Package: ovmf
Version: 2023.11-2
Severity: minor
File: /usr/share/doc/ovmf/NEWS.Debian.gz

Hi,

I just got the NEWS flashed by apt-listchanges, copy/pasted the link and 
noticed the file mentioned in NEWS.Debian.gz to not exist. On disk, the 
file is compressed, so ideally the link should point to 
/usr/share/doc/ovmf/howto-2M-to-4M-migration.md.gz


Paul

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/8 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

ovmf depends on no packages.

ovmf recommends no packages.

Versions of packages ovmf suggests:
ii  qemu-system-x86  1:8.1.2+ds-1

-- no debconf information


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059495: src:corectrl: unsatisfied build dependency in testing: libtrompeloeil-cpp-dev

[Paul Gevers]

Source: corectrl
Version: 1.3.8+ds-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#1059494: src:python-refurb: unsatisfied build dependency in testing: python3-fastapi

[Paul Gevers]

Source: python-refurb
Version: 1.24.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#1059493: src:python-docx: unsatisfied build dependency in testing: python3-behave

[Paul Gevers]

Source: python-docx
Version: 1.1.0+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.

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#1059487: src:django-oauth-toolkit: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: django-oauth-toolkit
Version: 2.3.0-1
Severity: serious
Control: close -1 2.3.0-2
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:django-oauth-toolkit has been trying to 
migrate for 34 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=django-oauth-toolkit



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059484: rasdaemon: autopkgtest failure: cannot access '/var/lib/rasdaemon/ras-mc_event.db'

[Paul Gevers]

Source: rasdaemon
Version: 0.8.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package rasdaemon, great. 
However, it fails. Currently this failure is blocking the migration to 
testing [1]. Can you please investigate the situation and fix it?


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

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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rasdaemon/40156577/log.gz

 34s ls: cannot access '/var/lib/rasdaemon/ras-mc_event.db': No such 
file or directory

 34s autopkgtest [11:52:08]: test ras-mc-ctl


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059478: src:vectorscan: fails to migrate to testing for too long: autopkgtest regression on ppc64el

[Paul Gevers]

Source: vectorscan
Version: 5.4.10.1-1
Severity: serious
Control: close -1 5.4.11-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:vectorscan has been trying to migrate for 
35 days [2]. Hence, I am filing this bug. The version in unstable fails 
its own autopkgtest on ppc64el.


https://ci.debian.net/packages/v/vectorscan/testing/ppc64el/41340940/
"""
 40s build: OK
 40s Illegal instruction
"""

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059477: src:patool: fails to migrate to testing for too long: new test depends on amd64/i386 only binary

[Paul Gevers]

Source: patool
Version: 1.12-5
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:patool has been trying to migrate for 33 
days [2]. Hence, I am filing this bug. If I read the history correctly, 
the version in unstable added a test to the list of autopkgtest which 
Depends on rar. rar is only available on amd64 and i386, hence the test 
fails on other architectures to install its dependencies. 
Non-installability of test dependencies can't really be handled 
correctly automatically (is the non-installability OK, or actually 
showing a problem), so you'll have to deal with it. I recommend to add 
an "Architecture" line to the second test stanza containing amd64 and 
i386. There is also the option to use the skip-not-installable 
restriction, but I don't recommend using that (I regret I added that to 
autopkgtest because too often it hides real problems).


On top of that, the upload included the binary, which means that the 
migration is blocked as we don't allow uploader built binaries in 
testing, but we can't meaningful binNMU arch:all binaries yet. Normally 
I would NMU with no-change version, but given the autopkgtest failure, I 
leave it to you.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059447: src:lz4-java: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: lz4-java
Version: 1.8.0-3
Severity: serious
Control: close -1 1.8.0-4
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:lz4-java has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on i386.


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=lz4-java



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052838: [debian-mysql] Bug#1052838: mariadb: FTBFS: make[1]: *** [debian/rules:161: override_dh_auto_test] Error 1

[Paul Gevers]

Hi,

On Thu, 26 Oct 2023 10:59:50 +0200 Lucas Nussbaum  wrote:

Hi,

On 02/10/23 at 21:59 -0700, Otto Kekäläinen wrote:
> Hi!
> 
> The relevant lines from log seems to be:
> 
> > main.bind_address_resolution w4 [ fail ]

> ...
> > 2023-09-26  6:31:03 0 [ERROR] Can't start server: Bind on TCP/IP port. Got 
error: 98: Address already in use
> > 2023-09-26  6:31:03 0 [ERROR] Do you already have another server running on 
port: 16020 ?
> > 2023-09-26  6:31:03 0 [ERROR] Aborting
> 
> What might have been holding port 16020 during the test run?


I could reproduce the issue again, and I was not running anything else
on the node.


The ci.debian.net results for mariadb seem to be very flaky lately (on 
amd64 they fail roughly 9/10) since version 1:10.11.6-1. Might be 
related (although the failure is different). i386 and arm64 seem to be 
exceptions.


https://ci.debian.net/packages/m/mariadb/testing/amd64/

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf

[Paul Gevers]

Hi Julian,

On 23-12-2023 20:40, Julian Andres Klode wrote:

I know this is automated but I feel lije it would be sensible to scan


It's *mostly* automated.


the logs for well known bugs so that you don't end up filing bugs
against every package broken by valgrind's missing support for the new
NOP sequences in binutils.


I do *some* minor triaging, but I didn't know this to be a common 
problem. Where do you think I should have picked this up?


Anyways, this bug is already closed (when I submitted) and because apt 
is a key package, it doesn't even do anything against apt, so the bug 
serves mostly for tracking purposes.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf

[Paul Gevers]

Source: apt
Version: 2.7.6
Severity: serious
Control: close -1 2.7.7
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:apt has been trying to migrate for 31 days 
[2]. Hence, I am filing this bug. The version in unstable fails its own 
autopkgtest on armhf.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059286: cacti: CVE-2023-46490

[Paul Gevers]

Hi,

On 22-12-2023 13:17, Moritz Mühlenhoff wrote:

There's also a reference for
https://github.com/Cacti/cacti/security/advisories/GHSA-f4r3-53jr-654c
but it's noin-public for two months now, might be worth checking with
upstream for the status.


Upstream confirmed they are working on an official release.

They referred me to these (haven't checked myself, just forwarding for 
info):


https://github.com/Cacti/cacti/commit/58a980f335980ab57659420053d89d4e721ae3fc
https://github.com/Cacti/cacti/commit/73d9a60e24d6d826e6343b94d833b48c28b68643

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059226: release.debian.org: Help doris migrate to testing

[Paul Gevers]

Control: retitle -1 britney2 wrong installability block in autopkgtest

Hi Bas,

On 21-12-2023 14:06, Bas Couwenberg wrote:

doris (5.0.3~beta+dfsg-17) is not migrating to testing, the excuses suggest 
this is due to superficial autopkgtests:

  https://qa.debian.org/excuses.php?package=doris


No, I think the problem is:
uninstallable on arch arm64, not running autopkgtest there

which I think is a bug in britney2 as this isn't a regression and 
britney2 shouldn't block on it. I've hinted doris but I'll leave this 
bug open for us to fix the issue.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386

[Paul Gevers]

Source: meson
Version: 1.2.3-1
Severity: serious
Control: close -1 1.3.0-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:meson has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable fails its 
own autopkgtest on arm64 and i386 (and armel, but that's not a regression).


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059222: src:pv: fails to migrate to testing for too long: FTBFS on armhf

[Paul Gevers]

Source: pv
Version: 1.8.0-3
Severity: serious
Control: close -1 1.8.5-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:pv has been trying to migrate for 31 days 
[2]. Hence, I am filing this bug. The version in unstable failed to 
build on armhf.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059220: src:restic: fails to migrate to testing for too long: new Build-Depends is no migration candidate

[Paul Gevers]

Source: restic
Version: 0.16.0-1
Severity: serious
Control: close -1 0.16.2-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:restic has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable has a new 
Build-Depends that isn't ready to migrate yet: 
golang-github-backblaze-blazer. Please ensure it migrates.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059168: Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues

[Paul Gevers]

retitle 1059168 flaky autopkgtest
user debian...@lists.debian.org
usertag 1059168 flaky
thanks
BCC: control@b.d.o

Hi,

On 21-12-2023 10:04, Jérémy Lal wrote:
Thank you for https://bugs.debian.org/1059168 



I noticed "Marked as found in versions nodejs/18.19.0+dfsg-6 and reopened."
while the test is flaky, retrying it will make it pass, so the bug is 
not as important as it seems.
And indeed, https://tracker.debian.org/pkg/zlib 
 is no longer blocked by nodejs.


It happens that I typically file bugs about flaky tests with severity 
serious with the following reasoning:

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

Having said that, I hardly ever fight over the severity if the 
maintainer(s) drop severity. It depends a bit on how flaky the test is, 
passing 1/3 or worse is really bad, passing more than 9/10 can be 
defended as acceptable but ideally should be fixed. My personal boundary 
for filing flaky bugs seems to lay around 1/5 to failures.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059165: [Pkg-javascript-devel] Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues

[Paul Gevers]

Hi,

On 20-12-2023 23:08, Jérémy Lal wrote:

I did the one for burp.


Thanks for that.


Dolfin has active maintainers, though.


I think I need to file a "flaky autopkgtest" bug report against dolfin.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058696: bugs.debian.org: Can we change the mail address of the release.debian.org pseudo package?

[Paul Gevers]

Hi all,

On 20-12-2023 05:17, Don Armstrong wrote:

On Tue, 19 Dec 2023, Cord Beermann wrote:

So I need some examples.


:0
* 1^0 ^X-Debian-PR-Package:.*release.debian.org
$junkdir/debbugs.$YEARMONTH

should be sufficient to get most (if not all of them).


Please hold. Some of the members of the team not present at Cambridge 
now raise concerns about this change. I admit that at least I *thought* 
you could subscribe in the bts to packages, but apparently that can only 
be done via the tracker. The tracker has hurdles due to its subscribing 
feature no longer being properly supported by browsers, so it's rather 
clumsy (it can be done).


Let us try to agree first.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059166: src:pelican: fails to migrate to testing for too long: unresolved RC issue and non-migrating B-D

[Paul Gevers]

Source: pelican
Version: 4.8.0+dfsg-3
Severity: serious
Control: close -1 4.9.1+dfsg-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1057484

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:pelican has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable has an 
unresolved RC issue (bug 1057484) and gained a Build-Depends that's not 
a migration candidate.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059165: src:zlib: fails to migrate to testing for too long: triggers autopkgtest issues

[Paul Gevers]

Source: zlib
Version: 1:1.2.13.dfsg-3
Severity: serious
Control: close -1 1:1.3.dfsg-3
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: affects -1 src:burp src:dolfin src:nodejs
Control: block -1 by 1057880

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:zlib has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. The version in unstable triggers 
autopkgtest failures in multiple packages (although I suspect that the 
current dolfin issues are due to it being flaky). The failure for burp 
has already a bug report against that package, which leaves nodejs on i386.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058696: bugs.debian.org: Can we change the mail address of the release.debian.org pseudo package?

[Paul Gevers]

Hi Cord,

On 19-12-2023 19:38, Cord Beermann wrote:

Hallo! Du (Don Armstrong) hast geschrieben:


On Sat, 16 Dec 2023, Cord Beermann wrote:

However: if we implement this, i'd consider this as a workaround as
mails that should not be distributed, should not be sent out in the
first place.


That works for me; there's a missing feature in the BTS currently to
turn off e-mails to maintainers, so when that is in place, this
workaround can be removed.


So I need some examples.


Are links to the lists.d.o enough? Or should I send you messages (with 
full headers)? (I'll start with the former)


https://lists.debian.org/debian-release/2023/11/msg0.html
https://lists.debian.org/debian-release/2023/11/msg7.html
https://lists.debian.org/debian-release/2023/11/msg00020.html
https://lists.debian.org/debian-release/2023/11/msg00029.html

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))

[Paul Gevers]

Hi

On 18-12-2023 10:07, Andreas Tille wrote:

https://tracker.debian.org/pkg/r-bioc-megadepth


d/tests/control has

Architecture: !s390x

Why is it considered failing on s390x anyway?


The log has this at the end:
127s run-unit-testSKIP Test declares architecture as not 
supported: s390x
127s run-unit-testSKIP Test declares architecture as not 
supported: s390x

127s pkg-r-autopkgtestFAIL non-zero exit status 1

pkg-r-autopkgtest comes from autodep8. You didn't tell autodep8 that you 
wanted s390x to be excluded also from that test.



https://tracker.debian.org/pkg/r-bioc-scater


While this is an Architecture:all package it Depends from r-bioc-densvis
which exists only on amd64 and arm64 due to the Build-Depends:
r-bioc-basiklisk.  Thus tests on other architectures are failing since
r-bioc-densvis is not installable.  What solution do you suggest in this
case?


Well, mark the test as amd64 and arm64 only? Were this due to Depends 
(and thus the package not installable) the test would *automatically* 
not be scheduled if I'm correct, but it works differently for test 
dependencies.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058889: src:openjdk-22: fails to migrate to testing for too long: FTBFS on armhf

[Paul Gevers]

Source: openjdk-22
Version: 22~22ea-1
Severity: serious
Control: close -1 22~25ea-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:openjdk-22 has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build on armhf.


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=openjdk-22



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058866: cacti: Cacti package does not include spine.conf.sample

[Paul Gevers]

Control: tags -1 - moreinfo
Control: tags -1 confirmed

On 17-12-2023 10:00, Paul Gevers wrote:

On 17-12-2023 09:15, Piotr Górski wrote:
Cacti package does not include file spine.conf.sample needed during 
installation of cacti-spine:


I confirmed it doesn't contain the file, see 
https://packages.debian.org/bookworm/amd64/cacti-spine/filelist



# apt install cacti-spine
Czytanie list pakietów... Gotowe
Budowanie drzewa zależności... Gotowe
Odczyt informacji o stanie... Gotowe
Następujące pakiety zostały zainstalowane automatycznie i nie są już 
więcej wymagane:

   libgnutls-dane0 libunbound8
Aby je usunąć należy użyć "apt autoremove".
Zostaną zainstalowane następujące NOWE pakiety:
   cacti-spine
0 aktualizowanych, 1 nowo instalowanych, 0 usuwanych i 0 
nieaktualizowanych.

Konieczne pobranie 0 B/71,6 kB archiwów.
Po tej operacji zostanie dodatkowo użyte 199 kB miejsca na dysku.
Wybieranie wcześniej niewybranego pakietu cacti-spine.
(Odczytywanie bazy danych ... 166740 plików i katalogów obecnie 
zainstalowanych.)
Przygotowywanie do rozpakowania pakietu 
.../cacti-spine_1.2.24-1_amd64.deb ...

Rozpakowywanie pakietu cacti-spine (1.2.24-1) ...
Konfigurowanie pakietu cacti-spine (1.2.24-1) ...
Error: The new file /usr/share/cacti/conf_templates/spine.conf.sample 
does not exist!

dpkg: błąd przetwarzania pakietu cacti-spine (--configure):
  podproces zainstalowany pakiet cacti-spine skrypt post-installation 
zwrócił kod błędu 1

Przetwarzanie wyzwalaczy pakietu man-db (2.11.2-2)...
Wystąpiły błędy podczas przetwarzania:
  cacti-spine
E: Sub-process /usr/bin/dpkg returned an error code (1)


Interestingly our testing infrastructure doesn't show the problem: 
https://piuparts.debian.org/bookworm/pass/cacti-spine_1.2.24-1.log


Do you know of any particularities of your system that may be relevant 
here?


OK, that was easier to find that I expected. postinst uses this file 
(removed in 2013) when there is no /etc/dbconfig-common/cacti.conf file. 
I guess that condition is very rare as nobody has reported the issue in 
10 years. Do you happen to know *why* you don't have that file, to 
understand the use case I need to support?


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature