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@lists.debian.org 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
Andreas.
[1] https://github.com/samtools/bcftools/issues/389
[2] https://release.debian.org/doc/britney/short-intro-to-migrations.html#migration-items
--
http://fam-tille.de
Reply to: