Re: Dependencies across architectures
Hi Paul,
Paul Wise <pabs@debian.org> writes:
> On Sat, Jan 6, 2018 at 5:43 PM, Ole Streicher wrote:
>> "iraf" exists only on selected architectures due to some required
>> assembler code for each arch and problems with big endian.
> There could be a fallback in C for arches with no assembler yet
> and any non-baseline instructions should be detected at runtime.
Unfortunately, this is impossible: the assembler code creates a kind of
sigsetjmp() (with its own calling interface) for Fortran 77. This cannot
be simply remodelled in C. In principle, one could re-implement this
with the libunwind library (see [1]), but since glibc scrambles stack
information since some time, this does not work anymore.
If you have a portable solution, share it with me :-)
> Upstream should fix the code to deal with endianness correctly.
> Please file bugs upstream about these if you didn't already.
Upstream is difficult for this package: the package has no new upstream
version since five years and the communication is difficult. Usually,
this would count as "dead", but the package has quite some importance
for the astronomy community, and therefore I decided to create a
temporary fork, also for other downstreams (Fedora, Conda). The package
has ~750.000 LOC, so all I can do is to keep it working as it is. Big
endian was there at some point (10 years ago) on 32 bit, but they never
had a 64-big big endian release; so unless someone really puts some
efforts in, this will not happen (s390x).
>> From the description of "Multi-Arch: foreign" I would expect that this
>> allows the dependency resolved by using another architecture. However,
>> piuparts (and the migration excuses) claim a missing dependency on the
>> archs not supported by IRAF.
>
> piuparts.d.o only tests amd64 at this stage, could you quote the error
> piuparts gives for you on other arches? I'm guessing you didn't add
> the foreign architecture to the chroot that piuparts was using for
> testing.
It was (probably) my mistake, as I didn't run piuparts locally.
> I'm pretty sure the testing migration doesn't support
> cross-architecture dependencies, but the release team will hint things
> into testing where that is the only thing blocking migration.
If we take Multi-Arch serious, this shouldn't be the case, right?
>> My first thought was to limit the possible archs for python3-pyraf (by
>> explicitly setting the arch list and/or build-depending on iraf), but
>> this would not require the removal of the packages already build.
>
> Looks like you already tried this option, to get it to work you will
> have to ask the ftp-team to remove the obsolete binaries on the arches
> where pyraf no longer builds.
>
> https://qa.debian.org/excuses.php?package=pyraf
which is what I pargmatically did now (#886524). I was however not sure
what the optimal way is, since I also don't know which architectures are
co-runnable in practice. Theoretically, one could do anything with
qemu-userland, however.
Best regards
Ole
[1] https://github.com/olebole/zsvjmp/blob/master/zsvjmp-libunwind.c
Reply to: