Re: OM6.9 on Arch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>:
On 15/02/15 06:28, David Jones wrote:

On Feb 14, 2015 5:48 AM, Len Ovens<len@xxxxxxxxxxxxx>  wrote:

On Sat, 14 Feb 2015, anders.vinjar@xxxxxx 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@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux