Hello, sorry to bother you once again 
I would like to use propellor in order to prepare a bunch of schroot for sbuild. This way all my machines could be used to prepare packages.
so I tryed to created a Debootstrap property in order to generate the initial image
& Chroot.debootstrapped (System (Debian (Stable "jessie")) "i386") Debootstrap.BuilddD "/var/lib/sbuild/jessie-i386.tar.gz"
But this does not work.
So I would like to know what should be done in order to instanciante a sbuild schroot and also how to customize it in order to add the apt proxy informations.
ok, so I created this property but it does not work
it fails with this error message
What I understand it that onChange expect a Property instead of a Chroot. So what is the right way to tell propellor look at this chrootdir directory and create a tarball if its containt changed.
So you have a Chroot and want a Property of some kind. If you look in the Chroot module, see this:
Which is just what you're looking for.
Thanks for the information,
Now I use the provision part but I am facing a problem when I try to create the chroot using withTmpDir I do not understand exactly how it must work
here the signature of my two methods
And here the property which does the work (it works thanks to your comment, I will have other questions about this part later
When I tried this I got this error
I need to extract the property from the monad, but I do not know how ?
In fact the real error meassage is this one.
You really have to follow the types here.
withTmpDirpasses a tmp dir to a monadic action. A RevertableProperty is not a monadic action (although it does contain one), so your code doesn't type check.What you can do is use
ensurePropertyto run a property from within the Propellor action of an enclosing property. The type of that isensureProperty :: Property NoInfo -> Propellor Result, so it can't be used on a RevertableProperty like yoursbuild'. If you can get afoo :: System -> FilePath -> Property NoInfo, you can use it withensurePropertylike this:But .. To get from a RevertableProperty to a Property NoInfo is a fraught conversion.
toPropcan get to a Property HasInfo. You'd have to useignoreInfoto get from there to a Property NoInfo, and a lot of care should be taken when usingignoreInfo.It might be ok to ignoreInfo in this case; the agument would go that this is a chroot being used to create a sbuild image, so any Info belonging to properties of the chroot doesn't affect the host that it's built on, and so it doesn't need to propagate out. But, consider that this would break any properties inside the chroot that use privdata, since privdata works via info.
I'd probably take an alternate tack here. Make
sbuilduse a chroot directory in a fixed location, instead of a temp directory. It could base the chroot location on the filename of the tarball it's creating(++ ".chroot"), for example.That approach also has the benefit of letting you alter properties of the chroot and propellor will modify the existing chroot to meet those properties, which is faster than building a new chroot every time.
(Then you can use
onChangeto update the schroot tarball anytime the chroot changes.)Just for information, here my solution. It is not perfect but it works
thanks a lot for your help
Factoring out a generic Propellor.Property.Sbuild would make this more perfect...
This could the plan, but I am not very confident that my code is generic enought.
In this case I do not like the way I give the chroot to the sbuild method. In fact I do not find the interface of this command generic enought.
There is assumtions in the code: - the initial configuration of sbuild was done - the chrootdir is hardcoded into /var/lib/sbuild and I do not know if this is the right way to do things.
If you would have some advices about interface, because it seems to me thaht you are great for this
Another problem is the schroot cofngiuration files.
sbuild-createchroot create a configuration /stc/schroot/chroot.d/jessie-i386-sbuild-xxxx where xxxx is random. In this code I remove all jessie-i386-sbuild-* files, but this seems plain wrong...
Seems like you could have a parameter giving the name of the schroot, and use that as the basis for both the location of the chroot, and the schroot config file.