On Fri, Jan 17, 2020 at 2:05 AM Johannes Schauer <jo...@debian.org> wrote: > yes, probably a communication problem. I think you are talking about [1] from > August 11 last year? I replied the same day, telling you to please file a bug > with your patches to continue discussion there. But then there was no response > from you anymore and I don't find your bug in the BTS. Maybe my mail got lost > somehow or I fail finding the bug you filed?
It seems the reply must have gotten lost somehow - I don't see it anywhere. > I'm also very excited about having yet another chroot backend being integrated > into sbuild! Though my first comment would be the same as I gave those asking > for a docker backend in #867176: maybe try adding that backend to autopkgtest > first. Then more people would profit from having that type of backend > available > and no additional changes would be needed in sbuild because sbuild can already > use autopkgtest backends for package building. OK, I'll try to get the patch submitted either tonight or tomorrow. (What I need to clean up is that it's interspersed with changes I made to have it run with a personal distribution build I've been tinkering with. On a quick review, I now notice it's also interspersed with changes to support using eatmydata only on the apt install commands and only if not in schroot-update mode, instead of having to put it into schroot config to apply to all commands - which seems reasonable to split out into a separate patch to submit. I also haven't yet updated documentation files.) One quick question: I don't see any mention of $options->{'DISABLE_NETWORK'} in lib/Sbuild/ChrootAutopkgtest.pm, whereas my new lib/Sbuild/ChrootNspawn.pm does support it. If I'm not missing something, then I wonder what it would take to add DISABLE_NETWORK support to the autopkgtest sbuild engine. -- Daniel Schepler