From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@gnu.org> Subject: Re: Plan for a release! Date: Thu, 26 Mar 2020 12:55:50 +0100 Message-ID: <87a743ba9l.fsf@gnu.org> References: <87pne3d5t6.fsf@gnu.org> <87o8t1smpe.fsf@gnu.org> <87k13h7gg3.fsf@gnu.org> <87tv2ld04o.fsf@gmail.com> <87k13fjo2i.fsf@gmail.com> <87k13d1zj7.fsf@gnu.org> <87k13bnp38.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org> Received: from eggs.gnu.org ([2001:470:142:3::10]:38485) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <ludo@gnu.org>) id 1jHR75-0008HG-3T for guix-devel@gnu.org; Thu, 26 Mar 2020 07:55:56 -0400 In-Reply-To: <87k13bnp38.fsf@gmail.com> (Mathieu Othacehe's message of "Mon, 23 Mar 2020 15:05:47 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." <guix-devel.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>, <mailto:guix-devel-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/guix-devel> List-Post: <mailto:guix-devel@gnu.org> List-Help: <mailto:guix-devel-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>, <mailto:guix-devel-request@gnu.org?subject=subscribe> Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" <guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org> To: Mathieu Othacehe <m.othacehe@gmail.com> Cc: guix-devel@gnu.org Hi, Mathieu Othacehe <m.othacehe@gmail.com> skribis: >> Yes: you need to have =E2=80=98installation-os-for-gui-tests=E2=80=99 (o= r preferably a >> variant thereof) include all the services/packages needed for the target >> config. >> >> In the manual installation tests we use =E2=80=98define-os-with-source= =E2=80=99 to both >> embed the target OS and its references in the installation image *and* >> have the source of the target OS available in /etc/target-config.scm in >> the installation image. > > Ok! I'm testing with an installation image containing all desktop > environments. This represents 1200 store items (image around 6GiB). > > The disk-image creation takes 2h45 on a powerful machine (with > KVM). I've seen your insights on this topic here: > >> I'd like to propose an alternative mechanism which would be faster and >> not involving virtual machines. Maybe producing the disk-image in a >> container? > > Unfortunately, I don=E2=80=99t think that=E2=80=99s possible. The reason= we resort to > VMs is that the Linux kernel doesn=E2=80=99t allow you, for instance, to = mount a > file system without being root. So doing things like running Parted, > mounting a file system, and populating it typically requires root > privileges. (In some cases, there are tools like mksquashfs that can do > that from user-space, but it=E2=80=99s very ad-hoc.) > > It makes sense and after some digging, I cannot propose something > better (nix is using the same mechanism). However, I feel very > frustrated by this disk-image thing, loosing a lot of time and > computation time for some copies. Understood. :-/ Another approach would be to do like =E2=80=98guix system vm=E2=80=99, whic= h is to share the store with the host. But then we would need a way to be able to run a daemon in the guest and have its build results overlaid on top of the host-provided store. Note that system tests other than the installation tests actually use the equivalent of =E2=80=98guix system vm=E2=80=99 already, so they copy mu= ch less stuff around. Thanks, Ludo=E2=80=99.