[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bitseq - Clarification on autopkgtest setup for 32-bit.



Hi team,

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?

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. I think it may be a compatibility issue with my setup.

After pushing the changes to Salsa, I noticed the build pipeline failed. 
 please review and suggest what might be wrong?


Thanks,
Harish



On Wednesday, 18 June, 2025 at 01:53:53 am IST, Étienne Mollier <emollier@debian.org> wrote:


Hi Harish,

Étienne Mollier, on 2025-06-12:
> harish chavre, on 2025-06-12:
> > Should I go ahead and try this approach that Nilesh
> > suggested? I can generate the files on amd64, add them to
> > debian/tests/data, and include a short note in
> > debian/tests/README.Debian to explain how the data was
> > created. 
>
> Please feel free to go ahead.  I agree that it could be a fine
> way out to resolve the problem of producing the test data
> (modulo the use of a component tarball instead of using d/t/data
> if the dataset is large, but let's focus first on making sure
> that the problem is limited to bowtie first).  Thanks Nilesh for
> the idea!  :)
>
> Note that we still don't know for sure whether bitseq does
> operate properly on 32-bit platforms, so before upload, it will
> be necessary to run the autopkgtest on all affected cpu
> architectures: i386, but also armel and armhf.  If you don't
> have an Arm machine at hand, then you can use the Arm emulator
> shipped in the package qemu-system-arm.  Tip: if you also
> install the package qemu-user-static, then your system gains the
> ability to run Arm binaries without the hassle of setting up a
> full fledged virtual machine; you would just have to pass option
> --arch armel or armhf to mmdebstrap, sbuild and autopkgtest
> commands, and they will happily change root into a Debian Arm
> file system tree.  This is not a silver bullet though, because
> sometimes the emulation layer may run into problems that won't
> occur on real hardware, and sometimes it's the other way around,
> but it's rare, and hopefully won't occur with bitseq.

I hope you're doing okay.  Have you managed to get somewhere
with this variant of the test?  I'm still pondering whether to
request a removal of bitseq on 32-bit platforms, and knowing
whether bitseq has a chance to work there or not would give
additional marbles for the removal request.

> Please don't hesitate to follow up if you manage to get
> somewhere or run into problems.  If bitseq fails to run as
> expected on 32-bit platforms, it may be simply that it has never
> been supported and thus a removal from 32-bit architectures
> would, again, become justified.

I insist, if you hit difficultie or if you're stuck, please
don't hesitate to reach out.  Stalling on the same issue for
days is not sane for one's mind, and it's okay if things don't
go as expected; this is usually in these situations we learn the
most things.

Have a nice day,  :)
--
  .''`.  Étienne Mollier <emollier@debian.org>
: :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
`. `'  sent from /dev/pts/3, please excuse my verbosity
  `-

Reply to: