[Dev] Fauno's workflow

Nicolás Reynolds fauno at kiwwwi.com.ar
Sat Dec 1 12:22:52 GMT 2012


"Luke T. Shumaker" <lukeshu at sbcglobal.net> writes:

> At Fri, 30 Nov 2012 15:29:56 -0300,
> Nicolás Reynolds wrote:
>> "Luke T. Shumaker" <lukeshu at sbcglobal.net> writes:
>> > It copies the packages in ${chrootdir}/srcdest to your configured
>> > SRCDEST outside of the chroot; where normal `makepkg` would put them.
>> 
>> but srcdest is for downloading sources... why copying if you can have
>> them all in the same place anyway? :D
>
> Because the file ownership of the outside srcdest (you) and the inside
> srcdest ("nobody") are different.

changing ownership is cheaper than copying files i think and you don't
have to trap it to keep them in sync

>> > > it may also bind mount a subdir on home where you store abslibre and
>> > > libretools (i use the git version) and that's clean enough. it's never
>> > > been a problem though.
>> >
>> > Eh, I'm a fan of getting an up-to-date libretools on the repos.
>> 
>> it's not enough if i'm testing changes to libretools itself ;)
>
> Well then, that's what /repo is for, put the testing package there.

i'll have to get familiar with your changes first D:

>> > > >  * A chroot also protects you from a misbehaving build script messing
>> > > >    with your $HOME.
>> > > 
>> > > i usually check pkgbuilds from aur and trust the ones that come from
>> > > abslibre...
>> >
>> > Not just the PKGBUILDS, but the Makefiles, ant scripts, etc that are
>> > part of the source.
>> 
>> ok then refer to mount chroot's ~ to something that contains libretools
>> and abslibre (or just abslibre):
>> 
>> $ ls ~/packages/
>> abslibre/
>> packages/
>> sources/
>> 
>> $ mount --bind ~/packages $chrootdir/home/$USER/
>
> I'll consider this. Perhaps I'll make bind mounts configurable, so you
> can configure whatever mounts you want.

\o/

>> >> chcleanup is run automatically here, not optionally. -c is needed when
>> >> the chroot is considered dirty if not pristine so it may remove the
>> >> packages you already installed if this is the second run, and this isn't
>> >> the case: chroot is considered dirty when more than the needed packages
>> >> are installed.
>> >
>> > How is it done automatically?
>> 
>> it's always run by treepkg before makepkg, no flag involved, and it's a
>> tiny script that just knows what to remove instead of removing
>> everything just in case (rsync is slow and btrfs is overkill in
>> comparison to a *tiny* script that runs pacman -Rn
>> packages-not-in-base-or-pkgbuild).
>
> How the tools clean has changed.
>
>  librechroot -c cleans the chroot using chcleanup
>  librechroot -s syncs it to a pristine chroot with rsync/btrfs 
>
> I've also just (since I started writing the email) tought libremakepkg
> to also run chcleanup for every build, since it isn't overkill like
> the old package cleanup was.

that's what i meant :D

>> >> recreating here means "mounting and umounting, removing files, spawning
>> >> shells...", why has this to be done many times when i can do it once or
>> >> less? (yeeloongs aren't the quickest machines).
>> >
>> > I wish I hade a yeeloong to verify...
>> 
>> :c
>> 
>> but still, doing things many times unnecesarily doesn't sound kiss to
>> me, as in i didn't had to rewrite libremakepkg, i just stopped using it
>> ;)
>
> My goal with rewriting libremakepkg was to "wrap makepkg, adding hooks
> to do things for me that I'm doing manually now".

ok

>> > It's pretty minimal now.  The most complicated parts are:
>> >  * handling signals to umount and exit gracefully
>> 
>> that's the problem with making it mount everytime instead of using
>> fstab, you can end up with the same dir bind mounted many many times.
>
> I think I fixed that bug. Before it trapped the signals so that when
> there was an error, it went to the umount function. The first thing
> that function did was reset the traps to the exit function. This was
> bad because it meant that it might exit early and not umount
> everything.
>
> I think that modifying the outside fstab is too invasive into the
> user's system.

we could also check if it's already mounted, just in case

>> >  * the legacy code that only runs if systemd-nspawn isn't available
>> 
>> this should be deprecated imo
>
> I agree, but removing it would involve patching devtools even more
> than I already do.  I'm trying to keep it so that I can still pull
> changes from devtools.

ok... have you asked about the gplv2?

>> > And some of the "checks" can only be done with a chroot, such as
>> > turning networking off during the build and package stages.
>> 
>> this is true, but what we're discussing (except from the "running any
>> command instead of a predefined set" part) does still apply.
>
> I'm not sure what you mean. In order to toggle the networking you must
> exit and re-enter the chroot.
>

i mean the changes we're discussing aren't specific to the way the
chroot is handled and benefit both :O


feature request: is it possible to run dbus+avahi-daemon on the chroot,
or make it available from the host system? now that avahi is a
dependency of distcc i wanted to try +zeroconf (my build machines are
changing ips a lot lately...) but it couldn't connect to the host avahi.

pd: i just learned how to pull submodules!

-- 
http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121201/c0444595/attachment.sig>


More information about the Dev mailing list