From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16373 invoked by uid 1002); 11 Apr 2003 16:15:54 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 31546 invoked from network); 11 Apr 2003 16:15:54 -0000 From: Noah Justin Norris To: danarmak@gentoo.org Date: Fri, 11 Apr 2003 10:17:20 +0000 User-Agent: KMail/1.5.1 References: <200304100013.30307.gentoo@mchsi.com> <20030410115023.209d65d5.xwred1@xwredwing.net> <200304102234.24047.danarmak@gentoo.org> In-Reply-To: <200304102234.24047.danarmak@gentoo.org> Cc: gentoo-dev@gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304111017.20931.gentoo@mchsi.com> Subject: Re: [gentoo-dev] Binary release of gentoo X-Archives-Salt: f6b7715a-a124-4210-bacd-e35a93cb4c95 X-Archives-Hash: c81f1609525f2c97398c052b45b05718 compile farm now thats a good one. how many machines would you need to do such a task. i have cable connection here and i have 10 plus machines and when i get dsl at the place i work i could have 300-600 pentuims On Thursday 10 April 2003 07:34 pm, Dan Armak wrote: > On Thursday 10 April 2003 21:50, Matt Thrailkill wrote: > > Biggest problem I see is putting them up for download. Making them > > shouldn't be that hard, just require ebuild maintainers to submit a binary > pkg built with emerge -b when they submit their .ebuilds. > > Easy for you to say! I and other gentoo devs use 56k dialup, which > tyipcally sends data at 33.6kbps. Ever tried uploading big stuff at that > rate (which also blocks your other internet activity)? > > Besides building against GRP would mean a) maintaining a grp chroot > (reasonable) and b) building every package twice - once for myself, once > for grp. (No ccache because my cflags are different from grp's). So twice > the build time. Ugh. > > The solution for these is a compile farm into which devs can log remotely > and build packages. Or it could just build them automatically. But all this > would be is an extended GRP set - I don't see the need for that. GRP for > 1.4 is already slated to include all of kde and gnome, plus probably some > of the other heaviest compiles. Other than that, 99% of systems only need a > smallish amount of smallish apps compiled, you can finish that quite > quickly even on a slow machine - quicker probably than it'll take you to > donwload the precompiled GRP. > > (BTW with a fast machine and a 56k dialup, many packages probably take > longer to download precompiled than to compile locally (that's if you > discount time taken to download the sources though :-) ). > > Anyway if this is just an exnteded set of packages for GRP, why is everyone > talking about it as if it were a radical new feature? > > Making grp include all or nearly all the source tree shouldn't be that big > a problem. After all we already include most of the longest compiles (and > have openoffice-bin), so we probably already have at least a third of the > tree as far as compile time goes - and we can generate it for all archs in > jsut a few days according to the release policy schedule. So if we wanted > to make a complete GRP we probably could. > > Making it always include all new (stable) versions of packages (for all > archs!) would need a lot of compile power though, or rather it would need a > dedicated compile server (or piece of a cluster). Well, if you the > proponents of this idea have such a server handy, you can easily enough set > it up to do this and tell gentoo users they can get packages from there. > Adding a feature to emerge that'll make it fetch binary packages from a > specified server should be easy enough. (Although we need to improve the > binary package format to make it specify metadata like CFLAGS, arch... I > don't know if that's been done yet.) > > Well all that you can do you have such a server with a good uplink to > spare. However we of the project (me personally too) don't think that would > be good use of such a server, because we think the existing GRP is enough > (it can be expanded in time, but not so radically as you propose, at least > not right away. And it's not top priority with us.) So we would like to > respectfully ask you, if you have such a server, to please donate it to the > project :-) > > (Or at least hear our counter proposal of what we'd do with it. There > are/were plans of a build farm for devs to log on - for testing though more > than for building binary packages iirc - I don't know what the current > status is on that.) -- life is linux linux is life -- gentoo-dev@gentoo.org mailing list