IRC channel logs


back to list of logs

***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | get Guix at | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged: | 1.1.0 is out!'
***ChanServ sets mode: -o nckx
<nckx>mbakke: Thanks for your merge write-up.
<mbakke>nckx: thanks -- I wish I had better terminology for the different types of merge conflicts :P
<nckx>I did a little ‘wait, what?’ when you wrote ‘hidden merge conflicts’, it's good to be reminded I know nothing about this stuff.
<nckx>In a constructive way 😛
<nckx>I'm usually the git guru in the room (bizarre, I know).
<civodul>signalfd's in the house, my friends
*civodul -> zZz
<nckx>Everyone's going to bed on these epic achievements.
<nckx>And imma be all ‘welp, time for z's I guess’.
<sirmacik>does anybody have an idea how to make hunspell-dict package more friendly for non english based languages?
<sirmacik>wuth current url it works only for en*
<sirmacik>I'd like to ad a Polish one but have no idea how to approach modyfing that package
<roptat>sirmacik, I think we have French dictionaries too
<sirmacik>oooh, I see them now. En dicts are at aspell.scm, others are moved to libreoffice.scm
<roptat>probably because hunspell is defined in libreoffice.scm?
<kmicu>I need to confess that every time Ludo mentions signalfd my brain replaces it and tells me that Ludo mentions Seinfeld.
<alextee[m]>is there a way to extract .dmg's?
***sneek_ is now known as sneek
<nckx>alextee[m]: Try loop-mounting it as -t hfsplus, if the Guix kernel supports that.
<alextee[m]>oh 7z can do it it seems
<alextee[m]>`7z x mydmgthing.dmg`
<nckx>…but that's not in Guix…
<alextee[m]>what :o
<nckx>🤷 Maybe unrar, maybe just waiting for that special alextee[m] to come along & bundle it up.
<alextee[m]> /gnu/store/ywm5v7sbs5xfk3rhkngjrk9ddhxq13b3-p7zip-16.02/bin/7z
<nckx>alextee[m]: ‘p7zip’? Any idea why?
<alextee[m]>i think msys2 has a similar name
<nckx>Ah, the p stands for POSIX (I think).
<alextee[m]>on archlinux it's also p7zip
*alextee[m] has spent almost a week packaging zrythm for windows and has almost gone insane but thank god finally made a CI build it (on azure...)
<nckx>7z is usually the first thing I install on other's non-free systems. I had no idea it was in Guix. Shameful.
<alextee[m]>i tried mxe, cerbero, meson cross files... in the end i went back to mingw and ended up using a windows machine on azure with msys2.. i wish i could cross build on guix somehow if we had a framework for mingw packages.i doubt many people care (and that's probably a good thing), but as an app developer i think having lots of users on different platforms will lead to more stable software so cross platform is helpful (also i
<alextee[m]>sell more installers :P)
<alextee[m]>i went back to msys/mingw on windows *
<nckx>alextee[m]: So is mingw in Guix only for wine?
<nckx>Re: good thing: perhaps, but don't hesitate to propose mingw toolchain improvements or ask about how it's supposed to work on the mailing lists, by the way. Getting more free software on non-free platforms is FSF-fine.
<alextee[m]>nckx: idunno. apparently it can be used to build a cross compiler 🤷‍♀️ ideally we should have a mingw build system that works like this:
<alextee[m]>i'd help but i have no idea how the mingw toolchain works : - ) i can only complain
<nckx>Please complain very constructively and it's all good.
<nckx>(I don't know the first thing about wingthings.)
<alextee[m]>i'll probably propose something that would be useful as a packager of things, and give an example of what i would expect from a mingw64 build system
<nckx>alextee[m]: I assume you're in contact with dongcarl as well?
<alextee[m]>he mentioned something about the bitcoin package here nckx:
<alextee[m]>i looked at it but it's still a bit of wizardry to me
<nckx>Same here I'm sure.
*alextee[m] prepares some new patches
<ryanprior>Guix has my 8-core machine pegged at 100% building ungoogled-chromium and it is ccrraawwlliinngg
<sirmacik>afaik building chromium tends to kill any machine
<ryanprior>Might have to abort my upgrade in 15 minutes if it doesn't pick up the pace, which would be sad.
<alextee[m]>ryanprior: amd ryzen?
<ryanprior>It hasn't progressed 1% in the past 5 minutes which tells me this is going to be an hours long thing.
<ryanprior>So that's cancelled, I'm not building that.
<nckx>Good call. It's not going anywhere in 15 minutes on a mere 8 cores.
<marusich>ungoogled-chromium is just super slow
<marusich>At least you aren't waiting on the daisy chain of rustc packages in order to build icecat
<alextee[m]>should i add new packages at random places in .scm files? iirc someone mentioned that it's easier to merge that way without conflicts vs appending at the end
<nckx>But those Rust builds are at least checkpoints of sorts.
<marusich>IMO that's fine, alextee[m]. The packages are out of alphabetical order in many cases, anyway, and yes, adding them randomly is less likely to produce merge conflicts later.
<nckx>alextee[m]: Eh, try to put them somewhere alphabetical instead, but most are such a mess…
<nckx>‘Random’s a new one tho'.
<alextee[m]>yeah there's no alphabetical order so i can't really do that
<alextee[m]>although i can alphabeticize the music.scm file
<alextee[m]>should i do it?
<nckx>No no.
<marusich>I personally am not sure there is much value in doing so
<nckx>A more diplomatic no no.
<marusich>If someone is looking for a package, usually they are not looking manually alphabetically; they are using git grep or guix edit
<marusich>or something else like that.
<alextee[m]>but it's not organized!
<nckx>I don't like this new ‘random’ advice. Some files are (roughly) sorted. If anyone starts putting packages randomly in sorted files like perl.scm I will point at them until they stop.
<alextee[m]>what's wrong with sorting a file though?
<alextee[m]>i can do it
<nckx>It's an extremely noisy & destructive git change.
<alextee[m]>fair enough
<nckx>gnu: packages: Break ‘git blame’.
<alextee[m]>well you can already search the git history for who did what changes to what package without git blame
<marusich>It also increases the risk of merge conflicts when everybody decides to add their new packages at the end of the list. And because the order is not strictly enforced, it is likely that it will become unordered again.
<marusich>I'm not saying you should always put something randomly in a list. I'm just saying that personally, I would not mind if packages are not strictly sorted.
<marusich>I honestly would usually try to put things in an order of some kind that makes sense, but then yeah there is a small risk that merge conflicts can occur if it's a busy file.
<nckx>alextee[m]: git log doesn't compete with git blame though. They are quite different. Or at least: I don't like git blame, but I still use it, so it must do something git log can't.
<marusich>In the end, I think the downsides to re-ordering the list (encourages merge conflicts, makes git history harder to read, will not ensure order is maintained) outweigh the problems of leaving things kind of messy.
<sirmacik>maybe ther should be some kind of commented out EOF mandatory snippet so those kind of patches don't cause much trouble?
<marusich>Arguably, the lack of visibility into git history is something that git porcelains should be able to make go away.
<nckx>If you're starting a new file by all means sort the things (and add a comment asking others to do so, perl.scm-style) but don't submit mass reshufflings.
<marusich>And, we could have scripts that enforce the ordering of packages etc. But I don't think we do.
<marusich>sirmacik, the problem with merge conflicts isn't that the changes happen at the end of the file - it's that they modify the same portion of the file.
<sirmacik>ah, got it
<alextee[m]> patch updated
<alextee[m]>we almost have as many lv2 plugins as archlinux!
<alextee[m]>lv2ls | wc -l
<alextee[m]>i have 571 here
***catonano_ is now known as catonano
<alextee[m]>just sent a couple more patches!
<anadon>Good evening folks
<nckx>Hullo anadon.
<nckx>alextee[m]: \o/
<azvede>is there a guix package that contains the ldd command? `guix search ldd` gives me nadanothing
<nckx>azvede: Sure, glibc.
<azvede>ahh, thanks
<azvede>is there a discoverability method I can use that would be better than guix search 'command' and less annoying than troubling you fine folks?
<anadon>nckx: I'm still going over your response email this weekend. It'll take some time to get together a strong argument, but I think it is there :P
<nckx>Here my lack of IRC ←→ mail name mapping fails me.
<nckx>Argument for?
<nckx>Welp, time for z's I guess. o/
*nckx → 😴
<pkill9>does anyone know how to fix this error when running `ssh -X <ip>`? Warning: untrusted X11 forwarding setup failed: xauth key data not generated
<pkill9>I'm trying to do X forwarding
<pkill9>into a server running guix system
<pkill9>i've enabled x11 forwarding in the openssh server, and confirmed it by reading the config file the process is using
<anadon>nckx: the client daemon implementation and interfacing
<anadon>nckx: Usually that's me that can't keep the names straight :P
<anadon>pkill9: If you _really_ trust the address, try "-Y" instead.
<azvede>so, any suggested method for determining which package contains a command you want?
<pkill9>anadon: i tried that too but it didn't work
<pkill9>with -Y it says "Warning: No xauth data; using fake authentication data for X11 forwarding.
<pkill9>i added stuff to ~/.ssh/config on the remote machine too
<anadon>pkill9: In an isolated environment -- one which has forgotten the previous sert for that server -- try using ssh -X there
<pkill9>that removed the error
<pkill9>where is this cert?
<anadon>Looks like the Aegis package no longer compiles, and is no longer maintained. Author looks like he fell of the face of the earth in 2014.
<anadon>pkill9: I don't remember that bit off hand. I'd try googgle for removing an ssh cert.
<pkill9>oh, it didn't work this time
<pkill9>when i exposed /tmp/.X11-unix
<anadon>Holy crap, the maintenance group is all together dead.
<anadon>Under what conditions do re remove packages?
<pkill9>the maintenance group?
<azvede>presumably the maintenance group of the Aegis package
<pkill9>what is aegis?
<pkill9>can i have a link?
<pkill9>i like abandoned stuff, like abandoned buildings
<anadon>Aegis was a version control system.
<anadon>Looks like John Darrington and Alex Kost are the originators of the package. Are they still around?
<anadon>Original submiters seems to be quiet, too. John hasn't been on in 2020.
<anadon>Alex hasn't been on in months.
<vagrantcish>guix doesn't have a strong maintainership model, though ... e.g. anybody can propose to update any package, in general
<vagrantcish>or maybe, not strong maintainer "ownership"
<vagrantcish>it's a model with different strengths :)
<apteryx>indeed. That the orignal contributors of a package are not around anymore or haven't bothered maintaining said package doesn't mean that much in Guix. It's up to anyone who has an interest in said package to maintain it.
<azvede>am I missing a distinction between project maintainer and package maintainer? because that seems like it could be problematic if anyone can make a change to a package
<anadon>I'd feel bad updating the version and updating the homepage but still knowing the thing can't build.
<azvede>anadon, seems like if it can't build, updating is a fine thing
<vagrantcish>azvede: anyone can propose patches, some people can commit directly (though are encouraged to propose patches for significant changes)
<azvede>vagrantcish, ahhh, that puts my mind at ease
<anadon>I don't envy the user who will need this. Best advice to them is to go back in history and build the thing from an older state of guix right after the first few commits.
<apteryx>anadon: updating the version and homepage doesn't make much sense if the package doesn't build; perhaps a fork exists that fixed the build problems, or some patching could be done to make it build
<anadon>apteryx: It is abandonware. I don't think any exist.
<anadon>brb, reboot
<anadon>Confirmed that aegis's author died in 2015.
<anadon>Rest in peace Peter Miller. Your name has echoed yet again.
<anadon>Is it possible to specify a build system from guix at a certain point in time?
<apteryx>no. You have to start with a given build system, and add phases of another build system to combine more than one build system.
<butterypancake>I'm having trouble package opendoas. It's configure script doesn't support setting variables as arguments (ex ./configure CONFIG_SHELL=/blah/blah). I'm not sure how I'm supposed to remove this type of argument from the configure-flags
<pkill9>what could cause 'undefined reference' errors in the linking phase of a binary in a compilation in a guix build, but not when manually compiling?
<anadon>OK, aegis got fixed up. Patch submitted. Hope Markus doesn't grill me this time!
<apteryx>anadon: neat :-)
<apteryx>pkill9: a missing library (the obvious one :-)). Or a missing environment variable? LIBRARY_PATH is the one, I believe.
<pkill9>It's from a library file in the source though
<pkill9>damn anadon :/
<butterypancake>when packaging, what should I set the library path too?
<anadon>pkill9: ?
<pkill9>that the author died
<anadon>Yeah. On the face of it, it is sad. I'm in no place to judge the man.
<pkill9>apparently he was a significant contributer to GNU Gettext
<anadon>Wow. He had an impact. I was using gettext last week.
<anadon>This is why we need the internet archive.
<pkill9>yea, loads of packages use gettext
***sneek_ is now known as sneek
<marusich>sneek, later tell dftxbs3e I haven't finished reorganizing/reformatting all your commits yet, and I have some questions I will ask later, but for now I thought you might want to know that with your first small change, applied to origin/master, a cross-built guile does not segfault:
<raghavgururajan>Hello Guix!
<raghavgururajan>I need an urgent help with git. Anyone proficient with git is online and available for 10-15min please?
<raghavgururajan>This is regarding the use of worktrees.
<azvede>hi again guix, so I found that online man pages can be the reference from command to package I was looking for... but now I'm running into a situation where a perl install script cannot find commands that I know exist... uname and cut... is this a profile issue or something where I can use coreutils, but my perlscript can't?
<rekado_>raghavgururajan: maybe I can help
<raghavgururajan>rekado_: Thanks, just a sec.
<rekado_>azvede: does it reset PATH?
<azvede>script gives me `sh: uname: command not found` whether I sudo or not; uname returns `Linux`
<azvede>rekado_ ah, that gives me an avenue to run down
<azvede>let me check into that, thanks and sorry for missing the obvious
<raghavgururajan>So I cloned guix repo and `cd guix`. Then did `git worktree add --track -b wip-desktop ./wip-desktop origin/wip-desktop`.
<raghavgururajan>When I `cd wip-desktop` and did `git status`, I get Your branch is up to date with 'origin/master'.
<raghavgururajan>But I wanted to track origin/wip-desktop
<rekado_>can you do “git checkout wip-desktop” in that worktree?
<raghavgururajan>You mean to do `git checkout wip-desktop` inside '~/guix/wip-desktop'?
<rekado_>oh, one moment
<rekado_>your worktrees are *sub-directories* of the main repository?
<rekado_>I don’t think that actually works
<raghavgururajan>I tried what you asked.
<raghavgururajan>I got
<raghavgururajan>Already on 'wip-desktop'
<raghavgururajan>Your branch is up to date with 'origin/wip-desktop'.
<rekado_>can you try adding a worktree in a sibling directory instead?
<rekado_>my worktree setup looks like this: ~/dev/guix/branches/{master,core-updates,…}
<raghavgururajan>So to do `git worktree add --track -b wip-desktop ./branches/wip-desktop origin/wip-desktop` in the '~/guix'?
<rekado_>the master branch is in ~/guix, isn’t it?
<raghavgururajan>yes, master branch is in ~/guix
<rekado_>I don’t think you can put worktrees inside of repo checkouts
<rekado_>I would clone to ~/guix/branches/master
<rekado_>and then add the worktree for wip-desktop to ~/guix/branches/wip-desktop
<rekado_>~/guix should not be a repository itself
<raghavgururajan>So `git worktree add --track -b wip-desktop ../wip-desktop origin/wip-desktop` instead? This will create worktree as ~/wip-desktop, alongside ~/guix.
<raghavgururajan>Okay. Just a thought. Instead of worktrees, can I clone different branches directly via `git clone`?
<rekado_>yes, you can do that but you will have multiple copies of the repository then
<rekado_>with worktrees you share the one repository but get separate views on it
<raghavgururajan>Ah I see.
<azvede>rekado_ seems like it's not interacting with the path as far as I can tell... is it like MS where there's a different path for different contexts?
<rekado_>this also means that for worktrees you don’t have to run “git fetch origin” separately; once is enough
<raghavgururajan>So I did ../wip-desktop and it works. It tracks origin/wip-desktop.
<rekado_>azvede: no, there’s just one PATH variable that will be effective
<azvede>sh: uname: command not found; sh: cut: command not found being thrown by the perl script.... huh...
<rekado_>azvede: how does it spawn uname? Have you grepped the source code?
<raghavgururajan>Now, I wanted to checkout multiple temp branches based-off wip-desktop. So I would normally do `git checkout -B fix-foo` inside ~/wip-desktop, correct?
<rekado_>yes, but that might be confusing given the name of the worktree
<rekado_>you can do that, but you would still need to switch branches and recompile stuff after switching
<rekado_>worktrees are rather cheap, so maybe just add more worktrees?
<raghavgururajan>Hmm. My plan is to have a local branch 'wip-desktop' that tracks origin/wip-desktop. Then create temp branch based-off on local wip-desktop and create patches against it. These patch will be sent to Danny, which will be reviewed and pushed to origin/wip-desktop, by him.
<raghavgururajan>So if I have multiple worktress, is it possible to format patches against another worktree?
<rekado_>yes, your other worktrees can be based on wip-desktop
<rekado_>whenever you update wip-desktop you should rebase them
<raghavgururajan>I see.
<azvede>yeah...rekado_ it calls uname by doing my $release = `uname -r | cut -f1 -d-`;
<raghavgururajan>How would ./pre-inst-env guix commands work though?
<rekado_>raghavgururajan: the same
<rekado_>you run that inside of the worktree
<azvede>which seems like it should just work
<rekado_>azvede: can you print the value of the PATH variable in that script?
<raghavgururajan>Should I do `bootstrap, configure and make` for every work tree?
<azvede>i'll stick a debug print line in there, yeah
<rekado_>raghavgururajan: yes
<rekado_>raghavgururajan: but you only need to bootstrap and configure once
<rekado_>and you’ll only have to repeatedly make those files that you changed in the worktree, not all files that differ after switching branches
<raghavgururajan>Oh, I was hoping to prevent that. Because I get "this is different from that" prompts everytime I change working dir. This consumes too much starting time when I try to build something.
<rekado_>raghavgururajan: but it’ll be worse when switching branches in the same worktree
<rekado_>huh, I don’t know how this is possible, but my COLUMNS variable is reset
<rekado_>I started a root shell and typed “export COLUMNS=1024”
<rekado_>then in that shell session I started the daemon
<efraim>I have 3 worktrees, master staging and core-updates. My wip-ppc branch is against core-updates so I check it out on my core-updates branch, rebase, switch back and run make again
<raghavgururajan>Ah!. Okay, if I want to create another worktree 'fix-foo' based on the worktree 'wip-desktop', what should be the syntax?
<rekado_>then I ran “guix build foo” in another session
<rekado_>and back in the root shell COLUMNS is now 146
<efraim>if it were me I'd just use a branch instead of a whole worktree and only check it out on the wip-desktop worktree path
<rekado_>yeah, if it is short-lived and only one file will change then a worktree is too much work
<raghavgururajan>`git worktree add -b fix-foo ../fix-foo` while being in ~/wip-desktop?
<efraim>that looks right, but I'd have to check the documentation again
<efraim>sometimes after I git-pull in the morning I'll open a new terminal window, cd to guix and run 'guix environment guix -- make && exit' and minimize it. no need to wait for it to recompile the modules to keep working
<raghavgururajan>efraim and rekado_: Thanks! Let me play around with this.
<rekado_>hmm, changing the zoom level of my Emacs window changes COLUMNS
<azvede>after much futzing with getting perl to print a global variable in a sub, I have confirmed that it does have my normal path
<efraim>if I'm choosing a specific commit for a channel I use 'commit' or 'branch'?
<efraim>looks like 'commit' works
<raghav-gururajan>Woah! make is failing.
<raghav-gururajan>ld: libstore.a(libstore_a-build.o)(.text+0x2000000f918): reloc against `_ZN3nix8SysErrorD1Ev': error 4
<raghav-gururajan>efraim, Any ideas on how to rectify the above error?
<efraim>making guix-daemon should be single-threaded
<efraim>I'd run make, C-c after the daemon and then make -j3 or whatever number
<efraim>depending on how much you want to avoid 'make clean' I'd start by removing the .a files in the guix checkout and see if that takes care of it first
<raghavgururajan>make clean worked :-)
***apteryx_ is now known as apteryx
<janneke>mothacehe: nice patch set!
<mothacehe>thanks :)
<mothacehe>I'll send an email regarding the second half of "WIP directives" later on.
<janneke>it looks like your idea to create an explosive mixture of our disk-image and hurd-vm patches has worked!
<mothacehe>he, who would have thought :p
<janneke>;) good; i have pushed the <menu-entry> rewrite to my gitlab, together with cleanups and other smallish rewrites
<mothacehe>oh, great I'll take a look!
<janneke>i didn't want to reset savannah just yet and start that review -- better do your work first, wdyt?
<janneke>mothacehe: there's one ugly directives-related diff on 'wip-hurd-vm-new' that procudes a working disk image
<mothacehe>yes savannah is in a "working" state, so maybe we can keep it that way until "WIP directives" is handled
<civodul>Hello Guix!
<janneke>hello civodul!
<xelxebar_>I think there might be a (minor) bug in the code that checks for and displays mismatched hashes. When first coding up a package, I fill the base32 hash with a bunch of "x"s but when attempting a first build it claims the expected hash is "1xxxx..."
<xelxebar_>Am I just missing something?
<civodul>(bytevector->base32-string (base32 "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")) gives an interesting result
<civodul>ah but (bytevector->nix-base32-string (base32 "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx")) gives "1xxx..."
<civodul>i guess the 5 least significant bits are ignored or something like that
<PurpleSym>Somehow UID resolution is not working in `guix environment -C` for me. The shell just says "I have no name!". I tried modifying /etc/nsswitch.conf to include “files”, but no luck. Any ideas?
<civodul>PurpleSym: "I have no name!" is for the host name
<PurpleSym>civodul: No, it’s definitely the username: I have no name!@node01 ~ [env]$
<civodul>normally in -C there's only /etc/{group,passwd} in the container
<civodul>do you see anything else in /etc?
<PurpleSym>nsswitch.conf from the host, as well as resolv.conf and services.
<civodul>oh you did -CN maybe?
<PurpleSym>Oh, yeah.
<civodul>this is on a "foreign distro", right?
<civodul>so it may be that /etc/nsswitch.conf requires NSS extensions not available in the container
<civodul>and nscd is not running/available
<civodul>do you have /var/run/nscd in the container?
<PurpleSym>NSCD is running, I also see a socket in /var/run/nscd, but it’s running *outside* the container.
<PurpleSym>(I’m also passing -u joeuser)
<civodul>it's ok that it's running outside, that's the whole point
<civodul>could you add strace to the container and run "strace -o log id" and paste it?
<janneke>civodul: thanks for your reviews, just chiming in real quick here
<PurpleSym>civodul: Yep, here:
<janneke>on wip-hurd-vm, we succeeded in kludging our way around running a native qemu and fixing cross-build issues to finally produce a working guix system vm-image
<PurpleSym>I think I already know what’s going on: NSCD is running outside the container, but there is no UID 1000 outside. Since processes inside the container will use that nscd to resolve their UIDs, it’ll fail.
<janneke>it has some rough edges (e.g., weird hurd-exceptions, the sqlite thingy)...but it works
<janneke>now, we also *almost* have disk-image working, so we could try to remove all workarounds for qemu-image (sqlite) and jump onto disk-image right away
<janneke>civodul: i thought that we were somewhat "done" wrt the qemu-image cross build (hence: merge wip-hurd-vm)...but if that turns out to be much help! :-)
<PurpleSym>If I --expose=/empty=/var/run/nscd it works as expected, so nscd is definitely the problem here.
<civodul>janneke: yeah i don't know, maybe i'm trying to catch up but there's so much going on!
<civodul>looks like there are several discussions and patches in parallel
<civodul>like mothacehe said we could bypass (gnu system vm) entirely, so i don't know if it's still relevant to comment on these changes
<civodul>IOW: i'm lost :-)
<janneke>civodul: np...;) i have pushed the <menu-entry> rewrite to my gitlab (wip-hurd-vm), together with cleanups and other smallish rewrites
<janneke>that needs one extra patch to actually produce working disk-images (a very hacky commit lives on wip-hurd-vm-new), and mothacehe is working on doing that properly
<janneke>then we want to reset wip-hurd-vm on savannah, mothacehe is also looking into my new <menu-entry> patches
<janneke>so..yeah, it's kinda explosive...which has good and bad aspects :-)
<civodul>heh :-)
<mothacehe>hey civodul. janneke, do you think we want to merge the vm-image related stuff?
<mothacehe>(that civodul reviewed earlier)
<janneke>yesterday i thought vm-image/qemu-image was working and "done" / OK to merge so i was in favour of merging and then deleting
<civodul>mothacehe: i'm looking at and i'd like to discuss things some more (apologies :-/)
<janneke>now it seems that it would need some work (see register-closures/sqlite, maybe more) it could make sense to drop it?
<civodul>on master "./pre-inst-env guix system vm --target=arm-linux-gnueabihf gnu/system/examples/bare-bones.tmpl -n --no-grafts" doesn't work
<civodul>because of the bag-graft issue probably
<mothacehe>janneke: yes that's what I think, as closure registration should work with disk-image (and the sqlite issue does not exist).
<civodul>so it's really hard to just know where we are
<janneke>oh, that's also good and bad
<civodul>i think the sqlite issue is a symptom, not the root cause
<sirmacik>issues are down again
<sirmacik>something about yesterdays server works?
<civodul>weird, mumi seems to be running
<janneke>civodul: wrt sqlite, i imagined that doing it properly was a waste, as disk-image already does it properly
<mothacehe>civodul: yes the master issue seems to be related to the grafts problem
<janneke>and that it's so sad that when you're happy not to register closures (we've been doing #:register-closures #f anyway until now for the Hurd), and thus do not use sqlite, the build still fails because the module gets pulled in
<janneke>so, i opted for a quick and easy hack to use until it's removed...
<civodul>i'm always afraid of having to support quick-and-easy hacks for the years to come :-)
<janneke>i agree
<civodul>dynamic binding was a quick-and-easy hack from 2013 and it makes us suffer every now and then ;-)
<mothacehe>janneke, civodul: we could maybe turn wip-hurd-vm into wip-hurd-disk, which would drop any VM related stuff?
***dingenskirchen1 is now known as dingenskirchen
<janneke>mothacehe: yes! i was just about to propose doing that in-place, but wip-hurd-disk is also a great idea
<mothacehe>janneke: good! Your new <menu-entry> approach is terrific ;)
<janneke>mothacehe: great! well, dropping VM related patches makes the review easier anyway and code base smaller
<janneke>i'm going to take a stab at that -- it's still tempting to just reset wip-hurd-vm, dunno -- let me hear what you'd like, civodul/mothacehe
<sirmacik>hm, sill 502
<rekado_>sirmacik: sorry, up again
<rekado_>the problem is actually an undiagnosed error in guile-xapian, which crashes the application…
<rekado_>so I’m running it in a loop
<rekado_>not ideal
<wd-1>i've been having some unusual trouble compiling epdfinfo for emacs on guix. does anyone know what to make of these errors?
<rekado_>wd-1: are you not using the Guix package for it?
<rekado_>I found that much more convenient than compiling it manually
<rekado_>just “guix install emacs-pdf-tools”
<wd-1>i don't really want to mix straight-use-package and guix's emacs packages, especially since emacs-guix appears to be broken, and has been for me for most of this year.
<wd-1>i also don't compile much, but the problems here seem to hint at broader issues than just an emacs package
<sirmacik>rekado_: thanks, as for the error... uh, that sucks, but whatever works.
<efraim>well, I think ly works. hard to say
<janneke>mothacehe: /me pushes a new wip-hurd-disk to gitlab
<janneke>which uses your HURD nodes and adds two hacky commits
<janneke>and with all VM stuff removed
<mothacehe>janneke: ok great, fetching :)
<janneke>mothacehe: i hope you don't mind my patches bringing "back" old kludges -- i'm trying to take small steps while keeping stuff working
<janneke>and hope it helps you in doing a proper rewrite
<mothacehe>janneke: not at all, it's starting to get in shape :)
<janneke>mothacehe: great -- just checking!
<janneke>has anyone built qemu on master?
*janneke has been trying to build that all offload build keeps hanging and then fails, just now my ssh connection got interrupted :/
*civodul tries this on master: ./pre-inst-env guix system vm-image --target=arm-linux-gnueabihf gnu/system/examples/bare-bones.tmpl --no-grafts
<civodul>it's building stuff
<civodul>the good thing, if we fix that, is that we're closer to a good state
<mothacehe>janneke: could you update your wip-hurd-disk branch from ?
<mothacehe>I squashed some stuff
<nckx>Good morning Guix.
<mothacehe>hey nckx!
<janneke>hi nckx
<janneke>mothacehe: sure...building now
<janneke>mothacehe: ah, great => + (file-system-options '("-o" "hurd" "-O" "ext_attr"))
<janneke>that removed the need for the fs-options hack
<civodul>howdy nckx
<guix-vits>Hi nckx.
*civodul wonders whether nckx's place changed timezones
<civodul>the tzdata changelog will know
<nckx>rekado_, raghav-gururajan: Worktrees are just (fake) git repositories with their own .git, you can nest them just fine. I suggested ~/guix/.worktree/foo because that's what I use but use whatever works for you raghav-gururajan.
<nckx>civodul: I am a citizen of the world! Time is an illusion! Also it's 13:40 here.
<nckx>anadon: Should have logged in here before calling aegis ‘dead’. Inappropes. Thank you for taking care of it.
<rekado_>too bad wd-1 has left.
<rekado_>I would have liked more information on how emacs-guix is broken
<rekado_>I don’t like comments that imply things have been broken since forever, and then there’s never enough actionable information to confirm that or fix it in the best case.
<rekado_>so: o people of this channel! Here is my plea to you: please report bugs to and don’t work around problems. They fester.
<civodul>re emacs-guix, i'm aware of this issue:
<rekado_>and upstream says it was fixed with
<raghavgururajan>Is it necessary to propagate all packages mentioned in 'requires' field of .pc file?
<mbakke>civodul: the tunnels to nckx's aarch64 machines on berlin are down
<raghavgururajan>nckx: Thanks!
<raghavgururajan>nckx: Is it necessary to propagate all packages mentioned in 'requires/requires.private' fields of .pc file?
<mbakke>raghavgururajan: yes, they should be propagated so that e.g. 'pkg-config --libs foo' works if you run 'guix environment --ad-hoc foo pkg-config'
<raghavgururajan>mbakke: Cool! Thanks.
<raghavgururajan>mbakke: Even when the guix lint warns to move it to native-inputs?
<nckx>raghavgururajan: Sorry, I'm going to be ‘here’ but AFK most of the time today.
<mbakke>raghavgururajan: do you have an example? sounds like the linter is overzealous if that is the case
<mbakke>or, which package is the linter suggesting to move to native-inputs?
<raghavgururajan>nckx: No worries! Thanks for letting me know.
<raghavgururajan>mbakke: gobject-introspection
<rekado_>mbakke: I hope they are no longer necessary. Have you tried connecting directly?
<mbakke>raghavgururajan: oh, hm... that probably should not be propagated, sounds like a bug in the .pc file
<mbakke>rekado_: will try
<raghavgururajan>mbakke: OK.
<civodul>mbakke: ah, the tunnels
<mbakke>rekado_: I can connect from home, but not on berlin
<civodul>mbakke: it should be back up
<civodul>i added /root/
*janneke remembers a git pull --roll-back ... ah --allow-downgrades --roll-back
<janneke>guess that makes sense
<civodul>mothacehe: how does one boot a VM with qemu-system-arm?
<civodul>qemu consumes CPU but there's no console
<civodul>just the monitor
<mroh>good morning guix!
<mbakke>civodul: thanks!
<mbakke>'evening mroh
<mothacehe>civodul: I never tried to run a "final" system with qemu-system-arm.
*janneke reverts to cd5d5f53228fd5bf96d9f790aa2606ae71fa68d7 to get a working qemu
<mothacehe>But producing a disk image for ARM, involved spawning a qemu-system-arm. So at some point in time it did work.
<janneke>i finally have an error: make: *** [/tmp/guix-build-qemu-5.0.0.drv-0/qemu-5.0.0/tests/Makefile.include:636: check-qtest-x86_64] Error 1
<mothacehe>civodul: The Qemu command line to boot an arm system is tricky. You need to pass "-M virt", check that your console is "ttyAMA0" at least.
<mothacehe>You can check for those flags in "load-in-linux-vm" procedure of (gnu build vm).
<civodul>ah, i'm missing ttyAMA0
<civodul>based on a variant of janneke's patch, i can do "vm-image --target=arm-linux-gnueabihf"
<civodul>that successfully produces an image
<civodul>now i need to check that it's a valid image
<mothacehe>nice! for now, I consider that a cross-built image offering a prompt is a valid image :p
<butterypancake>so I'm packaging a c application using the gnu-build-system, and for some reason, I have to specify "CC=gcc" even though the makefile has "CC ?= gcc". If I don't it tries to use "cc" which doesn't exist. Is specifying "CC=gcc" correct or do we support other compilers as well?
<butterypancake>maybe I should mention there is no configure script so I had to skip that phase
<nckx>butterypancake: Not transparently. Passing ‘gcc’ is fine but take a look at commit aa784dc for how to do so with cross-compilation in mind.
***danielalura is now known as danjelalura
<butterypancake>nckx: That's very helpful! Thank you very much!
<nckx>Oh dear, Yoshimi's broken :-(
<nckx>alextee[m]: That a familiar error by any chance?
<alextee[m]>nckx: yeah that's with the new lv2 upgrade
<alextee[m]>if it's not fixed upstream yet it's easy to patch
<rekado_>1.7.1 is out already
<nckx>Oh, there's a 1.7.1 release.
<alextee[m]>it looks fixed in 1.7.1
<nckx>oshimiLV2Plugin.cpp:837:1: error: invalid conversion from ‘void* (*)(const _LV2UI_Descriptor*, const char*, const char*, LV2UI_Write_Function, <lots of ints>
<nckx>Different but same same.
<butterypancake>so it looks like I'm using an autogenerated github tarball. What's my alternative? Hard code the commit of the version?
<nckx>butterypancake: (commit …) can be anything that identifies a git object. No tags?
<nckx>(commit version) or (commit (string-append "v" version)) are common.
<butterypancake>nckx: ok, there is a tag. I'm just not certain how to use it.
<nckx>I meant that commit doesn't have to be a raw 40-character commit. It can be anything that git knows about, like a tag or (don't do this) a branch.
<butterypancake>oh ok. So I'd do (commit "v0.25"). Thanks!
<nckx>You'd use (commit (string-append "v" version)) to make updates fun.
<butterypancake>ah, I see what you did there now. Thanks :)
<butterypancake>Ok, so I've sorted out all the lint warnings except this one: ./mspdebug.scm:16:11: mspdebug@0.25: scheduled Software Heritage archival
<butterypancake>is this important?
<nckx>Heh, that's not a warning.
<nckx>Just informational.
<butterypancake>I'm glad it's displayed exactly the same as all the things I had to fix then :/
<butterypancake>anyway, I made a package! I'm excited! Time to submit, however I do that!
<alextee[m]>struct _LV2_Descriptor *
<alextee[m]>ok it's still not fixed upstream
<nckx>butterypancake: No, I agree, it's not like the other warnings and (IMO) shouldn't be shown like that.
<alextee[m]>i'll file a bug report
<alextee[m]>or fix it and send a patch
<nckx>Oh, thank you.
<apteryx>butterypancake: yay! :-) Submitting patches is covered in info "(guix) Submitting Patches". The whole Contributing section is a nice read, too.
<nckx>alextee[m]: Didn't mean to make it your problem, you're just the LV2 person in my mind now.
<butterypancake>apteryx: I'm on it! Thank you :)
<apteryx>you're welcome!
<dutchie>butterypancake: if you aren't familiar with sending patches to mailing lists with git, is a very helpful resourc
<nckx>butterypancake: Congratulations by the way 🙂 Submitting is the easy part, it only gets tricky with multiple patches. I recommend setting up git send-email (guix install git:send-email), once that's over & done with you'll save time & always send good patches. Saving others time.
<alextee[m]>nckx: any LV2 problems are my problems too! LV2 must prevail ⚔︎
<nixfreak>whats the command to see multiple profiles and their generations?
<apteryx>'guix package -l' lists the generation of your user profile
<apteryx>there's also a 'guix package --list-profiles'
<nixfreak>ok thanks
<apteryx>and the 'guix package' can take a -p option to specify a profile
<apteryx>so, you could do something like this at the shell: for p in $(guix package --list-profiles); do guix package -p "$p" -l; done
<nixfreak>very cool I see for loops a lot for work
<butterypancake>so I'm reading through the contributing info page but maybe it isn't up to date? apparently the guix makefile doesn't have an 'authenticate' target for me?
<guix-vits>butterypancake: ./bootstrap ?
<rekado_>butterypancake: ’make authenticate’ only works after bootstrap and configure
<rekado_>butterypancake: arguably it’s mentioned too early in the manual
<butterypancake>oh shoot, I'm an idiot. Only bootstraped on my arch machine :P
<butterypancake>but ya, it does look like it's mentioned a little early
<nckx>Depending on your set-up you might have to run it as ‘guix environment guix -- make authenticate’ too.
<nckx>A note pointing back to bootstrapping would be nice.
<nckx>butterypancake: #goodfirstbug 😉
<butterypancake>oh dear, how deep am I going to get sucked in :P
<civodul>mothacehe: "console=ttyAMA0" + "-M virt -serial stdio" doesn't help
<alextee[m]>nckx: yoshimi bug looks fixed in master, but not released yet
<civodul>oh i was just reminded of libguestfs, maybe something we could use in the new image API
<alextee[m]>maybe we can do a 1.7.1-1 version from master
<nckx>alextee[m]: Cool. I'll add it as a patch.
<nckx>Yeah, something like that.
<nckx>I think 1.7.1 is fine here.
<mothacehe>civodul: you also need to pass -kernel and -initrd I guess
<mothacehe>one trick could be to use almost the same command line as the one used in load-in-linux-vm, but changing the device to the one you just produced.
<civodul>mothacehe: i wanted to run an image returned by "system vm-image"
<mothacehe>civodul: yes I get that. You picked the bare-bones.scm configuration, hence Grub bootloader. I doubt Grub supports ARMv7.
<mothacehe>So you need to specify kernel/initrd by hand
<civodul>mothacehe: hmm right, silly me!
<civodul>GRUB doesn't complain though, funny
<civodul>with -kernel i do get some output
<mothacehe>but :) ?
<civodul>our cross-compiled Guile 3.x is crashy with JIT enabled :-)
<civodul>so it crashes in /init, in the initrd
<civodul>to be continued...
<mothacehe>oh, ok. We could also provide a configuration with a bootloader supported by qemu-system-arm, so that the vm-image is directly bootable. For now, I only worked with specific target (hence specific bootloaders).
<mothacehe>Vast subject :)
<janneke>oh my!
<reepca`>are signal handlers inherited by new threads?
<guix-vits>reepca`: wrong tab?
<nckx>guix-vits: Sounds like a relevant daemon question.
<nckx>Have faith in our only person brave enough to hack the daemon.
<roptat>hi guix!
<apteryx>hello roptat!
<roptat>I've got two suggestions for the manual. The first would be to change the links in the installation instruction, because people can be confused by them (they don't work):
<roptat>change @var{system} with x86_64-linux so it would work in most cases, and propose changing that with i686-linux for the other architecture
<roptat>the second would be: add a QR-code to the manual when we tell users to reboot (and mention the availability of the manual). I've found that on the tails manual, and I think it's a great idea. What do people think?
<roptat>(the QR-code would help people with a smartphone to open the manual on their device)
<nckx>roptat: @var{system}: Fine. What does a QR code do?
<nckx>Does it encode an URL?
<roptat>it's a simple image that you can scan from your smartphone. it would contain the URL of the page you're seeing, so you can easily open it on your smartphone
<NieDzejkob>(it can encode any bytestring in general, but it's common to put URLs in them)
<nckx>Thanks for enlightening a blissful luddite. I'd seen it on a systemd system long ago (and on posters, of course).
<dissoc>what is the proper way to deal with non-guix bash scripts. most reference /bin/bash. is the expectation to replace them?
<nckx>roptat: Sounds cool 🙂
<roptat> suggests a few ways to keep the manual open while installing tails
<nckx>dissoc: Depends on the context. If you're building a package that uses them most are replaced for you by the build system, and you need to replace corner cases yourself.
<apteryx>dissoc: you could change them to use #!/usr/bin/env bash
<nckx>On ‘real’ systems, /bin/bash and /bin/sh have been de facto deprecated for decades, so change the script to use /usr/bin/env which will work out of the box.
<roptat>would it? I thought we didn't install /usr/bin/env by default?
<dissoc>nckx: that makes sense because i've experience that from writing packages.
<nckx>roptat: Oh, possible, it's changed more than once.
<nckx>It's probably still in the manual then, just search for /usr/bin/env.
<roptat>oh I have it on my system and it's not on purpose
<nckx>I have it on mine and it is.
<dissoc>thanks for the answers. my case is pretty greasy. it involves some build scripts for a java app that uses native code, which has some bash scripts
<apteryx>nckx: are you sure the practice of using #!/bin/bash is deprecated? I see it quite often still.
<nckx>roptat: I don't think it's great to have it, but we got a question literally every week and I was sick of it.
<nckx>apteryx: There's no authority.
<apteryx>to me its whether you want to use the system bash vs any version of bash that happens to be in the PATH. Depending of the context both could be correct.
<nckx>‘It breaks a lot, guess what people will say what you tell them’ is a close as it gets.
<nckx>apteryx: That's not up to the script author. Writing scripts on your own system, of course you do what you want, but then you know what to use.
<nckx>I use /run/current-system a lot.
<apteryx>especially in embedded circles, where everything is custom made for a single application and hard referring to things is not really frowned upon
<nckx>Right, that's different.
<nckx>Of course the real portable solution is curl | sudo bash.
*rekado_ faints
<apteryx>nckx: why isn't it great to have #!/usr/bin/env?
<nckx>Blah blah purity blah blah. It was just my throwaway persopinion.
*nckx pretending to work so needs to type something sometimes.
<nckx>If any future employer reads that (a) hi! hire me (b) don't hire me to respond to e-mails when you don't actually get any e-mails and then blame me that I'm not doing anything.
<apteryx>I think you also made the point that if we have /bin/sh, we might as well have /bin/bash in the paste
<nckx>Oh, really? Possible. I'm sure I had great and mad intelligent arguments, but that whole deal didn't end too well and I'm loath to relive it.
<nckx>Yay, 5:00.
*nckx → AFK.
<rekado_>mv /run/current-system/profile/bin /bin
<reepca`>something something read-only file system?
<rekado_>just keeping the flame alive
<nixfreak>guix package -i enlightenment --upgrade , correct or no
<nixfreak>or does that just re-install the package
<guix-vits>nixfreak: `guix package --help`
<guix-vits>probably -u is enough?
<nixfreak>ok cool thanks
<reepca`>nixfreak: depends on what you want to do. That command will create a new generation of your user profile containing enlightenment and updated versions of all packages from the current generation of your user profile.
<apteryx>nckx: enjoy AFK; IIRC the argument for /usr/bin/env (and to a lesser degree /bin/bash) was that we already had /bin/sh, and that if the purity argument was to prevent it should be removed for consistency.
<roptat>nixfreak, if you only want to update enlightenment and keep everything else at its current version, "guix install enlightenment" will do that
<apteryx>dissoc: there's also the extra-special-file service that you can use to create any symlink in a declarative fashion
<mbakke>rekado_: samplet already has a GHC 8.8.3 here:
<mbakke>the git dependency should be removed though
<janneke>so...what's the right curse to get a minimal texinfo doc setup? i''m trying texlive-bin texlive-tex-plain texlive-tex-texinfo
<janneke>but then i get: TeX neither supports -recorder nor outputs \openout lines in its log file
<apteryx>janneke: I would have though intalling texinfo should be enough? does it not refer to TeX absolutely?
<rekado_>janneke: always include texlive-base
<janneke>rekado_: ty, great!
<rekado_>I’m not sure it’ll fix things for you but it’s the set of packages that you need when you want to do anything with LaTeX
<rekado_>(it’s the “required set of LaTeX packages”)
<janneke>i needed also epfs; so this works for me: texlive-bin texlive-base texlive-tex-plain texlive-tex-texinfo texlive-epsf
<TZander>heya, does anyone know of a simple way to make this line go away? hint: Consider setting the necessary environment variables by running: [GUIX_PROFILE= etc]
<TZander>and, naturally, the GUIX_PROFILE env var is set (to /var/guix/profiles/per-user/).
<roptat>I have written a guile library and some of the tests require network access, so I can't run them in a guix build environment. Is there a way to disable only these tests, instead of every tests?
<nckx>alextee[m]: Applying <> leads to <> for which I need more coffee first.
<NieDzejkob>TZander: setting $GUIX_PROFILE is not the point
<NieDzejkob>the next line, where it tells you to source the profile file, is the important one
<alextee[m]>nckx: why not just use master?
<NieDzejkob>TZander: is this Guix System, or a foreign distro?
<alextee[m]>did you replace this line? YoshimiLV2Plugin.cpp:87
<nckx>alextee[m]: Because last release + patch is preferable. I haven't tried building master yet. I didn't change anything, just applied the attached patch.
<TZander>NieDzejkob: foreign. It was printed just after doing an upgrade.
*nckx will build master next.
<alextee[m]>all instances of "struct _LV2_Descriptor" should become "LV2_Descriptor", and all remaining instances of "_LV2_Descriptor" should become "LV2_Descriptor", you can just use sed i think
<alextee[m]>same for the UI descriptor thing
<alextee[m]>but i would just build master
<alextee[m]>they'll release a fix soon anyway
<TZander>NieDzejkob: oh, and on login the 'source' of profile is run. So not sure why there is this hint
<NieDzejkob>TZander: this usually happens when the profile file got some new env vars added to it
<NieDzejkob>restarting the shell will load them and make any new programs (or programs that now handle their environment variables differently) fully work
<NieDzejkob>for example, we somewhat recently merged the core-updates branch, which means that GCC now uses C_INCLUDE_PATH and CPLUS_INCLUDE_PATH instead of CPATH
<TZander>ohh, I guess that makes sense. The message is very confusing, though :)
<roptat>oh also the tests use scheme modules, and I'd like to make them with tests, but I don't understand where to put them in my
<nckx>alextee[m]: There is a misunderstanding: there *are* no occurences of either to replace. But building master works, I'll just use that. Thanks.
<nckx>Yep, this was far less effort than just commenting out yoshimi to update my profile 😊
*nckx celebrates with a shitty tune ♪
<dftxbs3e>nckx, rekado_, hey! did the 10G ethernet end up being fixed? :D
<sneek>Welcome back dftxbs3e, you have 1 message!
<sneek>dftxbs3e, marusich says: I haven't finished reorganizing/reformatting all your commits yet, and I have some questions I will ask later, but for now I thought you might want to know that with your first small change, applied to origin/master, a cross-built guile does not segfault:
<rekado_>roptat: what does “make them with tests” mean?
<roptat>I'd like these modules to be built only when I run "make check"
<dftxbs3e>sneek later tell marusish wow awesome!
<rekado_>roptat: oh, that’s unusual
<nckx>dftxbs3e: Typo.
<roptat>why is that?
<roptat>currently I've put them in SOURCES, but at install it installs the test modules which are not part of my library
<dftxbs3e>nckx, where?
<rekado_>roptat: are you using autotools?
<nckx>dftxbs3e: marusish.
<roptat>I am
<dftxbs3e>nckx, ahh
<dftxbs3e>sneek later tell marusich wow awesome
<sneek>Got it.
<rekado_>roptat: you can skip tests by overriding TESTS, e.g. make check TESTS=this
<nckx>sneek is simple boi.
<nckx>sneek: botsnack.
<roptat>rekado_, ah right
<rekado_>roptat: you shouldn’t add them to SOURCES
<roptat>but I still need to build them, right?
<roptat>I mean, I have tests/online.scm which uses modules in test-modules/
<rekado_>here the tests are under SCM_TESTS:
<roptat>but test-modules/... are not test programs themselves
<rekado_>and TESTS is SCM_TESTS
<nckx>dftxbs3e: Not yet, IIUC fixing that will require migrating ‘berlin’ to another machine first.
<rekado_>and to run them we define SCM_LOG_DRIVER
<dftxbs3e>nckx, I see
<rekado_>dftxbs3e: I suspect that the NIC is broken.
<rekado_>we don’t have a spare that would fit in that server, but we have other servers with 10G NICs
<roptat>rekado_, this is what I have right now:
<roptat>so test-modules/testsuite.scm does not belong to my library, but it's not a test file, it doesn't belong to TESTS either
<rekado_>do you need to compile them at all?
<rekado_>wouldn’t it be enough to load them?
<roptat>yeah, I'll do that
<rekado_>(why does the readme say: “Otherwise, your package manager might have guile-jsonld available”?)
<roptat>probably because I copied it from my guile-jsonld library :p
<roptat>which has the same issue :)
<dftxbs3e>sneek later tell marusich I used GNU Guile 2.2 previously for some reason
<sneek>Got it.
<emys>hi, can a package have conditional dependencies (inputs) depending on a choice of outputs?
<roptat>emys, inputs are fixed by package, but you can create variants with more or less inputs
*apteryx fixes ABI mismatch errors with: grep --include='*.scm' -rl origin | sed s/scm/go/ | xargs rm -f {}\;
<apteryx>crude, but more efficient than 'make clean-go' ;-)
<TZander>it would be nice if guix could build out-of-tree (which includes not changing any source files due to translations).
<nckx>emys: Outputs aren't conditional and are all built together, so there's no way (or -where) to split inputs. Could you give a concrete example?
<emys>nckx, so let me explain what I want to do. I want to us hg-git, the mercurial extension that lets one clone git repos with local checkout being a mercurial checkout.
<emys>thats the hg-git package I came up with
<emys>turns out, the extension is not found by mercurial
<emys>I think it is because hg-git is not an input of mercurial
<emys>so hg-git is not in the paths
<emys>to fix it, hg-git would need to be an input of mercurial
<emys>arguably I think it wouldn't be a huge price to pay to add it as an input to mercurial for everyone
<emys>in terms of "bloat"
<emys>yet, having it optional would also be nice so I wanted to explore the options in that regard.
<nckx>Yes, that would make it a hard dependency. What we do instead is make packages look in a known plug-in directory (or even more ideally: list of directories).
<nckx>Completely fictional example: MERCURIAL_EXTENSION_PATH=/gnu/store/foo:/gnu/store/bar
<nckx>Does mercurial support anything like that?
<emys>so I am not a mercurial expert, what I saw is that in the .hgrc file one can give paths to extension
<emys>like for each extension a specific path
<nckx>Hm, that's not great, Guix can't set that for you.
<emys>which is kind of impractical with guix because each update will change that path
<emys>I guess (kind of new to guix)
<emys>will look into the hg docs
<emys>guix size python-hg-git. ..... # => total: 0.2 MiB
<nckx>emys: It's likely that /gnu/store file names would end up in the configuration and break later, yes. It's happened many times before.
<nckx>I have to leave now but I'll read the log later and will look into hg extensions a tiny bit.
<butterypancake>Submitted my first patch! This is the biggest open source thing I've done to date! How long until it shows up in debbugs? I'm a little nervous :P
<MSavoritias>Hi. I bought this Technoethical N150 Mini Wi-Fi USB Adapter for GNU/Linux today. It says it works out of the box but it doesnt seem to be running at all in Guix. Not even detected. Is there something I should enable? The driver should be ath9k
<nckx>butterypancake: A few minutes. Either you've already passed moderation or your mail hasn't arrived yet, & I'll approve it immediately.
<nckx>Congratulations! We do strongly prefer ‘free software’ over ‘open source’, though. We don't see the two as equivalent. 😉
<butterypancake>my bad :P I've watched the RMS documentary and everything. Don't know why I can't seem to remeber to call it free :P
<nckx>That's quite all right.
*nckx → not here.
*apteryx is doubtful
<bdju>MSavoritias: the tehnoetic site says that USB adapter uses the Atheros AR9271 chipset. I searched guix packages for "ath9k" as you had mentioned it. There's one result, and the package description mentions the AR9271 specifically, so just installing that should do the trick most likely. (and then you may have to reboot as well)
<bdju>MSavoritias: that package being ath9k-htc-firmware
<roptat>it should probably be part of the configuration somewhere
<roptat>it's already in %base-firmware actually, so there shouldn't be a need to add or install it
<apteryx>sneek later tell MSavoritias that's strange. My ath9k based wifi adapters work out-of-the-box, without requiring to do anything.
<sneek>Got it.
<MSavoritias>I installed the package and rebooted but still nothing. Btw why are there not wifi settings in the settings app?
<sneek>MSavoritias, you have 1 message!
<sneek>MSavoritias, apteryx says: that's strange. My ath9k based wifi adapters work out-of-the-box, without requiring to do anything.
<MSavoritias>I tried also lspci but showed nothing
<MSavoritias>yeah... i tried also on solus my girlfriends linux. and a live cd of guix and still nothing
<MSavoritias>im starting to think there is a problem with the specific usb
<MSavoritias>do the wifi settings appear by themselves in settings?
<lfam>cbaines: Regarding my botched update of kr-pretty... Err, thanks for fixing it! I don't know how that passed my local tests. I must have dropped that hunk while doing Git surgery.
<apteryx>MSavoritias: isn't it listed in /var/log/messages when you plug it?
<apteryx>also, lsusb show show it
<apteryx>it should show something like: Bus 001 Device 020: ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n
<apteryx>(this is with my ThinkPenguin TPE-N150USB, which looks like the same thing)
<apteryx>it works without a fuss
<MSavoritias>doesnt show anything in either one of them
<apteryx>does it on another GNU/Linux PC with a different distribution? (if you have one)
<apteryx>if not, the dongle may be dead
<MSavoritias> I tried on my girlfriends linux laptop. It was still nothing. yeah seems like it. well i hope they accept returns
<bdju>Is there info anywhere about how to undervolt my CPU on Guix System? I'm getting some thermal throttling that I'd avoided via undervolting on NixOS with a "services.undervolt" in my configuration.nix
<apteryx>this is the /var/log/messages that I see when plugging my N150 key:
<apteryx>we see it loads a htc_9271.fw, which appears to be present in the default Guix System configuration
<lfam>I wonder, is there a difference between thermal throttling and undervolting? In both cases the system slowed down
<bdju>thermal throttling does come with slowdown, undervolting does not inherently negatively impact performance, just reduces power to the CPU which reduces heat
<bdju>undervolting in theory prevents the excess heat and thus prevents the thermal throttling, so you stay at your normal clocks consistently instead of being dropped down
<MSavoritias>@apteryx there is not even a message for me
<bdju>(you can undervolt without underclocking)
<MSavoritias>nothing to indicate that it tries to connect even
<lfam>So there's a needle to thread, huh? :)
<bdju>I think you can even undervolt and overclock, I'm not an expert on this stuff, but I at least know my ThinkPad gets too hot with normal settings and my dmesg is spammed with thermal throttling messages
<bdju>it's a problem I've had with several models, it may be worse from running them in a dock. not sure if that impacts airflow
<apteryx>MSavoritias: I confirm it should work out-of-the-box. In (gnu system), ath9k-htc-firmware is part of the %base-firmware, which is the default value of the `firmware' field of the operating-system record.
<apteryx>so nothing there's nothing to install or do to get support for your hardware on Guix System.
<MSavoritias>ok. thanks for the help. :)
<butterypancake>engineering student here, CPU's are designed to run at a certain frequency. Any faster and you could start getting race conditions (but you can push it). The physical silicon also only activates at a certain voltage. Sometimes you can push that lower too. The silicon sometimes needs a higher voltage to respond quicker, hence why some overclockers also bump the voltage. You can also decrease the frequency if you want to increa
<butterypancake>wiggle room you have for lowering the voltage. However, the engineers who designed that CPU did pick a certain frequency and voltage, and straying from that always risks instability. You can indeed both undervolt and overclock, but you get as far in either direction as both of those are introducing instability
<butterypancake>*won't get as far
<bdju>very cool. thanks for the lesson
<butterypancake>It's been 40 minutes since I submitted my patch and I still don't see it in debbugs :( I'm getting antsy
<lfam>butterypancake: Is it your first patch?
<lfam>Or, your first email to that address?
<butterypancake>yep. I probably just need to walk away and wait for someone to manually approve :P
<lfam>Yeah, first-time senders go into a manual moderation queue for anti-spam. Sorry :/
<lfam>It only happens the first time
<nckx>butterypancake: But it's not *in* the queue, is the thing.
<nckx>butterypancake: Did you send it to guix-patches at
<bdju>I found out which package nixos uses for their undervolt service and I put it on the guix wishlist under the hardware section (in case anyone is looking for something to do)
<nckx>The moderation Web UI is a bit slow, maybe that's a hint that the rest is too.
<nckx>bdju: Is it that forum-based thing (with a three-letter name that I always forget)?
<nckx>thc or something.
<lfam>I wonder, did it definitely get sent butterypancake? What program did you use to send it?
<nckx>My CPU is one generation too new to support it X-(
<nckx>Or old. I forget.
<butterypancake>I sent it to guix-patches, and the outlook web gui shows me that it did send. I used git send-email
<bdju>nckx: forum-based thing? if you mean the location of the wishlist, it's on libreplanet
<nckx>bdju: No the package.
<lfam>Okay, if your web UI shows it as sent, then it's probably got sent
<bdju>nckx: this appears to be the package
<nckx>Oh no, that's something else.
<nckx>Neat! I'll try it.
<lfam>Sorry to break your motivation butterypancake. I know how frustrating it can be
<nckx>If it works for me that means a package for you.
<nckx>butterypancake: Sometimes (not often) a mailing list just goes out to lunch for a few hours. Let's wait another hour or so.
<butterypancake>ya, I tested it by sending it to a second email I have, and it does seem to send. I'll stop worrying :P
<emys>nckx, so it seemsthat hg looks in the pythonpath
<bdju>nckx: I think I finally get what you meant earlier, there's "tlp". I have that running, actually, and am still having thermal issues
<butterypancake>If a made a commit to master, is there an easy way to move that commit to a branch?
<bdju>looks like tlp is more about battery life than temperature optimization, based on the website
<lfam>butterypancake: `git checkout $branch && git cherry-pick $commit`
<butterypancake>They say "You save 3 Watts of battery life", you say "3 Watts didn't become heat". It's all the same really
<nckx>bdju: No, it was specifically to undervolt Intel CPUs and it's ‘home page’ was just an old-school forum that dropped tarballs over the wall. Doesn't matter, it was old then and is probably obselete now.
<guix-vits>bdju: `cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor` ?
<nckx>butterypancake: If you're on the branch, ‘git cherry pick <the commit>’.
<nckx>butterypancake: True, but tlp handles a lot more than CPU freq (and I don't know if it touches voltage at all).
<nckx>emys: Hmm, OK.
<nckx>The bad thing about that is we can't use it as native-search-path, but maybe it gives us a way out.
<nckx>Or is it a way in?
<nckx>A matter of perspective.
<butterypancake>got it, thanks lfam and nckx
<lfam>I've been wondering, what is the difference between native-search-paths and search-paths?
<nckx>This was it:
<raghavgururajan>All of a sudden, `./pre-inst-env guix build foo` does nothing. It just stays at loading.
<nckx>Opening the ‘home page’ link automatically closes the tab in Ice Cat + uBlock which is… a very bad sign.
<raghavgururajan>Disk I/O keep buffering on my thinkpad and that's it.
<apteryx>lfam: me too. From past research, search-paths takes the value of native-search-paths by default, so they act the same except native-searchs-path should be honored in the build container IIRC.
<raghavgururajan>I even tried restarting my system.
<apteryx>I'm not sure any of this is still accurate though, so I'd encourage you to have a look :-)
<lfam>I thought it would be something like that apteryx, but the docs are unclear
<apteryx>I agree.
<lfam>Based on how we use the word 'native' in Guix
<lfam>It came up in the context of my patches for alsa-lib: <>
<raghavgururajan>The command `./pre-inst-env guix build foo`executes, but nothing happens.
<lfam>Usually that means that foo is already built
<lfam>Or, it means that your development environment is not set up correctly
<lfam>If you think it should do work and it does nothing, make sure that the environment is configured properly
*raghavgururajan checks
<rekado_>lfam: re – with Guix System we can use G-exps to refer to the actual plugin directory in the alsa-configuration for alsa-service-type
<lfam>Right rekado_, already it's handled on Guix System
<rekado_>having an environment variable would be useful for foreign distros
<lfam>My patch addresses the foreign distro use case
<lfam>I think the patch is sound although it would be great to get another pair of eyes on it
*rekado_ cannot be trusted to review C code :-/
<lfam>It's tough for sure
<rekado_>raghavgururajan: if nothing at all happens and the command doesn’t terminate you may have a dependency cycle somewhere.
<lfam>I put a lot of effort into making sure the heap allocations are big enough or the right size, and that they are idiomatic for alsa-lib
<lfam>The old patches from nixpkgs were rather bad, I'm not suprised they removed them
<lfam>It would be nice to get something like this upstream in alsa-lib
<lfam>I do think it's in the right spirit... upstream has set things up so that work automagically on traditional distros
<bdju>guix-vits: result of that is "performance". I suppose then you'd say I should switch modes?
<nckx>bdju: Performance hard-locks your CPU to 100% frequency at all times.
<nckx>It's almost never a good thing.
<guix-vits>bdju: maybe it's hot because of this mode? `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors`, Try to switch to powersave. IDK, but maybe it's sufficient?
<butterypancake>if I'm packaging a release and the author signed the release tag, I should validate that yes? Also how?
<nckx>Use ‘conservative’ on laptops.
<bdju>Well, if that mode is set in the BIOS, it'd be the same as it was on NixOS where I was fine after an undervolt, but I suppose it's worth a shot to tweak that.
<bdju>Looks like my other available mode is "powersave".
<bdju>Is this something I can set in my config.scm now?
<lfam>butterypancake: Check the --show-signature option of certain Git commands
<butterypancake>anyone know any packages that do that? I work well with examples. And certianly not becaue I don't know scheme :P
<bdju>My last throttling event was over an hour ago, I suspect I was running updates or something. Although, I'd prefer if it didn't happen even then.
<nckx>It's still bad regardless of voltage. The default is set in your kernel configuration (given how universally wrong a choice ‘performance’ is we should probably change that).
<guix-vits>bdju: "worst case scenario":
<nckx>You can't set it on the command line, so your only hope is to write it to sysctl at every boot. I think there's a service for that.
<nckx>bdju: ☝
<bdju>I started looking through services in the manual. I see tlp has several for setting different power states. Not sure if that's the place I should set it, though.
<nckx>bdju: Probably.
<nckx>If any service ever should handle it it's TLP.
***sputny1 is now known as sputny
<butterypancake>I'm looking at the recipe for guix which I thought signed it's commits but I don't see the verification logic. or is signed commits and tags different?
<lfam>You don't verify signatures in package recipes
<nckx>butterypancake: We don't check signatures in packages.
<lfam>You do it while writing the recipe and then include the hash of the source code
<butterypancake>I swore I read somewhere in the manual that you should check the signature on tar balls but I've been trying to find it again and I can't seem too :/
<bdju>This was my attempt at configuring it, but it seems to be wrong: (service tlp-service-type #:config (tlp-configuration (cpu-scaling-governor-on-ac 'powersave)))
<katco>i built a docker image utilizing `guix system docker-image`. the image includes packages from some channels in its global packages. however, when i attempt to access the channel packages within the container image, guile/guix cannot find them. even `specification->package` fails to find them. how can i utilize channel based packages in this manner?
<nckx>butterypancake: Yes, you should, but manually: by typing ‘gpg --verify’ or so before updating the hash.
<butterypancake>that makes a ton of sense. Thank you!
<nckx>Since Guix checks the hash on all machines, everyone will know they're getting that exact tarball, but checking the signature on each machine would be pointless theatre.
<nckx>Fragile theatre.
<butterypancake>that makes a lot of sense. Thank you!
<nckx>I.e. ‘got it, shut up’ 😃
<nckx>bdju: Yeah, that ‘#:config’ keyword doesn't make sense. Try without it. Did you find that in docs?
<nckx>I just approved a patch adding mspdebug.
<butterypancake>I'm so very happy
<nckx>So it was a lunch break after all.
<butterypancake>That's me on there! It even made my name purple becaue I'm special :D. I've never seen this before
<nckx>Further patches from that address will not be moderated.
<bdju>nckx: I actually had an elogind config thing on another line using that and so I just copied it
<nckx>bdju: Really, using the (service FOO BAR) notation? That's… not idiomatic, I think.
<bdju>Now I've got this error: guix system: error: Invalid value for field cpu-scaling-governor-on-ac: powersav
<bdju>this is the elogind line if you're curious: guix system: error: Invalid value for field cpu-scaling-governor-on-ac: powersav
<nckx>bdju: ‘maybe-space-separated-string-list’
<bdju>(elogind-service #:config (elogind-configuration (handle-lid-switch 'ignore)))
<nckx>our documentation is not the clearest.
<nckx>So I'm guessing "powersave" will work.
<bdju>I tried adding quotes after the ' and that didn't work, tried removing the ' and it still didn't work
<pkill9>why does sudo preserve $PATH by default?
<nckx>bdju: Why ' at all? Just (foo "bar").
<bdju>I was again just copying the elogind line
<bdju>this is what I've got now and it doesn't work: (service tlp-service-type (tlp-configuration (cpu-scaling-governor-on-ac "powersave")))
<nckx>Since ' is called ‘quote’ in Scheme, watch out with sentences like ‘I added quotes after the ' ’, it can get confusing quickly.
<nckx>bdju: Right, but quoting (') a symbol makes sense, quoting a "string" doesn't. Never mind.
<nckx>bdju: What's the error?
*nckx fires up emacs…
<bdju>it has not changed in several attempts
<bdju>guix system: error: Invalid value for field cpu-scaling-governor-on-ac: "powersave
<bdju>oh, actually it changes subtly
<bdju>and also I cut off the ending double quote
<nckx>Oh look, I'm already using TLP. I honestly forgot. Here's my (working) set-up:
<nckx>‘maybe-space-separated-string-list’ is the worst name ever for ‘a list of strings that we'll separate by spaces as an implementation detail later’.
<nckx>I'm sure I needed 2 tries to get it right then.
<bdju>sweet, went through now
<bdju>by the way, I notice you're using "conservative". I read that option comes from some driver being installed, but one of the files I cat'd earlier only listed two available settings.
<bdju>How do I install that drive?
<nckx>I use a custom kernel, I suspect that's how. Although Guix's linux-libre should include all governors, they're modular and tiny.
<bdju>ah, alright.
<nckx>Oh, you're not using acpi-cpufreq? What are you using?
<bdju>I'm... not sure. Where would I check?
<guix-vits>`cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver`
<nckx>A magical guix-vits appears.
<bdju>thanks guix-vits
<nckx>Same here.
<nckx>So I don't know why it doesn't work for you.
<bdju>well, I didn't try, an earlier thing just didn't list conservative as an option
<bdju>I'll try it
<nckx>Oh oh oh, this has changed since I last checked it: /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
<nckx>performance powersave
<nckx>That's new. Hm.
<bdju>Well, no error setting it to conservative, but then I worry that it could be a silent failure.
<nckx>It is.
<nckx>Powersave is fine by the way.
<bdju>Do I have to reboot for that to take effect? I'm still seeing the scaling_governor file output "performance"
<nckx>Conservative is powersave tweaked just a bit more towards, er, power saving by not upscaling as fast.
<nckx>bdju: Have you reconfigured and (perhaps) run sudo herd restart tlp?
<bdju>the former, but not the latter
<bdju>ah, that did the trick
<butterypancake>is there a way to replace the default configure flags with my own? A package I'm trying to do only accepts very few flags for its configure
<butterypancake>I did try reading gnu.scm but honestly I didn't understand much
<nckx>butterypancake: You'd define your own package ~somewhere~ that inherits from the original and changes only the configure flags.
<ryanprior>butterypancake: you mean in a package definition? You can replace the configure step and invoke configure in any way of your choosing.
<nckx>butterypancake: Search gnu/packages/*scm for substitute-keyword-arguments for examples.
<nckx>They'll also show you how to use (inherit …), but of course that's trivial.
<nckx>You write (inherit …).
<butterypancake>emacs can't seem to define substitute-keyword-arguments for me even though I added the guix repo to geiser-guile-load-path like the info page said too...
*nckx doesn't use geiser…
<butterypancake>idk, I'm trying to learn scheme. Honestly I haven't use geiser much anyways as all it seems good for is freezing emacs. or maybe that's semantic mode. Whoever wrote the emacs section in the guix manual had a much bigger hard on for this combo than I seem to have :/
<katco>hi, does anyone have any input for my question above?
*nckx doesn't use containers either…
<guix-vits>katco: seems no (according to backward search)
<butterypancake>docker is hard
<katco>well i appreciate the falsification of input at any rate :)
<rekado_>katco: the docker image is just a nested tarball. Have you looked inside to see if it contains what you expect?
<katco>the store contains the packages, but i can't figure out how to reference them
<rekado_>what do you mean by “the store contains the packages”?
<rekado_>how is that related to the container you built?
<katco>i.e. the assets are present, but i can't do say `(specification->package "my-channel-package")`
<rekado_>where can’t you do that?
<katco>within the container
*rekado_ shrugs
<katco>within a guile repl, or in a package specification
<rekado_>katco: can you show us “guix describe”
<rekado_>the store is only a cache. If you have no channels enabled in your current version of Guix you won’t have access to channel packages.
*katco sent a long message: < >
<rekado_>even if their outputs might be cached somewhere
<katco>the guix which produced the container image contains the channels, but the guix container it produces apparently does not
<rekado_>was this “guix” command obtained with “guix pull”?
<rekado_>wait, so you put Guix inside the container as well?
<katco>it was obtained by including the `guix` package within an `operating-system`'s package field.
<katco>yes, you got it
<katco>i want to be able to pipe guix commands through this container, such as `guix build`. this is a common scenario with buildboxes.
<raghavgururajan>rekado_: Yep, that was it. gtk-doc was depedency-cycle.
<rekado_>you would need to arrange for /etc/guix/channels.scm to be installed in the container
<rekado_>and then you’d need to pull in the container to get that channel-augmented version of Guix
<rekado_>the alternative is to build a custom “guix” package (instead of the one from gnu/packages/package-management.scm) that includes the modules provided by your channel(s)
<rekado_>gotta go
<katco>`/run/current-system/channels.scm` is correct within the container. i haven't done a pull yet. but that should be doable: perform a pull and then snapshot the container image
<katco>thx rekado_ !
<katco>if i can get this working, it will be a blog post
<butterypancake>ok, so I don't think I know how to use substitute-keyword-arguments. I instantly got to 100% CPU usage and my computer froze for a minute.
<butterypancake>I used it like this:
<butterypancake> (arguments (substitute-keyword-arguments (package-arguments opendoas) ((#:configure-flags flags) flags)))
<butterypancake>where the package I'm currently packaging is opendoas
<butterypancake>does that make some crazy recursion without an exit condition?
<apteryx>butterypancake: probably! Why are you trying to reference opendoas's own arguments within the opendoas package definition?
<butterypancake>idk, people told me to use this. I think it's probably too much. All I want, is to throw away all the default configure-flags and give it my own
<butterypancake>opendoas has a very limited configure script that won't accept the defaults
<apteryx>othen you can simply use the argument: #:configure-flags '(your flags)
<butterypancake>that appends more flags, doesn't remove to defaults
<butterypancake>the defaults causes the configure script to throw errors and won't continue
<apteryx>OK, then what I'd do is replace the configure phase altogether
<apteryx>grep for '(replace 'configure' in the sources, you'll find plenty of occurences
<nckx>butterypancake: (arguments #:phases (modify-phases %standard-phases (replace 'configure (lambda _ (invoke "configure" "foo" "bar" …
<butterypancake>oh sweet! Thanks nckx
<nckx>butterypancake: substitute-keyword-arguments is to modify the #:configure-flags of an existing package, not those appenden by the build system, there's no way to avoid those without replacing 'configure.
<butterypancake>how do you guys look up documention? I went to use geiser to look up invoke but apparently geiser is useless (or more likely misconfigured). I read the first little bit of the guile info pages but honestly those could use some work
<mbakke>pro tip: using (replace 'configure (lambda* (#:key configure-flags #:allow-other-keys) (apply invoke "./configure" configure-flags))) will let you keep using #:configure-flags without the "extra" flags added by gnu-build-system
<apteryx>butterypancake: there are two layers of code involved 1) the upper level where the packages are defined, and 2) inner level that is executed in the build container
<apteryx>often the bindings such as invoke that come from (guix build utils) are available only in the scope of the build code.
<apteryx>Geiser only finds stuff available in scope
<butterypancake>i ran (add-to-list 'geiser-guile-load-path "~/src/guix") so I though geiser might be more useful.
<apteryx>It *is* useful after we've groked how it works :-) give it some time
<apteryx>what I like to do is launch Geiser with C-c C-a
<apteryx>it starts the Geiser REPL and loads the current module
<apteryx>If you need more bindings (such as those of in a #:modules argument), you can ,import them in Geiser
<apteryx>after that the navigation (M-. and M-,) and documentation C-d d should just work
<butterypancake>I guess I'll look into it. It might be worth it to actually learn some scheme and some scheme related tools instead of just glueing random things together
<apteryx>butterypancake: this piece of config I use may be useful too:
<butterypancake>apteryx: could you share the function that starts the geiser repl and loads the current module?
<apteryx>it comes with Geiser
<butterypancake>and I'm curious what's in your guix-devel-mode
<apteryx>C-c C-a
<apteryx>or M-x geiser-mode-switch-to-repl-and-enter
<butterypancake>thanks! It even comes with evil bindings from somewhere. g Z for me
<butterypancake>is execpve() not in glibc? what is it in?
<butterypancake>oh, I probably just didn't tell it where glibc is. I should do that
<apteryx>butterypancake: do you mean execve?
<butterypancake> system has no execvpe(3): not supported
<butterypancake>hmmm... it knows where glibc is if it's asking the environment variables
<apteryx>I don't know! Are you using the gnu-build-system?
<apteryx>guix-devel-mode comes from emacs-guix
<jonsger>is there a way to bring libgcc, libstdc
<jonsger>et. al to a guix environment?
<apteryx>I think you want to --ad-hoc gcc-toolchain
<apteryx>but this is usually implicit if you 'guix environment some-package' if some-package uses the gnu-build-system for example
<jonsger>its for stuff not in guix
<apteryx>OK. Then gcc-toolchain is what you're after