From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: Advice about GuixSD on Serveraptor? Date: Wed, 22 Mar 2017 13:20:53 -0400 Message-ID: <20170322172053.GC6011@jasmine> References: <20170209183609.5rztohnqhsleifll@wasp> <20170213214717.GA11352@jasmine> <20170313003252.GA12094@jasmine> <20170321180638.GA3027@jasmine> <87mvcenzvw.fsf@dustycloud.org> <20170321204620.GA30143@jasmine> <20170321205335.GB30436@jasmine> <87r31ptt41.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cqjwS-0001fP-JD for guix-devel@gnu.org; Wed, 22 Mar 2017 13:21:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cqjwN-0000sq-FS for guix-devel@gnu.org; Wed, 22 Mar 2017 13:21:00 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:55314) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cqjwN-0000sf-7L for guix-devel@gnu.org; Wed, 22 Mar 2017 13:20:55 -0400 Content-Disposition: inline In-Reply-To: <87r31ptt41.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org On Wed, Mar 22, 2017 at 01:04:46PM +0100, Ricardo Wurmus wrote: > Leo Famulari writes: > > And to clarify my previous question: Should this QEMU image be created > > by me, or should it be created by a Guix maintainer as part of the Guix > > release process? > > I’m not sure. I guess it would be better for users if it was signed by > a maintainer key, but on the other hand I don’t know if we can commit to > publishing QEMU images with every release. Okay. > Could we build an image with Hydra instead and just provide the latest > build to Serveraptor? How would updates to the image be handled? Do > they offer some sort of API to upload new images or is this a process > that depends on humans making decisions? It's not a bad idea to build it on Hydra. Hydra already builds a usb-image / disk-image job [0], so we could add a qemu-image job, too. I think that updates to the image would have to be handled manually. One of us could send them a link to the new image and they'd make it available to their users. My expectation is that Serveraptor would offer our latest release, and users would be expected to update their systems, as on bare-metal. [0] https://hydra.gnu.org/job/gnu/core-updates/usb-image.x86_64-linux