Re: Changing HTTP proxy settings in GuixSD
Hi Chris,
> That error looks suspicious. Perhaps you already know this, but it
> probably means that the string "mirror.hydra.gnu.org" wound up being
> used where a procedure should probably have been used instead. For
> example, in your Guile REPL, you can reproduce this kind of error like
> this:
>
> scheme@(guile-user)> ("this is not a procedure")
> ERROR: ERROR: Wrong type to apply: "this is not a procedure"
Suspicious indeed...
> The workaround that Ludo described, in which you temporarily stop the
> guix-daemon, and then start it in an environment where http_proxy is set
> appropriately, should work.
That's exactly what I did.
> If it isn't, then can I ask to see the commands and conigs you're
> using which fail?
Here are the commands I typed:
sudo -s
herd stop guix-daemon
http_proxy=http://proxy.synchrotron-soleil.fr:8080/ guix-daemon
--build-users-group=guixbuild
guix system reconfigure /etc/config.scm
The config I used in this first test (attached) is exactly the same one
I am currently running, with no reference to the proxy at all. I was
planning to add that in a second step.
Konrad.
config.scm
Description: Binary data
Re: EOMA68-A20 preproduction unit for dev work
On 10 November 2017 07:35:50 GMT+07:00, Eric Bavier wrote: >Hello Guix, > >There may be an opportunity to get a preproduction EOMA68-A20 unit from >lkcl. He'd like them to be used for either hardware or software >development. I'm not sure that I have the time or necessary experience >to help in that way myself, but I'd like to still support the project >and I'd really like to see Guix(SD) up and running there. > >I know we already have a few people here who have been working on >arm/aarch64 things. If anyone is interested in working towards >Guix(SD) on the EOMA68-A20, I'd be willing to sponsor the cost of the >preproduction hardware. Please let me know so that we can discuss with >lkcl and arrange it. > >`~Eric Hey Eric, always exciting to see posts in in the lists for one project you're interested in about other projects you're interested in. For what its worth I will be receiving a preproduction unit from lkcl. I will prioritize whatever Luke needs first, but I would like to work on porting GuixSD as it is my preferred distro and the best path forward for GNU. That being said I'd encourage anyone else interested to peruse it as well as I have no idea how long it may take me.
make "sysadmin people" a proper service in master
Hi Ludovic, I've recently had the need for the (sysadmin people) module for some work in GNUnet. I had to copy it from the guix repo with the server configurations in it. I think it would be better to include it in master so that more people (and hosters) can make use of it. What's missing for it to be included? It's relatively small, so it shouldn't be too much work to include it in master? -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dl.n0.is/dist/keys/ WWW: https://we.make.ritual.n0.is signature.asc Description: PGP signature
Re: EOMA68-A20 preproduction unit for dev work
Hi Eric, > arm/aarch64 things. If anyone is interested in working towards > Guix(SD) on the EOMA68-A20, I'd be willing to sponsor the cost of the > preproduction hardware. Please let me know so that we can discuss with > lkcl and arrange it. Louis Pearson bring this subject a few month ago on this ML : https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00355.html. I'm currently working on porting GuixSD on a beaglebone black, and would still be really interested by the EOMA68-A20 board :) Thanks, Mathieu
Re: EOMA68-A20 preproduction unit for dev work
It's cool! I'll waiting for it and I'll try to help too. thanks, --- Daniel Pimentel (d4n1) On 2017-11-10 10:52, Mathieu Othacehe wrote: Hi Eric, arm/aarch64 things. If anyone is interested in working towards Guix(SD) on the EOMA68-A20, I'd be willing to sponsor the cost of the preproduction hardware. Please let me know so that we can discuss with lkcl and arrange it. Louis Pearson bring this subject a few month ago on this ML : https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00355.html. I'm currently working on porting GuixSD on a beaglebone black, and would still be really interested by the EOMA68-A20 board :) Thanks, Mathieu
Re: EOMA68-A20 preproduction unit for dev work
It's cool. I have a BBB and I waiting for my EOMA68. So, I want trying run GuixSD on it too. Thanks, --- Daniel Pimentel (d4n1) On 2017-11-09 21:35, Eric Bavier wrote: Hello Guix, There may be an opportunity to get a preproduction EOMA68-A20 unit from lkcl. He'd like them to be used for either hardware or software development. I'm not sure that I have the time or necessary experience to help in that way myself, but I'd like to still support the project and I'd really like to see Guix(SD) up and running there. I know we already have a few people here who have been working on arm/aarch64 things. If anyone is interested in working towards Guix(SD) on the EOMA68-A20, I'd be willing to sponsor the cost of the preproduction hardware. Please let me know so that we can discuss with lkcl and arrange it. `~Eric
Re: [PATCH 0/6] Error reporting and hints for missing modules
On 11/10/2017 at 00:04 Ludovic Courtès writes: > > Thrilled by this idea, I pushed an unbound-variable handler that can > provide hints, such as: > > configuration.scm:88:19: zip: unbound variable > hint: Try adding `(use-modules (gnu packages compression))'. > > Feedback welcome! I built and played with this. If I follow some of the hints literally they lead me astray. Here are some suggested hint rewording. Note: You can reproduce the errors/hints below with the attached files. HTH - George HINT REWORDING SUGGESTIONS: *** test2: "NON EXISTANT PACKAGE MODULE (qemu) for qemu PACKAGE SPECIFIED" The error messages ... /root/ctest/test2:4:0: error: module (gnu packages qemu) not found hint: Try adding `(use-package-modules virtualization)'. ... are followed literally in test2.fix, which does not fix the problem because the stale and non-existant 'qemu' package module reference also needs to be removed. Maybe a better hint would be ... hint: Remove the reference to the pachage module that was not hint: found and add `(use-package-modules virtualization)'. *** test3: 'NON EXISTANT (openssh) SERVICE MODULE specified' This has the same conceptual problem as test2 above. The error messages ... /root/ctest/test3:3:0: error: module (gnu services openssh) not found hint: Try adding `(use-service-modules ssh)'. ... are followed literally in test3.fix, which does not fix the problem because the non-existant 'openssh' service module reference also needs to be removed. Maybe a better hint would be ... hint: Remove the reference to the service module that was not hint: found and add `(use-service-modules ssh)'. *** test4: "SERVICE MODULE (ssh) for openssh-service-type SERVICE MISSING" A more helpful hint here ... /root/ctest/test4:46:19: /root/ctest/test4:46:19: openssh-service-type: unbound variable hint: Did you forget a `use-modules' form? ... would be ... hint: Try adding `(use-service-modules ssh)'. *** VERSION INFO: 74bea6a03 gnu: linux-libre: Update to 4.13.12. make check failed as reported in bug#29245 but I don't think those errors affect what I am seeing here. TEST FILES: test0.scm Description: Binary data try.sh Description: Bourne shell script try.sh.log Description: Binary data
Re: EOMA68-A20 preproduction unit for dev work
Hello Adam, On Fri, 10 Nov 2017 17:01:36 +0700 Adam Van Ymeren wrote: > On 10 November 2017 07:35:50 GMT+07:00, Eric Bavier > wrote: > >Hello Guix, > > > >There may be an opportunity to get a preproduction EOMA68-A20 unit from > >lkcl. He'd like them to be used for either hardware or software > >development. I'm not sure that I have the time or necessary experience > >to help in that way myself, but I'd like to still support the project > >and I'd really like to see Guix(SD) up and running there. > > > >I know we already have a few people here who have been working on > >arm/aarch64 things. If anyone is interested in working towards > >Guix(SD) on the EOMA68-A20, I'd be willing to sponsor the cost of the > >preproduction hardware. Please let me know so that we can discuss with > >lkcl and arrange it. > > > >`~Eric > > Hey Eric, always exciting to see posts in in the lists for one > project you're interested in about other projects you're interested > in. Indeed :) > > For what its worth I will be receiving a preproduction unit from > lkcl. Very cool! > I will prioritize whatever Luke needs first, but I would like > to work on porting GuixSD as it is my preferred distro and the best > path forward for GNU. Sounds like a good plan. I also think they're both important projects, so thank you for your help already. > That being said I'd encourage anyone else interested to peruse it as > well as I have no idea how long it may take me. We may have a small team of people working on it then. :) `~Eric
Re: EOMA68-A20 preproduction unit for dev work
On Fri, 10 Nov 2017 14:52:12 +0100 Mathieu Othacehe wrote: > Hi Eric, > > > arm/aarch64 things. If anyone is interested in working towards > > Guix(SD) on the EOMA68-A20, I'd be willing to sponsor the cost of the > > preproduction hardware. Please let me know so that we can discuss with > > lkcl and arrange it. > > Louis Pearson bring this subject a few month ago on this ML : > https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00355.html. Right, I remember seeing this conversation. And now there's another concrete opporunity. > I'm currently working on porting GuixSD on a beaglebone black, and would > still be really interested by the EOMA68-A20 board :) Your bootloader patches have been really great! It'd be great to have you working on the EOMA68. Let's discuss. :) `~Eric pgpdXN6yNUbFo.pgp Description: OpenPGP digital signature
Re: [bootstrappable] diverse double compilation: using $ORIGIN?
Jan Nieuwenhuizen writes: >>> Usage: guix build gcc-dcc >>> >>> Building gcc-dcc tests the diverse double compilation property >>> of the gcc that Guix is using. >>> >>> * gnu/packages/bootstrappable.scm: New file. >>> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it. >> >> Awesome! Does it build fine out-of-the-box? I didn’t expect it to be >> “this easy.” :-) > > I got very positive feedback from a slightly guix-sceptic person saying > something like: you lisp guys can do quite a lot with very little code. > > However, all this patch adds is a test that fails: gcc built with gcc is > not bit-for-bit the same as gcc built with clang. > > Since then I have included the build-path-prefix-map patch, use -rpath > $ORIGIN instead of -rpath "-lib", switched to gcc-7.2.0. Still, no > bit-reproducibility. > > I'll be sending updated patches soon. Well, that took more time than I expected. I switched from 7.2.0 to 4.7.4 as the first target for diverse double compilation as it seems that 7.2 uses some non-reproducible hash map that I cannot track down _and_ 4.7.x is the latest bootstrappable gcc. Finally, I succeeded in building repro-gcc@4.7.4 using $ORIGIN for rpath. However, gcc-ddc@4.7.4 still shows that some absolute file names are embedded in bin/gcc (yes, I know cpp, cc1 and ../lib* hold most of the functionality): /gnu/store/zw672zcmykdwzm4x7l098hb94c34ak85-repro-gcc-4.7.4/bin/ /gnu/store/zw672zcmykdwzm4x7l098hb94c34ak85-repro-gcc-4.7.4/lib/gcc/ /gnu/store/zw672zcmykdwzm4x7l098hb94c34ak85repro-gcc-4.7.4._ROOT the first one most probably comes from static const char *const standard_bindir_prefix = STANDARD_BINDIR_PREFIX; I haven't looked a the other two yet. I'm attaching the diffoscope diff and the new patch. Could do with some help here. Thanks, janneke >From 761ec12aa3a34cd3b95a1c3d828d8bb45558d383 Mon Sep 17 00:00:00 2001 From: Jan Nieuwenhuizen Date: Thu, 2 Nov 2017 06:52:46 +0100 Subject: [PATCH] gnu: Add clang-gcc, gcc-ddc. WIP Usage: guix build gcc-dcc Building gcc-dcc tests the diverse double compilation property of the gcc that Guix is using. gcc-dcc is a meta-package that depends on repro-gcc-4.7.4 and on clang-gcc-4.7.4 (the same GCC built with clang). The builder checks if both gcc's are bit-by-bit identical and fails if they differ. * gnu/packages/patches/gcc-4-build-path-prefix-map.patch: New file. * gnu/packages/patches/gcc-7-build-path-prefix-map.patch: New file. * gnu/packages/bootstrappable.scm: New file. * gnu/local.mk (GNU_SYSTEM_MODULES,dist_patch_DATA): Add them. --- gnu/local.mk | 2 + gnu/packages/bootstrappable.scm| 356 .../patches/gcc-4-build-path-prefix-map.patch | 780 + ...fns-fix-mismatch-in-gnu_inline-attributes.patch | 65 ++ .../gcc-5-reproducibility-drop-profile.patch | 36 + .../patches/gcc-7-build-path-prefix-map.patch | 934 + 6 files changed, 2173 insertions(+) create mode 100644 gnu/packages/bootstrappable.scm create mode 100644 gnu/packages/patches/gcc-4-build-path-prefix-map.patch create mode 100644 gnu/packages/patches/gcc-4-cfns-fix-mismatch-in-gnu_inline-attributes.patch create mode 100644 gnu/packages/patches/gcc-5-reproducibility-drop-profile.patch create mode 100644 gnu/packages/patches/gcc-7-build-path-prefix-map.patch diff --git a/gnu/local.mk b/gnu/local.mk index 71392d86c..335678160 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -79,6 +79,7 @@ GNU_SYSTEM_MODULES =\ %D%/packages/boost.scm \ %D%/packages/bootloaders.scm \ %D%/packages/bootstrap.scm \ + %D%/packages/bootstrappable.scm \ %D%/packages/build-tools.scm \ %D%/packages/busybox.scm \ %D%/packages/c.scm\ @@ -646,6 +647,7 @@ dist_patch_DATA = \ %D%/packages/patches/gcc-5-source-date-epoch-2.patch \ %D%/packages/patches/gcc-6-arm-none-eabi-multilib.patch \ %D%/packages/patches/gcc-6-cross-environment-variables.patch \ + %D%/packages/patches/gcc-7-build-path-prefix-map.patch \ %D%/packages/patches/gcr-disable-failing-tests.patch \ %D%/packages/patches/gcr-fix-collection-tests-to-work-with-gpg-21.patch \ %D%/packages/patches/gd-fix-tests-on-i686.patch \ diff --git a/gnu/packages/bootstrappable.scm b/gnu/packages/bootstrappable.scm new file mode 100644 index 0..cbd7592db --- /dev/null +++ b/gnu/packages/bootstrappable.scm @@ -0,0 +1,356 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2017 Jan Nieuwenhuizen +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;;
Re: Changing HTTP proxy settings in GuixSD
Hi Konrad,
Konrad Hinsen skribis:
>> That error looks suspicious. Perhaps you already know this, but it
>> probably means that the string "mirror.hydra.gnu.org" wound up being
>> used where a procedure should probably have been used instead. For
>> example, in your Guile REPL, you can reproduce this kind of error like
>> this:
>>
>> scheme@(guile-user)> ("this is not a procedure")
>> ERROR: ERROR: Wrong type to apply: "this is not a procedure"
>
> Suspicious indeed...
It turned out to come from a typo in Guile 2.2’s web client, now fixed
here:
https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2&id=7d0d9e2c25c1e872cfc7d14ab5139915f1813d56
and I’ve done some monkey-patching here:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=59da6f04f45b36696a9385babab3080d7d854fba
I’ll update the ‘guix’ package soon so that this change is available to
daemon-side code such as ‘guix substitute’. In the meantime you can run
the daemon from a checkout:
sudo -E ./pre-inst-env guix-daemon …
For reference, I used this command to test proxy support:
http_proxy=http://localhost:8118 \
./pre-inst-env guix download http://www.gnu.org
where Privoxy is listening to localhost:8118.
Thanks for reporting the issue!
Ludo’.
Re: Changing HTTP proxy settings in GuixSD
Ludovic Courtès transcribed 1.4K bytes:
> Hi Konrad,
>
> Konrad Hinsen skribis:
>
> >> That error looks suspicious. Perhaps you already know this, but it
> >> probably means that the string "mirror.hydra.gnu.org" wound up being
> >> used where a procedure should probably have been used instead. For
> >> example, in your Guile REPL, you can reproduce this kind of error like
> >> this:
> >>
> >> scheme@(guile-user)> ("this is not a procedure")
> >> ERROR: ERROR: Wrong type to apply: "this is not a procedure"
> >
> > Suspicious indeed...
>
> It turned out to come from a typo in Guile 2.2’s web client, now fixed
> here:
>
>
> https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2&id=7d0d9e2c25c1e872cfc7d14ab5139915f1813d56
>
> and I’ve done some monkey-patching here:
>
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=59da6f04f45b36696a9385babab3080d7d854fba
>
> I’ll update the ‘guix’ package soon so that this change is available to
> daemon-side code such as ‘guix substitute’. In the meantime you can run
> the daemon from a checkout:
>
> sudo -E ./pre-inst-env guix-daemon …
>
> For reference, I used this command to test proxy support:
>
> http_proxy=http://localhost:8118 \
> ./pre-inst-env guix download http://www.gnu.org
>
> where Privoxy is listening to localhost:8118.
>
> Thanks for reporting the issue!
>
> Ludo’.
Oh. I think I encountered a similar (or the same?) problem one
year ago without ever reporting it.
I'll check soon if my usecase is fixed with your latest commits.
Thanks for working on this!
--
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dl.n0.is/dist/keys/
WWW: https://we.make.ritual.n0.is
signature.asc
Description: PGP signature
Re: [PATCH 0/6] Error reporting and hints for missing modules
Le 10 novembre 2017 15:47:37 GMT+01:00, myglc2 a écrit : >On 11/10/2017 at 00:04 Ludovic Courtès writes: >> >> Thrilled by this idea, I pushed an unbound-variable handler that can >> provide hints, such as: >> >> configuration.scm:88:19: zip: unbound variable >> hint: Try adding `(use-modules (gnu packages compression))'. >> >> Feedback welcome! > >I built and played with this. If I follow some of the hints literally >they lead me astray. Here are some suggested hint rewording. > >Note: You can reproduce the errors/hints below with the attached files. > >HTH - George > >HINT REWORDING SUGGESTIONS: > >*** test2: "NON EXISTANT PACKAGE MODULE (qemu) for qemu PACKAGE >SPECIFIED" > >The error messages ... > >/root/ctest/test2:4:0: error: module (gnu packages qemu) not found >hint: Try adding `(use-package-modules virtualization)'. > >... are followed literally in test2.fix, which does not fix the >problem because the stale and non-existant 'qemu' package module >reference also needs to be removed. > >Maybe a better hint would be ... > >hint: Remove the reference to the pachage module that was not >hint: found and add `(use-package-modules virtualization)'. > > *** test3: 'NON EXISTANT (openssh) SERVICE MODULE specified' > >This has the same conceptual problem as test2 above. > >The error messages ... > >/root/ctest/test3:3:0: error: module (gnu services openssh) not found >hint: Try adding `(use-service-modules ssh)'. > >... are followed literally in test3.fix, which does not fix the >problem because the non-existant 'openssh' service module >reference also needs to be removed. > >Maybe a better hint would be ... > >hint: Remove the reference to the service module that was not >hint: found and add `(use-service-modules ssh)'. > >*** test4: "SERVICE MODULE (ssh) for openssh-service-type SERVICE >MISSING" > >A more helpful hint here ... > >/root/ctest/test4:46:19: /root/ctest/test4:46:19: openssh-service-type: >unbound variable >hint: Did you forget a `use-modules' form? > >... would be ... > >hint: Try adding `(use-service-modules ssh)'. > > *** > >VERSION INFO: > >74bea6a03 gnu: linux-libre: Update to 4.13.12. > >make check failed as reported in bug#29245 but I don't think those >errors affect what I am seeing here. > >TEST FILES: I saw that last hint today buveuse I misspelled a type name (dovecot-configurtation). I understand the hint is great when you forget to import a service module, but it's not so great when the error is misspelling. Maybe the solution would be: if the unbound variable is the name of a service, propose using that module, otherwise don't show any hint.
Re: GuixSD on armhf.
Mathieu Othacehe writes: > Hi Ludo, > >> IOW, a service that starts a GuixSD VM for another architecture. >> >> Thoughts? > > Thanks for this patch ! For now I'm still trying to build a GuixSD image > directly on an armhf system. > > About that, i made some progress, but i'm now stuck on > "load-in-linux-vm" part of system generation. This part is starting a > qemu machine, inside the qemu machine i'm using for this dev. It takes > about half an hour, just to boot ! > > Does anyone know how could I speed this up, by buying or renting a > powerful arm machine ? by skipping somehow load-in-linux-vm part ? > > Thanks, > > Mathieu I may be totally out of context here, but I'll just mention that we apparently have some procedures for running builders in "containers" rather than a qemu virtual machine. Perhaps you can avoid one of those load-in-linux-vm calls by running something in a container instead. Check out: guix/gnu/build/linux-container.scm guix/gnu/system/linux-container.scm You might find something you can use. -- Chris signature.asc Description: PGP signature
Re: Uninstalling a "unknown" package installs new stuff -> totally unexpected
Hartmut Goebel writes:
> I've build a vm-image using my development environment ("./pre-inst-env
> guix system vm-image …"). Now within the VM I have
>
> - guix 0.13.0-8.357ab93,
>
> - kdelibs4support 5.39.0,
>
> - plasma-nm 5.11.2.
>
> The installed guix differs from the one used to build the vm-image
> (modified commit 9ae29fc0e): The later defines some version of guix
> (0.13.0-8.357ab93) which will go into the vm-image. This means, the
> installed guix does not know the new package plasma-nm and for
> kdelibs4support is known 5.37 (while 5.39 is installed).
Indeed, this is true. You might find the following short email thread
interesting - it explains why this happens:
https://lists.gnu.org/archive/html/help-guix/2017-01/msg00010.html
Maybe you can work around this by using the "current-guix" variable that
Ludo mentioned? Although, also note that he mentions it's a bit of a
hack.
Anything that makes the version of Guix in the VM "closer" to the
version of Guix outside the VM will probably help reduce build times.
> Now when I try to uninstall plasma-nm (within the vm), guix starts
> downloading stuff. Esp. it starts with "binutils-bootstrap-0".
>
> # guix package --profile=/run/current-system/profile --remove plasma-nm
Yes, that happens because, as you know, the version of Guix installed in
the VM (call it G_vm) is older than the version of Guix that was used to
build the VM image (call it G_host). I wonder if using "current-guix",
as mentioned above, would cause G_vm and G_host to be identical. If so,
that might fix your problem. In theory, anything that allows G_vm to
approximate G_host (e.g., running "guix pull" in the VM) will probably
help make the build go faster.
It is surprising that G_vm is older than G_host, but it is not
surprising that, given that G_vm is older than G_host, G_vm will need to
build many things in order to remove a single package. Suppose you want
to remove a package p_1 from a profile in the VM that contains another
package p_2. The version of p_2 that is installed in the VM was built
by G_host. To remove p_1 from a profile means to build a new profile in
which p_1 is absent. To build a new profile in the VM which lacks p_1,
G_vm must build p_2. Assuming that the definition of p_2 has not
changed since the last profile was built, and assuming that none of the
definitions of p_2's dependencies has changed, when G_vm builds p_2 for
the new profile, the build will succeed quickly because the output of
p_2 is already a valid path in G_vm's store. However, if the definition
of p_2 or any of its dependencies has changed, then G_vm will need to
build all of them in order to build p_2 for the new profile. All of
this is necessary in order to build the next profile generation without
p_1. The reason that you are seeing so many builds is probably because
either many things changed between G_vm and G_host, or something deep in
the dependency tree changed between G_vm and G_host. Either way, G_host
did not build all the things that G_vm now needs in order to build a new
profile without p_1, so G_vm must build all of those missing things.
This is a natural result when G_vm is older than G_host.
> I would have expected guix to simply remove the links for the package
> from the profile.
Your expectation is totally understandable. However, due to the way in
which Guix builds a profile, removing symlinks is not as simple as it
sounds. When building a profile generation, it is sometimes necessary
to resolve symlink conflicts when two packages both provide the same
file - one file is chosen for inclusion in the profile, and the other is
left out. How should we "simply remove the link" in this case? It is
simpler and more functional (in the purely functional sense) to just
build an entirely new profile in which the removed package is not
present to begin with, and that is what Guix does.
It may be technically possible to implement a different profile
generation mechanism which allows the removal of a package by
"un-symlinking" it from a previous profile generation. However, if we
did that, it would mean that a profile generation might now depend on a
profile generation that came before it. That is not good because it
would make it harder to reproducibly build any given profile. It would
be better not to make profile generations depend on the state of the
profile generations that came before it. Since the problem here is that
it took much longer to build the new profile than you expected because
G_vm was older than G_host, I suspect that we can resolve the problem by
taking steps to bring G_vm "closer" to G_host, such as using
"current-guix" as mentioned above, or running "guix pull" in the VM.
> Whatever is happening here, guix should at least output some explanation
> to reduce the confusion.
Guix does say it's going to build a ton of things (I think). But right
after that, Guix spits out tons of build output. I rarely get a chance
to inspect it closely.
Re: parallelizing more actions
Efraim Flashner writes:
> While rebuilding glibc-final on aarch64 I realized that the 'strip
> phase took 235 seconds. The relevant code for 'strip from
> gnu-build-system is in guix/build/gnu-build-system.scm, starting at
> line 340, with the actual stripping starting at 398. When I changed
> 'for-each' to 'par-for-each' the time dropped from 235 seconds to 215,
> about an 8.5% savings. I'm pretty sure most of that time was spent
> failing to strip certain files, but it is still a savings.
Nice!
>
> I'm guessing there are other parts that can be parallelized in a
> similar manner.
>
> As for par-for-each (as many threads as cores on the machine) vs
> n-par-for-each (n threads), I think it would be better to use
> n-par-for-each, but I didn't quickly see a way to limit based on the
> number of cores offered to each builder.
I think you want parallel-job-count in (guix build utils):
(define parallel-job-count
;; Number of processes to be passed next to GNU Make's `-j' argument.
(make-parameter
(match (getenv "NIX_BUILD_CORES") ;set by the daemon
(#f 1)
("0" (current-processor-count))
(x (or (string->number x) 1)
--
Chris
signature.asc
Description: PGP signature
Re: [PATCH 6/6] gnu: Improve error reporting of the use-.*modules macros.
Hi Ludo, Ludovic Courtès writes: > +(define-syntax-rule (try-use-modules hint modules ...) > + (eval-when (expand load eval) > +(%try-use-modules '(modules ...) > + (source-properties->location > + (current-source-location)) > + hint))) > + Why is it necessary to use eval-when here? The Guile manual makes it sound like eval-when is intended to be used with syntax-case macros, not syntax-rules macros. -- Chris signature.asc Description: PGP signature
Re: Emacs minor-mode highlight code stages (gexp & sexp)
Oleg Pykhalov writes: > Hello Guix, > > I found Emacs minor-mode for highlighting stages of code and send a > request for release a tarball¹, so I could package it properly. > > > Also I made a fork to add a support for G-Expressions and I will wait > until close a request¹ before sending a patch. You could try it now: > > $ git clone https://github.com/wigust/highlight-stages.git -b gexp > $ cd CLONED_REPOSITORY_DIRECTORY > $ guix package --install-from-file=guix.scm > > > ¹ https://github.com/zk-phi/highlight-stages/issues/10 > > Oleg. Aw man, that's cool! I didn't know this was a thing. I love it already. I've only used it for about 5 minutes now, but I have one question: is it possible to highlight gexps using a different color than other "staged" code? For example, it's a little strange that in gnu/system/vm.scm, in procedure expression->derivation-in-linux-vm, the quoted module list passed to source-module-closure is highlighted the same color as the following gexp. As I understand it, source-module-closure will take the closure of modules from the host environment and make it available in the store on the build side, so it seems to me like this list of modules should not be highlighted as build-side code. I like that it highlights quoted expressions in addition to gexps, but it would be even better if there were two color "families" here: one for gexps (red, pink, salmon, etc. for different levels of gexps), and one for regular quotes (blue, light blue, lilac, etc). That way, it would be easy to tell different stage levels apart, and it would also be easy to tell different types of code staging apart. What do you think? Too much? I've also noticed that the highlighting breaks down when using ungexp-splicing inside of quasiquote inside of gexp. For example, look at gnu/tests/install.scm. In run-install, after the first #~(begin, you will find the following line: `(,(which #$(qemu-command system)) This line introduces a new level (shade) of highlighting. I do see that #$(qemu-command system) is correctly highlighted as host-side code (gray for me, like most of the lines outside the gexp). However, farther down, on these lines, the highlighting seems to be incorrect: #$@(cond ((string=? "ext4" installation-disk-image-file-system-type) Here, I believe that the expression following #$@ (the short form of ungexp-splicing) should also be highlighted gray, since it is host-side code. However, it is highlighted the same color as the rest of the build-side code in the gexp. I believe this is happening because it occurred within the quasiquote form, and the highlighting logic doesn't realize that #$@ took us back out two levels instead of just one. -- Chris signature.asc Description: PGP signature
Re: Uninstalling a "unknown" package installs new stuff -> totally unexpected
Chris Marusich writes: > It may be technically possible to implement a different profile > generation mechanism which allows the removal of a package by > "un-symlinking" it from a previous profile generation. However, if we > did that, it would mean that a profile generation might now depend on a > profile generation that came before it. I'd like to correct something I said in my last reply. I just remembered that we have a declarative description of what is installed in a profile at $PROFILE/manifest. In my last email, I may have incorrectly described what happens during the removal of a package. Judging by the code in guix/profiles.scm, it looks like we actually do re-use the existing store items that are referenced by the previous profile generation. Packages won't be upgraded unless you explicitly ask for it (e.g., with the "-u" option). So, when G_vm removes p_1 from the profile (i.e., when G_vm builds a new profile in which p_1 is not present), G_vm will in fact re-use the same package versions in the new generation that were installed in the previous generation. When I suggested that the builds you were seeing occurred because G_vm would want to build newer versions of all the packages, I believe was mistaken - I apologize for any confusion I may have caused. That said, I still think it's true that if G_vm is very different than G_host, it is likely that G_vm will wind up doing a lot of builds for things that G_host has "already" built (but which aren't installed in the profile itself). Guix uses derivations to do a lot of stuff under the covers, so I think this is likely to occur when G_vm and G_host are very different. -- Chris signature.asc Description: PGP signature
