6 Apr
2015
6 Apr
'15
2:13 a.m.
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(a)gmail.com>om>:
On 15/02/15 06:28, David Jones wrote:
On Feb 14, 2015 5:48 AM, Len Ovens<len(a)ovenwerks.net> wrote:
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
On Sat, 14 Feb 2015, anders.vinjar(a)bek.no wrote:
The real pain here is having to do 32-bit at all! If we only got lw to
Even my wife's years-discontinued little netbook is 64-bit.
With some distros talking about dropping support for 32bit kernels, 64bit
consider 64-bit a 'professional' feature,
and not just a high-end
'enterprise' feature... :-/
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.