* Jurij Smakov ([EMAIL PROTECTED]) [060713 04:39]:
> On Wed, 12 Jul 2006, Goswin von Brederlow wrote:
>
> >How about creating a sparc64 package (probably part of dpkg's internal
> >type-handling support) and depending on that?
> >
> >That would at least make the package uninstallable on sparc32.
>
Jurij Smakov <[EMAIL PROTECTED]> writes:
> On Wed, 12 Jul 2006, Goswin von Brederlow wrote:
>
>> How about creating a sparc64 package (probably part of dpkg's internal
>> type-handling support) and depending on that?
>>
>> That would at least make the package uninstallable on sparc32.
>
> Is there
On Wed, 12 Jul 2006, Goswin von Brederlow wrote:
How about creating a sparc64 package (probably part of dpkg's internal
type-handling support) and depending on that?
That would at least make the package uninstallable on sparc32.
Is there some mechanism to enforce it? I don't see anything whic
Jurij Smakov <[EMAIL PROTECTED]> writes:
> Hi,
>
> Recently I've been investigating the xine-lib build failure on
> sparc. It turned out that failure occured due to libavcodec, shipped
> as a part of xine-lib, using the sparc64-specific assembler
> instructions in some routines (without providing
Jurij Smakov wrote:
> Recently I've been investigating the xine-lib build failure on sparc. It
> turned out that failure occured due to libavcodec, shipped as a part of
> xine-lib, using the sparc64-specific assembler instructions in
> some routines (without providing any generic arch-independen
Hi,
Recently I've been investigating the xine-lib build failure on sparc. It
turned out that failure occured due to libavcodec, shipped as a part of
xine-lib, using the sparc64-specific assembler instructions in
some routines (without providing any generic arch-independent replacement
for the
6 matches
Mail list logo
