[LAU] OM6.9 on Arch

[Daniel Appelt]

I am sorry to come back only now to this old thread. After my last comment,
I did some further investigations to get to the root of the problem on my
system. In the end, neither libtiff nor gdk-pixbuf2 can be blamed.
It seems to be a "packaging problem" specific to Arch's multilib setup. To
make a long story short, I have filed a bug report:
https://bugs.archlinux.org/task/44474

For me, the bottom line is:

- Arch multilib is not perfect. You might have to patch packages that are
working perfectly on i686 or x86_64 in native mode. A 32bit chroot could be
an alternative approach, but I have never tried it myself.
- Having a 32bit only app is not preferable as it might mean lots of extra
work to make it run in multilib mode on x86_64.
- Using TIFF images or relying on libtiff in this case is not preferable as
the library's standard includes are architecture specific.

Cheers, Daniel

2015-02-15 2:55 GMT+01:00 Simon Wise <simonzwise at gmail.com>:

> On 15/02/15 06:28, David Jones wrote:
>
>>
>> On Feb 14, 2015 5:48 AM, Len Ovens<len at ovenwerks.net>  wrote:
>>
>>>
>>> On Sat, 14 Feb 2015, anders.vinjar at bek.no wrote:
>>>
>>>  The real pain here is having to do 32-bit at all!  If we only got lw to
>>>> consider 64-bit a 'professional' feature, and not just a high-end
>>>> 'enterprise' feature... :-/
>>>>
>>>
>> Even my wife's years-discontinued little netbook is 64-bit.
>>
>>  With some distros talking about dropping support for 32bit kernels, 64bit
>>> is just where the world is going anymore. 32bit versions are just
>>> outdated.
>>>
>>> As someone who uses old computers for servers etc. I find this anoying...
>>>
>>
>> I do wish kernel makers would also stop requiring PAE support. I have a
>> couple of boxes that don't support PAE.
>>
>> Musix is 32-bit only.
>>
>> I expect Debian will be producing 32-bit kernels for a good long while
>> yet. They just seem to change slower than others.
>>
>
> or rather they have made a point of building for many platforms (at least
> until the recent move to systemd). With systemd they drop their freebsd
> branch, but also cut off some of the unofficial branches like hurd (systemd
> can only run on linux ... hence no hurd, no freebsd) and probably lose
> quite a few of the small embedded systems like raspbian that were based on
> debian but which becomes much less useful as a base for any small headless
> systems. It was a very heavily contested decision, fire and brimstone
> everywhere, but as it ended up a lot of older stuff will drop off over time
> since adding systemd support won't happen to less used packages.
>
> Maybe it was too much to cover everything and still provide a base for
> ready-to-use distributions, but there is a fork, said to be released when
> jessie is, and given the need for a system without the huge pile of
> dependencies on gnome and for some use cases it could well prove long lived
> ...
>
> https://devuan.org/
>
>  ... time will tell, but it would probably be a much better base for
> anything simple and custom without a desktop (and without the need to boot
> quickly as a short term cloud instance).
>
> Simon
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20150406/594e86ad/attachment.html>