I forgot: the arch specific package needs a Depends on the arch:all
package, which has the wrappers.
On 01/07/2018 05:39 PM, Wookey wrote:
> On 2018-01-07 19:23 +0800, Paul Wise wrote:
>> On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:
>>
>>> If we take Multi-Arch serious, this shouldn't be the case, right?
>>
>> I guess the release team might accept patches to britney for this but
>> I've
On 2018-01-07 19:23 +0800, Paul Wise wrote:
> On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:
>
> > If we take Multi-Arch serious, this shouldn't be the case, right?
>
> I guess the release team might accept patches to britney for this but
> I've also a vague memory that they prefer arches
On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:
> 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
Hi Paul,
Paul Wise 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
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
Hi,
I have an "arch: all" package "python3-pyraf" (source package: "pyraf"),
that has a dependency on the package "iraf", but no build dependency on
that.
"iraf" exists only on selected architectures due to some required
assembler code for each arch and problems with big endian. python3-pyraf is
7 matches
Mail list logo