Hi Team , I have verified the package bitseq in an i386 environment and its working correctly , for testing i used $autopkgtest ../bitseq_0.7.5+dfsg2-1.dsc -- unshare --arch i386 --release unstable and all tests passed successfully. before running autopkgtest i also perform clean build using $ sbuild -A -d unstable ../bitseq_0.7.5+dfsg2-1.dscthe build completed without any issue . Based on this Results, bitseq appears to be in good shape and ready for upload to the archive. Regarding bowtie dependency :bowtie is not used during testing , i have documented debian-test -data details inside the README.Debian . please review and let me know if any further clarification is needed . Regards, Harish On Thursday, 19 June 2025 at 02:57:02 am IST, Étienne Mollier <[email protected]> wrote: Hi Harish,
Thanks for the status, I have focused on answering your questions for now, but have not gone through review yet, to give you some time to wrap up the changes you still wanted to bring, notably for the readme file about test data. I did push changes and tags to help you with the handling of the component tarball, so you may want to refresh your copy of the bitseq code. Also, I have left a question to you about your autopkgtest command execution being stuck, let's see the steps how to resolve that. harish chavre, on 2025-06-18: > I have updated the autopkgtest for bitseq to use pregenerated > data to avoid running Bowtie during the test. , placed outside > the debian directory. However, I haven't added the > d/t/README.debian file yet , please guide me on how best to > write it? Since the dataset is not dynamically constructed by bowtie anymore, but is precomputed and shipped via the component tarball debian-tests-data, the point of the free form text file debian/tests/README.debian would be to describe: 1. why precomputing the dataset was needed (because it requires running bowtie, which is not available on 32-bit platforms); 2. how the dataset can be reconstructed (using bowtie on a 64-bit platform independently, invoking the command that used to be present in the first version of the autopkgtest). It does not need to be litterature, something clear and concise, to the point, will suffice. Something along those lines might give you some inspiration: Debian Tests Data ================= bitseq normally parses the output of bowtie, which is usually invoked prior to bitseq, but bowtie is not available on 32-bit architectures. The component tarball debian-tests-data will thus ship the output of bowtie commands. Test data can be reconstructed with: bowtie-build -f Ref.fasta index bowtie -q -v 3 --all -m 100 --sam index Reads.fastq -S out.sam > I also tried running > autopkgtest bitseq_0.7.5+dfsg-7_amd64.changes --unshare --arch i386 --release > unstable > to test on another architecture after doing all the setup > mentioned in previous mails, , but the command gets stuck > after a few lines. Per chance could you also copy and paste the few lines before which autopkgtest got stuck? They might give us clues what went wrong exactly. I have already attempted to cover this question in my first answer of June 11th, but it is quite likely I missed the point if my initial information did not help. > After pushing the changes to Salsa, I noticed the build > pipeline failed. please review and suggest what might be > wrong? > [] https://salsa.debian.org/med-team/bitseq/-/commits/master Salsa logs for the build job shows notably the following errors: dpkg-source -b . dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building bitseq using existing ./bitseq_0.7.5+dfsg.orig.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: error: cannot represent change to debian-tests-data/index.1.ebwt: binary file contents changed dpkg-source: error: add debian-tests-data/index.1.ebwt in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: error: cannot represent change to debian-tests-data/index.2.ebwt: binary file contents changed dpkg-source: error: add debian-tests-data/index.2.ebwt in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: error: cannot represent change to debian-tests-data/index.3.ebwt: binary file contents changed dpkg-source: error: add debian-tests-data/index.3.ebwt in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: error: cannot represent change to debian-tests-data/index.4.ebwt: binary file contents changed dpkg-source: error: add debian-tests-data/index.4.ebwt in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: error: cannot represent change to debian-tests-data/index.rev.1.ebwt: binary file contents changed dpkg-source: error: add debian-tests-data/index.rev.1.ebwt in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: error: cannot represent change to debian-tests-data/index.rev.2.ebwt: binary file contents changed dpkg-source: error: add debian-tests-data/index.rev.2.ebwt in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: error: unrepresentable changes to source dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 1 I believe they are the root cause of the pipeline failure for all three jobs at the build step. I happen to have also run into this issue when trying to build your changes on my end too, when driving the package construction with `gbp buildpackage`. What happens is: changes brought to the component tarball are upstream changes, because they are not part of the debian/ directory. It is thus necessary to bump the upstream version to match the changes brought to the component version. Otherwise, as you can see above and in Salsa logs, the step consisting in the construction of the source package from the git tree will complain about the files that are not part of the regular upstream version 0.7.5+dsfg. Honestly, introduction of foreign datasets upstream via components tarball is hard to get right, because it goes off tracks a lot compared to typical packaging tasks. Here are the steps that I ran to recover: 1. I first edited the debian/gbp.conf with: [DEFAULT] pristine-tar=True component=['debian-tests-data'] Actually, I even identified in the git log that you issued d/gbp.conf file in 8927d2e08026aa0a055cf9b81bc4e7648bb47a76, but 5b46266bfcba234e735f51877127e099a0cc9da6 looks to have erased it, perhaps due to being in "upstream" branch instead of the default master; 2. I tagged the tip of "upstream" branch "upstream/0.7.5+dfsg2" so that the tooling around gbp is capable of selecting the dedicated version including the components tarball: git tag upstream/0.7.5+dfsg2 upstream 3. I then initialised the d/changelog file in order to align it to the 0.7.5+dfsg2 upstream by giving it the packaging version 0.7.5+dfsg2-1, `gbp dch` is still useful to wrap up a skeleton of changelog entry, but it is necessary to ensure that the version number does reflect the new upstream repack version, in addition to the usual making sure that changelog entries autogenerated make sense and are useful; 4. I rebuilt the original and component tarball out of the gbp upstream branch using: gbp export-orig --no-pristine-tar 5. At this point, I took an extra step to examine the newly issued bitseq_0.7.5+dfsg2.orig.tar.xz and compared it to the pristine bitseq_0.7.5+dfsg.orig.tar.xz in order to ensure there were no components tarball changes leaking into the original tarball by accident; 6. I reinjected the changes brought to the components tarball into the pristine-tar branch with: gbp pristine-tar commit ../bitseq_0.7.5+dfsg2.orig.tar.xz --component debian-tests-data Changes are pushed to Salsa, so you won't have to go through those steps yourself, but you may want to take good note of them in case you run into another similar situation involving changes in component data. I let you proceed with writing the d/t/README.debian, also don't forget to gather troubleshooting elements for the autopkgtest command execution. Once the autopkgtest invocation on i386 is on track, it will be possible to verify whether bitseq seems capable of running on 32-bit systems; I've had a peek at how things are doing, but let you discover the results by yourself. ;) Have a nice day, :) -- .''`. Étienne Mollier <[email protected]> : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-
