IRC channel logs


back to list of logs

<fosskers>Hi again. I seem to be in some sort of chicken-and-egg scenario. I can't use `guix home` until I've updated `guix`, but I can't actually use the new guix (that includes `home`) until I've updated my environment, but since I'm not a bash user I can't update the environment until I've setup a Guix Home... you see my problem.
***Xenguy_ is now known as Xenguy
<fosskers>What's the difference between what appears in /var/guix/profiles/per-user/ME/current-guix/ and /home/ME/.config/guix/current ?
<lilyp>none, the latter links to the former
<fosskers>That doesn't appear to be the case
<fosskers>Although I'm fairly sure my install is broken somehow
<sneek>tangonov, you have 1 message!
<sneek>tangonov, lilyp says: packaging gnome extensions is comparatively easy. Most often you just have to move some Javascript to the correct location using copy-build-system
<tangonov>lilyp: Thanks for that response, sorry it took me forever to see it
<tangonov>I am working on packaging a Ruby gem out of necessity for work. I am having a look at the guidelines for Free Software. The Gem in question has a generic license. I *think* it's OK, but I wouldn't know what to call it:
<tangonov>Is this something that may be contributed, or should I take it to the non-gnus.
<singpolyma>Looks like an expat to me?
<tangonov>I have seen that term in my package services, wasn't sure what it meant. I will go look that up
<singpolyma>Some people say "MIT"
<tangonov>MIT is confusing, and generally, I feel like people just throw it in their repos so they can forget about a license.
<tangonov>Found the GNU docs on Expat, this makes sense
<tangonov>And since we can call this (ruby-shopify-cli) expat, I will see about making it work
<fosskers>Hm, and has nothing about Fish in it. Not really sure what to do here.
<bjc>the zsh/bash services are just conveniences for ‘home-xdg-configuration-files-service-type’
<bjc>you can do pretty much everything they do with that, it's just less nice
<bjc>or ‘home-files-service-type’, depending on where you're dumping things
<fosskers>I'm trying to make a `home-configuration.scm` for the first time, setting Fish as my shell so that my commands actually work.
<bjc>you need to set fish as your shell in the operating system config, where you define your account
<bjc>i don't think there's a way to do it in your home configuration
<fosskers>This is a foreign install, it's not Guix OS
<bjc>then you gotta use the foreign distro utilities (usermod or the like)
<fosskers>I'm quite confused
<bjc>your home-config.scm will lay down the init files your shell uses, but it won't set your login shell
<fosskers>I don't need it to, I'm just testing out Guix (the tool) to help manage my dotfiles.
<bjc>ah, i misunderstood, then
<fosskers>`guix pull` and the setting of GUIX_PROFILE seem to assume Bash use
<bjc>well, in that case, you can do things like: (service home-files-service-type `((".fishrc" ,(local-file "fishrc"))))
<bjc>that'll create a ~/.fishrc that has a copy of what you have in ‘fishrc’
<fosskers>I do have a bash shell hacked together here in a side terminal with the proper vars set and sourced, so that `guix pull` is actually respected, but I don't know how to persist it.
<bjc>you could also use ‘mixed-text-file’ or ‘plain-file’ instead
<bjc>i don't know what you mean by “`guix pull` is actually respected”
<fosskers>guix pull updates guix, but the new `guix` executable isn't actually used unless you update your environment
<fosskers>But the tooling assumes I use bash, which I don't
<fosskers>`guix --version` is also reporting a version of 0, so that's another mystery.
<fosskers>Maybe I should just nuke-and-pave? Something seems really wrong
<bjc>it does seem broken? but i don't use guix as a foreign distro, so i couldn't say for sure
<bjc>when using guix home, it should create a $HOME/.profile, which needs to be sourced to have the correct paths
<bjc>i don't know how fish works, but the file itself is pretty straight-forward, as are the scripts it calls, so maybe you can hack it together from looking at that
<fosskers>Following the guide, I tried a `git home container path/to/my/home-configuration.scm` but this also failed due to assumptions about bash
<fosskers>(guix home ... I mean)
<bjc>that makes some sense. it does seem like we need to more explicitly support non-bourne shells
<fosskers>I'd love to hack on this but I'm so new to it that I don't know what's missing or where at all to start. Following the guides is unfortunately not working.
<fosskers>Thank you for your suggestions, though
<mekeor[m]>hello. "guix upgrade" fails for me because it can't find the tar-archive for the package "compat" in the internet (404). what's wrong?
<mekeor[m]>also, i wonder why i can't search cuirass like this:
<mekeor[m]>how can i find out which package(s) i have installed, that depend on "compat"?
<lilyp>guix graph?
<mekeor[m]>lilyp, so i have to run guix graph for each installed package?
<fosskers>I'm trying to delete my `/gnu/store/`, but it's claiming to be a read-only filesystem
<fosskers>chmod doesn't work either
<mekeor[m]>fosskers: what does "mount" say?
<lilyp>I'm pretty sure you should be able to graph a list of packages at once – if not, that sounds like a feature worth adding
<mekeor[m]>fosskers: try "mount | grep /gnu/store"
<fosskers>There we go
<fosskers>"/dev/sda1 on /gnu/store type ext4 (ro,relatime)"
<fosskers>Did the Guix install script do that?
<mekeor[m]>lilyp: true :)
<mekeor[m]>it's possible
<mekeor[m]>fosskers: are you on guix system?
<fosskers>mekeor[m]: nope, tried to install guix (the tool) on Arch to try it out. Wanted to play with `guix home` but it's not going well so I'm uninstalling.
<mekeor[m]>fosskers: i don't know what happens, but you could try "umount /gnu/store". your computer might explode tho
<fosskers>I'll restart my machine. It might have been the systemd service that make that mounting
<fosskers>Yup, after restarting the mount is gone. Thank you!
<mekeor[m]>glad your machine didn't explode
<fosskers>Me too haha
<fosskers>Perhaps I'll give it another shot if/when there's more support for Fish out of the box
<fosskers>I really like the Guix idea and was excited to be doing config in Scheme
<the_tubular>It takes a while to pick up though
<the_tubular>But yeah it's fun :)
<oriansj>well there is the minimal configuration approach if you want to grow into a setup
<the_tubular>I haven't followed everything, but why do you critically need fish ?
<oriansj>the_tubular: some people just like it better, they don't need a reason for doing so
<oriansj>and there is only a few environmental variables they would need to add to their setup script to make it work well with guix
<the_tubular>I understand that oriansj, but it's like picking seat color before picking a car IMO
<the_tubular>Also, I could understand for some other binaries that are critically required (web servers, db, etc etc)
<the_tubular>A shell doesn't fit that use case, I was just curious
<oriansj>the_tubular: I'd rather sit comfortably in a slow car than sit uncomfortably in a fast car that drives like a dream. Sometimes the seat matters more than the car to the person behind the wheel
<the_tubular>Color doesn't make it comfortable, but I get your point :P
<oriansj>if the shell they want to use is important to them, then it is important
<the_tubular>I wanted to know why
<the_tubular>If it's some hidden feature I've been missing
<the_tubular>Or maybe something I couldn't give less of a shit about
<oriansj>the_tubular: well give it a spin and see if you like it
<the_tubular>I already did, briefly
<oriansj>it does some things better than bash and other things worse
<the_tubular>A few years ago though
<the_tubular>Ohh not it was ZSH, nevermind lol
<the_tubular>I basically learn about emacs that way
<the_tubular>Hey, why did you need emacs that bad, and then the guy sent me his workflow and I got it :P
<oriansj>dash with readline is usually all that 99% of people want/need but for some people eshell in emacs is the only thing with the power they need
<fosskers>the_tubular: I've used fish for years, my fingers are deeply used to it
<the_tubular>And then I've picked up emacs and learned it
<the_tubular>That's fine fosskers :)
<the_tubular>ehsell is great!
<oriansj>the_tubular: one doesn't learn emacs, they just finds the bits in the mud they like playing with.
<jackhill>fosskers: I haven't done this myself, but one thing I've seen suggested would be to keep bash or whatever as your "official" shell for doing all the Guix-y stuff, but configure your terminal to start up fish for you automatically
<oriansj>ain't nobody learning emacs' teco mode
*the_tubular DuckDucksGoes emacs' teco mode
<jackhill>but, we need people like you to advocate and guide us to make the fish improvements, or at least point out the problems
<fosskers>Is there a good place for me to document the issues I just faced?
<jackhill>fosskers: probaly look to see (to the extent possible with how well the search works) if it's mentioned on and if you see nothing there, explain the problem in an email to
<the_tubular>Err not /recent but you'll figure it out :P
<jackhill>I beleive that we have fixed some problems in the past
<oriansj>the direct ancestor of Emacs which is why emacs still supports it to this very day
<jackhill>but clearly no enough :)
<bjc>it's honestly probably not too much work to get fish working with the home configuration. it just needs someone who knows both fish and a smattering of guix internals to do it
<the_tubular>"Tape Editor and Corrector because "punched paper tape was the only medium for the storage of program source on our PDP-1."
*the_tubular Closes tab
<jackhill>bjc: yep! or two people working together
<bjc>if i had the time i'd already be looking into it!
<bjc>i'd been meaning to look at fish anyway
<oriansj>this is a great place to find collaborators for crazy cool ideas
<fosskers>Well even if it's already somewhat supported, there's still the fact that `$GUIX_CONFIG/current/etc/profile` (etc.) assume you're using bash.
<bjc>does fish have an sh-compatibility mode you can use for sourcing scripts?
<the_tubular>It's called dash :P
<fosskers>It _does_ have a `source` keyword and does support `.`, but I'm not 100% sure about the syntax found in those `profile` files.
<fosskers>Another snag: it has no `hash` keyword so `hash guix` doesn't work.
<bjc>the syntax is ancient posix bourne shell
<bjc>as for ‘hash’, is there a call to that in the profiles? i didn't see one when i looked
<oriansj>well the contents are effectively: so one can just manually create the same in the native scripting language and it'll work just fine
<bjc>i guess it's not all that ancient, it does have: export XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR:-/run/user/$UID}
<bjc>but that's still posix
<fosskers>bjc: no but `guix pull` tells new(?) users to run `hash guix` "after setting your PATH"
<fosskers>exports in Fish are done via `set -x`
<oriansj>which if your shell doesn't cache lookups, it doesn't need to be done at all
<bjc>ah, that's a bashism - iirc, ‘hash guix’ just tells bash to re-find guix in the path
<bjc>depending on how fish works, that's not necessary. it's not even necessary in bash a lot of the time
<fosskers>Yeah I don't believe that's necessary
<oriansj>understanding removes magic incantations and enables a real engineering of the problems you face
<bjc>it's understandable why someone who doesn't use bash (and many who do) wouldn't know that command
<bjc>it's definitely on the esoteric end of the scale, imho
<nikola`>When i install a program through guix, it's visible in gnome shell until i logout and login again
<nikola`>It's there another way to refresh gnome program list
<oriansj>I find it odd that guix just doesn't looke at ${SHELL} and then display the proper commands based on what shell you are using
<oriansj>although I admit a few shells don't override that env variable like they should but I guess that should just be a bug report filed against them
<fosskers> Fish certainly seems to
<fosskers>Ok folks I'm going to head off for now, but tomorrow I'll open an entry on the Issue Tracker outlining some of the things we uncovered today
<fosskers>Thanks for your help so far
<oriansj>although the latest wording of the POSIX standard would seem to indicate they wish for its new meaning to be just the user's preferred shell
<oriansj>(or command language interpreter which honestly could be just guile or python as one's shell doesn't also have to be their preffered command language interpreter)
<apteryx>sneek later tell civodul why does tests/services/telephony.scm need to be updated (yet) ? :-)
<nouun>What's the Guix equivelent of build-essentials? Trying to find the package which provides execvp.
<tangonov>I am attempting to package up a ruby gem folling these handy notes:
<tangonov>It appears as though my sha256 checksup doesn't seem to line up with ./pre-inst-env guix package -i ruby-gem-name
<tangonov>I must be doing something silly/wrong here
<nouun>Okay I'm stumped, trying to build but I keep getting this error: 'fatal error: stdlib.h: No such file or directory'
<nouun>A gist of my .envrc and guix-manifest:
<nouun>Full log if needed:
<nouun>It seems to be something Guix-specific hence why asking here.
<rgherdt>whereiseveryone_: unmatched-paren : I'm already taking stuff from geiser code for my lsp-server I announced on Guile
<sneek>Welcome back rgherdt, you have 1 message!
<sneek>rgherdt, unmatched-paren says: Hi, whereiseveryone_ and me were discussing ideas for a Scheme LSP server, and we were pointed to your email to guile-user: the idea whereiseveryone_ had was to extract Geiser's Guile code and use that as the backend of the LSP server. What do you think? Would that work?
<unmatched-paren>rgherdt: ah, nice :)
<rgherdt>but more as inspiration. Directly using it could work, one would have to write adapter code to translate between s-exprs and LSP
<rgherdt>I'm working on clients for emacs and VS Code, it would be awesome if someone integrates it with vim/neovim
<unmatched-paren>why wouldn't it just work with eglot and neovim's builtin lsp?
<rgherdt>it should work. But at least for emacs-lsp and vscode one still has to write the extension that, for example, installs the LSP server (if needed) and calls it
<rgherdt>it's not much code actually
<unmatched-paren>like how you need to write a small amount of lua with neovim-lspconfig to set the command to use, the options to pass, etc. i see.
<rgherdt>one thing that is more tricky is that I'm trying to mimic the way geiser/slime work. Namely that you can start a REPL and load files into it. Based on that, I can get LSP info regaridng what the user loaded
<rgherdt>that's not the way most LSP clients work
<rgherdt>So for emacs-lsp, for instance, I fire up a server that displays the REPL to the user, and listens on a port where it spawns an LSP server (a thread) for each incoming connection
<rgherdt>but there is also an executable guile-lsp-server that gets installed that launches a single LSP server listening on stdin, this should be trivial to integrate on most clients
<rgherdt>My focus now is on getting vscode's plugin ready to publish (there is already a PR for the emacs-lsp package). After that I want to fix a bug and move on integrating gambit
<rgherdt>but I could help if someone starts writing an extension for other clients
<unmatched-paren>i'd be able to do that for nvim
<rgherdt>someone asked about a GNOME Builder extension, I could also take a look at it in the near future
<rgherdt>btw, which IDEs do you think are more popular among guix folks?
<rgherdt>I suppose node-js/electron based ones are not easily installable, right?
<unmatched-paren>emacs by far
<rgherdt>Because my biggest motivation with the LSP server is to make it easier to non-emacs users to start hacking scheme
*unmatched-paren bye \o
<lilyp>GNOME Builder has nice aesthetics, but the Emacs keybindings are not enough
<rgherdt>for newcomers that don't want to learn emacs it's possibly one of the best options in Guix, right?
<lilyp>I suppose?
<rgherdt>maybe I should install Guix again and explore it a bit :) It's also on my TODO list
<lilyp>If you do end up using it, please report any bugs that occur
<lilyp>It's one of those package that's barely maintained because it's outside of most folks' radars
<rgherdt>as an emacs user I'll probably don't spend much time on it
<rgherdt>but I'll definitely take a look at it
<rgherdt>is vscodium currently available in Guix?
<lilyp>no, it being an electron app makes it unworkable
<lilyp>also, vscodium is just a binary distribution of upstream vscode sans telemetry iirc
<rgherdt>yes, I suspected it. Actually I really dislike it, but started the lsp client for it anyway, since that's what most my colleagues are using
<rgherdt>writing the extension for it made it me realise how much I love Emacs :)
<rgherdt>there is also kdevelop, but I think they don't support LSP directly. Kate seems to support it
<civodul>Hello Guix!
<sneek>civodul, you have 1 message!
<sneek>civodul, apteryx says: why does tests/services/telephony.scm need to be updated (yet) ? :-)
<civodul>sneek: later tell apteryx hey! tests/services/telephony.scm refers to procedures in jami-service.scm that have been removed, IIUC
<sneek>Got it.
<nikola_>Is there a reason why emacs native comp isn't in the standard channel
<rekado_>apteryx: FYI: I'm taking node 129 offline so that the FC HBA can be installed.
<rekado_>apteryx: uhm… I don’t have root access on that node. Could *you* shut it down please?
<jpoiret>nikola_: no one has upstreamed it
<nikola_>Ah right
<jpoiret>maybe flatwhatson could consider upstreaming it
<nikola_>I know that there is an unofficial channel with it
<jpoiret>no idea who that would be though
<jpoiret>yes, this right?
<nikola_>I'd volunteer to do it, but I'm veru new to guix
<nikola_>Yes, that one
<nikola_>I don't think there are substitutes for it
<jpoiret> is not encouraging
<jpoiret>since that channel is GPL, maybe we could upstream it without explicit permission, right?
<lilyp>upstreaming is one thing, but I failed to reproduce their results
<jpoiret>lilyp: they hardcode the needed paths (to gcc-11, libgccjit, and stuff) directly with
<lilyp>That's not the problem :)
<jpoiret>oh, i thought you were still trying to make libgccjit work :p
<lilyp>Oh, sure, but it fails earlier
<jpoiret>did you want to enable it by default in the emacs package/
<lilyp>my stash is sadly incomplete, but this is what I've tried
<lilyp>the code for gccjit is more or less taken from flatwhatson's channel
<fps>hmm, i can't seem to find a mention of limits.conf in the guix manual. or rtprio, etc?
<fps>how would i set up those limits in guix?
<lilyp>fps: `guix system search limits' helpful?
<fps>lilyp: yep, ty
<fps>lilyp: possibly helpful, let's see
<rekado_>civodul: or if you have access on node 129, please shut it down
<rekado_>civodul apteryx or if someone could init my password on that node — that would be helpful too.
<rekado_>my colleague is in the data centre now and I need access to test the SAN connection.
<rekado_>I’m trying to fix some reproducibility problems in R packages after seeing vagrantc’s email
<rekado_>it pains me to see r-minimal back on the list. It’s a single character difference and I have *no* idea where it comes from!
<rekado_>working on r-affycompatible now, which I think is merely a sorting problem. It builds classes from XML, and I think that the xpath results are in non-deterministic order.
***mark is now known as mjw
<silicius[m]>I packaged vkmark recently but could only test it on x11 while it also lists wayland and kms as its possible backends. I wouldn't want to send a patch with 2/3 of its functionality broken..
<silicius[m]>I don't know how to test it on kms at all
<nckx>silicius[m]: Why not? Just ask someone using Wayland to test :) As for KMS: maybe switch to a Linux VT and try --winsys=kms?
<jpoiret>for wayland, you could test using a simple wayland compositor like sway with a minimal config but it might be a bit too much trouble
<jpoiret>too bad we don't have cage
<jpoiret>one more reason to properly package it
<nckx>Sending patches of a limited and well-defined brokenness level is fine, just mention exactly how.
<silicius[m]>I'm in the process of putting the declaration in guix and testing it there according to the manual, but if someone is willing to test it on wayland I can post what I have rn on
<nckx>silicius[m]: Certainly.
<nckx>If you wrote it in a separate (guix build -f) file, please paste the entiry file. People sometimes omit the use-module section leading to tedious re-work.
<nckx>Entiry \o/
<nckx>Weeks I longed to be back behind a proper keyboard and now I do things like this.
<silicius[m]>The module needs to be changed to something that will work for you, but otherwise it should be fully working
<silicius[m]>I'm considering putting the package into gnu/packages/vulkan.scm, seems like the best place for it
<nckx>I just appended ‘vkmark’ to the end of the file and used ‘guix build -f’. :) It's building.
<nckx>Yes, it's a toss-up between vulkan.scm and benchmark.scm.
<nckx>I generally prefer putting packages in modules that describe what they do (benchmark), not how (vulkan), but here both make sense.
<nckx>Whatever you prefer, or leads to the least new module imports.
<silicius[m]>I didn't know about benchmark, it might be a better place for it. thank you
<jpoiret>what's the stance on patented software in Guix?
<nckx>Still building; otherwise busy laptop.
<nckx>jpoiret: Maintainer hat off: I don't think we care?
<jpoiret>i was reading LWN and learned about the openh264 shenanigans just now, and realized that we're packaging open264 ourselwes
<nckx>Right, that. I really don't think we care.
<jpoiret>personally i wish we didn't
<nckx>Care or ship?
<jpoiret>but ianal and don't really understand who would be at risk with such behavior: the users themselves?
<nckx>But, while that sounds like ‘well we should protect users then’, the accepted argument is ‘we can't effectively do so, whilst we would harm many others in real ways, so don't try’.
<nckx>I'm sure the FSF has written that more clearly, let me look 😉
<nckx>That was easy: ‘Patents’:
<nckx>It's true that Guix could choose to be more strict, but I would argue against doing so.
<nckx>All such discussions get mired in WANAL, see the recent ML tedium.
<nckx>silicius[m]: Scary pony achieved. Wayland works!
<jpoiret>right, the FSF is pretty clear
<nckx>silicius[m]: As for 3/3: Error: Failed to find specified window system 'kms'
*nckx tries forcing -Dkms=true
<nckx>The KMS back-end is very new.
<nckx>jpoiret: So I'm clear: are you implying that's not ‘enough’ for us to justify our (possibly informal) policy?
<nckx>Or not at all?
<silicius[m]>that's the same for me. I think the arch package mentions something about it being broken
<silicius[m]>linking to this issue:
<jpoiret>oh no, i was just wondering if there was any actual stance on the issue
<jpoiret>the FSF saying "it's impossible to actually track, so we don't care" is reassurance for me, since i completely agree with that
<silicius[m]>ncks: Should I just remove dependencies for the kms backend, as it seems broken rn?
<nckx>silicius[m]: I see.
<jpoiret>this just in: the seatd/greetd patches have been committed
*nckx found a similar but more explicit
<nckx>2017, ‘just disable it’, sigh.
<nckx>jpoiret: We're pretty explicit in following the FSDG, although it's true that ‘non-rule’ isn't really part of the FSDG in a strict sense because it's not-there.
<jpoiret>what's the recommended way of inserting a package in a file? in the first place where it would belong alphabetically?
<jpoiret>i feel like this is the hardest part of writing a new package definition
<nckx>jpoiret: Yes.
<nckx>I'm going to not-be my usual hem-hawing IMHO-self and just say yes.
<lilyp>Either there or in case you see total chaos you might also try putting it near a related package
<jpoiret>heh, thanks for the new word (hem-hawing)
<jpoiret>lilyp: well it's total chaos currently (wm.scm) but it's never too late to start
<lilyp>perhaps we should teach guix style to sort files, might be fun
<nckx>jpoiret: Exactly. I do the first-alphabetical thing amidst chaos too.
<nckx>A widdle beacon of order, two packages, in order.
<nckx>Maybe if they grow to like each other they will make a third.
<nckx>So it begins.
<nckx>But seriously who is supposed to provide vulkan_intel.h — it's supposedly mesa, but also obviously not!?
<efraim>llvm configure flags are driving me crazy
<nckx>(A specific random development feature branch of mesa that is.)
<efraim>llvm@9 needs some extra flags for riscv64, my previous fix didn't quite get everything
<nckx>lilyp: There are people who actually like ‘git blame’, and would not like that.
*nckx not it.
<lilyp>Well, you can recursively blame, so...
<nckx>silicius[m]: Yes, removing them seems best. AIUI the kms back-end, as it is, seems to have bitrot and would need maintenance to work with current Mesa:
<nckx>Just put that in a comment and be done with it.
<nckx>silicius[m]: Have you tried to build from vkmark master by any chance?
<nikola_>What is the reason Firefox isn't in the official channel
<silicius[m]>nckx: Is the package not building from master? I used the latest commit
<nckx>I hadn't checked yet.
<nckx>I just saw 2017.
<silicius[m]>That's the latest stable version, the program's window also features this date
<jpoiret>nikola_: the firefox branding itself belongs to mozilla and they don't want other distros to compile and distribute binaries themselves
<nckx>So this has been broken since then and not fixed on master. Let's not bother [unless you want to fix it and write a patch].
<nckx>silicius[m]: Sure.
<nckx>You versioned correctly, it's just disappointing.
<nikola_>jpoiret: what about something like librewolf then
<jpoiret>although i think i saw something about Debian and Mozilla coming to terms with their decade-old feud
<jpoiret>we have icecat
<silicius[m]>I don't anything about programming for vulkan, just wanted to test my graphics card
<silicius[m]>so no patch from me
<efraim>llvm@12 and llvm-julia@11 worked, I'll have to see if llvm-10 needs anything special :/
<nckx>No problem. See my comment about a comment about it above, and go ahead and submit your package. But please move home-page, synopsis, description, and license to the end of the package, in that order.
<nckx>silicius[m]: ☝
<jpoiret>nikola_: librewolf might be viable
<jpoiret>(and with more personpower than icecat)
<nckx>silicius[m]: Also, newline before (revision …) in the let. Those always go on their own line.
<nikola_>My thoughts exactly
<silicius[m]>sure, I'll submit it today once I'm sure it's 100% ok
<nikola_>Though i don't think i can be the one to package it since I'm very new to guix
<apteryx>rekado_: hi!
<sneek>apteryx, you have 1 message!
<sneek>apteryx, civodul says: hey! tests/services/telephony.scm refers to procedures in jami-service.scm that have been removed, IIUC
<jpoiret>hmm, does `guix hash -rx .` not work for git repos?
<silicius[m]>nckx: guix style put flatenned that line automatically, but I'll change it
<nckx>Well, I don't like it. So there 😛
<apteryx>rekado_: you should be able to logon to 129 using the user 'rekado' and your usual sysadmin public key
<nckx>silicius[m]: Thanks for pointing that out.
<apteryx>rekado_: and from there you can use 'sudo' to gain root
<civodul>nckx: thou shall not contradict the almighty 'guix style'!
<bjc>i've had to fix up ‘guix style’ for some things. is that actually verboten?
<apteryx>jpoiret: it works, why?
<efraim>I tried packaging arcticfox but I wasn't able to get it to build
<civodul>bjc: no actually it does have some rough edges
<jpoiret>apteryx: i forgot to `git checkout <tag>` 🙃
<nckx>bjc: valiant last bastion of human taste against the tyranny of the machine.
<apteryx>jpoiret: :-)
<civodul>and that too :-)
<bjc>in the words of the great del the funkee homosapien: never let a computer tell me shit
<jpoiret>cage was surprisingly easy to package
<nckx>I'm willing to cede the (for me) hard-to-remember-and-bordering-on-arbitrary 5-input single line thingy but I think I draw the line at (let ((some superlongthing) (o hai)) …) — maybe it's just me, but I always feel a tiny bit of relief that I ‘caught’ the second one when I see it.
*nckx is probably just me.
<jpoiret>how do you find out where store references are in a store path?
<jpoiret>just grep?
<lilyp>bjc: Human + Emacs still results in cleaner style than the Guix tool.
<jpoiret>hmmm, should we drop debug-gui from libinput? it pulls in gtk
<bjc>lilyp: no disagreement from me; i was just wondering if the project required its use
<jpoiret>i'm staring at the "minimal" wayland compositor cage having a 1GB closure
<bjc>surely that's just for the build phase, and not the outputs?
<jpoiret>🤡 debug-gui is actually a UI you can launch through libinput's CLI
<lilyp>jpoiret: if you can separate it into a libinput-minimal
<lilyp>graphical debugging of input handling sounds mildly useful
<jpoiret>i'll look into that
<jpoiret>wlroots also retains references to Xwayland, but i don't think it should
<silicius[m]>how can I force a rebuild of a package? guix build does not seem to have an option for that
<jpoiret>although if guix doesn't want to rebuild a package, it's because the recipe hasn't changed
<silicius[m]>thanks, had to add --no-grafts as well
***stikonas_ is now known as stikonas
<jpoiret>lilyp: looks like we already have such a libinput-minimal
<jpoiret>but not everyone uses it
<reyman>Hi guix !
<reyman>I'm trying to configure eduroam wifi
<reyman>my command line wpa_supplicant -c cat_installer.conf -i wlo1 -B return an error : p2p-dev-wlo1:failed to initilaize drive interface
<reyman>with nl80211 Could not set interface p2p-dev-wlo1 UP
<apteryx>is there any message in dmesg?
<apteryx>perhaps that interface requires proprietary firmware
<nckx>jpoiret: Could it be a separate output somehow (say if libinput just uses $PATH to find it)?
<reyman>actually it's possible to connect to 4G without problem using the same interface
<nckx>The same interface providing 4G and wifi?
<reyman>I have this : Rekeying PTK for STA 94:b4:0f:bc:a8:70 but driver can't safely do that.
<jpoiret>nckx: it's ok actually, since we already have libinput-minimal for that use case
<jpoiret>just that many packages use the full libinput
<reyman>using my 4G with phone as wifi @nckx
<nckx>There is little point in shipping the full libinput if nothing is built against it IMO. ‘But you could build your own code with a debugger’ is meh.
<reyman>ok i have this also :
<reyman>[25462.032062] debugfs: Directory 'netdev:p2p-dev-wlo1' with parent 'phy0' already present!
<nckx>reyman: IC.
<reyman>ok, so running sudo dhclient -v wlo1 that work, but this is not displayed in gnome
<reyman>wifi applet
<rekado_>apteryx civodul, node 129 now has access to the SAN.
<apteryx>great! were you able to connect to it using your sysadmin key?
<apteryx>(and regular user)
<silicius[m]>I think I got the patch ready to send, but since it's my first package should I add my name somewhere like copyright or something?
<jpoiret>silicius[m]: usually at the top of the file, you'll see a bunch of other copyright lines, just add your own
<unmatched-paren>silicius[m]: you need to add your name (or pseudonym ;) and email to the header in each file you've modified
<jpoiret>let's say I mass rename libinput -> libinput-minimal for 4 packages in the same file, should that be 1 or 4 commits?
<silicius[m]>thanks. I think it isn't specified in the manual
<unmatched-paren>jpoiret: probably 4
<silicius[m]>woho, sent the patch
<nckx>It is taking its sweet perambulations to arrive.
<nckx>reyman: ‘I see’.
<nckx>apteryx: Good evening! How went the btrfs (mis)adventures, if any?
<hugonobrega[m]>hello folks. I have a quick question about package etiquette, so to speak: I'd like to package something whose man page requires pandoc for building. would including a prebuilt man page be frowned upon if I then tried to contribute the package to guix?
<hugonobrega[m]>because, uh, including pandoc as a dependency just for the man page makes me shudder a bit
<reyman>@nbkx :) thx
<nckx>? (😉)
<nckx>hugonobrega[m]: It's fine.
<nckx>Well that's ambiguous.
<nckx>Adding pandoc as a native-input is totally fine.
<nckx>silicius[m]: Arrived & approved, thanks!
<silicius[m]>that was quick, nice
<nckx>Ah, I meant as not-spam.
<nckx>If only.
<silicius[m]>ah. You got my hopes up there
<apteryx>nckx: hi! the node 129 is up on a Btrfs RAID 10 5 disks array, can reboot without issues at will
<nckx>Oh that's wonderful. So using btrfs is tenable.
<nckx>That's something of a relief.
<apteryx>yes; migrating /etc is potentially login breaking due to PAM and other possibly stale things kept there
<apteryx>and EFI probably improved because the boot drives were > 2TiB and BIOS can't cope with that
<apteryx>improved things*
<apteryx>I'm also relieved that the PERC seems to behave transparently as we'd expect, whatever their operation mode (RAID vs HBA)
<unmatched-paren>Those are some... interesting choices, `guix style`.
<nckx>let vs. setenv wut even why.
<nckx>I would not recommend running ‘guix style’ and committing the results.
<nckx>apteryx: Was there a reason for choosing BIOS initially?
<nckx>I'll rephrase: is there still a drawback/trade-off you made switching to UEFI now?
<unmatched-paren>nckx: yeah, i ended up resetting those changes :P
<unmatched-paren>nckx: could you have a look at the v2 patchset i just sent to #55999, if you're still interested in fixing Dub?
<nckx>Noted but not now.
<unmatched-paren>ok :)
<hugonobrega[m]>unmatched-paren: I don't have much to add, so pardon the ping if it's against house rules, but I was the original bug reporter so just wanted to say thanks for looking into this stuff
<unmatched-paren>hugonobrega[m]: no problem :D
<unmatched-paren>happy to help where i can. "where i can" isn't often due to my general inexperience :P
<unmatched-paren>hugonobrega[m]: all it took was updating Dub, really. we were 16 non-patch versions behind...
<hugonobrega[m]>nice, this whole thing came from me trying to package some things to teach myself guix+guile too
<hugonobrega[m]>yeah I figured as much, I managed to work some of that out locally but not all the way
<hugonobrega[m]>as you can see from my question on this channel a couple of hours ago I'm still somewhat in the "asking silly questions" phase, but knowing me that phase doesn't actually ever end
<jpoiret>hugonobrega[m]: we're all the silly person of someone else
<hugonobrega[m]>yeah totally
*unmatched-paren "Hello, is this Custom Signposts Co? I'd like to order a digital signpost saying 'Stupid Questions Welcome'."
<hugonobrega[m]>I'll order a couple for my day job (I'm a teacher)
***mark__ is now known as mjw
*unmatched-paren "What?! It comes with DRM?! I'll take my money somewhere else!"
<tangonov>I am not a ruby dev, but I need ruby tools to do a job. The package I am preparing for guix has a testing option, which is failing, because the gem seems to be missing a path to some file. Presumably because it doesn't exist. The path of least resistance is to turn tests off. Let's pretend for 5 minutes that I'd actually like to see tests run. Can anyone give me some pointers?
<hugonobrega[m]><tangonov> "I am not a ruby dev, but I..." <- disclaimer: I don't know much. but is the stuff that's missing packaged already in guix? if so, I'd try adding the package(s) in your package definition as native-inputs
<maximed>Does someone know how to resolve ‘File ... is read-only; trying to patch anyway’?
<maximed>(when adding a patch to an origin using git-fetch)
<maximed>For some git-fetch origins, this works, but not for others.
<tangonov>hugonobrega[m]: I was able to package the dependencies, how to do that was pretty clear :D
<tangonov>However, the testing that's part of the target gem in particular is calling for some sub-directory for itself. I have no idea if gems even deploy with these directories/files.
<tangonov>If they do, rake cannot seem to find it
<tangonov>I am thinking I need to make use of `#:test-target` somehow. Other gems in /guix/gnu/packages/ruby.scm seem to specify a string for some reason.
<lilyp>I don't know how this works for ruby, but #:test-target is supposed to be the second argument for make, e.g. ("make" "check") or ("make" "test"), and so on
<tangonov>That is helpful to know. If there's no makefile, then we will get nowhere
<tangonov>It starts out reading like it's trying to do something with the check command, which is only a little confusing. I'm not sure how abstracted gems are for guix:
<hugonobrega[m]>tangonov: my guess is you need to change into the appropriate directory before the check phase
<hugonobrega[m]>(arguments... (full message at
<tangonov>hugonobrega[m]: Thanks for that. There's a pretty good example of where to get test pre-requisites in `ruby-listen` as well. It involves pulling the repo source.
<hugonobrega[m]>tangonov: oh, bingo?
<hugonobrega[m]>;; Rubocop is for code linting, and is unnecessary for running
<hugonobrega[m]> ;; the tests.
<tangonov>If I need a newer package version of a dependency, what's the etiquette? Can I bump the existing package, or define a new one? I assume a new package is in order.
<tangonov>hugonobrega[m]: Yeah! I'm realizing that getting into the abstraction that is the guix package API is fairly straight forward.
<nckx>tangonov: If the update doesn't break any dependents, and it doesn't rebuild more than 300 packages, you can just replace it. ‘guix refresh -l PACKAGE’ tells you both that number, and which packages need to be rebuilt to test.
<nckx>Of course existing broken dependents can be ignored if they still fail to build. If they suddenly start building with the update, all the better.
<tangonov>Ok, so the refresh lists 7 other packages that may be rebuilt.
<tangonov>But I don't see any sign of an error.
<nckx>So you've added the package to your local guix git repository, then ran ‘./pre-inst-env guix build [said list of packages]’, and everything builds?
<nckx>If so, sounds good to go.
<tangonov>I did not! That's the next step, I suppose.
<nckx>Assuming you've tested the package itself by running it, of course, but how (or if) that's done depends on its nature.
<nckx>tangonov: ‘guix refresh -l’ won't throw errors.
<nckx>It just prints that info.
<tangonov>builds are running
<unmatched-paren>tangonov: after that, you'll want to `./pre-inst-env guix lint PKG` and fix any issues it may raise :) i would recommend `guix style`, but I've just learned that its styling is often... dubious.
<tangonov>Whatever makes it simple for someone to accept the patch
<nckx>I wouldn't recommend guix style now, since its suggestions are often as not worse than what a newishbie would come up with just by emulating other packages.
<nckx>If you don't know what to ignore, it's not a win (yet).
<nckx>Now ‘guix lint’ — there's a good boy. Be sure to run that if you haven't yet.
<patched[m]><nckx> "tangonov: If the update doesn'..." <- I am in a similar situation but for sdl2, which has 527 dependents. How would one best go about that then?
<tangonov>So `ruby-listen` is presumably hashed from a git checkout. Normally we get our hashes from a base32 representation of a sha256 checksum of a file. If the method is `(git-fetch)` I wonder where what we're checksumming
<unmatched-paren>tangonov: it's basically the equivalent of running `guix hash -rx .` in the git repo checkout
<unmatched-paren>-r means recursive (hash whole directory), -x means exclude vcs-related paths like .git/
<tangonov>This is good to know, in the event I want to be able to verify a checkout myself, without just going "oh, that's red!" and copy/paste it
<maximed>(on git-fetch + read-only issue): for now I'll apply the patch & make a git repo with the patch applied
<nckx>patched[m]: Locally nothing, but when you submit the patch (1) mention that it goes on the staging branch, as mentioned in the manual (grep for 300 or something), and (2) just don't expect to see your changes on master soon.
<nckx>Neither are big deals if you're aware of them. (1) is optional but polite, and avoids misunderstandings.
<nckx>The distinction is more important for committers than for patch senders.
<nckx>…so when you push to ‘master’, git doesn't send the name of the local branch anywhere, rite?
<nikola_>I am pretty sure it doesn't
<patched[m]>Allright. If I want to submit a package depending on that version, should I submit a version with a package variant in the meantime?
<nckx>nikola_: Phew.
<nckx>patched[m]: Is this a security update?
<nckx>If not: yes.
<nikola_>May i ask why, nckx
<nckx>my current one is extremely rude.
<nikola_>Lol now I'm curious
<nikola_>You're probably fine though
*nckx was being an idiot yesterday, yelling at self always helps 👍
<justkdng>hello again everyone
<justkdng>I'm trying to build a package but I'm getting this error when compiling
<unmatched-paren>justkdng: \o
<patched[m]>nckx not a security update, just an update that allows it to listen to pulseaudio monitor channels
<justkdng>make[1]: cc: No such file or directory
<justkdng>is there a dependency I'm missing?
<unmatched-paren>justkdng: you'll probably want to set $CC in make-flags
<maximed>justkdng: Is this when building a package (with Guix?)
<unmatched-paren>#:make-flags #~(list (string-append "CC=" #$(cc-for-target)))
<unmatched-paren>i think this error is because guix does not alias gcc to cc by default
<nckx>Being explicit is fun.
<justkdng>I indeed have that line
<justkdng>I'm trying to build old efivar
<maximed>justkdng: What package fails to build?
<justkdng>so just mostl copied the definition and changed versions
<maximed>pesign or efivar-old?
<nckx>patched[m]: Then yes, I'd create a variant, with a comment explaining why it exists, and use it in as many packages as you need/want to that don't hit the limit together.
<nckx>For bonus points send a second patch that ‘undoes’ the variant and updates the main package normally, that can be pushed to staging when master's merged.
<maximed>justkdng: Maybe run "grep -rF 'cc'" in the unpackad sourec code?
<maximed>to determine where the cc comes from
<nckx>patched[m]: Nobody does that but it would save the committer time.
<patched[m]>nckx good idea, I'll remember that
<unmatched-paren>looks like it's trying to be clever while cross-compiling...? probably not the issue tho
<unmatched-paren>no idea what $(filter default) means: $(if $(filter default,$(origin CC)),$(CROSS_COMPILE)$(COMPILER),$(CC))
<maximed>Looking at that file, it looks like 'CC_FOR_BUILD needs to be overwritten.
<unmatched-paren>ah, yeah.
<justkdng>oh, instead of CC?
<maximed>I'd guess: CC_FOR_BUILD=gcc
<unmatched-paren>this is a weird makefile, yeah
<maximed>justkdng: Both.
<maximed>i.e., point CC to #$(cc-for-target), and set CC_FOR_BUILD to gcc.
<justkdng>ok, I'm getting more errors related
<justkdng>is there a way to view the commit that updated efivar to 37?
<nckx>[Update your Tors]
<unmatched-paren>justkdng: it's just
<unmatched-paren>just bumping the version number...
<nckx>Commit message discipline for the win.
<justkdng>no, I meant in guix
<maximed>justkdng: you can do "git log --grep efivar" in a checkout of Guix
<maximed>Needs some degree of manual interpretation though.
<gnucode>hey guix! I am going to try to push my WIP smtpd-records today...
<maximed>Hmm I thought that the data service was supposes to implement that kind of searching?
<nckx>git log --format=oneline --grep 'gnu: efivar: Update' should really do it unless somebody screwed up.
<maximed>I found but it doesn't seem to have an ‘here's a list of old versions’ kind of thing
<justkdng>hmmm, when doing a guix pull I checkout the guix repo right?
<justkdng>where is that repo stored?
<maximed>justkdng: A checkout of the guix repo is made, somewhere behind the scenes
<maximed>TBC: modifying that repo has no effect, and it's technically an implementation detail
<justkdng>I figured if I already have it downloaded somewhere
<justkdng>it would be faster to check the git logs from there
<justkdng>than downloading the guix repo again
<maximed>justkdng: Ok
<maximed>I recommend making a new repository, and adding the checkout made by Guix as a remote
<maximed>(that way, you avoid interfering with Guix' copy)
<maximed>let's see where it's located ...
<maximed>Found it: it's a subdirectory of ~/.cache/guix/checkouts/
<civodul>maximed: hello! did you have further comments regarding home-openssh-service-type?
<justkdng>ok, efivar-37 is basically what I have
<justkdng>but probably the compiler is now messing with some stuff (?
<maximed>civodul: No new comments.
<justkdng>cc1: all warnings being treated as errors
<nckx>The relevant error is *somewhere* above that.
<nckx>Basically, a warning was emitted by the same people passing -Werror to the compiler.
<nckx>You need to fix that warning for them or remove the -Werror somehow.
<justkdng>yeah, I'm looking for the addition of Werror
<nckx>This package is unbelievable.
<unmatched-paren>could be worse! at least it's a makefile and not a cmakefile!
<unmatched-paren>sorry, CMakeLists.txt. (will never understand why ".txt"...)
<tangonov>If a ruby package like "listen" is trying to move a bunch of files around at test time, and tests are failing with EBADF - Bad file descriptior - might this have something to do with the immutability of the /gnu/store?
<nckx>I think you do, but I won't spoil your vibe.
<unmatched-paren>nckx: were you talking to me?
<unmatched-paren>if so, i genuinely don't understand it :P
<nckx>tangonov: It's impossible to say ‘no’, but it's not in the top-N of expected errors either.
<justkdng>hmmm, damn you red hat, and your shaenanigans
<nckx>unmatched-paren: …Windows?
<justkdng>Error: invalid attempt to declare external version name as default in symbol `efi_set_variable@@LIBEFIVAR_0.24'
<unmatched-paren>nckx: surely they'd use something like `.cmk`
<unmatched-paren>.txt denotes a plain text file...
<nckx>That's scary and won't pop up Notepad by default.
<nckx>unmatched-paren: Which it is?
<nckx>unmatched-paren: Are you advocating… they make it something else? Are you mad?
<nckx>Stop giving them ideas right this minute, young person.
<unmatched-paren>nckx: i'm sorry, o cmake gods! i repent!
<unmatched-paren>thy file extensions and GUI art sacred and I am but a sinner for condemning them!
<nckx>‘Dear users; sadly, the IANA has rejected our binary/cmake MIME type proposal.’
<nckx>‘This leaves us with no choice but to use .xml instead.’
<nckx>unmatched-paren: Happy.
<justkdng>It seems that error is related to lto, is lto enabled by default in guix?
<unmatched-paren>nckx: "Since a binary format is obviously 3000X more efficient, we will be designing a bxml format for build files."
<nckx>justkdng: …no?
<nckx>$(call enabled,ENABLE_LEAK_CHECKER,$(call enabled,ENABLE_LEAK_CHECKER_LTO,-flto,),
<unmatched-paren>"Hopefully IANA will be decieved by our claims that it's supposed to be a generic binary version of XML."
<nckx>There's EBML, but that would still be a standard, so I see your point.
<civodul>maximed: alright i'll go ahead then, thanks!
<unmatched-paren>"Dear users: we have decided that designing a binary format is too hard. Therefore, we will from now on be storing build recipes in Microsoft SQL Server databases."
*nckx waited minutes for a simple grep to complete, was sure their file system was hosed, probably took the kernel with it, not this again, turned out they had a file named ‘-’ in the cwd. I love Unix Fridays.
<civodul>unmatched-paren: you write you'll understand ".txt", but what about "Lists"? :-)
<nckx>Someone else!
<unmatched-paren>civodul: fair point! :)
<civodul>this CMake thing is an endless source of...
<civodul>of what?
<nckx>Of lists?
<civodul>lists, yes!
<justkdng>but I like cmake :(
<civodul>justkdng: that's okay!
<nckx>(The original topic wasn't even CMake, but a Red Hat Enterprise Software Enterprise that uses GNU make, but in the most something way imaginable.)
<unmatched-paren>"Dear users: for your convenience we will be bundling precompiled MS-SQL binaries for Windows, Linux, and Mac directly in the CMake source code. This ensures build files can be readable out of the box."
<justkdng>ok, seems they fixed it in a commit after the release of 37
<nckx>Sweet relief for once.
<unmatched-paren>justkdng: I used to like Cargo before I started contributing to Guix :) believe me, certain software packages seem nice and simple for users, but are hell for distros
<nckx>unmatched-paren: I encountered that once, but it was $random_project bundling a cmake.exe in their source tarball.
<nckx>It was a bootstrappable build.
<justkdng>how can I use that git commit as the source?
<justkdng>unmatched-paren: could be a guix issue ;P
<maximed_>justkdng: Have a look at git-fetch
<justkdng>rust's bootstraping is a nightmare
<justkdng>having to compile all previous versions
<unmatched-paren>nckx: have you ever encountered a project embedding a binary _directly in the source tarball_, though? :P
<unmatched-paren>*sourc code
<unmatched-paren>not tarball..
<unmatched-paren>as a byte array :P
<maximed_>unmatched-paren: Look for ‘blobs’ in the Linux kernel
<unmatched-paren>justkdng: you can use whatever build tool you like :) it's all just a matter of preference. guix users tend to be a little cynical about complex build systems, from what i can see, though
<tangonov>nckx: It's trying to make moves in the /tmp/ directory. The folder "guix-build-ruby-listen-xxx" is not in my /tmp folder. If I dig deep into the store may I find it and check the file permissions?
<unmatched-paren>maximed_: ...okay, that's another excellent point.
<unmatched-paren>--why is it so easy to demolish anything i say with a really obvious counterpoint--
<nckx>tangonov: Is there a reason/suspicion why you're fixated on permissions? They don't seem relevant.
<nckx>Are you getting a ‘permission denied’ anywhere else?
*nckx AFK though.
<tangonov>nckx: It's because I'm trying to appreciate whether or not Errno::EBADF: Bad file descriptor in is happening because of some permissions weirdness.
<justkdng>ohh, ty nckx, I was checking the cookbook though ;)
<justkdng>appreciate it though if I could get some feedback on my solution
<morganw>Does anyone know if there is a variable that can be used within the Guix Home configuration to get the path to the home directory?
<unmatched-paren>morganw: why not just (getenv "HOME")? should work...
<justkdng>I'm getting invalid field specifier
<morganw>unmatched-paren: I wasn't sure the environment where the build runs is stable, but I'll give it a try. Thanks.
*nckx ret.
<maximed_>justkdng: Guix doesn't do install staging (was that the terminology), so setting DESTDIR is pointless.
<maximed_>Also, the DESTDIR is incorrect, if anything, it should be /
<unmatched-paren>justkdng: it's PREFIX that should be set to #$output
<nckx>morganw: The answer is something like that regardless, e.g., using (getpwnam "user"), it won't be a Guix-specific thing. Use the power of Guile.
<maximed_>it was 'prefix' (lowercase), in this particular case IIRC
<nckx>justkdng: Missing ) after the hash.
<nckx>maximed_: It's prefix & they said DESTDIR was necessary regardless, which was plausible given the general quality of the Makefile.
<maximed_>civodul: TBC didn't look at the documentation
<maximed_>nckx: I missed or fotgot that message.
<maximed_>Though, er, sounds plausible.
<nckx>Yeh :-/
<nckx>I didn't verify it either. I'd rather it works before we start changing ‘details’ (your point is correct, of course, but first steps first).
<civodul>maximed_: ok, noted; i guess we can adjust the doc later on if needed
<nckx>maximed_: I think this is day 2 of justkdng packaging pesign, but it might be more.
<nckx>It's not a friendly learning package.
<nckx>justkdng: Any luck?
<justkdng>in what line is that missing ) ?
<nckx>After the hash.
<nckx>You're closing up to (origin, but not (source, no?
<nckx>(base32 …)))) ←
<justkdng>ah yeah
<justkdng>there was a rogue )
<gnucode>nckx: So I just submitted my opensmtpd-records to guix-patches.
<gnucode>It probably needs a fair amount of work.