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-rele...@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
