Re: Building Docker images of GuixSD
Hi Chris, I've run GuixSD in a Docker container and returned to tell the tale! Congratulations! And thanks for exploring all this. > Is this helpful? Is it worth polishing up and maintaining? I'm not > entirely sure, and I'd like to know what you think. I think it is useful, mainly for reason 3: * If you want to run Guix on a system to which Guix hasn't been ported (like macOS) but your system does run Docker, now you can run Guix on that system by running it from a GuixSD Docker container. To which I might add a less obvious one: with GuixSD nicely integrated into the Docker universe, it has a better chance of adoption by people committed to Docker, and thus a better chance of becoming a/the preferred way of constructing Docker images. In other words, an attempt to take over the (Docker) world from inside. For the third bullet point, I don't know of any other reasonable way to get Guix working in Docker (although one could certainly run Guix in a VM using a technology other than Docker, such as QEMU). To run Guix, I have been trying this approach for a while, but I am still much further away from running Guix on my Mac than you are. First, QEMU: forget it on the Mac. It's not nearly as advanced/stable as it is under Linux. You can run Guix with QEMU under macOS, but it's slow and crashes a bit too often to rely on it. I moved on to VirtualBox, which runs a basic GuixSD without any major problem. But what you get is an isolated virtual machine. I haven't yet found a usable strategy for accessing the macOS file system from GuixSD. VirtualBox relies on its proprietary guest OS add-ins. I suspect they could be ported to GuixSD from a technical point of view, but it's not a trivial job and you'd have to remove the term "free software" from your brain for a while to do it. Currently I am trying NFS, exporting my Mac home directory via an NFS server on the Mac (easy) and mounting it from GuixSD (no success so far, because of the very incomplete NFS support in GuixSD). I expect this will work eventually, but in terms of performance it will probably never get to what you can achieve with Docker. Konrad.
ATI radeon + modesetting
Hi, I just upgraded my desktop machine for the first time in about 3 months. It has this graphics card from about 5 years ago: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 7570] After the upgrade, I was experiencing horrible tearing and corrupted graphics. (I do install the binary firware blobs, for what that's worth, but that wasn't the source of the problem.) This reminded me of something I had experienced in the past with Intel on laptops, though with less intense effects: https://bugs.freedesktop.org/show_bug.cgi?id=101620 The ultimate problem in that case was that when running an OpenGL-enabled composited window manager like gnome-shell, some updates would not be synchronized to the display. There were various things you could do to ungarble the display on the application level, but it was very irritating. The origin of the problem is that the synchronization facilities exposed by OpenGL / GLX weren't playing well with the acceleration architecture in the Intel xorg driver. To explain this, some background follows. Historically there were different acceleration paths for 2D and 3D graphics on Linux/X. Some graphics people work to accelerate 3D, and some do 2D. If you have an intel card you might remember XAA, EXA, UXA, SNA, etc; those are all 2d acceleration paths. Now these days there is convergence to accelerate 2D in terms of 3D -- i.e. translate 2D operations to 3D operations, as much as possible. Then you just need to have one good generic 3d acceleration backend. The new "modesetting" xorg driver is just that: a generic xorg graphics driver incorporating a generic 2D-in-terms-of-OpenGL acceleration architecture called "glamor". The modesetting xorg driver needs basic facilities from the kernel to get the card into the right mode, then it can hook into the card-specific support for OpenGL/etc provided by Mesa. One of these kernel facilities is called "modesetting", hence the name of the driver. Glamor and the modesetting driver are now shipped as part of the X server itself, not as separate modules. Switching from the Intel driver to the modesetting driver was thus a switch from a separate 2D and 3D accel path to a unified path. Additionally, the 2d accel path in the intel driver was not very well maintained. There had been no release of xf86-video-intel for a couple years; distros that used that driver (a dwindling number; Debian switched over last year) used Git snapshots. The "SNA" acceleration architecture that the Intel devs came up with was indeed fast, but had some problems that couldn't be resolved related to buffer synchronization. Normally SNA worked fine but for some reason emacs under a composited WM exhibited corruption, so in guix we switched back to UXA, an earlier 2D accel architecture, but that was quite slow. So in c68c201fdd429140da1c606861c9296b9cb01265, we switched over to prefer the modesetting driver for Intel cards that are recent enough to have enough OpenGL support for the glamor pipeline to be usable. Recalling all of this history, I thought that perhaps a switch to modesetting could fix my radeon problems as well, and indeed, voilà, this patch fixes it: --- a/gnu/services/xorg.scm +++ b/gnu/services/xorg.scm @@ -117,7 +117,7 @@ Section \"Files\" FontPath \"" font-adobe75dpi "/share/fonts/X11/75dpi\" ModulePath \"" xf86-video-vesa "/lib/xorg/modules/drivers\" ModulePath \"" xf86-video-fbdev "/lib/xorg/modules/drivers\" - ModulePath \"" xf86-video-ati "/lib/xorg/modules/drivers\" + # ModulePath \"" xf86-video-ati "/lib/xorg/modules/drivers\" ModulePath \"" xf86-video-cirrus "/lib/xorg/modules/drivers\" ModulePath \"" xf86-video-intel "/lib/xorg/modules/drivers\" ModulePath \"" xf86-video-mach64 "/lib/xorg/modules/drivers\" Removing the ATI driver from the X server makes modesetting the "best" available driver; from Xorg.0.log: [ 465.481] (==) Matched ati as autoconfigured driver 0 [ 465.483] (==) Matched ati as autoconfigured driver 1 [ 465.485] (==) Matched modesetting as autoconfigured driver 2 [ 465.487] (==) Matched fbdev as autoconfigured driver 3 [ 465.489] (==) Matched vesa as autoconfigured driver 4 [ 465.491] (==) Assigned the driver to the xf86ConfigLayout [ 465.491] (II) LoadModule: "ati" [ 465.494] (WW) Warning, couldn't open module ati [ 465.494] (II) UnloadModule: "ati" [ 465.494] (II) Unloading ati [ 465.498] (EE) Failed to load module "ati" (module does not exist, 0) [ 465.498] (II) LoadModule: "modesetting" [ 465.500] (II) Loading /gnu/store/2ka3fa3rkxglhn88pqfv8gpcw0ai8fjk-xorg-server-1.19.5/lib/xorg/modules/drivers/modesetting_drv.so [ 465.502] (II) Module modesetting: vendor="X.Org Foundation" [ 465.502]compiled for 1.19.5, module version = 1.19.5 [ 465.504]Module class: X.Org Video Driver [ 465.504]ABI class: X.Org Video Driver, version 23.0 I think I would like to ap
parallelizing more actions
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. 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. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm index e37b75140..3162ec08b 100644 --- a/guix/build/gnu-build-system.scm +++ b/guix/build/gnu-build-system.scm @@ -24,6 +24,7 @@ #:use-module (ice-9 match) #:use-module (ice-9 regex) #:use-module (ice-9 format) + #:use-module (ice-9 threads) #:use-module (srfi srfi-1) #:use-module (srfi srfi-19) #:use-module (srfi srfi-26) @@ -395,24 +396,24 @@ makefiles." (format #t "debugging output written to ~s using ~s~%" debug-output objcopy-command)) -(for-each (lambda (file) -(and (or (elf-file? file) (ar-file? file)) - (or (not debug-output) - (make-debug-file file)) - - ;; Ensure the file is writable. - (begin (make-file-writable file) #t) - - (zero? (apply system* strip-command - (append strip-flags (list file - (or (not debug-output) - (add-debug-link file - (find-files dir - (lambda (file stat) -;; Ignore symlinks such as: -;; libfoo.so -> libfoo.so.0.0. -(eq? 'regular (stat:type stat))) - #:stat lstat))) +(par-for-each (lambda (file) +(and (or (elf-file? file) (ar-file? file)) + (or (not debug-output) + (make-debug-file file)) + + ;; Ensure the file is writable. + (begin (make-file-writable file) #t) + + (zero? (apply system* strip-command + (append strip-flags (list file + (or (not debug-output) + (add-debug-link file + (find-files dir + (lambda (file stat) +;; Ignore symlinks such as: +;; libfoo.so -> libfoo.so.0.0. +(eq? 'regular (stat:type stat))) + #:stat lstat))) (or (not strip-binaries?) (every strip-dir signature.asc Description: PGP signature
Emacs minor-mode highlight code stages (gexp & sexp)
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.
Re: Performance regression on NFS with new manifest version
Roel Janssen skribis:
> Indeed, here's a new strace, without using 'guixr', but instead using
> 'guix' with 'guix-daemon' listening on a TCP port:
>
> $ time strace -c guix package --search-paths -p /gnu/profiles/per-language/r
>
>
> export PATH="/gnu/profiles/per-language/r/bin"
> export R_LIBS_SITE="/gnu/profiles/per-language/r/site-library/"
> export TERMINFO_DIRS="/gnu/profiles/per-language/r/share/terminfo"
> % time seconds usecs/call callserrors syscall
> -- --- --- - -
> 30.150.010014 30 334 162 open
> 24.380.008100 5 1518 1285 stat
> 23.290.007738 9086 read
> 11.210.003723 12 31474 futex
> 2.990.000994 5 220 mmap
> 2.490.000826 5 175 mprotect
> 1.230.000407 2 175 close
> 0.720.000238 466 fstat
> ...
> -- --- --- - -
> 100.000.033219 3335 1535 total
>
> real1m12.196s
> user1m10.090s
> sys 0m0.377s
>
> So, I don't think the real issue is on display here, because strace only
> thinks the command took 0.033219 seconds, but it actually too 78.196
> seconds.
The timings above suggest that it’s mostly CPU time, which could be a
computational problem within Guix.
Unfortunately, I cannot reproduce it locally:
--8<---cut here---start->8---
$ guix package -p foo -i r $(guix package -A '^r-' |cut -f1|grep -v
bsgenome|head -100)
[...]
Creating manual page database for 4 packages... done in 0.038 s
pakoj 101 en profilo
La jenaj medi-variablaj difinoj povos esti necesaj:
export PATH="foo/bin${PATH:+:}$PATH"
export R_LIBS_SITE="foo/site-library/${R_LIBS_SITE:+:}$R_LIBS_SITE"
$ time guix package -p foo --search-paths
export PATH="foo/bin"
export R_LIBS_SITE="foo/site-library/"
real0m1.569s
user0m1.602s
sys 0m0.008s
$ guix package -p foo -I | wc -l
101
--8<---cut here---end--->8---
Could you try to isolate the problem in a way that I can reproduce it?
Maybe you can first try the same profile on a laptop with a local file
system and local guix-daemon.
Also, you may want to use ‘time’ without ‘strace’ to make sure we’re not
measuring the run-time overhead of ‘strace’.
TIA!
Ludo’.
Re: Let's build 'core-updates'!
Heya! I’ve started an evaluation of the “core” subset of packages for ‘core-updates’: https://hydra.gnu.org/jobset/gnu/core-updates#tabs-evaluations Let’s see how it goes. Ludo’.
Uninstalling a "unknown" package installs new stuff -> totally unexpected
Hi,
TL;DR: Removing packages makes to guix behave *totally* unexpected. guix
should at least output some explanation to reduce the confusion.
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).
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
I would have expected guix to simply remove the links for the package
from the profile. Even for me a an somewhat experienced user this is
*totally* unexpected. IMHO is crazy, since the system is running already
and FMPOV there is *nothing* todo but removing some links from the profile.
I would have had some (even little) acceptance for this behavior, *if*
I'd removed kdelibs4support, since kdelibs4support has some other
referrers, which *might* have some other effects. But for plasma-nm,
this is unexpected.
Whatever is happening here, guix should at least output some explanation
to reduce the confusion.
# guix gc --referrers /gnu/store/…-plasma-nm-5.11.2
/gnu/store/…-profile
/gnu/store/…-plasma-nm-5.11.2
# guix gc --referrers /gnu/store/…-kdelibs4support-5.39.0/
/gnu/store/…-plasma-desktop-5.11.2
/gnu/store/…-kdelibs4support-5.39.0
/gnu/store/…-profile
/gnu/store/…-khotkeys-5.11.2
/gnu/store/…-kdeplasma-addons-5.11.2
/gnu/store/…-plasma-nm-5.11.2
/gnu/store/…-kmenuedit-5.11.2
/gnu/store/…-plasma-workspace-5.11.2
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Best-practice to "develop" a system-config / service?
Hi,
TL;DR: How do I get my in-development version of guix into the VM build
with this version?
I made KDE Plasma start up in a VM by adding tons of packages to the
system declaration (to be on the save side). Now for finishing and
providing a nice service declaration I need to strip this list of
packages down to the bare minimum.
Since a vm (sharing the host store) is unacceptable sloow, I've
build a vm-image using my development environment ("./pre-inst-env guix
system vm-image …"). Now within the VM-image there is a different
version of guix installed than the in-development one I used for
building the VM. Of course the former one does not know any of the
packages I've just added. So I can't not just run "guix system
reconfigure …".
After some luckless tries I assume the easiest solution would be to get
my in-development version of guix into the VM. How to achieve this?
What I've tried:
0) Using a VM sharing the host store: Here starting Plasma takes 2
minutes, which is not acceptable for series of tests.
1) My first idea was to share my development directory with the VM and
run "./pre-inst-env guix system reconfigure …" from within the VM. This
failed with
./pre-inst-env: …/scripts/guix: /gnu/store/…-profile/bin/guile: bad
interpreter: No such file or directory
Well, yes. within the VM, my external profile is not available :-(
2) Changing the patch in …/scripts/guix into
/run/current-system/profile/bin/guile failed with
/gnu/store/…-libgcrypt-1.8.1/lib/libgcrypt
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
0xBF773B65.asc
Description: application/pgp-keys
GuixSD on armhf.
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
Re: Let’s meet before FOSDEM!
Just a quick update to all. Friday is on, we already have one or two potential venues. It'll get sorted. Book your flights/trains/trainers! On Wed, Nov 08, 2017 at 02:57:03PM +0100, Ludovic Courtès wrote: > Efraim Flashner skribis: > > > I should be able to make it again this year. Assuming I'm taking the > > same flight as last time I'll be in Brussels by about 5am. I'm not > > suggesting that we start that early, but depending on what everyone else > > is doing we could aim to have the talks/presentations when we have the > > most number of people and then have time before and after for hacking. > > I think we could aim for ~9am for the beginning. 5am is a bit too > early. ;-) > > Ludo’. --
isc-bind service draft
Hello Guix,
I work on isc-bind service. Currently generation of named.conf is done.
Ideas and suggestions are welcome! :-)
(define-record-type*
bind-options-configuration make-bind-options-configuration
bind-options-configuration?
(user bind-options-configuration-user ; string
(default "bind"))
(groupbind-options-configuration-group ; string
(default "bind"))
(run-directorybind-options-configuration-run-directory ; string
(default "/var/run/bind"))
(pid-file bind-options-configuration-pid-file ; string
(default "/var/run/bind/named.pid"))
(listen-v4bind-options-configuration-listen-v4 ; string
(default "0.0.0.0"))
(listen-v6bind-options-configuration-listen-v6 ; string
(default "::"))
(listen-port bind-options-configuration-listen-port ; integer
(default 53))
(allow-recursion? bind-configuration-allow-recursion? ; list
(default (list "127.0.0.1")))
(allow-transfer? bind-configuration-allow-transfer? ; list
(default (list "none")))
(allow-update?bind-configuration-allow-update? ; list
(default (list "none")))
(version bind-configuration-version ; string
(default "none"))
(hostname bind-configuration-hostname ; string
(default "none"))
(server-idbind-configuration-server-id ; string
(default "none")))
(define (bind-configuration-statement-string statements)
(string-join (list "{" (string-join statements ";\n") "}")))
(define-record-type*
bind-zone-configuration make-bind-zone-configuration
bind-zone-configuration?
(network bind-zone-configuration-network ; string
(default '()))
(class bind-zone-configuration-class; string
(default '()))
(typebind-zone-configuration-type ; string
(default '()))
(filebind-zone-configuration-filename ; string
(default '(
(define-record-type*
bind-configuration-file make-bind-configuration-file
bind-configuration-file?
;;
(config-options bind-configuration-file-config-options
(default (bind-options-configuration)))
;; list of
(config-zones bind-configuration-file-config-zones
(default (list (bind-zone-configuration
(network "localhost")
(class "IN")
(type"master")
(file"localhost.zone"))
(bind-zone-configuration
(network "0.0.127.in-addr.arpa")
(class "IN")
(type"master")
(file"127.0.0.zone"))
(bind-zone-configuration
(network (string-append "1.0.0.0.0.0.0.0.0.0."
"0.0.0.0.0.0.0.0.0.0."
"0.0.0.0.0.0.0.0.0.0."
"0.0.ip6.arpa"))
(class "IN")
(type"master")
(file"localhost.ip6.zone"))
(bind-zone-configuration
(network "255.in-addr.arpa")
(class "IN")
(type"master")
(file"empty.zone"))
(bind-zone-configuration
(network "0.in-addr.arpa")
(class "IN")
(type"master")
(file"empty.zone"))
(bind-zone-configuration
(network ".")
(class "IN")
(type"master")
(file"root.hint"))
(define-record-type*
bind-configuration make-bind-configuration
bind-configuration?
(config-file bind-configuration-config-file
(default (bind-configuration-file)))
(package bind-configuration-package ;
(default bind)))
(define-syntax option
(syntax-rules ()
((_ key value) (if value
(list "" (string-join (list key value)) ";" "\n")
'()
(define-syntax key/value
(syntax-rules ()
((_ (key value) rest ...)
(append (opti
Re: [PATCH 0/6] Error reporting and hints for missing modules
Hello, myglc2 skribis: > I built and played with this. I see you also provide a search hint when > you don't find an obvious match, as in ... > > sys.scm:3:0: error: module (gnu services sshx) not found > hint: You may use `guix system search sshx' to search for a service matching > `sshx'. If you get the line `location: gnu/services/foo.scm:188:2', add > `foo' to the `use-service-modules' > form. 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! https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a2985bb101faac9f085176e0329488b91b81dfb5 Ludo’.
Re: Best-practice to "develop" a system-config / service?
Hartmut Goebel writes:
> Hi,
>
> TL;DR: How do I get my in-development version of guix into the VM build
> with this version?
>
> I made KDE Plasma start up in a VM by adding tons of packages to the
> system declaration (to be on the save side). Now for finishing and
> providing a nice service declaration I need to strip this list of
> packages down to the bare minimum.
>
> Since a vm (sharing the host store) is unacceptable sloow, I've
> build a vm-image using my development environment ("./pre-inst-env guix
> system vm-image …"). Now within the VM-image there is a different
> version of guix installed than the in-development one I used for
> building the VM. Of course the former one does not know any of the
> packages I've just added. So I can't not just run "guix system
> reconfigure …".
>
> After some luckless tries I assume the easiest solution would be to get
> my in-development version of guix into the VM. How to achieve this?
>
>
> What I've tried:
>
> 0) Using a VM sharing the host store: Here starting Plasma takes 2
> minutes, which is not acceptable for series of tests.
>
> 1) My first idea was to share my development directory with the VM and
> run "./pre-inst-env guix system reconfigure …" from within the VM. This
> failed with
>
> ./pre-inst-env: …/scripts/guix: /gnu/store/…-profile/bin/guile: bad
> interpreter: No such file or directory
Running `./configure` again inside the VM should make it pick up
available versions of Guile and other dependencies. Will that work?
Another approach you might find useful is writing a "system test" that
starts a Plasma desktop. Look in (gnu tests) for inspiration. This has
the added benefit that we will notice early if KDE breaks.
Hope this helps!
signature.asc
Description: PGP signature
Re: diverse double compilation: using $ORIGIN?
Ricardo Wurmus writes: > Since the GCC build procedure is performed at least two > times (once with the bootstrap compiler, and then again with the GCC > variant this produces), the resulting GCC binaries should be identical. > > Except that they are not. One of the reasons is that the binaries > that Guix produces embed the target output directories. This means > that the two compiler binaries that result from diverse double > compilation will *always* differ in at least the embedded paths, such > as paths to itself (e.g. to binaries in the libexec directory) and > paths to. What ever happened to the intensional model (i.e., a content-addressed store)? If derivation outputs were content-addressed, this would not be a problem, right? Dolstra's thesis presented some ideas for how to rewrite self-references in derivation outputs under the intensional model. I've casually looked into what happened with the intensional model since his thesis was written, but I don't really know why it hasn't been implemented. All I know is that Dolstra and the Nix devs seem to have moved away from that idea; I never really learned the reason(s) why. -- Chris signature.asc Description: PGP signature
Re: Changing HTTP proxy settings in GuixSD
Konrad Hinsen writes:
>> A quick workaround would be to do something along these lines:
>>
>># herd stop guix-daemon
>># http_proxy=… guix-daemon --build-users-group=guixbuild
>># guix system reconfigure config.scm
>>
>> where config.scm has the relevant proxy configuration of in
>> ‘guix-configuration’.
>>
>> Would that work for you?
>
> No. Downloads fail with messages of the type
>
> ERROR: Wrong type to apply: "mirror.hydra.gnu.org"
>
> This looks like the proxy returns something that guix-daemon doesn't
> expect. Unfortunately, this may well be the fault of my institutions
> proxy, which has caused lots of people lots of trouble of various
> kinds.
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"
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. If it isn't, then can I ask to see the
commands and conigs you're using which fail?
--
Chris
signature.asc
Description: PGP signature
EOMA68-A20 preproduction unit for dev work
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 pgpbAqtWqOtYZ.pgp Description: OpenPGP digital signature
