* Re: ISO image available for testing!
@ 2017-12-05 22:15 D4n1
0 siblings, 0 replies; 13+ messages in thread
From: D4n1 @ 2017-12-05 22:15 UTC (permalink / raw)
To: ludo; +Cc: guix-devel
Thanks Ludo! But there isn't a i686 ISO :( I'll try install on my x60s. But I'll try on may another PC using x86_64 platform.
Thanks,
Daniel Pimentel (d4n1)On Dec 5, 2017 8:47 PM, ludo@gnu.org wrote:
>
> Hi Chris,
>
> Christopher Baines <mail@cbaines.net> skribis:
>
> > I've attempted to use this to install GuixSD on a Bytemark
> > VM. Unfortunately I haven't succeeded yet. I managed to get as far as
> > running guix system init, but when I did, it started downloading the
> > bootstrap binaries, and then building binutils.
> >
> > When I run guix system build, or guix build with the --dry-run options,
> > it says that it will download, rather than building, but it doesn't.
>
> It turned out to be issues related to grafts and to what Hydra builds,
> fixed with these commits:
>
> 3e442f85f * gnu: ghostscript-with-cups: Turn into a public variable.
> 91c9b5d01 * packages: 'package-grafts' trims native inputs.
> ff0e0041f * packages: 'fold-bag-dependencies' honors nativeness in recursive calls.
> f00b85ff8 * gnu: commencement: Do not graft early bootstrap packages.
>
> The Binutils issue is fixed by f00b85ff8.
>
> Commit 91c9b5d01 notably fixes the “expat issue”: coreutils had expat in
> its dependency graph, via gettext. Thus, the expat graft was picked up
> as a candidate graft. However, expat itself was subject to the glibc
> graft, and since there was no substitute for this particular expat, we’d
> have to build it first, just to throw it away later on because coreutils
> does not refer to it at run time.
>
> Long story short: we were flagging native inputs as potential sources of
> grafts even though, by definition, native inputs are not referred to at
> run time.
>
> The last commit ensures that Hydra builds the replacement for
> ‘ghostscript-with-cups’.
>
> What’s tricky is that one doesn’t notice these issues unless starting
> from a fresh store.
>
> I’ve uploaded an updated ISO image, which I used to test substitute
> availability and grafts. If you have time in the coming hours, feedback
> welcome:
>
> http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.91c9b5d01.x86_64-linux.iso.xz
> http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.91c9b5d01.x86_64-linux.iso.xz.sig
>
> Ludo’.
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
@ 2017-12-05 22:05 D4n1
0 siblings, 0 replies; 13+ messages in thread
From: D4n1 @ 2017-12-05 22:05 UTC (permalink / raw)
To: ludo; +Cc: guix-devel
I'll test it and report here.
Thanks,
Daniel Pimentel (d4n1)On Dec 5, 2017 8:47 PM, ludo@gnu.org wrote:
>
> Hi Chris,
>
> Christopher Baines <mail@cbaines.net> skribis:
>
> > I've attempted to use this to install GuixSD on a Bytemark
> > VM. Unfortunately I haven't succeeded yet. I managed to get as far as
> > running guix system init, but when I did, it started downloading the
> > bootstrap binaries, and then building binutils.
> >
> > When I run guix system build, or guix build with the --dry-run options,
> > it says that it will download, rather than building, but it doesn't.
>
> It turned out to be issues related to grafts and to what Hydra builds,
> fixed with these commits:
>
> 3e442f85f * gnu: ghostscript-with-cups: Turn into a public variable.
> 91c9b5d01 * packages: 'package-grafts' trims native inputs.
> ff0e0041f * packages: 'fold-bag-dependencies' honors nativeness in recursive calls.
> f00b85ff8 * gnu: commencement: Do not graft early bootstrap packages.
>
> The Binutils issue is fixed by f00b85ff8.
>
> Commit 91c9b5d01 notably fixes the “expat issue”: coreutils had expat in
> its dependency graph, via gettext. Thus, the expat graft was picked up
> as a candidate graft. However, expat itself was subject to the glibc
> graft, and since there was no substitute for this particular expat, we’d
> have to build it first, just to throw it away later on because coreutils
> does not refer to it at run time.
>
> Long story short: we were flagging native inputs as potential sources of
> grafts even though, by definition, native inputs are not referred to at
> run time.
>
> The last commit ensures that Hydra builds the replacement for
> ‘ghostscript-with-cups’.
>
> What’s tricky is that one doesn’t notice these issues unless starting
> from a fresh store.
>
> I’ve uploaded an updated ISO image, which I used to test substitute
> availability and grafts. If you have time in the coming hours, feedback
> welcome:
>
> http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.91c9b5d01.x86_64-linux.iso.xz
> http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.91c9b5d01.x86_64-linux.iso.xz.sig
>
> Ludo’.
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* What’s next?
@ 2017-05-24 13:11 Ludovic Courtès
2017-10-04 15:12 ` Release! Ludovic Courtès
0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2017-05-24 13:11 UTC (permalink / raw)
To: guix-devel
[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]
Hello Guix!
I think it’s time to think about what we want to work on next, ideally
before the next release, and ideally said release should be in a couple
of months rather than in 5 months. Here are some important items I can
think of:
• Merge the ncurses installer (the ‘wip-installer’) branch.
• We’re supposed to freeze ‘core-updates’ in a couple of days and we
have defined a couple of important goals:
<https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00120.html>.
I have a vague feeling that the ‘wip-build-systems-gexp’ merge is
not for this time yet…
• ‘guix offload’ terrible bug: <https://bugs.gnu.org/26976>.
• Guile 2.2 compiler terrible issue:
<https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.
• Adjust the release process so we don’t find ourselves without
substitutes for the ‘guix’ package, as reported at
<https://bugs.gnu.org/27032>.
• Prepare to migrate to the new build farm: the hardware of
bayfront.guixsd.org has been fixed (it was unreliable until we
changed its CPUs), so now we need to fix a couple of issues in
Cuirass and generally improve it so we can, via its HTTP interface,
add new jobsets and so on. Of course we’ll have to work
on that incrementally.
• Finalize the new bootloader API and support for new bootloaders:
<https://bugs.gnu.org/26339>.
• Merge the potluck! <https://bugs.gnu.org/26645>
I think everything above could pretty much go into a 0.13.1 release not
far away. And the missing bits, IMO, for a “1.0” label would be:
• Improve the UI: add colors (yay!), hide build logs by default for
most commands, improve progress reports, display how much will be
downloaded, etc.
• Implement channels: <https://bugs.gnu.org/22629>. A first step may
be to fix some of the obvious shortcomings of ‘guix pull’: use (guix
git) to optimize bandwidth usage, and compute the derivation of the
new ‘guix’ and use that.
• Authenticate Git checkouts: <https://bugs.gnu.org/22883>.
What do people think?
I think the key idea is that we should fix all the annoyances and bugs,
many of which seasoned Guix hackers more or less got used to, but which
are nevertheless a serious hindrance when using Guix “normally.”
Ludo’.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Release!
2017-05-24 13:11 What’s next? Ludovic Courtès
@ 2017-10-04 15:12 ` Ludovic Courtès
2017-10-06 18:30 ` Release! Ricardo Wurmus
0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2017-10-04 15:12 UTC (permalink / raw)
To: guix-devel, Danny Milosavljevic, Ricardo Wurmus
Hello Guix!
ludo@gnu.org (Ludovic Courtès) skribis:
> I think it’s time to think about what we want to work on next, ideally
> before the next release, and ideally said release should be in a couple
> of months rather than in 5 months.
Oops, that was 5 months ago… :-)
> Here are some important items I can think of:
>
> • Merge the ncurses installer (the ‘wip-installer’) branch.
>
> • We’re supposed to freeze ‘core-updates’ in a couple of days and we
> have defined a couple of important goals:
> <https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00120.html>.
> I have a vague feeling that the ‘wip-build-systems-gexp’ merge is
> not for this time yet…
>
> • ‘guix offload’ terrible bug: <https://bugs.gnu.org/26976>.
>
> • Guile 2.2 compiler terrible issue:
> <https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.
>
> • Adjust the release process so we don’t find ourselves without
> substitutes for the ‘guix’ package, as reported at
> <https://bugs.gnu.org/27032>.
>
> • Prepare to migrate to the new build farm: the hardware of
> bayfront.guixsd.org has been fixed (it was unreliable until we
> changed its CPUs), so now we need to fix a couple of issues in
> Cuirass and generally improve it so we can, via its HTTP interface,
> add new jobsets and so on. Of course we’ll have to work
> on that incrementally.
>
> • Finalize the new bootloader API and support for new bootloaders:
> <https://bugs.gnu.org/26339>.
>
> • Merge the potluck! <https://bugs.gnu.org/26645>
Good news is that we made progress on some of these issues, but not all;
we also made progress on other things which are really cool, such as the
ISO installer.
Regardless, I think we should be planning for a release within a couple
of weeks. An important question to me is ‘wip-installer’: what do we
do, Danny? John?
I would have loved to have a fix to at least mitigate Guile’s compiler
resource consumption issue. I made some progress at
<https://bugs.gnu.org/28590> notably, but it’s not over yet.
In the meantime, it would be great if people could run an installation
from an ISO image and report bugs and glitches:
https://www.gnu.org/software/guix/manual/html_node/Building-the-Installation-Image.html
Thoughts?
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Release!
2017-10-04 15:12 ` Release! Ludovic Courtès
@ 2017-10-06 18:30 ` Ricardo Wurmus
2017-11-30 10:40 ` Release! Ludovic Courtès
0 siblings, 1 reply; 13+ messages in thread
From: Ricardo Wurmus @ 2017-10-06 18:30 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Hi Ludo,
>> Here are some important items I can think of:
[…]
>> • Guile 2.2 compiler terrible issue:
>> <https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.
One way to side-step this issue for the upcoming release is to use one
Guile process per file when running “guix pull”. This will make it run
a lot slower, but that would be better than the current situation.
Maybe we could make parallel compilation within the same Guile process
an option, so that it won’t be needlessly slow on machines within the
RAM goldilocks zone.
I’ve reverted f07041f7d25badb7d74b8fad6ee446a12af04f63 locally on my
i686 netbook with 1GB RAM and tested it with “guix pull
--url=/path/to/guix”. This seems to work — it’s still running… :)
One annoyance is that after compiling one file it prints this message:
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
I suppose we should suppress this for “guix pull”.
Do you want to make this behaviour optional, e.g. through a command line
switch like “--sloth”? Or should this be the default until the problem
in Guile/libgc is fixed?
>> • Prepare to migrate to the new build farm: the hardware of
>> bayfront.guixsd.org has been fixed (it was unreliable until we
>> changed its CPUs), so now we need to fix a couple of issues in
>> Cuirass and generally improve it so we can, via its HTTP interface,
>> add new jobsets and so on. Of course we’ll have to work
>> on that incrementally.
I guess we’ll be using berlin.guixsd.org instead of bayfront, no? I’m
currently installing additional servers (we’re now at 13 build servers,
I’ll get this up to 18 this week).
>> • Merge the potluck! <https://bugs.gnu.org/26645>
About that… We now have a JSON importer, so maybe it’s worth using the
even simpler JSON package format instead of the simplified S-expression
format that Andy proposed. What do you think? Should we discuss this
at <https://bugs.gnu.org/26645>?
Who would like to help us squash some bugs before the release? Let’s
try to fix at least 5 more bugs!
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Release!
2017-10-06 18:30 ` Release! Ricardo Wurmus
@ 2017-11-30 10:40 ` Ludovic Courtès
2017-12-01 18:30 ` Release! Leo Famulari
0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2017-11-30 10:40 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: guix-devel
Hello!
Time flies, but I think we’re about ready for the release. I’d like to
aim for next Tuesday (Dec. 5th) and fix small hickups and annoyances by
then, particularly regarding GuixSD installation.
Ricardo Wurmus <rekado@elephly.net> skribis:
>>> Here are some important items I can think of:
> […]
>>> • Guile 2.2 compiler terrible issue:
>>> <https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.
There’s more going on on the Guile side, but for now the recent split of
the big package files has helped reduce peak memory consumption
noticeably.
> One annoyance is that after compiling one file it prints this message:
>
> Some deprecated features have been used. Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information. Set it to "no" to suppress
> this message.
This was also showing up a lot in ‘guix system init’ et al, when
compiling modules. I think a912c723f76d9762072ce27204a9227a64bcb625
removes most of these.
>>> • Prepare to migrate to the new build farm: the hardware of
>>> bayfront.guixsd.org has been fixed (it was unreliable until we
>>> changed its CPUs), so now we need to fix a couple of issues in
>>> Cuirass and generally improve it so we can, via its HTTP interface,
>>> add new jobsets and so on. Of course we’ll have to work
>>> on that incrementally.
>
> I guess we’ll be using berlin.guixsd.org instead of bayfront, no?
Yes. Questions:
1. Do we pre-register berlin’s key on GuixSD?
2. Do we add berlin.guixsd.org to the list of substitute servers on
GuixSD? On Guix? The drawback is that ‘guix’ sometimes talks to
both servers when retrieve substitute lists, which can be slightly
slower/annoying, but otherwise I think it’s a win.
Thoughts?
The main GuixSD annoying messages that I think we should address by
Tuesday are:
1. “Error in finalization thread: Bad file descriptor” coming from the
Shepherd;
2. “udevd[304]: RUN{builtin}: 'uaccess' unknown /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
Both are harmless but they may give users a false sense that something’s
broken.
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Release!
2017-11-30 10:40 ` Release! Ludovic Courtès
@ 2017-12-01 18:30 ` Leo Famulari
2017-12-01 19:32 ` Release! Ricardo Wurmus
0 siblings, 1 reply; 13+ messages in thread
From: Leo Famulari @ 2017-12-01 18:30 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]
On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
> 1. Do we pre-register berlin’s key on GuixSD?
I vote yes.
> 2. Do we add berlin.guixsd.org to the list of substitute servers on
> GuixSD? On Guix? The drawback is that ‘guix’ sometimes talks to
> both servers when retrieve substitute lists, which can be slightly
> slower/annoying, but otherwise I think it’s a win.
I think it's worth the extra source of substitutes. Since adding
berlin.guixsd.org to my list of substitute URLs, it seems like I need to
build less often.
In my experience, it's annoying to query multiple servers when my
network connection is slow or unreliable. But, it's also annoying in
that situation to need to download source files from a variety of
upstream sites.
> The main GuixSD annoying messages that I think we should address by
> Tuesday are:
>
> 1. “Error in finalization thread: Bad file descriptor” coming from the
> Shepherd;
I'm not sure how to start debugging this :/ If I get some advice, I
could try to fix it on Sunday and Monday.
> 2. “udevd[304]: RUN{builtin}: 'uaccess' unknown /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
I haven't seen this one before.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Release!
2017-12-01 18:30 ` Release! Leo Famulari
@ 2017-12-01 19:32 ` Ricardo Wurmus
2017-12-04 8:58 ` ISO image available for testing! Ludovic Courtès
0 siblings, 1 reply; 13+ messages in thread
From: Ricardo Wurmus @ 2017-12-01 19:32 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
Leo Famulari <leo@famulari.name> writes:
> On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
>> 1. Do we pre-register berlin’s key on GuixSD?
>
> I vote yes.
>
>> 2. Do we add berlin.guixsd.org to the list of substitute servers on
>> GuixSD? On Guix? The drawback is that ‘guix’ sometimes talks to
>> both servers when retrieve substitute lists, which can be slightly
>> slower/annoying, but otherwise I think it’s a win.
>
> I think it's worth the extra source of substitutes. Since adding
> berlin.guixsd.org to my list of substitute URLs, it seems like I need to
> build less often.
>
> In my experience, it's annoying to query multiple servers when my
> network connection is slow or unreliable. But, it's also annoying in
> that situation to need to download source files from a variety of
> upstream sites.
I’d like to add berlin.guix.org to the list of default substitute
servers, but before I can allow this with a good conscience I need to
increase space on the head node. We were very busy, so the new head
node and storage aren’t ready yet, and the old node that’s currently
coordinating builds on berlin.guix.org has very limited storage.
I’ll try to get the new storage ready on Monday.
>> 2. “udevd[304]: RUN{builtin}: 'uaccess' unknown /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
>
> I haven't seen this one before.
I have seen it, but only when checking the output of dmesg. I guess we
could just remove that rule.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
^ permalink raw reply [flat|nested] 13+ messages in thread
* ISO image available for testing!
2017-12-01 19:32 ` Release! Ricardo Wurmus
@ 2017-12-04 8:58 ` Ludovic Courtès
2017-12-04 21:35 ` Christopher Baines
0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2017-12-04 8:58 UTC (permalink / raw)
To: guix-devel
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
Hello there!
I’ve uploaded a GuixSD installation ISO image for testing:
http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.8d7f1d736.x86_64-linux.iso.xz
SHA256: 7e04017494c419bb6ca654cff05dc7e5ba4fdfd3c2812fba9ba6d929b319e93b
http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.8d7f1d736.x86_64-linux.iso.xz.sig
It was built with “guix system disk-image -t iso9660
gnu/system/install.scm” on commit 8d7f1d736.
Note that it’s 1.1G uncompressed so it won’t fit on a CD.
Feedback welcome!
Ludo’.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
2017-12-04 8:58 ` ISO image available for testing! Ludovic Courtès
@ 2017-12-04 21:35 ` Christopher Baines
2017-12-04 22:34 ` Ludovic Courtès
2017-12-05 22:47 ` Ludovic Courtès
0 siblings, 2 replies; 13+ messages in thread
From: Christopher Baines @ 2017-12-04 21:35 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]
Ludovic Courtès writes:
> Hello there!
>
> I’ve uploaded a GuixSD installation ISO image for testing:
>
> http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.8d7f1d736.x86_64-linux.iso.xz
> SHA256: 7e04017494c419bb6ca654cff05dc7e5ba4fdfd3c2812fba9ba6d929b319e93b
>
> http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.8d7f1d736.x86_64-linux.iso.xz.sig
>
> It was built with “guix system disk-image -t iso9660
> gnu/system/install.scm” on commit 8d7f1d736.
>
> Note that it’s 1.1G uncompressed so it won’t fit on a CD.
>
> Feedback welcome!
Hey,
I've attempted to use this to install GuixSD on a Bytemark
VM. Unfortunately I haven't succeeded yet. I managed to get as far as
running guix system init, but when I did, it started downloading the
bootstrap binaries, and then building binutils.
When I run guix system build, or guix build with the --dry-run options,
it says that it will download, rather than building, but it doesn't.
I also made a few other notes during the installation process:
- The documentation mentions ipconfig to get the wired interface up,
but it isn't available in the image. I had to run ip link set eth0
up.
- The documentation says that the ssh server needs to be started, but
it was running without me starting it.
Any tips on debugging the building from source issue?
Thanks,
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
2017-12-04 21:35 ` Christopher Baines
@ 2017-12-04 22:34 ` Ludovic Courtès
2017-12-05 22:47 ` Ludovic Courtès
1 sibling, 0 replies; 13+ messages in thread
From: Ludovic Courtès @ 2017-12-04 22:34 UTC (permalink / raw)
To: Christopher Baines; +Cc: guix-devel
Hello,
Christopher Baines <mail@cbaines.net> skribis:
> I've attempted to use this to install GuixSD on a Bytemark
> VM. Unfortunately I haven't succeeded yet. I managed to get as far as
> running guix system init, but when I did, it started downloading the
> bootstrap binaries, and then building binutils.
>
> When I run guix system build, or guix build with the --dry-run options,
> it says that it will download, rather than building, but it doesn't.
I’m pretty sure the building-from-source comes from grafts where the
package replacements, for some reason, are not getting built by Hydra.
I thought this had been fixed by
b574cee361bdabf21f5506252b6a183dcfcd028d, but clearly it hasn’t.
I’ll investigate tomorrow.
> I also made a few other notes during the installation process:
>
> - The documentation mentions ipconfig to get the wired interface up,
> but it isn't available in the image. I had to run ip link set eth0
> up.
It mentions “ifconfig” (with an “f”) and that one is present. Or am I
missing something?
> - The documentation says that the ssh server needs to be started, but
> it was running without me starting it.
Indeed. I’ve pushed a fix as aab322d909c0b4abec132ef7aff31c31a1208841
in the new ‘version-0.14.0’ branch (note that it changes the ABI of (gnu
services ssh)).
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
2017-12-04 21:35 ` Christopher Baines
2017-12-04 22:34 ` Ludovic Courtès
@ 2017-12-05 22:47 ` Ludovic Courtès
2017-12-06 0:52 ` Mark H Weaver
2017-12-07 20:09 ` Christopher Baines
1 sibling, 2 replies; 13+ messages in thread
From: Ludovic Courtès @ 2017-12-05 22:47 UTC (permalink / raw)
To: Christopher Baines; +Cc: guix-devel
Hi Chris,
Christopher Baines <mail@cbaines.net> skribis:
> I've attempted to use this to install GuixSD on a Bytemark
> VM. Unfortunately I haven't succeeded yet. I managed to get as far as
> running guix system init, but when I did, it started downloading the
> bootstrap binaries, and then building binutils.
>
> When I run guix system build, or guix build with the --dry-run options,
> it says that it will download, rather than building, but it doesn't.
It turned out to be issues related to grafts and to what Hydra builds,
fixed with these commits:
3e442f85f * gnu: ghostscript-with-cups: Turn into a public variable.
91c9b5d01 * packages: 'package-grafts' trims native inputs.
ff0e0041f * packages: 'fold-bag-dependencies' honors nativeness in recursive calls.
f00b85ff8 * gnu: commencement: Do not graft early bootstrap packages.
The Binutils issue is fixed by f00b85ff8.
Commit 91c9b5d01 notably fixes the “expat issue”: coreutils had expat in
its dependency graph, via gettext. Thus, the expat graft was picked up
as a candidate graft. However, expat itself was subject to the glibc
graft, and since there was no substitute for this particular expat, we’d
have to build it first, just to throw it away later on because coreutils
does not refer to it at run time.
Long story short: we were flagging native inputs as potential sources of
grafts even though, by definition, native inputs are not referred to at
run time.
The last commit ensures that Hydra builds the replacement for
‘ghostscript-with-cups’.
What’s tricky is that one doesn’t notice these issues unless starting
from a fresh store.
I’ve uploaded an updated ISO image, which I used to test substitute
availability and grafts. If you have time in the coming hours, feedback
welcome:
http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.91c9b5d01.x86_64-linux.iso.xz
http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.91c9b5d01.x86_64-linux.iso.xz.sig
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
2017-12-05 22:47 ` Ludovic Courtès
@ 2017-12-06 0:52 ` Mark H Weaver
2017-12-06 1:17 ` Ben Woodcroft
` (2 more replies)
2017-12-07 20:09 ` Christopher Baines
1 sibling, 3 replies; 13+ messages in thread
From: Mark H Weaver @ 2017-12-06 0:52 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Hi Ludovic,
ludo@gnu.org (Ludovic Courtès) writes:
> 91c9b5d01 * packages: 'package-grafts' trims native inputs.
[...]
> Long story short: we were flagging native inputs as potential sources of
> grafts even though, by definition, native inputs are not referred to at
> run time.
I agree that this *should* never happen, but I see little reason for
confidence that it never happens in actual fact.
What would happen if a reference to a native-input *was* present in the
build outputs? The reason I ask is that, for security reasons, it's
obviously very important to reliably avoid using ungrafted software at
run time.
I'm concerned that this recent change could cause minor
nearly-undetectable packaging mistakes to become major security holes.
One solution would be to explicitly check build outputs for references
to native-inputs, and to force a build failure in that case.
What do you think?
Regards,
Mark
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
2017-12-06 0:52 ` Mark H Weaver
@ 2017-12-06 1:17 ` Ben Woodcroft
2017-12-06 8:04 ` Mark H Weaver
2017-12-06 8:14 ` Ludovic Courtès
2 siblings, 0 replies; 13+ messages in thread
From: Ben Woodcroft @ 2017-12-06 1:17 UTC (permalink / raw)
To: Mark H Weaver, Ludovic Courtès; +Cc: guix-devel
On 06/12/17 10:52, Mark H Weaver wrote:
> Hi Ludovic,
>
> ludo@gnu.org (Ludovic Courtès) writes:
>> 91c9b5d01 * packages: 'package-grafts' trims native inputs.
> [...]
>
>> Long story short: we were flagging native inputs as potential sources of
>> grafts even though, by definition, native inputs are not referred to at
>> run time.
> I agree that this *should* never happen, but I see little reason for
> confidence that it never happens in actual fact.
>
> What would happen if a reference to a native-input *was* present in the
> build outputs? The reason I ask is that, for security reasons, it's
> obviously very important to reliably avoid using ungrafted software at
> run time.
>
> I'm concerned that this recent change could cause minor
> nearly-undetectable packaging mistakes to become major security holes.
>
> One solution would be to explicitly check build outputs for references
> to native-inputs, and to force a build failure in that case.
I believe there are a number of cases of this that happen when binaries
are wrapped with paths derived from getenv, e.g. this phase in bamm:
(add-after 'install 'wrap-executable
(lambda* (#:key outputs #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
(path (getenv "PATH")))
(wrap-program (string-append out "/bin/bamm")
`("PATH" ":" prefix (,path))))
#t))
It would be good to stop using getenv for this, for the reasons
described here and others e.g. non-reproducibility, unnecessary
dependencies etc.
Is there some easy way to "getenv" excluding unwanted components of an
environment variable?
Thanks, ben
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
2017-12-06 0:52 ` Mark H Weaver
2017-12-06 1:17 ` Ben Woodcroft
@ 2017-12-06 8:04 ` Mark H Weaver
2017-12-06 8:14 ` Ludovic Courtès
2 siblings, 0 replies; 13+ messages in thread
From: Mark H Weaver @ 2017-12-06 8:04 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
I wrote:
> One solution would be to explicitly check build outputs for references
> to native-inputs, and to force a build failure in that case.
More precisely, we could force a build failure when any build output
contains a reference to a component (store path) in the following set:
requisites(native-inputs) - requisites(inputs)
Mark
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
2017-12-06 0:52 ` Mark H Weaver
2017-12-06 1:17 ` Ben Woodcroft
2017-12-06 8:04 ` Mark H Weaver
@ 2017-12-06 8:14 ` Ludovic Courtès
2017-12-06 16:29 ` Tobias Geerinckx-Rice
2 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2017-12-06 8:14 UTC (permalink / raw)
To: Mark H Weaver; +Cc: guix-devel
Hi Mark,
Mark H Weaver <mhw@netris.org> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
>> 91c9b5d01 * packages: 'package-grafts' trims native inputs.
>
> [...]
>
>> Long story short: we were flagging native inputs as potential sources of
>> grafts even though, by definition, native inputs are not referred to at
>> run time.
>
> I agree that this *should* never happen, but I see little reason for
> confidence that it never happens in actual fact.
>
> What would happen if a reference to a native-input *was* present in the
> build outputs? The reason I ask is that, for security reasons, it's
> obviously very important to reliably avoid using ungrafted software at
> run time.
>
> I'm concerned that this recent change could cause minor
> nearly-undetectable packaging mistakes to become major security holes.
Given the examples that Tobias and Ben were quick to find, I’m afraid
you’re right and I was overconfident. I’m reverting the change.
> One solution would be to explicitly check build outputs for references
> to native-inputs, and to force a build failure in that case.
We could do that, though I suppose a lot of packages would break.
Thanks to the quick reply,
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
2017-12-06 8:14 ` Ludovic Courtès
@ 2017-12-06 16:29 ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 13+ messages in thread
From: Tobias Geerinckx-Rice @ 2017-12-06 16:29 UTC (permalink / raw)
To: ludo; +Cc: guix-devel
Ludovic Courtès wrote on 06/12/17 at 09:14:
>> One solution would be to explicitly check build outputs for references
>> to native-inputs, and to force a build failure in that case.
I started a rudimentary PoC for this last week, after realising how bad
the situation is in ghc-* alone. We'll see what comes of it.
> We could do that, though I suppose a lot of packages would break.
We *should* do it, though. Just not before the pending release.
Kind regards,
T G-R
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
2017-12-05 22:47 ` Ludovic Courtès
2017-12-06 0:52 ` Mark H Weaver
@ 2017-12-07 20:09 ` Christopher Baines
2017-12-07 21:19 ` Ludovic Courtès
1 sibling, 1 reply; 13+ messages in thread
From: Christopher Baines @ 2017-12-07 20:09 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 2953 bytes --]
Ludovic Courtès writes:
> Hi Chris,
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> I've attempted to use this to install GuixSD on a Bytemark
>> VM. Unfortunately I haven't succeeded yet. I managed to get as far as
>> running guix system init, but when I did, it started downloading the
>> bootstrap binaries, and then building binutils.
>>
>> When I run guix system build, or guix build with the --dry-run options,
>> it says that it will download, rather than building, but it doesn't.
>
> It turned out to be issues related to grafts and to what Hydra builds,
> fixed with these commits:
>
> 3e442f85f * gnu: ghostscript-with-cups: Turn into a public variable.
> 91c9b5d01 * packages: 'package-grafts' trims native inputs.
> ff0e0041f * packages: 'fold-bag-dependencies' honors nativeness in recursive calls.
> f00b85ff8 * gnu: commencement: Do not graft early bootstrap packages.
>
> The Binutils issue is fixed by f00b85ff8.
>
> Commit 91c9b5d01 notably fixes the “expat issue”: coreutils had expat in
> its dependency graph, via gettext. Thus, the expat graft was picked up
> as a candidate graft. However, expat itself was subject to the glibc
> graft, and since there was no substitute for this particular expat, we’d
> have to build it first, just to throw it away later on because coreutils
> does not refer to it at run time.
>
> Long story short: we were flagging native inputs as potential sources of
> grafts even though, by definition, native inputs are not referred to at
> run time.
>
> The last commit ensures that Hydra builds the replacement for
> ‘ghostscript-with-cups’.
>
> What’s tricky is that one doesn’t notice these issues unless starting
> from a fresh store.
>
> I’ve uploaded an updated ISO image, which I used to test substitute
> availability and grafts. If you have time in the coming hours, feedback
> welcome:
Thanks for fixing this Ludo, and congratulations on the release. I'm
glad to say that I've now managed to install GuixSD using the 0.14.0
x86_64 ISO, however I did encounter some difficulties.
I tried a few times with both the ISO you replied with here, and the
released ISO, but each time the virtual machine I was installing on to
appeared to restart while guix system init was running. It's difficult
to get more information, but the last messages I got out of guix system
init relate to grafting and collisions.
This evening when I tried again I passed --no-grafts to guix system
init, and this time it successfully finished the
installation. Interestingly, this is also what is actually tested by the
iso-image-installer system test, as it sets the GUIX_BUILD_OPTIONS
environment variable.
This isn't conclusive, but I'd be very interested to hear from anyone
that has had similar issues, or successes in using the ISO installer,
both with and without the --no-grafts option.
Thanks again,
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ISO image available for testing!
2017-12-07 20:09 ` Christopher Baines
@ 2017-12-07 21:19 ` Ludovic Courtès
0 siblings, 0 replies; 13+ messages in thread
From: Ludovic Courtès @ 2017-12-07 21:19 UTC (permalink / raw)
To: Christopher Baines; +Cc: guix-devel
Hello Chris,
Christopher Baines <mail@cbaines.net> skribis:
> Thanks for fixing this Ludo, and congratulations on the release. I'm
> glad to say that I've now managed to install GuixSD using the 0.14.0
> x86_64 ISO, however I did encounter some difficulties.
>
> I tried a few times with both the ISO you replied with here, and the
> released ISO, but each time the virtual machine I was installing on to
> appeared to restart while guix system init was running. It's difficult
> to get more information, but the last messages I got out of guix system
> init relate to grafting and collisions.
I wonder how the VM can restart. Could it be an out-of-memory
condition? Though even that should not lead to a reboot.
Could you see if you can get more details from the VM?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-12-07 21:19 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-05 22:15 ISO image available for testing! D4n1
-- strict thread matches above, loose matches on Subject: below --
2017-12-05 22:05 D4n1
2017-05-24 13:11 What’s next? Ludovic Courtès
2017-10-04 15:12 ` Release! Ludovic Courtès
2017-10-06 18:30 ` Release! Ricardo Wurmus
2017-11-30 10:40 ` Release! Ludovic Courtès
2017-12-01 18:30 ` Release! Leo Famulari
2017-12-01 19:32 ` Release! Ricardo Wurmus
2017-12-04 8:58 ` ISO image available for testing! Ludovic Courtès
2017-12-04 21:35 ` Christopher Baines
2017-12-04 22:34 ` Ludovic Courtès
2017-12-05 22:47 ` Ludovic Courtès
2017-12-06 0:52 ` Mark H Weaver
2017-12-06 1:17 ` Ben Woodcroft
2017-12-06 8:04 ` Mark H Weaver
2017-12-06 8:14 ` Ludovic Courtès
2017-12-06 16:29 ` Tobias Geerinckx-Rice
2017-12-07 20:09 ` Christopher Baines
2017-12-07 21:19 ` Ludovic Courtès
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).