<div dir="ltr">There is now an Arch User package available for OpenMusic: <a href="https://aur.archlinux.org/packages/openmusic/">https://aur.archlinux.org/packages/openmusic/</a><div><br></div><div>Cheers,</div><div>Daniel</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-06 2:13 GMT+02:00 Daniel Appelt <span dir="ltr"><<a href="mailto:daniel.appelt@gmail.com" target="_blank">daniel.appelt@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>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: <a href="https://bugs.archlinux.org/task/44474" target="_blank">https://bugs.archlinux.org/task/44474</a><div><br></div><div>For me, the bottom line is:</div><div><br></div><div>- 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.</div><div>- 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.</div></div><div>- Using TIFF images or relying on libtiff in this case is not preferable as the library's standard includes are architecture specific.</div><div><br></div><div>Cheers, Daniel</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-02-15 2:55 GMT+01:00 Simon Wise <span dir="ltr"><<a href="mailto:simonzwise@gmail.com" target="_blank">simonzwise@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 15/02/15 06:28, David Jones wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Feb 14, 2015 5:48 AM, Len Ovens<<a href="mailto:len@ovenwerks.net" target="_blank">len@ovenwerks.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Sat, 14 Feb 2015, <a href="mailto:anders.vinjar@bek.no" target="_blank">anders.vinjar@bek.no</a> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The real pain here is having to do 32-bit at all! If we only got lw to<br>
consider 64-bit a 'professional' feature, and not just a high-end<br>
'enterprise' feature... :-/<br>
</blockquote></blockquote>
<br>
Even my wife's years-discontinued little netbook is 64-bit.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With some distros talking about dropping support for 32bit kernels, 64bit<br>
is just where the world is going anymore. 32bit versions are just<br>
outdated.<br>
<br>
As someone who uses old computers for servers etc. I find this anoying...<br>
</blockquote>
<br>
I do wish kernel makers would also stop requiring PAE support. I have a couple of boxes that don't support PAE.<br>
<br>
Musix is 32-bit only.<br>
<br>
I expect Debian will be producing 32-bit kernels for a good long while yet. They just seem to change slower than others.<br>
</blockquote>
<br></span>
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.<br>
<br>
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 ...<br>
<br>
<a href="https://devuan.org/" target="_blank">https://devuan.org/</a><br>
<br>
... 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).<span><font color="#888888"><br>
<br>
Simon</font></span><div><div><br>
______________________________<u></u>_________________<br>
Linux-audio-user mailing list<br>
<a href="mailto:Linux-audio-user@lists.linuxaudio.org" target="_blank">Linux-audio-user@lists.<u></u>linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-user" target="_blank">http://lists.linuxaudio.org/<u></u>listinfo/linux-audio-user</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>