Hello, I am preparing a property in order to setup a debomatic machine but when I try to upload a package I get this error from debomatic
DEBUG: Command '['schroot', '-l']' returned non-zero exit status 1
Traceback (most recent call last):
File "/usr/share/debomatic/Debomatic/process.py", line 197, in _finish
raise e
File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/share/debomatic/Debomatic/build.py", line 525, in run
self._build()
File "/usr/share/debomatic/Debomatic/build.py", line 133, in _build
self._setup_chroot()
File "/usr/share/debomatic/Debomatic/build.py", line 395, in _setup_chroot
chroots = check_output(['schroot', '-l'], stderr=fd)
File "/usr/lib/python3.5/subprocess.py", line 316, in check_output
**kwargs).stdout
File "/usr/lib/python3.5/subprocess.py", line 398, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['schroot', '-l']' returned non-zero exit status 1
so tried on my own
:/etc/debomatic# schroot -l
E: /etc/schroot/chroot.d/stretch-amd64-sbuild-propellor: [stretch-amd64-sbuild]: Required key ‘directory’ is missing
to my opinion the schroot config file generated by Sbuild property does something wrong.
Cheers
this is strange because the stretch-amd64-sbuild file is wrong.
here the content
to compare with my previous jessie-amd64-sbuild
Hello, so I try to restart from scratch and ask for a stretch Sbuild
everything went fine until the update
On my network, I need a proxy so I setup the host with
If I understand correctly the Apt.proxy should propagate the Apt.proxy into the Sbuild but when I look inside the chroot, I can not find the
file which is on the host
And Indeed after a certain amount of time, the network gives a timeout
the good news is that now the schroot file contain the right informations
So to summarize, I think that the Apt.proxy propagation does not work.
This propagation should be optional because sometime we prepare images which are not meant to be used behind a proxy (where they were prepare)
thanks for your attention
Thank you for the detailed report.
I think the problem is the proxy propagation happens after the sbuild-createchroot command has run, but if the sbuild-createchroot command needs the proxy, it will fail in the way you describe.
After speaking to Joey at DebConf I think I can rework the sbuild module to bypass sbuild-createchroot and run debootstrap itself, without thereby polluting the chroot that is created. That should make it much easier to fix this bug, so I'll do that first.
Not sure why unpropelling blocks this. IIRC we discussed using a regular propellor chroot to set up the sbuild chroot. And I pointed out that when propellor runs inside a chroot, it does it without installing any dependencies into the chroot; everything propellor needs to run is bind mounted into /usr/local/propellor in the chroot.
So, the most an "unpropell" property would need to do in a chroot is to unmount below /usr/local/propellor and remove that directory, which should then be empty. This might be desirable to be sure that the sbuild environment is 100% clean, in the unlikely chance that something builds differently when /usr/local/propellor exists.
I'm almost done with my branch, and I now think that this bug applies to the
Chroot
andDebootstrap
modules. This is how the new sbuild module will work:As you can see, the propagation of the host's Apt proxy into the chroot is controlled by a property of the chroot, for maximum flexibility. For example, you could replace
Sbuild.useHostProxy
with a call toApt.proxy
.However, the properties of the sbuild chroot will not be applied until after the chroot is built. So, in order to resolve Fred's issue, it is the invocation of debootstrap by the
Chroot
/Debootstrap
modules that needs to be taught to use the host's Apt proxy, if one is set.(w.r.t. unpropelling: I'm not going to do any cleanup because /usr/local/propellor is not likely to interfere with the build. What matters is installed build-deps, and we've established there won't be any.)
I agree that it would make sense for propellor's debootstrap properties to use the host's apt proxy setting.
debootstrap does not have an option to use a proxy, but I think that setting
http_proxy
in the environment will probably make it work.