Re: offload daemon
Ludovic Courtès writes: > James Richardson skribis: > >> James Richardson writes: >> >>> Ludovic Courtès writes: >>> Hello, James Richardson skribis: > I am trying to setup an offload daemon. > > I have everything setup correctly (I think ;) > > $ guix offload test completes successfully. > > The offload daemon is actually guix on a foreign distro (Debian sid in > this case). > > Neither guix running on top of a Debian (sid and jessie) nor guixsd seem > to even call out to the offload daemon. All boxen are 64. > > My /etc/guix/machines.scm is here > > (list (build-machine >(name "thor.lab01.jamestechnotes.com") >(system "x86_64-linux") >(host-key "ssh-ed25519 > C3NzaC1lZDI1NTE5IJf0ezYgeVFit40VJwaBEW1dGm2Xz+SHzVmib8IbN58y > root@thor") >(user "guix") >(speed 1.) >(private-key > (string-append (getenv "HOME") > "/.ssh/identity-for-guix" > > Is x86_64-linux the proper system type? Yes. There are several things to consider here. By default, guix-daemon creates a single job, so that single job will end up being built locally, unless you spawn, say, two “guix build” commands in parallel (the number of jobs is per client.) Running “guix-daemon --max-jobs=0” should force all builds to be offloaded: https://www.gnu.org/software/guix/manual/html_node/Invoking-guix_002ddaemon.html I *think* “guix build --max-jobs=0” should give the same result. Alternately, if you run “guix build --max-jobs=2”, presumably half of the builds will be offloaded. Let us know if that works for you. Ludo’. >>> >>> I have a permission problem somewhere, I think. If I run as root offload >>> works, otherwise it doesn't. Don't really know here to look from here. >> >> Hmm, I move the key pair to /tmp and set the perms to 644 and offloading >> works for my regular user... Not quite sure I understand why. > > The ‘guix offload’ command is invoked by guix-daemon as root. So when > it is invoked, (getenv "HOME") returns "/root" or similar. Could that > be the problem? > > HTH, > Ludo’. Well, I think there is an issue with the offload. I don't (yet) know guile well enough to understand the code to help :( Here is what I am finding: $ guix build blah seems to offload builds properly. $ guix package -i blah, guix package -u blah, and $ guix system reconfigure config.scm does not offload builds. Thanks, j-r
Re: Unable to upgrade packages
On Wed, May 24, 2017 at 08:05:52PM +0100, Niall Dooley wrote: > On 14 May 2017 at 17:42, Leo Famulari wrote: > > guix pull --fallback (requires a recent Guix) > > > > guix build --fallback > > /gnu/store/db91i1ahr08b9n7hcjj2mmr4a1648ggz-guix-latest.drv > > > > I picked that derivation file out of your log after "The following > > derivations will be built:". > > > > In either case, you'll build the missing package from source. > > So as I'm running Guix 20170414.08 I don't believe I have a recent > enough version for option 1. In any case, option 2 is still > unsuccessful for me too though Okay, if `guix pull --fallback` complains about not understanding '--fallback', then option 1 won't work. > I didn't record the output on this occasion. I suspect at this point I > did something wrong in my use of Guix. It would be great to get the output so we know what happened, but I understand if you don't want to take the time to run the command again. I doubt you did anything wrong, however. > Is there a way to cleanly remove and re-install Guix. I don't mind as > I only have a handful of packages installed. Removing these directories should do the trick: $ rm -r /gnu && rm -r /var/guix && rm -r /etc/guix There is also a symlink owned by each Guix user: $ rm ~/.config/guix/latest
Re: Unable to upgrade packages
Putting this back on the list as I mistakenly only hit reply in my last mail. I hope this okay. On 14 May 2017 at 17:42, Leo Famulari wrote: > On Sun, May 14, 2017 at 05:15:03PM +0100, Niall Dooley wrote: >> Hi Leo, >> >> Attached is the output when I try to run 'guix pull'. You'll see there >> is a 404 response. >> Thanks for your time. > > This substitute still returns 404 (checked with wget), so there are two > options: > > guix pull --fallback (requires a recent Guix) > > guix build --fallback > /gnu/store/db91i1ahr08b9n7hcjj2mmr4a1648ggz-guix-latest.drv > > I picked that derivation file out of your log after "The following > derivations will be built:". > > In either case, you'll build the missing package from source. > > I hope that helps! So as I'm running Guix 20170414.08 I don't believe I have a recent enough version for option 1. In any case, option 2 is still unsuccessful for me too though I didn't record the output on this occasion. I suspect at this point I did something wrong in my use of Guix. Is there a way to cleanly remove and re-install Guix. I don't mind as I only have a handful of packages installed. I raised this query on a separate thread as well so apologies for the noise particularly if this is not best practice on a mailing list. Thanks as always for your time. Niall
Re: Unable to use Aspell installed via Guix
>> Downloading >> https://mirror.hydra.gnu.org/guix/nar/gzip/nr0qaf4xihy08mh2d0jyfjk964hgbd01-libatomic-ops-7.4.4 >> (623KiB installed)... >> guix substitute: error: download from >> 'https://mirror.hydra.gnu.org/guix/nar/gzip/nr0qaf4xihy08mh2d0jyfjk964hgbd01-libatomic-ops-7.4.4' >> failed: 404, "Not Found" > > I can’t seem to reproduce this problem. > > How old is your Guix installation, or the last time since you run “guix > pull” (“guix --version” should report that)? > I'm running Guix 20170414.08. So I guess this reflects too the last time I ran "guix pull" successfully. > Can you try adding this flag to the ‘guix package’ command line: > > --substitute-urls=https://hydra.gnu.org > > ? It instructs Guix to bypass the mirror; does it make a difference? > No, it doesn't. I still get the following after some time. guix substitute: error: download from 'https://hydra.gnu.org/guix/nar/gzip/qp42nrg3vxvcswhvdkgis7lfmr8il8bw-netpbm-10.61.01-checkout' failed: 404, "Not Found" As it seems I'm the only user suffering this issue perhaps it is due to something I did in my (mis)use of Guix. Is there a straightforward way for me to cleanly remove Guix and re-install. I don't mind if this resolves my problem. I only have a handful of packages installed. Thanks, Niall
Re: Retrieving the OpenPGP key used to sign the release
Quiliro writes: > El Tue, 23 May 2017 22:24:38 +0200 > l...@gnu.org (Ludovic Courtès) escribió: > >> Quiliro skribis: >> >> > $ gpg --verify guixsd-usb-install-0.13.0.i686-linux.xz.sig >> > gpg: supozas subskribitajn datenojn en >> > 'guixsd-usb-install-0.13.0.i686-linux.xz' >> > gpg: Signature made lun 22 Maj 2017 07:51:35 -0500 ECT using RSA key ID >> > 3D9AEBB5 >> > gpg: Ne povas kontroli subskribon: publika ŝlosilo ne trovita >> > >> > $ gpg --keyserver keys.gnupg.net --recv-keys >> > 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 >> > gpg: requesting key 3D9AEBB5 from hkp server keys.gnupg.net >> > ?: keys.gnupg.net: Host not found >> > gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused >> > gpg: validaj OpenPGP-datenoj ne trovitaj. >> > gpg: Nombro traktita entute: 0 >> >> Oops, keys.gnupg.net seems to be retired. Please use >> pool.sks-keyservers.net instead, for example. > > How? Is that documented? Instead of gpg --keyserver keys.gnupg.net --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 use gpg --keyserver pool.sks-keyservers.net --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Retrieving the OpenPGP key used to sign the release
El Tue, 23 May 2017 22:24:38 +0200 l...@gnu.org (Ludovic Courtès) escribió: > Quiliro skribis: > > > $ gpg --verify guixsd-usb-install-0.13.0.i686-linux.xz.sig > > gpg: supozas subskribitajn datenojn en > > 'guixsd-usb-install-0.13.0.i686-linux.xz' > > gpg: Signature made lun 22 Maj 2017 07:51:35 -0500 ECT using RSA key ID > > 3D9AEBB5 > > gpg: Ne povas kontroli subskribon: publika ŝlosilo ne trovita > > > > $ gpg --keyserver keys.gnupg.net --recv-keys > > 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 > > gpg: requesting key 3D9AEBB5 from hkp server keys.gnupg.net > > ?: keys.gnupg.net: Host not found > > gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused > > gpg: validaj OpenPGP-datenoj ne trovitaj. > > gpg: Nombro traktita entute: 0 > > Oops, keys.gnupg.net seems to be retired. Please use > pool.sks-keyservers.net instead, for example. How? Is that documented? -- Example of the problems in top posting: A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I leave quotations after my reply? Saluton, Quiliro 0987631031
Re: Kernel panic - not syncing: attempting to kill init! when booting GuixSD
Christopher Baines writes: > Excluding the generations that I removed, the others don't boot. All I > can really gather so far is a call stack, and the message: > Kernel panic - not syncing: Attempted to kill init! Has the label of your root partition changed? -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Kernel panic - not syncing: attempting to kill init! when booting GuixSD
Hey, So I deleted some system generations from one of my GuixSD systems, then rebooted. Unfortunately, I can no longer get it to boot. I think the latest system generation should work, and at least one of the previous generations should work. Excluding the generations that I removed, the others don't boot. All I can really gather so far is a call stack, and the message: Kernel panic - not syncing: Attempted to kill init! I'm uncertain that this is something I have done wrong, I'm pretty sure I was using the latest system generation when I ran guix gc, and I'm assuming that it is the garbage collection that has stopped things working. I'm going to try and make some time to see if I can get this system back working again. I'm not sure how realistic this is, but I'm planning to start by using the installation image, and somehow running guix system reconfigure. Has anyone done anything similar before, or have any ideas about how this happened, how to get more information out about why Linux panics, or how to fix it? Thanks, Chris signature.asc Description: OpenPGP digital signature
Re: Emacs-Guix 0.3.1
Ricardo Wurmus skribis: > Actually, I think Info is superior, not least because of the index. In > an Info reader (Emacs, for example) you can hit “i” and start typing a > concept. A well-written manual will take you right to the section > explaining the concept, even if the exact phrase is not used in the > manual text. > > For those who aren’t yet familiar or comfortable with Info readers work > is underway to add some JavaScript to HTML pages that can be generated > from the Texinfo sources. The added scripts would provide similar > features as a traditional Info reader application. > > Until then I really recommend learning a bit about Info and how to use > it. It’s a really good system and generally provides better results > than a web search. BTW, the manual now has a “getting started” section on how to take advantage of locally-installed documentation: https://www.gnu.org/software/guix/manual/html_node/Documentation.html Ludo’.
Re: not an ELF file
2017-05-24 12:08 GMT+02:00 Ludovic Courtès : > Catonano skribis: > > > sudo guix pull succeeded > > > > guix pull fails with > > guix pull: error: guile-ssh-rexec-bug.patch: patch not found > > Hmm, could you run “rm ~/.config/guix/latest”? > I could. But then, without a working guix, how would I reinstate it ? Anyway, I linked .config/guix/latest to a local checkked out master branch I had It seems to work Ricardo made me aware that I could run "guix pull" from within any checked out guix and that would reset the .coni/guix/latest to point to a guix subjected to the "guix pull" command So it seems this is solved I believe that these tricks related to .config/guix/latest should be discussed, to some extent, in the manual It's not just a configuration matter It's about the substantial day to day use I will open a new thread for this In the meantime: thank you
Re: offload daemon
James Richardson skribis: > James Richardson writes: > >> Ludovic Courtès writes: >> >>> Hello, >>> >>> James Richardson skribis: >>> I am trying to setup an offload daemon. I have everything setup correctly (I think ;) $ guix offload test completes successfully. The offload daemon is actually guix on a foreign distro (Debian sid in this case). Neither guix running on top of a Debian (sid and jessie) nor guixsd seem to even call out to the offload daemon. All boxen are 64. My /etc/guix/machines.scm is here (list (build-machine (name "thor.lab01.jamestechnotes.com") (system "x86_64-linux") (host-key "ssh-ed25519 C3NzaC1lZDI1NTE5IJf0ezYgeVFit40VJwaBEW1dGm2Xz+SHzVmib8IbN58y root@thor") (user "guix") (speed 1.) (private-key (string-append (getenv "HOME") "/.ssh/identity-for-guix" Is x86_64-linux the proper system type? >>> >>> Yes. >>> >>> There are several things to consider here. By default, guix-daemon >>> creates a single job, so that single job will end up being built >>> locally, unless you spawn, say, two “guix build” commands in parallel >>> (the number of jobs is per client.) >>> >>> Running “guix-daemon --max-jobs=0” should force all builds to be >>> offloaded: >>> >>> >>> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix_002ddaemon.html >>> >>> I *think* “guix build --max-jobs=0” should give the same result. >>> >>> Alternately, if you run “guix build --max-jobs=2”, presumably half of >>> the builds will be offloaded. >>> >>> Let us know if that works for you. >>> >>> Ludo’. >> >> I have a permission problem somewhere, I think. If I run as root offload >> works, otherwise it doesn't. Don't really know here to look from here. > > Hmm, I move the key pair to /tmp and set the perms to 644 and offloading > works for my regular user... Not quite sure I understand why. The ‘guix offload’ command is invoked by guix-daemon as root. So when it is invoked, (getenv "HOME") returns "/root" or similar. Could that be the problem? HTH, Ludo’.
Re: not an ELF file
Catonano skribis: > sudo guix pull succeeded > > guix pull fails with > guix pull: error: guile-ssh-rexec-bug.patch: patch not found Hmm, could you run “rm ~/.config/guix/latest”? HTH, Ludo’.
