Web lists-archives.com

Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages [and 2 more messages]

Hi Ian,

On Thu, Mar 29, 2018 at 03:37:10PM +0100, Ian Jackson wrote:
> > Why mailing the release team asking for a one-shot 'force' hint would be
> > bad?
> Well, I applaud Andreas's intention to try to solve the problem in a
> general way without additional human intervention, if possible.

... which is what we normally do if something is more frequent than once
per year / month / week (depending on your personal threshold ;-) )

> Andreas, is the root cause of the difficulty here that some of this
> scientific software is no longer buildable on i386 ?

Basically never ever build on any 32 bit architecture.

> I agree that it
> would be nice if there were a way to flag this.
> I had a quick look at one of the dependencies listed in the excuses
> and followed some links
>   https://tracker.debian.org/pkg/python-pysam
>   https://buildd.debian.org/status/package.php?p=python-pysam
>   https://tracker.debian.org/pkg/bcftools
>   https://buildd.debian.org/status/package.php?p=bcftools
>   https://buildd.debian.org/status/fetch.php?pkg=bcftools&arch=i386&ver=1.7-2&stamp=1519144568&raw=0
> and I see that on i386 bcftools fails some of its tests.
> Is this known ?  Intentional ?  Should bcftools be marked as not
> buildable on i386 ?

Bcftools should be buildable on i386 *in* *principle* but as you noticed
it fails and it is known (bug #819617, #870060) and discussed with
upstream[1].  Unfortunately upstream support for non-amd64 architectures
is weak and one resolution for the said bugs is to exclude i386 (and
other 32 bit architectures).  However, we did not gave up hope, thought.
> Would restricting bcftools's arch list fix this problem for testing
> migration ?  I guess maybe not.

No.  Bwa and bowtie2 were explicitly designed for amd64 (not even 64 bit
in general since it contains assembly code).  These packages are

   Architecture: amd64 kfreebsd-amd64

So getting bcftools tests fixed would be nice but has no influence on
paleomix testing migration.
> Andreas Tille writes ("Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages"):
> > Please do not consider my mail as complain.  I was just wondering why I
> > should trigger manual interaction if there might be a potential
> > automatic solution.  If the consensus would be:  Just send an e-mail
> > to debian-release@xxxxxxxxxxxxxxxx I'll simply do so.
> I guess the release team would prefer a bug filed by reportbug, rather
> than a simple mail to their list.  ICBW.

When we are now talking about this:  The excuses page could mention the
prefered way of action.  I checked the link to the britney docs[2] bit I
did not found any clue.  As I said I went that road about two years ago
with metaphlan2 but I simply tend to forget things I'm doing only once a
year - thus my mail.  If an automatic procedure seems to make more
effort than manual processing or might change a running system to deeply
its perfectly fine for me.  Some kind hint what to do would probably
avoid this kind of questions here.

Kind regards


[1] https://github.com/samtools/bcftools/issues/389
[2] https://release.debian.org/doc/britney/short-intro-to-migrations.html#migration-items