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 <emollier@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/2, please excuse my verbosity
`-
Attachment:
signature.asc
Description: PGP signature