Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages [and 2 more messages]
- Date: Thu, 29 Mar 2018 17:58:19 +0200
- From: Andreas Tille <andreas@xxxxxxxx>
- Subject: Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages [and 2 more messages]
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
> 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. 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 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.