IRC channel logs


back to list of logs

<nckx>rekado: This is nice. I think I'll keep it. Thanks.
*nckx checks another line into the the ‘Me? Oh no, I'll never use a supercustomised emacs, not me’ repo.
<bjc>isn't, like, the whole point of emacs the ability to customize it like crazy? it's a badge of honor for me that i break down in tears when i have to do anything with a minimal emacs
<DynastyMic>Hi, I'm new to Guix.
<DynastyMic>Can I install some software without packaging it?
<bjc>you are probably going to run into issues trying to install something from ‘make install’ or its like
<bjc>it depends on the software's expectations, but traditional unix binaries that expect to live in /usr won't work
<DynastyMic>Yeah, when I run the installation script, I get /home/users/allegro-graph/agraph-7.3.0/install-agraph: No such file or directory
<bjc>you may be able to tell it to install in your home directory or some other, non-guix managed place (eg /usr/local) by passing a ‘--prefix’ argument to configure, or flags for whatever it uses to install
<the_tubular>DynastyMic I use docker for that use case.
<bjc>👆another good option
<DynastyMic>I'm trying to install in /home/user/allegro-graph/tmp
<the_tubular>But yeah, best case scenario is to use the guix package for it.
<DynastyMic>But yeah, I think I'm better just using docker anyway
<DynastyMic>So which packages should I install for docker?
<DynastyMic>there are a few on guix
<DynastyMic>on guix channel*
<DynastyMic>just guix install docker?
<the_tubular>I personally use podman
<the_tubular>It works, but has a few quirks, docker is more tested
<the_tubular>You might have to start the docker daemon DynastyMic
<the_tubular>Podman has no daemon so
<DynastyMic>got you
<vagrantc>what actually sets SOURCE_DATE_EPOCH in the build environment?
<vagrantc>to answer my own question guix/build/gnu-build-system.scm: (setenv "SOURCE_DATE_EPOCH" "1"))
*vagrantc tosses a modest proposal over the wall
<nckx>vagrantc: wat
<nckx>‘You probably didn't mean what you said, I'll passively-aggressively ignore you.’
<nckx>How did *that* start?
<vagrantc>nckx: hrm?
*the_tubular tosses vagrantc over the wall.
<nckx>The NO_REALLY_FORCE_DATE dealio.
*nckx gets torches, pitchforks, and snacks.
<vagrantc>nckx: every once in a while i torture myself and read the threads that lead to that
<vagrantc>originally it was worse, like TEXLIVE_SOURCE_DATE_WE_THE_BEST
<vagrantc>eventually convinced them to switch to FORCE_SOURCE_DATE, where other projects with the same ... thinking ... wouldn't have to re-invent that idea in their own special way
<vagrantc>but... that ship has sailed straight for the lighthouse and narrowly avoided the worst at the last moment
<vagrantc>maybe still a few holes in the hull, but it didn't sink
<vagrantc>so i've got this file where i'm listing reproducibility issues for guix, somewhat akin to
<vagrantc>there was an ancient branch to try and be cross-distro, but that never really took off
<vagrantc>now that i'm working on two distros at the same time while doing a handstand...
<nckx>How did cross-distro not take off?
<vagrantc>i just started actually keeping one locally, but maybe it could be useful to keep it somewhere (publicly?) editable by others
<vagrantc>nckx: mostly by being proposed at a reproducible builds summit and then ... well ... and then brought up at another one ... and ... well ... here we are!
<vagrantc>oh, i guess it was multi-project-syntax
<vagrantc>though i'm noticing a fair number of issues that are distro-specific ... so ... hard to really ... manage a shared list of problems when the problems aren't shared
<nckx>Yes, I was mildly surprised by that implication above. Even if the build environments are quite different, I'd expect the list of behaving and misbehaving packages to be roughly the same.
<nckx>Guess not.
<vagrantc>part of that is because of upstreaming work
<vagrantc>e.g. one of my recent reproducible builds fixes was just updating to a newer version :)
<vagrantc>also, guix normalizes a lot in the build environment, debian intentionally varies things ...
<vagrantc>(well, reproducible-builds testing for debian, although debian too)
<vagrantc>maybe one patches the toolchain, one patches individual packages
<vagrantc>and some things are just inscrutible :)
<vagrantc>one distro hand-picks which files to install in the package, the other just dumps everything it can find as part of the build process, etc.
<nckx>Hey. I resemble that remark.
*vagrantc counts on nckx
<vagrantc>the great thing about some the texlive packages is the builds on ci and bordeaux waffle back between reproducible or unreproducible depending on if they build on the same date
<vagrantc>in a weird way, i actually like timestamps that embed the second, as it's easier to be sure it actually worked
<vagrantc>minute precision is fairly doable
<vagrantc>cbaines: guix data service and bordeaux are proving hugely valueable for this stuff, thanks so much!
<nckx>Sysadmin confusion aside, I wonder how much networking would break if you run bordeaux with the clock a day off.
<nckx>Not a serious suggestion.
<nckx>Unless you wanna.
<vagrantc>we run one debian build on a virtual machine 396 days in the future :)
<vagrantc>also sometimes catches build failures due to expired certificates and such
<vagrantc>woudln't be a bad idea to set up another build farm that's a little more intentially weird to catch reproducibility issues ... bordeaux and ci could be the "reference" build and then ...
<vagrantc>well, we have a lot of work to do :)
<nckx>Catching test suite certificate nonsense would definitely be a feature; I was thinking about url-fetch and such.
<nckx>Although those could easily run on a separate machine.
<nckx>I don't think any of the berlin build nodes have Internet access.
<nckx>Might as well set it to y2039 for good measure.
<vagrantc>and, once you have the infrastructure, automatically run diffoscope on the differing builds ... i should totally automate this process
<nckx>Go on, you've got all weekend.
<vagrantc>i'm currently doing it way too manually
***bingulo_ is now known as bingulo
<nckx>When diffoscoping locally, do you use the HTML or terminal output?
*vagrantc rediscovers for loops on the shell
<vagrantc>nckx: i'm basically doing: guix challenge --verbose --diff=diffoscope PACKAGE 2>&1 | tee PACKAGE.diffoscope
<vagrantc>though i just stuck that in a for loop after "parsing" a .json dump of unreproducible packages from
<bingulo>hi folks, i'm trying my first guix install today. i'm following the manual install method and is in "guix system init" command part. after reapir some issues on my config.scm, I cannot get any informative error other than "failed to load 'config.scm': invalid argument". what that means?
<nckx>bingulo: Is there really no other output? What's the exact command you're running?
<nckx>Also, welcome!
*vagrantc is embarrased that it took this long to stick that in a for loop
*vagrantc wrists are a little angry too
<bingulo>nckx: the exact command is `guix system init /mnt/etc/config.scm /mnt`, as in the guix manual
<vagrantc>hah. abcl. first i thought i was looking at a java package, only to find all sorts of lisp inside!
<nckx>bingulo: Hmkay. I think the installer comes with wgetpaste, otherwise you can simply ‘guix install’ it there. It would help if you shared a link your /mnt/etc/config.scm here.
<bingulo>nckx: I'll try it
<nckx>Or if you are 1337 and want to get fancy with curl, go ahead.
<bingulo>nckx: my config.scm
<nckx>It is very strang that you get ‘invalid argument’. Here's what I get:
<nckx>You're also not doing any local-file weirdness…
<nckx>And just to rule out the obvious: this file is at /mnt/etc/config.scm ?
<nckx>bingulo: Add wm to your use-package-modules, and remove one of the ) after %desktop-services.
<bingulo>nckx: I just realize that I put "certs" twice in (use-package-modules. Now I got the same error as yours
<nckx>Then: (targets "guixcrypto") → (targets (list "guixcrypto"))
<nckx>(I don't know if "guixcrypto" is the right notation, I don't use LVM.)
<nckx>Now it starts building stuff.
<the_tubular>A bit unrelated but I often see those lines in people's config.scm
<the_tubular>Allow resolution of '.local' host names with mDNS. (name-service-switch %mdns-host-lookup-nss))
<nckx>bingulo: It builds!
<the_tubular>Why ".local" there's a standard that should be used
<the_tubular>Why not use this one ?
<bingulo>nckx: yes, I think it's building now, very thanks!!
<bingulo>nckx: So, why I need to specifi a list target in mapped devices "targets" and not in bootloader section?
<nckx>the_tubular: It's not a standard but a proposed standard for one. But it sounds like a question for glibc, not Guix.
<the_tubular>glibc ?
<nckx>bingulo: You should.
<nckx>I didn't read the entire file, I just skimmed it and verified that it builds.
<bingulo>nckx: but why it build without that? I think that it should give an error, don't?
<nckx>the_tubular: Or are you saying the comment is incorrect?
<the_tubular>No, just wondering why this is a glibc question
<nckx>Because nss is part of glibc, but I see that it's a separate package.
<nckx>Explains why I was failing to find any mention of .local in glibc's nss tree :)
<the_tubular>Probably :P
<nckx>s/that it's/that nss-mdns is/, to be clear.
<nckx>Anyway, nss-mdns clearly does answer authoritatively for .local: if ((ends_with(name, ".local") || ends_with(name, ".local."))
<nckx>no mention of this proposal.
<the_tubular>I though it was standard, but apparently not
<nckx>Even when it becomes one, you'll have to talk to <> to implement it. I can't imagine they'll be open to removing .local, though, and .local will always remain unallocated because of its decades of use for this.
<the_tubular>I plan to run my own DNS in the future
<the_tubular>But I have a lot of reading left to do before doing so.
<nckx>I think so:
<nckx>.local is the standard TLD for mDNS.
<the_tubular>Got it.
<nckx>I don't see any mention of it in RFC 7788.
<nckx>the_tubular: I hope you're not planning on reading all RFCs.
<the_tubular>No lol
<nckx>the_tubular: What kind of DNS would that be?
<the_tubular>I don't know yet. I don't even know if I understand the difference between types of DNS
<the_tubular>Well authoritative and
<vagrantc>for being functional programming, all these lisp/scheme dialects sure seem to not be very deterministic in their own code...
<nckx>I know there's a #dns channel but I don't know its quality.
<nckx>vagrantc: Heh.
<nckx>the_tubular: Well, Guix has plenty of servers of both varieties. :)
<nckx>What kind of DNS would you run?
<the_tubular>I'm not sure, as I said I have to do some more learning
<the_tubular>I don't know what types of DNS are
<nckx>I didn't mean ‘kind’ as in type, just informally: what makes you interested in running any DNS in the first place, what would you want it to ‘do’ for you, …
<the_tubular>Ohh my bad.
<the_tubular>Well for 1, having full control of my DNS request.
<the_tubular>2nd Would be to not have to remember all local IPs
<the_tubular>(About 40-ish machine)
<the_tubular>Maybe some type of blackholing
<nckx>(Wow, 40.)
<the_tubular>(Sorry,(Scheme is getting in my brain))
<nckx>(I do this all the time.)
<nckx>(I was not parodying you.)
<vagrantc>ok, reproducibility issues a-clojure roughly cataloged (as well as a bunch of other random ones)
<the_tubular>Well I used "Machine" vaguely, some aren't bare-metal, but VMs
<the_tubular>Blocking ads and domain with low reputation
<the_tubular>I've got a few ideas. Just not enough time :(
<nckx>bingulo: I got distracted by hot DNS chat. I don't know why it didn't throw an error early. Maybe the compatibility code (the field used to be named target, singular, and took a single argument) is too eager? Etc.
<nckx>the_tubular: May I PM you?
<the_tubular>Sure :)
<bingulo>nckx: I think that it should be about guix version diffs. I was consulting latest manual and my image is the stable version, but I updated it with guix pull. maybe target is in depreciation
<nckx>It is.
<bingulo>how can I know if a package will be installed in binary mode or builded?
<kimjetwav>You can go `guix install <package> --dry-run` and it'll tell you whether it'll install or build.
<bingulo>what's the criteria for guix to choose if it will build or not?
<kimjetwav>It checks the upstream continuous integration build farms for whether a known build hash exists for the package you're building.
<kimjetwav>Oh you can also use `guix weather` for that if I'm not wrong.
<bingulo>ah, it makes sense, thanks
<kimjetwav>Basically guix's package definitions (the thing you see when you go `guix edit <package>`) compile down to a monadic derivation which is basically a lisp program for building that package.
<kimjetwav>Each derivation is chained together transitively with all the other derivations for its dependencies.
<kimjetwav>Local package builds are triggered when checking the server for all those derivations and the one you asked for fail to return all of them.
<kimjetwav>So it's a combo of "Does the build farm report it's done this", and "Would I be doing the exact same thing as the build far if I did it here." If the answer to both is yes, you download.
<kimjetwav>You can also force local builds if you want.
*nckx → 😴💤 'night Guix.
*kimjetwav 👋
*apteryx saw a test suite disabled because of YAMA; have we enabled it back in Guix? I see an old news: *** The Linux “YAMA” restricting policy on PTRACE_ATTACH is now disabled
<apteryx>OK, the bug report was
<apteryx>so it affects only foreign distributions
<tom1192>Hi. I'm trying to connect to a Matrix server via Weechat. I've installed weechat and weechat-matrix to my system environment, but my weechat is unable to find the plugin/script via '/plugin' or '/script'. Does anybody know how to help weechat find weechat-matrix?
<tom1192>I guess most weechat plugins are in the right plugin path, by virtue of being in the correct /gnu/store/*weechat/* directory, and weechat has no awareness of /gnu/store/*weechat-matrix*/ ?
<tom1192>I see /run/current-system/profile/share/weechat/python/ exists, so presumably weechat has awareness. I'll try to trace through the relevant load paths.
<tom1192>/python load /run/current-system/profile/share/weechat/python/ <<<< worked! (Just the basename did not.)
<tom1192>Stracing weechat, I can see that it's not looking in any directory under /run/current-system. I'll raise this as an issue.
<apteryx>tom1192: try installing weechat and weechat-matrix to your *user* profile
<apteryx>otherwise the bug you encountered is already known as #20255, the oldest bug in GNU Guix
<tom1192>apteryx: Thanks! Very handy to see the history of this and see it's a bigger problem.
<lilyp>damn, i missed 55900
<tomog[m]>I see that there are two types of kernels: -generic kernels, which use defconfig, and non-generic kernels, which use a kernel from aux-files. Why do both exist? Is the idea that we are in a transition step towards there being just one type?
<jpoiret>apteryx: about your jami error
<jpoiret>the shepherd service internals don't seem to use with-imported-modules with the set of modules given
<jpoiret>which is understandable, since each service shouldn't modify the load-path
<jpoiret>have you rebooted since?
<jpoiret>maybe a crev integration could be interesting in guix?
<jpoiret>i ended up there because of
<futurile>Happy weekend Guixers!
<denna[m]>I saw this video i wonder if it is true that guix dont have modules in the sense of nix. I saw something similar for the basic System Continuation in the documentation but have not seen hif/ow user applications can be configured by guix.
<unmatched-paren>denna[m]: i'm not sure how nix modules work, but if you're talking about traditional modules, guix uses guile's module system.
<unmatched-paren>applications can be configured in guix by way of Guix Home services
<unmatched-paren>although there isn't that many of them yet
<rekado>denna[m]: we’ve got system services (not to be confused with systemd services), which compose in a well-specified manner.
<rekado>the graph of system services is used to control any aspect of the eventual system state: user accounts, one-shot initializations, shepherd services, etc
<rekado>I would not want to replace this well-specified, declarative, and functional mechanism for the ad-hoc world of NixOS modules.
<denna[m]>An example of a nix module is for example this file that can be used to configure emacs
<rekado>we would use service extensions instead
<denna[m]>Any example for a user facing application? ... but i am also searching online right now
<unmatched-paren>how would you configure emacs without emacs lisp tho? seems like it'd be a bit limited?
<reyman>Hi guixguys
<rekado>denna[m]: for per-user stuff you’d use guix home services, but since Guix Home is pretty new we don’t *have* all that many Home services yet.
<reyman>I have one question unmatched-paren about some dotfile you share
<unmatched-paren>oh? fire away :)
<reyman>What the difference between and ?
<unmatched-paren>oh, i thought i deleted home.scm
<unmatched-paren>conf is the updated version :)
<unmatched-paren>reyman: home.scm is gone now
<reyman>ok :)
<unmatched-paren>i changed it because i wanted to store both my home AND system configurations, and because i'd pretty much completely overhauled my home configuration
<denna[m]>rekado: I guess it's this for example
<unmatched-paren>huh, rde provides an emacs service
<unmatched-paren>yes, that would be equivalent
<unmatched-paren>except instead of using a string as the elisp config, it uses a scheme expression, seemingly
<reyman>So the good config to look into ?
<unmatched-paren>reyman: yeah
<reyman>i see only home.scm
<reyman>but you say it's gone, i'm lost lol
<unmatched-paren>reyman: home.scm in that tree?
<unmatched-paren>that isn't gone
<unmatched-paren>it's the home.scm repository that contained my old config.scm that's gone :)
<reyman>ok right ! :)
<unmatched-paren>there's also system.scm in there
<denna[m]>unmatched-paren: Ah i see rde is not exactly guix. ...
<reyman>yeah i better understand this home.scm way to do, much more similar to doc :)
<unmatched-paren>denna[m]: yeah, it's kind of an extension to guix
<unmatched-paren>although that emacs service could probably be merged into guix proper
<unmatched-paren>reyman: where did you find that repo btw? were you just looking at the logs?
<unmatched-paren>(just interested ;)
<unmatched-paren>reyman: i'd be happy to answer any questions about what any part of ~unmatched-paren/conf is for
<reyman>yes @unmatched-paren, coming from the nix bazar, i'am used to look on github/ dotfile config
<unmatched-paren>ah, you found it searching on
<reyman>Nop i found via log here for your :) Some people on mailling list also give me link for their dotfile, like @dominicm :
<reyman>that help me A LOT as a begineer on guile/guix :D
<unmatched-paren>ah, i see :)
<reyman>creating one page listing awesome dotfile with guix home could be cool for noob like me :)
<unmatched-paren>i'm sure that would fit well on
<reyman>great !
<unmatched-paren>i'm in the process of upstreaming my aerc package now. would anyone be interested in that?
***avp_ is now known as avp
<sughosha>Hi all, `guix pull` is giving the following error, if someone can help me that would be great:
<sughosha>(repl-version 0 1 1)
<sughosha>Generating package cache for '/gnu/store/gm2cxwfcfp5nmwdxfsi05zh218d2rvvy-profile'...
<sughosha>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (libpng-1.2)) (value #f))
<sughosha>Thanks in advance.
<rekado>sughosha: this means that one of your channels references libpng-1.2, but there is no variable with that name.
<rekado>sughosha: you should report this to whoever maintains the channel
<sughosha>rekado: the channel is the Guix's default channel. Also this error doesn't occur with `sudo`, only without sudo.
<nckx>sughosha: Cat you run ‘mv ~/.cache/guix/checkouts{,.bak}’ and then try again?
<nckx>*Can 🐈
<sughosha>nckx: I tried it but still the same error :(
<nckx>Please share the full output of guix pull at, then, I guess.
<jpoiret>sughosha: do you use other channels?
<jpoiret>i was able to build the latest master
<sughosha>jpoiret: yes, I use two more channels on top of the default channel.
<jpoiret>it's possible that the other channels are causing issues
<jpoiret>libpng-1.2 was removed
<nckx>Thanks, but you should have just mentioned that you use other channels when told earlier.
<nckx>Now we both wasted time.
<nckx>sughosha: rek ado already gave you the answer, just follow their advice.
<sughosha>nckx: sorry for that...
<jpoiret>shouldn't be an issue with the aforementioned channel though, it has never referred to that variable i think
<nckx>sughosha: Meh :)
<nanounanue>hi everyone
<nckx>jpoiret: Uhm: ("libpng" ,libpng-1.2)
<nckx>Hi nanounanue.
<jpoiret>zamn, i don't know what's wrong but both ripgrep and git grep (and gitlab search) ignored that
<sughosha>jpoiret, nckx: thanks for both of you for taking your time to help me. I found out that `games` channel I used refers to libpng-1.2, I just grepped the channel's git folder and found this out. I will report them.
<jpoiret>🤡 i was looking at the wrong channel
<jpoiret>first time seeing channel dependencies in action
<nckx>Ah :)
<jpoiret>what do we think of adding a bigger backtrace to the package-cache-file profile hook?
<nanounanue>maybe someone could point me to a reference: I want to develop a python package, but I want to create a guix package for it. how should I set up the environment ?
<jpoiret>do you already have some existing code, or none at all?
<nanounanue>i have already code
<unmatched-paren>nanounanue: you'd create a `guix.scm` in the project root that evaluates to a package using python-build-system
<unmatched-paren>do you know how to write a package?
<nanounanue>I read the documentation, and I have a private channel but only using guix import
<nanounanue>so probably not very well
<nanounanue>I am confused about the workflow
<unmatched-paren>i see. should be easy enough for you to look at a package in python-xyz.scm in the guix channel and figure out how to make your own one, except for the source
<unmatched-paren>you'd replace the source with (local-file (dirname (current-filename)) #:recursive? #t)
<unmatched-paren>as in, (source (origin ...)) becomes (source (local-file ...))
<nanounanue>thank you!
<unmatched-paren>and then change all the fields in the package to suit your new one -.o.-
<nanounanue>what about the workflow
<nanounanue>how do I test it?
<civodul>unmatched-paren: (local-file "." "dir" #:recursive? #t) should be enough
<nanounanue>just edit and then repackage and then import it?
<unmatched-paren>you'd bind the new package to a variable (define python-mypkg (package ...)) and return it at the end of the file with `python-mypkg`. you can test it by running `guix build -f guix.scm` or `guix shell -f guix.scm`
<unmatched-paren>civodul: that wouldn't work if you're in, say, src and you run `guix build -f ../guix.scm`, would it?
<nanounanue>should I create and environment I supposejow do I mix the manifest.scm and the guix.scm
<unmatched-paren>nanounanue: well, what does your manifest contain?
<nanounanue>python jupyter and other python packages
<nanounanue>there are also some missing python packages in the guix, but I can import them from pypy
<unmatched-paren>nanounanue: the ones that are required to build your package should be given as propagated-inputs in the (package ...). (usually you'd use inputs or native-inputs but python is --annoying-- different)
<unmatched-paren>the ones that aren't required, but helpful in development, should probably go in the manifest
<nanounanue>thank you!
<nanounanue>one last question
<unmatched-paren>by the way... does anyone else think a --backend=list would be helpful for guix graph?
<nanounanue>if I am defining several packages, I should return them at the end of the guix-package, right?
<unmatched-paren>it would output a textual list of packages, and the packages would be sorted into an order such that packages only depend on packages below them
<unmatched-paren>nanounanue: are there literally multiple possible buildable packages, or are those other ones just dependencies?
<unmatched-paren>also, `--module` and `--not-module` flags; `guix graph --not-module '(gnu)' foo` would return all dependencies of foo that are not in the gnu module
<unmatched-paren>then, if somebody wanted to upstream a package from their own channel, they could do `guix graph --backend list --not-module '(gnu)'` to get a list of everything they need to upstream
<unmatched-paren>and the list would be sorted such that if they went down the list, upstreaming and committing one package at a time (as you're supposed to do), there would be no commits that don't work
<unmatched-paren>other kind-of-related idea: `guix import graph`
<jpoiret>what's the lowest Guile a Guix has ever used?
<jpoiret>i'd love to use (backtrace) but its usage has change from guile 1 to guile 2
<unmatched-paren>`guix import graph rust foo-bar --backend list` would output all the dependencies of foo-bar in the order that they need to be packaged in
<unmatched-paren>these features would have made packaging and upstreaming aerc much easier
<unmatched-paren>`guix import graph go --backend list`, go down the list, importing and packaging each one
<unmatched-paren>then when it's time to upstream it, `guix graph aerc --not-module '(gnu)' --backend list`, then upstream each one in order
<unmatched-paren>maybe it could be `--channel` and `--not-channel` instead, so `--not-channel guix`
<unmatched-paren>does (inputs ...) override or extend the build system's default inputs?
<jpoiret>the build system's default inputs are separate from the regular inputs
<lilyp>build systems add implicit inputs to the package, but you can make them explicit.
<unmatched-paren>i see.
<jpoiret>you can have a look at lower from (guix build-system gnu)
<unmatched-paren>ah, #:implicit-inputs
<unmatched-paren>wait, no.
<unmatched-paren>looks like build-inputs gets populated by splicing inputs and the standard inputs into a list?
<unmatched-paren>that's what i meant by extending them
<unmatched-paren>oh, never mind.
<unmatched-paren>just noticed that host-inputs holds inputs, and build-inputs (standard-packages).
<unmatched-paren>so i can remove the implicit build-inputs by setting #:implicit-inputs? #t
<unmatched-paren>thanks lilyp and jpoiret
***jesopo is now known as jess
*nckx is back to being unable to reproduce <>
<unmatched-paren>is $PREFIX set implicitly before a build is run?
<jpoiret>line 290 of guix/build/gnu-build-system.scm says likely not
<jpoiret>rather, it's the --prefix argument of ./configure that's used
<unmatched-paren>jpoiret: hmm, okay... i would have thought it would be passed as an implicit `make install` flag for packages that don't use autotools
<jpoiret>for other build systems, i don't know, you'll need to dig through their /build/.scm file
<nckx>unmatched-paren: No.
<nckx>I don't think that would be a good idea.
<jpoiret>nckx: ! hopefully should make guix pull package cache errors more descriptive :)
<jpoiret>just tested with that guix-games channel, it does print where the error actually occurs (surrounded by the usual raise-exception lines though)
<nckx>Why older Guile versions?
<jpoiret>guix pull could interact with very old guix versions
<jpoiret>(that part is run in the inferior, hence possibly with an old guile iiuc)
<maximed>Did the first version of GUix supporting channels support Guile 1?
<jpoiret>i asked above, but better be safe than sorry :p
<maximed>I thought we could assume at least Guile 2
<jpoiret>if it's the case then it could be made simpler, definitely
<nckx>jpoiret: Oh. This is odd. <>: ‘guile-2.0.0.tar.gz - 2011-02-16 — Guix git log: ‘Add GNU Guile 2.0, released today! - Sat Jul 7 18:41:16 2012’
<nckx>jpoiret: Would anyone ever pull from Guile 1, though? I think it's overkill to assume <2.
<unmatched-paren>what does this guix lint message mean? checking go-github-com-protonmail-go-crypto-openpgp@0.0.0-20220517143526-88bb52951d5b [inputs-should-not-be-input].
<unmatched-paren>never seen [inputs-should-not-be-input] before.
<maximed>jpoiret: Since commit ‘Augment `README', Guix required Guile 2.0.X
<maximed>that's from before Guix even had a Makefile or any actual packages.
<nckx>It notably predates ‘guix pull’ just an itty smidge.
<jpoiret>and `guix repl`
<nckx>I was probably too subtle: drop it.
<nckx>Still wonder what those very different dates mean, but who cares.
<jpoiret>i really liked launching the Guile 1 repl though. very different from today
<nckx>unmatched-paren: It just means that something is an input that shouldn't be. But it should tell you what.
<nckx>unmatched-paren: (G_ "'~a' should probably not be an input at all")
<nckx>Did it not?
<unmatched-paren>it doesn't tell me what, no
<nckx>In practice, it only checks for python-setuptools & python-pip.
<nckx>But it should still print a message. Odd. I'm saying ‘odd’ a lot today.
<unmatched-paren>it only has (propagated-inputs (list go-golang-org-x-crypto))
<maximed>when it says 'checking PACK [linter]’, that only means it is chacking PACK with [linter].
<unmatched-paren>maximed: makes sense
<maximed>it doesn't mean the linter detected a problem.
<nckx>But it should go away if that's the case.
<maximed>E.g., if the next linter run is rather slow, contacting the network, that line could stay for a while
<unmatched-paren>ok, i'll ignore it then -.o.- but that message only appears for this package
<nckx>I doubt that.
<unmatched-paren>well, for the others it disappears quickly i guess.
<nckx>So it crashes or prints a warning after this one? Causing it to remain on screen?
<maximed>unmatched-paren: maybe you pressed entered or pressed spacebar+delete such that Guix was unable to properly tell the terminal to delete the line?
<nckx>Heh, also possible 😛
<maximed>(Sometimes happens to me)
<unmatched-paren>only the "no tags" one, and maximed no it happens consistently
<unmatched-paren>but no tags happens for other packages, and that line doesn't appear for them
<nckx>I think I have an answer.
<nckx>This package spec is redonkolong.
<nckx>Is it wider than your terminal?
<nckx>That would cause the cursor to ‘fall off’ and the previous line not to be erased as expected.
<unmatched-paren>one character more and it would be
<unmatched-paren>oh, right
<nckx>That was a fun one. Thanks.
<unmatched-paren>thanks :0
<nckx>At least in other languages, there are terminal libraries that could probably handle that (and do other fancy things like real-time multi-line status updates) but it might be overkill here.
<nckx>I'm guessing Guix just echos \r\e[K and calls it a day.
<unmatched-paren>go package names are ridiculous
<nckx>guix lint: warning: Version string does not contain the author's telephone number and/or postal address.
<nckx>Supply chain attack detected.
<unmatched-paren>guix lint: note: Falling back to randomly guessing contact details.
<unmatched-paren>guix lint: note: Using contact details to send threats to the person who put this many dependencies in go.mod.
<lilyp>we need a .fetch tld
<nckx>unmatched-paren: Better CC everyone mentioned it ‘git log’ with crash reports, to be sure.
<lilyp>then someone needs to reserve me.fetch and they can create package names like "go-fetch-me-a-beer"
<unmatched-paren>nckx: And everyone who's ever posted to the project mailing list, we don't want to miss anyone!
<unmatched-paren>lilyp: that would just be
<unmatched-paren>unlike java domain names are not reversed
<nckx>Well, Guix adds the go-.
<civodul>maximed: Guix was written after Guile 2.0 had been released (fortunately :-))
<unmatched-paren>me.fetch would be go-me-fetch-a-beer.
*civodul sent a Home SSH service:
<nckx>civodul: We might have over-hyped guix time-machine.
*unmatched-paren was excited for a moment, thinking it was a home-ssh-agent service :)
<unmatched-paren>what's the openssh service used for?
<unmatched-paren>a configuration file...?
<unmatched-paren>yeah, looks like it
<Michal_Atlas[m]>Can I somehow get the package version information in a build phase?
<lilyp>unmatched-paren: that makes things somewhat easier
<unmatched-paren>nckx: if you thought go-github-com-protonmail-go-crypto-openpgp was bad, how about go-github-com-protonmail-go-crypto-internal-byteutil?
<nckx>Michal_Atlas[m]: Yep, with (package-version this-package).
<nckx>Use #$ or , according to how your (arguments …) are written.
<nckx>unmatched-paren: Assuming go-github-com-protonmail-go-crypto-openpgp uses go-github-com-protonmail-go-crypto-internal-byteutil, and we discover a bug in go-github-com-protonmail-go-crypto-openpgp that requires a patched version of go-github-com-protonmail-go-crypto-internal-byteutil, we'll have go-github-com-protonmail-go-crypto-internal-byteutil-for-go-github-com-protonmail-go-crypto-openpgp.
<unmatched-paren>nckx: beautiful, but sadly go-crypto-openpgp doesn't depend on go-crypto-byteutil
<nckx>Not *yet*.
<unmatched-paren>in total there are six of those packages
<Michal_Atlas[m]><nckx> "Use #$ or , according to how..." <- Thanks, I'm still confused but at least I know what to try look for. 😅
<nckx>Why are you confused? :)
<unmatched-paren>go-github-com-protonmail-go-crypto-bitcurves, go-github-com-protonmail-go-crypto-brainpool, go-github-com-protonmail-go-crypto-eax, go-github-com-protonmail-go-crypto-internal-byteutil, go-github-com-protonmail-go-crypto-ocb, go-github-com-protonmail-go-crypto-openpgp
<jorge[m]>Hola en Guix GNU Hurd. Could not load a pixbuf from icon theme.
<jorge[m]>This may indicate that pixbuf loaders or the mime database could not be found.
<nckx>Maybe by the preponderance of #$version and ,version over the ‘more correct’ (package-version this-package). I can relate. I find the former habit hard to break as well.
<jpoiret>jorge[m]: what are you trying to launch?
<Michal_Atlas[m]>nckx: Well, The first looks like a gexp thing, which I'm not too comfortable with yet, and I don't see a way to refer to the package itself.
<nckx>‘this-package’ is literal. It always refers to the current package.
<Michal_Atlas[m]>In that case I'm probably doing more fundamental mistakes, I thought that, but it states unbound variable this-package
<nckx>Gexps can look scary but in most contexts #~(gexp #$ungexp) is equivalent to `(quote ,unquote), and you'll quickly start reading them the same way.
<nckx>That sounds like you're not unquoting/gexping it.
<unmatched-paren>it's basically just #~(this thing will be evaluated inside the build environment #$(but this won't)) iiuc.
<nckx>Which is how we used quotes for ages :)
<nckx>‘Code staging’.
<nckx>Michal_Atlas[m]: Simplest example I stumbled upon:
<unmatched-paren>which makes me wonder: what's the point of gexps existing when you can do the same thing with quote/unquote?
<nckx>By your reaction to gexps I'm guessing you're not using gexps.
<nckx>That was for Michal_Atlas[m].
<maximed>unmatched-paren: with-extensions & with-imported-modules & the #$/#+ distinction important for cross-compilation
<maximed>you can't do that (easily) with quasiquote/unquote
<unmatched-paren>maximed: what's the difference between #{$,+}?
<nckx>unmatched-paren: Did you read (guix)G-Expressions yet?
<nckx>#+ means ‘native’.
<Michal_Atlas[m]>Yeah, huh, they just weren't #:used but now it states no code for module (guix gexp)
<unmatched-paren>i've skimmed over it
<maximed>Also: G-exps can theoretically support (a degree of) lexical hygiene (there's a draft branch wip-gexp-hygiene for that, not yet merged yet though)
<Michal_Atlas[m]>nckx: A few times, sorry for being a pain rn
<maximed>Michas_Atlas[m]: What's #:used?
<nckx>Michal_Atlas[m]: You are no such thing.
<maximed>I don't think the keyword #:used is used anywhere in Guix?
<maximed>Or do you mean #:use-module?
<Michal_Atlas[m]>I meant in the #:use-module it didn't include them, which I presumed I needed to do
<jorge[m]><jpoiret> "jorge: what are you trying to..." <- La Imagen de máquina virtual con un sistema Guix completo sobre GNU Hurd.
<nckx>I'd guess it's short-hand for #:use-module…
<maximed>Michal_Atlas[m]: Yes, that's necessary.
<Michal_Atlas[m]>Maybe it'll be easier to just say, what I'm trying to do
<nckx>You don't *need* to use gexps to use this-package, by the way.
<nckx>I'd get one working before the other.
<Michal_Atlas[m]>I noticed that chicken-status marks a lot of eggs that I tried adding as "unknown-version" which seems to happen whenever eggs don't include that in their .egg file, which is most of the times. So I thought I could just include it if it isn't in there, to fix the problem, hopefully it being a learning experience.
<Michal_Atlas[m]>*they don't include the version information
<nckx>Sounds good.
<nckx>So you're modifying an existing package?
<Michal_Atlas[m]>Umm, well, if it's an issue with most packages I figured it'd make sense to try edit the build-system
<Michal_Atlas[m]>and add an insert-missing-version step or something similar
<nckx>It makes what you're trying to do a bit harder though.
<Michal_Atlas[m]>I can't figure out how to get the version information in the function I register as the build-step
<Michal_Atlas[m]>I understand that
<nckx>I'm on shaky ground here but I think you'd have to use hyphen-separated-name->name+version?
<nckx>The ? is not part of the name, just part of me right now.
<nckx>Basically, at this point & level, the niceties of package records have been replaced with the hard reality of the store, and you need to ‘parse’ the /gnu/store/hash-name-version file name to get the info.
<nckx>But someone might correct me if I'm wrong.
<Michal_Atlas[m]>It seems to be a hard reality
<Michal_Atlas[m]>Why can't I ever find the functions you mention in the manual.
<maximed>FWIW with some tweaks to package->bag etc it should be feasible to pass the version to the build system
<maximed>Michal_Atlas[m]: many procedures in (guix build utils) are currently undocumented -- a documentation bug/missing feature
<Michal_Atlas[m]>Oh alright, thank you
<maximed>You'll have to use "git grep -F hyphen-separated-name-\>name+version" or the like to search for them
<nckx>Michal_Atlas[m]: Yes. I don't even look in the manual, unfortunately.
<maximed>often they have at least a docstring in the definition.
<nckx>maximed: FWIW you should be correct.
<nckx>I had a bit of a rosy view of self-documenting lisp systems before actually dipping into Guile. When it's great, it's great, but it seldom is.
<nckx>Speaking of build system things that should exist: a default phase to search for & report & possibly destroy .pyc files/ELF files/other binary ne'erdowells in sources…
<maximed>nckx: Agreed (though maybe in a snippet instead, to avoid leaving pitfalls for "guix build --source ..." && unpack && ./configure && make users?)
<maximed>And because sometimes binaries impose extra license conditions.
<nckx>I wrote phase whilst I was writing a snippet. Moet je kunnen.
<nckx>The challenge would be not returning a repacked tarball if there was nothing to remove. Which might be to big of a challenge, after skimming the code.
<maximed>We could have both: a procedure (to invoke from a snippet) for cleaning up what goes in "guix build --source", and a phase for verifying that the packager hasn't forgotten to add the phase
<nckx>Excellent suggestion.
*nckx backspaces.
<nckx>You often do my typing for me. Is nice.
<maximed>a little more extra work for the packager, but straightforward and saves CPU & I/O for repacking
<nckx>Repacking everything just in case is straight out.
<nckx>One day we'll normalise the output of sources & guix build -S to always be a whatever, and we can revisit automating it.
<foobarxyz>Hi, I can't seem to be able to lint via pre-inst-env, is this right? If so, how do i lint modified guix package definitions? thanks
<foobarxyz>src/guix/pre-inst-env guix lint gcc
<foobarxyz>guix: lint: command not found
<foobarxyz>hint: Did you mean `lint'?
<foobarxyz>Try `guix --help' for more information
<maximed>foobaryxyz: Run ./pre-inst-env from the git checkout
<maximed>and not from two directories upwards
<maximed>(I don't know if this matters)
<kaelyn> speaking of gexps, is there a way to use `substitute-keywords-arguments` with package arguments that are gexps instead of lists?
<maximed>kaelyn: Yes
<maximed>the same way as for sexps(≃ lists).
<maximed>just replace ` by #~ and , by #$
<foobarxyz>maximed: I get the same thing:
<foobarxyz>./pre-inst-env guix lint gcc
<foobarxyz>guix: lint: command not found
<kaelyn>Then perhaps it was modify-phases that complained for me recently...
*kaelyn tries to repro the issue they saw a few days ago
<maximed>foobarxyz: did you run "make" before ./pre-inst-env?
<maximed>"make && ./pre-inst-env guix lint gcc" (such that all things are properly compiled when testing modifications)
<foobarxyz>maximed: same result:
<foobarxyz>$ make && ./pre-inst-env guix lint gcc
<foobarxyz>make  all-recursive
<foobarxyz>make[1]: Leaving directory '/home/chaos/src/guix'
<foobarxyz>guix: lint: command not found
<kaelyn>maximed: Thank you for the example! I'm guessing I didn't have the #~ and #$ in the right spots
<maximed>foobarxyz: What does ‘stat guix/scripts/lint.go guix/scripts/lint.scm’ say?
<kaelyn>I ran into the problem trying to improve the guix.scm that's in the emacs-guix repo. I was trying to rewrite it with gexps to add its extra phase to the phases from the inherited emacs-guix, to replace it appending a second #:phases keyword to the argument that also just modifies %standard-phases
<maximed>foobarxyz: What is the output of "./pre-inst-env guix lint --help"?
<maximed>(the full output, maybe there's a message before ‘guix: lint: command not found’)
<foobarxyz>maximed: ./pre-inst-env guix lint --help
<foobarxyz>guix: lint: command not found
<foobarxyz>hint: Did you mean `lint'?
<foobarxyz>Try `guix --help' for more information.
<foobarxyz>maximed:  have been using ./pre-inst-env guix build fine for a long time now, so it is not that nothing works)
<maximed>Is "./pre-inst-env guix lint" the only impacted command?
<maximed>i.e., do you get the same for "./pre-inst-env guix refresh/deploy/system/git --help"?
<foobarxyz>maximed: build and gc commands work, describe and lint don't as an example
<foobarxyz>maximed: refresh and git work, deploy and system don't
<maximed>Maybe your guix checkout is too old?
<maximed>Can be tested with "git log becfa42ea79feb402fe6bc5922da2019ef021e88..HEAD | tail" by looking if it outputs something or not
<foobarxyz>maximed: I've /bootstraped/configured/make guix in a pure environment, running guix on top of ubuntu, if that helps:
<foobarxyz>guix environment guix --pure
<maximed>(no output: rather old)
<foobarxyz>@maximed: I've recently updated it, so I get a lot entry:
<foobarxyz>maximed ^log
<PotentialUser-60>i managed to get a fork running using i customized a xkeyboard-config in the xorg.scm file
<PotentialUser-60>how do i install it on the system level ?
<maximed>foobarxyz: Could you do the replacement in guix/ui.scm & run make & ./pre-inst-env again?
<maximed>(for some extra debug information)
<maximed>PotentialUser-60: I've heard that "guix system reconfigure" works from a ./pre-inst-env
<maximed>So you can do "./pre-inst-env guix system reconfigure" to reconfigure your system with your modified Guix.
<maximed>foobarxyz: Or maybe better do the following change:
<foobarxyz>maximed: the first change gave me this (assumeing I applied the patch correctly, I'll do the latter next:
<maximed>(this catch-all 'misc-error seems suspicious to me, it doesn't match the error message below -- what if the command actually exists, but (guix scripts command) has a line throwing a 'misc-error for whatever reason?)
<maximed>foobarxyz: oops I shouldn't have put a ( ... ) around command
<PotentialUser-60>thanks maximed i'm trying this
<PotentialUser-60>is 1.3.0 stable branch to run as a main driver or is it recommended to use master ?
<PotentialUser-60>i want to customize some minor stuff in order to test out guix first, something easily usable would be good
<unmatched-paren>PotentialUser-60: don't use 1.3, it's not really a "stable" branch
<unmatched-paren>guix is rolling release, you should always follow master
<foobarxyz>@maximed: ./pre-inst-env guix lint gcc
<foobarxyz>;;; (what (misc-error #f "no code for module ~S" ((json)) #f))
<foobarxyz>guix: lint: command not found
<unmatched-paren>the only thing stable about 1.3 is the installer disk :)
<maximed>foobarxyz: Issue found?
<PotentialUser-60>ok go for master
<maximed>You don't have guile-json in the environment or such, maybe redo "guix shell -D guix" & ./bootstrap && ./configure --localstatedir=/var && make etc?
*maximed writes a bug report for overly-general catch clause
<foobarxyz>maximed: I'll initiate a clean rebuild with "guix shell -D guix" this time, I was using "guix environment guix --pure" before, if this was likely to be the problem
<maximed>maximed: guix environment guix --pure should be fine.
<maximed>Just make sure the version of guix you run "guix environment/[shell -D] guix --pure" with is sufficiently recent
<maximed>Because IIRC old versions of the Guix (and hence, the Guix package in old versions of Guix) don't use guile-json/ have guile-json in inputs
<foobarxyz>maximed how do I make sure the guix "executable" is up to date? I was advised recently on this channel not to install it using guix install guix
<maximed>foobarxyz: guix pull
<maximed>& setting up ~/.bash_profile (or was it ~/.profile or both?) appropriately
<maximed>As a test, you can run "which guix"
<maximed>it should point to somewhere in ~/.config/guix/current/bin/guix
<foobarxyz>maximed I did guix pull recently and should be fairly recent (i'll try again once the guix rebuild is done); The correct one to setup is ~/.profile, i was caught up by this before
<foobarxyz>which guix
<foobarxyz>maximed /home/foobarxyz/.config/guix/current/bin/guix
<maximed>foobarxyz: looks good from here
<unmatched-paren>would someone kindly be able to review my aerc patchset when it comes through to debbugs?
***A_Dragon is now known as resv
<unmatched-paren>it's arrived! :D
<nckx>‘#41’ 👀
*nckx not it, sorry, busy.
<unmatched-paren>nckx: it's go, of course there's that many :)
<avp>Hello Guixers.
<foobarxyz>maximed: after a guix pull, and guix shell -D guix, make clean && bootstrap && configure .. && make -j, I am stil getting the same error when I run ./pre-inst-env guix lint gcc
<foobarxyz>;;; (what (misc-error #f "no code for module ~S" ((json)) #f))
<foobarxyz>maximed: (by "configure ..." above I meant to say "./configure --localstatedir=/var" it is just that I typed it by hand here)
<nckx>Hullo Aurora & avp.
*nckx puts out ☕ ☕.
<Aurora_v_kosmose>Coffee~ Apparently I have the font required to display that installed.
<avp>Thanks for the plain-text coffee, nckx
<nckx>Hardly plain, but my pleasure.
<foobarxyz>Hi anyone else willing to help with the  error I get when I run pre-inst-env guix lint gcc? maximed seems to have signed off
<foobarxyz>./pre-inst-env guix lint gcc
<foobarxyz>;;; (what (misc-error #f "no code for module ~S" ((json)) #f))
<foobarxyz>guix: lint: command not found
<foobarxyz>hint: Did you mean `lint'?
<foobarxyz>Try `guix --help' for more information.
<foobarxyz>The ;;; (what ...) part in the output is from instrumentation code I placed in guix/ui.scm as per maximed instructions:
<foobarxyz>So far I've done guix pull, and updated to the late guix source, and done make clean, bootstrap, configure, make, but the issue persists; guix is at /home/foobarxyz/.config/guix/current/bin/guix, and I'm running on ubuntu
<nckx>So you're in a guix environment/shell?
<foobarxyz>I configure/build guix  from source in a guix env/shell, but I run the pre-inst-env guix lint gcc from a top level bash shell (where I usually run the guix search, guix install etc commands)
<nckx>Then there's your problem.
<foobarxyz>even if I run the pre-inst-env guix lint gcc from a env/shell, i still get the same error
<nckx>Which command to you use to enter it?
<foobarxyz>normally I use guix environment guix --pure, but I've also tried with guix shell -D guix on maximed's suggestion, though he said both should be equivalent
<unmatched-paren>foobarxyz: `guix shell` is the new command; `guix environment` is deprecated because the command-line interface for it is a bit weird. you should generally use guix shell
<nckx>They should be, but what is the actual command please.
<nckx>Just that?
<nckx>‘Normally’ = you're using environment now?
<nckx>What's $GUILE_LOAD_COMPILED_PATH in the environment?
<foobarxyz>I have been mainly using guix environment to build guix from source and dive in into packages that build with -K and failed
<foobarxyz>guix shell only came to my attention a few days ago
<foobarxyz>so I have been building succesfuly with pre-inst-env build blah blah
<foobarxyz>pre-inst-env guix build blah blah
<foobarxyz>and I've only now tried pre-inst-env guix lint to lint an update I've been working on, and I got the above error message
<unmatched-paren>try `guix lint -L . PACKAGE` without pre-inst-env
<foobarxyz>`guix lint -L . gcc` has worked from within the root of the guix src dir
<Noisytoot>nckx: Does clicking on this link (or using the "Open Link in Browser" menu option) segfault HexChat for you? It does for me: https://example.invalid/%2F%3F%3D
*nckx just clicked.
<nckx>segfault at 0 ip 00007cc5b1c5642c sp 00007fff47faf978 error 4 cpu 5 in[7cc5b1bed000+87000]
<Noisytoot>I ran it with gdb, it says it's in some UTF-8 validation function in glib (I think it was g_utf8_validate or something like that)
<unmatched-paren>funny how emacs plugins get merged so fast :P
<nckx>And IRC clients that get spammed on IRC.
<foobarxyz>nckx: I've just tried `./pre-inst-env guix lint gcc` from withing a `guix shell -D guix`. It also worked from withing `guix enviornment guix --pure`; I think it must have worked because of the final gi tpull I've done to the guix source
<nckx>Noisytoot: So glib is… URL-decoding it? :-/
<foobarxyz>nckx: so is `./pre-inst-env` only supposed to be called from within a `guix shell -D guix` env?
<foobarxyz>in general?
<unmatched-paren>foobarxyz: it works for me outside that
<unmatched-paren>but ok
<nckx>foobarxyz: Nothing relevant has changed in Guix since you said you ‘updated to the late guix source’ earlier, above, so I'm not convinced. I'm glad it works for you! But if there is a bug, it hasn't been found or fixed.
<foobarxyz>unmatched-paren: ok I see what's happening outside the guix shell ..., picking up on maximed's hint, somehow  I am missing the `guile-json` package. Once i `guix install guile-json`, it then works
<nckx>unmatched-paren: It works if you have all the required guile-* packages available in your regular profile, but that's not guaranteed, so ‘guix shell -D guix --’ is always safer.
<nckx>11 Jun 22:48:29<nckx> What's $GUILE_LOAD_COMPILED_PATH in the environment?
<nckx>There was a reason I asked.
<foobarxyz>unmatched-paren: in case it still matters, it's `GUILE_LOAD_PATH=/home/foobarxyz/.guix-profile/share/guile/site/3.0'
<Noisytoot>nckx: Yes, it uses g_uri_unescape_string
<foobarxyz>nckx: oops sorry this was supposed to be addressed to you
<nckx>foobarxyz: It does, and that value is wrong, and that is why Guix didn't see guile-json in the environment.
<nckx>foobarxyz: No prob.
<unmatched-paren>foobarxyz: they were asking for $GUILE_LOAD_COMPILED_PATH ;)
<nckx>You have sharper eyes than I.
<nckx>unmatched-paren: Appreciated, but in this case both are fine.
<foobarxyz>here it is: `GUILE_LOAD_COMPILED_PATH=/home/foobarxyz/.guix-profile/lib/guile/3.0/site-ccache:/home/foobarxyz/.guix-profile/share/guile/site/3.0:/home/foobarxyz/.guix-profile/lib/guile/3.0/site-ccache:/home/foobarxyz/.guix-profile/share/guile/site/3.0`
<nckx>They *should* both contain a second entry.
***resv is now known as A_Dragon
<unmatched-paren>hm, should compiled be different?
<unmatched-paren>yes, of course it should. silly (
<unmatched-paren>wow, we have so many gnu/packages/*.scm
<nckx>Oh, yes, it's just that the exact file name isn't needed to see the bug here, merely that there's no /gnu/store in there at all.
<nckx>I didn't mean to imply they should be identical, just that they are suffering from the same problem.
<nckx>It's a cop-out, but I'd guess that Ubuntu is ‘somehow’ messing with those variable.
<unmatched-paren>foobarxyz: you have guile installed with apt, perhaps?
<unmatched-paren>or guix, which presumably installs guile as a dependency
<nckx>foobarxyz: Maybe you added some code to .bashrc, .{bash_,}profile, /etc/profile.d, … that isn't excactly doing what it should?
<unmatched-paren>you'd want to remove the guix apt package as soon as you guix pull
<foobarxyz>unmatched-paren, nope, I used the official installer script
<unmatched-paren>ok... hm.
<nckx>Nooo, that makes it our problem again. Boo.
<justkdng>hello everyone
<justkdng>is guix a rolling release distro?
<unmatched-paren>it has versions, but they are just markers/milestones
<nckx>Our ‘releases’ aren't meant to be used in production.
<unmatched-paren>(source of much confusion)
<justkdng>oh nice, I'm currently using arch and I'm looking into guix
<foobarxyz>@nckx: the only thing I've got in my profile is this
<foobarxyz>. "$GUIX_PROFILE/etc/profile"
<foobarxyz>export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
<nckx>Just to install the system, then you update to master.
<justkdng>after it broke arch's build system :P
<nckx>foobarxyz: Can you run ‘guix shell -D guix --check’?
<unmatched-paren>justkdng: i think you'll appreciate guix's atomicity and rollbacks then.
<foobarxyz>@nckx: the only thing related to GUIX that is
<nckx>Guix has a fancy checker built in now.
<nckx>I don't know if it finds all problems, but it's a good first step.
<foobarxyz>nckx:  guix shell -D guix --check
<foobarxyz>guix shell: checking the environment variables visible from shell '/bin/bash'...
<foobarxyz>guix shell: All is good!  The shell gets correct environment variables.
<justkdng>is there a complete book/guide for scheme?
<justkdng>I'm still struggling with it
<sleepydog>can anyone on guix sd try running `awk 'BEGIN { print ENVIRON["HOME"] }' </dev/null` and tell me if you get a floating point exception?
<unmatched-paren>justkdng: well, there's the guile reference manual. but it's kind of... large.
<nckx>foobarxyz: For reference, this is what you *should* see:
<unmatched-paren>sleepydog: nope.
<nckx>‘Something’ is clobbering that value if you're seeing /run/….
<unmatched-paren>i just get /home/paren
<sleepydog>unmatched-paren: thanks!
<nckx>Also no.
<unmatched-paren>justkdng: scheme's pretty simple though. i can teach you the basic concepts in PMs if you'd like :)
<nckx>Hey kid
<nckx>wanna learn scheme.
<sleepydog>first lesson is free
<justkdng>oh no, I wouldn't want to inconvenience you with all my questions
<justkdng>last time I spammed someone with question they blocked me :P
<foobarxyz>nckx : running the same command it gives me back a store path alright: guix shell --pure -D guix bash -- bash -c 'echo $GUILE_LOAD_PATH'
<foobarxyz>nckx /gnu/store/fby3hf4sbmmb4zxlxmjkfs56pg7ghxsl-profile/share/guile/site/3.0
<unmatched-paren>justkdng: your questions are appreciated. (mwahaha the scheme cult shall grow! what? no, just talking to myself.)
<unmatched-paren>sorry, it's called the (cult). seriously, how can i evangelize when i don't even get the name of the cult i mean religion right.
<justkdng>if I learn scheme would I be able to use/customize emacs?
<justkdng>or is lisp different than scheme
<unmatched-paren>justkdng: ELisp is a bit -worse- different
<unmatched-paren>but not too -much worse- different
<unmatched-paren>the basic concepts carry over
<Michal_Atlas[m]> it helps
<unmatched-paren>like quoting and unquoting
<unmatched-paren>and cons, etc
<nckx>foobarxyz: OK, so when you enter an interactive shell, and type ‘echo $GUILE_LOAD_PATH’ by hand, you do get /run…etc.?
<nckx>So the error is being introduced only in interactive shell start-up files?
<sleepydog>this is weird; `env -u 0 awk 'BEGIN { print ENVIRON["HOME"] }' </dev/null` prints $HOME but without unsetting $0 I get a floating point exception
<unmatched-paren>Although i'm a v*m user, so i don't really know much about elisp
<nckx>I guess that narrows it down, but I still don't see an obvious culprit.
<nckx>I'm not a foreign distro user I'm afraid.
<nckx>Very foreign to me.
<nckx>unmatched-paren: You may speak its name here.
<foobarxyz>nckx: I'm getting the same path twice: echo $GUILE_LOAD_PATH
<foobarxyz>@nckx: /home/foobarxyz/.guix-profile/share/guile/site/3.0:/home/foobarxyz/.guix-profile/share/guile/site/3.0
<unmatched-paren>sleepydog: iirc reading from /dev/null is just like reading from a completely empty file
<nckx>Right. The duplication isn't a problem, but it's a problem that the value gets changed.
<nckx>foobarxyz: ☝
<unmatched-paren>so i don't understand how /dev/null would change anything...
<unmatched-paren>sleepydog: try `touch foo && awk ... && rm foo`
<unmatched-paren>sorry, `touch foo && awk ... < foo && rm foo`
<sleepydog>unmatched-paren: /dev/null is not the problem here :). i'm reading from /dev/null so awk exits. the special BEGIN rule runs before any lines are read
<foobarxyz>nckx: sorry I've lost you. Not sure what you meant by "/run.." earlier, and what is the "value" that gets changed :(
<unmatched-paren>sleepydog: ah
<justkdng>is systemd-boot unsupported? what about systemd-networkd?
<unmatched-paren>justkdng: anything systemd will not work on guix system
<sleepydog>the problem is accessing the ENVIRON array is raising a SIGFPE and I don't know why. might have to break out the debugger
<unmatched-paren>guix doesn't even have a systemd package
<unmatched-paren>Guix System uses the GNU Shepherd as its init system
<unmatched-paren>what do systemd-boot and systemd-networkd actually do?
<nckx>foobarxyz: Substitute /home for /run, sorry for confusing you, they are both ‘wrong’ and that's all that matters. /run is a Guix System thing.
<nckx>I told you I'm not good with foreign distros :)
<nckx>Alas, I wasn't exaggerating.
<justkdng>I'm currently using systemd-boot as a bootloader, and systemd-networkd as a network manager of sorts
<justkdng>how does guix manage wifi/ethernet?
<nckx>Guix System supports only GRUB at this time (but both ‘BIOS’ & UEFI variants).
<unmatched-paren>justkdng: using system services i think
<nckx>Just FYI.
<nckx>justkdng: On my laptop: with NetworkManager.
<unmatched-paren>(also: WHY DOES SYSTEMD INCLUDE A BOOTLOADER?!)
<nckx>You realise it contains a caching resolver and NTP client right.
<nckx>A bootloader feels more in line with ‘system’d than either of those to me.
*unmatched-paren looks up what those are
*civodul attempts to redeploy pankow + grunewald
<justkdng>haha, systemd is indeed big
<unmatched-paren>ah, dns something something for the former
<unmatched-paren>and the latter is a time syncing protocol!?
<nckx>foobarxyz: I'm sorry I can't be of more help. I'd have to actually install Guix to another distro and don't have the spare cycles right now.
<foobarxyz>nckx: is the issue that I don't have the necessary packages installed on my interactive bash shell to support all possible ./pres-inst-env guix commands?
<foobarxyz>guix package -I |grep guile|sort
<foobarxyz>guile                   3.0.7           out     /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7
<foobarxyz>guile-gcrypt            0.3.0           out     /gnu/store/60jl4xry9c93j9l0rr7nkvbw7dihjz4k-guile-gcrypt-0.3.0
<unmatched-paren>next it'll be including a custom-built kernel!
<foobarxyz>nckx: it appears I am missing guile-json to have `./pre-inst-env guix lint` to work
<unmatched-paren>oh god please don't let the systemd developers see that message.
<foobarxyz>nckx: though `guix lint gcc` does work fine ...
<foobarxyz>nckx anyway thanks for your help!
<foobarxyz>nckx: I can continue my work with `guix shell -D guix`
<nckx>The issue is that ‘guix shell -D guix’ sets GUILE_LOAD_PATH to a directory that contains all the guile-* packages you need, including guile-json. You can verify that by looking in /gnu/store/fby3hf4sbmmb4zxlxmjkfs56pg7ghxsl-profile/share/guile/site/3.0, which is the correct value. But when your shell starts and loads its configuration files, something clobbers (overwrites) GUILE_LOAD_PATH so it no longer points to those modules.
<unmatched-paren>justkdng: ...on systemd-announce: "systemd renamed to system. we are proud to announce that systemd is now the world's second most bloated kernel, surpassed only by the Windows NT kernel"
<nckx>That's the root problem. I just don't know where to look for the cause on non-Guix Systems.
<unmatched-paren>(although apparently the NT kernel is actually a hybrid micro/monokernel
<unmatched-paren>so that doesn't really hold, but oh well!)
<foobarxyz>nckx: yes i can confirm this, the only packages that are in /home/foobarxyz/.guix-profile/share/guile/site/3.0, are those that are installed as given by the `guix package -I|grep guile` command above
<nckx>foobarxyz: The problem is that ‘guix lint gcc’ won't lint the gcc in your git checkout directory, it will lint the gcc package that's part of the ‘guix’ you're invoking.
<nckx>So I don't think it's what you actually want? You can add a ‘mistake’ to your checked-out hello package, like making the synopsis empty, to test. ‘guix lint hello’ won't catch it; ‘./pre-inst-env guix lint hello’ would.
<nckx>You can work around this but the root problem remains.
<nckx>And will probably bite you again in different ways.
*nckx AFK.
<foobarxyz>nckx: it is perhaps that the `guix` command refers to all the guix dependencies on the store, but the `pre-inst-env guix` only looks what is in the ~/.guix-profile/share/guile/site/3.0 directory?
<nikola`>unmatched-paren: well systemd would also be a microkernel in a way
<foobarxyz>nckx: courtesy of GUILE_LOAD_PATH which points to ~/.guix-profile/share/guile/site/3.0 ?
<foobarxyz>nckx: I think this could explain it (probably this is what you have been saying all along and I've only now realised)
<Michal_Atlas[m]>If I were to have two patches and one depends on another, how should I go about submitting them?
<Michal_Atlas[m]>s/another/the other/
<bdju>since the recent mpv update my CPU usage is high even with mpv paused at the start of a file. and my temps are in the high 80s or low 90s... very unfortunate. noticeably more fan noise as well