Hi Harish, harish chavre, on 2025-06-10: > I tried running the autopkgtest using --unshare to help > unblock the migration blocker(bitseq), and also gave local > i386 testing a shot. But in both cases, the command > (autopkgtest bitseq_0.7.5+dfsg-7_amd64.changes --unshare > --arch i386 --release unstable) either hangs or runs into > dependency issues. It feels like the environment isn't getting > isolated properly. I also tried setting the architecture > locally, but didn’t have any luck there either. > > please advise on how I should move forward with getting > autopkgtest to run for 32-bit platforms? Thanks for the status, strictly speaking, an invocation like the one you write results in unrecognized arguments errors; at least that's what I have on my end, by running the autopkgtest version shipped in Debian unstable: $ autopkgtest bitseq_0.7.5+dfsg-7_amd64.changes --unshare --arch i386 --release unstable usage: autopkgtest [options] [testbinary ...] testsrc -- virt-server [options] autopkgtest: error: unrecognized arguments: --unshare --arch i386 --release unstable But given the symptoms you describe, I can reasonably assume there was simply a typo in the argument passed in your email, and you probably meant to write: $ autopkgtest bitseq_0.7.5+dfsg-7_amd64.changes -- unshare --arch i386 --release unstable ^ I note the command is run against an amd64 changes file, but this is not too concerning, as autopkgtest will try to rebuild bitseq for i386 if the i386 binary package is missing. Once the i386 package is ready for the actual autopkgtest however, you should indeed run into the following dependency issue, which is a failure to deploy bowtie on i386, because the package does not exist for i386. Here is what I see with the unmodified bitseq version 0.7.5+dfsg-7 for i386: $ autopkgtest bitseq_0.7.5+dfsg-7_i386.changes -- unshare --arch i386 --release unstable […] The following packages have unmet dependencies: satisfy:command-line : Depends: bowtie but it is not installable E: Unable to correct problems, you have held broken packages. run-unit-test FAIL badpkg […] The error is expected as long as the architecture is not skipped from debian/tests/control. This is also the error that causes bitseq to fail to migrate to trixie. Once the skip is implemented, you should see autopkgtest skip on i386, while amd64 runs should still pass: $ autopkgtest bitseq_0.7.5+dfsg-8_i386.changes -- unshare --arch i386 --release unstable […] autopkgtest [22:23:57]: build not needed run-unit-test SKIP Test declares architecture as not supported: i386 […] Such output is the expected result from the maneuver. If we're lucky, this may be sufficient to allow bitseq to migrate. However, if the migration tool still expects to obtain some sort of result on 32-bit platforms anyway, it may become necessary to carry extra steps to remove bitseq support from 32-bit Debian platforms completely. This may be justified anyway, since your autopkgtest reveals bitseq may be hardly usable if bowtie is missing from the processing workflow. For the change to the debian/tests/control as such, I propose the following patch: --- a/debian/tests/control +++ b/debian/tests/control @@ -1,3 +1,6 @@ Tests: run-unit-test Depends: @, bowtie, bitseq Restrictions: allow-stderr +Architecture: !i386 !armel !armhf +# bowtie, necessary to generate test data, is not available on 32-bit +# platforms, hence limiting architectures at autopkgtest time. This will instruct autopkgtest to not run on the current 32-bit release architectures. Are you able to reproduce the skip after applying similar change on your side? Note I made quite some guesswork to make sense of the stage you were at. Please don't hesitate to be more specific in case you ran into different issues. Slightly off topic, if you're not using it yet, the following sbuild invocation should allow you to prepare the i386 binary package builds prior to running autopkgtest, if you want to keep the two stages separate: $ sbuild --arch i386 --dist unstable You may populate the sbuild cache by hand to substancially speed up build steps involving unshare: $ mmdebstrap --variant=buildd --arch="$arch" --skip=output/mknod unstable ~/.cache/sbuild/unstable-i386.tar.xz For even more performance bumps, I also have a relay running locally to cache Debian packages downloaded from my nearest mirror. If you're interested, you can look at apt-cacher-ng. In hope this helps, -- .''`. Étienne Mollier <emollier@debian.org> : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-
Attachment:
signature.asc
Description: PGP signature