IRC channel logs

2021-09-13.log

back to list of logs

<ryanprior[m]>kdl lang just got its stable release today, I think it might be a real slick language for defining Guix packages & services
<ryanprior[m]> https://kdl.dev/
<ryanprior[m]>compare this JSON package def: https://github.com/ryanprior/guix-packages/blob/master/testing/countdown.json
<ryanprior[m]>to the same in kdl: https://github.com/ryanprior/guix-packages/blob/master/testing/countdown.kdl
<ryanprior[m]>Reads to me as near identical to the sexp form, omitting some parens and replacing other wrapping parens with braces
<singpolyma>Probably could write something that compiles KDL do sexp
<lilyp>"have you read the xkcd about standards?" :)
<singpolyma>Is there any way to have a package definition with no hash / a hash that means "don't check / accept anything" ? Just for development purposes
<iskarian>There might be a better solution, but if you're developing locally, you might be able to make the source field a fixed-output derivation using a local file/directory
<singpolyma>Yeah, I just found guix gexp local-file, this seems like what I want
<singpolyma>I'm trying to do something maybe a bit odd (glue parts of the ruby and copy build systems together) and am getting this error: https://bhh.sh/65t -- I expect I'm just doing something wrong with my quoting, my Scheme is somewhat unpractised, but the error is quite cryptic
<iskarian>singpolyma, you have to replace with a lambda
<iskarian>Oops, I read too fast, sorry!
<iskarian>rather, does the package start to build without that "(replace 'install" step?
<singpolyma>yes, the replace install is the problem for sure
<iskarian>you want to import the copy build system with #:modules and #:imported-modules; check the uucp package for an example
<iskarian>nncp package*
<singpolyma> #:use-module ((guix build copy-build-system) #:prefix copy:) isn't right?
<iskarian>at the top of the file? No, because it's actually the builder that needs access to the copy-build-system's phases, not the host side, which reads the package definition
<singpolyma>Ah. And I guess the builder runs too far away for just doing a splice with , to work?
<iskarian>yes, exactly. a splice means you're "breaking out" of the code that we're sending to the builder and evaluating it on the host side instead
<singpolyma>So in general if I want to reference any complex value in the builder I need to make a module somewhere it can see and import it?
<zacchae[m]>Does guix not populate /dev/disk/by-label by default?
<zacchae[m]>I haven't touched anything udev related
<zacchae[m]>Just want to know if I've done something horrible, or if it's supposed to be like this
<podiki[m]>I see /dev/disk/by-label
<zacchae[m]>thanks...
<podiki[m]>and I do have disks that have labels
<podiki[m]>as formatted and used to mount in file-system
<bsturmfels>We're making some good progress on packaging MediaGoblin for Guix thanks to jgart and raghavgururajan. Details in our guix channel here: https://git.sr.ht/~mediagoblin/mediagoblin-guix/tree/master/item/README.md
***nckx_ is now known as nckx
<xd1le>bsturmfels: thank you for the work and update
<geex3>how to print/display in a system reconfigure? (can readline and getpass)
<geex3>the prompt in readline/getpass works, so i know its possible to make this interactive hah
***Keele_ is now known as Keele
<qzdlns[m]>morning guix
<lilyp>geex3: p sure (current-output-port) should still be the terminal
<jpoiret>is ar packaged in guix? i want to unpack a `.deb` file
<jpoiret>here is the GDM Wayland support patchset https://issues.guix.gnu.org/50563 (of course i had to make a typo in the subject)
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, nckx says: So I'm fooling about in linux-boot.scm. OK to remove this cute comment from 8 years ago that probably served its purpose, if any? https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/linux-boot.scm#n393
<civodul>nckx: heh, sure :-)
<civodul>it probably made sense back then
<jpoiret>are submissions to debbugs slow? I sent my two follow-up mails about 20 minutes ago
<efraim>hello everyone!
<jpoiret>ah, i sent those using another mail address that hadn't used debbugs either, so all is normal
<iskarian>sneek, later tell yoctocell: I promise I haven't forgot about generic-git, I've just been distracted! I'll try to take a look tomorrow :)
<sneek>Will do.
<lilyp>iskarian: sorry for distracting you :P
<iskarian>civodul, should #32844 be closed? (is it satisfied by --export-manifest?)
<iskarian>lilyp, no worries :) I actually fell down the Zig rabbit hole when attempting a "quick review" of Andrew's original patch
<iskarian>sneek, later tell yoctocell: I didn't actually expect my silly separator-frequency heuristic to make it in to anything :P
<sneek>Okay.
<iskarian>sneek, botsnack :)
<sneek>:)
<civodul>iskarian: hi! yes, #32844 can definitely be closed
<civodul>thanks for working on bug triage! much appreciated
<iskarian>is it still triage if they are >2 years old? ;)
<civodul>good point :-) it's even more appreciated anyhow :-)
<futurile>hey guixers
<civodul>iskarian, maximed: should i go ahead with the definition location patch? https://issues.guix.gnu.org/50286
<futurile>I'm trying to get set-up to build from git (reading the manual). I've pulled Guix fine, and built it with make, but when I run 'make test' it hangs on tests/gem.scm, the gem.log in the tests directory shows everything passing. Any ideas on what I can look at?
<civodul>it seems to do the job and would unlock iskarian 's patch set for "guix refresh"
<civodul>futurile: hi! it may be blocked on the test that follows tests/gem.scm, which i think is tests/gexp.scm (assuming you're not passing '-j')
<civodul>could you run "ls -lrt tests/*.log" to see which test logs are still being written to at that point?
<maximed>civodul: I prefer 'let&' myself, but YMMV and the ‘definition location patch’ would also work
<iskarian>civodul, my main concern is how the patch would affect the complexity of a potential future 'define-package', but that's probably far enough off that we can cross that bridge when we come to it
<maximed>(the exact method doesn't really matter for the "guix refresh" patches)
<iskarian>I did some further grepping, and about 40-50 packages use (define ... (let ...) (package)); about 10-15 of those use the 'let' to define a commit, so probably no big worries there.
<civodul>iskarian: if/when we introduce define-package, we can easily make it do the right thing like this 'define-public' replacement
<iskarian>ah, good to hear. Macros are still black magic to me.
<iskarian>LGTM
<civodul>it may be that we cannot cover 100% of the packages, but i think that's fine
<maximed>Does this Hurd offloading error look familiar to anyone: ‘https://paste.debian.net/hidden/212697e9/
<maximed>I didn't see it on issues.guix.gnu.org
<iskarian>I would personally be partial to a backward-sexp-search, but that patch doesn't exist (and I'm not going to write it anytime soon), so yours wins :P
<civodul>maximed: "Connection refused" means the childhurd is not running and/or sshd within it is not running
<civodul>iskarian: heh, alright :-)
<civodul>but yeah, i do agree that we need some kind of text editing facilities in the long run
<maximed>civodul: The "connection refused" is expected -- the childhurd was down so I've restarted it
<maximed>there's a ‘match-error’ error now
<civodul>ah right
<civodul>hmm, i've definitely seen that, but it's never quite clear what happens :-/
<civodul>sorta like https://issues.guix.gnu.org/50312
<civodul>it's hard to debug because you need to strace both sides and/or enable debugging printfs for libssh + sshd
<jpoiret>my follow up emails haven't shown up at https://issues.guix.gnu.org/50563 after ~1 hour, is that usual?
<maximed>FWIW, if I restart the build, it's working well
<maximed>(now building glibc)
<civodul>jpoiret: one's first messages to the lists go in quarantaine for a few hours, perhaps that's what's happening?
<jpoiret>civodul: oh i thought it was only the first one
<civodul>maximed, iskarian: so i'll go with the definition location patches and then we can adjust iskarian's "refresh" patches accordingly
<futurile>civodul: ah you must be right, it has gexp.log open and has written to it. It's says it's SKIP a test for Fake GUIX base32 module.
<iskarian>jpoiret, were the followup messages sent to 50563@debbugs.gnu.org?
<jpoiret>yes
<iskarian>Huh. Guess it's quarantine as civodul suggested? (I thought it was just the first message that gets quarantined)
<iskarian>civodul, sounds good to me :) might be a bit before I get to revising that patch, I'm trying to get #50493 (update go-build-system to use 1.17) out the door first since 1.14 is no longer receiving bug fixes
<iskarian>sneek, later tell lfam: You're right. I'm not going to block #50493 with all the go-build-system updates; I'll just send a patch for the "go-std-cache" bit
<sneek>Okay.
<efraim>I was going to finish up my go cross-build patch, but it failed to actually cross build anything from the CLI
<iskarian>civodul: after the issues with emulated builds for ppc64le (and apparently sometimes aarch64: #49921): WDYT about a package property that indicates the package doesn't play well with certain emulations?
<iskarian>efraim: :(
<efraim>looks like it was a typo somewhere, setting goos and goarch from a package file worked fine
<iskarian>How would you even do that from CLI? How would you even get the right inputs? AFAIK environment doesn't take --target
<efraim>guix build go-ipfs --target=aarch64-linux-gnu
<iskarian>oh that's what you mean
<efraim>well, i actually tried with keybase
<qzdlns[m]>is anybody using recoll? I'm missing the convenience of a desktop indexer, so looking to put a build together (https://framagit.org/medoc92/recoll)
<mroh>qzdl:ns: I started packaging recoll here: https://gitlab.com/mroh69/guix/-/blob/master/mroh/guix/packages/recoll.scm but its only a start and also w/o the gui/qt stuff, but maybe it helps.
<efraim>iskarian: I think I found the typo, was using 'guix' instead of './pre-inst-env guix'
<iskarian>Well... all considered, that's a pretty good place for the typo to be!
<iskarian>I'm glad it works! I was going to test it, but I never remembered to start it before I went to bed to build the cross-toolchains, haha
<iskarian>Ah, efraim, this is still a bit far off, but when Go 1.18 is released, it will bootstrap with Go 1.16+; for ppc64le do you think it makes more sense to do gccgo-10 -> go-1.16/1.17 -> go-1.18 or gccgo-11 -> go-1.18?
*iskarian -> bed
<iskarian>night all!
<civodul>night!
<civodul>iskarian: re package property for hardware emulation, i don't know, maybe that could work
<attila_lendvai>how come somwhere the input is called ("python-attrs" ,python-attrs), and somewhere else ("attrs" ,python-attrs)? the first elemenet is just an informal string for the humans?
<maximed>attila_lendvai: because it's used inconsistently
<maximed>attila_lendvai: these input labels matter sometimes, e.g. when using (assoc-ref inputs "python-attrs")
<maximed>or #$(this-package-input "python-attrs")
<attila_lendvai>maximed, so, does it make sense to prefix "python-" wherever it's missing? and record it as a standalone commit? or shall i just leave it as-is...? random example: python-duniterpy
*attila_lendvai decides to just leave it as-is in code he doesn't need to touch
<maximed>attila_lendvai: In case of python-duniterpy, adding "python-" prefixes would bring it in line with convention
<nckx>Good morning, Guix.
<dstolfa>good morning, nckx
<nckx>jpoiret: I just approved a message of yours about a (half?) hour ago. Only one, though.
<qzdlns[m]>mroh: great, thanks! I'll check this out and see if I can make any headway - I've never used the gui, but it should probably be an extra target for the package once the main indexer is building anyway
<nckx>Heyho.
<jpoiret>nckx: do you mean the original post on this one https://issues.guix.gnu.org/50563?
<nckx>Yes, I think so.
<civodul>i pushed https://issues.guix.gnu.org/50286, so "make clean-go && make" everyone :-)
<nckx>It would've shown up on that Web site the moment it arrived in the queue for moderation, because our system is all dorked up.
<jpoiret>do you know if there are more waiting or if they just didn't reach debbugs at all
<jpoiret>they should all be replies to the same patch
<nckx>My guess is that they are lurking in the shadows to be born. The good news is they won't be held for moderation.
<nckx>These long delays happen sometimes.™
<jpoiret>alright good, there might be an email with another one of my email addresses, if you ever see it go by i'd rather not have it approved if possible
<nckx>Duplicate?
<nckx>Invective-filled rant?
<nckx>Such suspense.
<nckx>Will (not) do!
*jonsger bravely will boot into core-updates-frozen after reconfigure went through (minus some packages)...
<jonsger-mobile>Hm that wasnt a big success. It hangs in grub rescue shell saying: unknown command cryptomount
<jonsger-mobile>Did we change some stuff on the bootloader recently?
<nckx>Not between master & core-updates-frozen…
<jonsger-mobile>Strange
*nckx was checking the same thing, but can't even find non-bootloader changes that seem related.
*attila_lendvai has sent his first patch
<nckx>Congrats!
<nckx>And thanks 😛
<jonsger-mobile>Maybe the target > targets change…
<attila_lendvai>well, thanks for guix! i'm having fun, and it feels worthwhile, too.
<nckx>jonsger-mobile: But that's on master too?
<jonsger-mobile>Yes it is. You are right. And I booted sucessfully on master some days ago..
<jonsger-mobile>I will file a bug later today…
<nckx>Good luck. You're braver than I am just now :)
<Butters>Hey fellas. Is it possible setup a Wireguard VPN on Guix?
<yoctocell>Butters: Yes, there is a Wireguard service <https://guix.gnu.org/en/manual/devel/en/html_node/VPN-Services.html#VPN-Services> :-)
<sneek>Welcome back yoctocell, you have 2 messages!
<sneek>yoctocell, iskarian says: I promise I haven't forgot about generic-git, I've just been distracted! I'll try to take a look tomorrow :)
<sneek>yoctocell, iskarian says: I didn't actually expect my silly separator-frequency heuristic to make it in to anything :P
<yoctocell>sneek, later tell iskarian: No worries, I see that you have been busy with Go and Zig stuff :-)
<sneek>Will do.
<efraim>Packages can be cross-built, and if a specific architecture or operating system is desired then the keywords @code{#:goarch} and @code{goos} can be used to force the package to be built for that architecture. The combinations known to Go can be found @url{"https://golang.org/doc/install/source#environment", in their documentation}
<yoctocell>sneek, later tell iskarian: re guess-delim, heh, it seems to be working pretty well so far ;-)
<sneek>Okay.
<efraim>sneek: later tell iskarian I'd be tempted to stick with gccgo-10 since it'll be the default gcc version when core-updates is merged so it won't be getting bumped. Otherwise every gcc-11 upgrade would force a rebuild of all the go packages for ppc64le
<sneek>Okay.
<efraim>sneek: botsnack
<sneek>:)
<jonsger-laptop>reported as https://issues.guix.gnu.org/50566
<jonsger-laptop>nckx: you were succesful booting?
<akib>jonsger-laptop: he/she is still updating
<jonsger-laptop>nckx: how is the update going?
<nckx>Still in progress, one component at a time :)
<jonsger-laptop>what does that mean. one component at a time?
***roptat_ is now known as roptat
<lilyp>'tmeans baby steps probably :)
<jonsger-laptop>guix system reconfigure --50% or what?
<nckx>This machine hadn't been updated in months so I wanted to take it slow. Not boot into EVERYTHING's BROKEN‌ WHEE.
<nckx>jonsger-laptop: So I'm on master now, with the targets change, and no trouble with cryptoroot.
<nckx>I didn't try core-updates; sorry. I like being able to receive e-mail.
<nckx>jonsger-laptop: Have you been able to restore your previous system?
<jonsger-laptop>nckx: nope, I'm still in my day job :P
<jpoiret>how is a build environment setup in guix? i'm mostly looking at the source code but I think it'd be more efficient if I had at least a faint idea of how it works
<maximed>jpoiret: See nix/libstore/build.cc and (guix build-system gnu)
<jpoiret>for example, who is responsible for setting up LIBRARY_PATH? i've seen the search-paths arguments in the build-systems, but i'm not sure if they're the ones responsible for setting those up, and if there's a "guixy" way of getting those instead of just getenv
<maximed>The former for how the environment is set up, the latter for what goes into the environment
<civodul>jpoiret: there's also an explanation at the top of https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html
<jpoiret>oh i forgot about nix, thanks!
<maximed>gnu-build-system sets #:search-paths
<civodul>for search paths and all, see guix/build/gnu-build-system.scm
<maximed>(the 'set-paths' procedure)
<maximed>for propagation (a notion which doesn't exist within the build environment or on the derivation level), see guix/packages.scm
<jpoiret>maximed i think that's the piece i was missing (propagation)!
<maximed>technically, nix' ‘references’ mechanism could be seen as a form of propagation
<maximed>though references don't influence the search paths
<maximed>(If X references Y, and X is available in some environment, then Y is available in the same environment)
<maximed>It's not called propagation though
<civodul>sneek: seen samplet
<sneek>samplet was last seen in #guix 3 months ago, saying: pretty safe approach.
<jpoiret>if i'm understanding this correctly, in a build, the build environment will have a union of the different package inputs's outputs, and the search paths will only reference that union, rather than a list of all the different outputs's sub search paths?
<jpoiret>eg, only one package has "GUILE_LOAD_PATH" set to "/share/....", and in the build, rather than all packages having their own "/gnu/store/thatpackage/share/..." in the search path, it will only refer to /gnu/store/thebuildenv/share/..." right?
<maximed>‘the build environment will have a union of the different package inputs's output’ --> true (if build environment == what the builder can see in /gnu/store), and it includes the ‘implicit inputs’ of the build system and the transitive references of all this as well
<maximed>There is no /gnu/store/thebuildenv
<maximed>no union directory is created when building things (guix environment package ... _does_ create an union however)
<maximed>Rather, within the build env, search paths are set to things like "GUILE_LOAD_PATH=/gnu/store/...-a/share/...:/gnu/store/...-b/share"
<maximed>(The ":" separates directories in the search path)
<jpoiret>alright, thanks a lot! i've got a much clearer picture of what goes on there. also the `search-paths` that is passed to the build phase is not simply that of the package but a propagated one from all of its inputs
<jpoiret>very nifty, maybe i'll get around to writing something about this after i finish what i'm working on
<Chap>Hi, Im trying to setup a Wireguard VPN.
<Chap>My config.scm: https://pastebin.com/eA4654H4
<Chap>When I type "guix system reconfigure" I get this error message: https://pastebin.com/WcWD4Uaf
<Chap>What should I do?
<roptat>hi guix!
<roptat>Chap, I'd like to help you, but pastebin just shows an empty paste for me. Can you use say paste.debian.org instead?
<roptat>(I'm not even using tor or anything, for some reason I see the text for a fraction of a second and then it disappears)
<apteryx>it seems linking with gold leads to the executable not finding the shared libraries it was linked against at runtime
<apteryx>see for example: https://paste.debian.net/1211585/
<apteryx>the LLVM* shared libraries are in LIBRARY_PATH
<apteryx>if I set LD_LIBRARY_PATH, it works
<roptat>Chap, mh, playing a bit with the css on the page let me see it. It looks like on line 36 (keyboard-layout keyboard-layout) you're closing the list too soon; remove one closing parenthesis
<Chap>Thank you very much, it worked. :)
<roptat>\o/
<roptat>I worked a bit on my android channel since last week. I now have 1/3 of the SDK tools: https://framagit.org/tyreunom/guix-android/-/issues/3 :)
<dhruvin>That's great!
<roptat>mostly, missing support for configuration keys, and I can't find two of the tools
<efraim>roptat: I noticed that there's some overlap between those java packages and the ones needed for bazel
<efraim>rekado_: ^
<efraim>at least according to debian's bazel-bootstrap package
<roptat>that's possible, android uses a lot of external packages
<roptat>the main issue with my approach is that I take the official android sources as the "source of truth", so I use their bundled dependencies, build the static libraries, ...
<roptat>although for java, that's less of an issue, but I don't want to use packages that are not at the version specified by the android team, APIs might not match
<roptat>especially since they apply their own patches
<roptat>well, once I manage to build the rest of the tools and start figuring out how to build the rest of the SDK, we'll have to talk about how to merge that into guix, I don't know if it respects the quality standards...
<zacchae[m]>my grub is trying to access my encrypted root filesystem before prompting for decryption key (and so fails). I definitely have (dependencies mapped-devices) in my config for my root. Anyone had similar trouble?
<nckx>zacchae[m]: Yes, that sounds like what jonsger-laptop encountered, at least in spirit. Do you also get unknown command cryptomount?
<zacchae[m]>No. The first line after "welcome to grub!" is "error: no such device: <<uuid-of-root-drive>>"
<nckx>Is this a new installation or a failed upgrade? And from which branch/commit?
<zacchae[m]>that uuid is the uuid of my root filesystem inside a luks partition, so would not be visible until decryption
<jpoiret>when i want to have a custom build phase and give it an identifier, i need to quote its whole value right? since it needs to be passed to the builder. in that case, how do i import modules builder side? i've tried `with-imported-modules` to no avail
<zacchae[m]>nckx: new installation. Let me guix pull before sending us round in circles...
<nckx>OK, AFK a while.
<zacchae[m]>but should be main branch, somewhat dated commit. I'm pretty sure I had this working once on this commit though
<jpoiret>zacchae[m] grub should detect that its target is on an unlocked luks device whenever it update-grubs tho
<zacchae[m]>you mean during install or boot?
<zacchae[m]>I have it unlocked when installing, then when I boot, it is no longer unlocked and I expect it to prompt me for a password before trying to access such a boot
<jpoiret>during install
<zacchae[m]>It doesn't seem fail during install, but when I try to boot is when I have the trouble
<jonsger-laptop>so it seems a bit different then my problem
<jonsger-laptop>what says "ls" in grub rescue?
<maximed>sneek: seen mothacehe
<sneek>mothacehe?, pretty sure was seen in #guix 12 days ago, saying: bsturmfels: ok, we slowly progress :) If you can find the sources of their resizing tool we can maybe understand why it doesn't work on our image..
<zacchae[m]>jonsger-laptop: Ill tell you in a sec. I have everything scripted at this point and am regenerating the drive from scratch
<roptat>jpoiret, with #:modules or #:imported-modules (I still can't remember the difference)
<jpoiret>in lambda*?
<jpoiret>oh no in #:arguments. Seems that it overrides the imported modules though, so it looks like i'll need to pass everything that is implicitely imported
<roptat>jpoiret, there are examples of that, some import %default-modules or whatever it's called
<radvendii>o/ hello guixers
<radvendii>does anyone here have experience with packaging golang applications with guix?
<zacchae[m]>jonsger-laptop: ls in grub rescue gives (hd0) (hd1)
<roptat>radvendii, you might want to try the importer, "guix import go ..."
<zacchae[m]>nckx: I just did a guix pull. Same problem. Also, I dd'd the disk with zeros before retrying
<jackhill>jpoiret: congratulations on figuring out GDM wayland! I just saw your patch come through and although I haven't tested it yet, am excited to do so later
<PurpleSym>rekado_: Sorry for pinging you again, but it looks like you touched hugs in the past. Have you ever got it working with GCC>4.9? I’m trying patches from Debian right now, but somehow -D_GNU_SOURCES is not actually passed through to GCC.
<radvendii>roptat Yeah, so i was looking at that. That seems to only accept a URL as an argument. Is there a way to do it with a local package? I'd like to bundle the packaging information into the repo with the code
<roptat>mh, no
<roptat>it needs a package name, and for go, it's a URL
<roptat>so, you'll have to import each dependency individually
<roptat>or add support for your use-case in the importer ;)
<nckx>jpoiret: 2 patches have arrived at http://issues.guix.gnu.org/50563 (which is not moderated) and in my inbox (for forwarding to all guix-patches@ subscribers, which is). Did you not want them approved? Why not?
<rekado_>PurpleSym: sorry, I don’t remember if I ever used it with a more recent GCC.
<rekado_>it’s been a very long time since I used it to work on the GHC bootstrap.
<maximed>roptat, radvendii: There is "guix import go --recursive STUFF"
<maximed>to automatically import dependencies not yet in guix
<nckx>zacchae[m]: Could you share you mapped-devices field, and check that your "/" <file-system> has (dependencies mapped-devices) present?
<radvendii>maximed roptat: wait are we talking about a command line utility? I thought we were talking about the `go-module->guix-package` function in the `guix import go` module
<PurpleSym>rekado_: No problem, thanks :)
<roptat>(guix import go) is related to the "guix import go" command-line utility :)
<apteryx>hmm, is it not possible to invoke 'guix pack' from a package defined in a guix.scm file?
<roptat>you can run something like "guix import go -r github.com/foo/bar" to import it and its dependencies that are not yet in guix
<radvendii>you mean import them into the `/gnu/store`?
<maximed>radvendii: The command line utility "guix import go" is implemented with the "go-module->guix-package" procedure
<maximed>from (guix import go)
<nckx>jpoiret: I see they are duplicates. Let me know which one you intend to arrive.
<zacchae[m]>nckx: http://zacchae.us:8080/broken.scm
<zacchae[m]>yes I have those things
<radvendii>maximed roptat: Ah, okay. I can run it on some well known go packages and now I understand what it does
<radvendii>it doesn't work on the go package i'm working on. I know it looks up metadata somewhere. Does that mean it doesn't work on random third party go packages?
<nckx>zacchae[m]: Hm, the only meaningful difference with mine (that I can see) is that I use /dev/sda1 & /dev/mapper/root instead of (uuid) and (file-system-label).
<nckx>The latter looks odd to me, try replacing with (device "/dev/mapper/jake"), I guess, maybe.
<maximed>radvendii: I don't think the go importer has a notion of ‘third party packages’
<maximed>it's all just packages to the importer
<maximed>I would assume it works on many go packages, though possibly not all
<maximed>radvendii: Do you receive some kind of error message?
<radvendii>yep https://paste.rs/ZwU
<maximed>that's a known bug, I think someone made a patch to fix that?
<maximed>maybe https://issues.guix.gnu.org/45984
<maximed>radvendii: IIRC, retrying without "-r" will prevent that backtrace
<maximed>though you will have to run "guix import go" recursively yourself for each dependency not yet in guix
<jonsger-laptop>can someone on EFI post my what `find /boot` gives back?
<radvendii>Hmm... I'm still getting something similar https://paste.rs/nrY
<apteryx>so, to allow using a local package with 'guix pack', I put the definition in a subdirectory guix/name.scm. Then I can do 'guix pack -L guix name'
<apteryx>The subdirectory is so that the -L option doesn't try to load (and choke on) the manifest.scm and channels.scm files.
<jpoiret>nckx: as long as they are from the original email address they're good
<jpoiret>i also sent some from my personal email address which i'd rather not share is all
<jpoiret>ah, i see it's too late https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50563, alas
<jpoiret>i'll send (one more! :( ) follow-up email to clarify
<radvendii>Also I just read vonnegut's "cat's cradle" so i'm very curious what guix's "ice-9" is and how it relates
<nckx>jpoiret: Yeah, sorry, GNU's infra is a bit weird that way. I'll bin it from re-mailing at least.
<jpoiret>thanks
<nckx>…aand somebody beat me to it in the past 40 minutes :(
<nckx>I don't know whether it was approved (probably) or not because it's not logged, but apologies either way.
<nckx>It's all quite primitive.
<jpoiret>it's all my fault in the end, so no worries there
<jpoiret>although i wonder if there's a plan to migrate to some more "modern" git platform, or if something is preventing it (ie GNU policy)
<nckx>No, and not AFAIK.
<jpoiret>even with the front-end, reading patches pretty annoying
<jpoiret>mhm, then i'll just act as if i had never thought of that. migrating such systems are the biggest pita
<zacchae[m]>nckx: I tried, replacing with "/dev/mapper/jake": no dice... If I understand correctly, it should try to decrypt my drive before even looking for my root filesystem, right? I assumed thats what (dependencies mapped-devices) did, but I don't even get any cryptsetup prints. Anyway, thanks for the help. If even the nckx is unsure, I'll just try installing from another computer
<ivel>Hello
<nckx>I'm not… no. But your assumption is certainly correct, and that is exactly what happens on this machine: GRUB prompts for the passphrase before even showing the menu.
<nckx>zacchae[m]: ☝
<nckx>Hi ivel!
<ivel>I've been trying out guix lately (I like it!) and made a few packages, but every time i try to build anything i get the following error: 'build of /gnu/store/...-ca-certificate-bundle.drv failed', this only happens once, when i run "guix install ..." the second time both the package and ca-certificate are installed succesfully
<ivel>contents of the log https://paste.debian.net/1211598/
<yoctocell>sneek: later tell civodul, I saw your suggestions for the generic-git updater; I will wait a bit and let iskarian take a look before I send an updated revision. :-)
<sneek>Got it.
<nckx>ivel: Hm… are you running Guix System (stand-alone OS) or Guix atop another GNU/Linux distribution?
<nckx>If it's the latter, what are the contents of /var/guix/profiles/per-user/root/guix-profile/lib/locale? That's the location used by default (in guix-daemon.service) for daemon locales.
*nckx → back later.
<ivel>nckx: Yes, I'm using guix on debian, installed via apt
<nckx>Have you run ‘guix pull’ as root? You might also need to run ‘guix install glibc-locales’ as root afterwards.
<maximed>sounds like https:/issues.guix.gnu.org/50264
<nckx>TTYL.
<maximed>nckx: it's the CA certificate bundle derivation which fails to build
<ivel>locales are present in /var/guix/profiles/per-user/root/guix-profile/lib/locale/2.31
<maximed>Presumably, it shouldn't care whether locales are installed in the profile
<maximed>(the G-exp has code like (setenv "LOCPATH" #+(file-append glibc-utf8-locales ...))
<attila_lendvai>robin, i have finished my trezor changes (but haven't sent it to guix-patches. first i through a simpler change as my first). i don't know about any bugs left: https://github.com/attila-lendvai/guix/tree/trezor
<ivel>yeah i installed glibc-locales-utf8 with root and i did a 'sudo -i guix pull; systemctl restart guix-daemon'
<maximed>ivelivel: ‘but every time I try to build anything I get ’ ... How are you building things?
<maximed>* ivel
<maximed>"guix build SOME-PACKAGE"?
<maximed>"guix environment --ad-hoc SOME-PACKAGE"
<maximed>If it's "guix build" or "guix environment --ad-hoc ...", it should be easy to reproduce
<ivel>maximed: sorry, i meant install instead of built
<ivel>build seems to work fine without errors
<maximed>ivel: Maybe do "guix package --export-manifest > manifest.scm"
<maximed>and guix environment -m ../manifest.scm
<attila_lendvai>so, i'm proposing a change for Idris2 (the language) to organize its code for automated bootstrapping. this seems to be welcome by the maintainer, but not merged yet. shall i add the idris2 package to Guix, hooking it on my own fork? or wait until it gets merged, and only package Idris2 afterwards? (may take a long time)
<maximed>Maybe it can be reproduced that way?
<maximed>If it can be reproduced this way, you could try to minimalise the manifest
<maximed>and sent a minimal reproducer?
<radvendii>maximed roptat: Aha! I just had to `guix pull` and now everything works. thank y'all so much for the help.
*attila_lendvai wishes there was a forum-like interface where discussion threads could be started under a specific package
<roptat>attila_lendvai, I would send a patch with your own code, explaining the situation in the message and in a comment, and then we can switch to upstream when they merge your changes
<dhruvin>Announcement/RFC: I'll soon be submitting a patch along these lines for builds.sr.ht upstream. https://paste.sr.ht/~dhruvin/2733df025bedfb675238c67cfc7ef17b0759da88
<dhruvin>maximed: I've changed everything completely. Earlier I was trying to do what guix pull would do, with cache and channels. Now I just straight-up boot a VM inside a VM and let guix pull do its job. Any comments on this?
<ivel>maximed: thanks, i'll try it later today. It does seem to be related to https:/issues.guix.gnu.org/50264 indeed
<maximed>dhruvin: It seems reasonable, though when does "genimg.sh" actualyl save the image?
<maximed>Shouldn't it shut down the qemu after the last ssh?
<maximed>Or is that what 'trap cleanup EXIT' is for?
<dhruvin>maximed: 1) in ./x86_64/root.img.qcow2 2) yes it does that in cleanup call.
<dhruvin>I'd have to say, having the ability to start a substitute server and use it this easily is brilliant. I could just use all packages from host os while building guest os. I'm quite fascinated by it to be honest.
<zacchae[m]>sneek tell nckx I seem to have fixed it by formating my luks drive with --type=luks instead of --type=luks2
<sneek>nckx, zacchae[m] says: I seem to have fixed it by formating my luks drive with --type=luks instead of --type=luks2
<zacchae[m]>lemme try again
<zacchae[m]>sneek: later tell ncks I seem to have fixed it by formatting my luks drive with --type=luks instead of --type=luks2
<nckx>OK, LUKS2 is currently unsupported by GRUB.
<sneek>Got it.
<nckx>I just got back :)
<zacchae[m]>s/ncks/nckx/
<ncks>sup
<sneek>Welcome back ncks, you have 1 message!
<sneek>ncks, zacchae[m] says: I seem to have fixed it by formatting my luks drive with --type=luks instead of --type=luks2
<zacchae[m]>that would do it
<nckx>Guix could check for LUKS2 and warn or even refuse to continue without ‘--skip-checks’.
<nckx>If you're looking for patch ideas 😛
<zacchae[m]>lol sorry ncks. That was my first time trying to use sneek. Meant to send that to nckx
<zacchae[m]>nckx: sounds like a good idea. I'm on a paper grind atm, but will make a note of it and check if its a problem later
<attila_lendvai>the grub repo seems to have quite a few luks2 commits: https://git.savannah.gnu.org/cgit/grub.git/log/?qt=grep&q=luks
<nckx>Yes. Progress is definitely being made, and we're probably not far from support, but last I checked (granted: a few weeks ago) it wasn't ready.
<nckx>Updating GRUB to any version, let alone an unreleased git one, is touchy because it can't be rolled back when it breaks.
<nckx>So this seems like something best worked around in Guix by testing for LUKS2 for now and giving GRUB time to mature.
<attila_lendvai>agreed. i was just surprised that it works for me, but apparently i have converted it to luks1 without even remembering it...
<nckx>We pass a build option to cryptsetup to default to LUKS1 because it's what we support, but it does mean that running the same cryptsetup creation command on Guix will give you a different LUKS header than the exact same command+release number on another distro.
<nckx>Not ideal.
<the_tubular>I got this error : WARNING: (build-self): imported module (guix) overrides core binding `define-public'
<the_tubular>I'm not sure I understand it though
<the_tubular>Could someone explain ?
<maximed>the_tubular: It is because of the recent commit that replaced define-public with a custom define-public*
<maximed>There is a mechanism for ‘opting out’ of these mechanisms I think
<the_tubular>Ohh, I see
<maximed>I'll check how things are done currently
<the_tubular>And what does the custom one do ?
<attila_lendvai>is there an equivalent of default.nix for guix? i.e. a file i can check into a project repo and is picked up by the guix tool?
<maximed>I'm not familiar with nix but I would imagine something like "guix buid -f guix.scm"
<maximed>* build
<maximed>where guix.scm contains a package definition
<maximed>Or see guix channels
<maximed>which are not entirely unlike nix flakes I've heard?
*maximed not familiar with flakes
<attila_lendvai>maximed, makes sense, thanks! but... then there would be duplication between what's in the guix repo, and what's in the project repo... that's not too bad, though. needs to be kept in sync by hand, but it's flexible.
<attila_lendvai>and i can just rely on the last printed line of guix build to return the store path?
<radvendii> https://paste.rs/Ss0 Okay, so now I'm getting this error on one of the dependencies. I'm not sure
<radvendii>i'm not sure why it's cutting off the `/go` at the end of the url
<radvendii>i couldn't find any place that that is happening in `guix/import/go.scm`
<radvendii> `https://pkg.go.dev/github.com/cncf/udpa` indeed doesn't exist, but `https://pkg.go.dev/github.com/cncf/udpa/go` does
<maximed>the_tubular: See https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8531997d2a1e10d574a6e9ab70bc86ade6af4733
<maximed>It fudges the source location of packages
<attila_lendvai>radvendii, you cannot specify git paths into the repo there
<radvendii>really? it seems to work in other cases
<maximed>it's required in some situations for letting "guix refresh -u" (or was it -e?) work with git-reference
<radvendii>oh wait no you're right. it stripped it out of hte other cases as well
<attila_lendvai>radvendii, maybe i'm wrong. it doesn't work when you specify git-fetch args in packages. it may be handled in the go importer.
<maximed>see recent git-fetch patches by Xinglu Chen, Sarah Morgensen and me
<radvendii>okay so is there a way to access a package that's not at the top level?
<maximed>(not yet merged)
<the_tubular>Nice, thanks for the maximed, I'm not sure I understand everything though
<the_tubular>Scheme is still a bit black magic to me :/
<attila_lendvai>radvendii, this is how i'm dealing with it, but i'm new to all this: https://github.com/attila-lendvai/guix/commit/7809d58f4ea10f1b138cc03644946151d879f0ff
<maximed>I'd have expected #:replace ((x . y)) to avoid the warning as I didn't see that warning with the let& patch I suggested ...
<attila_lendvai>radvendii, look for the snippets that delete and move files after the checkout
<maximed>atilla_lendvai: Adding a phase that chdir's into "python" might be simpler
<attila_lendvai>maximed, it caused some issues that i don't remember anymore. it's also nicer that unrelated stuff is not packaged into the source archives.
<attila_lendvai>can i at all copy parts of idris.scm into the idris repo? i mean licence-wise... or is there a way to reference the definitions in guix proper from the guix.scm file in the foreign repo? last time i tried it wasn't enough for both files to be in the same module.
<maximed>attila_lendvai: (define my-idris (package (inherit idris) (name "my-idris") (source (origin my-origin ...)))
<maximed>make sure to import (gnu packages idris)
<maximed>and define->define-public
<attila_lendvai>oh, right, it's define-public! i'm getting tired...
<maximed>And to use the non-exported idris-default-arguments: (define idris-default-arguments (@@ (gnu packages idris) idris-default-arguments))
<maximed>license-wise, if you preserve the license and copyright notice and respect the license, everything should be ok
<lilyp>tfw you collected 100 gigs of garbage only to install stuff from the top again
<iskarian>morning guix :)
<sneek>iskarian, you have 3 messages!
<sneek>iskarian, yoctocell says: No worries, I see that you have been busy with Go and Zig stuff :-)
<sneek>iskarian, yoctocell says: re guess-delim, heh, it seems to be working pretty well so far ;-)
<sneek>iskarian, efraim says: I'd be tempted to stick with gccgo-10 since it'll be the default gcc version when core-updates is merged so it won't be getting bumped. Otherwise every gcc-11 upgrade would force a rebuild of all the go packages for ppc64le
<zacchae[m]>Is there any way to make a fresh install have custom files in your home directory? I tried making my home directory a git repo, but guix detects that the folder exists at first boot and won't populate it with anything ☹️
<lilyp>guix home might help you in the future with that
<lilyp>otherwise not much more than skeletons
<nckx>./pre-inst-env guix environment guix -- make -j1 check-system TESTS="docker-system"
<nckx>gives me consistent XFS I/O errors.
<nckx>Can anybuddy repro?
<blackbeard>hello
<nckx>Hi blackbeard.
<iskarian>nckx, did you mean to have "--pure"?
<nckx>Not really. It shouldn't affect the test in any way.
<blackbeard>hi nckx !
<iskarian>cool, I'll give it a spin
<blackbeard>I am looking to solve some bugs
<nckx>If you can reproduce it with{,out} --pure of course I'd be interested (and puzzled)!
<blackbeard>what's the command to see packages that are outdated?
<blackbeard>maybe I can start there :p
<attila_lendvai>./pre-inst-env guix build -f ~/workspace/idris/idris2/guix.scm doesn't seem to see any of the guix modules. (i get "source expression failed to match any pattern") any hints? (i have pending changes that i need, hence the ./pre-inst-env)
<podiki[m]>barbanegra: https://guix.gnu.org/manual/en/html_node/Invoking-guix-refresh.html
<podiki[m]>could also check out what bugs are being reported for core-updates-frozen
<nckx>blackbeard: There isn't a command quite that magical yet, but ‘guix refresh’ is closest. Note that you should set up a GitHub API key if you want to run it against all packages or you'll be promptly rate-limited.
<blackbeard>ahhh I see
<nckx>Or use --type= to limit yourself to others.
<podiki[m]>speaking of, how is core-updates-frozen? thinking of trying out to see where we're at
<blackbeard>damn microsoft
<maximed>fwiw, IIRC, the rate limiting existed before GitHub was acquired by Microsoft
*attila_lendvai has realized that the package name must be a list, even if it's a toplevel one
<nckx>blackbeard: Another 3rd-party possibility is <https://repology.org/projects/?inrepo=gnuguix&outdated=1&families_newest=2-> It's also far from perfect but it can get you started.
<iskarian>podiki[m], x86_64 is coming along; there are still major issues with other arches
<nckx>blackbeard: And of course see <http://issues.guix.gnu.org/> for other bugs.
<iskarian>there are several world-rebuild fixes pending (so that they can be batched together)
<maximed>attilla_lendvai: Are you sure it doesn't see any guix modules?
<maximed>The ‘source expression failed to match any pattern’ is presumably a syntax error
<nckx>blackbeard: For example, you could add these archive.org URLs that maximed helpfully found to the source fields of the affected packages <http://issues.guix.gnu.org/50568#1>.
<nckx>That's just a random suggestion that should be ‘easy’; do what interests you.
<maximed>though hard to say what exactly the syntax error is without the complete error message and source fle
<podiki[m]>iskarian: thanks. I'm also on x86-64, not running anything too exotic, maybe take it for a spin this week. (guix pull from core-updates-frozen branch, system reconfigure, and reboot I guess for the important bits?)
<blackbeard>nckx: yes! absolutely
<maximed>(make sure the ./pre-inst-env is run within an environment created with "guix environment guix" or the like, an environment from which you would run "make" and "make check"))
<podiki[m]>barbanegra: if you know or are interested in Haskell, we have plenty to do there. ghc has an update patch mostly there, but then we need to update all the haskell package definitions to newer stackage
<maximed>Not sure if that's necessary but I think it is.
<nckx>(blackbeard: If you choose that one, check whether the packages can be updated, first. :)
<blackbeard>podiki: ohhh that would be sweet too, I am actually learning haskell right now
<iskarian>sneek, later tell efraim: cool, that's what I was thinking. Go builds pretty fast anyway.
<sneek>Got it.
<podiki[m]>barbanegra: still learning here too :) We just had some updates on ghc patch, so if that is good to go then we can work up updating packages. (you can see messages on guix-devel)
<podiki[m]>barbanegra: though the haskell ecosystem is...a bit much, from my limited experience
<nckx>blackbeard: Check out guix refresh --type=stackage then! Note that all Stackage packages *should* be upgraded to the same release ‘together’ (the same push; not the same commit).
<nckx>So it's not for everyone.
<blackbeard>ah I see I see
<blackbeard>ok I'll start with "Missing source code"
<blackbeard>and then I'll move to haskell
*nckx → meeting.
<attila_lendvai>is there a way to define a (source (origin ...)) that just build whatever is in ./ and doesn't require ever updating the commit and the hash?
<Noisytoot>attila_lendvai, yes: https://notabug.org/cwebber/mudsync/src/master/guix.scm
<attila_lendvai>Noisytoot, excellent, thank you!
<iskarian>sneek, later tell radvendii: yeah, I recently discovered that right now the go importer can't handle the go project being a subdirectory of a github repo, because github won't let you access that without adding a commit id into the url, like "https://github.com/tweag/trustix/blob/master/packages/trustix"
<sneek>Okay.
<iskarian>the Go spec says that we should be able to go to "https://import-path?go-get=1" to get information about the package, but that breaks with github sub-directories...
<zacchae[m]>lilyp: darn... It'll be ugly, but the best solution I can see is to add a minimal setup script to skeletons. But that means I can't populate private keys in the home directory, so I'll have to store them elsewhere...
<lilyp>I'd say wait for guix home, that's less hacky overall :P
<zacchae[m]>Yeah, it's probably not worth the trouble if I'm going to switch to guix home so quickly.
<stoned-buddha>what is "guix home"?
<zacchae[m]>stoned-buddha: https://guix-home.trop.in/Home-Configuration.html#Home-Configuration
<roptat>stoned-buddha, it's like "guix system" but for your user: it manages your configuration, user services, ... although I think it's not merged in guix yet
<zacchae[m]>It doesn't seem like it has the functionality to setup the user before first boot though.
<stoned-buddha>that's amazing! I am new to guix and it's everything I've been looking for in a system. As an embedded developer I skipped right passed all the "desktop" use cases and dove right into build system management. I am desperately trying to figure out how to replace yocto with this
<iskarian>sneek, later tell radvendii: well, I guess I was wrong, it does work with your package after all; I've seen it fail on e.g. the Azure repos, though.
<sneek>Okay.
<iskarian>sneek, botsnack :)
<sneek>:)
<zacchae[m]>For now, I just make a directory parallel to my home with all of the files I want my user to have, then copy the files over after first boot
<zacchae[m]>If anyone knows a better way to initialize a user before first boot, lmk
<cwebber>ohai
<cwebber>ah mudsync :)
<ronald>quit
<attila_lendvai>guix --long-format-args demand an equal sign, but that prevents the shell from expanding tilde: e.g. --root=~/foo/bar. is this worthy of a bug report?
<civodul>attila_lendvai: i'd say no
<sneek>civodul, you have 1 message!
<sneek>civodul, yoctocell says: I saw your suggestions for the generic-git updater; I will wait a bit and let iskarian take a look before I send an updated revision. :-)
<attila_lendvai>civodul, even if the equal sign is optional for most other programs that i encountered?
<nckx>How do those programs handle optional values?
<attila_lendvai>nckx, they probably don't. args are either a boolean flag, or mandatory. note though, that -f ~/foo works, but --file ~/foo doesn't
<nckx>Guix has a few long options that are optional. Probably not many. I didn't tally them, but guix build --sources comes to mind.
<nckx>I've never heard of ‘command --option value’ though. Looks weird!
<attila_lendvai>...another reason for not writing our own language/parser for "calling" a scheme function from the command line?
<nckx>Even if the programme can unambiguously parse if (for example, hard-coding package/all/transitive as valid values, never packages), a human can't immediately tell.
<nckx>But I assume greater minds have pondered that and found an answer.
<nckx>s/if/it/
<attila_lendvai>people rarely realize that all this --arg parsing is basically a function call where the arguments are passed as a flat string, and every function does its own parsing of it... guix could just call scheme's reader on it (minus the possible necessary escaping hell from the shell)
<nckx>I'm not sure a good CLI makes a good API and vice-versa.
<attila_lendvai>i'm pretty sure that i would be more comfortable and efficient in a lisp REPL (based on my Slime and CL experience; and assuming that all the apps are available as CL libs)
<nckx>Sure.
<nckx>coreutils' ‘ls’ doesn't support substituting ‘ ’ for ‘=’ for optional options, only mandatory ones.
<nckx>Still ambiguous for humans: between ‘ls --color always’ and ‘ls --sort extension’, which will print an error in an empty directory? You can't know just by looking at the command.
<ggoes>probably a basic question, but is it safe to continue a guix pull after this warning? "WARNING: (build-self): imported module (guix) overrides core binding `define-public'"
<ggoes>
<ggoes>this is guix system, with no "nonguix" or extra substitute servers being used