[Debian-med-packaging] Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)

[Sascha Steinbiss]

Hi Andreas,

> after routine-update dh_missing failed due to compat level 13 which 
> defaults to fail if some files are not installed.

Yep, encountered that in other places as well when updating a few (old!)
things.

> This made me aware that upstream in principle installs a test suite 
> we could use for an autopkgtest.  I also realised that you once
> added debian/ltrsift-examples.examples - so you probably had such a
> package in mind.

Well, upstream is me ;) At least the original upstream, I don't think
anyone at my former organization has adopted it in the meantime and I do
not have the time to still care for it.
But... since LTRsift is a purely graphical tool, there is no automated
test suite I know of. The files in samqqple_data are basically just
quickstart examples for the accompanying paper to provide a realistic
data set to preprocess, manually load and do first clicky analysis steps
with, I think.

> Since I have no idea what reasons you had not to use this file I'll 
> leave the final decision to you.

Interesting to see that there is no ltrsift-examples package indeed. But
I must have had my reasons back then...

Anyway, to be honest I don't see much long-term future for LTRsift. I am
actually surprised to see it still in Debian and not dropped out of
testing as it depends on GTK2, which I assumed was gone from Debian
already [0, 1].

I'd be happy with introducing an examples package but I don't think
there is going to be a usable autopkgtest to gain, sorry.

> (Please note:  Somehow a copy of ltrsift_code ends up in the
> examples dir - I did not yet investigated why this is happening.
> Before I have no clear picture about your intentions I'll left this
> for later investigation.)

That is a result of lines 62-65 in the Makefile, which make sure that
there is a copy of the executable in that directory, for the paper
reviewer's convenience I think (same as why we have the the static build).
I think this can be safely patched out as the prepare_encseqs script in
the sample_data directory also tries to run ltrsift_encode from the
$PATH. ltrsift_encode, BTW, is just a script that prepares the input
data and is actually just a wrapper around another tool from
GenomeTools, which we wanted to have in here for convenience.

I have pushed some changes and can upload soon.

Cheers
Sascha

[0] Apparently not, but it's dead upstream: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947713
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967603

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20240404/7b69eb04/attachment.sig>