IRC channel logs


back to list of logs

<EternalZenith>I'm having trouble getting Guix to boot on my first install
<EternalZenith>Grub is showing as a bootable option, but doesn't start
<EternalZenith>I'm pretty sure I'm not setting up the esp correctly
<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
<jlicht>hey guix!
<snape>jlicht: o/
***nonlinear is now known as NB0X-Matt-CA
***tau is now known as Guest69752
***MinceR_ is now known as MinceR
<snape>civodul: I'm trying to run the snippet there:
<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>civodul: openjdk10 built but failed in validate-runpath :/
<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>the snippet might be misleading!
<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>and: (elf-dynamic-info elf)
<civodul>where FILE is that file from your failed build
<efraim>lz4 failed to build on aarch64 on core-updates
<roptat>civodul: it will take some time
<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 file :/
<roptat>running find in /gnu seems to indicate that it's a glibc library
<EternalZenith>Does pinentry normally require manual configuration?
<civodul>roptat: ah silly me
<civodul>well can you run that on all of "/gnu/store/bdgbs6nsb1kzxpqmcxajjkvvkmk5kn72-openjdk-10+46/lib"?
*civodul has to go
<civodul>if you find out, you can send the details to bug-guix
<EternalZenith>What is the difference between cons* and list?
<EternalZenith>Does cons* just not end in '()?
<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 was just about to ask that
<roptat>yw :)
<EternalZenith>I'm having a surprising amount of fun digging through sources I've never had to to get things working
<EternalZenith>Mailing lists are something I've never really used before
<efraim>lfam: just saw a bunch of CVEs for python2 and 3
<lfam>efraim: Link?
<efraim>from the debian-security email list
<efraim>Bah my computer shut off
<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>But not the steps to build the package, right?
<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
<EternalZenith>That's the thing I'm missing the most, along with polybar
<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>That part of the package seems to be
<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?
<EternalZenith>lfam: 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
<EternalZenith>The importer mostly just handles metadata, right?
<lfam>Right, the basic stuff like name, version, source URI, which build system to use, etc
<EternalZenith>lfam: How do you find which module a package belongs to?
<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`
*lfam AFK briefly
<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.