[buildd-tools-devel] [RfC] Honor chroot personality in setup service script

[Jan-Marek Glogowski]

Am 05.02.2015 um 18:31 schrieb Lennart Sorensen:
> On Thu, Feb 05, 2015 at 04:46:45PM +0100, Jan-Marek Glogowski wrote:
>> All the setup.d scripts run "outside" of the chroot without the schroots
>> personality set (for mounts, nss copy etc.). The personality is just set
>> before executing the final chroot command - be it /bin/bash or whatever
>> you specify.
>>
>> Calling "linux32 schroot" is not really a workaround. There is a reason
>> to specify the personality inside the config file, so people don't have
>> to remember it.
>>
>> Probably all setup schripts should run with the correct personality when
>> calling a command inside the chroot, so we should actually wrap the
>> system chroot command?
>>
>>> personality=linux32 in the schroot config should do that for you.
>>>
>>> Certainly that works for me, and nothing has ever thought it was on a
>>> 64bit system inside the chroot with that setting.
>>
>> This just works for the final command inside the chroot, not the setup
>> scripts.
> 
> So what does your setup script do that would break?  I would have hoped
> that running icecc would be the final command to be run in the chroot.
> 
> But interesting that there are cases where the setup even needs to know.
> 

Seems I'm not clear enought about what's happening :-)
I don't have any own setup script.

I have a build / development system (Debian Wheezy), which is running
icecc. It's 64bit. The build schroot is an Ubuntu Precise schroot, 32bit.

The config for the schroot contains the line "setup.services=iceccd", so
an iceccd instance is started per schroot session. The schroots iceccd
runs without remote connect, so just distributes jobs.

So the user hacks on LibreOffice in the schroot and compiles using all
free icecc resources on several machines.

But without the patch / personality-helper, the schroot sessions iceccd
is started in the host system context, so it thinks, it's running on a
64bit system and generates 64bit object files, which obviuosly fails to
link, when the build system expects 32bit object files.

Hope this is more understandable with the context.

Jan-Marek