From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 8631E385702D for ; Fri, 2 Jul 2021 09:05:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8631E385702D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=none smtp.mailfrom=cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 7F6A15CE7; Fri, 2 Jul 2021 11:05:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhmH5oeugQ0S; Fri, 2 Jul 2021 11:05:33 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p50854661.dip0.t-ipconnect.de [80.133.70.97]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id E8EFA61D2; Fri, 2 Jul 2021 11:05:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1625216733; bh=GdYxnpBQlll+fiTr01gsQ102Ozz/+6jNAeiQyA1uAKE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Qke18t9WmsnRq+TS8vDswFOZjYKyoOG5vAUNcApCRxgnnQvOCpWX4sG1wQ92iVLuf fo+7vFAe7DDetNhFDU1W3SMrbPncsC2nB64ct/e0lK+RXjqLJZzwDLWNHyzCAUlbAn 1IB6T1o6dj5CcZRmzAVHmKjbdN76828o1nTjx4MMlQqbzdJTQf1aJS4/SDJJzNiIsC d7ynicKUq18YhdzALscpxZCx6dRvNYGJc4Vg4pNr8ZEjYs8Luxx3PcoLO9bzkqetSI q09I9BsOz3GaGKdBFUayr1jgqcjshMwLBQU1LN4pjf2diXIJgxYBYtwGgCid+WCntW C24md08VGJ1bA== From: Rainer Orth To: Luis Machado Cc: Luis Machado via Gdb Subject: Re: [RFC] Proposal for hosting GDB CI builds References: <7bfae273-3887-30c8-dc65-94d5b177db56@linaro.org> <0e30f5d9-9f2f-05bd-1d02-30424017c6d7@linaro.org> Date: Fri, 02 Jul 2021 11:05:32 +0200 In-Reply-To: (Luis Machado's message of "Thu, 1 Jul 2021 10:10:50 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3787.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 09:05:36 -0000 Hi Luis, >>>> Besides, I seem to have glimpsed from the Linaro instance that the >>>> builders use Docker. Is this a requirement or just a convenience? I'm >>>> asking because there's no current Docker port to Solaris (there used to >>>> be one based on zones, but it's no longer maintained) and the >>>> buildbot-based builders I'm running (for both LLVM and GDB) do fine >>>> without. >>> >>> That is a convenience so we can share hardware resources. It is possible to >>> use real hardware to run the jobs. One may need to adjust the >> For my existing buildbots, I let them run inside Solaris zones (the >> equivalent of Linux containers) and could use ressource control features >> to provide additional containment (e.g. cpu, memory use) if need be. >> > > That's good. One other benefit of using docker images is the consistency > between runs. You have control over the exact distro + set of packages > that are installed in the image, so you have a better chance of being able > to repeat a run. understood. You can achieve somethine similar when installing Solaris zones using particular profiles. IIUC that's what had been used for the Solaris port of Docker. >>> configurations a bit (distro, packages etc), but a job can automate some >>> of that. Details about distros to use and packages to install still need to >>> be investigated/discussed. >> In my case, I start from a configuration matching what I use for manual >> GDB builds, afterwards keeping the system up to date about once a >> months. This makes the host somewhat a moving target, but the rate of >> chance hasn't ever caused problems. > > I think that's reasonable. Regular updates shouldn't cause breakage to > GDB. If they do, that's a sign that something was/got broken anyway. Exactly. Besides, I've got good contacts to Solaris engineering in case I cannot figure out what's wrong by myself. >> Documenting the set of necessary packages is similar to what one needs >> for manual GDB builds, just a bit more formalized. > > We maintain a set of required packages in a separate file. That file gets > loaded and processed so we are sure all the dependencies are met. So coming > up with a similar non-docker-based mechanism shouldn't be hard. Agreed. I'll certainly try that once we get there. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University