Re: Problems running 'check-system'
l...@gnu.org (Ludovic Courtès) writes: > Hi Chris, > > Chris Marusich skribis: > >> I think I might have finally found the reason. When I remove the >> "--pure" from the invocation, the "installed-os" test runs successfully >> on my GuixSD machine. It seems that, for some reason, "--pure" was the >> cause of the failure. That's surprising to me, since my expectation was >> that Guix's tests should work just fine in a pure environment. Could >> this be a bug? > > When using ‘--pure’, there’s no ‘git’ command in $PATH. So my guess > would be that this changes the content of (current-guix), which uses > ‘git-predicate’. > > In particular, your ‘current-guix’ package ends up including > guile-2.0.9.tar.xz file, because it cannot determine that it’s not under > version control, and then the build process of the ‘guix’ package fails > because this file already exists and is read-only. > > QED! :-) > > That’s a limitation of ‘git-predicate’ in its current form. Eventually > we’ll require ‘guile-git’ and we won’t have that problem. > > In the meantime, the workaround is to add Git to your environment: > > guix environment guix --ad-hoc git --pure > > Thanks for debugging it, and I HTH! > > Ludo’. You're right. The test passed when I added "--ad-hoc git". Your explanation makes sense. Thank you for bearing with me and taking the time to help me figure this out! -- Chris signature.asc Description: PGP signature
Re: "Perfect Setup" for hacking on Nix?
l...@gnu.org (Ludovic Courtès) writes: > Hi, > > Chris Marusich skribis: > >> I asked on nix-dev, and the (limited) response was basically that you >> should use whatever works best for you: >> >> https://mailman.science.uu.nl/pipermail/nix-dev/2017-April/023416.html >> >> I guess that means I should look into a C++ IDE (Eclipse?) or the emacs >> ecosystem for C/C++. > > Yeah. As Thomas wrote, Semantic (part of Emacs) or KDEvelop are your > best bets. > > But fundamentally, C++ doesn’t lend itself to live coding the way Lisp > does, so you’ll probably never have an environment close to the > Emacs/Geiser combo. Oh yeah, thank you for reminding me about Semantic and KDEvelop. I'll check those out. Thank you for the recommendations! -- Chris signature.asc Description: PGP signature
Recent change in 'guix package --search-paths' behavior?
Hi, The manual says ((guix) Invoking guix package): --8<---cut here---start->8--- This option can also be used to compute the _combined_ search paths of several profiles. Consider this example: $ guix package -p foo -i guile $ guix package -p bar -i guile-json $ guix package -p foo -p bar --search-paths The last command above reports about the ‘GUILE_LOAD_PATH’ variable, even though, taken individually, neither ‘foo’ nor ‘bar’ would lead to that recommendation. --8<---cut here---end--->8--- I've tried this just now, and the command says nothing about the GUILE_LOAD_PATH: --8<---cut here---start->8--- $ guix package -p foo -p bar --search-paths export PATH="foo/bin" --8<---cut here---end--->8--- Is the documentation wrong, or is this a regression? -- Chris signature.asc Description: PGP signature
Re: Heads-up: transition to Guile 2.2
Hi, myglc2 skribis: > I run GuixSD from git checkout this way ... > > cd ~/src/guix > guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \ > -c 4 > git pull > make clean-go > ./bootstrap > ./configure --localstatedir=/var --sysconfdir=/etc > make -j 10 check > exit > sudo guix system build /root/con/55.scm -M 4 -c 4 > sudo guix system reconfigure /root/con/55.scm -M 4 -c 4 > sudo reboot > > Should this just work? Or is there something that needs to be done > differently for the 2.0 >>> 2.2 change? That should just work. The only issue you might have is warnings about invalid .go files if ~/.config/guix/latest contains 2.0 .go files and you’re running Guile 2.2. The fix is to run ‘guix pull’. Ludo’.
Re: Recent change in 'guix package --search-paths' behavior?
Chris Marusich skribis: > Hi, > > The manual says ((guix) Invoking guix package): > > This option can also be used to compute the _combined_ search paths > of several profiles. Consider this example: > > $ guix package -p foo -i guile > $ guix package -p bar -i guile-json > $ guix package -p foo -p bar --search-paths > > The last command above reports about the ‘GUILE_LOAD_PATH’ > variable, even though, taken individually, neither ‘foo’ nor ‘bar’ > would lead to that recommendation. [...] > Is the documentation wrong, or is this a regression? Try with “guile2.2-json” instead of “guile-json”. Ludo’.
Simplified release process
Hello Guix! The release process as documented in doc/release.org was terrible because it involved a lengthy sequence of error-prone manual steps. Commit 334dce145122683e576ca4cb6c68c360d4aada7e adds a ‘release’ makefile target. “make release” produces the source tarball, the binary tarballs, and the GuixSD installation images, which can then be directly uploaded. Offloading must be set up to build binary tarballs for all the architectures. This involves building Guix a couple of times for each architecture so it takes time. *If* Guix’s build process is deterministic, that’s OK, though it seems that Guix occasionally fails to build in a non-deterministic fashion (that was the case with Guile 2.0 in part due to non-thread-safe ports I think; 2.2 has thread-safe ports, so it might be better.) Anyway, I would welcome feedback especially from you Ricardo since you felt the pain before. :-) An easy way to test is by building for a single architecture: make release -j4 SUPPORTED_SYSTEMS=x86_64-linux \ GUIXSD_SUPPORTED_SYSTEMS=x86_64-linux Note that this will make a couple of commits on your behalf, to update the ‘guix’ package, so be careful. I’m also interested in thoughts on how to automate other bits from the release process, though they are probably less critical: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org Ludo’. signature.asc Description: PGP signature
Re: Simplified release process
Ludovic Courtès writes: > Hello Guix! > > The release process as documented in doc/release.org was terrible > because it involved a lengthy sequence of error-prone manual steps. > > Commit 334dce145122683e576ca4cb6c68c360d4aada7e adds a ‘release’ > makefile target. “make release” produces the source tarball, the binary > tarballs, and the GuixSD installation images, which can then be directly > uploaded. Offloading must be set up to build binary tarballs for all > the architectures. Thank you so much! This is great! > Anyway, I would welcome feedback especially from you Ricardo since you > felt the pain before. :-) An easy way to test is by building for a > single architecture: > > make release -j4 SUPPORTED_SYSTEMS=x86_64-linux \ > GUIXSD_SUPPORTED_SYSTEMS=x86_64-linux > > Note that this will make a couple of commits on your behalf, to update > the ‘guix’ package, so be careful. I’m going to give this a try soon. > I’m also interested in thoughts on how to automate other bits from the > release process, though they are probably less critical: > > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org I’ll take a look at this again after testing the release target. Thanks again for all the hard work! -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: I can not run 'guix pull', how to deal with
On 07/05/2017 11:36, Ludovic Courtès wrote: guix pull: error: build failed: some substitutes for the outputs of derivation `/gnu/store/d1qkv7x8ayi75qjlg7d5j5g1h7y4fl5p-make-boot0-4.2.1.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source I fixed it yesterday, let me know how that goes. There seems to be a reservoir of similar bugs. Here is the one I just ran into: hash mismatch in downloaded path `/gnu/store/q6rbp7s542jkhrhz04hsp2i60gw0h4as-python-2.7.12': expected aea4335a5e6d65a36ed74561b15f8242773c49110be30d8ab7b43590f0568e60, got 49b3fc5b436309b4d097ed3c84946d5cab742db6159d76f5ad7a1d7896a2760f fetching path `/gnu/store/9761yfpvyr1fcpjhry8pgb3f0k6kj8n4-sed-4.2.2'... killing process 3685 guix pull: error: build failed: some substitutes for the outputs of derivation `/gnu/store/wn2068qzbyh1v64dxxwbfjik7cjq0sji-python-2.7.12.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source Does hydra have any kind of self-checking mechanism? It would be nice if such issues would be resolved automatically. Konrad.
Re: Heads-up: transition to Guile 2.2
On 05/10/2017 at 14:05 Ludovic Courtès writes: > Hi, > > myglc2 skribis: > >> I run GuixSD from git checkout this way ... >> >> cd ~/src/guix >> guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \ >> -c 4 >> git pull >> make clean-go >> ./bootstrap >> ./configure --localstatedir=/var --sysconfdir=/etc >> make -j 10 check >> exit >> sudo guix system build /root/con/55.scm -M 4 -c 4 >> sudo guix system reconfigure /root/con/55.scm -M 4 -c 4 >> sudo reboot >> >> Should this just work? Or is there something that needs to be done >> differently for the 2.0 >>> 2.2 change? > > That should just work. > > The only issue you might have is warnings about invalid .go files if > ~/.config/guix/latest contains 2.0 .go files and you’re running Guile > 2.2. The fix is to run ‘guix pull’. Thanks, I did that and, as you suggested, I got warnings ... g1@g1 ~/src$ guix package -m g1.scm ;;; WARNING: loading compiled file /home/g1/.config/guix/latest/guix/ui.go failed: ;;; ERROR: In procedure load-thunk-from-memory: not an ELF file ;;; note: source file /home/g1/.config/guix/latest/guix/ui.scm ;;; newer than compiled /gnu/store/d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/lib/guile/2.2/site-ccache/guix/ui.go ... but I really didn't want to do a git pull. So I re-built guix. Bottom line: FWIW, I upgraded from 2.0 to 2.2 without 'guix pull' like this way ... cd ~/src/guix guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \ -c 4 git pull make clean-go ./bootstrap ./configure --localstatedir=/var --sysconfdir=/etc make -j 10 check exit sudo guix system build /root/con/55.scm -M 4 -c 4 sudo guix system reconfigure /root/con/55.scm -M 4 -c 4 sudo reboot cd ~/src/guix guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \ -c 4 make clean-go ./bootstrap ./configure --localstatedir=/var --sysconfdir=/etc make -j 10 check ;-) George
backup w/ duplicity borg attic bup?
I am looking for a command line de-duplicating backup tool. I will be using it between GuixSD, Guix/GNU/Linux, and MacOS. Based on what I see in gnu/packages/backup.scm and in https://brew.sh, duplicity, borg and attic seem like they could be good choices. I am also intrigued by bup (https://github.com/bup/bup), for which we don't have a package (yet). I would like to avoid python, but all of the above seem to use it ;-( Does anyone out have suggestions? TIA - George
Re: backup w/ duplicity borg attic bup?
> Does anyone out have suggestions? I use obnam (https://obnam.org/). It works well for me. However, obnam is also written in python. :-P
Re: backup w/ duplicity borg attic bup?
On Wed, May 10, 2017 at 03:52:32PM -0400, myglc2 wrote: > I am looking for a command line de-duplicating backup tool. I will be > using it between GuixSD, Guix/GNU/Linux, and MacOS. > > Based on what I see in gnu/packages/backup.scm and in https://brew.sh, > duplicity, borg and attic seem like they could be good choices. I don't think Attic is a good choice anymore; it's unmaintained for ~2 years and has critical data integrity and security bugs. Borg is the active fork. The Borg team is developing new features while also triaging the Attic bug tracker, although they've worked through most of those Attic bugs by now: https://github.com/borgbackup/borg/issues/5 I like Borg overall. I've restored from it many times now, and it's always worked. The developers are actively maintaining and improving the software, and there is even a commercial offering (rsync.net). It's a very similar backup paradigm to Tarsnap (snapshots composed of deduplicated encrypted chunks), although the key management is less advanced. I'm not familiar with Duplicity so I can't compare it to Borg.
Re: Heads-up: transition to Guile 2.2
On 05/10/2017 at 13:11 myglc2 writes: > On 05/10/2017 at 14:05 Ludovic Courtès writes: > >> Hi, >> >> myglc2 skribis: >> >>> I run GuixSD from git checkout this way ... >>> >>> cd ~/src/guix >>> guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \ >>> -c 4 >>> git pull >>> make clean-go >>> ./bootstrap >>> ./configure --localstatedir=/var --sysconfdir=/etc >>> make -j 10 check >>> exit >>> sudo guix system build /root/con/55.scm -M 4 -c 4 >>> sudo guix system reconfigure /root/con/55.scm -M 4 -c 4 >>> sudo reboot >>> >>> Should this just work? Or is there something that needs to be done >>> differently for the 2.0 >>> 2.2 change? >> >> That should just work. >> >> The only issue you might have is warnings about invalid .go files if >> ~/.config/guix/latest contains 2.0 .go files and you’re running Guile >> 2.2. The fix is to run ‘guix pull’. > > Thanks, I did that and, as you suggested, I got warnings ... > > g1@g1 ~/src$ guix package -m g1.scm > ;;; WARNING: loading compiled file /home/g1/.config/guix/latest/guix/ui.go > failed: > ;;; ERROR: In procedure load-thunk-from-memory: not an ELF file > ;;; note: source file /home/g1/.config/guix/latest/guix/ui.scm > ;;; newer than compiled > /gnu/store/d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/lib/guile/2.2/site-ccache/guix/ui.go > > ... but I really didn't want to do a git pull. So I re-built guix. > > Bottom line: FWIW, I upgraded from 2.0 to 2.2 without 'guix pull' like > this way ... > > cd ~/src/guix > guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \ > -c 4 > git pull > make clean-go > ./bootstrap > ./configure --localstatedir=/var --sysconfdir=/etc > make -j 10 check > exit > sudo guix system build /root/con/55.scm -M 4 -c 4 > sudo guix system reconfigure /root/con/55.scm -M 4 -c 4 > sudo reboot > > cd ~/src/guix > guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \ > -c 4 > make clean-go > ./bootstrap > ./configure --localstatedir=/var --sysconfdir=/etc > make -j 10 check Or maybe not. With your recent change, guix says it's 85 days old ... g1@g1 ~/src/guix$ guix package -i icecat guix package: warning: Your Guix installation is 85 days old. guix package: warning: Consider running 'guix pull' followed by 'guix package -u' to get up-to-date packages and security updates. [...] But I just did a git pull ... g1@g1 ~/src/guix$ git -C ~/.config/guix/latest describe v0.12.0-3681-gbc0e6c931 ... and my ~/.config/guix/latest points to it ... g1@g1 ~/src/guix$ stat ~/.config/guix/latest | grep File: File: /home/g1/.config/guix/latest -> /home/g1/src/guix/ ... and I did 'make' and 'git system reconfigure' & reboot so that guix claims it is the latest version ... g1@g1 ~$ guix --version guix (GNU Guix) 0.12.0.3681-bc0e6 So... is some part of my guix 85 days old? Or... there a problem with the new "days old" message? TIA - George
Re: Debugging info unavailability
Hello ng0, Sorry for the delayed reply! ng0 writes: > Maxim Cournoyer transcribed 1.0K bytes: > … >> >> What good is a substitute server if it doesn't hold the stuff I need >> >> *now*? :) On the other side, it really makes me want to look at GNUnet, >> >> which seems like the better long term solution. >> > >> > Though GNUnet doesn’t solve the fact that one needs a lot of CPU and >> > storage to build and store all this. :-) >> > >> >> I think what I meant was "integration of GNUnet with guix publish". >> Something which would allow anyone to effortlessly share what's been >> built on their machine with the other Guix users. A zero config kind >> of thing, with auto discovery of peers and available substitutes. >> >> I haven't researched much about GNUnet yet, but it seems it might be >> fit for that purpose. >> >> Maxim >> > > This has been addressed between 2013? and late 2015, and I'm about to > document my own > discussions, thoughts, and roadmap for this (gathered in the last 2 years). > In the sense of freedom of choice, I'd rather make this an opt-in (contrary > to what > my own position in discussions was before) so that I can make pragmaOS use > this and > those who would like to use it too. > The main roadblocker is 5 weeks - 5 months until a new GNUnet release, but > there's > some tasks to work on which can be quickly updated once we have released > GNUnet 0.11 > or which version number is decided upon. > If you are interested, I can CC you in the message update when I have > documented > the ideas (though they are 90% identical to the outcomes of the GSoC > discussions > of the past, thought about without knowing it has been discussed > before). Count me in. I'd like to learn more about GNUnet and any design ideas/known issues there might be to integrate 'guix publish' with it. > My basic idea without going too much into depth (I don't want to search my > papers): > > - following the ideas of pragmaOS, to first make GNUnet as easy as > possible to use and configure (the system service I'm working on) Shouldn't deploying GNUnet on Guix be as easy as adding a service to the system declaration (and maybe tweeking a few parameters) ? > - update the gnunet-guile bindings for HEAD of gnunet but work with 0.10.1 > for the > current version of the service [...] > I know from the meeting december of last year that Ludovic is sceptic about > GNUnet by now to some degree, and if I could decide on releases GNUnet would > now > have an -dev or -preview or whatever release. The amount of bugfixes which > happened > since 0.10.1 are just too much to keep 0.10.1 around, especially since the > compability > no longer works between nodes running 0.10.1 and ones running HEAD. > Is backward compatiblity absolutely necessary, given that this version has its share of problems and is fragmenting the network. I'd rather put efforts on making GNUnet 'next' working, and well. Also, why not packaging a GNUnet-next already in Guix? With only two bugs left to fix, it should already work rather well (maybe better?) compared to 0.10.1? Guix makes it easy to have multiple versions if we need -- let's make use of it! Maxim signature.asc Description: PGP signature
