<EternalZenith>Do you use the uuid or the partuuid when defining a filesystem? <EternalZenith>How do you get an encrypted root partition and unencrypted boot partition to work? <EternalZenith>The boot entry doesn't even try to decrypt the root even when things are set up how they are shown in the example configs <nico202>Hi, I'm in the process of moving from NixOS to GuixSD. Does anybody knows a way to setup persistent storage on the USB stick so that I can configure my system in the spare time without having to partition the drives? I'm very low on free space <roptat>good news: openjdk10 built on core-updates, but it fails in the validate-runpath phase where I get a backtrace ***specing_ is now known as specing
***tilpner_ is now known as tilpner
***joehillen_ is now known as joehillen
***jonsger1 is now known as jonsger
***tau is now known as Guest5223
***nonlinear is now known as NB0X-Matt-CA
***tau is now known as Guest69752
***MinceR_ is now known as MinceR
<snape>but I get In procedure string-prefix?: Wrong type argument in position 2 (expecting string): #<package bash@4.4.19 gnu/packages/bash.scm:119 3abda80> <roptat>I get a stack trace I don't understand <snape>is there an obvious way to get the store path as a string, so that (derivation) is happy? Also, how come it works in Guix tests? <civodul>snape: you can't pass a package to the low-level 'derivation' procedure <civodul>roptat: could you spawn a REPL, do ",m(guix build gremlin)" and then: <civodul>(call-with-input-file file (compose parse-elf get-bytevector-all)) <civodul>well: (define elf (call-with-input-file file (compose parse-elf get-bytevector-all))) <civodul>where FILE is that libanl.so file from your failed build <efraim>lz4 failed to build on aarch64 on core-updates <efraim>Also the backtrace apparently contained a null character which guix choked on <snape>civodul: ok thanks, I found a solution <snape>but yes, the doc is misleading <roptat>civodul: there is no libanl.so file :/ <roptat>running find in /gnu seems to indicate that it's a glibc library <civodul>well can you run that on all of "/gnu/store/bdgbs6nsb1kzxpqmcxajjkvvkmk5kn72-openjdk-10+46/lib"? <civodul>if you find out, you can send the details to bug-guix <roptat>mh... In procedure module-lookup: Unbound variable: define <roptat>EternalZenith: list takes arguments and put them in a list. cons* take arguments, put them in a list and add them to the last element which is a list <roptat>so (list 1 2 3) is the same as (cons* 1 2 3 '()) or (cons* 1 (list 2 3)) <roptat>in the configuration, %default-packages, %default-services etc are lists, so that's why we suggest to use cons* there <EternalZenith>I'm having a surprising amount of fun digging through sources I've never had to to get things working <efraim>lfam: just saw a bunch of CVEs for python2 and 3 <efraim>from the debian-security email list <efraim>msg00238 had another one listed for python3, didn't get a chance to look <lfam>efraim: Can you make a tracking bug for us on bug-guix? <lfam>(I actually got these emails a few days ago but haven't had time to deal with the bugs) <efraim>lfam: my computer is in a reboot loop from the Mac trackpad bug, could be a while until I get my computer back up and running: ( <lfam>Okay, I can make the bug now <lfam>That sounds pretty frustrating :( <efraim>Wouldn't be too bad if my computer didn't overheat and shut itself off sometimes ***jonsger1 is now known as jonsger
<EternalZenith>Having nix installed and functioning is required to import nix packages to guix? <lfam>EternalZenith: Yeah, basically. However, the Nix importer is not very useful except in cases where you need to import a large number of packages that are totally uncomplicated <lfam>The importer only imports the basic parts of the Nix package expressions <EternalZenith>There is several packages I want to make, but I'm not sure I can make them from more-or-less scratch yet <lfam>EternalZenith: It depends on the specific package. If you can link to it, I can give you some advice about it <EternalZenith>It makes capslock act as control and escape systemwide, more reliably than setting that with xcape and it works in ttys <lfam>EternalZenith: If you use my name in your messages, I'll be notified and respond more quickly :) <lfam>EternalZenith: That package looks pretty simple. It would be very easy to just package it for Guix without trying to set up the importer <EternalZenith>It depends on this, too, as well as a patch to get udev to work with it <lfam>It applies the patch to udev or to itself? <lfam>That substituteInPlace is one of the many "complications" that the importer won't translate, and it's also the least trivial part <lfam>I mean, it's not very complicated. It won't be very hard to rewrite it for Guix, but the importer will not really save you any time, in my opinion <lfam>That importer was more useful in the early days of Guix, when there were not many Guix packages yet, for picking the low-hanging fruit, so to speak <EternalZenith>I guess now is as good a time as ever to learn how to package things from scratch <lfam>Also, to clarify my earlier message, I don't see any other "complications" in this Nix package. I meant that most Nix packages have at least one, so the importer won't give you a working package on its own <lfam>Right, the basic stuff like name, version, source URI, which build system to use, etc <lfam>An ideal package can be built with only that, by using its respective build system according to the standard. But, most packages deviate somehow :) Also, dependencies are probably named differently in Nix and Guix, so a human would need to do that too <lfam>EternalZenith: It's in the output of `guix package --show` and `guix package --search` <georges-duperon>What's the most idiomatic way to feed the hash of the inputs to the build command (make) ? <georges-duperon>e.g. I could call "guix hash ." inside my software's Makefile, or I could pass #:make-flags `(,(string-append "INPUT_HASH=" (some_guix_function))) to the gnu-build-system.