Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:tcpreplay has been trying to migrate for
61 days [2]. Hence, I am filing this bug. Your package fails to build
from source on armhf where it built successfully in the past.

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 bookworm, 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/2020/02/msg00005.html
[2] https://qa.debian.org/excuses.php?package=tcpreplay

Paul, I am somewhat confused. I have not touched any old versions on
github, including 4.3.4. Is this something I should concern myself with?

Fred Klassen
Maintainer - Tcpreplay.

Fred Klassen wrote...

tcpreplay failed to build on armhf and I never managed to take a deeper
look:

https://buildd.debian.org/status/fetch.php?pkg=tcpreplay&arch=armhf&ver=4.4.0-1&stamp=1644098099&raw=0

(check for "Bus error")

Will check again tonight.

    Chri- "Debian maintainer, slacking" stoph

I see.

I had tested 4.4.1 on armhf as part of release testing. I can try 4.4.0 if you still have issues. But I suspect the VM does not have `eth0` to test on. I have that on my dev VM, in which case I have to configure this way

./configure --with-testnic=ens33

I have seen users use localhost (lo), but I have not tested it.

Dear Fred,

This bug has nothing to do with what happens outside of Debian, so this
bug is totally unrelated to github.

This bug is about the fact that in Debian the version in unstable is
newer than in testing for more than 60 days. The reason why the version
in unstable is not migrating is that the version in unstable failed to
build on armhf, while previous versions built on that architecture. That
needs somebody to figure out what the best solution is.

Paul

Paul Gevers wrote...

Indeed, there are two issues upstream that cause trouble on armhf (and
sparc64 ought to be the same story):

https://github.com/appneta/tcpreplay/issues/725
https://github.com/appneta/tcpreplay/issues/726

So I will wait a few more days in the hope Fred can take care of these.
In case there is no quick solution, I will temporarily drop armhf from
the list of architectures to build for, something that hopefully will be
for a short time only.

    Christoph