Your package htslib fails to build on Debian for mips/mipsel architectures.
I have already reported a bug on Debian bug tracking system at:
with proposed patches attached.
Build logs for mips and mipsel are available at
Current version of htslib on Debian is 0.2.0~rc3-1.
I am currently adapting the patch to fit the latest htslib version.
I will send you a pull request as soon as I'm done.
Incidentally, are you doing NGS analysis on a mips/mipsel platform? While we endeavour to use portable code and to the extent practical build on all e.g. Debian platforms, we need to focus our efforts where they will bear fruit for those using the software.
Sadly it seems that just about everybody doing high-performance NGS genomics is doing it on x86-64. The htslib maintainers don't particularly have access to any big-endian or unaligned-access-is-bad machines for testing, and we don't know of anyone using htslib on such machines in earnest. So it's not particularly easy to see why focussing on this would be a priority...
At http://imgtec.com/ we would like to support htslib on mips/mipsel. For some time there has been available powerful MIPS machines like the Cavium Octeon III with up to 48 cores per chip. With these patches we're trying to position Debian MIPS architectures as additional platforms for scientific computing.
As mentioned, we would in principle like htslib and associated tools to work on platforms such as mips/mipsel. However it's not very practical when we can't build and test them on such platforms.
Perhaps Imagination Technologies could be in a position to support htslib on mips/mipsel by providing htslib maintainers with SSH access to a MIPS host for occasional build and test purposes?
Fix endianness problems outwith CRAM code
In swap_data(), for 'B' we must copy the count into n when it is in
host format. In test/sam.c, the same count is in host format while we
are checking it. Hat tip @azlicic, cf #99; partial fix for #98.
annotate -x INFO drop all header lines. Fixes #98
Hi, these failures affect armhf, powerpc and s390x builds too. W.r.t. build and testing, all debian developers have access to such machines and can run occasional builds for you. If you want access yourself you can request access to debian porter boxes, after agreeing to the Debian Machine Usage Policy (?! can't remember exact name) and somebody sponsoring (a DD recommending you) your access. Can we please resolve this? At the moment there is a chain of dependencies that fails to build due to this. blasr in debian stopped using bundled libs, and thus now depends on pbseqlib and htslib to be available on more arches. Specifically armhf and big-endian systems (powerpc, s390x). What's outstanding to resolve with this merge proposal?
There are some forks that should work on big-endian platforms in:
but I'm afraid they're now well out of date. Unfortunately more pressing
things got in the way so it's been ignored for a while and would now need
a bit of rework to get it merged.
How much demand is there for this? As it's not something we need
ourselves it gets a low priority at the moment.
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.