[arch-general] Question about automated builder

[Jelle van der Waa]

On Thu, 2011-01-27 at 12:34 -0700, Thomas S Hatch wrote:
> On Thu, Jan 27, 2011 at 12:28 PM, Thomas Dziedzic <gostrc at gmail.com> wrote:
> 
> > On Thu, Jan 27, 2011 at 1:12 PM, Thomas S Hatch <thatch45 at gmail.com>
> > wrote:
> > > On Thu, Jan 27, 2011 at 12:01 PM, C Anthony Risinger <anthony at extof.me
> > >wrote:
> > >
> > >> On Thu, Jan 27, 2011 at 12:37 PM, Thomas S Hatch <thatch45 at gmail.com>
> > >> wrote:
> > >> > On Thu, Jan 27, 2011 at 11:24 AM, Ray Rashif <schiv at archlinux.org>
> > >> wrote:
> > >> >
> > >> >> On 28 January 2011 01:36, Thomas S Hatch <thatch45 at gmail.com> wrote:
> > >> >> > I have been passively working on a similar project called quarters,
> > >> but I
> > >> >> > must admit that my motivation is somewhat low not knowing if the
> > >> project
> > >> >> is
> > >> >> > in demand. So here is my question, do we think that something like
> > >> this
> > >> >> > would be a benefit to Arch? Is this the type of project that should
> > >> merit
> > >> >> my
> > >> >> > attention?
> > >> >>
> > >> >> You have my personal full support.
> > >> >>
> > >> >> Does this Koji allow people to upload their own .spec/.src packages
> > >> >> and offer them a build? I'm thinking something like that for quarters
> > >> >> would be good. We can separate the building into 3 categories:
> > >> >>
> > >> >> == Distribution ==
> > >> >> This is where devs and TUs connect. If you can work out some kind of
> > >> >> integration, it will be totally seamless. Subversion hooks can
> > trigger
> > >> >> the builds, which then are placed in the respective home folders in
> > >> >> gerolde/sigurd. They can be auto uploaded with dbscripts as well but
> > I
> > >> >> don't know if that's a good idea, mainly because there needs to be
> > >> >> inspection (namcap and other habits) before the binary gets served
> > >> >> across the mirrors.
> > >> >>
> > >> >> == Projects ==
> > >> >> Any third-party packaging initiative can hook up to the system, and
> > in
> > >> >> turn get their binaries cooked. No-one is responsible for bad
> > >> >> packages.
> > >> >>
> > >> >> == Community ==
> > >> >> Users submit a PKGBUILD and in turn can download a Pacman package.
> > >> >> No-one is responsible for bad packages.
> > >> >>
> > >> >
> > >> > HAHA! I had not thought of that! I love it! The build system can build
> > >> user
> > >> > packages from uploaded PKGBUILDS, I would need to add some extra
> > security
> > >> on
> > >> > the chroots (or build them in super thin virtual machines), but that
> > >> would
> > >> > be great, users could verify that their packages were top notch before
> > >> > submitting them to the AUR and TUs could check packages much more
> > easily.
> > >> >
> > >> > As for the svn hooks, I was actually looking at polling the scms, this
> > >> way
> > >> > an scm can be completely detached from the builder and the builder can
> > >> just
> > >> > arbitrarily build from any old scm. I think that the solution here is
> > to
> > >> > configure the scms with specific criteria, so that they build into
> > >> specific
> > >> > repos.
> > >> >
> > >> > And thanks for your support Ray, it means a lot :)
> > >>
> > >> did somebody say distributed AUR?
> > >>
> > >> add a little P2P sharing of the PKG bits into localized repositories
> > >> and you got yourself a winner.
> > >>
> > >> C Anthony
> > >>
> > >
> > > Honestly, a build system could check AUR packages for cleanliness and
> > make a
> > > binary repo of working clan packages?
> > >
> > > We have been discussing this in the TU chat, and there is a lot of
> > > excitement about it, I am going to post some degign docs on the wiki here
> > in
> > > a few days (give me some time to put it together :) ) and then we can
> > have a
> > > free for all on how we want this to work.
> > >
> > > In the meantime, keep throwing ideas at me so I can work them into the
> > > design!
> > >
> > > Thanks again for the feedback!
> > >
> > > -Thomas S Hatch
> > >
> >
> > Hey, as I said in the irc, I also have given my full support for this.
> > I am willing to work on this also.
> >
> > I see a lot of potential especially in the aur portion of this system.
> > Mainly because it would guarantee that pkgs in the aur are "correct"
> > in the sense that they have correct dependencies, makedependencies and
> > proper variables (no $startdir) and that then can be built in a clean
> > chroot.
> >
> > Also, just to reiterate what I've said to Thomas Hatch, I have
> > implemented an aur clean chroot build system that works recursively:
> > https://bbs.archlinux.org/viewtopic.php?id=111366
> >
> 
> Yes, aurtools will prove to be a great asset for the builder.
> 
> FYI, I don't think I mentioned this, so far I have been calling the builder
> quarters, since we all know that in the arcade quarters are what really
> feeds pacman!
> 
> My project is on google code (I will be moving it to github so that making
> it official will be easier) and you are welcome to look it over and look at
> me preliminary design doc.
> 
> http://code.google.com/p/quarters/
> 
> Keep in mind, what is on google code will change dramatically based on your
> input!
> 
> With that all said, much of whats there will be replaced!

Hmmm just read all the mails and yes i am interested ;) 

except the idea of uploading to AUR and then building it, seems like a
waste of resources. 


The idea of an automatic build robot for the repos is much more
interesting,  and for me it only seems interesting if you're doing a big
rebuild. Or would you like the idea of scp src.tar.gz to your
~/autobuild on pkgbuild.com or any other build server.

Or massive rebuilds based on libs where you put a new perl/whatever in a
buildchroot and just upload your source packages and let them query then
put the output / packages build on some webpage.


So before coding get's done i am interested in the documents, design
etc. then I would love to help out ;)
-- 
Jelle van der Waa