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@xxxxxxxxx> wrote: > > > On Thu, Jan 27, 2011 at 1:12 PM, Thomas S Hatch <thatch45@xxxxxxxxx> > > wrote: > > > On Thu, Jan 27, 2011 at 12:01 PM, C Anthony Risinger <anthony@xxxxxxxx > > >wrote: > > > > > >> On Thu, Jan 27, 2011 at 12:37 PM, Thomas S Hatch <thatch45@xxxxxxxxx> > > >> wrote: > > >> > On Thu, Jan 27, 2011 at 11:24 AM, Ray Rashif <schiv@xxxxxxxxxxxxx> > > >> wrote: > > >> > > > >> >> On 28 January 2011 01:36, Thomas S Hatch <thatch45@xxxxxxxxx> 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
