[arch-general] Question about automated builder
gostrc at gmail.com
Thu Jan 27 14:28:51 EST 2011
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>
>> > On Thu, Jan 27, 2011 at 11:24 AM, Ray Rashif <schiv at archlinux.org>
>> >> 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
>> >> is
>> >> > in demand. So here is my question, do we think that something like
>> >> > would be a benefit to Arch? Is this the type of project that should
>> >> 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
>> > packages from uploaded PKGBUILDS, I would need to add some extra security
>> > the chroots (or build them in super thin virtual machines), but that
>> > 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
>> > an scm can be completely detached from the builder and the builder can
>> > 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
>> > 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
> 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
Also, just to reiterate what I've said to Thomas Hatch, I have
implemented an aur clean chroot build system that works recursively:
More information about the arch-general