is going away

For those of you, still using my binary packages. It’s just a waste of disk space for me (6.8G to be exact), so I decided to remove them. I’m gonna give people one week to grab yourself a copy. I’m gonna keep the bashrc and all the other stuff I wrote back when I was still interested in binary packages, but the binary packages are gonna vanish!

Again, grab yourself a copy if you need them, at some point next week (probably on Friday), I’m simply gonna rm -rf them.

Advanced bashrc (‘Turning a simple chroot into a binpkg repository’ continued)

As I pointed out back in October, it’s rather easy to create a setup which syncs a built binary package to a remote node (which is serving them to the world – via http,rsync,ftp – pick your poison).

Now, ever since we had slight space problems on miranda (cough my binpkgs cough), I wanted to look into methods on how to get rid of storing them on the buildnode and the webnode. I think now (hehe, it’s only 7pm), I finally managed to get a “proper” bashrc which does a lot of that foo. Take a look at this:

As you can see, it does a lot of things, which are all connected with binary package repositories (including cleaning up old packages no longer in the tree – trying not to waste too much space). Sadly, I currently have to use a custom patched qpkg version, as the one implementing the –eclean features isn’t in the tree yet. When I talked to Ned the other day, he complained about it being slow (well, yeah — it has to go through the whole tree) which I don’t really see when you look at what it’s doing.

Also, I had a weird phenomenon today happening: the buildnode built a binary package, sent it to the webnode, which ran qpkg --eclean' afterwards. But after that the binary package was gone. "Why" you ask now ? Well, apparently the webnode isn't synced the same time the buildnode syncs (the webnode is in Germany, the buildnode in the US). So I had to come up with a trick, in order to fool qpkg into not cleaning the freshly built binary packages. See the rssh’ in front of the qpkg call ? Guess what, that’s the lil’ dirty trick …

Anyway, the full bashrc is available. The next thing I’m gonna have to look at (which Markus already did), is building packages via buildbot.

Update: as you see, I updated the bashrc a bit. That’s because after writing this, I started a new (fresh) binpkg repository (empty), and out of the sudden the thing ain’t syncing correctly (as in no Packages file, no portage settings). Turns out, rsync doesn’t create directories which ain’t there. So another extra `ssh‘ execution to create the settings/ directory inside the repo.

Turning a simple chroot into a binpkg repository

OK, since Alex asked me last Sunday what exactly needs to be done to turn a simple chroot (or even a bloody box) into a binpkg producing environment, here’s a little howto …

First, lets start from a freshly unpacked stage3.

With that single change you’re basically nearly finished with setting up the whole thing, the remaining things are just

  1. Making sure the binary packages get to a web-enabled (either ftp or http) box, from where you’re going to fetch the binary packages to their target
  2. Make sure you use binary packages on the target systems by default

But first, we’re gonna need to emerge something within that freshly created build chroot.

Since we now emerged some things we do have quite a few binary packages, which we are going to need on the target systems in order to avoid individual compile time.

Now, we just need to figure out a way to get the packages to a remote repository. That’s where bashrc, rsync and ssh come into play.

Take a looksie at my bashrc (or at solar’s if you can find it), especially at syncpkg. That’s the actual function doing all the work for us. It’s basically guessing what profile you’re using atm (by reading the info’s on /etc/make.profile (x86, amd64)), and the uploading it to the remote location given by REPO_HOST, REPO_BASE and REPO_TYPE (either via environment or by /etc/make.conf).

Sure the emerge takes a bit longer (since emerge forks an rsync process via ssh that syncs the just merged binary to our remote repository), but that way you have a nice repository, from which you can install one or 1.000 boxes.