Re: ruby2.2 fuckup (was Re: Log for attempted build of libselinux_2.4-3 on m68k (dist=unstable))
> On Nov 24, 2015, at 11:55 PM, Eero Tamminen <oak@helsinkinet.fi> wrote:
>> Not really possible to keep the Aranyms. They take up space in my
>> office which I and especially my boss want to get rid of. The qemu-m68k
>> stuff can be easily set up on our VMWare cluster.
>
> Why Aranym emulator takes office space and cannot be run in VMs?
> Or did you mean real HW?
Aranym is a bit more complicated than just using qemu-user-static plus sbuild.
For Aranym, I first need to run a X server to set up the system. You cannot configure Aranym headless.
Secondly, you need a manual, more complicated network configuration as compared to qemu which requires nothing in this regard. Considering that my university has a special network configuration for the Linux hosts, everything that requires extra configuration is rather bad.
To run Aranym, I basically need a Debian machine which is manually installed and configured, while for qemu, I can just spin up four VMWare machines, make a fully automatic installation (FAI) over the network and set up and configure qemu plus sbuild.
This means much less adminstration work for me and makes my boss much happier because I spent less time on these things and since the buildds run "our Linux", they can be much easier maintained within the IT department.
Don't forget, I am not hosting this at home but at my university where I work. And I am already hosting way too many buildds. Thus, I should try to keep the maintenance overhead as low as possible and make sure that the machines adhere to the IT guidelines of my employer.
Given that I currently host nine m68k buildds, one sh4 buildd, one x32 buildd and one huge HP desktop which hosts four hppa buildds, I don't think I really need to defend myself here. This doesn't include the extra work I spend on sparc64 even. My university also donated two rather expensive SFF SAS drives for the sparc64 buildd I maintain in Hungary.
>>> I think the instruction emulation is at the same level as Aranym, but
>>> the qemu linux-user part has some issues with multi-threaded applications.
>>
>> Well, we'll see how it goes. Packages like gcc-5 and systemd build fine,
>> so I am not too scared. For pure building, qemu-m68k is a very good
>> alternative.
>
> Btw. Nokia's "Debian based" Maemo distro used qemu for running
> any necessary native code during cross-builds. All code for
> it was cross-built (to ARM, before Debian supported given ARM
> versions), same was with Nokia's Harmattan/MeeGo that followed
> Maemo. It worked fine until Nokia stopped doing Linux based
> phones/tablets.
qemu-arm still works fine and Google uses it for its Android emulator, don't they?
> Besides threading (and unimplemented syscalls + bugs), one more
> issue was /proc/ files. I guess e.g. /proc/PID/auxv HW capability
> leakage from host is nowadays plugged in user-space Qemu and
> provides suitable values for m68k?
>
> Threading part can mean that you get random problems, e.g. with
> threaded test-suites (gstreamer?), that are run as part of build
> process. While the other issues are fixable in user-space Qemu,
> AFAIK the threading issue really isn't. :-/
I haven't really run into any bigger issues yet. Some packages got stuck during build, but that's all really.
If you want to have things improved, you're very welcome to help.
Adrian
Reply to: