<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>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 <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 <the_tubular>It works, but has a few quirks, docker is more tested <the_tubular>You might have to start the docker daemon DynastyMic <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>‘You probably didn't mean what you said, I'll passively-aggressively ignore you.’ *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>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>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. <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>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>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>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. <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 ... <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. ***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 data.guix.gnu.org <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? *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. <nckx>Or if you are 1337 and want to get fancy with curl +ix.io, go ahead. <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)) <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. <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? <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 :) <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 .home.arpa proposal. <nckx>Even when it becomes one, you'll have to talk to <https://github.com/lathiat/nss-mdns> 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>But I have a lot of reading left to do before doing so. <nckx>.local is the standard TLD for mDNS. <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. <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 <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>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 <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, … <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 <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? <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 <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. <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. *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>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/matrix.py 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/matrix.py <<<< 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. <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>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 <denna[m]>I saw this video https://m.youtube.com/watch?v=S9V-pcTrdL8 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. <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. <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? <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>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 <unmatched-paren>except instead of using a string as the elisp config, it uses a scheme expression, seemingly <reyman>but you say it's gone, i'm lost lol <unmatched-paren>it's the home.scm repository that contained my old config.scm that's gone :) <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>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>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/sr.ht dotfile config <reyman>that help me A LOT as a begineer on guile/guix :D <reyman>creating one page listing awesome dotfile with guix home could be cool for noob like me :) <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>Generating package cache for '/gnu/store/gm2cxwfcfp5nmwdxfsi05zh218d2rvvy-profile'... <sughosha>(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (libpng-1.2)) (value #f)) <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? <sughosha>nckx: I tried it but still the same error :( <nckx>Please share the full output of guix pull at paste.debian.net, 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 <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. <jpoiret>shouldn't be an issue with the aforementioned channel though, it has never referred to that variable i think <nckx>jpoiret: Uhm: ("libpng" ,libpng-1.2) <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 <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? <unmatched-paren>nanounanue: you'd create a `guix.scm` in the project root that evaluates to a package using python-build-system <nanounanue>I read the documentation, and I have a private channel but only using guix import <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>and then change all the fields in the package to suit your new one -.o.- <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 <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 <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 <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 crates.io 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 git.sr.ht/~rjarry/aerc --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. <jpoiret>you can have a look at lower from (guix build-system gnu) <unmatched-paren>looks like build-inputs gets populated by splicing inputs and the standard inputs into a list? <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 ***jesopo is now known as jess
<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>I don't think that would be a good idea. <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. <https://ftp.gnu.org/gnu/guile>: ‘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]. <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. <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>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. <maximed>when it says 'checking PACK [linter]’, that only means it is chacking PACK with [linter]. <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>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? <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. <nckx>That was a fun one. Thanks. <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. <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: Using contact details to send threats to the person who put this many dependencies in go.mod. <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! <nckx>Well, Guix adds the go-. <civodul>maximed: Guix was written after Guile 2.0 had been released (fortunately :-)) <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 :) <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 <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 :) <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 <nckx>unmatched-paren: Did you read (guix)G-Expressions yet? <Michal_Atlas[m]>Yeah, huh, they just weren't #:used but now it states no code for module (guix gexp) <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) <nckx>Michal_Atlas[m]: You are no such thing. <maximed>I don't think the keyword #:used is used anywhere in Guix? <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. <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. <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 <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 <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. <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 <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>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 <maximed>foobaryxyz: Run ./pre-inst-env from the git checkout <maximed>and not from two directories upwards <kaelyn> speaking of gexps, is there a way to use `substitute-keywords-arguments` with package arguments that are gexps instead of lists? <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>make[1]: Leaving directory '/home/chaos/src/guix' <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: 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: <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>(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>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 <foobarxyz>;;; (what (misc-error #f "no code for module ~S" ((json)) #f)) <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>& setting up ~/.bash_profile (or was it ~/.profile or both?) appropriately <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>maximed /home/foobarxyz/.config/guix/current/bin/guix <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
*nckx not it, sorry, busy. <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) <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>;;; (what (misc-error #f "no code for module ~S" ((json)) #f)) <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>‘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>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 <foobarxyz>`guix lint -L . gcc` has worked from within the root of the guix src dir <nckx>segfault at 0 ip 00007cc5b1c5642c sp 00007fff47faf978 error 4 cpu 5 in libglib-2.0.so.0.7000.2[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) <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? <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' <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>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
<nckx>"/gnu/store/…-profile/share/guile/site/3.0:…" <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. <nckx>foobarxyz: Maybe you added some code to .bashrc, .{bash_,}profile, /etc/profile.d, … that isn't excactly doing what it should? <foobarxyz>unmatched-paren, nope, I used the official installer script <nckx>Nooo, that makes it our problem again. Boo. <nckx>Our ‘releases’ aren't meant to be used in production. <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="/home/foobarxyz/.guix-profile" <foobarxyz>export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" <nckx>Just to install the system, then you update to master. <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>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? <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>‘Something’ is clobbering that value if you're seeing /run/…. <unmatched-paren>justkdng: scheme's pretty simple though. i can teach you the basic concepts in PMs if you'd like :) <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? <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 <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>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. <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 :( <justkdng>is systemd-boot unsupported? what about systemd-networkd? <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 <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 <nckx>Guix System supports only GRUB at this time (but both ‘BIOS’ & UEFI variants). <nckx>justkdng: On my laptop: with NetworkManager. <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 <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>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 <foobarxyz>nckx: it appears I am missing guile-json to have `./pre-inst-env guix lint` to work <foobarxyz>nckx: though `guix lint gcc` does work fine ... <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 <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. <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? <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