From: Jan Nieuwenhuizen <janneke@gnu.org>
To: Mathieu Othacehe <othacehe@gnu.org>
Cc: 41350@debbugs.gnu.org
Subject: [bug#41350] [PATCH 0/3] Use native qemu to build vm-image.
Date: Tue, 19 May 2020 09:22:53 +0200 [thread overview]
Message-ID: <87367wbd82.fsf@gnu.org> (raw)
In-Reply-To: <87y2ppfw28.fsf@gnu.org> (Mathieu Othacehe's message of "Mon, 18 May 2020 11:10:07 +0200")
Mathieu Othacehe writes:
Hello Mathieu,
Thanks for chiming in, I meant to CC you... :-)
>> Cross-building a vm-image used to be done using a cross-qemu, e.g, qemu-ARM.
>> That does not work for the Hurd, as there is no qemu-HURD.
>
> Yes that's an issue.
Yes...luckily I think we found a way to use qemu-NATIVE to build
packages for the Hurd. Now to see if this can be put into digestible
form.
>> This patch switches to cross building vm-images using a native qemu vm. If
>> there a reason for using qemu-TARGET we may want to make this switch
>> conditional for cross building to the Hurd?
>
> Well first this 'vm-image' thing should be done in (gnu system image) as
> soon as I have sorted out the bootloader issue. So the solution we will
> find to overcome this Hurd issue will be temporary I hope.
Can you elaborate a bit on that? Do you think it makes sense to continue
this temporary path some more (as it starts to work right now), or can we
better abandon it and work the permanent solution? How could I contribute?
> About using qemu-TARGET, let say you are on an armhf machine and you
> want to cross-build an x86-64 image. I fear that using a native, armhf
> Grub to install an x86-64 Grub won't work.
Ah...right, that's helpful information.
> So maybe, it would be better to do that only for the architectures
> without an available qemu-TARGET (only the Hurd for now)?
OK -- I have changed patch 2 and 3, and am sending a new patch set.
>> ...the problem is now avoided by removing the sqlite dependency when
>> cross-building by not registering closures and postponing the loading of (gnu
>> store database) and thus (sqlite3).
>
> When I produce a system without register closures, once booted, "guix
> build" something does not work. I don't know if its possible for
> guix-daemon to work without its database. An option could be to generate
> this database if its absent, at first boot?
Ah, OK. I'm using this "solution" to use #:register-closures? #f now
for the Hurd only and we'll hit the problem that causes later. We can
then, s discussed on IRC, sqlite3 databases are indeed platform
independent and we could use something like guix/scripts/pack.scm's
store-database. WDYT?
>> ./pre-inst-env guix system vm-image --target=i586-pc-gnu --no-grafts \
>> gnu/system/examples/bare-hurd.tmpl
>>
>> now produces a pretty nice hurd VM :-)
>
> Great to see you so close :)
Yes...
Greetings,
janneke
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
next prev parent reply other threads:[~2020-05-19 7:24 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-17 10:01 [bug#41350] [PATCH 0/3] Use native qemu to build vm-image Jan Nieuwenhuizen
2020-05-17 10:03 ` [bug#41350] [PATCH 1/3] utils: Move 'reset-timestamps' out of database Jan (janneke) Nieuwenhuizen
2020-05-17 10:03 ` [bug#41350] [PATCH 2/3] system: vm: Do not register-closures when cross-building Jan (janneke) Nieuwenhuizen
2020-05-17 10:03 ` [bug#41350] [PATCH 3/3] system: vm: Build vm-image using native qemu Jan (janneke) Nieuwenhuizen
2020-05-18 9:10 ` [bug#41350] [PATCH 0/3] Use native qemu to build vm-image Mathieu Othacehe
2020-05-19 7:22 ` Jan Nieuwenhuizen [this message]
2020-05-19 10:02 ` Mathieu Othacehe
2020-05-20 14:03 ` Mathieu Othacehe
2020-05-20 15:09 ` Jan Nieuwenhuizen
2020-05-19 7:23 ` [bug#41350] [PATCH v2 1/3] utils: Move 'reset-timestamps' out of database Jan (janneke) Nieuwenhuizen
2020-05-19 7:23 ` [bug#41350] [PATCH v2 2/3] system: vm: Do not register-closures when cross-building to the Hurd Jan (janneke) Nieuwenhuizen
2020-05-19 7:23 ` [bug#41350] [PATCH v2 3/3] system: vm: Build vm-image using native qemu, for " Jan (janneke) Nieuwenhuizen
2020-05-19 9:14 ` Mathieu Othacehe
2020-05-20 21:49 ` Ludovic Courtès
2020-05-23 9:28 ` Jan Nieuwenhuizen
2020-05-23 17:45 ` Mathieu Othacehe
2020-05-23 19:07 ` Jan Nieuwenhuizen
2020-05-24 9:18 ` Mathieu Othacehe
2020-05-27 9:30 ` Ludovic Courtès
2020-05-28 7:00 ` Mathieu Othacehe
2020-05-24 11:19 ` Jan Nieuwenhuizen
2020-05-24 12:07 ` Mathieu Othacehe
2020-05-24 14:20 ` Jan Nieuwenhuizen
2020-05-24 16:36 ` Ludovic Courtès
2020-05-20 21:58 ` Ludovic Courtès
2020-05-22 19:24 ` Mathieu Othacehe
2020-05-27 22:54 ` Ludovic Courtès
2020-05-28 6:36 ` Mathieu Othacehe
2020-05-28 12:29 ` Jan Nieuwenhuizen
2020-05-28 15:39 ` Ludovic Courtès
2020-05-28 17:07 ` Jan Nieuwenhuizen
2020-05-28 17:10 ` Mathieu Othacehe
2020-05-28 18:19 ` Jan Nieuwenhuizen
2020-05-29 8:18 ` Ludovic Courtès
2020-05-29 9:06 ` Jan Nieuwenhuizen
2020-05-30 10:08 ` Jan Nieuwenhuizen
2020-05-30 13:54 ` Ludovic Courtès
2022-09-28 20:18 ` [bug#41350] [PATCH 0/3] Use native qemu to build vm-image Maxim Cournoyer
2022-09-29 14:17 ` bug#41350: " Mathieu Othacehe
2020-05-23 9:30 ` [bug#41350] [PATCH v3 1/3] utils: Move 'reset-timestamps' out of database Jan (janneke) Nieuwenhuizen
2020-05-23 9:30 ` [bug#41350] [PATCH v3 2/3] system: vm: Do not register-closures when cross-building to the Hurd Jan (janneke) Nieuwenhuizen
2020-05-27 8:45 ` Ludovic Courtès
2020-05-27 9:13 ` Jan Nieuwenhuizen
2020-05-23 9:30 ` [bug#41350] [PATCH v3 3/3] system: vm: Build vm-image using native qemu, for " Jan (janneke) Nieuwenhuizen
2020-05-27 8:43 ` [bug#41350] [PATCH v3 1/3] utils: Move 'reset-timestamps' out of database Ludovic Courtès
2020-05-27 8:59 ` Ludovic Courtès
2020-05-27 9:10 ` Jan Nieuwenhuizen
2020-05-24 18:11 ` [bug#41350] [PATCH v2 3/3] system: vm: Build vm-image using native qemu, for the Hurd Mathieu Othacehe
2020-05-24 18:40 ` Jan Nieuwenhuizen
2020-05-25 15:46 ` Jan Nieuwenhuizen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87367wbd82.fsf@gnu.org \
--to=janneke@gnu.org \
--cc=41350@debbugs.gnu.org \
--cc=othacehe@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).